Skip to main content

Home/ Groups/ SoftwareEngineering
kuni katsuya

Chapter 2. Mapping Entities - 0 views

  • Composite identifier
  • You can define a composite primary key through several syntaxes:
  • @EmbeddedId
  • ...66 more annotations...
  • map multiple properties as @Id properties
  • annotated the property as
  • map multiple properties as @Id properties and declare an external class to be the identifier type
  • declared on the entity via the @IdClass annotation
  • The identifier type must contain the same properties as the identifier properties of the entity: each property name must be the same, its type must be the same as well if the entity property is of a
  • basic type
  • last case is far from obvious
  • recommend you not to use it (for simplicity sake)
  • @EmbeddedId property
  • @EmbeddedId
  • @Embeddable
  • @EmbeddedId
  • @Embeddable
  • @Embeddable
  • @EmbeddedId
  • Multiple @Id properties
  • arguably more natural, approach
  • place @Id on multiple properties of my entity
  • only supported by Hibernate
  • does not require an extra embeddable component.
  • @IdClass
  • @IdClass on an entity points to the class (component) representing the identifier of the class
  • WarningThis approach is inherited from the EJB 2 days and we recommend against its use. But, after all it's your application and Hibernate supports it.
  • Mapping entity associations/relationships
  • One-to-one
  • three cases for one-to-one associations:
  • associated entities share the same primary keys values
  • foreign key is held by one of the entities (note that this FK column in the database should be constrained unique to simulate one-to-one multiplicity)
  • association table is used to store the link between the 2 entities (a unique constraint has to be defined on each fk to ensure the one to one multiplicity)
  • @PrimaryKeyJoinColumn
  • shared primary keys:
  • explicit foreign key column:
  • @JoinColumn(name="passport_fk")
  • foreign key column named passport_fk in the Customer table
  • may be bidirectional
  • owner is responsible for the association column(s) update
  • In a bidirectional relationship, one of the sides (and only one) has to be the owner
  • To declare a side as
  • not responsible for the relationship
  • the attribute
  • mappedBy
  • is used
  • mappedBy
  •  Indexed collections (List, Map)
  • Lists can be mapped in two different ways:
  • as ordered lists
  • as indexed lists
  • @OrderBy("number")
  • List<Order>
  • List<Order>
  • List<Order> 
  • To use one of the target entity property as a key of the map, use
  • @MapKey(name="myProperty")
  •  @MapKey(name"number")
  • Map<String,Order>
  • String number
    • kuni katsuya
       
      map key used in Customer.orders
  • @MapKeyJoinColumn/@MapKeyJoinColumns
  • if the map key type is another entity
  • @ManyToAny
  • 2.4.5.2. @Any
  • @Any annotation defines a polymorphic association to classes from multiple tables
  • this is most certainly not meant as the usual way of mapping (polymorphic) associations.
  • @ManyToAny allows polymorphic associations to classes from multiple tables
  • first column holds the type of the associated entity
  • remaining columns hold the identifier
  • not meant as the usual way of mapping (polymorphic) associations
kuni katsuya

Dell UltraSharp U2713HM 27-inch Widescreen Flat Panel Monitor with LED : Monitors: Flat... - 0 views

kuni katsuya

NetBeans FAQ - IntelliJ-Wiki - 0 views

  • NetBeans FAQ
    • kuni katsuya
       
      intellij for netbeans users faq
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

Graph database - Wikipedia, the free encyclopedia - 0 views

  • are pertinent information that relate to nodes
    • kuni katsuya
       
      ie. attributes of the entities (aka nodes)
  • Edges
  • are the lines that connect
  • ...6 more annotations...
  • nodes to nodes
  • nodes to properties
  • they represent the relationship between the two
  • Most of the important information is really stored in the edges
  • depend less on a rigid schema, they are more suitable to manage ad-hoc and changing data with evolving schemas
  • Conversely, relational databases are typically faster at performing the same operation on large numbers of data elements
kuni katsuya

The 4 Most Important Skills for a Software Developer | Javalobby - 0 views

  • The 4 Most Important Skills for a Software Developer
  • Skill 1: Solving Problems
  • It is amazing how bad most developers are at solving problems.
  • ...17 more annotations...
  • problem solving is the base skill of software development.
  • Skill 2: Teaching Yourself
  • There is probably no more important skill in life than learning to learn.
  • especially important in software development, because no field I know of changes more rapidly than software development.
  • need the ability to quickly acquire the knowledge you need for the task at hand.
  • learn how to teach yourself
  • Skill 3: Naming
  • Software development is all about describing the metaphysical
  • Every time you are writing code you are naming things
  • can accurately predict a developer’s skill level by looking at how they have named methods, variables and classes in code they have written
  • A developer who lacks the ability to give good names to concepts and data in their code is like a mute translator
  • focus on giving good names to things
  • most visible thing about your code
  • if I read it and can understand it, I am going to assume you know what you are doing.
  • Skill 4: Dealing with People
  • humans are not logical creatures
  • we are emotional ones
kuni katsuya

Top 10 Lessons Learned From 10 Years in Agile | Agile Zone - 0 views

  • Top 10 Lessons Learned From 10 Years in Agile
  • 1.  Simplicity is Sophistication.  
  • 2.  Define your Rhythm.  
  • ...18 more annotations...
  • start cutting down on wasted meeting time
  • 3. Agile is Fundamentally About Discipline.  
  • areas of planning, unit testing, test driven development, continuous integration, and test automation.
  • 4.  Software is Hard to Scale, Agile is Not.  
  • Focus on business goals
  • 5.  Think of the Big Picture.   
  • success requires a
  • consideration of the system as a whole
  • before making changes to its parts, or else the change will likely be fraught with risk.
  • 6.  Lose the Religion  
  • adapt agile to your need.
  • 7. Continuous Focus on Business Value.
  • get caught in the weeds of a technical story's delivery and velocity at the expense of overall business value, company and project goals
  • 8. Agile - It's Not Just For Software Anymore.
  • 9. Continuous Planning. 
  • Plan on a daily basis if possible
  • Keep your focus on maximizing value
  • 10.  Doing agile and being agile aren’t the same.
kuni katsuya

Changing Bits: Lucene's FuzzyQuery is 100 times faster in 4.0 - 0 views

  • Lucene's FuzzyQuery is 100 times faster in 4.0
  • FuzzyQuery matches terms "close" to a specified base term
  • specify an allowed maximum edit distance, and any terms within that edit distance from the base term
  • ...3 more annotations...
  • FuzzyQuery is great for matching proper names
  • Prior to 4.0, FuzzyQuery took the simple yet horribly costly brute force approach: it visits every single unique term in the index, computes the edit distance for it, and accepts the term (and its documents) if the edit distance is low enough.
  • Levenshtein
kuni katsuya

Listing Directory Contents with JDK 1.7 and NIO.2 : Adam Bien's Weblog - 0 views

kuni katsuya

Lazy Loading Entities In Views Challenge--Reader's Question And Answer : Adam Bien's We... - 0 views

  • Lazy Loading Entities In Views
  • class User
  • Address
  • ...10 more annotations...
  • Friend
  • addresses are lazily loaded
  • detached mode already in the controller
  • eagerly loaded
  • It gets ugly pretty quickly
  • JXPath relations
  • Use Fetch Joins they are designed to prefetch lazy relations
  • Anti-Pattern
    • kuni katsuya
       
      DO NOT USE THE OPEN-SESSION-IN-VIEW *ANTI*-PATTERN
  • Use Stateful Session Beans
    • kuni katsuya
       
      do not penalty: death, or at least a public flogging
  • eager load the relations
    • kuni katsuya
       
      just don't hard-code this eager loading behavior by using jpa's FetchType.EAGER when annotating the entity beans if you do, you force all clients of said entity beans to *always* eager fetch everything, even if the client doesn't want/need the full depth/breadth of the object graph to eager load the relations when needed, try fetch joins (see item 5)
kuni katsuya

Open Session in View | Hibernate | JBoss Community - 0 views

  • Open Session in View
    • kuni katsuya
       
      do not do this!  this be an anti-pattern
kuni katsuya

AnemicDomainModel - 0 views

  • AnemicDomainModel
  • Eric Evans
  • basic symptom of an Anemic Domain Model
  • ...40 more annotations...
  • The catch comes when you look at the
  • behavior
  • there is hardly any behavior on these objects, making them little more than bags of getters and setters
  • I was chatting with
    • kuni katsuya
       
      note, the 'i' here, is mr. MARTIN FOWLER!! and of course, eric evans hails from domain driven design fame
  • fundamental horror
  • it's so contrary to the basic idea of object-oriented design
  • combine
  • data and process together
  • procedural style design
  • completely miss the point of what object-oriented design is all about
  • It's also worth emphasizing that putting behavior into the domain objects
  • should not contradict the solid approach of using layering to separate domain logic from such things as persistence and presentation responsibilities
  • logic that should be in a domain object is domain logic
  • validations
  • calculations
  • business rules
  • One source of confusion in all this is that many OO experts do recommend putting a layer of procedural services on top of a domain model, to form a Service Layer
  • this isn't an argument to make the domain model
  • void of behavior
  • service layer advocates use a service layer in conjunction with a behaviorally rich domain model.
  • does not contain business rules or knowledge, but
  • only coordinates
  • tasks and delegates work to
  • collaborations of domain objects
  • in the next layer down
  • can have state that reflects the
  • progress of a task
  • for the user or the program
  • Domain Layer
  • Application Layer
  • Service Layer
  • Responsible for
  • representing concepts of the business
  • business rules
  • This layer is the heart of business software
    • kuni katsuya
       
      ... and has the *most value* to an organization investing in writing their own software infrastructure software (eg. user interface, orm, application server-related frameworks) or plumbing code should be treated as commodities where possible, unless, the business consciously decides that a custom, home-grown implementation is absolutely required for patenting or other differentiation reasons and/or that no existing off-the-shelf solution can be used but these cases should be rare! do not blindly fall for the not-invented-here syndrome
  • all the key logic lies in the domain layer
  • I don't know why this anti-pattern is so common
  • if they come from a
  • data background
    • kuni katsuya
       
      this is why during every sprint, i reiterate that the data model up approach to designing the system is OH SO WRONG but nobody listens
  • J2EE's Entity Beans
    • kuni katsuya
       
      damn baggage from  eons ago!!!
kuni katsuya

Anemic domain model - Wikipedia, the free encyclopedia - 0 views

  • objects containing only data
    • kuni katsuya
       
      ie. dumb data structures with little or no behavior
  • objects containing only code
    • kuni katsuya
       
      ie. classes that are just containers for methods that implement the behavior part of the domain objects (aka the procedures)
  • Martin Fowler, who considers the practice an anti-pattern
  • ...14 more annotations...
  • Benefit
    • kuni katsuya
       
      none
  • Liabilities
    • kuni katsuya
       
      lots
  • Logic cannot be implemented in a truly object-oriented way
    • kuni katsuya
       
      for example, polymorphic behavior
    • kuni katsuya
       
      dammit, can't change highlight color if there's also a sticky note attached!!! arrgggghhhh!!! diigo plugin bug!!
  • Violation of the encapsulation
  • domain model's objects cannot guarantee their correctness
  • validation and mutation logic is placed somewhere outside
    • kuni katsuya
       
      instead of, say, attaching validation 'behavior' directly on, but still decoupled from domain classes themselves (eg. validation rule annotations on jpa entity beans)
    • kuni katsuya
       
      dammit, can't change highlight color if there's also a sticky note attached!!! arrgggghhhh!!! diigo plugin bug!!
  • Necessitates a service layer when sharing domain logic across differing consumers of an object model.
  • Makes a model less expressive and harder to understand.
  • Facilitates code duplication among transactional scripts and similar use cases, reduces code reuse.
  • Liabilities
  • Liabilities
  • Liabilities
  • Liabilities
  • Liabilities
kuni katsuya

How To Configure Java EE 6+ Applications ...Without XML : Adam Bien's Weblog - 0 views

  • How To Configure Java EE 6+ Applications ...Without XML
  • with @Inject:
  • See also page 98 "Configuration Over Convention with Inversion of Control" in Real World Java EE Night Hacks--Dissecting the Business Tier.]
kuni katsuya

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

  • 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
       
      evidence of the anti-pattern of procedural design in a java ee6 cdi application
  • previous way is more procedural
    • kuni katsuya
       
      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
       
      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
       
      ... if you just blindly follow the anti-pattern, of course  ;)
  • many benefits
    • kuni katsuya
       
      with the procedural approach, you also cannot implement polymorphic behavior, for instance
  • builder
  • fluent interface
  • it’s not for small projects
    • kuni katsuya
       
      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
       
      not sure i agree with these points, but will refuse in a later sticky note
kuni katsuya

TH03-EP01-US001 - Media Management, Media Upload, Media Item Fields (Groomed BE21, FE8)... - 0 views

  • Associated with
    • kuni katsuya
       
      ?
  • viewed by users
    • kuni katsuya
       
      and available to all legacy content distribution services (eg. oms, viewers, vscape, etc)
« First ‹ Previous 281 - 300 of 1272 Next › Last »
Showing 20 items per page