It’s been an astounding six years since a web-designer friend and I began work on our first product. Our goal was to design a software-as-a-service product that would grow into a business which could support us both financially. We ran individual web design/development companies but often worked together, and had become good friends very quickly. We took a product I had developed for myself and started a new version. It was codenamed Kiwi.

Kiwi came together quickly because of our excitement for what it represented: the possibility of having complete control over our product. Clients could never dictate what limitations we had to work around and there was no red-tape from legal and I.T. teams. After six months of highly motivated work it was stable enough to begin using internally, and shortly after we made agreements allowing local companies to use the service during development. Interested company contacts were piling up fast – from health insurance agencies to sports product manufacturers.

One woman even overheard us during a lunch meeting and was so interested she gave us her card. We we’re excited. We felt like we were in complete control. We had outlined a set of features that had to be present, and were perfectly clear to each other about what had to wait.

Soon we had too much client work – several large deadlines for some extremely demanding corporate clients drew our attention away. I’ll have to be honest and say my partner in this product began dropping the ball on his portion a lot more than I was, but I figured it was a temporary saturation of work.

Lesson #1: Don’t worry about losing focus on a side project. Your budding idea needs you to be your best, and if you’re putting in too many hours or neglecting paying-work, you’re going to suffer. If you return and can still feel as motivated about the idea, you know it’s the right project.

Six months went by before we were able to get back to our product. Meetings resumed, excitement levels came back, and we were sure launch day was approaching. However, I was still noticing delays from my partner that didn’t make sense to me. I thought I’m able to get my work done and I’m working all day, teaching at night, and I have two kids as well, so why is he not getting his work done? His schedule is less busy than mine!

I’m the kind of guy that when I have a product I want to make, I run with it until it’s made. I may lose steam or take a break but my partner would go weeks without doing any work outside of the office. He’d just relax at home. Deadlines were being missed. I’d keep asking when tasks would be done, I’d ask if they could be done by a specific date and they rarely were. He was the best at what he did so I was too afraid to make an issue of out of it.

Lesson #2: You need to be open to your partners scheduling decisions as long as they can consistently keep up with the progress of others and make their deadlines.

Lesson #3: The moment you feel something isn’t working, bring it up. Don’t settle for something if you’re not happy.

We consulted with several investors for advice on getting funding to complete the project. We felt that this could be the solution to our lack-of-time issue. We ultimately decided that it wasn’t smart (thank god) but we did add three new members to our baby company.

Three former coworkers and friends of my partner came on board. I didn’t know them until just prior to their joining. They had once built a software company from the ground up, sold it for lots of money to a large corporation and had the experience, resources, and connections to help us create a spectacular company.

We all had mostly-weekly meetings in our office for a year. A lot of great ideas, a lot of debates that changed how we thought about our product and its potential.

Lesson #4: If anyone shows up at the next meeting having not done a single bit of work, and has no good excuse, it’s time to figure out why they’re on board.

I could have not wasted an entire year.

These guys were clearly smart, clearly experienced. They just weren’t right for this product. Two of them were programmers but had no experience programming for the web. They had no exposure to our target market and knew only what we told them about our competition. They all had other endeavors already and found it hard to focus much time and energy into the project. This delay was made worse when my partner entered another long period of time without a single minute of work. Six months, at least.

During this time I had completely re-written the core logic of the application based on a much-improved version of our internal framework. I spent time training the partners on the technology, setting up code access and emails, and doing a lot of organization work. I wrote a ton of “product direction documentation” which felt like busy work from elementary school. I’m sure 37Signals would agree.

Lesson #5: Adding super-smart, previously successful partners to your company is worthless if they’re not right for the market. You’ll get a year of generic business help and crazy white board diagrams but you’ll also have another year without a product.

Somehow we all stopped meeting and six months later I realized they had essentially ceased to exist. Not one email. In 2009, I requested that we drop the three individuals from our company and my partner agreed. I felt bad about the decision but it was clearly not working.

Lesson #6: As the founder, the business and the product is your first priority. Get rid of everything that honestly isn’t contributing to it.

We eventually stopped working on Kiwi because the market had become absolutely saturated with competition. So many products were encroaching on our territory that we felt less and less confident that we could make any money. Our ambition dropped to the lowest of lows.

Snowy

In October 2009 I made the decision to begin building a bug tracking application. I had long been complaining about the existing tools and finally had a light-bulb moment about why I should spend my time making a new one.

I already knew we could make a killer interface that was easy enough for clients to use but also powerful enough for us (developers). I already knew that I could eliminate the issues I had with existing tools. My realization was that I could build a product that allowed our deployed applications to report back errors rather than storing them locally, so that we could easily track those issues and be one-step ahead of our clients.

Whether or not this product would ever be used by others, it was going to be perfect for me.

Lesson #7: If you can’t actually use your own product, you’re not supposed to build it.

Work began. I was initially going to build the entire application myself to avoid the problems I had before. However I quickly realized that the interface could use the perfectionist’s touch, and I asked my partner from Kiwi if he would be willing to put together some designs for this issue tracker. He agreed. Six months later I had a lot of my work completed. The interface was moving along, but slower than I would have liked.

Soon it was mid-2010 and the effects of the recession were starting to hit us both. We were struggling with a long list of clients that suddenly couldn’t pay us, and new clients were nowhere in sight. I used some of my suddenly-free time to market for new work, – but the rest went into the new product. My partner did the opposite – he put in even less time on our product than he did when things were busy.

By 2011 I was fed-up with the lack of progress on the design. There was so little progress from my partner I assumed he was no longer interested. I began looking for a new designer and it wasn’t long before I had several candidates. A few weeks later I had narrowed it down to one.

I was excited about the new designer as I had heard of his work before, and he seemed extremely interested in the product. I emailed my partner with the news.

After several days of no response, I eventually got an email from my partner apologizing for the lack of focus and consistent problems with the project. He outlined ways we could get back on track and was trying to save our friendship. He asked for another chance. I decided that it was best to try to work this out and give it another shot. Not only did I think his work was unbeatable, but he was a good friend.

My choice was upsetting to the candidate I had selected. I should have, and could have handled that a lot better.

Lesson #8: Sometimes, saving the friendship means stopping the partnership before you truly wind up hating each other.

Like he promised, he recommitted to the work and after several months we had the product almost ready for a private beta. Despite having a sizable portion of the design work still incomplete, we decided to go ahead with a beta. We settled with a very ugly sales page and sent an email to a few hundred friends and coworkers. Things were looking up. Snowy was closer to launch than Kiwi had ever been.

Lesson #9: Nothing motivates you like seeing people use your product. It can be hard to see what doesn’t work but the amazing fact is that you have the power to fix it.

We both dealt with some personal issues that delayed us in the last half of 2011 but by early 2012 we were on our final stretch. Yet suddenly, we lost a few more months because my partner has become unavailable for the work. I ended up taking over the remaining bit of design work. I’ve been cranking away with final tweaks and testing and we’re finally ready to launch a product, two and half years after we started, and six and half years since we began this endeavor.

I’d like to introduce Snowy Evening. An issue tracking application with an incredibly clean and easy to use interface, powerful features that blend seamlessly, and a lot more.

Built with determination, and run by a guy who’s truly invested in it’s survival. I’m in it for the long haul.

Lesson #10: Working with people who don’t share your work habits or ability to sit down and make progress is like swimming upstream. Do your best to find partners who truly match your personality. Like marriage you’ll always have differences but if you’re all driven and can manage themselves professionally, you can make it to product launch. That’s when the real journey begins.

As Snowy grows, I’ll continue posting here about the behind-the-scenes.

The extension layer I’m working on will add functionality for building basic quizzes and scoring them, and hopefully, some MongoDB support. When completed I’ll push that functionality as well. But for now, I need your help in testing the changes in 0.4.

As usual, source code and downloads are on GitHub.

On paper, the ideas behind Sass and Less seem amazing. Shorten css development by using variables (for colors, etc), reduce the amount of written syntax by calling functions once, that when compiled, produce all necessary vendor prefix equivalents, and so on. By themselves, those were enough to convince me to try it.

I tried Less first, which is mainly different by the fact that it uses javascript to compile the real css. For those unwilling to add another script and process time to the client-side there are server-side solutions as well, and then there’s Sass. Sass has essentially the same features but is compiled on the server by Ruby gems.

However, when I began using these in already-live projects I discovered how painful they are. Here is a quick rundown of everything I’ve discovered about using these technologies versus hand-written CSS.

The Environment

Right out the gate, using Sass was a pain because I had absolutely no development environment for it. I had to install ruby, as well as the gems for compiling it. Firebug needs an additional plugin (and the gems need additional configuration) so that it will point you the Sass file and not the compiled css file. All of my editors/IDEs needed special plugins in order to recognize the syntax (for coloring, etc).

Now this is all install-once-and-you’re-set stuff but it still throws several additional steps into the mix when I move to new machines, etc.

Every day of work I need to ask the compiler to watch the project for changes. When I forget to do this, I get frustrated wondering where my css changes are.

The Nesting Danger

One of the benefits of sass/less is the ability to nest selectors. The sass could look like:

body {
  /* ... styles ... */
  header {
    /* ... styles ... */
    nav {
      /* ... styles ... */
    }
  }
}

When compiled, the selector for nav becomes:

body header nav {  }

The issue is that while attracting you with a nicer layout in the raw css file, it’s compelling you to build unnecessarily complex selectors. Although there are times when you need to specify the hierarchy, it’s not every time. In one project I’ve taken over, almost everything is nested this way.

It’s a performance hit to the browser because every chain becomes longer and requires a more specific application of the styles. The bigger issue is that it becomes an absolute nightmare trying to override styles. When I’m attempting to override a base style for a larger screen size I must repeat the entire selector because CSS requires that specificity.

So I’ve wound up writing selectors that look like the following:

body #main ul li a { float: none }

It creates a lot more hassle about figuring out what the exact selector needs to be, debugging it when it’s not working, and sorting through the clutter this adds.

Commit Spam

When using version control it’s very easy to suddenly see a huge amount of commit spam from the compiled css. You can bypass this by compiling the css on deployment but that’s a bit more effort. If you have development configurations in place, sass will leave a lot of comments in the compiled css referencing the original location of the sass-version. These change with every compile and if you have a thousand-line-long css files, your commit diffs will be absolutely huge, even for a one-line change.

In fact reviewing said commits will be impossible because you can’t figure out what changed in all of that mess. In order to avoid that, you need to be sure that you never commit compiled code with any development/debug info left in.

When you’re working by yourself I see more of a benefit to using these technologies but when you’re working with a team, you’re not the only one who has to do these steps. It becomes the entire team.

Conclusion

I’m ready for you tell me why I’m wrong. But in the end I have to ask if all of this work is really worth not having to write extra vendor prefixes (which we all copy/pasted anyway) and having to refer back to your notes for each rgb/hsl/hex color code? It seems like that’s a lot easier to do to me.

This will never be a problem again, thanks to Snowy Evening. Snowy-Evening.com has been in development for almost two years and despite an amazing list of features (all listed on the home page) it has an incredibly clean and very easy to understand design. Our clients have been using it for a year and there are several well known web companies already using it for their projects.

I highly recommend you try a free account at Snowy Evening.

There are a few plugins that automatically size the text (like FitText) but they only increase the font size, and the font sizes don’t adjust when the parent is adjusted.

Enter my newest plugin ExpandText. You can provide a minimum and maximum font size and the plugin will adjust the font when the container element changes dimensions. It uses the width and height of an auto-inserted span which wraps the text directly.

Simply attach the plugin to the text element selector inside of a document ready and window resize:

$(function(){
	$(window).resize(function(){
		$('.text').expandText();
	}).trigger('resize');
});

The benefit of the span technique is that we can avoid trying to measure the characters themselves which change dramatically with each font type and style.

Download the code via GitHub and try out the demo.

For a recent project I decided to finally (long overdue, I know) make the the transition to an external search and indexing application called Sphinx.

Sphinx is a separate server that will index content from a variety of sources (in our case, MySQL) and provides an API that allows you to search the content more effectively.

If you’re using it with MySQL, you need to ensure that the mysql-devel package has been installed. Since this project was on CentOS, this is a simple yum call:

$ yum mysql-devel

Once that’s installed you’re ready to install Sphinx:

$ wget http://sphinxsearch.com/files/sphinx-1.10-beta.tar.gz
$ tar xzvf sphinx-1.10-beta.tar.gz
$ cd sphinx*
$ ./configure --prefix=/usr/local/sphinx
$ make
$ make install
$ sudo mkdir -p /var/data/sphinx

Once installed, you need to create a configuration file that will dictate where the data is indexed from, and how the search server will behave.

$ vi /usr/local/etc/sphinx.conf

Sphinx needs to know about two things – where to find the data for indexing, and how to index it. The source needs to point to a database or content source – in this case it points to our MySQL database.

source name_your_source
{
    type                            = mysql
    sql_host                        = 127.0.0.1
    sql_user                        = mysql_user
    sql_pass                        = mysql_pass
    sql_db                          = mysql_database
    sql_sock                        = /var/run/mysqld/mysqld.sock
    sql_port                        = 3306

    # indexer query
    # document_id MUST be the very first field
    # document_id MUST be positive (non-zero, non-negative)
    # document_id MUST fit into 32 bits
    # document_id MUST be unique
    sql_query = SELECT id, field1, field2 FROM ourtable;

    # document info query
    # ONLY used by search utility to display document information
    # MUST be able to fetch document info by its id, therefore
    # MUST contain '$id' macro
    sql_query_info  = SELECT * FROM ourtable WHERE id=$id
}
index name_your_index
{
    source                  = name_your_source
    path                    = /var/data/sphinx/name_your_source
    morphology              = stem_en
    min_word_len            = 3
    min_prefix_len          = 0
#    min_infix_len           = 3
}
searchd
{
	port				= 3312
	log					= /var/log/searchd/searchd.log
	query_log			= /var/log/searchd/query.log
	pid_file			= /var/log/searchd/searchd.pid
}

The first few lines clearly setup the database connection credentials. The sql_query statement is what pulls in the data for indexing. Everything you need indexed needs to be pulled with this query. It’s also possible to pull fields that won’t be indexed, but will actually be used for filtering the data. These are called attributes.

The index component configures the index itself and how searches will be processed. Features like the minimum word length, and morphology (how variations of the word are matched) are defined here.

The searchd component simply sets some configurations for the daemon itself.

Once configured, run the following command and Sphinx will build all of the indexes:

$ /usr/local/sphinx/bin/indexer --config /usr/local/etc/sphinx.conf --all 

If the configuration file is loaded properly and the database connection/queries work, you will see the indexer output:

using config file '/usr/local/etc/sphinx.conf'...
indexing index 'yournamedindex'...
collected 1421 docs, 0.1 MB
sorted 0.0 Mhits, 100.0% done
total 1421 docs, 75457 bytes
total 0.188 sec, 400587 bytes/sec, 7543.82 docs/sec
total 2 reads, 0.000 sec, 22.6 kb/call avg, 0.0 msec/call avg
total 6 writes, 0.000 sec, 17.1 kb/call avg, 0.0 msec/call avg

Once the index is complete, you can run a test search directly without starting the daemon:

/usr/local/sphinx/bin/search --config /usr/local/etc/sphinx.conf searchtermhere

You will see a dump of every matching document. Once you’ve got the search running, it’s time to start the daemon. First, we need to create a directory for the log files we asked for in the config:

sudo mkdir -p /var/log/searchd

Then, start the daemon:

/usr/local/sphinx/bin/searchd --config /usr/local/etc/sphinx.conf

Keep watching for more posts – I’ll discuss how to to work with the search from PHP, how to run incremental index updates, etc.

I grew tired of typing the full push/pull commands so I’ve finally spent some time searching for the best bash function on the net… which appears to be http://forrst.com/posts/My_gitstuff_bash_shortcuts_for_working_with_g-BwI

Edit your bash profile and place the “gpush” and “gpull” functions after anything that currently exists. I personally didn’t use the aliases shown in the pasted code sample, as I already use a different set.

vi ~/.bash_profile

When running gpush or gpull they will activate the associated commands on the current branch.

Because of this, I’m transitioning the WordPress courses to a new instructor so that I can focus on my series of web development courses (which are my primary focus anyway). Before I put the materials I’ve developed for the WordPress courses into eternal digital storage I thought it would be best for me to share the list of tips and plugins used or mentioned in any of these courses.

I’d love your comments or recommendations on any plugins I’ve missed.

Essential Plugins – For Every WP Install

1. WP-DB-Backup – You can always re-download WordPress, and you’ll most likely be able to find your theme again. But you don’t have any backups of your database, which is the most important part. Install this plugin and schedule a backup so that if something happens, your content is still safe.
2. Google XML Sitemaps – An XML-based sitemap is simply a directory of every page, post, and other information that search engines should be immediately aware of. It’s an amazing plugin working with an awesome standard  – and it’s done wonders for SEO on every website.
3. Akismet – It even comes with WP. Comment spam is bad, and annoying but Akismet will handle it all for you. Free for personal use, with a small recurring fee for commercial.
4. All in One SEO Pack – This tool modifies some basic functionality so that you can improve your search engine indexing. By making minor changes to the page titles, and meta information, your content is better suited for spidering.
5. W3 Total Cache – WordPress isn’t exactly the fastest the piece of software, and with enough incoming traffic (usually unexpected traffic when someone popular links to you) it can quickly consume your server resources. The total cache plugin has a huge number of options that all help speed everything up. As the name implies, it caches page content so that php and apache aren’t churning as hard with every single request. Some great options for css, javascript, and html compression as well. Speed is worth every penny.

Statistics Plugins

1. Google Analyticator – Google Analytics is the current leader in website statistic software. Even though adding the necessary javascript to your theme isn’t difficult, it’s still a pain especially if you’re not familiar with FTP software. Plugins like Analyticator insert the code for you, no matter the theme.
2. GetClicky – Google Analytics is the leader, but I don’t see that lasting forever with the rise of real-time analytics tools. Clicky is pretty neat service and in many cases, better suited for clients who a) have small sites, b) want real-time information, and c) find G.A. too complex to work with.
3. Feedburner – The analytics tools are great, but they typically fall short when determining who’s subscribed to the RSS feeds of your website. If you have your feeds routed through FeedBurner.com, they can.

Social Media Integration

1. Twitter Widget Pro – This plugin ads a widget (requires themes with widget support) that will display your last x tweets.
2. Facebook – There are so many plugins now for Facebook, and so many for posting info as well as reading, I’d recommend just browsing the Facebook Plugin directory.
3. Facebook Comments – This plugin uses the Facebook comments API to load their commenting system onto your posts. Users with Facebook accounts can immediately discuss your post without messing around with the WordPress name/email and spam protection system.
4. ShareThis – Personally I despise seeing tools like these on a website, but they are still in high demand. ShareThis and a few similar plugins allow users to share your content on dozens of social networking websites. A range of icons and logos are displayed and the users choose which network to “share this” on.

Contact

1. ReplyMe – This plugin will send an email to users when a comment they’ve made has been replied directly to. If you need more control, and you need to let them opt-in to such a service, Subscribe to Comments may work better.
2. ContactForm7 – By far the most popular contact form builder. Before this plugin showed up in the repository, developers were essentially building such forms manually – whether they were directly in theme or wrapped inside of custom plugins. ContactForm7 is now the leader and offers a lot more than just basic contact form support.
3. Contact Form 7 Campaign Monitor Addon – There are many popular email campaign services out there – MailChimp, Constant Contact, etc. They all have some basic WordPress plugins. Campaign Monitor is one of the most popular, but it’s even easier to setup because of this plugin which is simply an addon to ContactForm7.

Other

1. WP Touch – If your WordPress theme doesn’t have any mobile device support, WP Touch and WP Touch Pro are cheaper alternatives. These plugins create mobile-friendly versions of your content (independent of your theme however).
2. Syntax Highlighter Evolved – For those of you who need the ability to display code snippets in your posts (like us) then you need this plugin. By providing a series of WordPress shortcodes, you can add proper syntax highlighting, line numbering, and the ability to copy the entire snippet to any block of code. Even better is the fact that it works in the comments too!
3. Yet Another Related Posts Plugin (Related Entries) – There are several plugins that attempt to automatically link related posts, but this one seems to work out the best when properly configured. Still, changing the title of the link lists to “Possibly related” gives you a lot more leeway when things go wrong.
4. MapPress – I’ve spent a lot of time working with the Google Maps API, so being able to add in a simple map directly from the posts page is extremely helpful. The free version has all of the important features but the pro version adds some more advanced functionality. Now that Google doesn’t require an API key, it’s even easier.

Resources

1. The WordPress documentation.
2. http://www.wpbeginner.com/
3. http://www.wp-tutorials.org/
4. http://wordpress.tv/

I’m sure there are hundreds of useful plugins that I haven’t listed. I’m always interested in trying out new plugins, so feel free to post any suggestions in the comments.

However, I’ve recently learned that there is a way to share the library using Dropbox – not sync it, but share it. Simply move the library itself. I had considered this option before (since it’s how I use 1Password) but there seemed to be no way to move the Snippets library.

The last item on their FAQ however, describes what we need:

1. Copy the library from ~/Library/Application Support/Snippets/Snippets.xml to your Dropbox account. (~ = Your user folder.)
2. Launch the application while holding the option key.
3. Click the “Choose a library” button, and select the new xml file in your Dropbox folder.

You’re done! You can now use this same library from any of your machines with access to the same Dropbox folder.