Markjuh

Hanging FCGI-processes with Edge Rails and lighttp

2005-09-26T14:51:28+02:00

For quite some time now, if you use lighttpd combined with Edge Rails, the Rails FCGI-processes don’t terminate when lighttpd terminates. This is strange, since lighttpd sends the TERM signal to the FCGI-processes. I had to use a kill -9 to actually end the FCGI-processes.

Rick Olson confirmed this behaviour and we tried to track it down. We couldn’t find it back then, but since then I got SO annoyed that I looked into it a bit more.

It seems that the problem is in vendor/rails/railties/lib/fcgi_handler.rb. It shows that the TERM signal is handled by the graceful_exit_handler. This handler sets whenready to :exit, which should make sure that the FCGI-process ends after processing the current or next FCGI-request.

And now this last part exactly forms the problem. When lighttpd terminates, the FCGI-process is waiting for the next request to come so it can finish gracefully. But the next request never comes, since lighttpd is already down, so there is no process to send requests to the FCGI-process.

So, I’ve written a dirty hack to fix this problem. David Heinemeier Hansson already promised to fix it the right way, but I just couldn’t wait for that to happen. (Using kill -9 every time you restart the webserver is just too annoying.)

Unexpected characters when using Prototype (AJAX)

2005-09-26T13:27:17+02:00

A little while back someone pointed me at the weird behaviour of my preview box when adding a comment. Somehow &_= was added to the end of the preview content.

It took me quite some time to figure out where it was coming from. I searched and searched, but couldn’t find the problem. I thought it wouldn’t be a Prototype bug, since Rails had been updated, but Prototype hadn’t changed.

So I asked around in #rubyonrails and Thomas Fuchs pointed me in the right direction.

It seemed changeset 2106 in Rails changed the way a Safari bug was tackled. It had been the case that Prototype added the &_= to the end of the POST data and ActionPack would strip this away again. But since another fix was found for this problem, there was no need for the &_= anymore.

So the following (line 213, or in the latest Edge Rails version line 476) should be removed from prototype.js:

if (parameters.length > 0) parameters += '&_=';

I had already discovered that removing the line fixed the problem, but it was good to find the reason why. And I’ve filed it as ticket 2258.

How to make sure an attribute doesn't get updated

2005-08-08T10:55:17+02:00

I have a Rails model in which I don’t want the title attribute to change. I implemented this with a before_update:

  before_update :check_title_unchanged

  protected

  def check_title_unchanged
    Post.find(id).title == title
  end

This didn’t quite work because of an ActiveRecord bug I wrote about before.

When talking to Michael Koziarski at #rubyonrails about this bug, he made clear that I have at least one problem with my code and that I could have made a different implementation.

First to tackle the real problem in my code. The problem with my implementation is that it isn’t thread-safe, because the title could have been changed by another thread after we’ve fetched the object from the database. And hence our title wouldn’t have changed, but we still wouldn’t be able to save our model.

So the better way of doing it is by adding an after_find which is documented at the Rails Wiki. And also updating the before_update method accordingly.

  before_update :check_title_unchanged

  attr_accessor :original_title

  protected

  def after_find
    @original_title = title
  end

  def check_title_unchanged
    @original_title == title
  end

Now to take a look at another approach to tackle this. We could also override the validate method. The validate method has the following documentation:

Overwrite this method for validation checks on all saves and use Errors.add(field, msg) for invalid attributes.

So we could now change our code to:

  attr_accessor :original_title

  protected

  def after_find
    @original_title = title
  end

  def validate
    @original_title==title
  end

And if we would want to make it really nice, we would use Errors.add to add a descriptive error message, which is then added to the list of errors that will be displayed by error_messages_for. This would be the only reason I would use this approach instead of using a before_update.

So we could do:

  def validate
    result = (@original_title==title)

    if !result
      Errors.add(:title, "Title cannot be changed.")
    end
  end

Conclusion: in my project I have no use for the error message, so I don’t really see the point in overriding the validate method. But now I at least know the available options and can choose one wisely. So if I just need to make sure the title cannot be updated by a programming mistake in a controller, I use the before_update. If the user needs to be presented with a nice error message why they cannot change the title, then I would choose for overriding the validate method.

Update: I tried to put this nice piece of code to work, but it breaks my CRUD tests. My CRUD tests might behave a little different from the actual application, but still, they shouldn’t break. I actually create an object, save it, update it and then save it again. This failed, because I did not do a find for the same object and hence original_title is not yet set. So I’ll leave my implementation as it is currently. The issue with thread-safety is not that shocking in my case, since the title really shouldn’t be changed anyway.

Significance of Unit Testing in Rails

2005-08-07T03:14:54+02:00

Today I’ve been explaining some basics of Ruby on Rails to a friend of mine. With a couple of friends we’re building a front-end for LEDR, which is basically an educational document repository, which we intend to use at Eindhoven University of Technology.

We only went into the model part of the MVC design pattern. And since Rails applications are especially suited for Test Driven Development, I decided to start showing Rails by writing unit tests. So we first started with the generation of a model and then wrote some basic CRUD tests for them. We had been writing down requirements for some of our models earlier today and could now write these requirements in the tests directly. We heavily borrowed test code from other projects I’m doing. So we had some default tests for each possible model requirement we had come up with.

Time to run rake! And boy, did we get failures and errors!

We were using SQLite, had created the databases and even made sure config/database.yml contained the right settings. All nice, but we had forgotten to install sqlite-ruby on our development system. (Ironically enough, our production server already has it installed.) We should have definitely read Howto Use SQLite in Rails a bit better.

If you are not even interested in writing tests, running the automatically generated test for the model would have already shown this.

After getting this out of the way, our tests were still failing… Well, duh! We forgot to even create a table in the database for the model. Again, just running the automatically generated test would have shown this.

So, writing the table and importing it in SQLite (which by the way is a painful process when you are used to PHPMyAdmin or YourSQL for all your database editing) solved at least a bunch of the errors/failures. Basic CRUD tests were now at least passing.

So on with the more interesting aspects. Our tests clearly showed we were missing validates_presence_of, validates_uniqueness_of and validates_format_of. Since we had some well-defined tests, it was really clear what to add in the corresponding model.

Still, one test was failing… The test that made sure that we couldn’t change the code field of the model. Maybe not as clear, but after some thinking we added the following straightforward before_update to the model:


  def check_code_changed
    Course.find(id).code == code
  end

Now our test should have all passed.

Unfortunately there is a bug in Rails I wrote about some time ago. So we first had to apply the patch I had made for the bug. Then everything worked just fine.

After this we wrote another two models and created relationships between them, all driven by tests defined before actually writing any model code. And every since test-case that failed showed us exactly where we had to find the problem and showed us at least a hint of where to find our mistakes or where to add model code; even more specific, it often showed us which code to add.

We also had a problem in the SQL code that updated our SQLite database. It wasn’t actually a query performed by Rails, but we needed it to update our table to the lastest version. We had totally forgotten to add a commit at the end of the transaction. Our tests showed our missing field in the table quite nicely.

I can conclude that it convinced us both that Test Driven Development is the way to go when developing Rails applications. It helps you detect so many things, sometimes not even directly related to the specific model (as we can see above). Lots of times before I had seen tests as a necessary evil, but today we both got really excited by writing tests and seeing all the positive results we got from it. Our tests even made it possible to write Rails code after having a couple of glasses of wine. ;)

Rails ActiveRecord bug

2005-07-29T16:43:42+02:00

Today I had to make sure a model couldn’t be saved if someone tried to update a certain field.

Reading in the API documentation I found the following:

If a before_* callback returns false, all the later callbacks and the associated action are cancelled.

So a before_update callback in my model would be the solution. I just had to make sure it would return false in the right cases.

Because of the last three months of test-driven development, I decided to write a test first. And to my surprise I could always save the model, even if my before_update callback would always return false. First I double-checked my test, but it was okay. Time to use yet another great tool in Rails: script/console.

It showed that even though the save method always returned true, it in fact did not save the model. So fortunately no problem with the before_update callback. This meant that there was no way avoiding it anymore… I would take my first dive into the ActiveRecord code.

After quite some time of searching back and forth through a couple of Ruby files, I found the problem:


def create_or_update
  if new_record? then create else update end
  true
end

And see here, it always returns true instead of the actual result from create or update. Why? Well, probably because there would be a problem in the create method:


def create
  self.id = connection.insert(
    "INSERT INTO #{self.class.table_name} " +
    "(#{quoted_column_names.join(', ')}) " +
    "VALUES(#{attributes_with_quotes.values.join(', ')})",
    "#{self.class.name} Create",
    self.class.primary_key, self.id, self.class.sequence_name
  )     

  @new_record = false 
end

This create method returns the value of new_record (which is false), instead of the result of the query (self.id).

I’ve written a simple patch (see ticket #1861), which solves my problems and doesn’t introduce any new problems in my application. But again, it would be good to have a test for ActiveRecord. The problem is that I’m just not well-acquainted with ActiveRecord, so I have no idea where or how to incorporate the test. Any help with this would be greatly appreciated.

Sword

2005-07-27T22:30:24+02:00

This blog has now moved to my own machine and it’s running Sword.

Since most people will not be interested in every note I make about this project, I’ve moved the frequent and detailed posts about Sword to it’s own blog. It will mostly contain posts about new versions and features.

This blog will contain things I’ve uncovered during Rails development. Interesting behaviour or pieces of Rails code that might be of interest.

Back up again

2005-07-05T14:14:23+02:00

Finally I’ve been able to get this blog up and running again after somehow going down and not being able to start up again.

I checked the lighttpd.conf file, but I couldn’t find anything that was wrong. But after throwing away the configuration file and setting it up again from scratch, it now works again!

Prototype adjustment

2005-05-30T12:56:14+02:00

The little error I just fixed made me look at some minor issues with running this prototype.

I used Keeping your lighttpd up on TextDrive, part II to make sure lighttpd would be restarted if the Rails FastCGI process had died.

And I also added Pagination to the main weblog part so the page that needs to be loaded is smaller than before (only 5 posts instead of all of them).

Annoying bug

2005-05-30T11:38:00+02:00

Since Textdrive moved bidwell to new hardware, this application doesn’t seem to function as well as before.

As a first step I’ve removed the contents of the vendor directory and restarted lighttpd, so the gem versions of the Rails components will be used.

Now to figure out why posting fails.

Update: I guess that was it, it’s fully functional again.

Routing

2005-05-13T08:34:26+02:00

I’ve been diving into routing the last two weeks. It’s a great concept, but the code is hard to get through.

One thing that had me puzzled for several hours was that I wasn’t able to break the routing tests, no matter what I did. It turned out there was an error in the filename of the file that contains the routing tests.

After fixing this simple problem, I added support for domains and subdomains to vendor/rails/actionpack/lib/action_controller/routing.rb. The Route::items= method now sets an optional part in array that contains the routing information.

[[domain_info], path_info], where if domain_info is empty, it reduces to [path_info], which is just the regular case it used to be without any domain/subdomain additions.

This makes sure that I did not break existing behaviour, yet provides a way to identify the new items.

Unfortunately, also changes to the test-functions are needed, since currently verify_recognize and verify_generate do not accept / as a prefix for the path. And the possibility to use this prefix is essential in our extension of routing, since we would like to use the following scheme in our application:

//:weblog.ourdomain.org/:year/:month/:day/:post

(the nice Route::items= method would give us [[:weblog, "ourdomain", "org"], :year, :month, :day, :post] here)

Furthermore, the flow of information through the UrlRewrite::rewrite method would need to change. The following implementation would not work anymore:

rewrite_url(rewrite_path(options), options)

But instead rewrite_path should also update the options in a smart way.

Since this is too much of a hassle at the moment, we decided to drop this for a bit and go ahead with the implementation of the pilot version and use URIs of the form /:weblog/:year/:month/:day/:post/.

Daedalus

2005-05-02T12:50:00+02:00

I waited for the transfer of bidwell (one of the shared hosting servers of TextDrive) to the new hardware and took some time today to figure out how to get Daedalus to work, so it would monitor lighttpd and restart it if it would crash.

$ mkdir ~/src
$ cd ~/src
$ wget http://svn.textdrive.com/repos/scripts/daedalus-1.2.tar.bz2
$ tar xjvf daedalus-1.2.tar.bz2
$ mkdir ~/daedalus
$ cd ~/daedalus
$ cp ~/src/daedalus/daedalus.rb .
$ mkdir log run
$ wget http://blog.fngtps.textdriven.com/daedalus.conf
$ ./daedalus.rb

And it was up and running.
Just to be sure, I added a cron job to make sure Daedalus gets started each time the server is rebooted.

Of course I cheated and prepared the config file (daedalus.conf) in advance:

name: lighttpd
checkcommand: /bin/ps ax
checkregex: /lighttpd/
onfailcommand: /usr/local/sbin/lighttpd -f /home/thijs/lighttpd/lighttpd.conf
checkinterval: 30
aftercommandwait: 15

Caching (2)

2005-04-18T15:18:40+02:00

Now that I had caching at least working, it was time to get it the way I wanted it to work. Page caching turned out to be quite nice if you are just looking at the page as a visitor, but then after you login, you cannot edit anything, because the links just don’t show up. This is not that weird, since I was caching the whole page and invalidating the page just because someone logs in is a bit silly.

So, then I did some research and it turned out that action caching wasn’t the thing for me either, so I turned to fragment caching. After some initial confusion it turned out to be quite simple and fast.

I also tried to use memcached on my development machine at home. After installing Ruby-MemCache and it’s required libraries and adding the following line to config/environments/development.rb, it worked quite nicely:

ActionController::Base.fragment_cache_store = ActionController::Caching::Fragments::MemCacheStore.new("localhost")

So why use memcached instead of the default MemoryStore? Well, the default MemoryStore creates its own fragment store for each FCGI-process. So it would create more of a burden on your system then just using one central fragment store.

Caching

2005-04-15T16:24:00+02:00

I’ve been trying to get page caching to work. All to no avail, until I asked around in the Ruby on Rails IRC channel. It turned out that in version 0.11.1 caching of pages is broken and that updating to Edge Rails solved the problem.

This was the perfect time to change my repository around and move the vendor part into a SVN external.

lighttpd

2005-04-15T08:37:00+02:00

Just switched this Rails application to FastCGI on lighttpd. And it’s no surprise at all that lighttpd is much faster, since I’ve been using it on my development-machine ever since I started on Rails-applications.

So finally, this blog is a bit more usable. :)

For those of you wondering how I’ve set this up, have a look at (which is what I found when I was looking how to do this):
Having one’s own lighttpd and running it too

So now what?

2005-04-14T20:43:00+02:00

Well, I still have to figure out caching and build support for multiple users. And if possible, try out itex2mml, which basically converts a subset of L^aT_eX to MathML.

Before anyone comments on it, yes, this does look like WordPress and Typo, but that’s not strange. Typo took it from WordPress and I took some of both. Since it is supposed to be a prototype, I’m not taking the time to make a different design. This one is just clean, nice and readily available.

Prototype online at Textdrive

2005-04-14T20:26:00+02:00

Yesterday and today I’ve been trying to get this prototype online at TextDrive.

Once you know how to install it, it’s quite simple. But there are some pitfalls. First thing I ran into was that I couldn’t get Apache properly configured. But it turned out I had to disable *.fngtps.textdriven.com or otherwise blog.fngtps.textdriven.com wouldn't work. Then it worked just fine, but just with CGI, which is slow. But I couldn’t get FastCGI to work properly. Someone was kind enough to tell me that there were some problems with the combination of Apache2 and FastCGI on TextDrive. Still have to switch to lighttpd and use Apache2 as a proxy. At least so far it works.

Next obstacle was MySQL… It doesn’t complain when you make tables with the InnoDB engine, but as soon as you try to insert values into the table, it returns an error (#1030 - Got error -1 from storage engine). It took me hours of searching on Google and trying things to figure out that just switching to MyISAM fixed the problem.

Then once it was online, I disabled the signup-functionality of the login generator I used, imported the blog entries I had been typing in a text-file.

Then I found out my Atom feeds were containing quite a few errors, so I found a feed validator and the The Atom Syndication Format 0.3, which helped me correct the mistakes I had ignorantly made.

Only annoying thing left was that I had no real titles for each post, so I took some time to read what I had written before and come up with a title. :)

Ajax makes life more fun :)

2005-04-13T11:09:00+02:00

So, what have I been doing since last Friday?

Well, I’ve been busy with the prototype I’m building. Not quite sure what I did exactly on which day, but so far I’ve got comments to work. Mostly adding comments Ajax-style. Ajax, shorthand for Asynchronous JavaScript + XML, makes web interfaces more interactive. It relies heavily on XMLHttpRequest, which enables the use of asynchronous server communication. For more information see Ajax: A New Approach to Web Applications.
After that I added deleting of comments. Having done this in a more traditional way, I had to wait for a new page every time I deleted a comment. Since this too was annoying, I used Ajax here too. And it sure made the page more responsive.

I’ve also added very basic authentication support, which basically boils down to having to login to be able to edit, delete or post a new entry. During this process, I made sure that users who are not logged in are shielded from all this management functionaly.

Next in line is support for multiple blogs and after that caching is waiting around the corner.

Shifting design perspective

2005-04-07T23:23:00+02:00

Today I got home around 13:00 after having a hard time with the trains yesterday and today.

So, after lunch, I started working on the prototype of the blogging application, which is what I’ve mostly been busy with since Tuesday.

Tuesday I mostly learned how to deal with database design in combination with Rails and how to use the console script to test your models. My first idea was to define my foreign keys as NOT NULL, but this gives the key a default value of 0. In it’s own not much of a problem. I thought that validates_presence_of and validates_associated would take care of this and not accept non-existant foreign key values. But that wasn’t quite right.
So then my idea was to enforce the foreign key constraint directly in the database. But this made sure I could never get my unit tests to work again, since you cannot independently test one of the tables of the one-to-many relationship. Back to the old idea then. But now defined my foreign keys as NULL and giving them a default value of NULL. This at least makes validates_presence_of work and you have to actually change the value of the foreign key to be able to save a record.

But setting a default value of NULL is ugly, right? Sure, if you are looking at it from the old RDBMS-view, that’s absolutely right. But we are now looking at it from the Rails side, which is quite innovative. I had a hard time grasping this too at first, but after a day of discussing it, I remembered an article by Date I had read a couple of years ago in which he argued (quite well I must say) that a RDBMS combined with business logic is in itself again a RDBMS. So when you look at Rails, you have to see for example MySQL + ActiveRecord + models as the RDBMS. And when you take that perspective, it all makes sense. It’s not MySQL anymore that does the constraints, it’s actually defined in the models, so you can use the DRY (Don’t Repeat Yourself) way of working.

Then Wednesday, I’ve mostly been busy with giving functional tests a try and working on the controller and view part of adding a new post to the blog.

Which brings me to the work of today. Mostly been working at some functional tests, getting some green lights and finally some refactoring (mostly of views). I really like working TDD-style, but it annoys me that it’s so hard to write functional tests.

Tomorrow I want to work out comments, logins and creation of new blogs (which requires some database remodeling). So that will mostly be “yay for refactoring”-day.

Mondays

2005-04-05T11:02:00+02:00

Yesterday was a typical Monday. Lots of things just didn’t work out the way you expected them to go.

But in the process of writing the use case/evaluation for Blogger, I found out that I had overseen some details and that it was actually a better blogging site than expected.

Other than that, I’ve been watching Thijs being busy with a nice script that creates a graph of the Rails models in your project. See Graphing graphers graphically for more information. Although it contained some bugs, it surely helped us to spot errors in the model code. And while we were playing around with this script, Thijs was also trying out single table inheritance. It took him some time to get it working, but we both learned a lot from it.

Thijs left early, I finished up some documentation and read how components are supposed to work in Rails.
For the most part, it was a typical 8:30 to 16:30 day, which I normally don’t have. :)

FlySketch to the rescue!

2005-04-04T09:52:00+02:00

So, what did I do last Friday?

Mostly, I’ve been busy all day with making screenshots of all those beautiful (read: annoying) weblog tools/sites. Fortunately Thijs came up with a nice application which helped me to get all the screenshots and yellow markings on those shots done in just one day, called FlySketch”. So basically, today I will be busy with working out the use cases and getting the images in.

Furthermore, this morning (in the train from Eindhoven to Utrecht), I’ve been playing around with the console script of Rails to see how I can interact with database models that way. It was interesting to find out how it all works.

TDD (2)

2005-03-30T23:40:00+02:00

This afternoon and evening I’ve been reading a bit more in the fabulous book by Kent Beck. Not quite sure when I finished doing work today, since I’ve done a few things in between. But the reading really made me want to do some serious test-driven development. :)

Test-Driven Development

2005-03-30T19:26:00+02:00

This morning, I started working around 9:15. After catching up with the Rails weblog, I started reading “Test-Driven Development (By Example)” by Kent Beck. I’ve finished Part I and so far it has been quite inspiring. It has some nice parallels to the way Multiprogramming is taught by Wim Feijen at our university; in this course you learn to first focus on the simplest possible correct implementation and then worry about progress requirements. To make the parallels more explicit, I like to point out constructing correct implementations from a specification is not so different from making tests and trying to implement the simplest possible thing that fulfills these tests. The test can be seen as a sort of specification in this TDD-methodology. Often it occurs that the progress requirements in multiprogramming problems require you to do refactoring of the implementation. So far TDD sounds logical and actually gives testing a better place in the way I think about programming.

The Fibonacci-example in Appendix II made it clear that it fits really well with the formal programming style I learned in university. I think I’ll write a comparison of the two methods of working later when I have some spare time.

Using Instiki

2005-03-30T17:19:00+02:00

Yesterday, I left work around 17:15. It took me some part of the day to document some user interface related things in Instiki”, a wiki-system built upon Rails. I thought Instiki would be helpful, but weird enough the stable version had a few annoying bugs which bothered me. After some research, I found out that the problem was fixed in the SVN-version of Instiki. On the one hand this has cost some precious time, but on the other hand it had me looking at several Rails and RedCloth (library for Textile support) topics.

What will I be doing?

2005-03-29T10:36:00+02:00

Today, I arrived half an hour late at work, because the NS decided to cancel a train. So, I arrived around 9:00. Then around 9:45, Thijs and I had a brief meeting to discuss what I have been doing and what we both expect to do the coming weeks and more specifically, what I will be doing this week. He suggested that I should also make a quick, functional prototype and write unit tests for the models and also some functional tests. It will be nice to at least briefly touch every aspect of the Rails framework and see what kind of troubles you can run into.

Blogging systems

2005-03-24T16:55:00+01:00

So, what did I do today besides fucking up two important files? Well, mostly been busy with blogging engines today.

I first registered with Six Apart to be able to test their TypePad online blogging service and download Movable Type, which you can install on your own webserver. Getting a TypeKey is quite an annoying process ~~- if I didn’t have to research this, I would have stopped after 1 minute of annoyance –~~ but finally I got everything to work. I got an error message somewhere and filled out an error report and to my amazement they looked at it, pointed me in the right direction and didn’t forget to mention that by the looks of it in their logs, I had figured out what to do myself. So, buggy process, but good feedback. Installing Movable Type was alright, but more annoying than other products.

Then registering with Blogger... This went really painless, just enter some information and you’re good to go. The only negative thing I found so far is that they don’t send an email to confirm your account.

So, which leaves us with WordPress. No registration to be able to download anything, easy installation ~~- once you figure out that you have to set cgi.fix_pathinfo = 1 in your php.ini –~~ and good usability.

Which leaves me with the installation of Typo, which I will do tomorrow morning. And then I’m ready to make use cases and screenshots of the different blogging systems. But for now, I call it a day, after working from 8:30 to about 17:15.

Debian vs MacOS X

2005-03-24T14:57:00+01:00

I just accidentally copied some files to the wrong location and in turn destroyed the already existing files… As a result of this, I lost my entry of what I did yesterday (which was on my notebook) and I lost all of my bookmarks on my desktop. The entry of yesterday’s work is unfortunate, but not unrepairable. But my bookmarks… Damn! Lost hundreds of handy bookmarks. Especially losing locations of HTML/CSS-related stuff and homepages of people bugs me.

Anyway, let me first recover ~~- briefly –~~ what I did yesterday. I installed a virtual desktop program to make my working experience even more fun. Then I was confronted with all kinds of package-stuff I was taking for granted on my Debian systems.

For example, installing a new version of MySQL on my machine. Installing the new version is not much of a problem, but purging the old package… There is just no predefined way of doing that, so the simplest solution is just to keep it hanging around and let it clog up your system.

Furthermore I had an issue with Ruby-FCGI. It seems the default Ruby-installation doesn’t come with that on MacOS X. No wonder I couldn’t get Rails to work. So I had to go and fetch the source, apply patches, build and install it myself. Quite annoying when you are used to automatically having dependencies coming along with your installation. Even installing the gems-version of Rails didn’t automatically download the gem of this library.

Of course there was no FCGI-version of PHP ~~- which is needed for most webservers that don’t include their own PHP-module –~~ installed on MacOS X, so I had to build that myself too. No package for phpmyadmin either, so I found out that the Debian package actually fills in quite a sane default for the config file (which I now had to do by hand).

There are some things that just work though. X11-support for MacOS X is just marvellous and installing and using The GIMP is quite easy that way. And once you get the hang of it, the default terminal that comes with MacOS X is quite usable too ~~- after configuring default window size and keybindings –~~ .

It didn’t feel like much work, but I had been working from 8:30 to around 17:15.Anyway, back to work.

Working at home

2005-03-22T21:22:00+01:00

I had set my alarm around 7:00, but I still felt pretty tired, so I slept until around 7:55. I got up, put some bread into the oven and sat down behind my computer. During breakfast I played around with Squirrelmail, but wasn’t quite as charmed by it as I thought I would be, so I switched to Thunderbird. I used it to send an email to Marc Voorhoeve, who will be my guide from university to help my out during my internship, to ask him what I needed to do for my report on this whole project. I got a reply later that day and with the help of some documents online and some of the reports class-mates had made, I started to set up the main document layout. After identifying risks and countermeasures, I filled in the guidelines for the rest of the document.

Furthermore, I noticed Rails was updated to version 0.11, which includes all kinds of new nifty features. I won’t repeat what is new, Rails 0.11.0: Ajax, Pagination, Non-vhost, Incoming mail lays it all out for you. It will also contain a link to a movie about the new Ajax-feature, which basically makes it possible to make web-applications more interactive (more like “normal” applications).

Somehow it felt like I’ve been doing quite a bit, but somehow I don’t feel as accomplished as yesterday. But I guess I also have to get used to the dynamics of working at home. At least it was nice to listen to some uplifting music by VNV Nation and some soothing music by Vangelis.

First day!

2005-03-21T17:49:00+01:00

This morning around 8:30, I started the first day of my internship at Fingertips in Amsterdam.

Basically, I’ve been busy setting up my working environment all day. I’m finally in the fortunate position to work with MacOS X (panther) and although I still have to get used to some things, I must say that I really like working with this system. After completing the system installation and required updated, I continued with QuickSilver. Now that is an application I’m going to miss when I’m working my days at home. Once you get the hang of it ~~- say in about 10 minutes –~~ you really speed up your work ~~- and I’m not even scratching the surface of all the functionality –~~ .

To keep it short, I’ve got everything ready for the work I need to do. Just have to find a decent RSS/Atom-feedreader and fix a permissions problem with the Rails/lighttpd combination.

Left work around 17:30 with an accomplished feeling and some regrets that I have to work with Linux at home.