Wednesday, September 23, 2009

self become: PolyGlot

I'm checking out Clamato, a Smalltalk dialect implemented in Javascript to make the coding of web client interfaces a bit more sane. (we are already up to two languages in this post). It was created by the folks at Dabble DB this summer.

Definitely check out the tutorial pointed to on the Clamato site - the code browser is well designed with efficient workflow in mind. For finding code you effectively have the senders and implementors functionality of a traditional Smalltalk browser, but in an elegant and compact UI. Kudos to the Dabble DB folks there - their UI design skills are top notch.

I want to play with Clamato both inside and outside of a web browser, so I decided to grap v8, which is what I believe the Dabble DB folks use when doing debugging. Naturally, I browsed my way over to Google and figured out how to download v8 (svn repository) by reading the build instructions.

To build v8, you need SCons, which is a software build system analogous to the GNU autoconf tools; SCons is written in Python (there's three!). No problem, right? I write a lot of code in Python, nearly every day in fact.

I first tried the Python install tools I have on hand, and did
pip install scons


... Which resulted in a nice error:
error: option --single-version-externally-managed not recognized


... at this point, trying to play with a Smalltalk dialect implemented in JavaScript, I didn't really want to chase down why this failed, since pip is still experimental. So I did the old-school Python routine:
python ./setup.py install


This seemed to work fine. No errors... until I tried to use it. I changed back to the v8 source tree I had downloaded, and following the instructions typed scons. This produced a Python traceback:
> scons
Traceback (most recent call last):
File "/Users/brian/.bin/py/scons", line 162, in
import SCons.Script
ImportError: No module named SCons.Script


Hmpf. That says to me, "The module is missing from the site-packages". So I went and looked. Not there. Cool. $SYS$WHAT???

Fine. The developers best friend to the rescue. Google turned up this nugget for me:
Hi David--

>> Now, SCons installed it self in $HOME/local/lib
>
> At one point, I wondered why scons installed
> itself in lib instead of lib/python-version/site-packages.
> What is the rationale for this ?

To make it easier to install and compare multiple versions of SCons side-by-side.

In enterprise development organizations, the biggest barrier to upgrading a tool isn't technically whether you can push a button (like setup.py) and have it installed. The biggest challenge is being able to compare the behavior of the old and new versions and verify the new behavior doesn't introduce any relevant problems. So we wanted to make it convenient for people to experiment with a new version without having to uninstall (or install over) the old version, or dedicate a separate system to the project, or do a lot of other custom work.

In essence, we've tried to make SCons more like a standalone application that happens to use Python, instead of a Python application that only exists "within" the Python installation itself. This separation also allows you, for example, to experiment with your Python version without having to re-install SCons.

How well we've done with this overall is debatable, though, in no small part because Python's distutils and the like are so much more geared towards installing Python packages and not separate applications. Note that the hacking we've done on our setup.py does allow you to install into the site-package/ subdirectory if you wish, using an extended --standard-lib option.

HTH,

--SK


Ok, so I next tried:
python ./setup.py install --standard-lib


and SCons was working. I can happily report that v8 is compiled, and now I will play more with Clamato!

My theory is that since the SCons folks hacked the setup.py file, pip is using a newer version, so the option isn't common between the two. I might have to research that. might...

It is amazing to me how much knowledge is required to play in this space, and how much reuse of code is happening. I had to touch three languages just to get set up the way I wanted, and as I learn, I already anticipate the need for knowledge about JQuery, Smalltalk, CSS, JavaScript, and some web server technology (Seaside for me, please).

More about Clamato and Seaside later....

Monday, June 29, 2009

self selectLang: #ruby

This post is ostensibly about my first foray into the world of ruby - not the language per se, but the everything around the language. I'll get to that eventually, but first a bit of background and blog filler.....

I tend to manage a lot of software projects - the company I work for does a lot of research in the cognitive disability area, and builds software for people with intellectual disabilities. With lot's of little projects - some that go on to become commercial and some that never make it past the prototype stage - it becomes quite painful to manage them and keep a decent level of corporate memory around and accessible. On top of that, I'm part of company that has published several packages of Open Source software, and that all needs to be managed as well.

I'm not really talking about managing people so much as managing the technical infrastructure of a given project; code repositories, setting up the development environment, tracking features, bugs, requests and that sort of thing. Consequently, I'm always on the hunt for tools that make this job a bit easier, and actually allow cross-project management.

For example, once-upon-a-time I ran across Trac from Edgewall. It is written in Python, and, since I do a great deal of development in python, I thought, "Great! If I have a problem, I can fix it, or extend it!". And technically, I could.

So we dove into Trac and built a structure for the Trac instances, tied each project to an SVN repository and taught developers how they can reference bug numbers in the check-in comments. I even created a Trac plugin that enumerated a series of Trac installations and created links to them, so it was easy to go to one starting point and see all the other Trac'd projects. Each of them had their own Issue tracker, wiki, etc. I happily started filling up information on a couple of the 20+ projects that existed. Then I started getting others developers to take a look and start recording information and issues into the system.

Pretty cool all in all.

Operationally though, having 20+ separate issue trackers with no way to get an overview is, well, dumber than a box of rocks (DTaBoR... probably not going to catch on as an acronym any time soon).

Nobody wants to, um, trac things down, as it were, so the result is some very old and currently inaccurate information on the sites that nobody looks at anymore. When your time spent managing the bug tracker overcomes the time actually writing code, it's time to do something different.

What to do? We wanted the benefits of a tool like this; I could change Trac, or hope something better comes along. Also, this kind of tool is not my core business, if you know what I mean. I don't have a passion for building that kind of tool, so my spare time isn't going to be spent there, especially on a major overhaul to support multiple projects.

So, yeah, Trac - it is really good for managing one project, and they have been planning on cross-project support for some time, but so far, not so much.

We limped along for quite a while without any tool at all, unless you count email. I evaluated a lot of issue trackers, and toyed with writing something myself, in Seaside of course, but time is always in short supply. Finally, I stumbled onto Redmine.

First off, it's a Ruby-On-Rails app. RoR gets a lot of press these days and a lot of nice applications have been written using that framework. My initial reaction is usually something along the lines of, "Do I want to learn how to install YAF? Couldn't they have written it something I already know?"... and various other Vintages of Whine. But the feature set is so compelling!

So, I decided to bite the proverbial bullet and try to get this sucker running. Of course, getting a web framework running is more an exercise in system administration than in anything "Web". And the target OS in this case? OpenBSD.

MySQL was already installed, so no problem there. Apache is also, installed... 1.x. It seems the OpenBSD folks didn't like the apache license change, so are not going to Apache 2. Hmm, people don't seem to be writing new plugins for 1.x so I'll have to explore the possibilities of putting RoR behind apache 1. For now, webbrick (the built in ruby webserver) will suffice.

The basic install of Ruby was easy on this platform:

sudo pkg_add ruby

After this, I was introduced to the RubyGems package, which is a package management tool for Ruby, and I must say that it is quite nice. I've used CPAN (perl), DistUtils (python), and Universes (Squeak/Pharo), and I think Ruby really has something going it for it there. It was completely painless to add the packages I needed... well, mostly.

I did have to research what the package names on OpenBSD were to get some things installed, and hunted a lot until I was able to figure out an error with iconv. Overall though, it went quite well for a first time.

I did struggle a bit with the order of things. For example, on the Redmine install page, you are to run:

gem install rails -v 2.2.2

Which, if you just installed Ruby, it doesn't know about that version of Rails. You have to update RubyGems first, then it works well. You also have to be careful of your Redmine versions - there are a lot of very cool plugins for the system, but some only work with SVN version, and you'll get several errors if you don't have the correct version of Rails installed.

Redmine is very, very nice and has the features for cross-project management that I have been wanting for years. SO, even though all the software we are managing with Redmine on the TechGame site are written in Python, we'll use ruby to manage the process :-)

Thursday, June 4, 2009

A strategy for picking a coding language...

CollectionOfLanguages do: 
[:lang |
lang sucksOrResemblesC
ifTrue: [
lang useWhenForcedTo]
ifFalse: [
lang useWhenAppropriate]]


It shows a sort of bias...