Sass is compiled CSS. It fits in with the current (kind of stupid, in my opinion) trend of taking a language or syntax that doesn’t need compilation, then adding a compilation step in order to get some syntactic sugar. Coffeescript is another example. Sass is a Ruby program that will sit in your CSS directory, scan your .scss or .sass files, then spit out .css results. With these sorts of things, you have to decide if learning new syntax will save you time later on.

I’m doing some CSS work for the first time in about a year, so figured I’d give Sass a shot, because I’m bored out of my mind, and need to do something to keep myself entertained. After working with it for about an hour, I was pretty much converted.

The main benefits I see to Sass are the nested syntax, mixins, and variables. With it, you can write CSS in a “nested” fashion, similar to how your HTML document is arranged. It makes it much easier to scan a block of Sass to see what style corresponds to what HTML element. An additional benefit is that copy/pasting large blocks of CSS is now possible, without having to remove or change the top level selectors for a rule. I’ve been able to create whole new page layouts extremely quickly using this technique.

Mixins and variables are just extra bonuses. Instead of having to write a bunch of vendor prefixes for box shadows or gradients, I can create a box-shadow mixin that can then be included in every rule that requires that style. Variables are great, too: you can just define a $text-color variable, then refer to it easily later without having to memorize an arcane hex value.

If you work in web development, I’d recommend giving Sass a try. Check out this article at 37signals.com for more info, then read the Sass tutorial. Next stop: productivity!

(Also, Command + Click opens links in a new tab. When I had a scroll wheel mouse, I used the wheel click to open/close new tabs, but since I’m Magic Mousing it up, I’ve had to drop that habit.)

Fire up JMeter, and you’ll be presented with a new plan. Create a new thread group (your users) in the Test Plan (as detailed in the previous tutorial). Now, instead of manually adding HTTP Requests for these users to perform, we’ll hook up a proxy server to create the HTTP Requests for us.

Right-click on the WorkBench item in the sidebar, and select Add > Non-Test Elements > HTTP Proxy Server. You don’t have to configure anything here, just click the Start button at the bottom of the config window to start the proxy server on port 8080. Now you’ll have to configure your browser to pass its’ requests through the proxy server. In Mac OS X, you do this system-wide by accessing your System Preferences. Go to System Preferences > Network > Advanced (the “Advanced” button is in the lower-right corner of the window). When the advanced options window pops up, click the Proxies tab, then check the Web Proxy (HTTP) option, and change the Web Proxy Server port to 8080. Click OK to save your changes, then Apply to make them take effect.

Next, open your browser and go to the JMeter homepage (http://jakarta.apache.org/jmeter/). Click a few links, and then go back to your JMeter window. There should now be an arrow next to your thread group, meaning that the group contains some actions. Click the arrow to expand the list, and you should see requests for all the resources that you requested in your browser. You’ll see that requests have been made for every resource your browser asked for, such as images and CSS files. You can remove those requests if you want, or leave them in for a more realistic simulation.

Don’t forget to go back into your Network settings and disable the proxy server, otherwise you won’t be able to make HTTP requests when you close JMeter. However, this method of creating JMeter test cases is way easier than its’ manual counterpart.

Obviously, first of all you should download JMeter. Unzip the downloaded package, and place the whole folder structure somewhere easy to remember. If you want, you can set the /bin directory on your path so you can start the program from the command line. I just double-click the ApacheJMeter.jar package to start the program.

After JMeter starts up, you’ll be faced with a totally blank slate. What we want to do is create a group of users, and have each of those users perform a certain sequence of actions (such as access a URL, post a form, or whatever). There are two ways to do this with JMeter: enter the sequence by hand, or configure a proxy server to intercept your browser requests and save them as an action sequence. If the list of actions you want to perform is complex, it might be a good idea to set up a proxy. I’ll show you how to manually set up your test; running the proxy server will be reserved for a future post.

First, let’s rename the test plan to be something more descriptive. Click on the “Test Plan” text in the project sidebar, and rename it to something descriptive, such as “My Jawesome Test Plan.” Now, the first step in creating your test scenario is to make a group of users. Right click on your test plan, then select Add > Threads (Users) > Thread Group. “Thread Group” is kind of a confusing term, so you can rename the group to “Users” if you want. When you click on your user group in the sidebar, you’ll see there are various options you can change about it, the most significant being the number of users, how fast they start performing their tasks, and whether they repeat their tasks. Change the number of users to 10, and the ramp-up period to 10 as well. That means that it’ll take 10 seconds for all the users to be activated. Since there are 10 total users, that means that one will start up each second. Change the loop count to 2, so that each user runs through their tasks twice.

Next, we’ll add some configuration options to the test, so that you don’t have to enter certain info each time you want to add an action for the user group to perform (such as the base site URL). Right-click your user group and select Add > Config Element > HTTP Cache Manager. This simulates a browser cache for each of your users, so if they download a static resource on the first test run, they’ll have a cached version for the second, making the test more realistic. Select the user group again, right-click, and choose Add > Config Element > HTTP Request Defaults. You can put in any default options you want here, such as the site name, port number, and path. So for example, if you were testing your site foo.com, you could put in “http://foo.com” as the server name. Then all subsequent requests from your users would use that information. If a user requested plain ol’ “bar.html,” the defaults would be prepended to that request, resulting in a request to “foo.com/bar.html.” When creating a test by hand, the Request Defaults configuration becomes very useful. For our example, let’s query the JMeter site, so in the HTTP Request Defaults options, enter “http://jakarta.apache.org” as the server name.

OK, we’ve got the test users all set up. Next, let’s have them try to make some requests. Right click on your user group in the sidebar, and select Add > Sampler > HTTP Request. This represents a request for a single page or resource on your site. Let’s have it request the JMeter homepage. If you remember, we already set up the default site URL and path, so the only option we have to change for the sampler is the path value, which we’ll set to “/jmeter/index.html” (for the homepage). Also, change the name of the HTTP Request to “JMeter Homepage” so that it’s easier to see what it’s requesting.

At this point, you’ve got enough set up to actually run the test and see real results, but let’s go ahead and add another HTTP Request to the test. Right-click your user group, add another HTTP Request, and set the path to “/jmeter/usermanual/index.html.” Rename this request to “JMeter User Manual.” Now the test is completely set up, but there’s no way to view the test results yet. To remedy this, we’ll add two “listeners,” which track results and display them in a human-readable way. Right-click your user group, and select Add > Listener > Graph Results. Also Add > Listener > Summary Report. These are two simple listeners that show your results in a graph and text-based summary.

Now, go ahead and run the test by choosing Run > Start (or Command-R). Wait for a bit for the test to finish, then click on your results listeners. You should see the (hopefully successful) results of your test. Now for some embellishments. In a more realistic scenario, users would load a page, read it for a few seconds, then click a link to go to a different page. In the test script right now, your users make requests as fast as they can. To insert a random delay between requests, right click each HTTP Request in the sidebar, and choose Add > Timer > Uniform Random Timer. This timer allows you to set a base constant delay (such as 2 seconds), and then add another random delay on top of that. I like to have a 2 second constant delay and a 3 second random delay, so go ahead and edit both timers to have values of 3000 (random) and 2000 (constant). Also, ideally we want to make sure that the results of each request were successful. There are a number of ways to do this in JMeter, but the simplest is to make an assertion that each request returned a HTTP status code of 200. Right-click each of the HTTP Requests and choose Add > Assertions > Response Assertion. Modify each assertion to check the Response Headers, choose “Equals” for the Pattern Matching Rules, and add “200″ as a Pattern to Test. The Response Assertion is very powerful… you can modify it to check for patterns in the HTML of the requested page, etc., but this basic assertion is enough for our needs right now.

And that’s it! You now have a fully functional basic test plan. You can run it and see a cool graph of response times as well as get the summary report for the whole test. Hopefully that will get you started with the wonderful world of load testing.

Well, this story actually started last year(!). While browsing the Seagull Bags website, noticed that they didn’t have any sort of “preview” feature for ordering their custom bags online. I had been tinkering around with Flash for a few months, so figured I might be able to offer some sort of a trade – “programming a bag preview widget in exchange for a messenger bag” sort of thing. I also already knew Dan McKewen, the owner of Seagull, through church, so I already had an “in.” Well, Dan liked the idea, and I started mucking around, trying to create a Flex app that would be a suitable order form replacement. I actually got pretty far, in spite of my lack of knowledge regarding Flex. What held me up was that I needed some good photos of messenger bags to use in order to create a “preview” of each custom bag. Dan promised me some, but he was always busy, and the project got pushed to the back burner.

Fast forward to July of this year. Out of the blue, Dan said that he had photos for me, and the project lurched from the grave. It had been so long since I’d touched any sort of Flash/Flex, I didn’t want to keep trying to build on what I had previously created. Since my current job had me doing a lot of Javascript and jQuery, I decided to re-build the order form using Javascript. Javascript also had the added bonus of being accessible to Apple’s iOS devices.

There were a few delays (such as me trying to publish my first iOS game and the birth of my daughter), but the form eventually got done! I think it works pretty well, and gives you a decent preview of what you’re getting before you plunk down some of the cold, hard-earned. Check it out at the Seagull Bags site.

UPDATE: They just posted a picture of my bag on Facebook. Awesome!

// Encrypt the password with Blowfish and a salt - 16 chars starting with $2$
$salt='$2$';
$salt_length=16;

// Chars to choose from to generate the salt
$chars="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz1234567890!@#$%^&*";

//Generate the salt string
while(strlen($salt)< $salt_length)
	$salt.=$chars{mt_rand(0,strlen($chars)-1)};

$hashed_password=crypt($password, $salt);

Fortunately for me, it’s relatively easy to edit key mappings in OS X, which means that the functionality I’m used to has mostly returned. For the mouse issue, I had to install a Microsoft mouse driver, which conflicted with the mouse control panel option for a while.

On a somewhat related note, have I mentioned that the Mighty Mouse is horrible? It doesn’t fit my hand at all, has a worthless “scroll wheel” nubbin, and flaky left/right-click support. Sadly, back when I was working at my old job, I had thought about buying one, even going so far as to make some low bids on eBay. I think this piece o’ junk is going up there for some other sod. I do like the Mac keyboard, though (not the new, shallow version). The keys, while not clicky, have an appropriate amount of tactile feedback. The keyboard itself is much narrower than my Model M IBM keyboard, though, which took a bit of time to get used to as well.

All in all, I’m pretty happy about my purchase… a little bit bitter about getting the shaft in terms of RAM and HD space (1 GB/250 GB in a machine of this class? Ridiculous! Plus no Bluetooth or WiFi=superlame), but prices for that stuff will keep going down. I’m glad to be using a more versatile machine, albeit one that’s a massive investment.

Another thing I just wanted to mention for my own reference was short conditionals in PHP. Example:

<?
	if(empty($_GET['id']))
		echo 'No ID';
	else
		echo 'ID: '.$_GET['id'];
?>

Can be replaced with:

<?=empty($_GET['id'])?'No ID':'ID: '.$_GET['id']?>

The syntax can be broken down into CONDITIONAL ? IF TRUE : IF FALSE

It’s basically just a way to make your code concise and look esoteric while doing so.