Skip to content

Day to Day Apps of a Web Developer

2010 July 6
by Tom Schlick

Any good developer has a set of applications that helps them get their job done faster and better. When developing on a mac this is no exception. There are tons of high quality applications from both big name companies to small independent companies. This is a list of some of the applications I find myself using each and every day.

Coda

Out of everything in my arsenal I really do use coda the most. It is the jack of all trades editor from the great people over at Panic. It includes a ton of features such as built in FTP, Terminal, CSS Editor, and Reference Books. The best part about Coda is that it’s not bloated. Panic has done an awesome job with coda and I can’t wait to see what they come out with in the next major release. I have tried many other clients including Espresso & TextMate (I do use TextMate for other things) but I always come back to Coda. Coda is $99.00 and is well worth the purchase.

Sequel Pro

sequel proSequel Pro is a MySQL database management interface. Think PhpMyAdmin but more powerful and desktop based. Sequel Pro allows you to view, create, and manage your databases without having to go through the hassle of using a command line interface. It is an active open source project which means its free to download and use. Once you start using Sequel Pro it will be hard to go back to anything else. (Note: I used to use Navicat but it sucked for mac and sequel pro seems a lot better at not sucking.)

Evernote

Evernote is a simple but amazing application. If you are not using it already you should be. Evernote is your digital brain. You can use it to store everything from code snippets to reciepts. I use it all the time to take picture of whiteboard sessions with my phone and send them to evernote where they are scanned and indexed making them searchable.

Fluid

Fluid is  SSB (site specific browser) application for the mac. Similar to Mozilla’s Prizm, it allows you to create a desktop application from a web app. I use SSB’s for my personal gmail account, work’s google apps account, lighthouse ticket tracker, TeuxDeux and google voice. I can have these windows open (or hidden) all the time and when something needs to get my attention such as a new email I get a Dock badge! This makes it a lot easier to use gmail’s awesomeness 100% of the time without having to use something like MailPlane or the native Mail app.

Billings

Billings is an invoice tracking application. It makes it easy to track your time, send out estimates / invoices, and helps account for every last penny a client owes you. It is one of the most elegant I have found and provides some very nice invoice templates by default. I know there are some web based ones out there such as FreshBooks, but I prefer billings.

Transmit

Transmit is an awesome FTP client from the same great people that make Coda. It is elegant and features FTP, SFTP, Amazon S3 and many other integrations. It is a rock solid client and the recent refresh made it even more powerful and easy to use. FYI: The core of transmit also powers Coda’s FTP integration. Transmit is $34 and is also well worth the money. (Plus they have a pretty nice truck icon so you can’t go wrong with Transmit).

I will add anything new I come across to this list. If you have any suggestions of things I should try out let me know.

If you’re smart, don’t use Smarty

2010 June 10
by Tom Schlick

Today in the world of web frameworks people are looking for the perfect marriage of technology to scale their applications & provide rapid development. Through this time of transition some really great advancements have come out such as CodeIgniter, Ruby on Rails, & jQuery. Unfortunately, some of the things that are popular now seem to be good but can actually hurt your application. I’m talking about template engines in PHP.

Why They Are Bad

Template languages like Smarty are essentially another programming language built on top of PHP. This is a problem because php is what we call an interpreted language which means every time you load the page it is parsed on the fly and is outputted. When you add a template language on top of this the template language has to be interpreted, converted to php and then interpreted as php and outputted. This doubles the amount of work that the cpu has to do to return the page the user requested.

At one point in an application I’ve been working on, I noticed that smarty was accounting for 60% of page load time. The page load time was still under a second but thats a huge amount of the process just for smarty to convert to php.

What About Designers!?

Using a template language just because you are working with designers is a poor excuse. Those designers could just as easily learn PHP Shorthand as they could something link Smarty. By teaching your designers small amounts of PHP, your giving them the knowledge to help with other areas of your application without having to learn something new.

When It’s Appropriate

Sometimes a template language is the perfect solution. For instance if you were creating a CMS application where your users would have to edit template code you might want to use a template language. It would allow you to restrict which functions could be executed on the views side so that your application would be more secure. This is ok for CMS type apps like WordPress and Expression Engine, but its usually something you dont need when your app is just something that your company will be editing.

For use with codeigniter views, I have my own template library built and extended off of the initial work of Phil Sturgeon. You can take a look at his library here http://github.com/philsturgeon/codeigniter-template and I may release mine in the future.

Using MongoDB for CodeIgniter Logs

2010 May 18

Anyone who has ever worked in a production environment knows that your users will find errors you have not even dreamed of. They will find your broken links, they will find your missing files, and yes they will find every database connectivity issue you hoped would never occur. Thankfully we are all great developers and sysadmins so we log everything we possibly can to find and remove these errors.

This is great at first but after a while log files become enormous and eat up lots of disk space. The problem multiplies when you start getting into a clustered environment (more than 1 server). You now have to read & maintain logs on 2+ machines which will most likely lead to neglecting your error fixing duties. Fortunately MongoDB recently hit the scene.

MongoDB

MongoDB is a scalable, high-performance, open source, document-oriented database. It’s ability to accept huge amounts of data very quickly make it perfect for application logging. It has built in support for auto-sharding & replication so when your application takes off mongodb will scale with you. It uses a JSON based storage system meaning you can give the database an object (from any programming language with support) and when you pull it back out of the database it will be the exact same as when you put it in. No conversion, no hassle, no bullshit.

Capped Collections

Mongo uses things called Collections which are essentially tables in mysql. The main difference is these collections are schemaless. I can have 10 fields in one document (row) and 500 in another and they will play nice inside the collection. This allows a huge amount of flexibility to the developer.

These collections also have the ability to be “Capped”. This means I can set a max document count of 5000 and only the most recent 5000 documents will be kept. The older documents are deleted as new ones come in. This is awesome for logging because you will never have to rotate your logs in fear that they will become too large and occupy all of your file system space.

Use this command to cap a collection (in a mongo shell):

db.createCollection("my_collection", {capped:true, size:5000})

More Information on Capped Collections

Use in CodeIgniter

By default CodeIgniter writes to log files in /system/logs/ . I have created a class that overwrites that default functionality and sends all logs to a mongo db collection. Adding this library to all of your servers will allow all of those servers to write to the same mongo collection. I have also added some more data to the logs that is helpful in a clustered environment such as the server name, server ip, request uri, and a few more. Just place the MY_Log.php in your application/libraries directory and codeigniter should handle the rest.

You can view and fork the class on Github:
http://github.com/trs21219/codeigniter-mongo-logs/

Feel free to modify data inserted to fit your specific needs. If you find any bugs or have suggestions you can comment below or raise an issue here.

Avoiding Database Overload with Memcached

2010 March 8

Overview

Probably the biggest challenge for a newly popular site these days is scalability. The most common point of failure in applications seems to always be the database. These days our applications are totally reliant on some sort of relational database to store the information for our website’s content. Each and every page load brings many queries that read or insert information into this database all while rendering the web page in a timely manner. This isn’t so much a problem for your Mom & Pop business, but when your website starts to get some real traffic pointed towards it,  your underlying architecture that you thought was impervious to anything will crumble before your eyes. The solution? Stop making so many queries to your database.

Caching

Caching is nothing new. Servers have been caching content for many years quite successfully. There are many different ways you can cache data in your application but right now we will just be talking about using Memcached. Memcached is a high-performance, distributed memory object caching system. So what does this mean? Basically it can store any kind of value that you would normally store in your database and retrieve it much much faster than your database can.

Memcached Flow

When you implement memcached you use it along side of your database. Neither takes the place of each other, memcached just takes some of the load off of your database server after your database server has previously done the grunt work. It works on a key pair system. Meaning it has no tables, rows, columns etc. You give memcached a name and pass it data and it stores that data just as you passed to it. You can pass it an object, array, binary, etc and it will output the same way when you go to retrieve it.

So how does this all work with the database? First, you add code that checks to see if the memcached object (blogpost-45 for our example) exists before it checks the database for the data. If it does you return that data and never touch the DB.  If the memcached object does not exist  you retrieve data from your database, take the array that is passed back and store it in memcached with the key of “blogpost-45″. So the next time you try to get the data for blogpost-45 it will return from memcached and not your database. This is where the load savings occurs.

So what happens when I want to change the data? When you change the data in your database you should delete the key in memcached. You shouldn’t re-add the data after you delete it, let the select query do that to avoid complications.

CodeIgniter + Memcached

I have created a CodeIgniter Library that can help you get a jump start on your integration with memcached, its available on my github page and will be updated when I get time.

http://github.com/trs21219/memcached-library