Windows 7 or Ubuntu, a developer's POV

When I started ubuntu for my desktop years ago, I had three targets :

1- be familiar with linux, for better tackling with our integration/production servers.
2- better understanding for OS, since you will rely much on the terminal instead of GUI
3- security, no malicious exe on my usb flash will harm my PC

the results -respectively- where :

1- somehow, not much
2- a little, as I was just struggling here and there to find how to make things work
3- Yes yes yes

but I -both as a developer and and an end user- faced many problem, that can be summarized to "productivity killer" and "no easy way to ...."

1- No GIT client as easy and free as tortoise GIT (some friends adviced to settle for GIT bash but I wasn't convinced)

2- If you do any freelancing work, most of your clients will be windows users, so you need to simulate their environments as much as possible.

3- One of my projects where killed because I wasn't able to install a third party mysql library that my code rely on - 4 nights of hard working with no hope- on my client's windows pc, though it was tooooo easy on linux .... may be If I had windows I would have taken another approach

4- One of my odesk clients swindled me and refused to pay for the task because I wasn't able to setup the monitoring client easily -It took me a day later to setup- , so he pretended that the work wasn't done

5-need to easily run exe files that your client provide you.

6-  Difficult to install the driver of the Internet USB driver provided by a local telecom providor

7- go search the internet in order to install any thing

8- No pdf/doc editor provides printingon both sides or booklet printing -AFAIK-

9- No audioplayer provides fast play that I need much to finish lectures and lessons quickly -AFAIK-

So, sadly I decided to switch back to windows and face again the endless trojans, viruses, ad-wares and similar stuff

Continous Integration - a summary

Reference to Martin Fowler's great article Continuous Integration , I liked to summarize some of most important points in the article along with the main steps that a developer should follow in his daily process according to my understanding from the article

What is it?

software development practice where members of a team integrate their work frequently (at least daily)

Benefits of CI:

1.       reduced risk (frequent tests and integration for small changes)

2.       Have a predictiction how long integration it will take

3.       See how far you are through the process

4.       Easier to find bugs (depends on the efficiency of unit tests)

       Daily routine:

1.       Everything should be stored to the Source code management tool (code + properties files+ DB schema + DDLs for DB configuration + install/build scripts  + libraries + last stable executable) à If using a virgin machine, do a checkout, and be able to fully build the system

2.       Take a copy from the source code management  (GIT for ex) mainline (master in case of GIT) to  your machine.

3.       Make your changes + unit tests (Self-Testing code  , TDD preferred)

4.       Build + test

5.       Commit to mainline now (or make a separate branch till integration tests pass)

6.       Should build (a fast build) on integration server (Clone of the Production Environment) after each commit (don’t go home before it succeeds)

7.     Fix Broken Builds Immediately (top priority) : if reason not obvious, rollback then fix, don’t debug.

       Rules and Tips:

-          Each build must be accompanied with running unit tests. 
-          Should commit to the mainline daily at least. 
-          Deployment can be automated (preferred) with scripts to deploy /rollback  applications into any environment easily, or manual (if automated is slow)

-          If you are not using CI , you can start first with nightly builds

-          Commit build must be fast (10 minutes ) ,To achieve this, 1) break down the system to smaller parts - 2)  the deployment tests (which take most of the time)can be divided into 2 categories (thus 2 environments) : main short tests(no DB hits) that is run with the commit build and heavy lengthy tests that can run afterwards (after I guarantee a correct build) , this is called deployment pipeline

-          make sure there's a well-known place where people can find the latest stable executable.

-          All people should be able to see build status.

-          Integration environment should be a Clone of the Production Environment (OS ver, DB ver, IPs, all libs, same HW) : every difference results in a risk that what happens under test won't happen in production.

-          you need multiple environments, one to run commit tests, one or more to run secondary tests + prod

-          good ideas for deployment : 1) deploying a trial build to a subset of users – 2) In clustered environments ,deploy to one node at a time

**This is to claim that I took all the info from the mentioned article and that the article's author is not responsible of this summary