After installing the CoffeeScript brush for SyntaxHighlighter Evolved, I wanted a Clojure brush. Rather than install another plugin, I created a combined plugin, with a generic name so I can add more semi-popular languages to it, called SyntaxHighlighter Evolved: Brush Pack. I’m planning on putting it in the WordPress Plugin Directory.

To show it off, here’s a Clojure web server example, from Heroku:

(ns demo.web
  (:use ring.adapter.jetty))

(defn app [req]
  {:status 200
   :headers {"Content-Type" "text/plain"}
   :body "Hello from Clojure!\n"})

(defn -main []
  (let [port (Integer/parseInt (System/getenv "PORT"))]
    (run-jetty app {:port port})))

Not bad. The :keywords and curly braces, which aren’t a part of Common Lisp or Scheme, are neatly highlighted. The code sample above, by the way, gets the port from an environment variable, which is how Heroku makes it easy for applications on different platforms to adapt to their environment.

For the CoffeeScript highlighter, which I mentioned in my last post, here’s app.coffee from express-sinatra:

express = require('express')
app = express.createServer()

# Setup Template Engine
app.register '.coffee', require('coffeekup')
app.set 'view engine', 'coffee'

# Setup Static Files
app.use express.static(__dirname + '/public')

# App Routes
app.get '/', (request, response) ->
  response.render 'index'

# Listen
app.listen process.env.PORT || 8000

This one also is ready to deply on Heroku!.

Please add an issue if you’d like to see another SyntaxHighlighter brush included!

I installed a WordPress plugin called SyntaxHighlighter Evolved, which highlights source code with client-side JavaScript. Here are a few notes about how it works:

  • Code can be inserted using a Shortcode. Thanks to how Shortcodes work, HTML entities don’t need to be escaped in the HTML view.
  • It uses a lot of Shortcode tags, one for each language, like php, so there is minimal overhead to inserting code snippets. This is a good decision in my opinion, because it gets used so often on code blogs.
  • The underlying library, SyntaxHighlighter, has a core that contains generic features for highlighting code, and contains brushes for highlighting different languages. These are mostly data.
  • The JavaScript code for SyntaxHighlighter is included at the end of the page, and only the needed brushes are included. Apparently when shortcodes are used, a language or brush name is added to a variable, and at the end of the page, it adds the appropriate script tag(s).

Finally, here are a couple of examples. This one is the included php brush:

function factorial($x) {
  if ($x > 1) {
    return $x * factorial($x-1);
  } else {
    return $x;
  }
}

And here is the CoffeeScript brush, which is provided by another plugin that depends upon the SyntaxHighlighter Evolved plugin:

passed = (score for score in scores when score > 60)

I really like this plugin. It’s a very complete solution. That said, I’d really like to be using ACE editor or CodeMirror to insert/edit snippets in blog posts.

During the last few years, while working as a web developer, I’ve seen awareness of the potential for XSS increase. I’ve also seen frameworks and open source applications come with better tools for avoiding XSS. There is still work to be done, though.

The most common way to avoid XSS is to have a very convenient way to put the escaped contents of a variable into HTML. What this does, is instead of inserting the HTML, <script>, it inserts the text, <script>, using the HTML, &lt;script&gt;. In Ruby On Rails and Django, variables are now by default escaped. In Django if you want a variable to not be escaped, you either need to mark it as safe in the python code, or include the template tag “|safe” in the template code. In mustache, you have double-mustaches for escaped ({{name}}) and triple-mustaches for unescaped ({{{html}}}). These encourage using the escaped option. With WordPress, using standard interpolated PHP, you have to be more careful. The simple <? echo $name; ?> will result in an unescaped value. To get an escaped value, the slightly longer <?php echo esc_attr($name); ?> or <?php esc_attr_e($name ?> can be used.

The above methods work for values inside and outside of tags, as they escape, at a minimum, <>"'. The angle bracket escaping deals with variables inserted outside of tags, and the quotes deal with data inside of tags (such as attributes).

There is one important case that they don’t cover, though: sometimes attribute values can do bad things. An href attribute can be set to javascript code, and if the users click on it, it will run. This is a security problem.

This means that, assuming the data isn’t validated first, the following mustache code is insufficient:

<a href="{{url}}">{{name}}</a>

Before it gets rendered, the URL must be sanitized to remove the javascript: URL scheme if it’s present.

Different tools have different ways of dealing with this:

  • Django doesn’t appear to have anything built-in, but the Bleach library covers this in its sanitization of HTML, at least partially.
  • Ruby On Rails has a built-in HTML sanitizer.
  • mustache, while extremely convenient for escaping HTML, doesn’t solve the URL problem, and so developers using it will need to look elsewhere. Google Caja would be one option.
  • WordPress has my favorite solution of all of these: the esc_url function. Running a full HTML sanitizer is overkill when using templates. I think it got a nice solution out of necessity: WP can be set up so users that aren’t logged in are allowed to comment and leave a link to their website, and malicious users could easily submit a link with a javascript: URI scheme. I took a look at the source for esc_uri and the functions it calls and it seems to handle a lot of cases, including a value starting with javascript:javascript: and the URI scheme being in upper case.

Most of these aren’t commonly known, and yet many, many apps provide ways to add URLs. Because of this, I think this must be a very common way of doing XSS attacks. It’s frustrating that I don’t have a quick way for developers to get up to speed on this, no matter what tool they’re using.

A better solution

I’d very much like a JSON test suite and a list of recipes to run the test suite in various languages, with extra recipes for languages where there is a framework or a library that makes the code shorter.

I really like the way that this theme, the WordPress Twenty Eleven theme, looks on my mobile device, which happens to be an Android. One thing I noticed is that it can take a little while to load on my Android phone. It’s not slow, but I think it could be faster. That would take dropping some features that don’t get used, which would make it less easy to customize.

I started thinking about whether it would be worth it, and then it hit me. Mobile won’t be slow forever, yet it will always be small. Unless I’m particularly good at it, or I have a specific need to do it, it’s better to spend my time thinking about how to make good interfaces for small screen sizes than how to make them use fewer bytes.

I got PHP and MySQL working together on my MacBook Pro with Mac OS X Lion tonight. I’m using the MySQL server that I installed with Homebrew. Homebrew doesn’t come with Apache or PHP due to its policy of avoiding including packages that are already installed on OS X. Because of that, I’m using the included Web Sharing, which I enabled in the Sharing Preference Pane under System Preferences.

I’m posting what I did below. I found a more thorough guide when I got stuck on a step. Please consider using that, as it covers much more, including getting PEAR set up.

Here are the steps that I remember taking, to get WordPress running locally:

  • Install MySQL using Homebrew (brew install mysql)
  • Since I added something to my /etc/apache2/httpd.conf that caused Web Sharing to fail to start, I copied /etc/apache2/original/httpd.conf to /etc/apache2/httpd.conf, and that fixed it.
  • Turn on Web Sharing in the Sharing Preference Pane
  • Uncomment the line that starts with LoadModule php5_module in /etc/httpd/httpd.conf
  • Since I didn’t want all of my files in ~/Sites, I enabled redirects in my user php file, /etc/apache2/users/bat.conf, by adding FollowSymlinks to the Options.
  • Add a symlink to the WordPress directory (~/Sites/blog in my case) and set up the database
  • Go to the directory in the browser (http://localhost/~bat/blog/ in my case)
  • My database connection didn’t work despite my username, password, and hostname being correct. After some googling I found that I needed to change all instances of /var/mysql/mysql.sock in /etc/php.ini to /tmp/mysql.sock
  • Fix the WordPress site url in the database

I’d like to go to IndieWebCamp next year. I found out about it when I checked out Ward Cunningham‘s Smallest Federated Wiki project. It’s an annual conference in Portland, OR that started this year. The conference is dedicated to participants building their own websites, that are under their control, and helping each other do the same. Only Builders and Apprentices (people invited by builders who want to become builders) may attend.

As part of requiring that participants have their own personal websites, we are required to have OpenID on their our domain to log in. We can run our own server or use delegation. Running an OpenID server generally means setting up an application with a database. Delegation is quite a bit simpler. All that it requires is adding a few meta tags. Here are mine:


<link rel="openid.server" href="http://www.myopenid.com/server" />
<link rel="openid.delegate" href="http://be.myopenid.com/" />
<link rel="openid2.local_id" href="http://be.myopenid.com" />
<link rel="openid2.provider" href="http://www.myopenid.com/server" />
<meta http-equiv="X-XRDS-Location" content="http://www.myopenid.com/xrds?username=be.myopenid.com" />

There are three different standards referenced: OpenID, OpenID2, and XRDS. Not all are used by a given server. I tried removing all but the OpenID2 lines and logging into IndieWebCamp still worked (lines 3-4).

To log in, I type the address where my OpenID delegation is, http://id.benatkin.com/, and IndieWebCamp’s OpenID plugin for MediaWiki sends me to MyOpenID to log in.

This is different from using MyOpenID directly in that if I decided to use a different service, or my own, I could. This is a big part of IndieWebCamp: being free from lock-in, even if you really like the service provider.

WordPress Plugin

I also wrote a WordPress plugin, specifically for MyOpenID, which lets me specify my MyOpenID username and adds the needed meta tags. It’s called WordPress MyOpenID Delegation. Unfortunately, it only works for me if I remove the W3 Total Cache rewrite rules from my .htaccess file. This is because apparently the two OpenID client websites I tried (Indie Web Camp and a test site) don’t follow 301 redirects to find a delegate. I removed them and checked how much it slowed things down. After fiddling with ab and getting the idea that it slows things down quite a bit, I added the W3 Total Cache rewrite rules back to my .htaccess, and set up a static page on http://id.benatkin.com/ instead.

It was good practice for writing a WordPress plugin, though. I learned how to add something to the header using a hook, how to only add it to the root page by checking is_front_page(), how to add a setting to General Settings, and very importantly, how to escape HTML in WordPress.

What was interesting to me was how little my code was about using PHP and how much it was about finding the right APIs.

I’m going to try to get this working with my rewrite rules later. I may make it use a different path for my openid, like /openid, rather than my root path. But in the meantime, I’m off to write another WordPress plugin.

I archived this blog using HTTrack for a few months because it was killing my tiny (256MB) improperly-configured slice and I was considering switching my blog engine. It worked surprisingly well, except I couldn’t write new posts. My blog is still #1 for my name on Google and I didn’t detect any broken links. It wasn’t the first time I used HTTrack; I also used it to download a couple websites.

During this time I’ve been posting to tumblr and posterous. I had a short info page linking to both of these blogs and my then-archived WordPress blog, which was previously at http://benatkin.com/weblog/. During this time I’ve been following WordPress and watching it grow, and wanting to get involved with it. I still want to use other CMSes, but I decided that I would switch benatkin.com back to WordPress and explore other CMSes on different sites.

For several months I’ve had a slightly beefier CMS that I prepaid a year for. I got two extra IP addresses on it so I can run more than one web server and have multiple SSL sites. I’m running both Apache and nginx so I can learn both of them. I’m using Apache to host this blog, and nginx to redirect to it from the www and blog subdomains.

It feels good to be back on WordPress. Many friends have benefited from WordPress’s customizability and ease of use. I also like it from a software freedom perspective. I tend to favor non-copyleft licenses to copyleft licenses like the GPL, which WordPress uses, but the bottom line is that people are in control of their site and their data. They are free to switch hosting platforms and even export their data to another CMS and set up URL redirects if needed. Finally, there are many great plugins and themes available, due to the size of the WordPress community. I hope one day to go to a WordCamp.

If you’re thinking about setting up your own custom WordPress.org blog, I encourage you to give it a shot!

Some configuration details follow.

Continue reading

When the iPad came out, I was hoping that, because of the low screen width in portrait mode (768 pixels), web developers would turn off their sidebars when low horizontal browser widths were encountered. This would make it so, even if I didn’t buy an iPad, I could benefit by when displaying my browser and text editor side-by-side. Alas, I haven’t seen many sites changing to look better with lower widths. I think the main reasons for this are:

  • iPad uptake, while significant, hasn’t got web developers who are set in their ways (myself included) to change their layouts
  • The iPad’s pan and zoom feature is so convenient, horizontal scrolling hasn’t annoyed users that much
  • iPad users are compensating by using their iPad in horizontal mode most of the time when browsing, or by rotating when they come to wide websites

With this in mind, I’ve noticed when I see a site I like that doesn’t take up too much width, both while using my 15″ MBP and while using my iPad. I’ve noticed that having a sidebar rarely adds to my experience of reading a blog entry. I don’t need help forming biases toward the writer by seeing his or her picture. I don’t need to know how old the blog is, or what other topics the author blogs about. When I’m on somebody’s blog for the first time, usually the only thing I care about is the content of the article. If I enjoy the article, I may bookmark the blog and poke around some more later*.

I also like narrow text. So, a blog layout I like is one that leaves half the page empty, when I’m viewing it full-screen on my MBP. This isn’t weird to me. It doesn’t feel like wasted space. It doesn’t bother me that if I wanted, I could use the space for something else. In fact, I love it!

Here’s a problem. When I’m reading it on the go, it’s nice that the dip is small and easy to carry. However, when I’m at home, I don’t need the small size. Wouldn’t it be nice if, while I’m reading it, I could have a little information about Seth Godin and some links to other books in the sidebar? Here’s a proof-of-concept:

web-in-physical-world

Right now my site contains a sidebar with a tag cloud, links to archives, and some other stuff. It’s days are numbered. I may replace it with a link to another page, a drop-down menu, or nothing. I don’t know if this goes against anything in Ambient Findability (which I hear is an excellent book). I doubt it. None of the stuff in my sidebar is connected to this article in any significant way. I often find links to related articles helpful, though.

* Ideally. I just realized that if I’m trying to do something, and I find a great blog entry that helps me, I should get back to doing that thing, rather than looking for other blog entries right away. This, I think, is a large part of what gets me spending too much time browsing the Internet.

I just realized one big thing that Freckle and Stack Overflow have in common: they have virtuosity built into the definition of their target market.

Freckle‘s target market is defined as small businesses where everyone trusts everyone else. That’s how it can be a social time tracking where everyone can see everyone else’s entries. And tagging makes seeing other peoples’ entries useful for owners, managers, and employees alike.

Stack Overflow, on the other hand, is geared mainly towards programmers who want to cultivate knowledge. It’s also geared towards google searchers, but they’re not the core group, and don’t get the benefits available to the core group, like reduced advertising and moderation abilities.

For a counter example, there are mass-email companies that sell their servers to spammers. And there are ones that avoid spammers, but have a hard time achieving separation just by how they define their target market (and saying people who want to send mass email minus the spammers doesn’t work well). But Campaign Monitor circumvents that problem by marketing to designers, who are an intermediary between them and a larger group which includes spammers, that keeps most of the spammers out.

I think defining a good customer base is a large part of having a good customer base.

I like seeing URLs, whether in the link text or by hovering over a link. They are often truer to their content than what the person adding the link writes. I always have the status bar turned on in my browsers. It annoys me that there is no status bar on the iPad. It pleases me that Chrome shows URLs without taking up space for a status bar, by fading them in when hovering over a link. But a significant percentage of URLs aren’t worth a whole lot. They are either too long, or contain nothing identifying but numbers.

Some say that URLs will go away. But do they have to? If people still care about them, I don’t think so. That’s why we need URLs worth caring about. Just like we need buildings worth caring about, and neighborhoods worth caring about:

So how ’bout it?

(Yes, I realize that this blog’s urls suck, and don’t have to. I plan to change that soon.)

I had some issues upgrading to Django 1.2.1, and needed to roll Django back to 1.1.2. I searched for “Downgrading Django”, and didn’t find instructions, so now that I’ve figured it out, I’m posting instructions here.

First, if you’re using easy_install, I suggest switching to pip. It has more features, is better designed, and uses the same repositories, so it’s easy to upgrade. To install it, type sudo easy_install pip.

To install Django 1.1.2, type sudo pip install Django==1.1.2. When I ran this, pip automatically removed the newer version of Django, and the two glitches I was encountering with the admin interface went away. Once I figure out what caused the glitches, I’ll upgrade back to Django 1.2 so I can take advantage of its new features.