Archive for January, 2010

Seeking trial users

Friday, January 15th, 2010


open image from junctionjimage.com

As you will be aware, we are very excited about our self serve email application launching this week.  It’s essentially a do it yourself system where you add your email list, choose a template, add content and send! It has some tracking too so you can see open rates and clicks.

W are pricing it at $5 per campaign, plus $0.01 per email sent. So if you’ve got 1,000 emails to send, it’ll cost you $15.

We’re not going to be charging for a few months as we are looking to invite people to use the system for free to help us test it out and make sure it’s running smoothly. We successfully sent out 600 emails the other day for a client, and while it works beautifully, there are a few things we need to do to make it more usable.

If you are interested in using the system, I have taken down the sign up link so please email russ @ junctionj.com and I’ll give you the secret sign up link!

image copyright Jo Smith – junctionjimage.com

checking out images on the blog

Thursday, January 14th, 2010

blah blah blah junctionjimage.com

Using google docs to compare documents

Thursday, January 7th, 2010

I had an issue today that led me to learn something new and useful.

While working on the self serve app, I discovered in testing that the import function was not working. My developer was offline and I thought I’d take a look at it. I am not a coder, and have no grid for php, but I had something to go on. I had origionally outsourced the development of the app to Charthouse, and they had completed the code work, but it wasn’t designed. So I know that when we got the code, the import component worked. In adding the design or something, perhaps the code had been mistakenly broken.

I thought I’d compare the two files. So I printed both files off to see if I could make any sense of them, see a glaring error. I quickly realized that doing a manual check like that would take ages and be prone to error. So after quick research online, I discovered that google docs can do it simply!

Here’s how to compare any two documents. Create a new google doc. Copy and paste the code (or text) into the new doc. Save it. Then copy the text from the file you want to compare, and save again. Then go to file > see revision history. Check the 2 boxes next to the 2 recent revisions, and click the ‘compare checked’ link. Google docs shows you the differences!

How easy is that! Probably works for spreadies too, but I didn’t try that.

SVN

Monday, January 4th, 2010

While we set up and tested we used sub version – SVN – to track changes. When you have a number of developers in different locations as we do, it’s fundamental that you use something to track who has done what, and what files have been updated. SVN is just that. We set up a development environment (dev env) and put all the source files there under SVN. Then each developer and project manager checks out the files, and after they have worked on them, updates the system with their changes.

As the team leader and project manager, I am not that technical, especially when it comes to using command line prompts. Fortunately we have a excellent and knowledgeable server administrator who took me through the basics. This post is by no means a tutorial on svn, but it’ll give you a grasp of the process.

My server admin set up the dev env, putting the files into SVN.

I SSH into the server, then change my user to root using the sudo su – command.

Files are checked out from the server using svn co – svn check out.

This downloads the files to your local machine, so you can make changes. Then when the files are saved, you need to add this back to your local svn repository – this is the bit I couldn’t get for ages…. you download from the server, make changes to your local files, then add the files back to your local respository using the command svn ci – ci standing for check in.

When you use svn ci, it brings in the text editor to make a note of the changes – this gives a log essentially. Exit and save the text editor, then it uploads the files to your local repository.

Finally, update the server with the changes by svn up – svn update, and it gives a revision number of you update. You may need to watch out for the permissions on the file – the update may not put the correct permissions, so watch out for the need for a chown – talk to your server guy about that.

It helps to have two command prompt windows open – I am on Mac OSX so I’m using Terminal. I have one window open for the server – checking out and checking in – and one window for the local checking in.