I really hope this adds a ton of value to new or established businesses looking for more efficiencies in their web-contact-to-deal-close processes.

The plugin installs just like any other Wordpress plugin. It should be pretty intuitive to anyone that has even limited experience administrating a Wordpress site. The plugin can be downloaded from Wordpress or at my repo on github.

Fat Free CRM is a great customer relationship manager (CRM) I’ve been using for a little while now instead of Highrise. I used Highrise for a little while before I grew frustrated by its hosting costs and lack of features. The guys at 37signals don’t seem to update it very often either.

For the rails project, I forked the repository and made a few minor changes like adding access via an API key. I also added a few usability options in the view codes to make integration with the plugin seamless.

For new businesses that are just implementing a CRM solution, I’d be happy to host the CRM application on my servers for a nominal cost. Feel free to contact me for more details. (hint, the contact form is an example of the plugin in action )

To use the plugin and CRM together, just follow these simple instructions:

1. Download or clone the CRM from my github repo. Install on my servers (contact me for pricing) or on your own
2. Download and install the fat-free-crm-lead plugin either from Wordpress or my github repo
3. Configure the plugin with the URL of your CRM and an API token (details are provided in the admin interface of the plugin)
4. Watch the leads come rolling in and enjoy not having to copy and paste from emails any longer

Hopefully, this is really easy. If you run into any problems or have feature requests, please feel free to contact me.

====UPDATE====

The plugin has been accepted into the WP plugin directory. Take a look at the fat-free-crm-lead-form at Wordpress.

There Are No HTML/CSS Programmers

Markup languages are not programming languages. They can’t do math and neither can be written to create more of their own code. I’ve met a few people in my years of experience who have described themselves as HTML and/or CSS programmers. These developers have usually turned out to be disasters on my team. Overwriting changes on production servers, bloated markup and wonky css are just a few of the frustrations experienced with these lower level developers.

I don’t mean to disrespect other developers at all. I consider it a starting point for developers to get a strong command for html markup. Like good writers, I require anyone working on my sites to use only the markup required and take everything else away. It makes for a good looking site that is quick to load in the browser and simple to make updates to six months later.

HTML and CSS are also languages that developers and designers can unite over. Both designers and developers should have a strong sense of how to create good markup and style since it is one of the few things that overlap each others’ talents. So, while CSS and HTML are markup languages, they are not programming languages and both designers and developers should be rock solid on both before moving on to more advanced languages.

Just Making It Work Is Dumb

So many times I meet developers who have created superfluous html markup or javascript because they’ve hacked together a solution. A hacked solution is a bad solution. When we come back to that solution in six months, the process for arriving at that solution has long been forgotten and we spend way too much extra time just trying to figure out what we were thinking when we created the hack.

It should work, but it should work in a way that is not hacked together and makes sense now … and in six months when we need to make edits.

The Best Solution Is The Simplest Solution

This may be redundant, but I think the approach to software design as an engineer is very personal. Just like I don’t like a lot of extraneous markup, I also like to limit the number of moving parts in an application. Keeping as much logic in a single language for example helps to create an overall simplicity to the project.

Take, for example, an application written in Ruby, using MySQL and Apache for data storage and web serving respectively. Say the application uses a lot of stored procedures or triggers in MySQL for some data processing. This could be done in the ruby application language, but for whatever reason, it was written in the MySQL framework. Now say the business has a compelling reason to leave MySQL and move to another RDMS. If the data processing had been written in Ruby instead of MySQL, then the port would be relatively simple and quarantined to only the database classes. Instead, new code must be written in the new RDMS language.

This example is fairly trivial but illustrates a point that I like to keep the engineering of an application simple so it can be nimble and respond to changes in business practices and usability.

Source Control is a Must

I’ve led development on projects a few times and I’m always disappointed when other developers look at me blankly when I mention git or svn for source code management. For developers, their use is fairly intuitive. For projects, their use is a requirement. Source control makes sure that a group of developers and designers on a team do not overwrite each others changes and it provides a means to revert bad changes that inevitably make it into a staging or production environment. It’s also a great accountability tool to see which developers are contributing most to the source code.

Designers I’ve worked with often pick up how to use git or svn pretty quickly limiting disruptions in productivity and creating a secure, backed up, developing environment.

Beyond the benefits of automatic backup and accountability, source control also offers an easy way to scale web applications. When your site gets to the point that one server isn’t enough, source control allows for pushing changes in source code over multiple servers quickly.

www.precisiontext.com

Precision Text, a brand new company with only an idea, needed to hire a solid web developer to bring their new business idea to life.  After a few conversations, we both agreed that the best way to bring this idea to the marketplace would be to use the Ruby on Rails framework and a solid text messaging API.

The application allows for business owners to gather a list of their customer’s cell phone numbers. The business can then send out a message to these customers alerting them of new deals or special offers. The response rate has been high and the utility to the business has been huge.

I built the application from scratch and within a month was comfortable with a deployment in a beta stage. Using this beta deployment, the founders put the application through some of their own testing and determined they were comfortable selling the product as it was. Within a month of deployment, they had already secured 10 contracts!

TDD

This was the first app that I built in a completely test driven development (TDD) coding style. I have had some experience with unit and functional testing, but I have never actually built an application from scratch using TDD. Even though the processes was new, I still found the coding process to be much more efficient. I will be building apps using only TDD from now on.

Daemonized Processes / Time Zones

Sometimes businesses need to send messages later than when they’re at the computer. Rather than set up a complicated cron job or some other solution, I created a daemon within the application that actively listens for queued messages and sends them according to the time the end user requested.

Implicit in the scheduling is getting their time zone right. From a usability perspective, it is much easier not to do time math when queueing a job. A restaurant owner in Colorado shouldn’t have to compute the difference of her time zone to where the server is located. Neither would she want a message to accidently go out an hour early.

For usability and business rapport reasons, I implemented automatic adjustments for the time zone the user is in. To the user, it is seamless and easy to manage.

Given the budget of next to nothing and the relatively small size of the office, I decided it was best to proceed with a Linux based Samba server. Although their office is 100% Microsoft (a mix of XP and Vista machines), Linux would be a great light weight solution. The added benefit was we re-purposed an ancient workstation (circa 1996) to run the Samba server so no new hardware was purchased and we prevented another machine from polluting a land fill.

We created three shared drives for the business.

1. A share everyone in the office could access
2. A share only the executive could access
3. A share for the exclusive purpose of backing up everyone’s workstation

I simply installed Centos 5.2 distribution on the old workstation, created three distinct user accounts and group permissions, enabled the samba service, and locked down access through iptables firewall.

Creating a secure, readable, smb.conf file was really important to me. Not only for readability but also because I won’t be supporting this server after installation. Any other administrator should be able to walk into the office and quickly & clearly see how to make edits for upgrades or changes.

The smb.conf file:

#smb.conf
 
[global]
	#set up what the end user would see on their desktop
	workgroup = H4LSharedFiles
	server string = common files for H4L
 
	#general user perms
	security = user
	passdb backend = tdbsam
 
	#printing support
	load printers = no
        printing = bsd
        printcap name = /dev/null
        show add printer wizard = no
        disable spools = yes
 
[AllSharedFiles]
	comment = Files for everyone to share
	path = /sambashares/allAccess
	writeable = yes
	browseable = yes
	guest ok = yes
	write list = +allemployees
 
[Backup]
	comment = Files to back up everyone's computer
	path = /sambashares/backups
	writeable = yes
	browseable = yes
	guest ok = yes
	write list = +allemployees
 
[AdminOnly]
	comment = Access for sensitive files
	path = /sambashares/admins
	writeable = yes
	browseable = yes
	guest ok = no
	write list = +administrators

A creative design company called Old Green Pickup began its transition to using Ruby on Rails as its primary development platform. Since this was one of only a few projects Old Green Pickup had used Ruby on Rails with, the President of Old Green Pickup hired Bryce to take over the production and make sure everything was running smoothly. This is the first project in a new relationship we wish to cultivate.

I was brought in as an associate developer to the AAA project to make sure it was completed on time with high quality. I resided in Ohio for a period of three weeks to develop alongside the lead developer.

During that time, I helped with formalizing the architectural plan of the application, offered assistance in deployment and led development projects for several areas of the application.

One fundamental role in the project was to create an online market place and integrate it with an existing SQL Server database. I also created a robust shopping cart and checkout procedure. I also built a web service to manage users in the shopping cart.

The main application was build using a Flash frontend and required data called from the Rails backend. I built a background RESTful interface and helped the lead designer integrate it with Flash.

Integration with other AAA services was also required. I built the front end code to a GIS service, a system for sending emails, and a mechanism to create, store and display unique travel products.

I returned home and continued working on the project through their successful launch in early May of 2008.

The music festival had just had a falling out with their core team of developers. They had an application with bugs and no support. Bryce was hired to become familiar with the code, do testing and bring the project up to production status.

This included re-factoring and building new code into the existing framework.

I also fixed their ailing e-commerce solution. The festival was unable to sell tickets to their events until I fixed that part of the code base

We developed a good relationship with the music festival by sharing frequent progress reports and handling new bugs quickly.

Its programming includes an interface to build medical surveys and host a variety of physician specific questionnaires. It resembles a SurveyMonkey like solution specifically tailored to the security and confidentiality concerns of the medical profession.

I developed all the code including user management and payment processing.

A “Web 2.0″ application designed as an all in one solution for medical research.

Physicians can design studies, write surveys and collaborate with peers. A unique challenge with this project was patient confidentiality. I built a secure system focused on patient anonymity.

The project also required a regular, non-intrusive, payment processing mechanism which I implemented.

A community area allows physicians to discuss emerging research and develop new studies. Includes a regularly updated blog.