Git For Version Control - Why Choosing It Can Define You And Your Team As Developers

The first question one usually asks if one hasn't been exposed it is why use version control software?
My first experience with version control within a team environment was just after I came off a project where two other developers and myself were unable to deliver a first cut of a project because each of us developed in our own way and style, and we just could not get many, many ownership and integration issues worked out in time. I then joined a team that used Sourgear Vault for version control. and where several ground rules placed by our Technical Architect ensured that all code was checked in at the end of every day, and that builds were made automatically on commits. Breaking the build was a big no-no, and the incentive to keep to this was that if someone broke the build, they bought everyone lunch that day, a nice rule which cost me a bit at first in terms of free BK for folks at my expense, but paid itself back nicely in terms of disciplining me to check my code and my tests more thoroughly before committing.

This also gave immediate benefits to me in that not only did I become a better programmer because my code was being constantly checked to ensure I did not break the build, but it also allowed for easier reviewing by my team to ensure adherence to good design patterns, no implementation of anti-patterns or unwarranted hacks, and an adherence to accepted coding standards. For the team it also meant that integration of various components in the project happened much eariler and frequently. Learning from each other's own hacks and best practices also happened much more often, and frequently.

As a single or lone developer, I would also recommend version control as features such as 'code-revert' means quickly 'righting the wrongs' of horrible coding efforts where the neat organised project you started with several hours earlier became strands of spaghetti code you wish you could throw out with yesterdays leftovers.

Recently I came across a video on YouTube about Git by Linus Torvalds, creator of Linux. After watching it and playing around with Git myself, I find it personally appealling to my style of development as I find myself to now be a more mature developer, but still wishing to work closely with younger developers who may be very talented but not have had as many best practice habits in team development ingrained in them.

The key point of this version control system is the term 'distributed' There are no branches, there is no central repository, things common in all systems I met before such as Vault, Team Foundation Server, CVS and Subversion. Instead, every member of the team has his/her own copy of a starting point in the system, and one may choose to include submissions by team members to all to update their own copy of the project system, or not.

In a mentoring-friendly environment of software development I think this can be most effective to training junior developers, as code reviews can be more real time and one-on-one with anyone, from a peer to the lead technical architect. This is not to discount the team dynamics, full team code reviews are great for experienced developers, but for me required a bit of a thick skin as my coding practices are open to a barrage of public, sometimes undiplomatic, feedback from everyone on my team at once. Developers are passionate about their code and coding practices, and so peer code reviews can get a bit heated at times.

With Git, I can see more interaction happening with just as much passion, as well as growth, for a junior developer as a technical architect or senior team member walks through one-on-one with them why certain submissions they make to the technical architect's repository won't make the grade and be included in their build, at least, not yet.

One thing that is great about this is that ownership is so clear here. In this case, the project will be delivered via one person's copy of the project, probably the technical architect or project delivery lead. This ensures ownership is directly attributed, so that in the case of a technical architect code reviews HAVE happened, and no unfixed results of previous code reviews are present.

I missed getting in to today's Open Space Coding so I haven't gotten a 'real world' test with Git yet, but hopefully soon I'll find an opportunity to experiment with it, either at work or on a pet project of my own.

Wolfram Alpha - How it stacks up against Google

WolframAlpha launched at 7pm CST yesterday, against much Twitter hype. If it wasn't tweeted by Peter Kim I probably would not have been interested in yet another search engine claiming to have Googly potential. I went through the WolframAlpha demonstration video, and my interest peaked. After having used it a bit with several adhoc as well as recommended search terms, I realise that, as a database of intentions, WolframAlpha is still a very young infant in the search business, albeit an infant with a potentially high IQ.

One example that started me on this unscientific evaluation was the search for 'Universities near Hounslow, UK', something a little generic, but still near-enough to natural language to be human readable and express the intention of my search. Given the video demo and instructions on the site, it also gave the impression that WolframAlpha would make mince meat of this search. It was very sad to see that it again gave me a 'Wolfram|Alpha isn't sure what to do with your input' screen.
Modifying the search to include a more popular location, 'Universities near Cambridge' resulted in a similar screen. By comparison, Google's seach result returned a mini-map from Google Maps with several univerisities listed, along with their names as website addresses. WolframAlpha failed this search 'litmus test' whereas Google shined brightly.
The second test used was 'September 11, 2001.' Indeed, under noteable events WolframAlpha did list 'World Trade Center destroyed' as one of its results, the result I was searching for. Google, by comparison also had the wikipedia entry for that sad day as its first link. Good litmus test results for both, nice!
A search for a more obscure date of 'September 14, 1979' produced more useful information in WolframAlpha though, since information on a noteable event was there, and the relevancy of its statistical information like moon-phase and sunrise/sunset times seemed a little more appropriate to the possible intention of the search. By comparison Google's relevancy ranking was a bit off to my intention, with links to an archived issue of Science Magazine being its first choice result. 'All technology stories on 14th September 1979 in the Guardian UK' was in the top ten results still around number 5, so still not too far off, given the obscure nature of the search and my unspecific intention with this search.
The tie-breaker for me was using a not-too-popular but still known date, UK Prime Minister Gordon Brown's birthday of 20 February 1951. Here Google floundered, the Wikipedia link to Gordon Brown was listed in the top 10, but was not number one. By comparison, in WolframAlpha's Noteable Events listing Gordon Brown's birthday was listed, along with actor Edward Albert. The Edward Albert birthday was a result that was NOT in Google's top ten search, but did seem to have a strong relevance to search intention that Google missed, even though it was not my search intention. This is a toss-up, but given my opinion that the intention of a search for a date would be noteable events. Given the missing of Edward Albert's birthday from the test results, I'm not sure if Google passed this litmus test.
One nitpick is that WolframAlpha's noteable events listing is always a bit of scroll down the page, the first result was actually the time difference from today. This is probably a tribute to its Mathematica underpinnings, since it is billed as more of a number-cruncher and statistical analyser than a relevancy-finder, which is more Google's forte.
The final litmus test I used was two stocks, 'MSFT AAPL'. That's Microsoft and Apple's stock names, for those unaware. Here WolframAlpha did work as advertised, bringing up very relevant information about each company, and a 'optimal portfolio return' for each. By comparison, Google continuously listed links to stock alerts for each from the previous day's trading. One additional result that came in with Google was an article from May 1st this year on 'What Microsoft Can Learn From Apple', something that may not have been my intention, but was still relevant, and a good link to me, as a business reader. If I were a stock analyst though, I'm not sure how I would have reacted. Both guys passed this litmus test, however where Google offered variety, WolframAlpha offered more purposeful computational knowledge.
However, this should not say WolframAlpha is a Google-killer (yet). Searches for less mathematically formulated queries, such as my name, or 'Ratio of Men To Women in London' seemed to confuse WolframAlpha's supposedly powerful natural language interpreter, just as my initial 'Universities in Hounslow, UK' search did. Google, on the other hand, had no problem understanding it, and directing the results of my search to the intention, which was the national statistics site for the UK.
So although the score so far seems to lead to WolframAlpha being gifted in quite a few ways, it still has a long way to go to even start to be in Google's league. I don't think is quite WolframAlpha's mission yet to be the successor to Google's crown as search engine king, but it should be the BHAG (Big Hairy Audacious Goal) of all search engines anyway.
As I write this, Google actually links 'BHAG' directly to the Wikipedia article on it, whereas WolframAlpha thought I was asking about somewhere in Pakistan. I guess that just reinforces my conclusion, that if you follow the script given, WolframAlpha works decently, however as a database of intentions, WolframAlpha has a long way to go still to reach the Google standard.

Presentation on Improving Web Applications - User Experience and Styles

After a few design sessions today everyone on the team walked away feeling very accomplished, except me. In the pit of my stomach I felt quite the opposite, and though it could have been the flu that I am still recovering from, I needed to be sure that we were not suffering from blissful ignorance and hence getting ourselves into serious trouble when it came to pending estimations we are about to do regarding work we intend to complete in upcoming sprints.

This is around the time any good team member should ask for a health check, but in this case there are no ground rules established so far within the team for health checking designs, so the effectiveness of one is questionable. For effective health checks to happen, the ground rules for analysis of materials for formulating the health weighting have to exist, and be understood and agreed to by all participating.

So I built this presentation based firstly on research into the ground rules used by two leaders in design and development, Google and Apple, and using my own past experience as a web developer to help build it.

I hope it helps teams using it (including ours) ask the right questions that setup good, iterative health checks for improving web applications.