26. November 2013
20. October 2012
Idea. Idea is starting point for life of software system. Pure raw idea and vision of future able ignite spark of hope that new software could work.
First stages of system evolution are very vulnerable. Idea need to form protective shell from enthusiasts who are helping to grow it. Idea also needs power and resources to survive. Enthusiasts must form some form of protective structure. It could be startup.
Idea is safe for the time being. It starts growing and eating more and more resources.
Time is passing. Enthusiasm is depleting. Dwindling resources could barely support life of idea.
Key turning point. Idea must transform into system which is able to sustain next phases of its life. It must turn into the system which is able to acquire new resources. Sell or bankrupt.
Luck, serendipity or deus ex machina. Somehow it starts selling. Early adopters begin to emerge. They like new system. They sense that it could become something great.
Idea is adapting protective its shell. Startup is no longer viable solution, because original enthusiasts are nearly exhausted. They spent many many hours and sleepless nights to push this idea forward.
Idea is transforming startup shell into company shell. First it is small, but it is growing.
Transformation will take some time. Software system is growing and consuming more and more resources. Balance of income and consumption is critical for survival of idea.
Maintenance. Software system has been around for several years. Idea prospers. New things were introduced with blinding speed, but this is slowing down over the time.
New changes in software system are causing pain. Idea doesn’t like it.
Idea must protect itself and its system. New defensive processes will emerge. Idea is able to deflect all dangerous changes with carefully designed processes.
System continues to grow and attract more resources. It is obvious that everything is ok.
Unfortunately entropy in software is growing. Hidden. Protected. Old parts of system are becoming legacy.
System starts to deflect even good changes by making them hard to implement. Legacy became so big that there is no way around.
Even minor changes must be introduced with careful precision of surgeon. Adding just one line of code to the system could take several days.
Legacy became burden. Development processes are slowing down. Maintenance is burning tremendous amount of resources.
This is a deadly trap. There is no way out. For some companies it is true.
One approach could be to set aside very high amount of resources. Develop wast change and then deploy it in one BIG STEP. It seems to be right! Welcome to booby trap.
More reasonable approach is to diverge small amount of resources from maintenance furnace. Remove clutter and legacy by small steps in the time. Keep a steady flow.
26. February 2012
Software engineers love exactness of computing machines.
Developers often ask for detail specification in order to implement feature according to customer expectation.
It’s impossible to create 100% correct requirements. Customer “moods” are changing and it affects requirements.
Developers are puzzled when requirements are changing every day.
Software engineers were implementing exactly what was written in requirements. The next day they have to adapt to new requirements and half of previous work is nonsense in the context of new day.
The question is: How to face change in requirements?
One way is to put everything into requirements, build protective walls from corporate processes and invoke bureaucratic machinery against any deviation from predefined path. Defend current status quo at all cost…
Then you better start swimming or you’ll sink like a stone
For the times they are a changing
What is the other way? Use anticipation and imagination. Build the software in adaptive fashion. Prepare it for change.
The first step is to admit that requirements are incomplete and that it does not mean that they’re bad.
The second step is to see a bigger picture and to find understanding for customer behavior.
Anticipate rather than react.
28. November 2011
27. August 2011
Try it 🙂
I was playing with one package from Linux. I grab source code of package using Cygwin. This source code contained one funny file: aux.h.
Windows version of Vim refused to open this file with error message: Permission denied.
Even Notepad refused to open this file.
Finally Visual Studio gave me interesting hint about this aux.h file name:
I tried to zip this file by 7Zip and extract it back. Result was that 7Zip decompressed file as _aux.h.
Interesting issue. 🙂
18. June 2011
What I mean by multi-target?
Today it is possible to create Flex project that runs in browser as Flash application. Other option is to create mobile or desktop application using AIR.
The question is how to structure bigger projects that need to target web, mobile and desktop.
Let’s assume that we’re developing multiple applications and therefore it is good to have common library which aggregates common functions.
That is sufficient when you’re targeting just one platform. Once you need to support more projects then one common library is not enough.
It is reasonable to split this library into the main core that is common for all projects and then create specialized libraries for AIR, web and mobile.
On the top of these libraries you can build final applications for desired platform.
- top: applications for mobile, web and desktop
- middle: specialized libraries that extends functionality for mobile, web, desktop
- bottom: common library for all platforms
21. May 2011
17. May 2011
World of mobile devices is quite complex. Increasing number of operating systems and platforms is spliting market and making it harder to implement app that works across different devices.
Thankfully there are some good solutions. Flex development team made a huge step forward and they prepared tools for whole workflow.
If you’re interested in mobile development take a look at this video from Edge newsletter.
I’ll show part of this workflow also this week in Prague at Android Dev Camp. So feel free to stop by. We can discuss many topics related to mobile and Flex/AIR. 😉
17. May 2011
Sergei Sokolov wrote article about Using automated tools across the lifecycle to develop higher quality Flex applications.
He explained some tools and approaches how to build better Flex based software.
I’d like to add some of my notes to this topic:
1. The key factor for reaching good quality of Flex products is learning. Flex is platform and it is evolving. Therefore it is imperative to learn new approaches to solve some problems.
2. Automation is very important. Flash Builder is bundled with support for Ant. That is not enough. Continuous integration should be implemented via tools like Maven using FlexMojos. Without this point everything is useless, because you’ll end up with mixing different versions of Flex SDK with your framework. Thanks to Jenkins and FlexMojos you reach stability in SW production. We already launched Jenkins CI for open source ActionScript projects – you can find some details at corlan.org.
Here is small example how to use FlexMojos.
3. Teach developers how to use FlexUnit. Companies tend to buy cheaper version of Flash Builder which has no support for FlexUnit. Investing few more bucks could give them very handy tool. See lynda.com or tv.adobe.com for lecture about FlexUnit. There are also other helpful tools like FlexMonkey, etc.
4. Different tools. Flash Builder is great, but real development power comes with combination of Flash Builder with IntelliJ Idea Ultimate. Those two tools together could speed up development and improve code quality. Also test automation has good implementation in IntelliJ Idea.
5. Flex PMD. This could help team which deals with new developers. Often it is hard to guess level of skill of new developer in the team. Using Flex PMD could help with measuring and detecting anomalies in his code style
6. Get rid of Not Invented Here Syndrome. There are many small useful frameworks which could help to improve Flex productivity, like Swiz, RobotLegs. Knowing those frameworks could save hundreds of development hours. So give a space to developers to learn new approaches.
I prefer small frameworks with less singletons inside. Some Flex frameworks are overflowing with singletons. Do not use sw with too much singletons, it will bite you and maintainability of your Flex product will drop to zero. Just a friendly warning at the end 🙂
In my opinion this is the core of producing real good and stable Flex software.
2. May 2011
I was invited to give a talk about development based on Adobe AIR platform for Google Android. 🙂
This is my favorit topic. AIR platform has been here for several years and it is quite mature. It provides solid framework for large range of applications. AIR platform is good for developing small apps or even the big enterprise systems.
Flex/AIR framework is open source. Flash Builder IDE based on Eclipse is very useful tool for developers.
You can find more details about this event at aDevCamp.cz.
It’s great opportunity to meet people from Android community.