Dan Q

Tag: rails

Wikipedia @ 25: Rail transport in Indonesia

Duration

Podcast Version

This post is also available as a podcast. Listen here, download for later, or subscribe wherever you consume podcasts.

To celebrate the site’s 25th birthday this year, Wikipedia is encouraging/challenging people to read one Wikipedia article a day for 25 consecutive days. I felt that I could do one better than that: not only reading an article but – where I found one that was particularly interesting – to write a blog post or record a podcast episode for each of those days, sharing what I learned. For each entry, I’ll hit “random article” a few times until something catches my interest, start reading, and then start writing! Everything I’ve written below came from Wikipedia… so you should check other sources before you use it to do your homework. Happy birthday, Wikipedia!

Today’s random article: Argo Wilis
Today’s topic: Rail transport in Indonesia

A long train snakes around hillside stepped farms in a tropical and mountainous landscape.
The Argo Wilis, near Lebakjero Station. Photograph courtesy of Naufal Farras, used under a Creative Commons license.

With such an unfamiliar-sounding article title as “Argo Wilis” I momentarily thought I was playing Two Of These People Are Lying, but it turns out that it’s just a train. Well, I say just a train, but it’s a train that took me on a journey (ah-hah!) to a rabbithole of Wikipedia pages, and today I’m going to drag you along with me.

The Argo Wilis is a train that goes back and forth along the Southernmost train line connecting Surabaya Gubeng, in the East, to Bandung, in the West, along Java, the vastly most-populous island of the Indonesian archipelago: most of the length of the island. “Argo” means “mountain”: it’s part of a modern collection of “Argo network” trains that are each named after mountains in the region. Mount Wilis itself is a dormant volcano whose magma chamber apparently has the potential for future geothermal power generation possibilities.

Map showing the East-West route of a train line along the island of Java.
Map courtesy Twotwofourtysix, used under a Creative Commons license.

Learning about the Argo Wilis got me to reading about rail travel in Indonesia in general. There are particular challenges to running a train network in a mountainous island nation with a somewhat monsoonal climate, it seems!

Like: one of the stops on the Argo Wilis‘s line is Cipeundeuy, a relatively tiny mountain station that every single passing train stops at in both directions. Why? Because every train is required to have its brakes tested here before proceeding down the mountain slops on either side of it!

Cipeundeuy Railway Station, a small white building with a railway track running alongside, with people on the platform.
All services must stop here, and have since the 1910s (except for a brief period in the 1990s).

That rule’s existed since the railway was first built, under Dutch East Indies rule, over a century ago. It’s been consistently enforced ever since… except for a spell in the early 1990s when the practice was stopped… until a head-on crash in 1995 nearby acted as a reminder of the importance of the checks, at which point they were reinstated.

Workers pose at a railway tunnel under construction in the mountains.
The construction of the Javanese railways up and over or through the many mountains of the island would have been an incredible feat of engineering even today, let alone in the late 19th and very-early 20th centuries.

Anyway, here are some other things I learned about Indonesia’s railways while I was exploring Wikipedia:

Trains drive on the right

Like many island nations (and in common with some non-island nations, particularly those that were part of the British Empire), Indonesian cars drive on the left. But unusually, their railways don’t follow the same pattern: on twin-tracks, Indonesian trains typically travel on the right.

The Dutch colonists were already running their railways on the right and brought this tradition with them, but when the Netherlands switched to right-hand driving for their cars in 1906 (except in Rotterdam, which imposed no fixed rules about which side of the road you should drive on until 1917!), they only dragged some of their colonies along for the ride.

Suriname is another former Dutch colony that still drives on the left. The question of which side their trains travel on is somewhat moot, though, because they don’t currently operate any trains on their railways.

Train classes

Not sufficing to have just first and second class travel like we do here in the UK, Indonesian trains are broken down into at least four classes: luxury, executive, business, and economy. Plus a further two categories for tourist-centric trains, imperial and priority. Plus some sub-classes that seem to be line-specific.

Interior of a busy train carriage.
“Premium economy”-class interior of the train Sawunggalih Utama. Photo courtesy Gaudi Renanda, used under a Creative Commons license.

It’s all mostly diesel locomotives…

Jakarta’s got an electrified metro system, but most of the Indonesian rail network’s powered by diesel. However, a handful of industrial narrow-gauge mountain railways might still see the use of steam locomotives for farming or mining purposes, like this one seen hauling sugar cane in 2003:

A small steam locomotive pulls carts full of cut sugar cane along a railway line through cropped fields.
Photo courtesy Joachim Lutz, used under a Creative Commons license.

Jakarta was supposed to be getting an electrified monorail, but the project stalled in 2008 and the already-built infrastructure is in the process of being demolished.

Lebong Tandai is a special case

The remote mountain village of Lebong Tandai is only reliably connected to the rest of the world via a mountain railway line. Much of the narrow-gauge track is connected via a plateway, rather than by sleepers, and residents operate the tiny motorised locomotives independently of the rest of the railway network.

A tiny enclosed passenger rail vehicle crosses an old narrow iron bridge in a jungle.
This “Molek-Motor” on the remote line to Lebong Tandai is constructed out of the remains of a goods vehicle that was written-off after an accident. Photo courtesy Harry Siswoyo, used under a Creative Commons license.

Anyway, that’s what I enjoyed learning about on today’s Wikipedia dive. I wonder what I’ll learn tomorrow! (If it’s as-interesting, I’ll let you know!)

Article posted at UTC on .

No comments

Why it is just lazy to bad-mouth Ruby on Rails

This is a repost promoting content originally published elsewhere. See more things Dan's reposted.

It’s inevitable these days: we will see an article proclaiming the demise of Ruby on Rails every once in a while. It’s the easiest click bait, like this one from TNW.Now, you may say “another Ruby fanboy.” That’s fair, but a terrible argument, as it’s a poor and common argumentum ad hominem. And on the subject of fallacies, the click-bait article above is wrong exactly because it falls for a blatantly Post hoc ergo propter hoc fallacy plus some more confirmation bias which we are all guilty of falling for all the time.

I’m not saying that the author wrote fallacies on purpose. Unfortunately, it’s just too easy to fall for fallacies. Especially when everybody has an intrinsic desire to confirm one’s biases. Even trying to be careful, I end up doing that as well…

Repost posted at UTC on .

1 mention

Rails is f*cking boring! I love it.

This is a repost promoting content originally published elsewhere. See more things Dan's reposted.

Together with a friend I recently built Dropshare Cloud. We offer online storage for the file and screenshot sharing app Dropshare for macOS/iOS. After trying out Django for getting started (we both had some experience using Django) I decided to rewrite the codebase in Rails. My past experience developing in Rails made the process quick — and boring…

Repost posted at UTC on .

No comments

Too Ruby

Ruby, a programming language of which I’m quite fond, is well-known for it’s readability and ease of comprehension, among about thirty-seven other wonderful features.

I rediscovered quite how readable the language is when I genuinely ended up writing the following method last week: 

# On saving, updates the #Shift counters if the #ExperienceLevel of this
# #Volunteer has been changed
def update_counters_if_experience_level_changed
  update_counters if experience_level_changed?
end

For the benefit of those of you who aren’t programmers, I’ll point out that which is obvious to those of us who are: the body of the method (that’s the line that’s indented) is almost identical to the method name (the line that starts with “def”).

This is the equivalent of going to WikiHow and looking up the article on, say, How to Make a Tie Dyed Cake, only to discover that the text of the article simply says, “Choose what colours you want, and then make a cake in those colours”… and you understand perfectly and go and make the cake, because you’ve got that good an understanding. In this metaphor, you’re the Ruby interpreter, by the way. And the cake is delicious.

Okay, I cheated a little: the experience_level_changed? method was provided for me by the Rails framework. And I had to write the update_counters method myself (although it, too, contains only one line of code in its body). But the point is still the same: writing Ruby, and thinking in a Rubyish way, produces beautifully readable, logical code.

×

Article posted at UTC on .

No comments

HttpOnly Session Cookies using ActiveRecordStore in Rails 2.2

If you’re using CookieStore to manage sessions in your Ruby on Rails application, Rails 2.2 provides the great feature that you’re now able to use HTTPOnly cookies. These are a great benefit because, for compatible web browsers, they dramatically reduce the risk of a Cross Site Scripting (XSS) attack being able to be used to hijack your users’ sessions, which is particularly important on sites displaying user-generated content. You simply have to adjust your environment.rb file with something like:

config.action_controller.session = {
:session_key => ‘_session_id’,
:session_http_only => true,
:secret      => ‘your-secret’
}
config.action_controller.session_store = :cookie_store

Unfortunately, the Rails developers didn’t see fit to extend HTTPOnly cookies to those of us using ActiveRecordStore, where the XSS risk is still just as real. To fill this gap, I’ve produced a very simple and only slightly-hackish plugin which overrides the functionality of Rails’ CGI::Cookie to force all cookies produced by Rails to be HTTPOnly, regardless of the session store being used.

To use it, download this file and extract it into your application’s vendor/plugins directory, and restart your application server. You can test that it’s working using Tamper Data, FireCookie, or whatever your favourite cookie sniffing tool is.

Article posted at UTC on .

1 comment

SSL Client Certificate Authentication In Ruby On Rails

I’ve been playing with using client-side SSL certificates (installed into your web browser) as a means to authenticate against a Ruby on Rails-powered application. This subject is geeky and of limited interest even to the people who read this blog (with the possible exception of Ruth, who may find herself doing exactly this as part of her Masters dissertation), so rather than write about it all here, I’ve written a howto/article: SSL Client Certificate Authentication In Ruby On Rails. If you’re at all interested in the topic, you’re welcome to have a read and give me any feedback.

Article posted at UTC on .

2 comments

Writing A Calendar App In Rails Vs. PHP

Some time ago, I wrote a web-based calendar application in PHP, one of my favourite programming languages. This tool would produce a HTML tabular calendar for a four week period, Monday to Sunday, in which the current date (or a user-specified date) fell in the second week (so you’re looking at this week, last week, and two weeks in the future). The user-specified date, for various reasons, would be provided as the number of seconds since the epoch (1970). In addition, the user must be able to flick forwards and backwards through the calendar, “shifting” by one or four weeks each time.

Part of this algorithm, of course, was responsible for finding the timestamp (seconds since the epoch) of the beginning of “a week last Monday”, GMT. It went something like this (pseudocode):

1. Get a handle on the beginning of "today" with [specified time] modulus [number of seconds in day]
2. Go back in time a week by deducting [number of seconds in day] multiplied by [number of days in week] (you can see I'm a real programmer, because I set "number of days in week" as a constant, in case it ever gets changed)
3. Find the previous Monday by determining what day of the week this date is on (clever functions in PHP do this for me), then take [number of seconds in day] multiplied by [number of days after Monday we are] from this to get "a week last Monday"
4. Jump forwards or backwards a number of weeks specified by the user, if necessary. Easy.
5. Of course, this isn't perfect, because this "shift backwards a week and a few days" might have put us in to "last month", in which case the calendar needs to know to deduct one month and add [number of days in last month]
6. And if we just went "back in time" beyond January, we also need to deduct a year and add 11 months. Joy.

So; not the nicest bit of code in the world.

I’ve recently been learning to program in Ruby On Rails. Ruby is a comparatively young language which has become quite popular in Japan but has only had reasonable amounts of Westernised documentation for the last four years or so. I started looking into it early this year after reading an article that compared it to Python. Rails is a web application development framework that sits on top of Ruby and promises to be “quick and structured”, becoming the “best of both worlds” between web engineering in PHP (quick and sloppy) and in Java (slow and structured). Ruby is a properly object-oriented language – even your literals are objects – and Rails takes full advantage of this.

For example, here’s my interpretation in Rails of the same bit of code as above:

@week_last_monday = 7.days.ago.gmtime.monday + params[:weeks].to_i.weeks

An explanation:

  • @week_last_monday is just a variable in which I’m keeping the result of my operation.
  • 7.days might fool you. Yes, what I’m doing there is instantiating an Integer (7, actually a Fixint, but who cares), then calling the “days” function on it, which returns me an instance of Time which represents 7 days of time.
  • Calling the ago method on my Time object, which returns me another Time object, this time one which is equal to Time.now (the time right now) minus the amount of Time I already had (7 days). Basically, I now have a handle on “7 days ago”.
  • The only thing PHP had up on me here is that it’s gmdate() function had ensured I already had my date/time in GMT; here, I have to explicitly call gmtime to do the same thing.
  • And then I simply call monday on my resulting Time object to get a handle on the beginning of the previous Monday. That simple. 24 characters of fun.
  • + params[:weeks].to_i.weeks simply increments (or decrements) the Time I have by a number of weeks specified by the user (params[:weeks] gets the number of weeks specified, to_i converts it to an integer, and weeks, like days, creates a Time object from this. In Ruby, object definitions can even override operators like +, -, <, >, etc., as if they were methods (because they are), and so the author of the Time class made it simple to perform arithmetic upon times and dates.

This was the very point at which I feel in love with Ruby on Rails.

Article posted at UTC on .

5 comments