url::encode

Why Writing a Webapp Reminds me of Playing a RPG

I’m sure you’ve played an RPG of some sort… Diablo, Torchlight, Titan’s Quest, City of Heroes, World of Warcraft, Pirates of the Burning Sea, Aion, Eve Online, Dark Age of Camelot, Age of Conan, etc.  These all invariably involve the same pattern of gameplay.

You design a character — it’s gender, appearance, skin tone, and of course role/class.  You enter the world, simple and weak, using the same basic skills to accomplish every task.  As you grown in experience you begin to use more tools to accomplish the same tasks.  In the “middle” portion of this experience, between when you first created the character and the maximum level is probably the highlight of playing:  You’re progressing at a very notable pace, you frequently receive gear upgrades and new skills, and the sense of accomplishment is very high.  As you start to near level cap the “newness” begins to wear off: you only receive more powerful versions of the spells you already had.  There isn’t anything new, just bigger numbers.  Hitting level cap the sense of accomplishment trails off very fast.  The only progression left is to try to acquire more and more esoteric pieces of gear/upgrades.  The time between those upgrades becomes farther and farther apart as more time investment is required to attain them.

I see a lot of similarities with writing a webapp.  You start off designing your technology stack — it’s web server, server framework, client framework, and of course language.  You write your first few lines of code, simple and weak, using the same basic patterns that you read in the “Getting Started in X Web Framework” tutorial.  As you grow in expirience, reading more Stack Overflow answers you begin to use more refined tools to accomplish the same tasks in ways you’d label “better architected” or “more scalable”.  In the “middle” portion of this new webapp when you hit Minimum Viable Product is probably the highlight of the webapp:  You’re progressing at a very notable pace, you frequently add new features and upgrades to existing ones, and the sense of accomplishment is very high.  As you start to near completion where all of the features have been implemented the “newness” begins to wear off:  You’re only refining existing features now, making small slight changes and tweaks here and there.    The only progression left begins to render very small changes.  A 0.5% improvement here, a 0.75% iimprovement there.  The time between “upgrades” becomes farther and father apart as more people begin to use your webapp and you risk upsetting people’s workflow by changing too much.  The excitement and passion is slowly draining.

At this point what happens?  Well in an RPG you’d either re-roll a new character or switch to another game. In webapp development you’d either “re-roll” the projects by re-writing huge portions of it in the latest language or framework.  Or you’d switch to another “game” (a different project).

I think this is somewhat of a problem but I’m not sure what the fix is.  Is there a way to keep excitement, newness, and a sense of accomplishment on a well establish project?  If so how?

Blekko & Google: A Quick Study in Color Contrast

Blekko recently launched with much fanfare.  There hasn’t been much change in the search engine world recently so I imagine a flood of early adopters will give them a steady flow of traffic for sometime.  Being a techy and web developer myself I of course wanted to hop on the bandwagon early on.

However within just the first day I began to feel like Blekko was “harder” to use.  That sounds silly right — it looks and works almost identical to Google.  I couldn’t quite put my finger on it but the search results page felt undecipherable if I was just scanning it.  With Blekko search results I felt forced to read each result individually.

So curious I compared Google and Blekko side by side.

They look almost identical: Blekko is red, Google is blue.  How hard can it be?

But after further use what I began to notice was that I had a harder time scanning the titles of the search results.  Apparently over the years I’ve developed a habit of just scanning the titles and completely skipping the summary, unless of course the title is of interest.

When it comes to Blekko, this is how it feels to me…

The interesting thing is that I think this is simply an issue of the contrast relationship between the title and the tools/links under it.

Here’s an example of what I mean.  If everything was to remain constant except the links below the title, the ability to scan the result titles becomes increasingly easier.

Try scanning these two and quickly reading just the titles.  Which is more comfortable on your eyes?

Is the Golden Age of Django Over? [Opinion]

To me Django was revolutionary.  Sure there were many more frameworks who came before it, but for those of us who didn’t care for the scaffolding-command-line-driven style Ruby On Rails offered, Django was a breath of fresh air to the otherwise tedious task of web development.  Django had so much going for it…

• Tons of features
• Built on python
• A positive and helpful community
• Good documentation
• Very easy-to-use ORM
• and so on

I spent about a year and a half learning and using Django, enough so to earn the Django Badge and be in the top 20 answerers for the django tag on StackOverflow.

Aside from the general technical benefits that Django brought to many, it was personally quite revolutionary for me.  A brief bit of history here if you would entertain me.

A few years ago I was in an interesting point in my career where I really needed to start seriously pursuing if I wanted to be a web developer/user interface guy or if I wanted to be a graphic designer/marketer.  My web development career had initially kicked off with classic ASP and various ill designed apps which naturally led to .NET and C#.  However my day job was largely design and marketing.

Those were the days web development was weary work.  Some still used HTML tables because CSS layouts were slightly broken in a handful of browsers.  AJAX was just starting to become buzz-y and the phrase “web two point oh” was being incubated in journalists minds.

I had found that the majority of my web development tasks were concentrated on boilerplate and infrastructure.  I considered a future in such monotony wasn’t looking enjoyable and was questioning my web development role.

Unknowing to myself I had actually created a mini-web framework very similar to Django in C# for .NET.  I had all the things you’d expect: a templating engine, an HTML forms engine, and a data layer that abstracted a decent portion of the underlying SQL away.  I spent most of my time trying to keep this up and it really slowed real progress on the website I was working on.

Humorously, it was actually the announcement of ASP.NET MVC that lead me to Django.  You see after learning the general principals of MVC I realized something I should have already known:  The entire internet was trying to deal with these same issues.  I’m sure it surprised others too.  It’s a lesson you don’t learn in school.  Shortly there after that I set out to find a language which provided a vast array of libraries that I could use to free up development time to actually focus on domain problems and not supporting thousands of lines of libraries.

This lead me to Python — And who was the knock-out web framework for Python at the time?  None other than Django.  Some called it “Python’s answer to Rails”.  This was back before Django and pink ponies were synonymous.

I learned Django in 2 days (went through every chapter in the Django Book) and was just totally blown away.  For the next year and a half everything I did web-related was in Django, including a rather large website and a handful of Django reusable apps.

In a sense Django was my training wheels to thinking about web development in an abstract, separated, and well defined way.  Django didn’t just team me MVC — it got me thinking about how websites are architected.  Once I realized there was an entire ecosystem of web application frameworks I was like a kid in a candy story; Pylons, Werkzeug, Sinatra, Merb, Seaside, Lift, Flask, and most recently Tornado.  I wanted to learn them all.

In my eyes Django was revolutionary, but it wasn’t without it’s issues — most of which I could happily overlook.  It seems though that in the wake of Django’s success literally hundreds of web app frameworks, many written in Python, have followed offering potential developers a certain take on how web development should be done.

Receiving a slight bit of internet buzz recently, Alex Martelli recently recommended Flask (based on Werkzeug) over Django for personal projects.

Today it seems there is such a choice of frameworks that it’s highly unlikely that one would not find something they like which is specialized to their development style or project.  However in the jungle of choice I’m wondering [out loud] if Django is being left behind as the large-one-size-fits-all that no one feels fits them like more specialized frameworks do.

In some sense we knew it was coming; no technology lasts forever.  In another sense it seems like Django’s time in the spotlight was too short lived.  Was it that Django included so much (batteries included) and the web changes so fast that it can’t keep up?  Is it that Django’s broad focus lends itself only to projects that fit it specifically?  Is it that the technical innovation of “competing” frameworks give developers enough of an edge for them to switch?  Is it just that developers have an insatiable appetite to use the latest and greatest, even if the previous worked just fine?

Is the Golden Age of Django over?

Why Using the AJAX Spinny Wheel Is Bad [Opinion]

Alright that was a tricky title just to get you to read the first line.

Twelves years ago when I made my first website on AOL’s “MyPlace” I copied some javascript I found out there on the internet somewhere to try and make a hover effect for my “personal webpage”.

Why?  Because it looked cool.

A few years later I was implementing DHTML page transitions.

Why?  Because it looked cool.

A few months ago I was sticking that stupid AJAX spinny wheel on everything.

Why?  Because it looked cool.

Just like javascript hover effects and DHTML page transitions maybe it’s time to stop and think about what we’re doing with AJAX.  To be fair the actual AJAX spinny wheel itself isn’t bad in and of itself.  Giving visual feedback to the user to indicate something is happening is always a good choice.

However I’ve started to notice that whenever I find myself reaching for the AJAX spinny wheel I need to really take a long and hard look at what I’m doing.  In the majority of cases the AJAX spinny wheel indicates that I am replicating browser functionality.

Unless there is really a specific benefit that can be gained by doing this it almost always ends up bad.  In the past few months I’ve actually had a couple of projects I was working on where the interface had been written in AJAX and I ended up un-ajaxifying the UI because not only did the AJAX UI not add value but it was restrictive and removed default browser functionality.

AJAX often brings problems like…

• Non-standard interfaces and interface elements
• Reduced browser default functionality* (history, back/forward buttons, etc.)
• Unnecessary lag via animation effects often implemented to display AJAX content changes
• Reduced SEO*

* - Yes I know there are efforts on these fronts to improve this, but still.

The fact still remains that the majority of times end users would rather have a predictable, usable, and effective website experience than to have a glittery, effects-filled one.

It’s sad.  I know.  I just re-read that to myself and it was more sad the second time.  Being half designer this pains me even more.

Eric Ries (on the topics of A/B testing websites) says it well: “…this led us to confront the disappointing reality that sometimes customers actually prefer an uglier design to a pretty one…”
[The one line split-test, or how to A/B all the time, Sep 15, 2008].

The next time you reach for the AJAX spinny wheel ask if you’re really adding efficiency to your webapp or if you’re just sprinkling unnecessary glitter.

3 Cool Jquery Tricks I’ve Been Using Lately

Everyone loves jQuery.  Ok maybe not everyone, but at least a huge portion of the internet.  It’s likely because jQuery implements the DOM very similar to how it should have been implemented in the first place (but we won’t beat that dead LiveScript horse anymore).

Anyways, here are some cool tricks that I’ve learned, used, or been using lately…

1. Use .live for binding events on elements not yet created

It’s common to write jQuery code that creates new DOM elements or shuffles them around.  What’s not cool is to try to wire-up events up to those new or shuffled elements, especially when you don’t know if they’ve previously had event handlers attached to them.  I often found myself doing things like this…

var bindTagEvents = function(tag) {
    $(tag).unbind().click(function(){
       // foo 
    });
}

// ...

span = $('').attr('title','My New Span');
$('body').append(span);
bindTagEvents(span);

Note the unbind() before the click().  Yeah it works, but jQuery provides the .live function which works for all elements current and future.  This means even if we were to create that new span tag and append it to the <body> tag, the .live function would still apply it.  Using .live, we can shorten the example above down to…

$('body > span').live('click', function() {
    // foo
});

// ...

span = $('').attr('title','My New Span');
$('body').append(span);

2. Draw attention to newly created elements using the highlight effect

Again it’s common to create new elements in our jQuery scripts but one thing to be concerned with is how it will feel to the user.  Often times the addition of new content is subtle enough that users won’t notice, even if we the developers do.

JQuery UI provides an effect known as “Highlight” which when fired causes the element to briefly pulse in a yellow “highlighter” color, hopefully drawing attention to it.

Implementing it is ridiculously easy:

$(tag).effect('highlight', {}, 1500);

The 3rd argument is the length — in milliseconds — that the yellow highlight color should fade out with.  It sounds like an obnoxious effect but it provides a subtle visual cue for users that a new element has been created.

3. jQuery Includes an Auto-Complete Feature

No kidding.  Like the highlight effect mentioned above, this feature requires the jquery-ui library, not just jquery ala-carte.  To be fair, there are many autocomplete implementations that have more features, but if jquery-ui is already included on your page why add another dependency (unless of course you really need that killer feature).

Autocomplete takes a couple of properties and handles most of the plumbing of what it takes to make an autocomplete/autosuggest system.  When activated on an input:text, the only thing it really needs is a datasource.

// Any array will do...
$('input').autocomplete({
    source: ['batman', 'robin', 'joker', 'catwoman', 'dr. freeze', 'penguin']
});

// Or URL of a custom page that returns an array in JSON format...
$('input').autocomplete({
    source: 'yoursite.com/api/autocomplete'
});

// Or a callback (to implement basic caching perhaps)...
var $autoCompleteCache = {};
$('input').autocomplete({
    source: function(query, addOptions) {
        if ($autoCompleteCache.hasOwnProperty(query)) {
            addOptions($autoCompleteCache[query]);
            return;
        }
        else {
            $.getJSON(
                'yoursite.com/api/autocomplete',
                function(data) {
                    $autoCompleteCache[query] = data;
                    addOptions(data);
                }
            )
        }
    }
});

Bookmarks Are Dead

At least to me.  I noticed the other day that I almost never use bookmarks anymore.  A year or two ago I was a bookmark junky, having 500+ easily.  So what changed?  In reflecting upon it, I think there are a few reasons for this…

1. I switched to using Chrome whenever I’m not doing web development (Firebug is just too awesome to give up).  The way Chrome is designed the bookmarks aren’t exactly a prime, in-your-face feature which are easily accessible — at least not in the way Firefox and Internet Explorer implement it. 
2. I use Twitter much more than I did in past years.  A lot (and by lot I’d say 50% at least) of the new sites I visit are from links seen on Twitter.  I follow people who tweet about topics I’m interested in (@smashingmag, @sixrevisions, @activestate, @cssbeauty, @usejquery) and thus click a lot of links that are posted.
3. Instead of “surfing the web” looking for new sites, as was all the rage in the 90’s, I tend to frequent the same sites, often times which serve in some part as content aggregation — and I already know their address.  Why do I need to bookmark it?
4. Chrome Pinned Tabs — Sites I really frequent have a permanent Chrome tab to keep them open.
5. Chrome Address Bar — Why waste the time to find a bookmark when you can just type something relatively close to what you want into the address bar and get instant results?

(Why are 3 of the 5 related to Chrome?  Google conspiracy theories ignite…)

5 Reasons to Consider Tornado for AppEngine (Python)

As I’ve begun to become better acquainted with Google’s AppEngine platform, I’ve hit a few points where the python-based “webapp” framework is less than desirable.

While I have a background in Django, I didn’t feel as if it was a fit for AppEngine due to it’s heavy data layer ties.  On the flip side, Tornado (IMHO) is a lightweight alternative and prime candidate.

Tornado, if you don’t know, is the web framework that powers FriendFeed and was recently open sourced by Facebook.  It includes the basics you’d expect: request handling, routing, templating; you know, the usual fare.  A scatter of MySQL utilities come bundled, but the framework leaves the data layer completely up to you (consequently it doesn’t including features like an automatic administrative interface or data models-to-web forms).

1.  May the Source Be With You

Sure, webapp has online documentation, but sometimes it’s easier to just read the source.  Even better, in Tornado’s case it’s available via GitHub.

Depending on your experience with python this might not sound like a compelling reason but consider this: You will likely have the tornado source folder inside of your project’s folder while developing (as it needs to be deployed to AppEngine with the rest of your python source files).  This means you can simply open up the Tornado source files in another tab in your editor for quick reference.

Once you get used to doing this it greatly speeds up your development time when you need to reference something and it gets you much more acquainted with how the framework works.

2.  Simple Templating

There are quite a few good templating engines out there for python. The problem I have with many of them is that they typically are too complicated or unnatural in syntax or too restrictive for in form, particularly when it comes to creating re-usable sub-templates which manage their own logic and data independent of the main page (I’m referring to what Django and other engines call “template tags”).

Before I mention tags a few words about the Tornado template engine — it’s simple.  It uses the common {% %} format.  It lets you put real python in between the {% %}’s   Sure, people say logic should be out of the template, however if it’s logic that relates to display I disagree.  Tornado gives you the choice.  If you want it, use it.  If not, do it the hard way.  It’s up to you.

Behind the scenes Tornado compiles the templates to a python file to make them speedy when serving to viewers (this has the odd side effect of requiring you to restart the appengine dev server whenever you change the template).

The one slip up is that if you, like me, are used to Django-style templates, you’ll probably write things like “{% endblock %}” or “{% endif %}”.  Tornado simply uses “{% end %}” for everything.

3. Drop-Dead Easy Template Tags

So about template tags, Tornado refers to them as “UI modules”.  Defining a new module is dead simple…

class SchemePreviewSmall(BaseUIModule):
    def render(self, scheme, lang='python'):
        data = self.handler.data.get_something_cool(scheme)
        return self.render_string('modules/scheme-preview-small.html',
                                  scheme=data,
                                  lang=lang)

In this example I’m calling the method get_something_cool which is actually a member of the calling RequestHandler (self.handler).  The return value is then used to generate the response by loading and rendering a template.  The nice thing here is that if I have a re-usable widget such as an ad, a login interface, whatever I can make it a module and re-use it throughout the site.

Using this module in a template is as easy as…

{{ modules.SchemePreviewSmall(scheme) }}

4. Easy to follow documentation

Yes, if the source isn’t you thing, there still is easy-to-follow documentation.  There’s enough there to get you up and running in an evening and you’ll learn a lot of cool tricks too.

5.  Minimal to Convert

Lastly, the webapp and Tornado syntax for request handlers are so similar, converting to Tornado from webapp requires minimal effort.

webapp Request Handler

class HelloWorld(webapp.RequestHandler):
    def get(self):
        self.write("Hello World")

Tornado Request Handler

class HelloWorld(tornado.web.RequestHandler):
    def get(self):
        self.write("Hello World")

There are, of course, a few other differences.  For example, fetching the value of a querystring. Webapp uses self.request.get() while Tornado instead does self.get_argument().  The differences are minor and easily done with Find and Replace.

Restoring Browser Functions to Clickable DIVs Without Javascript

Occasionally the situation comes up in web development where you have a highly styled tag such as
<div> or <li> that you want to make clickable.  This often happens when you have a list of items in which you want to make the entire item clickble instead of just the title for example.  The standard fare for doing so is to set { cursor: pointer; } with CSS then to bind the .click event to the tag (in jQuery as so)….

$('#myDivTag').click(function() {
    // your code here
});

Don’t get me wrong — this does work.  However, in doing this what you loose is the standard functionality that most viewers are used to; things like middle clicking to open in a new tab, right-click to copy URL address, and so on.  There is also the lag between when the page renders visibly to the user but the javascript hasn’t downloaded and $(document).ready hasn’t yet fired.  In this case the tag will not be clickable but the mouse cursor will indicate that it should be.

I’ve been dealing with this more so lately and there are a couple of ways to solve this problem.

The first is to wrap the <div> (or li or whatever else) tag in an anchor tag <a> and set that anchor tag to { display: block; }.

<style type="text/css">
	#myDivWrapper { display: block; }
	#myDiv {  }
</style>

<a id="myDivWrapper">
	<div id="myDiv">
	       ... content ...
	</div>
</a>

By wrapping the div tag in an anchor you’ve restored the default functionality viewers are used to with a clickable item.  This works in most browsers but for the most part things like <div> and <li> are not allowed inside of an anchor tag per HTML language specifications.  In a sense in doing something like this you are rolling the dice that the next version of IE9 strict mode won’t render when it hits this.

It also feels kind of  weird, because all of the styling that was on #myDiv, things like height, width, float, etc., now need to be applied to the anchor tag instead.  And no one likes wrappers. They just clutter things up.

The 2nd way to solve this problem which I’ve started using lately is to have an absolutely positioned anchor overlay the area of the div.  Consider the following…

<style type="text/css">
    #myDiv { position: relative; }
    a.clickable-overlay {
        position: absolute;
        top: 0;
        left: 0;
        height: 100%;
        width: 100%;
        z-index: 1;
        display: block;
        background-color: transparent;
    }
</style>

<div id="myDiv">
    ... content ...
    <a class="clickable-overlay" href="#wherever"></a>
</div>

Here’s what’s happening:  At the end of the <div> (or li or whatever) we’re adding an anchor tag.  The parent div is set to { position: relative }, and the anchor tag to { position: absolute; }.  If you’re not familiar with position absolute you’re missing out.  The way it is designed to work is that any element positioned absolutely is done so in relation to it’s parent (or any parent’s parent) that is positioned either relatively or absolutely.  What this means is that in setting our <div> tag to position: relative the anchor tag with position absolute will be positioned relative to the div.  Top 0 and left 0 will be the top left of the div,  and height 100%, width 100% will cause the anchor to fill out the area of the div.

The result is that we are left with a transparent anchor tag that completely overlays the area of the div, providing the default clickable behavior users expect.  The last CSS trick to making this work is to set z-index to 1, forcing the browser to always render the anchor tag over whatever content is in the div.

The positives to this method are that 1. we restore the expected clickable behavior without javascript (meaning it also works as soon as that markup is rendered and not when $(document).ready is fired) and 2. we’re using correct HTML syntax.

I should point out there is a downside to this method, in that because the anchor overlays the div, the contents of the div are no longer selectable or clickable.  Depending on your application this may be negligible.

Top 10 Programming T-Shirts That Don’t Make Sense

mind.location = unknown
http://www.zazzle.com/javascript_mind_tshirt-235892961444457742
I wonder what the value of the variable unknown is?

import_soul
http://www.zazzle.com/import_soul_tshirt-235715645595867505

Python Templating For the Web (Random Ideas)

Well it’s past midnight and I’m musing about web templating in Python for Tornado or AppEngine.   The thing about most Python templating engines that I notice is…

• There’s kind of an obsession with being agnostic about everything.  You can render JSON and XML and whatever else you want with our engine!  When is someone just going to make a really awesome templating engine for the web and not try to be everything to everyone?
  
• The value in a template engine to me is how easy it is to allow the template to include logic that’s independent of the controller that’s generating it.  For example, you might want a server-side ad manager on every page, but you don’t necessarily want to put the code for that in every controller.  Solution?  Some engines call it modules, some call it template tags, but whatever the name there is some type of logic that’s independent of the controller.  The problem is that most of these pieces of independent logic are needlessly complicated.  (side note: Django has gotten a bit better about this since I first used it two years ago).
  
• Maybe some better support for lazy-loaded values which are available for all templates… things like static URL, etc.