Archive for the ‘Coding’ Category

For the sake of architecture…

January 21st, 2009 derlanders Comments off
  • If it is simple, expand the problem by adding additional concerns. Justify this by future extensibility and maintainability. Incite and nurture confusion about what may only look simple but is likely to turn out complex later. Later, argue against it by pointing out that the additional complexity never came and no one knows which code is used at all.
  • If it is complex (or likely to become complex after the prototype phase), analyze half of the complexity and implement one half of that. Justify with completion time and pragmatism. Later, argue against because maintainability requires pain suppressors and protective eyewear.
  • If it has many features, have modularization by layers only. Justify with build and deploy overhead. Later, argue against the efforts going into a complex build system that was never needed because the layers are always built and deployed together anyway and no different usages, development cycles or versions exist.
  • If it has many layers, modularize by features only. Justify with agile deployment. Later argue against feature-based modularization in general because shared components have to be versioned and/or redeveloped so often.
  • If both of the above apply, use arbitrary names and have cycling dependencies between layers *and* between features. Justify by saying that you will build the whole lump in one piece anyway. Justify with easy deploy. Later, argue against modularization in general because with all those cyclic dependencies refactoring would take ages.
  • Never modularize by abstraction tier. You don’t need to justify that, nearly everyone will be with you, here, because concrete and explicit is always better than abstract and configurable. You could argue against it when having base components for more than one application. But usually this is not a problem and you will be expected to develop everything again for the second app anyway.
  • If something is expected to be used at exactly one place, have 4 or 7 classes describing its exact lifecycle. Use unary vertical inheritance or delegate to a stack of static utilities that do it. Justify with reuse. Later, argue against OO because it makes your code less understandable.
  • If something is used everywhere in different contexts, have it copied, pasted, developed anew each time or at least made static to avoid dependency inversion. Justify with redundancy and damage control. If someone tries to convince, trick or force you into abstract services that use parameter containers or commands, at least have concrete methods to keep it from sinking down the dependency tree. Produce static utilities that carry the name of the desired pattern (e.g. Service, Command etc.) so you can say you did it enterprisey.
  • If something is the same all the time, have it configure itself by a proprietary configuration file format in a virtual, internet based filesystem on a remote grid. Justify with configurability. Argue against by pointing at the myriad of undocumented config files.
  • If something is likely to change or be used in a different context, put up a couple of assumptions for the least probable case and hardcode these in a static and final fashion. Have all public methods finalized and all internal methods private. Justify with safety. Later, write a wrapper around them that fuses some concrete components into one, even more concrete component.
  • If you are working platform-independent, try to have as many dependencies to certain environmental settings as possible. Use the OS to configure your application if you can’t do it in hardware. Hidden OS particularities like new File(“C:\\”) can help. Later, argue against platform independent code because it is slow. Then use another platform-independent system.
  • If you lose control of your low level implementation, wrap it into a slightly changed interface on the same abstraction level and lose control of that as well. Then delegate that to a static utility with the same “interface”.
  • Try to have interfaces as concrete as possible. Use @implementedBy if you can. Have all possible usecases of a topic defined in one interface. Justify with comprehensibility. Later, argue against interfaces. They are emballage, bulky, stop your code from compiling and do not do anything.
  • If you really must have terms like module, service, application, scope, mandate, deletion, replication, staging or plugin in your application, try to introduce them into your code as late as possible. Justify with development speed. Have the “new” thing be parallel and concurring to the “old” thing. Spread among these strategies evenly.
  • Have as many things as possible require specific knowledge. If you have the choice between writing automation or writing documentation, choose email or your local hard drive.
  • If something is retrieved dynamically, have a static and final reference to it. Justify with coding convenience. Argue against dynamic retrieval with runtime/network restraints when high availability does not work and strange Errors show up. Recommend a different technology.
  • If something is static and final, have it initialized by a timer thread, a second application or by special parameter values in regular calls.
  • Use reflection for public business methods, within the same layer and abstraction level and especially for initialization. Have everyone hate you for it. While reflecting, do not annotat. Use concatenated naming conventions instead.
  • Ban reflection for lookups and configuration in abstract components and code that handles application components. These calls should always be explicit and concrete, with business names and long, scalar parameter lists at best.
  • Use fields for temporary calculation results and then transfer these into static methods by either a long parameter list or a proprietary backpack pattern. Make the method synchronized if strange things occur. Use delays if they continue to occur.

Categories: Coding, Technology Tags:

The way

December 16th, 2008 makii Comments off

I just found some interesting slides from the AJAX in Action conference. IMO this is where we need to go:

There are more interesting slides on these topics here at

Categories: Coding, Technology, Web, Work Tags:

Branching and Merging

October 22nd, 2008 bleiente Comments off

Everybody is talking about subversion (svn), branches, and merging these days, so I collected some resources from the net.

  • There is the online version of the book Version Control with Subversion which covers the basics and advanced stuff as well as all svn commands in detail.
  • The German site accompanies the print edition and also hosts a discussion forum.
  • If you’re looking for further links to clients, articles, etc. try the Javapedia.

And here are some interesting recent blog entries which focus on the art of branching and merging:

We’ll have a discussion round on this topic soon, so let’s see what we will come up with…

parallelization + array = ParallelArray

October 17th, 2008 AVC Comments off

The idea is that a ParallelArray represents a collection of structurally similar data items, and you use the methods on ParallelArray to create a description of how you want to slice and dice the data. You then use the description to actually execute the array operations, which uses the fork-join framework under the hood, in parallel…This idea coming in JDK 7 :)

In fact, here are some operations supported by ParallelArray:

  • Filtering: selecting a subset of the elements
  • Mapping: convert selected elements to another form
  • Replacement: create a new ParallelArray derived from the original
  • Aggregation: combine all values into a single value
  • Application: perform an action for each selected element

- avc

Categories: 16ms, Coding, Common, Java, Technology Tags:

Too lazy to architecturize your projects?

October 17th, 2008 derlanders 2 comments

Here is the solution:


The best Java Exception ever

October 10th, 2008 makii Comments off

A lot of thanks to Code To Joy for the best Java Exception I ever saw: JavaDoc of CME

Categories: Coding, Java, funny Tags:

String literals

June 2nd, 2008 makii Comments off

When coding in Java, I usually try to avoid string literals in the code, especiall when they reference other software components like templates, which are filled with values in arbitrary places throughout the code. This is what I found in a project which we’re going to insource soon:

#-[ user@host ]- ~/work/project/trunk
#-[0]-> find . -type f -name "*.java" -exec grep -r "\"salutation2\"" {} \; | wc -l
#-[ host@host ]- ~/work/project/trunk

No comment.

Categories: Coding, Java Tags: ,