One of the biggest challenges for me is often where to get good graphics and sound resources. There are already a lot of lists from other developers available, but still my own list might be useful for you, too. 🙂
Just Another List of Graphics and Sound Resources weiterlesen
Google announced on its Android Developers Blog that they are now providing a device dashboard showing the distribution of the Android version accessing the Android Market (later on also including hardware characteristics of devices).
As a developer, I often wonder which Android platforms my applications should support,especially as the number of Android-powered devices grows. Should my application only focus on the latest version of the platform or should it support older ones as well?
To help with this kind of decision, I am excited to announce the new device dashboard. It provides information about deployed Android-powered devices that is helpful to developers as they build and update their apps. The dashboard provides the relative distribution of Android platform versions on devices running Android Market.
…
In summary, Android 1.5, 1.6, and 2.0.1 are the 3 versions of the platform that are deployed in volume. Our goal is to provide you with the tools and information to make it easy for you to target specific versions of the platform or all the versions that are deployed in volume.
We plan to update the dashboard regularly to reflect deployment of new Android platforms. We also plan to expand the dashboard to include other information like devices per screen size and so on.
Don’t get me wrong: the data is very interesting. However, it strongly reminds me on the situation on Windows, where still about 30% of the users use Windows XP. Having such a big fragmentation of OS versions really forces you to either make big compromises and build your application only using the features of the lowest OS version or to make your application adapt to the OS version it is running on. The later one adds a lot of trouble in development efforts, testing and bug fixing.
Still, it will be interesting to see how the fragmentation of Android devices evolve and how this will influence the attraction of developers providing Apps for the Android OS. Of course, having developers focusing only on certain Android OS versions and/or hardware characteristics could also make the hardware vendors streamline their hardware specs and OS versions. Selling Android devices which show only very few apps on the Android Market might not sell so well after all.
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.
Recently, I stumpled upon Ralf Westphal’s post about packing of .NET assemblies for releasing (sorry, german only). The tool he describes is called Netz and really seems to be useful for having the possibility to break down separate functionality into specific assemblies at development time but not having to deliver a lot of separate assemblies for release.
I did not yet have the time to try Netz by myself. But it is good to know that such a tool exists and will try it out at the next opportunity.
As soon as something is broken—whether it is a bug in the code, a problem with your process, a bad requirement, bad documentation—something you know is just wrong, you really have to stop and address it right then and there. Just fix it. And if you just can’t fix it, put up police tape around it. Nail plywood over it. Make sure everybody knows it is broken, that they shouldn’t trust it, shouldn’t go near it. It is as important to show you are on top of the situation as it is to actually fix the problem. As soon as something is broken and not fixed, it starts spreading a malaise across the team. „Well, that’s broken. Oh I just broke that. Oh well.“
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.
Hello world, software developers and architects! I hope, I can provide you some interesting articles and links with this blog. There are some interesting topics in my backlog, but I did not yet estimate them. So let’s wait for the next sprint review to post the results.
Man, too many agile buzz words in my mind… 😉