Haml comes with a script, html2haml, which can take HTML with ERB and convert it nicely to haml. Seeing as I would have to run that command more than once, I have a little command snippet that I like to use to aid with the conversion.

$ find . -name '*erb' | \
xargs ruby -e 'ARGV.each { |i| puts "html2haml -r #{i} #{i.sub(/erb$/,"haml")}"}'

That will print out what the html2haml commands would be, it does not run the command. I do that step such that I can review what will be converted. If I like what’s going to be done, then I just run that command and pipe it into bash…like so

$ find . -name '*erb' | \
xargs ruby -e 'ARGV.each { |i| puts "html2haml -r #{i} #{i.sub(/erb$/,"haml")}"}' | \
bash

If you like it, it probably wouldn’t hurt storing that as a shell script somewhere

With multiple programmers, you can probably expect a versioning system, perhaps a centralized versioning system like SVN or Perforce. With that system, each programmer would make his/her changes and then would check in his/her changes into the repository. From there, the programmer’s peers would review the code.

What’s the problem with this system? The code is already checked in. The pressure is on the peers to ensure that the code is good, and it’s likely that this could slip through the cracks. I mean, those peers are working on getting 10 features complete themselves.

Enter Git

Well, I would argue that Git has a strong code review process built right in. This is due to the process of how distributed version control works.

Programmer A creates a fork of the master project. A makes his changes and commit his code; however, the code is committed to his local repository and not the master origin. This is because A does not have write access to that repository.

A has to contact programmer B, who has write access. A tells B that he should pull his code. Since B has to pull the code, this means that B has to review the code coming in.

It’s this workflow that promotes code review. Now that’s not to say that you can’t do code reviews in a centralized model, it just fits a little better in a distributed model

Ticgit takes a simplistic approach to issue tracking as Lighthouse has done. You can comment, add tags, manage the state of an issue, save views, and change to whom an issue is assigned. There is still more planned, like keeping track of milestones and syncing the tickets to Lighthouse.

As mentioned, there is a web interface to ticgit; however, it wasn’t my cup of tea. So I have started my own web interface, tiwatchtower. It’s still a little rough around the edges, but I would love to hear any thoughts.

Conclusion

So far, I like it and it’s exciting to see how git can be pushed. It’s great for keeping track of things that are on my mind without worrying about having to setup trac or having to use up a Lighthouse project. It’s simple, effective, and worth a look at.

I bought a Flex book to, well, teach myself Flex. The book right now is taking me though one application and is building it out piece by piece. So I began to think: “What if I just keep track of all my changes through git?”

For one, Flex is nice because it’s all XML, so that makes revision tracking fairly easy. Also, git is very easy to get started because you don’t have to do any server setup. Just issue a git init command and get going. Then after each chapter, I can tag the repository for posterity’s sake. And I have to say, it’s been great to see how the code has changes, especially since Flex Builder generates code.

That’s one thing I love about git, and mercurial, it’s so easy to start using version control for even the littlest of tasks.

Essentially, if your column is an enum, then indexing it could actually cause MySQL to do more work. Why? Because the data set is so large, the MySQL ends up doing a full scan. So things like keeping track if something is active (1 or 0) then you can expect indexing to hurt.

So how does this effect ActiveRecord? Well, if you’re keeping track of whether a user is active or not you would not want to index that column alone. Nor would you want to index a type column if you were using single table inheritance, again, because there isn’t a lot of variance in the type.

So make sure that you index the right things, like IDs and leave the enum-like columns alone.

So what does “This software cannot be installed because the file system of the OS volume is not supported” even mean???!?! I tell you what it means, it means that Photoshop will not run if you happened to have formatted your file system to be case sensitive. Thanks for the clear error!

I don’t even want to begin on how insane that sounds to me? So what’s a person to do?

Well, my friend James Gibson suggested that I install Photoshop in Windows and use Photoshop through WMware. Another possibility is to rename directories to make CS3 work.

I think I’m leaning towards the first option as some people are having some issues with the renaming method. Either way, it’s kinda lame.

Actually, you hurt the initiative to get an issue addressed when you make those comments. You see, when you star an issue, you receive emails when that issue gets updated or commented upon. So if an issue has 100 or so “+1″ comments, then whoever put a star on that defect is going to get 100 or so emails. After getting 20 inane emails, one might decide to remove the star from the issue, thus lowering it’s rating and hurting the campaign.

So please, if you want to help, just star the issue.

Well my friends, fear not. If you enjoy the sweet freedom of RESTful urls, I’m here to help. Since this is all built on top of WSGI, we can create a some new Middleware to sit before the application to resolve this little issue.

MockHTTPMethodMiddleware

from google.appengine.ext import webapp

class MockHTTPMethodMiddleware(object):
  def __init__(self, app):
    self.app = app

  def __call__(self, environ, start_response):
    method = webapp.Request(environ).get('_method')
    if method:
      environ['REQUEST_METHOD'] = method.upper()
    return self.app(environ, start_response)

The code is pretty simple. So when this middleware is called, it processes the environ into a Request object. From there, I just inspect the params for a key called _method. If that param exists, then it overwrites the REQUEST_METHOD and bam…we have mocked the HTTP method of our choosing.

Putting that code to good use

Let’s pretend that this is our class is something inane like this:

from google.appengine.ext import webapp

class MethodTest(webapp.RequestHandler):
  def get(self):
    self.response.headers["Content-Type"] = 'text/text'
    self.response.out.write("Get")
  
  def put(self):
    self.response.headers["Content-Type"] = 'text/text'
    self.response.out.write("Put")

So now when you are writing your main method that creates the WSGI application, you would write it something like:

import wsgiref.handlers

def main():
  app = webapp.WSGIApplication(
      [('/', MethodTest)], 
      debug=True)
  wsgiref.handlers.CGIHandler().run(MockHTTPMethodMiddleware(app))

if __name__ == "__main__":
  main()

Notice that in the run method arguments, MockHTTPMethodMiddleware takes app as a parameter, thus MockHTTPMethodMiddleware will run before it runs app.

Conclusion

While there wasn’t support out of the box for mocking HTTP methods for browsers, with a little help from a WSGI Middleware class, it’s not too hard to add that functionality in, nor is it hard to add anything else you would want to use.

Prerequisites

Now I don’t want to go too deep into this, so I’m going to assume that if you are reading this, that you have the following installed

• Mac OS Developer’s Tools
• MacPorts
• Ruby (comes with Leopard)
  • Ruby Gems (also comes with Leopard)

Installation

So now that you have all of those dependencies out of the way, let’s get to installing us some PostgreSQL.

PostgreSQL

To install the database software, simply run the following command in Terminal

sudo port install \
  postgresql83 \
  postgresql83-server

This will install the client and server needed for you to run this on your machine. Now pay special attention to the installation script. At the end of installation processes, macports will display a message for you that contains some commands for you to get started with.

Configuration

First, execute these lines of code. This will setup a new database for you to play with

sudo mkdir -p /opt/local/var/db/postgresql83/defaultdb
sudo chown postgres:postgres /opt/local/var/db/postgresql83/defaultdb
sudo su postgres -c '/opt/local/lib/postgresql83/bin/initdb -D /opt/local/var/db/postgresql83/defaultdb'

Start PostgreSQL Automatically

By running the next command, you can have PostgreSQL lunch automatically so that it’s always available to you

sudo launchctl load -w /Library/LaunchDaemons/org.macports.postgresql83-server.plist

pgAdmin III

pgAdmin III is a PostgreSQL management and administrations piece of software. It’s a nice GUI to some things that you may find yourself wanting to do, like created databases and whatnot. Installation of this is pretty cake.

sudo port install pgAdmin3

Upon completion of installation, you can find the application in /Applications/MacPorts/pgAdmin3

PostgreSQL Libraries for Ruby via Gems

I have to admit, the previous installation steps were nothing to cry about; however, it was this step that made me want to put together this little walkthrough.

sudo env ARCHFLAGS="-arch i386" \
  gem install postgres -- \
  --with-pgsql-lib=/opt/local/lib/postgresql83 \
  --with-pgsql-include=/opt/local/include/postgresql83

That’s not exactly your everyday gem install command. For one, the environment variable ARCHFLAGS has to be set. Secondly, the gem command needs to know where the PostgreSQL libraries and include headers are so that it can compile. Looking back, it’s actually quite easy to copy and paste that command, it just took me a while to find out exactly what I needed to make it work.

Fin

Well, I hope that helps anyone looking to install and setup PostgreSQL in Leopard. Until next time…