141+ characters

Chrome’s developer tools has way more shit than I realized

• <Ctrl>+<Shift>+F:Search across all sources — because searching in only one file just doesn’t help me that much
• Overrides tab lets you change your user agent — great for testing mobile version of pages
• Disable javascript and disable cache — because sometimes it’s a pain in the ass to keep having to go clear your cache over and over again
• Logging ajax requests to the console — means i don’t have to fire up fiddler

It looks like there’s some other valuable options there as well, i just don’t really understand all of them?

I recently started maintaing some code using Freemarker, a templating language. This is not a new technology by any means, it’s been around for a long time, but it’s new to me. So I wondered … why would anyone need to use a templating language … isn’t that what JSP is for?

Here’s what I’ve found:

• It’s interpreted… i know what you’re thinking … “so what?”. Well, here’s a practical example. Say you have a search results page generated with a JSP. And say for some reason you need to send those results as an html based email. Well… in order to do that you would somehow need to execute the jsp server side, grab the results as string output, and write them into the body of your email. There’s no easy way to do that. You’d most likely end up rewriting your jsp in a string buffer … which would leave you with a mess. So, in comes templates. Assuming your results page was written with a templating language instead of JSP, you can simply run it through the interpreter on the fly, passing the appropriate parameters, and viola, you have your html as a string which you can include in your html email. So with a single view file, you can use it for both the regular web view and also the html email view, no code duplication.
• It’s interpreted … so you can use it for anything. Like my example above, I’ve seen it used for emails in a number of organizations, mainly to avoid writing html with string buffer (yuck!). You could use it to write CSS and Javascript files dynamically.  You don’t even need to be in a ServletContainer, you could use it as part of your build process to dynamically generate some static HTML files.
• It has a smaller memory footprint because, you guessed it, it’s interpreted. (Though technically it’s probably slightly slower due to it being interpreted, the effect is negligible).
• JSPs have to be lazily compiled when they are requested … which often leaves the user hanging for a few seconds. 
• Templates never need a server restart to pick up changes. If you ARE precompiling your JSPs, great, but that means you lose the ability to just drop a new JSP in and go, because you’ll likely need to restart your server.
• It has support for most basic operations you’d find in JSP, meaning conditional statements, loops, etc, and it also even supports EL. So you don’t really lose much functionality when compared to JSPs. If you’re sticking to a good MVC pattern, you most likely are trying to keep as much logic outside of your view as possible, so this shouldn’t matter.

So from what I’ve found, templates are ever so slightly slower because they are interpreted, but it’s well worth the simplicity and flexibility they provide.

After attending Velocity this year, I thought I would take a moment to reflect on some things I learned.

Unfortunately, my laptop and all of my notes from the conference are in the hands of an unknown taxi driver somewhere in the San Francisco Bay area. So I’m pulling most of this from memory. So in no particular order:

1. Perceptual diffs - I forget what talk this was from, but one of the speakers mentioned that as part of automated regression testing in their CI process, they actually perform “perceptual diffs” of on new content vs. old content. Meaning that purely visual bugs (think CSS error on a web page) can be caught, where traditional regression tests would miss them. Cool, right?
2. RUM (Real user monitoring) - Not a replacement to Synthetic monitor, but a compliment. Using the Navigation Timing API, we can gather metrics on what real users are actually experiencing (don’t forget about the outliers!). Best of all, Google Analytics by default will now gather samples from 1% of your traffic and report it under the “Site Speed” section. Now we just need to wait to see what goodies the Resource Timing and User Timing specs provide.
3. John Snow is not only a bastard brother of the night’s watch and true heir to the kingdom of Westeros (speculation/spoiler, sorry), he was also a renowned physician infamized by his “work in tracing the source of a cholera outbreak in Soho, England”.
4. Async script hacks aren’t always the best option. So, to download a script asyncronously, we have to do some hacks, right? Inject a dom node, or one of those other crazy hacks, right? Well, it sounds like the answer is “no, not really”. The main issue with this, is that it defeats “look-ahead” script downloading … meaning the browser can’t start downloading other scripts ahead of time, so you can actually get worse parallelization and ultimately worse performance. So, that’s where the script tag’s “async” attribute comes into play. We favor these async hacks because the “async” attribute is not fully supported by all browsers, namely the old ones. However, considering the advantages of “look-ahead”script downloads, and that 80% of users are using browsers that DO support the “async” attribute, it actually may be more advantageous to use as script tag with the “async” attribute. The one BIG exception to this is third-party scripts. So for example, if you’re including addThis (who don’t actually provide you with async snippet … shame on you!) on your website, you’ll want to include the script via an async hack, because you’d risk introducing a SPOF to your site for user’s who’s browsers DO NOT support the “async” attribute.
5. SPOF tools - Speaking of Single Point Of Failures, there are now 2 tools available for auditing your site for SPOFs. One, a Chrome plugin by Stoyan Stefanov and another another Chrome plugin by Patrick Meenan.
6. “Don’t fight stupid, make awesome”. - I love this concept … don’t waste your time fighting stupid, spend your time elsewhere making awesome. And people do, there was a whole lot of awesome all around … awesome programmers, awesome projects, awesome talks … it’s all very inspiring.
7. Automated optimization - This was new to me. There are a number of vendors offering products that will actually intercept your server responses rewrite them to implement front end performance techniques. They do everything from script deferal, image optimization, and even domain sharding. The one thing that was more realistic for me was mod_pagespeed, an Apache plugin that will automatically implement a subset of these best practices. It’s smaller, free, and gives you more fine grained control. This will make for a fun “experiment”.
8. Google Critical Path Explorer. Basiaclly, a waterfall diagram but you can actually interfactvely explore the “critical path” … meaning what is blocking what from executing. This will be offered as part of Page Speed Insights.
9. “Networky” things matter - I used to ignore all the different colors on a waterfall chart, but as it turns out, they’re quite important. They represent a bunch of “networky” things you can tune to make your page faster … minimizing DNS look ups, setting a keep-alive header, preventing scripts from being split across packets, chunked encoding, gzip, and a few other techniques.
10. SPDY is not always faster than HTTP - As I understand it, while SPDY is strictly faster than HTTPS, it is only faster than HTTP in certain situations. A lot of the problems SPDY was meant to solve originally, have been fixed in most browsers. So while SPDY is “awesome”, depending on the situation, it is not always faster than HTTP. I’ll be interested to see how widely this is adopted.

Bonus: Facebook is big … I mean REALLY big. Like 6 million images uploaded every 30 minutes big.
Bonus: CSS can be tuned for performance. Who knew? It mainly involves minimizing your DOM size and favoring the most efficient selectors.

I use Fiddler extensively. It’s one of the few tools that I honestly don’t think I could do my job without.

A few good use cases:

• Any time redirects are involved … like with authentication systems with multiple redirects for one request. You can see step by step what’s happening.
• Cookies … rather than just checking your browser tools to see what cookies have been set, just check out the response headers and see exactly where they where and by what they were set.
• Caching. Viewing cache headers is huge. Not to mention to see whether a request for a resource was actually made to the server, or just served from cache.
• Ajax. Obviously, it helps to see what you are sending a receiving.
• Tracking code … is your beacon request being sent?
• Basically any time there is a front end issue with your web page, fiddler can usually help … are all the resources you’re expecting being included? Is there a funny third-party request from your page that you don’t recognize? Are there 404’s on any of your resources… etc.
• Pausing requests and responses. This is helpful if you want to test a SPOF for a file, or performance.
• Editing requests and responses. Is there an obfuscated js file on a page that you want to debug, but can’t because it’s all on a single line? No worries, pause the response, copy the script into a js beautifier, edit the response by adding the beautified js, and viola, you can now debug.

Scripting

You can manipulate requests and responses programatically, which is a new thing I recently discovered… which is way more useful than I would have anticipated. http://www.fiddler2.com/fiddler/dev/scriptsamples.asp

In particular:

• Highlight requests that have certain text or headers … (like requests that set a certain cookie, etc.)
• Simulate delays
• Pause particular responses so you can edit (or test SPOF)
• Return a 404 or 500 on certain resources to test how your app will handle it
• Add / Remove headers

There’s other good tools out there that can accomplish the same thing, and Fiddler is admittedly not the most intuitive program. But just like Eclipse, once you figure it out, you’ll love it.

Bah! This took longer than 10 minutes … i might have to bump my description up to 15 :/

A version of the drinking game Wizard Staff, based on the Game of Thrones / A Song of Fire and Ice series.

Competitors will be competing for control of the Iron Throne and the Kingdom of Westeros, so each player must pick a house to represent. For maximum results each player should attire themselves appropriately with house color and sigils.

The rules:

Beers 1-5: You are a squire.

To continue on to beer 6, you must complete an act of bravery (a shot of wild turkey), at which point you become a knight.

Beers 6-10: You are a knight.

As a knight, you may challenge other knights (not squires or lords) to shotgun battles (first player to finish their shotgun wins) … the winner of the shotgun battle gets to put both cans on their staff, the loser none.

Beers 11+: You are a lord.

As lord of your house, for each beer you add to your staff you may create a rule that everyone else (that have not yet becomes a lord) must follow.

The joust: For the crown

To determine a winner, a joust must be held. Only lords may contend. Two lords joust at a time, the loser is out and the winner continues on. Each jouster must where a helm (a beer case) with a single beer can taped to the top. Each jouster must knock the beer can from their opponents helm. Whomever loses their can (or their entire helm) first loses.

Remember, when you play the game of thrones … you black out. Enjoy.