I love using the Git branching model outlined by Vincent Driessen. My flow is almost identical to what he has described except for where the feature branches are stored. Specifically he states:

Feature branches typically exist in developer repos only, not in origin.

I’m a little less trusting with feature branches and instead often push them to the central remote repository. For me, I fear that days of work could be lost by keeping the work solely on my repo until it is ready to be merged back into the develop branch. I can imagine my repository being corrupted, my hard drive dying or my computer being stolen all causing work loss. I don’t like to leave my hard work to Murphy’s law.

Now one could use a backup strategy to mitigate this issue and I do highly recommend doing this. I have used CrashPlan for years and it has saved me a few times, making CrashPlan worth every penny. However, I also like to know there is a central Git repository holding my code (again a trust issue). Plus some companies will not allow their code to be placed on any server outside of their network.

Since myself and my entire team have chosen to place our “feature-*” branches on our central remote repository, it has caused a small issue. We find that we end up with a lot of old and forgotten branches on this remote repository as well as our local machines. Of course Git is great at this task of removing the old branches.

Delete Local & Remote Branches

We can remove the remote branch by using the command:

git push origin --delete <branchName>

Then we can remove the local branch with the command:

git branch -d <branchName>

Great, problem solved I can run those two commands each time I’m done working on a feature. But wait, I don’t want to remember those two commands and I want to run only one command. So, I put together a couple bash functions that will make this easier. Just drop these functions in your ~/.bashrc file or in the appropriate dotfiles directory if you happen to be using my Dot File Manager.

function confirm () {
    # call with a prompt string or use a default
    read -r -p "${1:-Are you sure? [y/N]} " response
    case $response in
        [yY][eE][sS]|[yY])
            true
            ;;
        *)
            false
            ;;
    esac
}
function git-delete-branch () {
  if [ "$#" -ne 1 ]; then
      printf "Usage: $FUNCNAME branchName\nWill delete the specified branch from both the local repository and remote\n";
      return 1;
  fi
  echo "Delete the branch '$1' from your local repository?" && confirm && git branch -d $1;
  echo "Delete the branch '$1' from the remote repository?" && confirm && git push origin --delete $1;
}

After adding these functions don’t forget to use the source command to load the functions into your shell.

Now a branch can be easily deleted from both the local and remote repository or just one of them by executing the command:

git-delete-branch <branchName>

Delete Merged Branches

Since we have multiple developers all pushing their branches to the central repository, we often find that over time we start to get a long list of orphaned branches (branches that no one is working on anymore). Any easy way to clean up most of these branches is with the following command which will show the branches that have already been merged into your current branch.

git branch --merged

Then each branch can be manually deleted with the command:

git push origin --delete <branchName>

Again, I like things simple so I put together the following function to streamline the process:

function git-delete-merged-branches () {
  echo && \
  echo "Branches that are already merged into $(git rev-parse --abbrev-ref HEAD) and will be deleted from both local and remote:" && \
  echo && \
  git branch --merged | grep feature && \
  echo && \
  confirm && git branch --merged | grep feature | xargs -n1 -I '{}' sh -c "git push origin --delete '{}'; git branch -d '{}';"
}

Make sure you use the the confirm function pasted above.

Another tool

Another possible solution to the above stated problem is to use the git-flow tool. At first glance it seems to be a handy tool to automate many of the tasks in the GitFlow process.

However, in my short experience with it, I found it doing things I didn’t expect. I then checked the github repository and noticed an unhealthy amount of open issues (175) and pull requests (78) with the last commit date being September of 2012. This project is officially dead in my book.

More recently, I have found out that there is another fork of this project that is being kept up-to-date. It’s called git-flow (AVH Edition). This one might have more potential.

However, I think the GitFlow approach is easy enough to carry out with the standard Git tool that I have not yet taken the time to test out this newer git-flow (AVH Edition) tool.

Have you used the newer git-flow tool? What are your experiences with it? Do you have any other git commands or tools that have helped with your day-to-day Git operations?

The post Git Flow – Remove Local & Remote Feature Branches appeared first on Brett Batie.

I’ve had my blog running on port 80 for years and have finally decided it is time to deprecate HTTP and move everything to a secure SSL connection. This decision was a lot easier to make now that Let’s Encrypt is providing free SSL certificates and has been out of beta since April. I also appreciate that the entire installation can be done via command line and that the certificate can be automatically renewed a month before it expires. Wahoo, no more pesky calendar reminders to tell me to hurry up and buy a new certificate before it expires and manually install it.

With that said, my blog is currently running on CentOS 6 with Apache with vhost files placed in a non-standard directory by DirectAdmin. This means I will have to manually add the certificate information to the vhost file for each host instead of letting Let’s Encrypt do all the work for me. That’s ok though, as I will only have to do this once.

Also, CentOS 6 will throw a little curve ball as it doesn’t have Python 2.7 setup by default and depends on Python 2.6 for yum. So, care will be taken to get them both setup on the machine.

Here are the steps needed to set up Let’s Encrypt. First, we need to set up the IUS repository with the following commands:

wget https://centos6.iuscommunity.org/ius-release.rpm
sudo rpm -Uvh ius-release*.rpm
rm ius-release.rpm

Then, we need to get Python setup:

sudo yum update
sudo yum install centos-release-scl python27 python27-devel python27-pip python27-setuptools python27-virtualenv

Next, we will install pip as that gives us any easy way to install Let’s Encrypt and update it in the future.

sudo easy_install-2.7 pip

Now we will install Let’s Encrypt (which also goes by the name certbot)

sudo pip2.7 install letsencrypt letsencrypt-apache

If you happen to have a very vanilla Apache setup and are running Debian then the following command to generate and install the certificate may magically setup everything for you. This was not the case for me so I didn’t use this step.

sudo certbot --apache -d brett.batie.com

Or, you could try to be more specific about where your config files are located for Apache as I did in the following command. However, at the time of this writing this does not work if your vhost file has more than one vhost in it. So, I didn’t use this step either.

sudo certbot --apache --apache-server-root /etc/httpd/ --apache-vhost-root /usr/local/directadmin/data/users/admin/httpd.conf -d www.brett.batie.com

The route that I actually took was to use the following command which only generates the certificate. This is the webroot approach which differs from the above Apache approach.

sudo certbot certonly --webroot --webroot-path /home/admin/domains/brett.batie.com/public_html/ -d brett.batie.com

This provided output like the following:

IMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at
/etc/letsencrypt/live/brett.batie.com/fullchain.pem. Your cert will
expire on 2016-09-01. To obtain a new or tweaked version of this
certificate in the future, simply run certbot again. To
non-interactively renew *all* of your certificates, run "certbot
renew"
- If you like Certbot, please consider supporting our work by:
Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate
Donating to EFF: https://eff.org/donate-le

Sweet, I have a certificate! Now, I just have to tell Apache to use it. My vhost file is located at /usr/local/directadmin/data/users/admin/httpd.conf and I need to add the following 4 lines to the appropriate vhost in that file.

Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateFile /etc/letsencrypt/live/ryogasp.com/cert.pem
SSLCertificateKeyFile /etc/letsencrypt/live/ryogasp.com/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/ryogasp.com/fullchain.pem

Now do a graceful restart of Apache and we should have the new SSL certificate up and running.

sudo service httpd graceful

You can load the site in your browser to see if it is using the new SSL certificate as well as test it at SSL Labs to see if you received a passing grade.

Since I decided to completely remove http (port 80) from my site I also added the following redirect which could be placed in the appropriate (port 80) vhost (preferable) or in a .htaccess file (less preferred).

Redirect / https://brett.batie.com/

Now, we just need to automate the certificate renewal by adding the following to a cronjob:

@monthly /usr/bin/certbot renew

As you can see there were a few steps involved in this process but overall I found this easier than generating certificate requests, verifying domain ownership, receiving an email with the certificate, needing to find the entire certificate chain and then manually put all the files where they needed to go. The fact that Let’s Encrypt is free and it simplifies the process makes it a no brainer and should help our Internet become a little more secure.

The post Install a Free SSL Certificate (LetsEncrypt) on CentOS with Apache and WordPress appeared first on Brett Batie.

Today I finished putting together a dot file manager. This is a tool that helps manage all of the settings and configurations for multiple computers. I’m currently storing configs and settings for vim, sublime, bash, aliases, custom functions, bin files, thunar, diffuse, kupfer and the like. This tool allows building out a new computer with all of my settings very quickly and also helps me keep multiple computers/servers configs in sync. No more painful copying to usb, emailing or using scp/rsync to manually pull my settings and configs. YEAH!

The installation of this tool couldn’t be easier with a simple one line command:

bash <(wget -nv -O - https://raw.github.com/brettbatie/dotfiles/master/bin/dotm)

That command will download all settings/configs into a dotfiles directory and then ask if symbolic links should be created. The dot file manager tool (called dotm) can be used by anyone to store their custom configs (without being forced to use mine). I hope others find it useful, I know I have.

More detailed instructions about this tool can be viewed on my github account: https://github.com/brettbatie/dotfiles

Below are some features that this tool currently supports. Please feel free to submit suggestions or issues on github.

The post Dot File Manager appeared first on Brett Batie.

I recently had a task where I needed to export a specific table that was in a few hundred different databases. However, mysqldump does not have a way to specify that a specific table should be dumped out of every database. See the supported formats below:

mysqldump [options] db_name [tbl_name ...]
mysqldump [options] --databases db_name ...
mysqldump [options] --all-databases

I was hoping for a command like: mysqldump --all-databases 'table_name'.

mysqldump does have an --ignore-table option but in my case there were too many different tables to list and I didn’t want to go there.

My next thought was to build a quick PHP script that would loop through every database, check if the desired table exists and then mysqldump it. Before I had the chance to start on this approach I realized I could accomplish this with a one line shell command. The approach I took was the following:

mysql -s -N -e "select TABLE_SCHEMA from information_schema.tables where TABLE_NAME='users'" | xargs -I % sh -c 'mysqldump % users | mysql -uUSERNAME -pPASSWORD -hHOST %'

In the example above, I got a list of all databases (TABLE_SCHEMA) that contained a “users” table. I piped that output to xargs which runs mysqldump on the specific database and users table. Last I piped mysqldump to send the output to another server so that it could be imported in the same step.

The post Mysqldump Specific Table From All Databases appeared first on Brett Batie.

I recently had a task where I needed to quickly start up 50 spot instances that all required an Elastic IP (EIP) address. I initially worked out the steps in the web console and determined I needed to accomplish the following:

1. Request 50 spot instances based on an existing AMI
2. Allocate 50 new EIPs
3. Associate each EIP with one of the newly running spot instances.

Requesting 50 spot instances from the web console was quick and painless. However, the EIP allocation and association quickly become tiresome. As the Amazon web console only allows allocating and associating 1 EIP at a time. To repeat the following steps 50 times did not seem like a good use of time: requesting a new EIP, determining the appropriate instance ID to associate with the EIP and then assigning the EIP

Instead I decided to quickly put together a few commands to achieve the goal using the AWS API. First I issued a request for 50 instances with a command like the following

ec2-request-spot-instances ami-1d2b34e5 --price .15 -n50 -s subnet-c1f234ae -t m2.4xlarge --kernel aki-88aa75e1

Of course the above command will need to be modified for each specific case. The specific AMI ID, max bid price, number of instances, subnet, instance type and kernel will all need their respective values modified.

Then I waited until all of the instances were running with a command like the following:

ec2-describe-instances --filter "instance-state-code=16" | grep 'spot' | grep -E '10\.0\.1\.[0-9]{1,3}\s+vpc' | wc -l

The above command lists all of the running instances (instance-stat-code=16), limits it to only spot instances and then limits the output to a specific VPC that has an internal address in the 10.0.1.* range.

Once the above command displayed 50 I was ready to start allocating and associating IP addresses. I accomplished this with a combinations of commands. I needed to use ec2-allocate-address to request a new EIP and ec2-describe-instances to get a list of instances that need an EIP. Last, ec2-associate-address needed to be used to associate the new EIP with a specific instance ID. The command to accomplish this looked like the following:

for((i=0;i<50;i++)); do ec2-associate-address -a `ec2-allocate-address -d vpc | cut -f5` -i `ec2-describe-instances --filter "instance-state-code=16" | grep 'spot' | grep -E 'monitoring-[a-Z]+\s+10\.0\.1' | cut -f2 | head -n1`; done

The above runs the ec2-associate-address command 50 times. It then runs two sub commands one which requests a new EIP address in the vpc (ec2-allocate-address -d vpc) and one which gets the next running spot instance that does not have an EIP (ec2-describe-instances –filter “instance-state-code=16″…).

Last, the new EIPs can be listed with a command like the following:

ec2-describe-instances | grep 'spot' | cut -f17

This worked beautifully for my goal of quickly firing up 50 spot instances and assigning an EIP address. As always, there is room for improvement. If automating something like this on a regular basis, I would suggest taking the one line command and doing more validation on the output of each command. The above assumes that everything is in a good state and that no issues occur in requesting or assigning the EIPs.

Let me know if you find this useful!

The post Automatically Allocate IP Address to AWS Instances appeared first on Brett Batie.

I often join IRC channels where other developers hang out. I’ve found this to be very beneficial in keeping up to speed with changing technologies. I generally stick to two servers Freenode and OFTC. Freenode is by far my favorite as it seems to be the standard server for other developers to join and create channels about their products.

Over the years, I’ve found this extremely beneficial. I can generally get immediate responses about bugs, feature requests and up-coming enhancements in software I’m using. Also, if I need a feature added to a piece of software I can code it up and send it straight to the developers. I do highly recommend all developers participate in IRC channels as a huge amount of quality information is being shared and it’s easy to find someone who is more specialized in a specific software development topic.

That said, I’ve used HydraIRC for the last year and it’s been growing on me. I was previously using mIRC which is also a good product.

Automated Connection To Two Servers

The very first task I had after installing HydraIRC was to set up an automated script to connect to my favorite servers and favorite channels. The scripting piece was quite simple and consisted of the following steps:

1. Open HydraIRC and click Options –> Prefs, then click Scripts
2. In the Command Profiles box type the name “OnStartup” (this is case-sensitive)
3. In the Commands window type the commands to join the server. For me this was:

/server irc.freenode.net:6667
/newserver irc.oftc.net:6667

With those two command in-place HydraIRC will automatically connect to both Freenode and OFTC when I first start the application. Sweet! As a developer doesn’t it always feel good to save a little time?

Join Channels After Connect

Now, we just need to create two more scripts to connect to specific channels after we join the servers. This consists of the following (similar steps):

1. Open HydraIRC and click Options –> Prefs, then click Scripts
2. In the Command Profiles box type the name “irc.freenode.net_OnLoggedIn” (again case-sensitive) or irc.oftc.net_OnLoggedIn. Basically, the format is serverName_OnLoggedIn.
3. In the commands window type:

/join #php
/join #java
/join #html
/join #apache
(and whatever other channels you like)

Identify After Connect But Before Channel Join

With the above in place OFTC was working perfectly but Freenode was telling me:

Cannot join channel – you need to be identified with the service

To resolve this, the command: /msg NickServ identify needs be sent to the server (it’s like logging in).

The trouble is, doing the commands in the following order does not work:

/msg NickServ identify myPass
/join #php
/join #java

This is because HydraIRC does not wait for the response to the identify command but instead immediately runs the next join command. This means HydraIRC tries to join the channels before the server has finished identifying my nick. Darn!

With a little more thought I did come to a solution that has worked very well. Basically, I needed to execute:

/msg NickServ identify myPass
(pause)
/join #php
/join #java

But, wait, HydraIRC does not have a (pause). The work around was to instead use ping which I’ve seen used for pausing in other scripts that do not support a true pause/wait (i.e. Dos Batch Script).

I modified my irc.freenode.net_OnLoggedIn profile to have the following commands and now when I fire up HydraIRC. I automatically connect to my favorite servers, log into nickserv, and join my favorite channels, all while sipping on a little coffee!

/msg nickserv identify myPass
/ping localhost
/ping localhost
/ping localhost
/ping localhost
/ping localhost
/ping localhost
/ping localhost
/ping localhost
/ping localhost
/ping localhost
/ping localhost
/ping localhost
/ping localhost
/ping localhost
/ping localhost
/ping localhost
/ping localhost
/ping localhost
/ping localhost
/ping localhost
/join #php

I love automation!

What other handy scripts do you use in your IRC client? Please do share!

The post HydraIRC / Freenode – Auto Connect, Identify, Join appeared first on Brett Batie.

On occasion I need to run some software tests where Symantec gets in the way. So I put together a simple batch file that will stop and start Symantec. Just add the following commands to a symantec.bat file. Then you can run the commmands symantec start or symantec stop.

if "%1" == "stop" (
        echo "stopping"
	net stop "Symantec Endpoint Protection"
	net stop "Symantec Event Manager"
	net stop "Symantec Settings Manager"
	net stop "Symantec Network Access Control"
	"c:\Program Files\Symantec\Symantec Endpoint Protection\smc.exe" -stop
) else (
	if "%1" == "start" (
		echo "starting"
		net start "Symantec Endpoint Protection"
		net start "Symantec Event Manager"
		net start "Symantec Settings Manager"
		net start "Symantec Network Access Control"
		"c:\Program Files\Symantec\Symantec Endpoint Protection\smc.exe" -start
	) else (
		if "%1" == "stop_ntp" (
			echo "not supported"
		)else(
			echo "usage: symantic start|stop"
		)
	)
)

The post Disable / Enable Symantec Protection via Command Line appeared first on Brett Batie.

For those unfamiliar with Mercurial, it is an awesome Source Control Management (SCM) tool. One of my favorite features of Mercurial is that the repositories are distributed which allows each machine to have a full copy of the project’s history. Being distributed has many advantages such as faster committing, branching, tagging, merging, etc. since it is all done locally. Of course this setup also creates a backup of the repository each time an engineer clones a repository. There are a lot of benefits to using Mercurial, but that is not the focus of this post.

In this article, I am going to discuss how to setup a Mercurial hook to handle checking the syntax of files. Specifically, the hook will be setup to check the syntax of PHP files. This is beneficial as it will prevent users from adding files to Mercurial that are invalid and will keep the repository clean. Better yet, when dealing with a repository for a live website, it will prevent invalid files from ever being added to the live site.

The Pretxnchangegroup Event

Mercurial hooks are programs that Mercurial will execute during specific events. Ideally, a hook such as checking syntax would happen just before a commit is being made (the precommit event). Since Mercurial is distributed, this would require each client to install and setup the hook. This may work for some, but it does require more work and can cause issues if the hook is not setup correctly on each machine.

There is a better solution for environments that have a central repository for everyone to push their changes to. Basically, the hook can be setup on the pretxnchangegroup event. This event is executed just before a changeset (group of commits) is added to a remote repository (during a push).

To setup a hook on the pretxnchangegroup event, the syntax checking will need to build a list of every file that was changed for each changeset and then check the syntax on the latest version of each file. If there is a syntax error, the hook can exit with the appropriate status code to prevent the changesets from being added to the central repository.

When using the pretxnchangegroup event, each machine will be able to commit changes with files that have syntax errors. However, when trying to push the files to the central server, the changesets will be rejected until the syntax errors have been fixed.

In Process vs. External Hooks

With Mercurial, there are two types of hooks: an in-process and an external hook. An in-process hook is a Python module that is loaded at the time the Mercurial starts. An external hook can use any programming language that is supported by the OS.

These are advantages to using both an in-process and an external hook. An external hook is most beneficial when the code is already written in another language or the developers are more familiar with a language other than Python. An in-process hook has some nice advantages as it allows the developer access to the internals of Mercurial. It also gives the ability to display a message to the user when making a change in the repository.

External Hook Using a Shell Script

In order to show how Mercurial hooks work, I have developed both an external and in-process hook to check the syntax of PHP files. Below is the source code for an external hook. This hook is a bash script that I named php_syntax.sh.

#!/usr/local/bin/bash
echo "STARTING PHP SYNTAX CHECK..."
# create a random temp file
temp_file=`/usr/bin/mktemp -t php_syntax_files`
# get all modified files and remove duplicate's
#note: use file_mods,file_adds instead
hg log -r $HG_NODE:tip --template "{files}\n" | sort | uniq > $temp_file
# Walk through each line
#for line in "$temp_file"; do
for line in $(< $temp_file); do
	# Make sure it is a php file
	if [ `echo $line |  grep -Ei ".+\.(php)|(php4)|(php5)$"` ]
	then
		# create a random temp file
		php_file=`/usr/bin/mktemp -t php_syntax_check`
		# save the contents of this file (latest commit) to the temp file
		hg cat -r tip $line > $php_file
		# check the syntax
		php_syntax_output=`/usr/local/bin/php -l -d display_errors=1 -d error_reporting=4 -d html_errors=0 < $php_file`;
		# remove the temp file
		rm -f $php_file;
		test_syntax=`echo $php_syntax_output | grep "Parse error"`
		if [ "$test_syntax" ];then
			exit 1;
		fi
	fi
done
rm -f "$temp_file"

The above code will check the latest version of each file that is being changed when pushing to the server. It will only check files that have an extension of PHP, PHP4 or PHP5. The content of each file that is being pushed to the server is then stored in a temporary file and passed to PHP to check the syntax. If the syntax check fails, the program returns a 1 for failure which causes the entire push to fail so that no changes are pushed to the server. If there are no syntax errors, the hook exits normally and continues to push the files to the server.

In order to install the above hook in Mercurial, simply add the following 2 lines to the .hgrc and/or the hgweb.config file.

[hooks]
pretxnchangegroup.syntax_check = /usr/home/mercurial/php_syntax.sh

Of course the path in the above line needs to be updated to where the bash script was saved. The bash script will most likely need to be updated to contain the correct paths as well.

With all of the above in place the following message will be displayed to the user when trying to push a file that has a syntax error:

running hook pretxnchangegroup.syntax_check: /usr/home/code.softwareprojects.com/php_syntax.sh
transaction abort!
rollback completed
abort: pretxnchangegroup.syntax_check hook exited with status 127
warning: commit.autopush hook exited with status 1

In-Process Hook Using Python

The major flaw with using the above shell script is it does not allow us to display a nice informative error to the user when their push fails due to a syntax error. This is one advantage of using a Python in-process hook instead. I have written very similar logic in Python which can be seen below:

import subprocess,os,re
import os.path
from mercurial import ui
from random import randrange
from time import time
def check(ui, repo, hooktype, node, **kwargs):
    #initialize variables
    error = ""
    fileSet = set()
    # Loop through each changeset being added to the repository
    for change_id in xrange(repo[node].rev(), len(repo)):
        # Loop through each file for the current changeset
        for currentFile in repo[change_id].files():
            # Only Check PHP Files
            if re.match('.*\.(php)|(php4)|(php5)',currentFile):
                # Build a unique list of each file that has changed
                fileSet.add(currentFile)
    # Loop through each file that has changed
    for currentFile in fileSet:
        # Grab the latest version of the current file in the changeset
        ctx = repo['tip']
        # Do not check the file if it is being deleted
        if currentFile not in ctx:
            continue;
        # Generate a unique temporary file name using random number and timestamp
        temp_file = '/tmp/php_syntax_check.%s%s' % (randrange(0,100000),int(time()))
        # Open the temp file for writing
        f = open(temp_file,'w')
        # Get the file context
        fctx = ctx[currentFile]
        # Save the contents of the current file to the temp file
        f.write(fctx.data())
        # Close the temp file
        f.close()
        # Check the syntax of the current/temp file
        proc = subprocess.Popen('/usr/local/bin/php-cgi -l -d display_errors=1 -d error_reporting=4 -d html_errors=0 < %s' % temp_file, shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
        # Retrieve the output of the syntax check
        out,err = proc.communicate()
        # Check for syntax errors and save them
        if 'Parse error' in out:
            error += "%s%s\n" % (out,currentFile)

        os.unlink(temp_file);
    # Check if an error occured in any of the files that were changed
    if error != "":
        # Display a message to the user about each file that contained a syntax error
        ui.warn("******************************************************" +
            error +
            "******************************************************\n")
        # Reject the changesets
        return 1
    # Accept the changesets
    return 0

This code is very similar in functionality to the shell script. It first builds a list of all of the files being pushed that have a PHP, PHP4 or PHP5 extension. Then it obtains the contents of each file that is being pushed and stores each file in a random temporary file. It checks the syntax of each file and then cancels the push if there is one or more files with invalid syntax.

Since this is an in-process hook, it is able to display a nice message to the user about why the push was not allowed. This hook is also set up to check every single file and display a message about every file that has a syntax error. This allows the hook to display a message to the user such as the following:

******************************************************
Parse error: syntax error, unexpected T_ECHO in - on line 3
Errors parsing -
afile_test.php
Parse error: syntax error, unexpected '@' in - on line 15
Errors parsing -
anotherfile_test.php
******************************************************

In order to setup this hook with Mercurial, save the above Python code in a file that is on the PYTHONPATH. Then add the following two lines of code to the .hgrc and/or the hgweb.config file.

[hooks]
pretxnchangegroup.syntax_check = python:php_syntax.check

It is important to point out that the text on the right half of the equals sign tells Mercurial what to load. In this example, it says use Python, look for a file named php_syntax.py and call the function check.

Also, Mercurial will need to be restarted after setting up the above hook or after each time the hook is modified. This is because the in-process hook is loaded when Mercurial/Python is first started.

Conclusion

Mercurial is a great SCM tool and can be very powerful when combined with either in-process or external hooks. In-process hooks provide much more control and are the preferred method in most cases. The examples above are just an introduction to Mercurial hooks and they can easily be modified for specific environments or checking the syntax of other languages.

Please leave a comment if you have found this code useful or share your experiences with Merucial and hooks.

The post Mercurial Hook for Syntax Checking (PHP) appeared first on Brett Batie.

I recently had a project to setup an Instant Messenger Robot for Windows Live Messenger. A IM robot can have many purposes such as:

• Keeping track of when contacts are online/offline and when they were last seen.
• Broadcasting a message to all contacts.
• Automatically answering common questions.
• Notifying contacts about new events. A newer site http://notify.me has a nice IM Robot that notifies you when a RSS feed is updated. This works well in conjuction with sites like craigslist.
• Keeping track of code snippets
• Checking the weather
• Checking server status

An IM robot can be setup to automate just about any task.

What IM Library to Use

Setting up a IM robot can be a bit of work especially if starting from scratch. There are a lot of libraries out there that can be used to help simplify the process. The trouble is a lot of libraries are not kept up to date and fail to work as IM protocols change.

I did some digging and found a library that would provide a good foundation to build a IM Robot that can do just about anything. I saw implementations in PHP, C, Java, Perl and Python. After some testing I concluded the Java MSN Library would be a very good fit.

How To Use It

Using this library with java is pretty straight forward. First, the library must be added to the classpath. The step to take to complete this will depend on how your developing your java code. The most basic method to add a library to your classpath is to do this at run time with a command such as:

java -classpath MyLibrary.jar MyPackage.MyClass

A better approach would be to setup the classpath in a manifest file. The manifest file is then placed inside the jar file and tells the executable jar where to look for the libraries. This manifest file should look something like the following (note the class-path on line 5):

Manifest-Version: 1.0
Ant-Version: Apache Ant 1.7.1
Created-By: 14.3-b01 (Sun Microsystems Inc.)
Main-Class: imstatus.Main
Class-Path: lib/jml-1.0b4-full.jar lib/httpcore-4.0.1.jar lib/mysql-co
 nnector-java-5.1.6-bin.jar
X-COMMENT: Main-Class will be added automatically by build

This is setup so that the 3 required libraries are in the lib folder. These 3 libraries are needed for setting up an IM robot and can be downloaded from the following locations:

• jml-1.0b4-full.jar
• httpcore-4.0.1.jar
• mysql-connector-java-5.1.6-bin.jar

Now that the libraries are setup we can begin to use them.

Developing the IM Robot Code

There are a few examples of using the Java MSN Library on the main page. However, they are a tad confusing as it creates a new BasicMessenger class. This is confusing as the library already has a BasicMessenger class which is abstract. The library also has a SimpleMessenger class which is a subclass of BasicMessenger. This class appears to be the correct implementation that we would want to use to create a new IM Robot. However, the original authors made the constructor protected so that we cannot instantiate the class outside of the original package. Since we want a simple way to create an IM Robot I have modified the original source code to have a public constructor for the SimpleMessenger class. This new package can be downloaded from our server.

With this new package we can very easily create a new IM Robot with the following two lines of code (make sure to replace yourLogin and yourPassword):

SimpleMessenger messenger = new SimpleMessenger(Email.parseStr("yourLogin@msn.com"), "yourPassword");
messenger.login();

With that code in our main funtion we can run it and test that the Robot automatically logs into Windows Live Messenger.

Of course, that code just logs the Robot into Windows Live Messenger. The next step is to setup the robot to do something interesting. This is one feature that is very nice about the Java MSN Library as it has listeners for many different events. For example we can detect when the robot has finished logging in with the following:

messenger.addListener(new MsnAdapter() {
	// Setup the login completed event
	@Override
	public void loginCompleted(MsnMessenger messenger) {
		MsnOwner owner = messenger.getOwner();
		owner.setInitStatus(MsnUserStatus.ONLINE);
		owner.setStatus(MsnUserStatus.ONLINE);
		// Setup the contact list event
		messenger.addContactListListener(new ContactListAdapter());
	}
});

Then we can take this a step further and detect when a status changes for one of the robots contacts with something like the following:

messenger.addListener(new MsnAdapter() {
	// Setup the login completed event
	@Override
	public void loginCompleted(MsnMessenger messenger) {
		MsnOwner owner = messenger.getOwner();
		owner.setInitStatus(MsnUserStatus.ONLINE);
		owner.setStatus(MsnUserStatus.ONLINE);
		// Setup the contact list event
		messenger.addContactListListener(new ContactListAdapter());
	}
});

The above code will detect when the robot has finished logging in and then setup a new listener to detect when a contacts status has changed. The new listener invokes the ContactListAdapter class when a status has changed. This contactListAdapter class is setup as followes:

class ContactListAdapter extends MsnContactListAdapter {
	@Override
	public void contactStatusChanged(MsnMessenger messenger, MsnContact contact) {
		System.out.println(contact.getEmail()+" is currently "+contact.getStatus());
		// Can add code here to store the status in a database
	}
}

We can still take this a step further and setup the robot to handle automatically adding contacts when a contact requests it. This logic can be added to the ContactListAdapter class with something like the following:

class ContactListAdapter extends MsnContactListAdapter {
	@Override
	public void contactListSyncCompleted(MsnMessenger messenger) {
			MsnContact[] contacts = messenger.getContactList().getContactsInList(MsnList.AL);
			for (int i = 0; i < contacts.length; i++) {
				contactStatusChanged(messenger,contacts[i]);
			}
	}
	@Override
	public void contactAddedMe(MsnMessenger messenger, MsnContact contact) {
		messenger.addFriend(contact.getEmail(), contact.getDisplayName());
	}
	@Override
	public void contactAddedMe(MsnMessenger messenger, MsnContactPending[] pending){
		for(int i=0; i<pending.length; i++){
			messenger.addFriend(pending[i].getEmail(), pending[i].getDisplayName());
		}
	}
	@Override
	public void contactStatusChanged(MsnMessenger messenger, MsnContact contact) {
		System.out.println(contact.getEmail()+" is currently "+contact.getStatus());
		// Can add code here to store the status in a database
	}
}

There you have it! Put all of the above code together and you will have a robot that knows how to automatically add contacts and keep track of when a contact’s status changes.

The post Java Live Messenger (MSN) Robot appeared first on Brett Batie.

I use the application UltraMon to help manage my multiple monitor setup. Overall this application is awesome as it makes moving applications between monitors a breeze and supports a separate task bar on each monitor, among other things.

However, I have had this issue for a while where UltraMon will not move applications between monitors after a Remote Desktop Connection has been established, instead UltraMon acts as if there is only one monitor.

In the past the only solution I had for this issue was to restart my computer. This is not an ideal solution for me as I’m often multi-tasking and running many applications at the same time.

In order to reboot I have to close down each application, save my work, reboot, and then start up every application again after the reboot. This is not a major amount of time but it does add up if I have to do it on a regular basis. Plus, I am one who likes to optimize everything to achieve as much efficiency as humanly possible in a given day.

So, I spent a few minutes and fiddled with UltraMon and found a way to fix this RDP flaw without requiring a reboot. The steps are as follows:

1. Close UltraMon
2. Right click on your desktop and select Screen Resolution
3. Disable the monitor that the application cannot be moved to and click apply (screenshot on right). Repeat for all monitors that are suffering from this issue.
4. Start UltraMon
5. Enable all monitors that were disabled in step 3.

After completing the above steps UltraMon will be as good as new.

I have only tested this on Windows 7 so let me know if this works on other Windows versions as well.

Anyone up for automating the above steps? If I get a break I might try and tackle it.

The post UltraMon Breaks After Remote Desktop Connection (RDP) appeared first on Brett Batie.