Wiseheart Design - Home

Create Facebook-like Windows with Popup.js

2008-07-17T04:00:00Z

Over the past couple of months I’ve been working on a little library for a client that allows us to create Facebook-like popup windows with ease. It’s called popup.js. The library depends on Dan Webb’s excellent Low Pro and comes complete with it’s own behavior for easy unobtrusive use.

So how does it work? Well, once you have the proper plumbing in place you can declare a simple popup window like this:


<div class="popup" id="test" style="display: none">
  <h3 class="title">Popup Window</h3>
  <div class="popup_content">
    <p>Hello world!</p>
    <p><a href="javascript: Element.closePopup('test')">Close</a>
  </div>
</div>

This markup assumes that you are using the included facebook.css stylesheet, but the only thing that is necessary to have a functioning popup window is a div with an ID attribute. You should also set style=”display: none” to ensure that the div is not visible when the page loads.

Popping up the window is as simple as linking to it:


<a href="#test" class="popup">Popup</a>

Links with the class of “popup” get the Popup.TriggerBehavior which will trigger the popup when clicked. Note that the href should be set to the ID of the element to popup. If you prefer you can set the href to a URL that returns the HTML for the popup and an AJAX call will be made to that URL.

For more information about this little lib, see the README in the GitHub project:

http://github.com/jlong/popupjs/tree/master/README

And investigate the test project:

http://github.com/jlong/popupjs/tree/master/test

Special thanks to Five Points Solutions for their help with debugging this library. They have contributed several Internet Explorer bug fixes in addition to funding much of the initial development.

Pragmatic Programmer Site Live!

2007-10-27T00:39:00Z

This may be old news for some of you, but the Pragmatic Web Site got a face lift a couple of weeks ago. I was thrilled to have the opportunity to work on the site with Mike, Dave, and Andy. Most of the design work was done this summer, while the finishing touches on programming and the data import pushed the launch date back to the beginning of October. (Site credits here.)

If you haven’t seen it yet, I’d encourage you to head on over to the site and buy a book or something!

Introducing Serve: Now With Gemmi Goodness!

2007-09-25T05:59:00Z

Based on my HAML Server for Web Designers article, I’ve created a small gem “serve” which makes it extremely easy for a Web Designer to get up and running with Haml and Sass:

$ sudo gem install haml redcloth bluecloth serve
$ cd ~/Workspaces/prototype
$ ls . * 
.:
index.haml

images:
logo.gif

javascripts:
prototype.js        dialogs.js         tabset.js

stylesheets:
application.sass        dialogs.sass
$ serve
[2007-09-25 02:11:42] INFO  WEBrick 1.3.1
[2007-09-25 02:11:42] INFO  ruby 1.8.5 (2006-12-25)
[2007-09-25 02:11:42] INFO  Serve::Server#start: pid=1626 port=3000
...

And voila! I can now access the files in ~/Workspaces/prototype at:

http://localhost:3000

Serve isn’t just a HAML or SASS server. With the proper gems it can also handle Textile and Markdown (not to mention plain Jane HTML!).

Serve also plays nicely with Rails. If you have a file named “script/server” in the current directory, Serve will execute that script instead of launching the normal WEBrick server.

Complete usage information is available with:

$ serve --help

Learn more about the project over at Ruby Forge…

A HAML Server for Web Designers

2007-09-04T02:45:00Z

I have a script named serve in my bin directory that let’s me quickly startup a Webrick server in any directory. This is handy for serving HTML mockups or other files. Today, updated it to work with HAML:


#!/usr/bin/env ruby
require 'webrick'
require 'rubygems'
require 'haml'

class HamlHandler < WEBrick::HTTPServlet::AbstractServlet

  def initialize(server, name)
    super
    @script_filename = name
  end

  def do_GET(req, res)
    begin
      data = open(@script_filename){|io| io.read }
      res.body = parse_haml(data)
      res['content-type'] = 'text/html'
    rescue StandardError => ex
      raise
    rescue Exception => ex
      @logger.error(ex)
      raise HTTPStatus::InternalServerError, ex.message
    end
  end

  alias do_POST do_GET

  private
    def parse_haml(string)
      engine = Haml::Engine.new(string,
        :attr_wrapper => '"',
        :filename => @script_filename
      )
      engine.render
    end

end

WEBrick::HTTPServlet::FileHandler.add_handler("haml", HamlHandler)

args = ARGV.join(' ')
args.gsub!(%r{^http://}, '')
args = args.split(/[ :]/).compact

server = WEBrick::HTTPServer.new(
  :Port => args.pop || 3000,
  :BindAddress => args.pop || '0.0.0.0',
  :DocumentRoot => Dir.pwd
)

trap("INT") { server.shutdown }

server.start

Just an Experiment

2007-08-26T00:02:00Z

OK, this has nothing to do with what I’m working on in Adam’s basement, but here’s a starfield simulation I’ve been working on for a small game in Javascript. It’s an interesting example of what is possible in Javascript on a modern Web browser (tested on Safari 3 and Firefox 2). Be sure to check out the source. Prototype makes this type of thing extremely easy.

Constraints, Frameworks, and Adam's Basement

2007-08-25T15:28:00Z

It’s official. Adam Williams and I are now working feverishly in his basement on our little idea for a web app. We’re both pushing off other obligations for the next 3 months so that we can concentrate on building a quality product.

One of the fun things about building your own application is that you can truly make it whatever you want it to be. If you’ve been in an environment (like me) where you are constantly building things for other people, working on your own project can be liberating. As a creative person I love this! The sky is the limit. No idea is a bad one. Every idea is worth considering.

But wait a minute! Even though we are now working on our own project we still have constraints. We don’t have an unlimited amount of time or money that we can devote to this. We eventually need to ship a working product even if it isn’t everything we initially visualized it would be. In fact, we have to be brutal about what we allow into the app and what we throw out. If we aren’t brutal we’ll end up with something sub-par. Either the app will lack the really useful features when it ships or it will never ship.

This week we’ve worn our creative hat a lot. One of the mistakes I think that we have made is that we have focused a lot on system architecture issues and not enough on application features. I’m beginning to realize that on the front end of this process it is extremely important to focus on application features. We can always refactor the application in the future when we know more about what the system architecture issues are. The features will help clarify that.

Extract a framework from your application. Resist the urge to invent a framework before working on features.

Better Modularization for Rails 2.0 (or What Rails Can Learn from Django)

2007-06-15T21:27:00Z

In my previous post about Rails and Engines, I talked about some of the issues I’d like to see resolved in Rails 2.0. Specifically, it seems that we need to rethink modularization in Rails and make it easier for people to share complete slices of applications.

One of the primary hinderances of the present Rails architecture to modularization is the directory structure.

Consider the typical rails app directory:

app/
  controllers/
    application.rb
    account_controller.rb
    blog_controller.rb
    comments_controller.rb
  helpers/
    application_helper.rb
    account_helper.rb
    blog_helper.rb
  models/
    user.rb
    blog.rb
    post.rb
    comment.rb
  views/
    account/
      signup.rhtml
      login.rhtml
      edit.rhtml
    blog/
      index.rhtml
      archive.rhtml
      post.rhtml
    comments/
      view.rhtml
      remove.rhtml
    layouts/
      application.rhtml

Now at first glance, the Rails directory structure seems quite helpful. There is a place for everything and everything is in its place. Models go here, views here, controllers here… The entire MVC in 3 different directories. Wait a minute! Compare this to the Django directory structure for the same application:

account/
  __init__.py
  urls.py
  models.py
  views.py
  templates/
    account/
      account_login.html
      account_signup.html
      account_edit.html
blog/
  __init__.py
  urls.py
  models.py
  views.py
  templates/
    blog/
      blog_list.html
      blog_archive.html
      blog_detail.html
    comment/
      comment_view.html
      comment_remove.html

Wow! See the difference? Django divides the application up not according to file type, but according to logical structure. Related files are together. This makes it easy to share entire chunks of an application. All you have to do is create an svn:external to the appropriate directory of another app and instantly you have access to an entire slice of the other application.

Imagine if Rails took the same approach. The new app directory could look something like this:

app/
  application/
    application_controller.rb
    application_layout.rhtml
  account/
    _config.rb
    _routes.rb
    account_controller.rb
    account_helper.rb
    account_edit.rhtml
    account_login.rhtml
    account_signup.rhtml
    user.rb
    user_migrations.rb
  blog/
    _config.rb
    _routes.rb
    blog_controller.rb
    blog_helper.rb
    blog_index.rhtml
    blog_archive.rhtml
    blog_post.rhtml
    comment.rb
    comment_migrations.rb
    comments_controller.rb
    comments_helper.rb
    comments_view.rhtml
    post.rb
    post_migrations.rb

Now I’ve changed things around just a bit to accommodate the new directory structure and support better modularization. Views are now prefixed with the name of the controller that they are associated with (this allows us to avoid having to put them in a separate directory). I’ve also changed migrations around so that all the migrations for a particular model are in the same file (we would probably need a new domain language for this). Also note that the _config.rb and _routes.rb files give us a convenient place to store configuration for a particular slice of our application (the underscore prefix would sort them to the top of a directory listing).

So that’s my big idea for Rails 2.0. It would be a radical departure from the present directory structure. So radical that it would effectively make Rails 2.0 applications incompatible with Rails 1.0 apps. But as we are already dropping support for deprecated features in Rails 2.0, so perhaps it’s time to rethink the directory structure.

Update: There is some interesting discussion going on about this on the Rails-Core mailing list.

Setting Up Ubuntu for Rails

2007-05-03T13:09:00Z

I just found a wonderful little screencast by Geoffrey Grosenbach of Peep Code Screencasts on setting up the full Rails stack on Ubuntu. He’s uploaded it so that anyone can watch it over on the ShowMeDo website.

From the description:

This 10 minute demo shows how easy it is to install Ruby, Rails, Apache, Mongrel, Subversion, and MySQL on an Ubuntu server. Capistrano and the deprec gem (deployment recipes) are used to automate the installation process with only a few commands. It finishes with a deployment of a Rails app to the newly built server! The demo is done with Parallels on a Mac, but would work with any machine that can boot from the Ubuntu 6.06 Live CD.

Props to Geoffrey for his great work with helping Rails newbies (and even “old timers” like me) get their feet wet.

Two Rails Testing Plugins

2007-05-03T01:37:00Z

I just released two Rails plugins that should make testing a little easier for some of you.

The test_helpers plugin makes it easy to DRY up your test cases by moving shared code into modules. It includes the handy dandy “test_helper” class method to make requiring and including a snap.
The abstract_testcases plugin makes it easy to create abstract test cases that don’t complain about tests not being defined. If you’d rather not go the module route, this is the plugin for you.

Installation is just like any other Rails plugin:


% script/plugin source http://wiseheartdesign.com/svn/plugins/
% script/plugin install test_helpers
% script/plugin install abstract_testcases

Comments and feedback are welcome.

So You Want to Write a Book?

2007-03-12T17:29:00Z

Over on Dave Thomas’ Blog he’s writing a unique series of articles entitled So You Want To Write a Book. If you’ve ever thought about writing a technical book, or even a non-technical book you will definitely enjoy the series. Here’s an excerpt from his second article, The Hero’s Journey:

Every Hero’s Journey follows the same basic plan. We start by meeting the protagonist, an average person living a standard life. Suddenly, something bad happens to them, normally something unimaginable and outside their control. At this point, our character must make a decision. Do they cave, or do they commit to face the challenge—do the take a risk an embark on the journey?

Once they join the path, they face a series of challenges, often getting harder or more complex as the story progresses. By overcoming each, the hero gradually masters the initial problem.

But the story never ends there. Once the hero conquers all the problems, they face one last challenge. They must return to the real world, which often feels different to them. However, once back home, they get to apply what they learned on their journey. They are stronger.

What does this have to do with technical books?

Everything.

Because a good technical book is also a hero’s journey. The reader joins the book already faced with a major challenge—they need to learn some new technique or technology. Thy need to make a commitment to follow the path. Along the way, they need to learn stuff, try things, conquering increasingly difficult concepts and challenges. Eventually they graduate; they’ve learned what they came to learn. But they journey doesn’t end there. Like the hero, they then have to come home, bringing back what they learned.

Dave really has a talent for connecting with his readers. Read More…

John's Essential Guide to CSS

2007-02-13T16:07:00Z

I once taught a workshop on CSS and in the process compiled a list of essential reading for people interested learning CSS. I’ve revamped the list below adding a few additional articles and reorganizing it a bit. Most of the articles are from A List Apart, but the volume of articles at A List Apart can can be overwhelming to people just to getting started. Consider this a pocket guide to the best of A List Apart with a few additional links thrown in to spice it up a bit.

The Basics

The Power of Floats and Backgrounds

Faux Columns
Creating Liquid Layouts with Negative Margins
Two Column Tableless Layout
CSS Design: Creating Custom Corners & Borders
Mountain Top Corners
CSS Drop Shadows (1, 2, and 3)

Print Stylesheets & Cross-Browser Compatibility

CSS Design: Going to Print
Print It Your Way
Alternative Style: Working With Alternate Style Sheets
Flash of Unstyled Content
The IE Doubled Float-Margin Bug
The Trouble With EM ’n EN
The Box Model Hack
Position Is Everything has fixes to bugs in IE, Opera, and Firefox

Lists, Rollovers, & Image Replacement Techniques

Secrets of Absolute Positioning

Additional Resources

The Terralien Crew

2006-12-13T21:09:00Z

Nathaniel Talbott (of Test::Unit fame) has put together an unbelievable crew that may be just what you need for your next Ruby on Rails project. Crew members include such notables as:

Myself
Bruce Williams (a popular blogger, programmer, and designer)
Matt McCray (the author of Comatose CMS and the Rails Theme Support Plugin)
Duff O’Melia (the creator of Soapadoo)
And others…

Terralien is a network of designers and programmers who specialize in developing Web applications with Ruby on Rails. We have a reputation for being able to deliver quality code on a deadline through rapid prototyping and incremental release cycles. Read more about the crew on the Terralien Web site.

Introducing FeedChamp: A Camping RSS Feed Aggregator

2006-12-07T16:57:00Z

I went camping last night and decided to see how easy it would be to create an RSS feed aggregator. After just a short time I had a working app and with some additional tweaking it became FeedChamp:

http://wiseheartdesign.com/svn/public/feedchamp/trunk/

Have a look if you can. And if you want to help with its development I’ll gladly give you commit rights to the subversion repository.

It’s not much right now, but perhaps with a little love from a few others it will turn into a nice app. For more info see the README.

Rails Needs Something Better Than Engines

2006-12-06T21:37:00Z

I need to apologize for exploiting a title like the above to introduce an article like this. The Rails Engine guys have taken a lot of flack for the work that they have done to make it easy to share code between applications and I don’t want to add to their misery. Instead, I’d like to use the issue to put the focus on something else.

The traditional argument against Rails Engines (as I understand it) is that prepackaged components are a pipe-dream. Components, particularly the way Rails Engines implements them are just too big. Every application will require something custom, and Rails Engines are too generic. Sure, they work well for getting you up and running, but what about down the road when you need to tweak something that the engine author hasn’t thought about yet? And after all, Rails is so easy to use why not take the agile approach and only develop what you need when you need it?

I’m interested in the Rails Engine argument because I think it exposes something about the philosophy that is driving Rails which may not be extremely obvious to those of us on the sidelines who are just trying to use Rails to build better Web sites and applications. That is that Rails is primarily designed for building completely custom green-field Web applications and it shows. When it comes to sharing code between applications the best thing Rails has to offer is generators. So instead of offering a login engine Rails offers a login generator.

Now don’t get me wrong here, generators are great for getting people up and running quickly. At first glance they offer exactly what Rails engines offer in that they allow you to get up and running quickly with prepackaged code and the added bonus that you can completely customize the generated code. But where they fall down is that they encourage rampant code duplication.

Take the login generator for example. How many of us use the generated login code nearly unmodified in application after application? Even if we customize the generated code is it not true that we often perform the same modifications again and again as we move from one application to another?

Folks we need something better. In a nutshell we need standard way to share views, models, controllers, and URLs between applications.

Of Snakes and Rubies

On December 3rd of last year I helped organize a debate between David Heinemeier Hansson and Adrian Holovaty (the creator of Django). We dubbed the event Snakes and Rubies and the video and audio from it are available here.

Even though I am an avid Rails user I was favorably impressed by Adrian’s presentation on Django and I must say that I am sad to see that more of the ideas in Django have not gained greater traction in the Rails community.

One of the things that Django does better than Rails at the moment is that it encourages you to subdivide your application according to components. In Django terms you don’t just create an “application” you create a Django “project” which contains multiple “apps”. An app is a full slice of the application and contains models, views, and controllers (actually in Django terms it contains “models”, “templates”, and “views”, but it is essentially the same thing).

Django’s model is perfect for Web sites because you can have mini apps for the admin, blog, and forum, and maybe one for that extremely custom event registration system that you have. Of course the great thing about this is that you can share these little mini apps across applications.

As I was working on this article I wrote Adrian Holovaty to ask him about this very point. He wrote back:

This was a big design goal when we were first putting together Django, because at our Web operation, we managed several sites—all of which used bits and pieces of the same functionality, but always a different mix. Indeed, as you point out, Django has a “batteries included” philosophy and ships with some apps that you can choose to use in your own projects.

And how easy is it to use another Django mini app in your own project? All you need to do is include it in the INSTALLED_APPS configuration variable. Here’s a small configuration snippet from the Django tutorial:


INSTALLED_APPS = (
  'django.contrib.auth',
  'django.contrib.contenttypes',
  'django.contrib.sessions',
  'django.contrib.sites',
  'mysite.polls'
)

There are four little mini apps there that are installed by default for the standard Django project: auth, contenttypes, sessions, and sites (I’ll bet you can guess what they do). Django also provides a rather powerful admin mini app that automatically creates an admin interface for your models. This is extremely helpful in that it allows you to concentrate on the Web site part of your application while leaving the admin part to Django. To see all of this in action check out the Django Screencast at throwingbeans.org.

Can Rails Take a Page from the Django Playbook?

I’m interested in all of this because of my work on Radiant (the content management system I developed for the Ruby Web site). Over the past several months I have been working on an extension system for Radiant that will allow others to develop mini rails apps that plug straight into a Radiant application. A Radiant extension is like a Rails plugin except that it supports additional models, views, and controllers (much like Rails Engines do, but with added benefits). The directory structure for a Radiant extension looks like this:


vendor/extensions/
  my_extension/
    app/
      controllers/
      helpers/
      models/
      views/
    lib/
    test/
    my_extension.rb
    Rakefile

The benefit that Radiant Extensions offer over something like Rails Engines is that they integrate into the Radiant administration system. Right now that integration is a little rough, but we hope to make it easier in the future. Even so, the progress that we have made is encouraging. Here’s a snippet which demonstrates adding a custom tab to the Radiant administration system:


class AssetManagerExtension < Radiant::Extension
  version "1.0" 
  description "Provides asset management support for Radiant." 

  define_routes do |map|
    map.connect 'admin/assets/:action', :controller => 'admin/asset'
  end

  def activate
    admin.tabs.add "Assets", "/admin/assets", :after => "Layouts" 
  end

  def deactivate
    admin.tabs.remove "Assets" 
  end 
end

Now the work on the Radiant extension system has been difficult. Rails doesn’t make it easy to allow views to reside in multiple places (there is only one template_root). Nor does it provide support for defining routes in multiple locations. Model reloading through the dependencies mechanism is also a difficult issue. Time and again I find myself twisting Rails’ arm to let me do what I want to do. I’ve had to hook into the Rails internals on multiple occasions (just like the Rails Engines people did).

I can’t help looking beyond Radiant though to wonder if built in support for this kind of thing would not be a benefit to the Rails community at large? I know Rick Olson is working on something like the Radiant extension system for Mephisto and I can see that other apps could be benefited by something similar. We’ve already seen Rails Engines and now there is also Appable Plugins. How many other approaches are necessary before the Rails community is able to settle on a standard?

As the Rails-Core team is looking towards Rails 2.0, perhaps it’s time to start thinking about restructuring Rails applications to take a more modular approach? Maybe there really is something to be learned from Django after all.

Now Using Mephisto!

2006-12-01T02:13:00Z

It may come a surprise to some of you that the author of Radiant is now using Mephisto for his Weblog, but I’ve decided to give it a shot while Radiant is still under development. True blogging support is a couple of months away for Radiant so I figured it would be good to scope out the “competition” in the meantime.

Rick and Justin have done a phenomenal job on Mephisto. It’s simple, the interface is well designed (very professional), and the code underneath is beautiful. The closest thing I can compare it to is Textpattern from the PHP world—and it is much better. Asset management and theme support put it head and shoulders above Textpattern.

As to the Radiant vs. Mephisto argument. I’d say that Mephisto is much better for blogging and probably always will be. Radiant will eventually add support for blogging, but it’s focus will continue to be content management. I want Radiant to be a light-weight CMS, with a blogging engine feel, but blogging will always take second place to content management. This is good news for the Rails community because I think Mephisto’s goal is to be a great blogging engine first and after that a light-weight content management system.

My hat is off to Rick and Justin. Mephisto is definitely a Typo killer.