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 checkout Snowy Evening – it’s free while it’s in beta.

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.

I’m primarily condensing a jumble of older web-related classes into a single flow. We had several classes with overlapping content and misleading titles, so the new structure will make a lot more sense for students beginning their web development careers. I’ve also decided not to teach any of the WordPress courses after the summer term, allowing me to focus on my continuing and new courses.

Web Development 101 and 102 will begin again in Summer 2011 and will repeat every term. Javascript/jQuery will begin in the Fall and will likely repeat every term.

I’ve enjoyed this more than I expected because my teaching style really seems to fit well with our students. I’ve never had an average whole-class evaluation score lower than 4.19 out of 5 and my mean scores are around 4.5. From my understanding, these are difficult scores to maintain for any department.

For my Web 101 courses – which I enjoy teaching the most – I’m earning a 4.64 average score which feels great considering every single student is evaluating my performance.

I’ve had some reviews from students that really encourage me to continue these courses. From these reviews and discussions with the students and management, I feel that I’ve been able to do so well because:

• I enjoy working with web technology, and I enjoy teaching it.
• I work with it daily so I’m aware of current trends, what’s becoming outdated, and what to expect in the neat future.
• I’ve been doing this long enough, and on such a wide variety of projects that I am able to easily answer any question that comes up. I always back up my recommendations with logic and reasoning that makes sense for all students.
• I’ve been both an employee and a business owner in this field, and I have a unique perspective from both career paths.
• I seem to have a knack for taking difficult to understand topics and explaining them very clearly to first-time students.

While I’m not paid for time spent developing course materials, I’ve found that I really enjoy that time because I’m able to put in as much iteration time as I want. I’m constantly refining my course materials based on how students react to the labs. I have a very strict no-slide-presentation rule except for a very short introduction on the first day. The rest of our time is spent in our code editors, building and trying each lesson.

If you’re interested, I’ve made all of my course materials available on GitHub.