Skip to main content

Home/ SoftwareEngineering/ Group items tagged best practice

Rss Feed Group items tagged

kuni katsuya

Collaboration Best Practices - 3 Reasons Interruptions are Hurting Your Team's Producti... - 0 views

  • Interruptions Hurt Your Team’s Productivity
  • Productivity is futile in the face of constant interruptions
  • work is scattered through shared network drives, hard drives, and email
    • kuni katsuya
       
      or sharepoint, confluence, jira, word docs, pdf docs, spreadsheets, walled post-it notes, emails... not universally or easily searchable. arghhh...
  • ...17 more annotations...
  • Charging towards a common goal is difficult when:
  • center on meetings alone.
  • When disorganization and uncertainty is the norm, clarification and re-clarification is needed to regularly keep a team focused and working together
  •  waste A LOT of your time
  • Information isn’t located in a centralized place so it isn’t easily accessible to everyone.
  • It’s just easier to ask someone else because they are a Subject Matter Expert (SME). Both.
  • 2. Interruptions encourage multi-tasking, which is bad
  • 1. Most interruptions are trivial and could be avoided
  • it takes most people 16 minutes to refocus after sending an email while doing other work
    • kuni katsuya
       
      it takes most software engineers *at least* 20-30 minutes to get back into 'the zone' following an unrelated distraction
  • No wonder people like to work from home!
  • To perform at your productive best, you need your best focus, something that’s unachievable when you’re constantly interrupted
  • 3. Recovering from interruptions takes longer than you think
  • Between email, meetings, and interruptions (both active and passive),
  • there’s hardly time to get any work done while you’re actually at work.
  • Pro-Tip: Only turn on email and instant message when you need to use them
    • kuni katsuya
       
      ie. never?  ;) though then, you end up with 5,932 unread emails in your inbox and 113 angry co-workers!
  • To combat such interruption, check these tools 3 times a day – when you first get into the office in the morning, around lunch, and before going home for the night – and turn them off otherwise.
  • reduce the rate at which interruptions occur
kuni katsuya

Services, practices & tools that should exist in any software development house, part 2... - 0 views

kuni katsuya

Services, practices & tools that should exist in any software development house, part 1... - 1 views

  • Services, practices & tools that should exist in any software development house, part 1
  • Code repository/Versioning system
  • Issue & Bug Tracker
  • ...5 more annotations...
  • Corporate - central Wiki
  • Build Server (Continuous Integration)
  • Testing (tools and practices)
  • Code Coverage
  • Services, practices & tools that should exist in any software development house, part 1
kuni katsuya

Best Practices - 0 views

  • Best Practices
  • start with some of the obvious rulesets - just run unusedcode and fix any unused locals and fields. Then, run basic and fix all the empty if statements and such-like. Then peruse the design and controversial rulesets and use the ones you like via a custom ruleset
  • Using PMD within your IDE is much more enjoyable than flipping back and forth between an HTML report and your IDE
kuni katsuya

Lean service architectures with Java EE 6 - JavaWorld - 0 views

  • DAOs aren't dead, but they cannot be considered as a general best practice any more. They should be created in a bottom-up, rather than a top-down, fashion. If you discover data-access code duplication in your service layer, just factor it out to a dedicated DAO and reuse it. Otherwise it is just fine to delegate to an EntityManager from a service. The enforcement of an empty DAO layer is even more harmful, because it requires you to write dumb code for even simple use cases. The more code is produced, the more time you must spend to write tests and to maintain it.
  • With JDK 1.5 and the advent of generics, it is possible to build and deploy a generic, convenient, and typesafe DAO once and reuse it from variety of services
  •  
    DAOs aren't dead, but they cannot be considered as a general best practice any more. They should be created in a bottom-up, rather than a top-down, fashion. If you discover data-access code duplication in your service layer, just factor it out to a dedicated DAO and reuse it. Otherwise it is just fine to delegate to an EntityManager from a service. The enforcement of an empty DAO layer is even more harmful, because it requires you to write dumb code for even simple use cases. The more code is produced, the more time you must spend to write tests and to maintain it.
kuni katsuya

Jenkins Best Practices - Jenkins - Jenkins Wiki - 0 views

  • Archive unused jobs before removing them.
  • All unused jobs should be archived so they can be resurrected if the need arises
kuni katsuya

Temporary "junk" Packages Are A Best Practice : Adam Bien's Weblog - 0 views

  • Temporary "junk" Packages Are A Best Practice
  • In the first iterations class names and their packages are constantly refactored
  • a really bad sounding name like "waste", "junk" or "unrelated" does a better job by forcing you to refactor such a "kitchen sink" package with its contents in a later iteration
kuni katsuya

UML 2 Class Diagram Guidelines - 0 views

  • UML 2 Class Diagram Guidelines
  • 1.        General Guidelines
  • 2.        Class Style Guidelines
  • ...49 more annotations...
  • Use Common Terminology for Names
  • Prefer Complete Singular Nouns for Class Names
  • Name Operations with a Strong Verb
  • Name Attributes With a Domain-Based Noun
    • kuni katsuya
       
      don't just use the attribute's type with first character lower cased!!! argghhh!  (eg. instead of Node node, Node parent)
  • Do Not Model Scaffolding Code
  • Include an Ellipsis ( … ) At The End of Incomplete Lists
  • Develop Consistent Method Signatures
  • Avoid Stereotypes Implied By Language Naming Conventions
  • 3.        Interfaces
  • Name Interfaces According To Language Naming Conventions
    • kuni katsuya
       
      I+ is NOT an acceptable naming convention!  this is a very dumb, thoughtless, pointless convention originated by microsoft
    • kuni katsuya
  • Do Not Model the Operations and Attributes of an Interface in Your Classes
  • Consider an Interface to Be a Contract
  • 4.        Relationship Guidelines
  • Model Relationships Horizontally
  • Depict Similar Relationships Involving A Common Class As A Tree
  • Always Indicate the Multiplicity
  • reduce clutter in the diagram
  • Avoid a Multiplicity of “*”
  • Replace Relationships By Indicating Attribute Types
    • kuni katsuya
       
      if dependency relationships were drawn between every class and the types of it's attributes, the class diagram becomes cluttered very quickly this dependency is obvious if the type is indicated for each attribute
  • Do Not Model Every Single Dependency
    • kuni katsuya
       
      generalization of #7 what you show/don't show depends on the main concepts  you're trying to convey in any specific diagram
  • Write Concise Association Names In Active Voice
  • Indicate Directionality To Clarify An Association Name
  • Name Unidirectional Associations In The Same Direction
  • Indicate Role Names When Multiple Associations Between Two Classes Exist
  • Indicate Role Names on Recursive Associations
    • kuni katsuya
       
      eg. parent, child
  • Make Associations Bi-Directional Only When Collaboration Occurs In Both Directions
  • Question Multiplicities Involving Minimums And Maximums
    • kuni katsuya
       
      this just leads to stupid programming practices like hard-coding array sizes, making code more brittle
  • 6.        Inheritance Guidelines
  • “is a”
  • “is like” relationships
  • Apply the Sentence Rule For Inheritance
  • Place Subclasses Below Superclasses
  • A Subclass Should Inherit Everything
    • kuni katsuya
       
      if a subclass sets an attribute to null, implements a method returning null or throwing a NotImplementedException, it really isn't a subclass, or the superclass needs to be decomposed
  • 7.        Aggregation and Composition Guidelines
  • object is made up of other objects
  • aggregation
  • “is part of” relationships
  • whole-part relationship between two objects
  • Composition
  • stronger form of aggregation where the whole and parts have
  • coincident lifetimes, and it is very common for the whole to manage the lifecycle of its parts
  • Apply the Sentence Rule for Aggregation
  • Depict the Whole to the Left of the Part
  • Don’t Worry About Getting the Diamonds Right
  • associations, aggregation, composition, dependencies, inheritance, and realizations
  • line on a UML class diagram
  • defines a cohesive set of behaviors
  • Indicate Visibility Only On Design Models
  • Design Class Diagrams Should Reflect Language Naming Conventions
kuni katsuya

Access Tokens and Types - Facebook Developers - 0 views

  • Access Tokens and Types
  • Access Tokens
  • random string that provides temporary, secure access to Facebook APIs
  • ...27 more annotations...
  • token identifies a User, App or Page session and provides information about granted permissions
  • Types
  • User Access
  • generated in the login flow when a
  • Facebook Pages
  • on behalf of a user
  • use this token to perform API calls
  • Page Access
  • used to
  • manage
  • user grants permissions to an app
  • user who is the
  • App Secret or an App Access token should never be included in any code that could be accessed by anyone other than a developer of the app
  • must grant an extended permission called
  • manage_pages
  • use this type of token to make API calls
  • on behalf of a page
  • unique to each page, admin and app
  • App Access
  • useful to modify app settings, create and manage test users or read App Insights data
  • use app tokens to publish or delete content
  • on behalf of a user
  • unique to each app
  • Security Best Practices
  • extremely important that an App Secret is not compromised
  • Page admin
  • App Access Tokens should only be used directly from your app's servers in order to provide the best security
kuni katsuya

Equals and HashCode | Hibernate | JBoss Community - 0 views

  • best strategies for implementation of equals() and hashcode() in your persistent classes
  • The general contract is: if you want to store an object in a List, Map or a Set then it is an requirement that equals and hashCode are implemented so they obey the standard contract as specified in the  documentation
  • Why are equals() and hashcode() importantNormally, most Java objects provide a built-in equals() and hashCode() based on the object's identity; so each new() object will be different from all others.
  • ...8 more annotations...
  • Separating object id and business key
  • recommend using the "semi"-unique attributes of your persistent class to implement equals() (and hashCode()
  • The database identifier property should only be an object identifier, and basically should be used by Hibernate only
  • Instead of using the database identifier for the equality comparison, you should use a set of properties for equals() that identify your individual objects
  • "name" String and "created" Date, I can use both to implement a good equals() method
  • Workaround by forcing a save/flush
  • work around by forcing a save() / flush() after object creation and before insertion into the set
  • Note that it's highly inefficient and thus not recommended
kuni katsuya

Unquiet Code | Using Generics To Build Fluent API's In Java - 0 views

  • Using Generics To Build Fluent API's In Java
  • extends BaseClass
  • super(ChildClass.class)
  • ...19 more annotations...
  • accomplish the same idea using generics
  • creates a bad sort of dependency where we need to update the base class every time we make a new derived class. Not good!
  • superclass requests information about the child, and the child provides it
  • (CHILD)
  • <CHILD extends BakedGood<CHILD>>
  • CHILD
  • (CHILD)
  • CHILD
  • abstract
  • extends BakedGood<Cake>
  • The type parameter is saying “the Child class must extend Base<Child>”, forcing the Child class to provide its own type to the type system
  • Now that we can return the derived class in our chained method calls we are free to alternately call methods from the base class and the derived class
  • All of the normal polymorphic abilities are retained (you can see that we’ve implemented the abstract bake() method required by BakedGood)
  • .bake()
  • .bake()
  • practical applications of fluent API’s can be found
  • this one
  • best article I was able to find on the topic was
  • here and here
kuni katsuya

Welcome to PMD - 0 views

1 - 20 of 34 Next ›
Showing 20 items per page