Posted by John on October 26th, 2007
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!
Posted by John on September 25th, 2007
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…
Posted by John on September 3rd, 2007
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
Posted by John on August 25th, 2007
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.
Posted by John on August 25th, 2007
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 and before working on features.
