Skip to main content

Home/ SoftwareEngineering/ Group items tagged international

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
kuni katsuya

Seam International Module - 0 views

docs.jboss.org/...html

Seam Seam3 I18N L10N international

shared by kuni katsuya on 04 Dec 12 - No Cached
  • 3. Locales
  • 3.2. User Locale
  • 4. Messages4.1. Message Creation4.2. Properties Files
kuni katsuya

EP1 - DMM - US9 - DMS application (shell) similar to ECM - Projects - Confluence - 0 views

confluence.visualfrenzy.com/...ion+%28shell%29+similar+to+ECM

work vfml FacebookCMS

shared by kuni katsuya on 09 Jan 13 - No Cached
  • full-screen
    • kuni katsuya
      kuni katsuya on 09 Jan 13
       
      why full screen?
    • kuni katsuya
      kuni katsuya on 09 Jan 13
       
      should at least consider displaying something sensible if either/both dimensions of browser window used is too small ideally, use responsive design approach to ux
  • path + "DMM_APPLICATION.html"
    • kuni katsuya
      kuni katsuya on 09 Jan 13
       
      need to establish sensible (ie. short, but meaningful) conventions used for externally facing urls
    • kuni katsuya
      kuni katsuya on 09 Jan 13
       
      also including my long-standing desire to keep internal things opaque to the outside world (eg. minimize exposure of directory structure, internal oids, host names, port numbers, etc)
kuni katsuya

Authorization | Apache Shiro - 0 views

shiro.apache.org/authorization.html

ApacheShiro authorization RBAC Role Permission Subject

shared by kuni katsuya on 31 Aug 12 - No Cached
  • PermissionResolver
  • use the PermissionResolver to convert the string into a Permission instance, and perform the check that way
  • All Shiro Realm implementations default to an internal
  • ...26 more annotations...
  • WildcardPermissionResolver
  • which assumes Shiro's
  • WildcardPermission
  • String format.
  • Authorization Sequence
  • what happens inside Shiro whenever an authorization call is made.
  • invokes any of the Subject hasRole*, checkRole*, isPermitted*, or checkPermission*
  • securityManager implements the org.apache.shiro.authz.Authorizer interface
  • delegates to the application's SecurityManager by calling the securityManager's nearly identical respective hasRole*, checkRole*, isPermitted*, or checkPermission* method variants
  • relays/delegates to its internal org.apache.shiro.authz.Authorizer instance by calling the authorizer's respective hasRole*, checkRole*, isPermitted*, or checkPermission* method
  • Realm's own respective hasRole*, checkRole*, isPermitted*, or checkPermission* method is called
  • Authorization Sequence
  • Authorization Sequence
  • Authorization Sequence
  • Implicit Roles:
    • kuni katsuya
      kuni katsuya on 23 Sep 12
       
      BAD! do not use. prefer explicit (see below)
  • implies a set of behaviors (i.e. permissions) based on a role name only
  • Excplict Roles
  • named collection of actual permission statements
  • your realm is what will tell Shiro whether or not roles or permissions exist
  • Each Realm interaction functions as follows:
  • key difference with a RolePermissionResolver however is that the input String is a role name, and not a permission string.
  • Configuring a global RolePermissionResolver
  • RolePermissionResolver has the ability to represent Permission instances needed by a Realm to perform permission checks.
  • translate a role name into a concrete set of Permission instances
  • globalRolePermissionResolver = com.foo.bar.authz.MyPermissionResolver ... securityManager.authorizer.rolePermissionResolver = $globalRolePermissionResolver
  • shiro.ini
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
kuni katsuya

Chapter 3. Project Setup - 0 views

www.graniteds.org/...graniteds.projectsetup.html

graniteds project configuration

shared by kuni katsuya on 08 Aug 12 - No Cached
  • The configuration of a GraniteDS project will generally involve the following steps : Add the GraniteDS jars to the WEB-INF/lib folder of the WAR file or the lib folder of the EAR file Add the GraniteDS listener, servlets and filters in the standard WEB-INF/web.xml configuration file Define the internal configuration of GraniteDS in the WEB-INF/granite/granite-config.xml file Define the application configuration of GraniteDS (remoting destinations, messaging topics...) in the WEB-INF/flex/services-config.xml
  • You will always need granite.jar
  • jar for your JPA provider (granite-hibernate.jar for Hibernate)
  • ...11 more annotations...
  • granite-beanvalidation.jar if you want to benefit from the integration with the Bean Validation API
  • configuration file declares 3 differents things
  • Channel endpoint
  • Service factories
  • Service/destinations
  • destinations using this factory will route incoming remote calls to EJB 3
  • endpoint
  • factory 
  • destination
  • channel 
  • factory
kuni katsuya

Architecture | Apache Shiro - 0 views

shiro.apache.org/architecture.html

apache shiro architecture

shared by kuni katsuya on 15 Aug 12 - No Cached
  • Realm is essentially a security-specific DAO
  • 3 primary concepts:
  • Subject
  • ...51 more annotations...
  • SecurityManager
  • Realms
  • High-Level Overview
  • Subject
  • essentially a security specific 'view' of the the currently executing user
  • Subject
  • instances are all bound to (and require) a
  • SecurityManager
  • When you interact with a Subject, those interactions translate to subject-specific interactions with the SecurityManager
  • SecurityManager
  • 'umbrella’ object that coordinates its internal security components that together form an object graph
  • Realms
  • ‘connector’ between Shiro and your
  • application’s security data
  • Shiro looks up many of these things from one or more Realms configured for an application
  • Subject
  • SecurityManager
  • Authenticator
  • Authorizer
  • component responsible determining users' access control in the application
  • if a user is allowed to do something or not
  • SessionManager
  • knows how to create and manage user
  • Session
  • lifecycles
  • Shiro has the ability to natively manage user Sessions in any environment, even if there is no Web/Servlet or EJB container available
  • Shiro will use
  • an existing session mechanism
  • if available, (e.g. Servlet Container)
  • if there isn't one, such as in a standalone application or non-web environment, it will use its
  • built-in enterprise session management
  • SessionDAO
  • exists to allow any datasource to be used to
  • persist sessions
  • SessionDAO
  • performs Session persistence (CRUD) operations on behalf of the SessionManager
  • allows any data store to be plugged in to the Session Management infrastructure
  • CacheManager
  • creates and manages Cache instance lifecycles used by other Shiro components
  • improve performance while using these data source
  • Cryptography
  • Realms
  • ‘connector’ between Shiro and your application’s security data
  • Realms
  • Realms
  • Realms
  • ‘connector’ between Shiro and your application’s security data
  • ‘connector’ between Shiro and your application’s security data
  • ‘connector’ between Shiro and your application’s security data
  • ‘connector’ between Shiro and your application’s security data
  • ‘connector’ between Shiro and your application’s security data
kuni katsuya

ListCollectionView/ArrayCollection tip for using GraniteDS - Ross Henderson - 0 views

blog.rosshenderson.info/...ection-tip-for-using-graniteds

graniteds tip ListCollectionView ArrayCollection

shared by kuni katsuya on 06 Jun 12 - No Cached
  • The reason why GraniteDS generates properties of type ListCollectionView is simple : it internally uses collections implementations that extend ListCollectionView and not ArrayCollection. But as you have described when you manually assign collections, you should use ArrayCollection. It’s exactly the same as in Java when you do List list = new ArrayList().
  • ListCollectionView/ArrayCollection tip for using GraniteDS
  • new ListCollectionView();
  • ...4 more annotations...
  • instead of this:
  • do this:
  • new ArrayCollection();
  • I’m not really sure what the deal is
    • kuni katsuya
      kuni katsuya on 01 Nov 12
       
      see comment from william (wdrai) below (graniteds guy)
1 - 8 of 8
Showing 20▼ items per page