Codrin Andronic

"stop existing and start living" – M. Jackson

My adventure generator device

Yes there is such a thing. In my case it’s an old motorcycle which found it’s way into my life 5 years ago and doesn’t want to leave, despite my attempts to get rid of it.

I live a solitary life and most of the year it’s quite boring. At times I attempt to change it but without success. But starting late spring until early autumn, my trusty BMW comes to my rescue. And it does a good job too. When I look back into my past, I always see good memories which otherwise might just be blank spaces.

Not all these so called adventures are pleasant at first, but become so when you look back at them. Like when rain starts and you begin looking for shelter but find one only after you’re already wet and cold. Or when riding in remote areas and drop your bike in a ditch. Or when you start driving and after a few hundred meters hear a desperate “miauuu” coming from inside the motorcycle then stop to find a kitten at the base of the swing-arm. Or when you are so dirty and stinky after days of riding and camping and take a bath in cold mountain river. And the list can go on.

At these times I promise myself I will sell the damn bike and travel like normal people do, in a heated/air conditioned car, protected from the elements, listening to music, missing all the fun :). But after the rain comes the sun, and so the old BMW stays with me like a good friend.


Leave a comment »

Software – Food Chain Analogy

Reading Code Complete 2nd edition, I came upon a good analogy for the software development process, which I will quote below.

Compare the software food chain to a real food chain. In an ecologically sound environment, seagulls eat fresh salmon. That’s nourishing to them because the salmon ate fresh herring, and they in turn ate fresh water bugs. The result is a healthy food chain. In programming, if you have healthy food at each stage in the food chain, the result is healthy code written by happy programmers.

In a polluted environment, the water bugs have been swimming in nuclear waste, the herring are contaminated by PCBs, and the salmon that eat the herring swam through oil spills. The seagulls are, unfortunately, at the end of the food chain, so they don’t eat just the oil in the bad salmon. They also eat the PCBs and the nuclear waste from the herring and the water bugs. In programming, if your requirements are contaminated, they contaminate the architecture, and the architecture in turn contaminates construction. This leads to grumpy, malnourished programmers and radioactive, polluted software that’s riddled with defects.

Let’s start eating healthy and build quality software once and for all!

Leave a comment »

MyGoals 1.3

New update availabe for MyGoals. Now it features a Vision Board and improved ergonomics.

Click HERE for download and details.

Leave a comment »

Pragmatic programmer tips

Recently I read an interesting book about software development  – “The Pragmatic Programmer, From Journeyman To Master“. I highly recommend it to all programmers. As a summary, following is a list with the highlights:

  • Invest regularly in your portfolio
  • Diversify your knowledge (the more things you know the more valuable you are)
  • Manage risk when investing in knowledge (are you learning useful things?)
  • Learn a new programming language every year
  • Read a technical book every few months
  • Experiment with different environment
  • Stay up to date with technical news
  • When you have something to communicate, make a plan
  • Know what to say
  • You must know the audience
  • Choose the right moment
  • Pay attention to aesthetics (if you write a document, or make a presentation)
  • Involve the audience
  • Listen
  • Provide answers
  • Do not duplicate (code, functionality, comments, anything)
  • Develop orthogonal (independent) systems
  • Develop closed components (do not let other components to change its state)
  • Use prototypes to try something experimental, such as:
    • Architecture
    • A new functionality into an existing system
    • The structure and content of external data
    • Component or 3rd party tools
    • Performance
    • UI / design
  • When you make a prototype, you can omit:
    • Correctness
    • Completeness
    • Robustness (error handling)
    • Style (comments, documentation, writing clean code etc.)
  • Implement your own mini-language when you need it
  • Do not panic
  • Always use source control
  • Learn a text manipulation language.
  • Use code generators
  • Write “shy” code – do not reveal too many details and do not interaction with many modules
  • Minimize coupling
  • When writing methods, use parameters of primary types
  • Develop configurable systems
  • Consider concurrency when you design
  • Always be aware of what you do
  • Developing something you don’t understand or working with technology that you are not familiar with is an invitation to make mistakes or wrong decisions
  • Work with a plan
  • Do not make assumptions. If you have to assume, consider the worst case
  • Document the assumptions and talks to them
  • Do not just test code, test assumptions too
  • Prioritize efforts and tasks
  • Do not let existing code dictate future code
  • Complexity of algorithms, in descending order of performance:
    • O (1) – access to array elements, simple instructions
    • O (log (n)) – binary search
    • O (n) – simple loops, computing min/max in arrays
    • O (n * log (n)) – quick sort, heap sort
    • O (n ^ 2) – two nested loops, selection and insertion sort
    • O (n ^ c) – combinatorial problems
  • Always test an algorithm for worst case before you start improving it (is it absolutely necessary, has it reached its limits?)
  • Consider refactoring in case of:
    • Duplications
    • Dependent components
    • Code that is expired due to modifications to the requirements
    • Bad performance
  • When you discover that something needs refactoring, acts immediately or as soon as possible
  • Don’t do refactoring and add functionality at the same time
  • Make sure you have rigorous tests before you begin refactoring
  • Take small steps and test often
  • Write code that is easy to test. Tests help to develop orthogonal systems
  • Test all possible input/output
  • Write tests before implementing
  • Unit tests illustrate how to use the module being tested
  • When gathering requirements for a project, spend time with users to better understand their needs
  • Use use-case diagrams when writing requirements documents
  • Do not overload requirements
  • Keep track of changes in the requirements
  • Use a glossary to identify clearly each term used in the project
  • In most cases, a problem seems more complicated than it actually is. Approach it systematically. Ask yourself the following questions:
    • Is there a simpler way?
    • Are you trying to solve the correct problem?
    • Why is it a problem?
    • What makes it so difficult?
    • Must it be done this way?
    • Is it needed?
  • Automate everything.
  • Generate documentation from comments in the code
  • Comments say what is implemented; they don’t explain how
  • Expectations should be communicated and exceeded only slightly
Leave a comment »

Winamp remote control

I just finished a small project for Pocket PC that is controlling Winamp music player remotely using Bluetooth or WiFi. It is free to use, just like my other software and quite useful, at least for me :)

Here is the link to Winamp Remote. Enjoy!

1 Comment »