Archive for January, 2009

A little science lesson for you!

January 23rd, 2009 makii Comments off

All hail the power of atom!!

A is for Atom from JP Sykes on Vimeo

via Jon Skyes.

Categories: Science, Technology, funny, video Tags:

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:

Not introduced at the MacWorld, but…

January 7th, 2009 makii Comments off

… funny nonetheless: This new “Apple” product is the ultimative No-Brainer:

Apple Introduces Revolutionary New Laptop With No Keyboard

"leaked" via

Categories: Mac, Technology, video Tags: