nickbennett_blog

Tag: svn

  • Essential LAMP tools

    Essential LAMP tools

    For the last time am I going to utter the words ‘I wish I’d found this earlier’. There are so many great tools out there for developers that it can become overwhelming. I used to just accept the flaws in my text editor or database client. Often telling myself ‘it’s better the devil you know’. Recently, however, certain frustrations have caused me to reassess the tools I am using. At this current point in time, I have reached a state of LAMP developer nirvana! This article is to help you reach the same higher state of consciousness!

    OK, few points to know before we kick off. I am very tight with my cash. Despite this, I am a keen Apple advocate (maybe the two traits aren’t entirely unrelated). The tools I’ll talk about will be for OSx but I’ll try to mention some Windows tools along the way.

    MySQL
    Free GUIs for MySQL have come a long way since the free ones provided by MySQL. The latest incarnation is Workbench. The killer functionality here is the ERR modelling creation tool. You create your database, tables, initial inserts and relationships. Hit forward engineer and hey presto! Your schema is all up and running. And you also have a fully documented schema. As a habit, I try to add comments to all tables and some columns. This diagram process is one of my first tasks for any new project. The query editor for Workbench doesn’t include a decent auto-complete functionality. An essential feature if you ask me. For this try Sequel Pro. It’s snappy, free and highly intuitive.

    Text editor
    OK, the most delicate of subjects. I’ve never really used a full IDE to develop but I hear Eclipse is the front-runner on this. I had been recently using Komodo edit which is a great free text editor. My highlight feature on this is the scanning of other PHP DocBlock comments. Within your current file, it sees you’re calling a method from another class (in another file) and tells you what parameters the class expects. Pure black magic. My only gripe with the editor was that the shortcuts weren’t intuitive and some just didn’t work. I’d found Textmate was better for this so gave Textmate 2 a try. They’ve really dropped the ball on this. Textmate 2 is awful! That’s when I found Sublime Text. Sublime Text will cost you around £45 but it’s worth every penny. Once package control is installed you have a world of useful plugins at your fingertips! For Windows, I always find Notepad++ a decent free editor.

    Source control
    I’ve used CVS and Subversion. Both of which are quite similar. Recently, I’ve made the switch to GIT and I am amazed by it! I’ve implemented a GIT flow approach which means I have a solid workflow which doesn’t interfere with other feature branches on the same code base. Switching to different features is so easy and still makes me go ‘wow’ when I do it.

    Linux/Apache
    I work on the mac mainly as it’s a UNIX-based operating system. This allows me to use a lot of the Pre-built commands available with my personal/work Linux servers. The terminal app is very good on the Mac and likewise Putty on Windows is also very good. For package installation on the Mac Macports is essential and for Linux Yum is superb!

    I guess that’s it for the time being! To take the pain out of setting up your LAMP environment on your mac I would highly recommend Zend’s community server.

    Next time I’ll discuss my project process methodology.

  • SVN Magic

    My company recently hired a new developer which brought the number of developers to….(drum roll)…Four! OK, not a really significant amount but enough for us to need a more effective code change reporting system. We needed a way to alert developers of any changes made to their files. The system I managed to put in place has been running for about a week and I thought I would do a blog post to maybe help other small development teams to introduce something similar. The solution I set out to achieve was this …

    A daily email is sent to every developer with a list of files that have been changed the previous day. The list will only include files that this particular developer had previously added or changed. Attached to the email is an HTML file containing a more detailed view of the changes made to each file.

    If you think this would be useful for you then continue reading. The first step was to store the details of each SVN commit in a DB table. This was accomplished by creating a script that was called after every commit. SVN comes with a selection of ‘hooks’ which are executable bash scripts that run after (or before ) a specific SVN event occurs. Simply go to your SVN hooks directory and copy the template file post-commit.tmpl as post-commit. Add the shell commands required to call your script and make it executable.

    chmod +x post-commit

    My script uses the Repository and Revision variables passed via SVN to carry out an svnlook on the repository for that revision. I use the PHP system call to store the output in a variable (use square quotes “). I then use the PHP explode on the new lines (n) to generate a nice neat array of variables. I simply store each of the files involved in the commit in my DB table along with the revision number, the author, the comment, and the DateTime.

    My second script does the main leg work. I firstly added the script to our crontab to run every morning. The first thing the script does is return all of the commits for the previous day. For each file, it runs svn log and stores the output in a variable. By using some exploding and other PHP string functions the scripts gets the output into a manageable format. From this information, we determine who previously changed this particular file. We use the author name as the main KEY of a large array we’ll use later. In the array, we store all of the information we think may be useful to include in our final email.

    Now for the cool part. We export the previous revision of this particular file to a temporary directory and also the latest version of this file.

    svn export --revision 120 file:///my_repos/blog.html temp/temp1.txt
svn export --revision 121 file:///my_repos/blog.html temp/temp2.txt

    We use a 3rd party Pear class to give us a comparison array of the two files (showing new code snippets, changed code snippets, and deleted code snippets). We add some final gloss to our email by using some 3rd party syntax highlighting.

    OK, at this point we should have our enormous array of SVN usernames and file details. All we need to do now is loop through each SVN username key and create our email. I have a template system in place that takes care of displaying the diffs between the files. I simply write this to an HTML file and attach it to the email. I have a list of email addresses in the database assigned to each SVN username. And you’re done.

    Please let me know if you would like any further details on this and I’ll elaborate on those points. Good Luck!