Abe and I have decided to help raise money and awareness for men’s health this month by taking part in the global charity event Movember.

Check out our Movember blog for the details and daily updates…

That headspace that lies somewhere between complete focus and mind numbing obsession.  Well, I snapped out of it two days ago and realized the first half of summer has just disappeared.

The past few weeks have been intense and over night Thirdi has gone through a complete metamorphosis.

First, Thirdi says goodbye to the teams first developer: Ivan Sim. He has moved on to explore new technologies at MDA Corporation.  We wish him the best of luck in his new adventures.

Second, Thirdi has a few new faces.

Andrea Tam - Project Manager
Andrea has been involved with Thirdi since the beginning as manager and contact point for Chosen Stock.  Her intimate knowledge of client relations with Thirdi will go a long way in redefining our process and improving the way we do business.

Charles Iliya Krempeaux - Very Senior Developer
Let me start off by saying his title is not a reference to his age. Charles is a recent graduate of Navarik.  Their loss is our gain and his senior level skill set is a welcome addition to the team. Not to mention his intimidating bouncer like presence.

Rado Gazo - Senior Developer
According to Tony Burbage, Rado is a yoda. Charles classifies him as “one of the top 3 developers I’ve ever worked with”. That’s high praise. ‘Nuff said.

So here we are in the middle of summer with the makings of an incredible team. The future of web software is bright and Thirdi is poised to make a difference.

Each developer is given 3 Summer Days (one for each month of summer) and allowed to use them as they see fit. There is no restriction on consecutive days used, nor on notice of absence. The only restriction is that their escape doesn’t affect crunch time.

So keep your eyes open around the trails of UBC, the hills of North Burnaby and the Central Park pitch & putt - you just may see a developer on the loose!

Fortunately, there is an elegant solution. The idea is based on the Symfony CLI environment. At the top of the test script, add the following lines (or put them in a file and include that file):

<?php
require_once ‘PHPUnit/Framework.php’;

define(’SF_ROOT_DIR’,      realpath(dirname(__file__).’/../..’));
define(’SF_APP’,           ‘frontend’);
define(’SF_ENVIRONMENT’,   ‘cli’);
define(’SF_DEBUG’,          false);

require_once(SF_ROOT_DIR.DIRECTORY_SEPARATOR.’apps’.
DIRECTORY_SEPARATOR.SF_APP.DIRECTORY_SEPARATOR.’config’.
DIRECTORY_SEPARATOR.’config.php’);
?>

These lines should be familiar if you have worked with Symfony CLI. Basically, they are boilerplate code for any Symfony CLI app. With any luck, Symfony should load classes for you automagically.

I was going to write a tool that will solve this problem, but my laziness would have none of it. Instead, I searched the Internet and found this cool little tool: sfPropelMigrationsLightPlugin, a Symfony plug-in. It works like this. Whenever there is a database change, you would initialize a migration and the plug-in creates a PHP file for you to add the database changes. To update the database, just run “symfony migrate <app name>” and the tool will automagically apply all missing updates to the database. This feature is particularly useful if there is more than one person working on the project at the same time. Team members just run “symfony migrate <app name>” and viola, their databases are synchronized with yours. No fuss. It couldn’t have been more simple.

Checkout the plugin at http://trac.symfony-project.com/wiki/sfPropelMigrationsLightPlugin.

The problem had to be solved from a different angle. Rather querying the database with  select statements, we used a free text search engine called Lucene via the sfLucenePlugin. Execution time was reduced substantially but it was still too slow. Since Lucene was originally written in Java, we did a quick test to see how well the Java implementation performed. To our delight, it performed very well - results were returned in less than a second.

The challenge was how to make Java and PHP talk to each other. We experimented with a number of alternatives. In the end we chose XMLRPC over HTTP to bridge the language gap. The protocol is well supported by both languages. It only takes a few lines to create an XMLRPC request object, send it to the XMLRPC Java server and get back an array of PHP objects. No home-brewed, string delimited request/response protocol! The architecture also allows the two processes to run on separate servers or have one Lucene server service multiple PHP servers for better scalaliblity and hardware utilization.

What was the lesson we learned? Use the right tool for the job: if a library suck in one language, try libraries written in other languages (or write one yourself in another language).

The conference also helped to raise my personal awareness of the open source community. There were definitely some very bright minds in the conference. Listening to presentations and case studies where these people tackled and solved hard problems in elegant and practical ways was inspiring. The impact and influence that this community will continue to have in shaping our society is unfathomable.

I’ll like to share some of the important lessons I have picked up at the conference.

1. Security on web applications (by Damien Seguy). Security is a key requirement in all web applications that is often overlooked (or at least not dealt with until it was too late). In his presentation, Daimen was able to demonstrate how a lot of software security compromises in the code can be avoided by using very simple tool such as grep. Best practices include:-
   1. getting rid of unneeded files (.doc, .zip, .old) from the web directory,
   2. moving configuration files out of the web directory,
   3. paying special attention to code such as var_dump, print_r, mysqli_query etc., and make sure their presence don’t open up any potential security breach.

   The idea is to avoid exposure of confidential information to unauthorized personnel.

2. Deployment (by Chris Hartjes). This was one of my favourite talks. In his presentation, Chris shared with us his 6 rules of deployment. The one that I found most prominent can be paraphrased as “if a deployment process was not repeatable and not automated, mistakes will happen”. Chris went on to say “manual deployment is for suckers”. These are strong but truthful words. We might be able to get away with manual deployment for small projects. But if these projects ever grow and scale across multiple servers, manual deployment is out of the question. Another insightful statement by Chris was “a good deployment process is a one-step process; not a two-, three-step process”.
3. Engineering of internal process (by Ronn Abueg and James Andres). Ronn and James implemented a social intranet tool using Drupal. Interestingly, there isn’t much CMS-related content in this presentation. They were able to implement a solution to help facilitate transfer of internal knowledge and information without re-engineering people such as forcing the CEO to turn on his laptop, open up his browser, fill in a form etc. It was a solution that fits seamlessly and painlessly into their existing work flow. Thirdi has been searching for a simple, accurate and cheap (in terms of human effort) mean to track the number of development hours per project. Perhaps something we can implement is to tweak our IDE to keep track of how many hours we spent on a project, or a script to keep track of the number of commits per day, or duration between the early-morning update and end-of-day commit etc. Little things like these can be integrated seamlessly into our existing dev process without imposing additional overhead on our team.

I also picked up some interesting web tools (google gear, phpundercontrol, capistrano, maven, APC) from the conference. But I won’t talk about them here as all of them can easily be found on Google.

Overall, I enjoyed my time at the conference and was able to walk away with a lot of useful tips and tools.

I recently read Daniel Tenner’s blog post on How to recognise a good programmer, and I was curious to see if we do have good programmers according to his criteria.

First I thought about the passion each of us has for our job, and asked each member of the team if they love what they do, and in fact, I quickly found that each one of us here at Thirdi loves what we do.

Ivan likes the whole software development process, from requirements and design to the final high quality product. Stan enjoys solving programs with an elegant solution. Abe, our QA guy, is passionate about delivering the best possible software to our clients and is not satisfied with a product until it is bug free. Matt loves his job so much he says it doesn’t feel like he has a job anymore. And I enjoy creating what we call painless software, software that is simple, easy and straightforward to use.

From talking with the team, I learned that self-teaching is a pretty strong part of our culture. Stan, a Java programmer, learned PHP on his own for a new project and Ivan picked up the Zen Cart framework when he created an online store. Learning a new framework or technology is relatively easy, but being able to leverage it appropriately is a challenge. We don’t use the latest technology buzzword just because it’s the current hot item, but we would use it if the scenario were appropriate. Each of us are self learners because we enjoy it, and we can use the added skills to build better products.

Each of us has worked with a variety of technologies, from bash shell scripting, to JavaBeans, we have used a wide variety of tools and languages: Java, Ruby, Bash, C++, Hibernate, JV2, JV3, Struts, Perl, PHP, Symfony, JMS, Propel, Torque, SOAP, Lucene, and many more. This is just a subset of all the technologies and experiences various members of our team have gained.

Even for a new project each of us will be working on, we have decided that it will be built on Ruby on Rails, an up-and-coming web framework that we’ve been wanting to try.

Does Thirdi Software have good programmers? I believe we do, and the breadth of skill and experience we each bring to the table surprised me.

It is not uncommon for software developers (myself included), who have been programmed to think and work with logical, tangible, and quantifiable entities, to sweep these constraints under the rug until, one day they come back to haunt us. Yet I religiously believe these constraints, to some extent, can be implemented in the software. A lot of them can be accounted for during the design phase of development.

For example, we are 2 weeks into the Gamboozle Fantasy Sports project, and here are 3 non-functional constraints that stood out during the design phase.

1.      Potential Performance Deterioration As A result Of Data Growth. The way we decided to deal with this constraint was to implement an archive module, which is scheduled to migrate old data from some of the “bigger” tables to new tables. Ideally, a simple SQL INSERT.. SELECT statement will do the job. Since this archived data will still be accessed, we need a mechanism to identify which tables (current vs. archive, and if archive, which archive) the end-users are trying to access. A naming convention for these archive tables is needed too.

2.      Efficient Computation. As part of the business requirement, a number of aggregate values have to be displayed regularly to the end-users. Instead of computing these values on-the-fly, we decided to devise a calculate-once-display-often mechanism to help lighten the frequency of number crunching.

3.      Code Maintainability. Since this project involves PHP and JAVA components sharing the same database, there will definitely be some redundant code in the object-relation mapping (ORM) layer. We have decided to use Propel and Torque as the PHP and JAVA ORM layers respectively. Since Propel is ported from Torque, their XML database schema files are very similar. So we will be able to generate 1 common XML database schema file for both components. In this way, any modification to the database schema, for example, adding new columns, dropping existing columns, type change etc., can be easily propagated to both the PHP and JAVA ORM classes.

This is our very own soapbox. Throughout the lifetime of this site you will have a chance to hear about the world as seen through our eyes.

A small taste of things to come include software development, design, best practices, and products we build or like. The blog isn’t limited to this list, but will touch on anything we find interesting. What I’m trying to say is if it smells funny - we’ll let you know. Thirdi is home to some fascinating minds, and it’s time to unleash them on the internet at large. So sit back and listen to our rants, praises, and general nonsense. We hope to offer a feast to your senses from ours.