Skip to main content

Home/ SoftwareEngineering/ Group items tagged features

Rss Feed Group items tagged

kuni katsuya

Preemptive commit comments | Arialdo Martini - 0 views

  • Tell me what the software does
    • kuni katsuya
       
      tell me how the software should *behave*, not how the behavior was *implemented* ie. describe the changes in this commit from the behavioral perspective rather than implementation details
  • What is the project behavior, in this snapshot?
  • What did the programmers, in order to produce this snapshot?
  • ...43 more annotations...
  • committing comments describing the
  • behavior of the software,
  • rather than the
  • implementation or a description of what we did
  • commits’ comments started to look like BDD’s methods name: a description of a behavior.
  • principles
  • Talk about the feature, not about yourself
  • Don’t refer to the past
  • I know it’s now
  • list of benefits
  • More focus while developing
  • Commit review is much easier
  • Less cognitive load
  • You learn commenting much more precisely
  • commit comment becomes a
  • declaration of intent
  • like a BDD method name
  • No more “Just a fix“, “Improvements” or “I made this, this, this and also this” comments.
    • kuni katsuya
       
      BDD/TDD or any methodology aside, these are the worst commit comments as they are as useless as empty commit comments
  • Each preemptive comment triggers a micro design session
  • A preemptive comment sets a micro goal
    • kuni katsuya
       
      which also aligns well with the 'micro goal' or incremental deliverables approaches of most agile methodologies 
  • helps to focus a goal to be reached
  • Without preemptive comments, I often went on coding, always asking myself: “Should I commit now? Have I reached a stable state which I could consider a good commit?“
  • define micro-goals through preemptive comments
  • macro-goal through the feature branch name
  • A preemptive comment creates a little timebox
    • kuni katsuya
       
      similar to the timeboxing strategy of a short sprints, for instance
  • Writing comments preemptively puts the agreement between the pair members to a test
    • kuni katsuya
       
      more relevant to methodologies using pair programming
  • commit history gains a very balanced granularity
  • feature branch becomes a collection of evolutionary commits each of which has usually a 1:1 binding with tests
  • very easy to find which commit introduced a bug, since each commit is related to a single new goal/feature
  • Preemptive commit comments
  • Rule #2: write what the software
  • I started taking a lot of care of the words I was using in comments, commits, test names and classes/variables/methods’ names
  • be supposed to do,
  • not what you did
  • should
  • Introducing BDD
  • began with the simple attempt to replace the world
  • “should“
  • “test”
  • with the world
  • Rule #1: write commit comments before coding
  • use the same criteria for my commits’ comments as well.
  • (not what you did)
kuni katsuya

Niklas' Blog: CDI 1.0 vs. Spring 3.1 feature comparsion: bean definition & dependency i... - 0 views

  • CDI 1.0 vs. Spring 3.1 feature comparsion: bean definition & dependency injection
  • Spring offers three different approaches to do dependency injection: XML-based, annotation-based and pure Java-based (programmatic)
  • CDI on the other hand is strictly annotation-based
  • ...2 more annotations...
  • pure feature oriented-perspective
  • only little critical difference in the two technologies
kuni katsuya

Feature Visibility [Enterprise Architect User Guide] - 0 views

  • enables you to set the visibility of attributes and operations
  • hide or show attributes and operations
  • visibility you set applies only to the current diagram, so a Class can appear in one diagram with all features displayed, and in another with features hidden
kuni katsuya

UML Class Diagrams - structure diagrams which show architecture of the designed system ... - 0 views

  • «Boundary»
  • Boundary is a stereotyped class or object that represents some system boundary
  • «Control»
  • ...31 more annotations...
  • Control is a stereotyped class or object that is used to model flow of control or some coordination in behavior
  • usually describe some "business logic"
  • «Entity»
  • Entity is a stereotyped class or object that represents some information or data, usually but not necessarily persistent.
  • Features of a class are
  • attributes
  • operations
  • Static features are underlined
  • «Boundary»
  • «Boundary»
  • «Control»
  • «Entity»
  • «Control»
  • Interface
  • An interface is a classifier that declares of a set of coherent public features and obligations
  • specifies a contract.
  • Data Type
  • A data type is a classifier - similar to a class - whose instances are
  • identified only by their value
  • typical use of data types would be to represent value types
  • «dataType»
  • Enumeration
  • An enumeration is a data type whose values are enumerated in the model as user-defined enumeration literals.
  • «enumeration».
  • Multiplicity
  • Multiplicity allows to specify cardinality (allowed number of instances) of described element
  • Visibility
  • UML has the following types of visibility: public package protected private
  • Package visibility is represented by '~' literal.
  • Protected visibility is represented by '#' literal.
  • Private visibility is represented by '-' literal.
kuni katsuya

Web Features | Apache Shiro - 0 views

  • Apache Shiro Web Features
kuni katsuya

Cryptography Features | Apache Shiro - 0 views

  • Hash Features
  • Deault interface implementations - Shiro provides default Hash (aka Message Digests in the JDK) implementations out-of-the-box, such as MD5, SHA1, SHA-256
  • Built-in Hex and Base64 conversion - Shiro Hash instances can automatically provide Hex and Base-64 encoding of hashed data via their toHex() and toBase64() methods
  • ...1 more annotation...
  • Built-in Salt and repeated hashing support
kuni katsuya

FreeMarker: Java Template Engine Library - Features - 0 views

  • highlights of FreeMarker features
  • Lightweight
  • Powerful template language
kuni katsuya

Pro JPA 2: Mastering the Java™ Persistence API > Advanced Topics > SQL Querie... - 0 views

  • queries are also known as native queries
  • SQL Queries
  • reasons why a developer using JP QL might want to integrate SQL queries into their application
  • ...32 more annotations...
  • JPA 2.0, still contains only a subset of the features supported by many database vendors
  • features not supported in JP QL.
  • performance required by an application is to replace the JP QL query with a hand-optimized SQL version. This may be a simple restructuring of the query that the persistence provider was generating, or it may be a vendor-specific version that leverages query hints and features specific to a particular database.
  • recommend avoiding SQL initially if possible and then introducing it only when necessary
  • benefits of SQL query support is that it uses the same Query interface used for JP QL queries. With some small exceptions that will be described later, all the Query interface operations discussed in previous chapters apply equally to both JP QL and SQL queries.
  • keep application code consistent because it needs to concern itself only with the EntityManager and Query interfaces.
  • An unfortunate result of adding the TypedQuery interface in JPA 2.0 is that the createNativeQuery() method was already defined in JPA 1.0 to accept a SQL string and a result class and return an untyped Query interface
  • consequence is that when the createNativeQuery() method is called with a result class argument one might mistakenly think it will produce a TypedQuery, like createQuery() and createNamedQuery() do when a result class is passed in.
  • @NamedNativeQuery
  • resultClass=Employee.class
  • The fact that the named query was defined using SQL instead of JP QL is not important to the caller
  • SQL Result Set Mapping
  • JPA provides SQL result set mappings to handle these scenarios
  • A SQL result set mapping is defined using the @SqlResultSetMapping annotation. It may be placed on an entity class and consists of a name (unique within the persistence unit) and one or more entity and column mappings.
  • entities=@EntityResult(entityClass=Employee.class)
  • @SqlResultSetMapping
  • Multiple Result Mappings
  • A query may return more than one entity at a time
  • The SQL result set mapping to return both the Employee and Address entities out of this query
  • emp_id, name, salary, manager_id, dept_id
  • address_id, id, street, city, state, zip
  • order in which the entities are listed is not important
  • ntities={@EntityResult(entityClass=Employee.class), @EntityResult(entityClass=Address.class)}
  • expected result type and therefore received an instance of TypedQuery that is bound to the expected type. By qualifying the result type in this way, the getResultList() and getSingleResult() methods return the correct types without the need for casting.
  • Defining a Class for Use in a Constructor Expression
  • public EmpMenu(String employeeName, String departmentName)
  • List<EmpMenu>
  • NEW example.EmpMenu(" + "e.name, e.department.name)
  • EmpMenu.class
  • createNamedQuery() can return a TypedQuery whereas the createNativeQuery() method returns an untyped Query
  • List<Employee>
  • createNamedQuery("orgStructureReportingTo", Employee.class)
kuni katsuya

Spring Security - Features - 0 views

  • Domain object instance security: In many applications it's desirable to define Access Control Lists (ACLs) for individual domain object instances. We provide a comprehensive ACL package with features including integer bit masking, permission inheritance (including blocking), an optimized JDBC-backed ACL repository, caching and a pluggable, interface-driven design.
  • OpenID Support: the web's emerging single sign-on standard (supported by Google, IBM, Sun, Yahoo and others) is also supported in Spring Security
  • Easy integration with existing databases: Our implementations have been designed to make it easy to use your existing authentication schema and data (without modification). Of course, you can also provide your own Data Access Object if you wish. Password encoding: Of course, passwords in your authentication repository need not be in plain text. We support both SHA and MD5 encoding, and also pluggable "salt" providers to maximise password security.
  • ...5 more annotations...
  • Caching: Spring Security optionally integrates with Spring's Ehcache factory. This flexibility means your database (or other authentication repository) is not repeatedly queried for authentication information when using Spring Security with stateless applications.
  • Run-as replacement: The system fully supports temporarily replacing the authenticated principal for the duration of the web request or bean invocation. This enables you to build public-facing object tiers with different security configurations than your backend objects.
  • Tag library support: Your JSP files can use our taglib to ensure that protected content like links and messages are only displayed to users holding the appropriate granted authorities. The taglib also fully integrates with Spring Security's ACL services, and obtaining extra information about the logged-in principal.
  • User Provisioning APIs: Support for groups, hierarchical roles and a user management API, which all combine to reduce development time and significantly improve system administration.
  • Enterprise-wide single sign on using CAS 3: Spring Security integrates with JA-SIG's open source Central Authentication Service (CAS)
kuni katsuya

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

  • 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
       
      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
       
      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
       
      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
       
      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
       
      DO NOT DO THIS this is just bad design
  • "null returns xxx"
    • kuni katsuya
       
      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
       
      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 2. Usage Scenarios - 0 views

  • Client Options
  • client there are two main choices
  • standard Flex RemoteObject API
  • ...16 more annotations...
  • GraniteDS does not support the standard Consumer and Producer Flex messaging API
  • its own client implementations of these classes org.granite.gravity.Consumer and org.granite.gravity.Producer that provide very similar functionality
  • Tide remoting API with the GraniteDS/Tide server framework integration
  • most advanced features and greatly simplifies asynchronous handling and client data management
  • preferred for new projects
  • Server Options
  • two options
  • GraniteDS service factory
  • RemoteObject API,
  • GraniteDS support for externalization of lazily loaded JPA entities/collections, and support for scalable messaging though Gravity
  • GraniteDS/Tide service factory
  • Tide API
  • full feature set of Tide data management and further integration with data push through Gravity
  • complete support for Spring and Seam security or integration with CDI events
  • Tide/CDI/JPA2/Java EE 6 on JBoss 6/7 or GlassFish 3
  • If you are on a Java EE 6 compliant application server, it is definitely the best option
kuni katsuya

WebORB for Java Overview - 0 views

  • WebORB for Java
  • Solid Alternative to Adobe LCDS and BlazeDS
  • drop-in replacement for Adobe Live Cycle Data Services (LCDS) and BlazeDS
  • ...5 more annotations...
  • free and more feature rich alternative to BlazeDS, but also outranks LCDS’ out-of-the-box features when it comes to data management, streaming media and integrating with mobile devices and Cloud computing
  • developer tools like code generation, invocation test drive and interoperability with multiple IDEs and frameworks
  • supporting integration with mobile clients (Android, Windows Phone 7, RIM Playbook and soon iOS) and the Java service layer, which includes support for Java POJOs, EJBs, Spring Beans, Grails controllers, Hibernate Objects and XML Web Services
  • WebORB for Java
  • WebORB for Java
kuni katsuya

In Relation To...  Bean Validation for Flex developers - 0 views

  • Bean Validation for Flex developers
  • GraniteDS have added support for Bean Validation into their project and hence Bean Validation is usable by all Flex users
  • Because they do not run on the JVM, they basically have reimplemented the full specification in Flex: you can annotate your ActionScript3 objects with constraints: it supports all the standard constraints and you can write your own constraints you can execute the validation logic and retrieve the error report you can make use of most of the feature including advanced ones like groups, group sequence etc
  • ...3 more annotations...
  • for GraniteDS users keeping their Java domain model and ActionScript3 domain model in sync via Gas3, the constraints are kept in sync
  • a couple of gotchas to be aware of
  • the constraint implementation is in the same class as the constraint declaration (not a problem in a dynamic language) @Pattern has a sightly different semantic because the regexp engine in Flex is a bit different. instead of the features provided by ConstraintValidatorContext, you can define a properties attribute in your constraints to make it belong to several sub-properties. not as flexible but good enough in many cases.
1 - 20 of 54 Next › Last »
Showing 20 items per page