Text

· · to read

I started building a Rails 3.1 app that runs on Heroku using the Cedar stack. In this app I really want to take advantage of the Rails 3.1 Asset Pipeline. I’m using CoffeeScript, Sass, and Compass. The former two come with Rails 3.1 but I needed to add Compass myself. I used the instructions here, but used the latest version of Compass because it now works, and I added a check in the initializer to see if sass was loaded. The check in the initializer is needed because Heroku only runs with the asset gems from the Gemfile when it compiles the assets, and it only compiles the assets when a new slug is loaded. So what happened is that the Rails 3.1 initializer, sass.rb, tried setting a configuration parameter in sass when sass wasn’t loaded.

Here’s the relevant code. The asset section of my Gemfile now contains compass:

group :assets do
  gem 'sass-rails', "  ~> 3.1.0"
  gem 'coffee-rails', "~> 3.1.0"
  gem 'uglifier'
  gem 'compass'
end

…and I added config/initializers/sass.rb:

if Rails.configuration.respond_to?(:sass)
  Rails.configuration.sass.tap do |config|
    config.load_paths << "#{Gem.loaded_specs['compass'].full_gem_path}/frameworks/compass/stylesheets"
  end
end

It uses respond_to? to see if it there is a sass configuration object.

Right now I’m using Compass to set a border radius.

Text

· · to read

Here is a list of a few awesome sites offering tools for learning Rails:

PeepCode

Pricing: Starts at $12 for one screencast; Twitter: @peepcode and @topfunky

I bought my first PeepCode screencast back in 2008, before Rails and Merb merged. It’s been around for a while, but Geoffrey Grosenbach does a great job of keeping it up-to-date. There are now a number of screencasts about current topics of interest to the Ruby on Rails community, including Rails 3, Backbone.js, PostgreSQL, CoffeeScript, and John Barnette.

Railscasts

Pricing: Free weekly episodes, additional weekly episodes and revised episodes for $9/mo (RailsCasts Pro); Twitter: @railscasts

Railscasts is great for keeping up on Ruby On Rails, and because it’s free, it’s also great for recommending to people who are curious about Rails but not ready to spend money to help them learn it. Ryan Bates is great at explaining things. He covers a wide variety of topics in his screencasts and presents them in a nice format with code snippets.

Update: since I posted this Ryan Bates released Railscasts Pro, which is fantastic!

Ruby on Rails Tutorial

Pricing: $26 (book), $85 (screencasts), $95 (both); Twitter: @railstutorial

Michael Hartl is a physicist who does a number of other things (see his about page) including Web Development with Ruby On Rails. I’ve watched all of his screencasts; they’re fantastic. He builds a web application TDD-style and teaches many different concepts including MVC and how TDD can help with authorization (which is trickier than authentication IMO).

Rails Apps

Pricing: Free; Twitter: @rails_apps

I always thought that the Rails Starter App templates were cool, but they were missing something: in-depth tutorials and a comparison between the many different templates and quick-start tools. Daniel Kehoe has provided both and many more useful resources in his Rails Apps GitHub account.

Code School

Pricing: Free (one substantial free product), $45-55 (single paid products); Twitter: @codeschool

Code School is a set of tutorials designed to help developers to quickly get up to speed building web applications. Gregg Pollack and Envy Labs have been doing podcasts and screencasts for quite some time, and it’s not surprising that they still do it, because they’re very enthusiastic in front of a camera and a microphone.

Text

· · to read

I put my SyntaxHighlighter Brush Pack on WordPress.org, using the excellent git to WordPress.org Subversion instructions to preserve history.

In order to check that it works, I moved my plugin (installed as a git submodule) outside the wp-content/plugins directory, went to Add Plugin, searched for it, and instructed WordPress to automatically install it. It works! The following CoffeeScript code was highlighted using it:

launch() if ignition is on

If you use WordPress and either CoffeeScript or Clojure, I’d love for you to give it a shot!

Repositorywordpress-syntaxhighlighter-brush-pack
Ownerbenatkin
Text

· · to read

Faraday

Faraday is an high-level HTTP client library with middleware support, and support for multiple low-level HTTP client libraries. It can be used just by adding it to the Gemfile and running bundle install, just like RestClient can. Or, a different library can be added to the Gemfile and then used through one of its adapters.

Faraday Middleware

The faraday_middleware library, which was started by Wynn Netherland and has been maintained by Erik Michaels-Ober, contains a bunch of middlewares for authentication, response parsing, and convenient hash objects.

Faraday Stack

Faraday Stack is a pretty generic yet convenient API client. It encodes JSON, parses XML and JSON, follows redirects, and raises errors. In short, it works like many expect custom API clients to work, yet it can be used anywhere, just by specifying the domain. It doesn’t include authentication, which ships with many API clients, but that can be added easily by looking at the source for the stack and adding authentication from another library into it. It’s better than many custom API clients, so if an API client is the slightest bit frustrating, it may be a good idea to use faraday_stack instead.

I really like Faraday, because it lets me choose which HTTP library I’m going to use, which is different between Ruby and JRuby. I often use Faraday by itself even when a custom API client is available. I also will use it in irb (next time, pry) instead of curl at times.

Repositoryfaraday
Ownertechnoweenie
Repositoryfaraday_middleware
Ownerpengwynn
Repositoryfaraday-stack
Ownermislav
Text

· · to read

I’m working on a plugin for displaying infoboxes for URLs called Resource Infobox. The interface is a shortcode with a single url property. To include an infobox, use an expression like the following:

[resource-infobox url="https://github.com/benatkin/wordpress-resource-infobox"]

This will show an Infobox with some basic information:

Repositorywordpress-resource-infobox
Ownerbenatkin

Examples of Infoboxes include those on Wikipedia, in the upper-right corner of pages, and the old Crunchbase ones I saw on TechCrunch:

The neat thing about the ones built by this WordPress Plugin is that it renders based on some JSON rules. The current rule file has two resource types, GitHub Repositories and GitHub Users. These are not limited to GitHub, though; with the current implementation they could be written for twitter, Crunchbase, and any URL that has straightforward mapping from the HTML url to the JSON url. Here are the current rules:

{
  "github": {
    "repository": {
      "url": "https://github.com/:owner/:repo",
      "api_url": "http://github.com/api/v2/json/repos/show/:owner/:repo",
      "fields": [
        {
          "label": "Repository",
          "param": "repo",
          "url": "https://github.com/:owner/:repo/"
        },
        {
          "label": "Owner",
          "param": "owner",
          "url": "https://github.com/:owner/"
        },
        {
          "label": "Last Commit",
          "path": "repository/pushed_at",
          "type": "date",
          "format": "Y-m-d"
        },
        {
          "label": "Watchers",
          "path": "repository/watchers"
        }
      ]
    },
    "user": {
      "url": "https://github.com/:username",
      "api_url": "http://github.com/api/v2/json/user/show/:username",
      "fields": [
        {
          "label": "Username",
          "param": "username",
          "url": "https://github.com/:username/"
        },
        {
          "label": "Followers",
          "path": "user/followers_count"
        },
        {
          "label": "Respositories",
          "path": "user/public_repo_count"
        }
      ]
    }
  }
}

It’s a JSON DSL inspired by the DSL for Django’s admin interface. It has few features now, but following Django’s lead, it can have more features added to it while retaining its essence. The nice thing about using a JSON DSL rather than custom code is that it can easily be validated, and due to its declarative nature, XSS attacks and other undesired behavior can be avoided. It uses WordPress’s esc_attr and esc_url functions to render strings.

I’d love feedback on this. My goals for it include:

  • Caching (WP Total Cache greatly reduces requests to GitHub’s API on this page)
  • Adding more resource types
  • Adding more field types
  • Adding more display customization
  • Adding instructions for using code from this plugin as a base for other Infobox embedding plugins
  • Improving the resource type DSL
  • Building an editor for creating custom resource types
  • Supporting grabbing a resource type definition based on a custom header of a resource (like X-Infobox-Resource-Type)

I’d also like to make this work with more than just WordPress.

Text

· · to read

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!

Text

· · to read

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.

Text

· · to read

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.

Text

· · to read

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.

Text

· · to read

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
Text

· · to read

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.

Text

· · to read

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 →