Skip to main content

Home/ SoftwareEngineering/ Group items tagged software

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
kuni katsuya

Access control - Wikipedia, the free encyclopedia - 0 views

en.wikipedia.org/...Access_control

security models authentication authorization

shared by kuni katsuya on 31 Aug 12 - No Cached
  • Computer security
  • authentication, authorization and audit
  • In any access control model, the entities that can perform actions in the system are called subjects, and the entities representing resources to which access may need to be controlled are called objects
  • ...39 more annotations...
  • Principle of least privilege
  • object-capability model, any software entity can potentially act as both a subject and object
  • Access control models used by current systems tend to fall into one of two classes:
  • those based on capabilities
  • those based on access control lists (ACLs)
  • Both capability-based and ACL-based models have mechanisms to allow access rights to be granted to all members of a group of subjects (often the group is itself modeled as a subject)
  • identification and authentication determine who can log on to a system, and the association of users with the software subjects that they are able to control as a result of logging in; authorization determines what a subject can do; accountability identifies what a subject (or all subjects associated with a user) did.
  • Authorization determines what a subject can do on the system
  • Authorization
  • Access control models
  • categorized as either discretionary or non-discretionary
  • three most widely recognized models are
  • Discretionary Access Control (DAC)
  • Mandatory Access Control (MAC)
  • Role Based Access Control (RBAC)
  • Attribute-based access control
  • Discretionary access control
  • Discretionary access control (DAC) is a policy determined by the owner of an object. The owner decides who is allowed to access the object and what privileges they have.
  • Every object in the system has an owner
  • access policy for an object is determined by its owner
  • DAC systems, each object's initial owner is the subject that caused it to be created
  • Mandatory access control
  • Mandatory access control refers to allowing access to a resource
  • if and only if rules exist
  • that allow a given user to access the resource
  • Management is often simplified (over what can be required) if the information can be protected using
  • hierarchical access control
  • or by implementing sensitivity labels.
  • Sensitivity labels
  • A subject's sensitivity label specifies its
  • level of trust
  • level of trust required for access
  • subject must have a sensitivity level equal to or higher than the requested object
  • Role-based access control
  • Role-based access control (RBAC) is an
  • access policy
  • determined by the system
  • not the owner
  • Access control
kuni katsuya

Dependency injection discourages object-oriented programming? @ Blog of Adam Warski - 0 views

www.warski.org/...es-object-oriented-programming

java javaee6 CDI CdiDependencyInjection OO Object-Oriented procedural DI DependencyInjection

shared by kuni katsuya on 12 Dec 12 - No Cached
  • Dependency injection discourages object-oriented programming?
  • if you’re using DI, and you have an X entity, do you have an XService or XManager with lots of method where X is the first argument?
    • kuni katsuya
      kuni katsuya on 12 Dec 12
       
      evidence of the anti-pattern of procedural design in a java ee6 cdi application
  • previous way is more procedural
    • kuni katsuya
      kuni katsuya on 12 Dec 12
       
      ie. ProductService.ship(Product,Customer)
  • ...12 more annotations...
  • service/manager is a set of procedures you can run, where the execution takes a product and a customer as arguments
  • better
  • OO approach
  • not saying that achieving the above is not possible with a DI framework
  • only that DI
  • encourages the ProductService approach
    • kuni katsuya
      kuni katsuya on 12 Dec 12
       
      well, dependency injection, but moreover, the soa approach to service design tends to force otherwise intelligent software engineers into doing procedural design the services just end up being bags of method calls that implement any type of behavior, with the domain objects or entity beans being reduced to mere data structures with little responsibility or behavior beyond persistence. (which, in this anti-pattern, is typically mostly provided by the repository or dao class! ie. domain object crud)
  • it’s just easier
    • kuni katsuya
      kuni katsuya on 12 Dec 12
       
      ... if you just blindly follow the anti-pattern, of course  ;)
  • many benefits
    • kuni katsuya
      kuni katsuya on 12 Dec 12
       
      with the procedural approach, you also cannot implement polymorphic behavior, for instance
  • builder
  • fluent interface
  • it’s not for small projects
    • kuni katsuya
      kuni katsuya on 12 Dec 12
       
      fuckwhat? small or big matters not. if di is applied poorly, regardless of project size, it's an anti-pattern! disregard these comments!
  • problems with DI frameworks:
    • kuni katsuya
      kuni katsuya on 12 Dec 12
       
      not sure i agree with these points, but will refuse in a later sticky note
kuni katsuya

DDD: putting the model to work - 0 views

www.infoq.com/...model-to-work-evans

DomainDrivenDesign presentation

shared by kuni katsuya on 27 Mar 13 - Cached
  • DDD: putting the model to work
  • foundations of domain-driven design:How models are chosen and evaluated;How multiple models coexist;How the patterns help avoid the common pitfalls, such as overly interconnected models;How developers and domain experts together in a DDD team engage in deeper exploration of their problem domain and make that understanding tangible as a practical software design.
kuni katsuya

GraphicsMagick Image Processing System - 0 views

www.graphicsmagick.org/index.html

graphicsmagick

shared by kuni katsuya on 23 Apr 13 - Cached
  • does not conflict with other installed software
    • kuni katsuya
      kuni katsuya on 23 Apr 13
       
      ie. dependencies
  • process billions of files at the world's largest photo sites
    • kuni katsuya
      kuni katsuya on 23 Apr 13
       
      ie. battle tested
  • over 88 major formats
  • ...1 more annotation...
  • multi-threaded
kuni katsuya

What is SiteCatalyst? | Adobe Developer Connection - 0 views

developer.omniture.com/...c-what-is-sitecatalyst

Adobe Omniture SiteCatalyst documentation

shared by kuni katsuya on 23 Jan 13 - No Cached
  • What is SiteCatalyst?
  • What is SiteCatalyst?
  • What is SiteCatalyst?
  • ...4 more annotations...
  • software-as-a-service (SaaS) solution that
  • collects web site visitor's online analytics data like page views and visits
  • provides both a data processing and reporting platform.
  • SiteCatalyst User's Guide
kuni katsuya

Stephen Colebourne's blog: Javadoc coding standards - 0 views

blog.joda.org/...javadoc-coding-standards.html

java javadoc BestPractices documentation design communication

shared by kuni katsuya on 13 Dec 12 - No Cached
  • Javadoc coding standards
  • explain some of the rationale for some of my choices
  • this is more about the formatting of Javadoc, than the content of Javadoc
  • ...63 more annotations...
  • Each of the guidelines below consists of a short description of the rule and an explanation
  • Write Javadoc to be read as source code
  • Making Javadoc readable as source code
  • Public and protected
  • All public and protected methods should be fully defined with Javadoc
  • Package and private methods do not have to be, but may
  • benefit from it.
    • kuni katsuya
      kuni katsuya on 13 Dec 12
       
      think of it as internal design documentation when you revisit this code 8 months from now: - based on nothing but your well-chosen ;) package/class/method/variable names, will you recall all of your current design intentions and rationale? likely not - when you hand-off this code to another software engineer, how easy will it be to mostly rtfm? will you have to waste time preparing design/implementation notes specifically for the hand-off? if this is the case because the code is unreadable and not self-guiding and there's not already at least high level design notes in a wiki, you're doing it wrong!
  • If a method is overridden in a subclass, Javadoc should only be present if it says something distinct to the original definition of the method
    • kuni katsuya
      kuni katsuya on 13 Dec 12
       
      ie. don't just copy-paste the javadoc from the superclass. that's mindless and pointless monkey work
  • Use the standard style for the Javadoc comment
  • Do not use '**/' at the end of the Javadoc
  • Use simple HTML tags, not valid XHTML
  • XHTML adds many extra tags that make the Javadoc harder to read as source code
  • Use a single <p> tag between paragraphs
  • Place a single <p> tag on the blank line between paragraphs:
    • kuni katsuya
      kuni katsuya on 13 Dec 12
       
      this at least makes the paragraph breaks wysiwygísh and somewhat easier to read
  • Use a single <li> tag for items in a list
  • place a single <li> tag at the start of the line and no closing tag
  • Define a punchy first sentence
  • it has the responsibility of summing up the method or class to readers scanning the class or package
  • the first sentence should be
  • clear and punchy, and generally short
  • use the third person form at the start
  • Avoid the second person form, such as "Get the foo"
  • Use "this" to refer to an instance of the class
  • When referring to an instance of the class being documented, use "this" to reference it.
  • Aim for short single line sentences
  • Wherever possible, make Javadoc sentences fit on a single line
  • favouring between 80 and 120 characters
  • Use @link and @code wisely
  • @link feature creates a visible hyperlink in generated Javadoc to the target
  • @code feature provides a section of fixed-width font, ideal for references to methods and class names
  • Only use @link on the first reference to a specific class or method
  • Use @code for subsequent references.
  • This avoids excessive hyperlinks cluttering up the Javadoc
  • Never use @link in the first sentence
  • Always use @code in the first sentence if necessary
  • Adding a hyperlink in that first sentence makes the higher level documentation more confusing
  • Do not use @code for null, true or false
  • Adding @code for every occurrence is a burden to both the reader and writer of the Javadoc and adds no real value.
  • Use @param, @return and @throws
  • @param entries should be specified in the same order as the parameters
  • @return should be after the @param entries
  • followed by @throws.
  • Use @param for generics
  • correct approach is an @param tag with the parameter name of <T> where T is the type parameter name.
  • Use one blank line before @param
  • This aids readability in source code.
  • Treat @param and @return as a phrase
  • They should start with a lower case letter, typically using the word "the". They should not end with a dot. This aids readability in source code and when generated.
  • treated as phrases rather than complete sentences
  • Treat @throws as an if clause
  • phrase describing the condition
  • Define null-handling for all parameters and return types
    • kuni katsuya
      kuni katsuya on 13 Dec 12
       
      ideally, if the method in question has any specified/required pre and/or post conditions, they should be noted in the javadoc, not *just* null handling also, there are cleaner ways to design around this type of old school null handling hackage
  • methods should define their null-tolerance in the @param or @return
  • standard forms expressing this
  • "not null"
  • "may be null"
  • "null treated as xxx"
    • kuni katsuya
      kuni katsuya on 13 Dec 12
       
      DO NOT DO THIS this is just bad design
  • "null returns xxx"
    • kuni katsuya
      kuni katsuya on 13 Dec 12
       
      this might also stink of poor design ymmv
  • In general the behaviour of the passed in null should be defined
  • Specifications require implementation notes
  • Avoid @author
  • source control system is in a much better position to record authors
  • This wastes everyone's time and decreases the overall value of the documentation. When you have nothing useful to say, say nothing!
    • kuni katsuya
      kuni katsuya on 13 Dec 12
       
      likewise with javadoc on things like default constructors /**  * Creates an instance of SomeClass  */ public SomeClass() {} is equally useless and unnecessarily clutters up the source code
‹ Previous 21 - 40 of 71 Next › Last »
Showing 20▼ items per page