Closed development instance in Eclipse ecosystem

I've been reading Bjorn's posts on open source and open development. I can't disagree with his view on open source being more than just making code available. Getting project participation, in greater capacities than just mailing lists, from community is a good thing, and that should definitely be taken into consideration with proper feedback. The very purpose of being "open" is defeated when a project starts ignoring community contribution without sensible reasons.

I've reason to write this, although I'm not strictly against closely developed open source projects.

I've been working with a modeling toolkit for quite sometime and had customized it to suit my requirements. The contribution was in the core part of the tool (GEF based clipboard, motility and other ergonomic support for better modeling experience). I sent a mail to project admin asking if they would be interested in taking this contribution, after unknown number of days I got the reply asking for contribution review. I sent it as plug-in source code, not as patch, listing changes in the packages and configs. Most of the features offered in the contribution are actually in the project road-map as enhancement list.

But, after more than two months now, I'm still without reply(positive or negative), without comments, without acknowledgment. Now, I've almost lost interest in contributing it.

I hope those required features will be implemented (in anyway project team wishes) in next major release of the project, but I can only hope because the project is not really being developed openly. How sad...

Don't get me wrong. I've nothing against the tool, the tool is excellent and remarkably well designed and implemented; Nor with the team developing it, it's their job. But they should definitely mention somewhere that they are not open to external contributions in development.

Essential Features for Eclipse PDT

Eclipse PDT project initiative is a good news for PHP developers. However, there are few basic features, which are expected of any web development tooling, still missing. It is good to know that the project is focused on serious features on unit testing, debug infrastructure, editors etc. You can vote for the essential feature enhancement on project page.

I would like to share some PDT uses from a developer perspective. I use PDT for editing and source code management. These features are good enough, and will be more productive eventually.

However I felt lack of support for deployment features, all you get is external tools for local apache and basic page browsing. But Every time I modify a web page, I've to do rcp or use WinSCP to deploy that file back to the server and refresh page. Also, most of the times, It's essential to be connected with server on SSH connection to do regular fancy server stuff. WinSCP, although a great tool, isn't really "ergonomic excellence" and hence this tool switching becomes a painful activity.

It seems PDT is assuming that developers work only on development/staging machine and hence the lack of support for deployed web applications. Also based on my experience, I found PHP deployment to be very very different, fairly simple to be ridiculously near non-existence, compared to other "heavy-weight" web environment. Java, for example, has lots of "things" and steps to deploy a web app, but that's a different story...

I strongly recommend consideration for following features:

1. Built in SSH command interface (remote terminal as console view ).
2. Support for auto upload, or built in rcp (rsync builder - rsync as a part of auto-build would be a great feature!). Alternatively, this can be like MS Visual Studio style interface through HTTP interface, using HTTP methods (PUT etc.). Live Deployment feature is *essential*.

These basic features, not specific to only PHP IDE, can substantially increase productivity.
I'll post more uses of PDT as I go along using it.

SOA for Techies

Tired of marketing meaning of SOA? Does the word SOA really made you feel sick? Confused what is SOA after all?

Here is the simple explanation of SOA (Service Oriented Architecture) with technical touch by Uncle Bob.

SOA is the practice of sequestering the core business functions into independent services that don’t change frequently. These services are glorified functions that are called by one or more presentation programs. The presentation programs are volatile bits of software that present data to, and accept data from, various users.

SOA is very obscure, if not obliterate, term - one of many which are humming on the web. Thanks to guys like Martin, who tries to address the real side of it. Read more here. I recommend reading this post, and upcoming posts, before you start speaking about SOA in any conference or technical discussions. Well the same is true for every other Buzz word.

HOW TO: Setting up GForge in minutes

GForge is a collaborative development environment, which was forked from SourceForge, read more about it here. GForge is being used heavily world wide and is much better option for project management, versioning and collaboration. The best thing is, it's open source and freely available and is documented and improved regularly.

I spent past week configuring and hacking GForge. Apparently, It requires a good understanding of many Linux related stuff. Being sufficiently complex, it takes good system administration skills to get it running perfectly. I'm not proclaimed Linux expert, neither plan to be one; but I agree it was fun playing with this cool stuff in Linux among others.

Well If you are not curious on details, you may skip rest of the post.

There are multiple ways of setting it up, in increasing order of difficulty:

1. You can download Pre-configured GForge VMWare Image on Fedora core.
2. If you use debian based linux distributions, auto install all the dependencies and gforge using one simple command.
3. Download official tar-ball and configure it by hands on any Linux.

I tried all of them on Ubuntu and Fedora, and It worked well in most cases. Doing everything from scratch, i.e. installing it from "official" tarball, is bit difficult but not amazingly hard (more than linux, you need to understand how various things like DNS, Postgres, MailMan, WikiWikiWeb, CVS, SVN, LDAP etc. work).

If you want to deploy it on Debian or debian based distro, you've to update your sources.list to lookup/install and upgrade Gforge for debian, read more here. Be careful in doing 'apt-get install', it may render your OS useless, if GForge and dependencies are not configured smartly. Especially you'll face problems related to OpenLDAP and Postgres SQL, also these sources has older versions of Postgres which are bit difficult to upgrade without dependency issues. For example, if you fail to install postgres properly, you'll not be able to login which expects LDAP authentication. LDAP, in turn, depends on DB which is not well-configured, what will happen is everytime you try to login at tty it will give you "Can't connect to DB". If you run in such problems, You can login as single user from GRUB loader and delete ldapnss and other ldap related files from /etc to get it running normally, but this can be really dirty exercise.

The easiest most is to play with VMWare image. Recently, (ok, not so recently) some contributors at gforge.org made virtual appliance of GForge on Fedora Core 3, you may download it from here. It's pretty easy to setup and get going with it.

However, There are several problems when you run VMWare image in VMWare Player:
1. At first you've to setup the virtual host for 80 and 443 (HTTP, HTTPS) in apache configuration.

2. If you run this image on other network, you'll have problems of failed login with out any warning or error message you'll see glorious "Cookies must be enabled past this point" and nothing will happen. This is because your VMWare Image IP is different than what it is configured for apache, and browser will stop accepting cookie from the server. This whole IP thing is problematic with VMWare because VMware host does not automatically provide internal DNS service for the virtual machines, and IP allocation is based on the host network adapters bridged with virtual VMWare adapters, which may have different addressing schemes. In short, IP of gforge image keeps changing based on the computer you run it on.

In this case you can either reconfigure Virtual host settings in httpd.conf to match current IP or you can force static ip by adding following lines in your /etc/rc.local file.

/sbin/ifconfig eth0 [staticip] netmask [subnetmask]

This will ensure that you've static IP everytime you run image. Once run, you can access the gforge portal from host OS browser. That's it, there you go.

I'll write more about GForge interesting internal stuff sometime later.