Posts Tagged ‘open source’

Portable Meld on Windows

February 12, 2011

Often I need to compare and merge files or folders together for changes between them. Gladly, many applications exist for such a task. This can come as using the diff command line tool, sadly it is not visually pleasant. Therefore several visual interfaces to ease the comparison side by side. Examples of such are:

A detailed comparison between the them and others can be found here. My personal favorite of these is meld (specially for folder comparison). On a Linux system, it is quite easy to set up, specially if it is deb bases because there is a package for it. A problem shows up when wanting to use meld in Windows. After some googling I found this guide showing how to install it for windows. Using this guide, I managed to get it to work, but I prefer a portable installation to take it anywhere.

Following are the steps I followed to get a portable version of meld up and running. Take care that performing the steps need administrative rights, but it can run anywhere.

  1. Create a directory to contain meld binaries and its dependencies. Let us reference to it as <meld install dir>
  2. Download portable python 2.6, and install it under <meld install dir>\Python26
  3. Add the portable python installation to the registry. This is done by opening the portable python interpretor an running the script from here
  4. Download the GKT+ 2.2 run time all in one bundle from here. Extract it to <meld install dir>\gtk+
  5. Download an install the latest PyGTK libraries. These are the PyGTKPyCairo, and PyGObject modules. This will install to the correct python based on the registry entry from step 3.
  6. Download meld 1.5 from here. Extract it to <meld install dir>\meld-src
  7. Create a file “<meld install dir>\start-meld.bat”. The content of this file is:
    @echo off
    set PATH=%CD%\Python26\App;%CD%\gtk+\bin
    python meld-src\bin\meld

And that is it, run start-meld.bat and enjoy 🙂


Developer vs. User <=> Driver vs. Mechanic

April 1, 2010

Hypothesis: The Developer User relation is equivalent to the car driver mechanic relation.

Through my few numbered years of driving in the lovely streets of Cairo, i faced car troubles every now and then. In the case of such circumstances, I head to my trusty mechanic. From here, starts the problem, when I am driving my car, and i notice a problem, it is very difficult to reproduce by the mechanic. Such a reproduction often happens when it’s too late.

Here, comes the fitting analogy, mechanics are car using experts. They manage to use cars in an expert manner, one that hides any possible problems in the car.

The same maps to the computer software users, where they see problems that developers are unable to reproduce, simply because of their computer usage habits that are so much different from that of end users.

Quod Erat Demonstrandum (QED).

Thus, the lesson to learn here is, every time you want to feel like a user, think of yourself driving your car, and weird things starting to happen.

Breaking up with your code

March 4, 2010

A famous quote from The Cathedral and the Bazaar is “Plan to throw one away; you will, anyhow”. This never hits a programmer with it’s true meaning until they have to throw aways a large bit of code base that they invested time and effort in. Coders tend to build an emotional connection towards every letter of code they wrote (I know i sure do). On the other hand, needs arise where obstacles render current software “unfixable”. This confronts with the painful fact that change must be done. Taking an objective stand point in that decision is a tough decision, but facts are fact in face of improvement. In the end of the day, breaking up is tough but a fresh start would most likely end up in more bulletproof code.

Open source Projects, The Life Cycle

November 21, 2009

Recently, I have been involved into the development of an open source project, that is currently under major modifications. Seeing this change happening before my eyes got me to think, how do open source projects evolve, and how do exiting well matured (old) projects reached their current state.

I feel that most open source projects start with a crazy idea, usually driven by some sort of need (the itch as called by The Cathedral and the Bazaar). But when one thinks about it, not many people have the guts to go out in the open to satisfy that drive. Mostly people who do aim to get an up and running prototype that shows the idea to the community. This is mainly to get people in the community excited, and people who had a similar itch involved.

To reach that initial prototype, the team working is often small, as the community knows nothing yet. The lack of the outsider perspective might limit the developers to their own coding style, and the drive of getting a prototype out might loose focus on certain coding aspects.

After the prototype is out, the effects of the bazaar model is seen, where bugs are fixed, code is optimized, improved, and documented. At this stage, the project takes it’s first step to maturity.

The changes over time could range the minor to the drastic. The main issue that developers wanting to get involved  with an evolving project, whether rapidly or slowly, patience is need. This is due to the need to take time to obtain a deep understanding of the code. Furthermore, patience is needed when a project is changing rapidly, as they mostly could end up in code breaks, but keep in mind they will eventually be fixed (possibly by you). Such an aspect also requires high flexibility.

After these many iterations by the community, the project starts to stabilize into a state of maturity. Usually this is called the 1.0 release. After that stage, progress starts to slow down, and focus starts to go to having new features. The main code base is rarely changed unless with major following released, or core feature additions that require that due to the structure of the code.

%d bloggers like this: