After arriving back in Germany from the O’Reilly Android Open Conference in San Francisco, I want to summarize my conclusions and general impressions.
Being in San Francisco and attending the conference was very inspiring. The keynotes have given a great overview what is possibly coming in the future and having Tim O’Reilly speaking about leveraging the openness of the Android platform was very motivating. As well as seeing what people are doing with standard hardware, like the NASA with Nexus S based mini satellites is crazy.
What was also great, was to „feel“ what makes the bay area so special in terms of innovations: ways are short, it is easy to connect with people from great companies ( be it startups or established ones), you get first class information from first hand, and people are very open to try out new things.
My summary of the Android Open Conference 2011 weiterlesen
Over the time, I have collected some links to websites and articles with topics interesting for Software Architects. Since they might be of interest for others, too, I am providing them here for you. If you also have some links which you think are interesting for other Software Architects, please let me know.
Links for Software Architects weiterlesen
A nice high-level overview of the technique of Dependency Injection using Microsofts Unity framework can be found in the May release of the MSDN magazine.
These principles include maintaining separation of concerns, using abstraction to implement loose coupling between layers and components, implementing service location capabilities, and managing crosscutting concerns such as logging and security. While these may seem to be desirable but unrelated aims, one technique can help you to apply several design principles easily. The Dependency Inversion principle implies separation of concerns through abstractions rather than concrete implementations. In terms of design patterns, you can achieve this by applying the Inversion of Control (IoC) pattern and its related pattern, Dependency Injection (DI).
The theory is simple enough. Instead of specifying at design time the actual concrete type that each class or component will use to perform some activity or process, you arrange for these classes or components to retrieve the appropriate object from a container that you previously configured with type maps and registered types.
Dependency Injection is great for achieving loose coupling of components. There are a lot of tools available that can be used for injecting dependencies. A list of such tools can be found on the Wikipedia page as well as on the Clean Code Developer Tools page.
What defines a professional developer? The initiative „Clean Code Developer“ (german only, english version using Google Translate) tries to facilitate a common understanding of this question. It has started to collect principles, rules and best practices for better software.
They see as basic principle for becoming a professional developer to be self-conscious about your work and always try to improve yourself as well as to adhere to some common best practices and working principles. Trying to lead developers to more professionalism, they have also collected a lot of concrete recommendations for the day to day work. To make it easier to follow these practices and rules, all recommendations are grouped by a so-called grade system. So you can start with the easy ones and get to the maybe not so easy to follow rules later.
Even if you don’t agree to all suggested practices and principles, the side is definitely worth a read since you will find a lot of good practices concentrated on one location. Additionally, they also maintain a link list for useful tools and frameworks.
You can find the Clean Code Developer initiative here.
A helicopter has four main controls: foot pedals, collective pitch lever, cyclic, and throttle. The foot pedals control the tail rotor. With the foot pedals you can counteract the torque of the main blade and, basically, point the nose where you want the helicopter to go. The collective pitch lever, which you hold in your left hand, controls the pitch on the rotor blades. This lets you control the amount of lift the blades generate. The cyclic, which you hold in your right hand, can tip one section of the blade. Move the cyclic, and the helicopter moves in the corresponding direction. The throttle sits at the end of the pitch lever.
It sounds fairly simple. You can use the pedals to point the helicopter where you want it to go. You can use the collective to move up and down. Unfortunately, though, because of the aerodynamics and gyroscopic effects of the blades, all these controls are related. So one small change, such as lowering the collective, causes the helicopter to dip and turn to one side. You have to counteract every change you make with corresponding opposing forces on the other controls. However, by doing that, you introduce more changes to the original control. So you’re constantly dancing on all the controls to keep the helicopter stable.
That’s kind of similar to code. We’ve all worked on systems where you make one small change over here, and another problem pops out over there. So you go over there and fix it, but two more problems pop out somewhere else. You constantly push them back—like that Whack-a-Mole game—and you just never finish. If the system is not orthogonal, if the pieces interact with each other more than necessary, then you’ll always get that kind of distributed bug fixing.
via Orthogonality and the DRY Principle.