A RailsConf Europe 2008 diary... NOT
Around RailsConf Europe in six words.
Sunday: Arrival by train, St. Oberholz.
Then All-you-can-eat, Tacheles top floor. Yay.
Monday: St. Oberholz, Bratwurst on Rails.
Taught Geoffrey how to use zsh.
Tuesday: Vietnamese dinner with Sean O’Halpin.
Then RejectConf at Pirate Cove (Arr!),
Then to Ambulance Bar and Tacheles Garden.
To bed at about 5 am.
Wednesday: Deutsches Technikmuseum, dinner at Marx.
Then Ambulance Bar, Tacheles first floor.
To bed at about 6 am.
Thursday: Dinner at the Ständige Vertretung.
Then Ambulance Bar (See the pattern?).
Friday: Flight home, way too early.
Thanks and greetings wholeheartedly go to:
Scholle5 for the apartment and WiFi,
Members of #caboose I stayed with,
for the good time and community,
Geoffrey Grosenbach for his unhidden praise,
Sean O’Healpin for dinner and beer,
All barkeepers in previously mentioned places,
Yikes, I accidentally my whole fleshlight!
See you all in near future.
Almost overheard: Rails is getting stale.
NP: Queen Adreena—Princess Carwash
Off to Berlin
Busy packing my stuff to travel to
Berlin where I’ll play lobbyist at
RailsConf Europe 2008
(i.e. I don’t have a ticket.)
Please contact me if you want to
meet up, I’m there until early Friday morning and have lots of free
time.
I’ll be taking my EEE PC with me, so
mail and IRC ought to be available, given I find some free WLAN
(no deal).
I’m staying with Jarkko Laine,
Cristi Balan,
Andrei Bocan,
Manfred Stienstra,
Eloy Duran, and Lars Pind. Gonna have a good time.
Anarchaia will resume publishing Friday, September 5.
NP: Queen Adreena—Medicine Jar
Taming $RUBYLIB with the Z shell
Ok, I’m fed up. Writing a good package manager for Ruby is a fight
against windmills.
So let’s do the easiest thing that could possibly work. Redefining
Kernel#require is a no-go, for it will lead to the gates of
hell.
Installing multiple projects to the same location is error-prone,
requires non-trivial amounts of code and introduces packaging effort.
Luckily, most packages these days run directly from a checkout or
their released archives (and if you provide neither, you’re doing it
wrong).
Essentially, all you need to make it convenient setting and
manipulating $RUBYLIB, “A colon-separated list of directories that
are added to Ruby’s library load path ($:).” The Z shell
(1,
2) to the
rescue!
Add this to your .zshrc (or .zshenv, if you want it in non-interactive
shells as well):
# unique, exported, tied array of $rubylib to colon-seperated $RUBYLIB
# 08aug2008 +chris+
typeset -T -U -gx -a RUBYLIB rubylib ':'
rubylib-add() { rubylib+=("$@") }
rubylib-del() { for i ("$@") { rubylib[(r)$i]=() } }
rubylib-reset() { rubylib=(); [[ -f ~/.rubylib ]] && source ~/.rubylib }
rubylib-reset
This creates a zsh array rubylib which value reflects $RUBYLIB and
vice versa (zsh does the same for $PATH and $MANPATH, for example),
and defines three functions to add and remove paths as well as reset
the variable.
Also, create a file ~/.rubylib where you set the defaults.
I simply use:
rubylib-add ~/projects/{testspec,bacon,rack}/lib
rubylib-add ~/src/{camping,markaby}/lib
Remember, you can use the full power of zsh to set this:
rubylib-add ~/src/rubystuff/*/(lib|ext)(/)
You need to use (x|y) instead of {x,y} here to only expand to
existing files. The final (/) ensures these files really are directories.
Reload your .zshrc, and voila, your packages are accessible from every
Ruby script. Now, if a project has different requirements, just
create a script there to adjust $RUBYLIB. Or use vared to
interactively change the load path.
[Thanks to et for improving rubylib-del.]
NP: Curve—Dirty High
Review: Practical REST on Rails 2 Projects
Practical REST on Rails 2 Projects
by Ben Scofield.
Apress, Berkeley 2008.
284 pages.
[Full disclosure: I have received a copy of the book in exchange for this review.]
The book, targeted at intermediate and advanced Rails users, starts
with a chapter “Why REST?” that tries to explain how REST helps
interconnect applications and reflects the structure of the web.
As examples for such connectivity a few mashups are presented.
The author states that APIs can make web applications much
more useful and interesting, but costly to develop. He contrasts
REST with XML-RPC and SOAP. Finally, the basics of REST are outlined:
It is a client/server architecture based on stateless requests that
describe and transform resource representations. The author argues
that REST makes it easier to develop clients and servers and extend
these applications in the future, last but not the least because
REST is implemented well in Rails 2.
After demonstrating the use of (deprecated) ActiveWebService, the
author shows how these ideas are expressed nowadays in Rails 2,
outlining the history of simply_restful. He continues by
explaining the new styles of URI routing that also dispatch on the HTTP
method like map.resources/map.resource/nesting and map.namespace.
The author also addresses Rails’ support for multiple
output formats and new helpers related to routing. Scaffolding is
discussed and will be used in the book. At last, there is a mention
of ActiveResource to use RESTful Rails applications together.
The third chapter develops the main application of the book dubbed
MovieList. It is used throughout the rest of the book. MovieList, a
site that informs about movies and their releases, lets users express
their interests and displays when new movies with the same actors are
released. The code is not developed test-first, but the downloadable
code contains a test suite. Occasionally the code is
pretty weird, for example it defines setters that are merely
called for their side-effects using #update_attributes. In some
places, explicit iteration over ActiveRecords would have been solved
better by doing it in the database. Also, the generated HTML is
partly unsemantic and hard to scrape (which is not that bad if the
data can be reached by the API, you may argue). The author explicitly
defines notifications and interests for the movies to belong to the
logged-in singleton user (they reside at /user/interests, not
/users/:id/interests), supposedly so one cannot see other people’s
interests. In later chapters, he decides however to at least revert
this for notifications—it would have been better to properly design
it in first place, as it actually is a nice feature and more RESTful
anyway (can you speak of “current users” in a stateless request,
really?) and show how to protect the page for users that don’t want to
allow it to be seen. The author mentions at the end of the chapter
that a “great deal of planning, testing and other work has gone
undescribed”; wouldn’t it have been useful to have these parts in the
book as well? The actual architectural concerns of REST applications
are not really mentioned in the book.
The next four chapters deal with accessing the MovieList applications
from other technology. Chapter 4 uses JavaScript to provide a
widget users can embed on their homepage and shows how to do
full-fledged access to the application using AJAX after extending it
to support JSON. Chapter 5 shows how to access the site using the PHP
framework Squidoo. During this, a feature is added to allow users to
display the movie releases within a time frame. This is the code used
to parse the relative time, and I’m not kidding:
raw_time = params[:time] || '1 month'
time = eval("#{raw_time.sub(/ /, '.')}.from_now")
How this gaping remote code injection hole passed any kind of
technical review is a miracle to me. Ironically, the next
section is called “Injection Flaws”, and addresses SQL injection and
so-called “HTML injection”, which actually is passing anything you
want as parameters. The author then decides to “fix” it by checking
the time parameter in the PHP script calling the Rails application. Duh.
Chapter 6 builds an client for the iPhone, optimized to its interface
constraints: a small screen, popup keyboard and lower bandwidth. It
uses the commonly used approach of defining a new Rails format that is
triggered by a special subdomain or by user agent sniffing.
The chapter shows how to use iUI to make the interface look
native, too.
Chapter 7 shows how to embed the application to Facebook either by
using iframes or the FBML. I have no idea how the contents of this
chapter are related to REST, especially since the FBML approach
actually calls everything using POST.
Chapter 8 is called “Dealing with success” and is about making the
application faster and more robust. Apart from the classic caching
approaches (which work very well in REST due to the idempotency of
GET, but see below) and foreshadows of denormalization,
it contains a few general hints on Rails and database performance. It
also addresses throttling access to the API by using API keys
and setting up auditing to monitor the site.
Finally, Chapter 9 tries to place “Rails in the enterprise” and
explains the chances, but also the problems of REST and Rails in the
enterprise. It contains a small example of how to create a RESTful
interface for a SOAP backend.
Conclusion:
Generally, I found the book lacking. Instead of shifting focus to the
design and architecture of real-world REST applications and showing up
the patterns that can be used to help development, the book shows how to
combine a simple CRUD application with half a dozen of buzzword loaded
Web 2.0 stuff. The semantics of REST are only half-heartedly addressed
(a third of page 13 discusses what the HTTP methods mean),
the idempotency of GET merely assumed (it’s actually in a
parenthesized half-sentence on page 72), and the actual means of
applying REST (proper status codes, correct/multiple content types)
are not made explicit. Instead of wasting over 15 pages on
screenshots unrelated(!) to the application and another 2 pages on
showing a WSDL that is very much useless, the reader would have
had more benefit from a table of HTTP status codes and content types.
Also, writing a REST client in Ruby is not addressed by means other
than (the limited, non-general) ActiveResource.
I think this sounded too negative, please bear with me:
The book is okay. It’s well written, and if you like a whirlwind tour
of Web 2.0 things one can do it’s a good read. It’s just not really
about REST, or at least not what I’d expect of a book about REST.
Rating: 3.5 of 5 points.
NP: Dandi Wind—Hostages
Workshop on Self-sustaining Systems 2008
These are my personal notes from the Workshop on Self-sustaining
Systems (S3).
[A quick note beforehand: The descriptions make use of a metric called
“lines of code” (LOC), which widely is regarded as being insufficient
for measuring program size. Due to lack of better means, I decided to
mention them nevertheless. Take them with a grain of salt.]
The conference started after lunch, but we got there earlier so we had
the chance to socialize with the HPI
people already.
⁂
Ian Piumarta gave the first invited talk on his
Late-bound lambda object architecture, wherein he decided to fight the fact
that software tends to become too complex by finding out how much you
can say with how little. He started by contrasting the three cubic
miles of paper that is the US case law to Maxwell’s four tiny
equations which are able to fully explain all electromagnetic
phenomena.
Moving to software, he showed the source code line counts of some
popular projects, and we could see, for example, that OpenOffice.org
has more lines of code than the entire FreeBSD operating system.
Comparing lines of code with the size of literary categories, he
decided that 20kLOC, which roughly resemble a 400 page roman, are the
maximum size of a program a programmer has the chance of fully
understanding.
He continued explaining how it is possible to get much done in such
a limited amount of code by showing off how simple things like shape
rendering, which only consists of a few elementary transformations, is
enough to render fonts and essentially provide a full graphical
interaction system.
He gave a quick tour of other interesting ideas to be further
investigated, such as multiple subjective perspectives, which result
from the realization that objects have several roles, or regarding
computation as “fields” (re)acting on particles, a concept which makes
it easy to specify complex interactions between many objects.
Since predicting anything is difficult, he argues that it highly
important to be as dynamic as possible, by using the fewest minimal
abstractions that allow for any possible feature/paradigm to be added
to the language/system.
His design combines functions and objects into the foundation of his
system, COLA. Functions,
represented as s-expressions provide the proto-behavior, while
proto-structure expresses form by providing objects that messages are
sent to. They provide the dichotomic base, since without
function, form cannot be animated while function has no representation
without form. This results in a self-describing structure.
(Actually, after the talk he told me they are trying to unify
functions and objects into one thing, I’m very curious about the
result.)
His talk was larded with memorable insight such as looking at GTK+ and
noticing “C is highly deficient and wasteful” or encouraging the
students to look at the “old” papers where technology was severely
limited because “sometimes progress is behind you”.
⁂
The next talk was by Christophe Rhodes, who spoke on
SBCL – A sanely bootstrappable Common Lisp. After a short overview
of Common Lisp, he summarized the history of
SBCL, which started as a fork of CMUCL in 1998.
The main reason of the fork was that CMUCL was horrible to
bootstrap and it actually wasn’t possible to compile CMUCL without
already having the last version of CMUCL before that.
Christophe Rhodes emphasized the importance of a system being able to
rebuilt itself from a “blueprint” since it makes the result a lot
clearer, easier and predictable. He showed an example of a bug in a
core data structure which was easily fixed by changing the structure
and recompiling the system—without the ability to rebuilt from
scratch, magic hackery would have been required to modify the existing
structures to be compatible enough until they could replace
themselves.
SBCL nowadays can be compiled using half a dozen of different CL
implementations and does, once built, not any dependencies on the build
environment.
This unusual level of self-sustainability has many benefits: it is
more fun, enables quicker turnaround, makes the system more
future-proof, and doesn’t limit improving the core of the system to
hackers with magic abilities. Instead, every developer can work on
the code because in the end it’s just another big Lisp program.
Because of this, more people can help with the system and maintain it,
thereby having more control over the destiny of the system as a whole.
⁂
Charlotte Heerzel was the next, presenting
Reflection for the masses, in which she showed how to implement
3-Lisp
using CLOS. She noticed that programming languages are made powerful
by abstractions, but there are cases where one wants to get rid of
them, for example if you need access to the current continuation.
Reflexive languages, on the other hand, allow the programmer to
control internalization, normalization, and externalization within the
language.
She showed lots of code, implementing a small Lisp interpreter in CPS
and then adding structural reflection by exposing the internal data
structures as abstract data types and behavioral reflection by
introducing reflective-lambda, which has access to the current
continuation, environment and code. For example, this allows to
implement when as a first-class function.
⁂
The first day ended with two social events: first, there was a boat
trip around Potsdam, where I had the great luck to sit on a table next
to Richard P. Gabriel and Pascal Constanza. We had a long interesting
discussion with them about the lack of (helpful?) limitations in
programming, what designers really do, how Java became popular, the
danger of the obvious and demonising copy and paste programming. I
learned one thing about how rpg decides which poems to publish, which
I cannot keep back:
Richard P. Gabriel writes a poem each
day, and once a year, he needs
to select six of them for publishing (six seems to be the usual amount
the publisher wants). So how does he do it? Using a computer, he
randomly picks sets of six, until all of them don’t suck. Then he
sits down and revises them.
We crystallized this as the essence of design: to choose the things
that don’t suck.
Afterwards, we had a dinner buffet on a restaurant boat until night.
⁂
The next day started with Daniel H. H. Ingalls (say it in German!)
demonstrating The Lively Kernel – a self-supporting system on a web pagex.
He admitted that web programming is complicated, but
implementing Morphic in JavaScript seemed like an easy thing to do.
While he explicitly mentioned that he is not proud of the code, he
thinks it’s easy enough and works well.
The whole Lively Kernel is
rendered using dynamically generated SVG and doesn’t include any
(visible) HTML at all. All drawn stuff are vector objects. In good
Smalltalky manner, the system uses MVC extensively.
After a short demonstration with some turtle graphics and live-code
editing, he pointed out some of the non-obvious features of it: For
example, to support multiple people working on it, they introduced a
change-set format for JavaScript which allows to check in modified
parts of the system into version control. Also, they have a pretty
sophisticated system for profiling by dynamic method rewriting to
insert measuring code.
The whole Lively system at the moment is a mere 10kLOC of JavaScript
and already includes many details such as rich-text-boxes.
On the topic of security, Dan Ingalls proclaimed that his security
philosophy was like this: “Make it work, then make it secure,
and I hope someone else does step 2.”
⁂
Carl Friedrich Bolz presented a joint-work of eight Pythonists and
Squeakers titled
Back to the future in one week – Implementing a Smalltalk VM in PyPy
which they started in October during a five day
sprint.
PyPy, initially a
Python implementation in Python, but now moving towards a general
compiler tool-chain, enables one to write highly flexible language
implementations because most things are late-bound. Therefore,
garbage collection, object layout and the threading system can be
exchanged easily and allow for lots of experimentation. PyPy aims to
autogenerate dynamic compilers from interpreters written in a reduced
set of Python called RPython with nevertheless allows full-fledged
compile time metaprogramming.
They already implemented all Squeak bytecodes and most of the
primitives. The resulting system,
SPy, can load unmodified Squeak
images and run simple benchmarks. It is roughly 10x slower than
Squeak itself, and they plan to support the graphical builtins in the
future as well.
The team continued hacking on SPy in a sprint in Berlin just after the
S3.
⁂
Guillermo Adrián Molina next introduced Huemul, a Smalltalk
implementation that directly generates native code. It is a very
small system of only 4.5kLOC since it doesn’t try to do everything but
instead reuse existing code. For example, he uses libc, pthreads,
setjmp/longjmp, GTK+ for the UI and OpenGL. The system is
MIT-licensed and inspite of lacking real optimizations already pretty
fast: It runs roughly 832 million bytecodes/s and therefore is comparable
to the performance of commercial Smalltalk systems.
Huemul looks very interesting and
certainly is a thing that deserves more attention.
⁂
Are bytecodes an atavism?, Theo d’Hondt wondered when he
noticed that people are fixated on virtual machines: They think
it’s the only way to write a fast system.
However, interpreters are the simplest way to express the semantics
of a language.
After a glimpse of the history of bytecode from BCPL over Pascal-P to
Smalltalk, Self and Java, he presented Pico,
a tiny language implemented using CPS that is smaller than Scheme that
was roughly as fast as PLT Scheme (as of 2004)
Based on his experience with Pico, he decided to write PicoScheme,
which is written in a subset of C and works by compiling s-expressions
into an abstract syntax tree that then is interpreted. Soon he
realized that “Scheme isn’t all that simple to implement”, but now he
has a very promising implementation of the most parts of Scheme
(nothing really relevant is missing) that is as fast as PLT by now.
It also is very compact: the GC only has 150 LOC.
After the talk, he promised to open PicoScheme to the public in the
future.
⁂
The last talk was called On Sustaining Self by Richard P. Gabriel.
I only can recommend to take any chance to hear him
speaking because he’s doing excellent presentations—I’m unable to do
his audio-visual impressions justice, so please excuse the rough
sketches: The talk started off with playing Hogni Lisberg’s cover of “All
along the watchtower” while Noble and
Biddle’s eternal
words of their Manifesto in “Notes on Post-Modern
Programming”
appeared on the screen. “There must be some way out of
here!”
The ultimate goal of all computer science is the program. The
performance of programs was once the noblest function of computer
science, and computer science was indispensable to great
programs. Today, programming and computer science exist in
complacent isolation, and can only be rescued by the conscious
co-operation and collaboration of all programmers.
There are three ways to build self-sustaining systems according to
Gabriel: First, Designed Perfection, which is what most people try
to do today; it is very efficient, but entropy will get you. Second,
Instinctual Adaption, which is resilient and flexible. Third,
Learning, which is costly, but gives the best results in a highly
dynamic environment.
A poem assembles on the screen; to brilliant guitar music there
appears:
slowly
dawning
is
night
and it morphs into:
slowly
dawning
insights
He proclaims:
Abstraction ignores the relevant,
therefore it requires ignorance!
He does a case-study on
Levittown, which
overcame the limitations and plannedness of itself and turned into a
non-designed suburb.
He presented a case of artificial evolution showing the FPGA
evolution experiment
that generates very effective chip designs that
nobody really understands how they work.
Finally he enters an dialogue with himself asking “How are cities
designed?” At first look, they look modular, but they are so full of
interconnected dependencies that they are impossible to modualize
really. Also, the nature of the city is not planned.
In the end, the recognizance: Design is an illusion.
(I highly recommend you to watch the video when it is online.)
⁂
Summary: Attending the conference has been a great pleasure.
Although being rather short and small (only one-and-a-half days and
maybe 50 attendees), there were top-notch invited talks and many
important people (and also many unknown, but friendly, clever and
interesting ones!) around that everyone simply could talk to. The
social events were well organized (free dinner, free beer) and
actually allowed to socialize.
I seriously hope S3 can turn into a periodic conference because I’d
really like to attend it again.
[Let’s also mention the not-that-good-stuff, just for the sake of
completeness and so you see there’s not much to dislike:
introductionary marketing speeches; the “Workshop” in the name
misrepresents the conference; occasional WiFi failure.]
NP: Bob Dylan—I Believe In You
Off to Potsdam: Attending S3
Tomorrow I take the train to
Potsdam to attend the
Workshop on Self-sustaining Systems
(S3), which means I
get the chance of meeting rpg and many other
people that worked on Lisp, Self and related cool stuff in real life.
The stuff I’m working on got not
finished by far, but maybe I can write down enough on the train to
explain it to interested parties.
If you want to hook up, don’t hesitate to contact
me. I’m there until Saturday
morning.
Anarchaia and chris blogs will resume publishing Sunday, May 18.
NP: Manu Chao—Politik Kills
Celebrating Three Years of Anarchaia!
It has been another
year of your
favourite (near) daily favourite dose of links, IRC quotes, lyrics
and quotes?
Lots has happened in that time! Tumblelogs really turned mainstream,
new platforms like Soup appeared, and
tumblelogging was featured at the Telegraph, Chaosradio Express and Rails Podcast.
Time for the yearly
statistics
(previous year in parentheses):
- Anarchaia as of today consists of
- 996 posts (669)
- 18499 snippets (13555)
- 12797 links (9445)
- 2100 pictures (1440)
- 1148 IRC quotes (979)
- 610 #ruby-lang quotes
- 371 #ruby-de quotes
- 34 #rpa quotes
- 17 #rubyist.org quotes
- 14 #haskell-blah quotes
- 10 #haskell quotes
- 10 #lisp quotes
- 82 other quotes
- 1860 lyrics (1242)
- 379 quotes (311)
- 205 thoughts (138)
- totaling 4.8 megabytes, 443416 words and 85119 lines.
Thanks for all your kind mails, contributed links and other
pleasantness. I still enjoy it as much as I hope you do as well.
However, Anarchaia will have to change in the future: when my study
begins (roughly October), I won’t have the time any more to do a daily
issue. But I will try my best to make at least a weekly version of
it.
Now, on to another year of tumblelogging!
(BTW, chris blogs turned four this week as well. 48 posts this year
and still no new blogging software. I’m working on it, really!)
NP: Grotus—Good Evening
Off to Seelbach
Tomorrow I’m going to leave early for
Seelbach deep in the Black Forest
where I’ll spend the rest of the week educating myself on civil
service (which I finished for two thirds already, but hey, who cares).
Anarchaia and chris blogs will resume publishing Saturday, March 29.
Please notice that this means I will not be able to attend Euruko
2008 in Prague this year. That’s sad,
but I can’t help it (not that I’d have anything to talk about).
Enjoy the program.
Regarding conferences, I am planning to go to the Workshop on
Self-sustaining Systems in May
and RailsConf Europe
in September (I hope there will be a CabooseConf Europe, really).
I expect to have occasional Internet access in Seelbach, else mail
will have to wait. It’s my first travel with the
EEE.
NP: Grateful Dead—Promised Land
Introducing gitsum
The major showstopper before I was seriously considering going to Git
was the lack of an darcsum-like
interface for Git.
Yesterday night I finally decided to write it.
git-status (included as git.el in the Git distribution) is usually
good enough to use, but I often like to do partial commits, that is,
commit only parts of a file. Git can do that now for some time, using
git add --interactive or frontends like
git-hunk-commit
or git-wt-add. Still, there
was no way to do it conveniently in Emacs.
Let me introduce gitsum:
You can freely delete hunks you don’t want to commit, split big
changes, or even edit the patch directly if you feel adventurous. It
also integrates into git-status so you can easily switch between these
frontends.
Gitsum is hosted at http://github.com/chneukirchen/gitsum (which I
highly recommend) and is mirrored at http://git.vuxu.org/, patches and
additions are welcome! It’s still very fresh and has some rough
corners, but I already notice my increase in productivity.
NP: Twelve Tone Failure—As I Hit the Floor
Review: Ruby on Rails Enterprise Application Development
Ruby on Rails Enterprise Application Development
by Elliot Smith and Rob Nichols.
Packt Publishing, Birmington 2007.
[Full disclosure: I have received a copy of the book in exchange for
this review.]
The book targets Rails beginners that have a little prior knowledge of
Ruby and Ruby on Rails and aims to accompany them on their way to
Rails mastership. It focuses on the iterative and stepwise
development of a small CRM system for a small company. Since the
chapters don’t anticipate, it can be read straight forward,
while the reader continuously learns and refines his skills.
It starts with a general introduction on why to use a web-based
client-server architecture for business applications, and then
recommends Rails to implement them, last but not the least because it
is open source and enables easy testing.
Next, the reader is introduced to basic database design, elementary
normalization and how Rails’ ORM works. Then, it discusses Rails
naming conventions and includes a list of reserved words in Ruby. A
list of reserved class names is unfortunately not included, it would
have been very helpful since Ruby already claims some very generic
class names (Date, Thread, etc.).
Contradictory to the introduction, now nevertheless follows a tutorial
on how to setup and install Rails. The book was written before Rails
2 and generally speaks of outdated versions, however, most of the
content is not affected by this—still, there may be some traps if
one tries to follow it with more recent Rails versions. After setting
up Rails, the installation of a database (MySQL throughout the book)
and a revision control system (Subversion) is explained.
After these preliminaries, a Rails project is created and the book
explains the Rails directory structure. Tables are set up, migrations
introduced, and the reader learns about the essential ActiveRecord API
with finds and relationships. Validations are addressed as well; the
regular expression for email checking is broken. After a quick
overview of unit testing and Test::Unit (TDD is discussed but not
used), the reader can check in the code for the first time.
Now, they generate controllers, introduce ERB and pagination (using
the built-in paginate), how to do links and layout and furthermore
how to use partials and flash. The chapter also shows how to write
functional tests.
The application is ready for a first deployment. After an overview of
the typical Rails hardware requirements, the book explains how to
set up Mongrel.
The next chapter focuses on user experience. The authors introduce
routes for better bookmarking, show how to add search and input
validation and finally give examples of using AJAX for autocompletion.
They also point out that AJAX should be used sparingly and only when
it makes sense. The chapter also makes an excursion on how to setup
Instiki as a help system.
After this, the book deals with improving error handling,
authentication (for which they use unsalted password hashing) and file
uploads. After displaying a primitive version of file uploads, it is
shown how to install plugins and how to use acts_as_attachment.
Then, more serious deployment gets addressed. They introduce
Capistrano, explain how to set it up and then use it for upgrading,
downgrading and database-related tasks. A list of common problems is
provided to help fix likely issues. The authors also explain how to
install automatic start-up scripts, session cleaning and log rotation.
The rest of the chapter deals with optimizing the Rails application:
how to find and identify the bottlenecks with profiling and how to
speed up Rails with the different kinds of caching available or by
using eager loading. Finally, they also address scaling by using
multiple Mongrels and Apache as a reverse proxy and static file
server.
The last chapter, “Down the Track” tries to school the reader when
it’s okay to break Rails’ conventions. They give situations where the
use of custom SQL or using multiple databases is required or
advantageous. The chapter also outlines general virtues of a business
application developer, such as the importance of understanding the
business processes, that successful applications primarily need to
yield profit, that automation is good, and reporting important.
The book is concluded by an appendix showing how to setup your own Gem
server.
Conclusion: The book does not satisfy the introductory claims: it is
often too detailed on the basics and too shallow on the crucial things
and sidetracks the reader into unimportant issues. The writing is
occasionally clumsy and sometimes overuses the passive voice to
incomprehensibility. Some code examples are syntactically invalid and
a few Ruby-related commentary plainly wrong. Throughout the text,
replace all occurrences of “property” by “attribute” and of “ampersand”
by “commercial at”. Various other mistakes sprinkle the book,
occasional typos, random font changes and weird spacing suggest the
book was produced in a hurry. People with typographic sense will
be shocked by the table of contents and complete and the utter lack of
typographical quotes. The few illustrations are reproduced in a very
low resolution.
Still, the book may be useful for Rails beginners that are interested
in the development of an “enterprise application” and would like to
know what else there is to keep track of. The complete Rails newbie
however will stumble due to the preknowledge of Ruby, whilst the
slightly advanced Rails developer will hardly learn anything new and
would be better off with specific books on deployment or system
administration to extend his knowledge.
Rating: 3 of 5 points.
NP: Minutemen—Love Dance
Unsubscribing ruby-talk
To: ruby-talk-ctl@ruby-lang.org
Subject: unsubscribe
From: Christian Neukirchen <chneukirchen@gmail.com>
I finally got around unsubscribing ruby-talk, which has a feeling of
both pity and relief. I didn’t read it for the last months, and only
skimmed the overgrowing thread list. There was no way to keep up.
What I don’t want to miss are the software announces, therefore I set up
a quick’n’dirty RSS feed
to keep me up to date.
It’s been over three years and more than 800 messages. See you
somewhere else.
(Of course, I’ll continue to post my ANN’s there.)
NP: Morcheeba—Fear and Love
A Euruko 2007 diary
Friday afternoon: Flight FDH–VIE
Intersky sucks: it’s expensive, uncomfortable, and sitting next to the
propellers of that small machine was no fun. The weather also sucked
and made the flight feel more like a rollercoaster than a bus ride.
Motto of the flight: “Ich beschwöre euch, meine Brüder, bleibt der
Erde treu” (… and “Verächter des Lebens sind es, Absterbende und
selber Vergiftete, deren die Erde müde ist: so mögen sie
dahinfahren!”.)
Friday evening: Das Lederer
Euruko almost DDOS’ed Das Lederer, the
Viennese restaurant we went to in the evening. The waiter planned for
15 people but then we were 60. ;-)
Also, I finally met Manuel in real life. We
figured out that I read his del.icio.us network more often than he
does.
Friday night: Metalab
After dinner and a few beers, we went to the
Metalab. This is a seriously great place.
Where else can you solder, etch boards, develop photos, cook dinner,
surf the web, read Concrete Math, smoke, have 8-bit color lighting
control, drink Club-Mate, meet guys creating a Web 2.0 porn
site (NSFW) or the best hosted tumblelog
solution, play kicker, and maybe even make meta-LSD?
If you ever get to Vienna, going there is a must-do IMO if you are
geeky.
We stayed at the Metalab until 4:30, then we walked to the flat, and
took the tram for the last few stations—if you don’t have a ticket,
you can just buy one there. Very nice.
Saturday morning
Roughly four ours of sleep later I head to the university, miss the
entrance and walk around it once. It’s a great building with huge
staircases and marble columns, and actually the second-oldest
university of Europe, which Jürgen Mangler tells us in his
introduction about this year’s host, the University of Vienna.
There have been four initial fields back in the fourteenth century,
which were theology, jurisprudence, medicine and philosophy. The
computer science department actually belongs to the jurisprudence,
which is weird. He goes on and speaks about the Viennese coffee
culture and that good waiters must be mean. After his intro, we
decide what talks there will be and in which order.
Hal Fulton is chosen to give the keynote, Future of Ruby.
After a short recap of the Ruby history (Hal was one of the first ten
Ruby users in the US), he shows the growth of the community by using
the ruby-talk as a metric. Then, he shows which new features are
planned for 1.9 and 2.0. There also are many new implementations of
Ruby going on, which focus on speed and interoperation. In his
opinion, Ruby is enterprise ready for a long time. He also wants to
see Ruby on handheld and phones. Notable quote: “If you have to work
on Java for eight hours a day, you go home and kick your dog.”
Next, Tim Becker presented a small library of his, Dbrb, which
is a very simple DWIM API for doing SQL things in Ruby. He’s not a
fan of Rails and ORM in general, and DBI is very complex to use.
Therefore, he decided to create a really simple SQL library, which he
first tried to hack into Ruby strings etc. to make it invisible but
then he just defined a method, cleverly named sql, which does
everything. With it, one can easily query and change data using SQL
without all the messy details. There also is profiling support to
help you find bottlenecks. Dbrb is a
seriously cool idea because I think all direct database interfaces for
Ruby are much too complicated and I hate myself for not having the
idea in the first place. Sometimes, things almost are too simple.
David Anderson presented his Informl Wiki, which essentially
is a Wiki with support for forms and database objects. He demoes a
portal for King Louis XIV and shows how easy it is to make simple CRUD
apps and entry forms. They have a cool wikish and simple markup
format for forms and one can do database queries and report generation
with it as well. You’ll find it here.
In the lunch break, we had some pizza.
Then, Ramine Darabiha and Sven C. Köhler demonstrated
Mysit.es, which aims to provide a central data storage for all
your Web 2.0 sites and they showed how to create a new service with
it. Lots of Myfoo.es-jokes came up, the one I like most is
“Myfec.es — Put your shit online, literally.”
After this, I gave my talk Introducing Rack. The
material is online, so
I’ll not go deeper into Rack here.
Stephan Kämper talked about Transitions next up, which he
classified into social, qualitative and quantitative and personal
ones. He showed that Euruko itself is full of transitions, and how
they matter in daily life. He also showed that there are many
transition effects in Keynote.
Kingsley Hendrickse spoke on Riess Automation, which is a
library to script the Internet Explorer using COM. He didn’t like
Watir anymore, so he decided to write
Riess, which is better designed,
has a nicer DSL, is quicker, has builtin assertions and also can work
without JavaScript. He accesses the DOM via COM directly and provides
a CSS selector like API to do assertions on the DOM. He also quickly
demostrated Hyperdrive, which can be used for testing any Win32
application. As well as “automating tasks in World of Warcraft”, that
is.
Then, Peter Szinek gave a presentation on ScRUBYt!, which is a
DSL for writing web scrapers, a task generally known to suck.
However, with ScRUBYt!, which uses Hpricot and
WWW::Mechanize, it becomes fun again. His examples at least looked a
lot simpler than the usual scraping code I’ve seen. There also is
Firescrubyt, which uses Firewatir (to talk to Firefox) and Scrubyt and
can be used to scrape AJAXy sites.
The last talk on Saturday was Martin Grund on Easy DSLs with Ruby,
where he explained what DSLs are and showed how to create a
simple, lispy, external DSL with Dhaka. Then, he demoed a DSL he’s
been writing, RMQL, which is a kind of
simplified XQuery.
Saturday evening: Universitätsbräu
This evening, I had my first Schnitzel and after some beers, Jürgen
Mangler and I started hacking some deepish metamagic trick which we
would talk about the next day then.
After dinner, we went to the Metalab where we stayed until half past
three and then went home—where I talked to Jürgen and his girlfriend
and we tried to explain her what we hacked in the evening.
I went to bed short before five o’clock, whereas they went to see an
episode of Stargate. Yeech.
Sunday morning
I woke up after another four hours of sleep, but since I tried to be
polite, I didn’t wake Jürgen, which made us be late, which was a bit
troublesome because he had the key to open the conference place. ;-)
Jürgen and I presented our yesterday-late-hack, **super: an
exercise in drunken programming*. Instead of *foo and bar, we
used food and beer as metavariables.
The following talk was by Kingsley Hendrickse again, this time on
BDD with RSpec. After explaining the idea behind BDD a bit, he
tried to develop an address book in a pair-driven BDD style. That is,
he’d write the tests^Wspecifications and someone in the audience would
write the code. They didn’t get very far, though. Probably everyone
had not had enough sleep
Next, Paul Battley spoke on Fun with trees. He tried to find
similar product names for work and needed a fuzzy string match for
that. After showing a few well-known algorithms how to do that
(Soundex and Metaphone, for example), he introduced metric trees based
on the Levenshtein distance, which results in a so-called BK-Tree. He
explained how to build, query and use them.
Stephan Kämper talked on Quality in code after, since there
has been lots of discussion about “beautiful code” recently. He
referenced Zen nnd The Art of Motorcycle Maintainance, and showed
various small Ruby hacks on how to make more beautiful code.
Then, Hal Fulton quickly presented a Proposal for an in operator in Ruby.
Fine with me.
In the lunch break, I had my second Schnitzel at the Cafe
Einstein.
Tim Becker spoke on DTrace, which really is impressive. There
are 45k different things in Leopard you can probe for and he showed
how to write D scripts (which reminds me a lot of awk) to discover
various things. He showed how to inspect Ruby with DTrace in a
high-level way. Very powerful stuff.
After that, Ry Dahl gave a talk on Ragel & Ruby, where he
first explained what Ragel is, when to use it and how state machines
work. He showed pieces of Hpricot for explanation purposes. Ragel
can generate multiple languages, but the recent Ruby generator is very
slow, but useful for development and experimentation.
Martin Grund and others showed Twizzr then, a recreational
game they wrote the night before. It’s a few hundred LOC camping
application that is well tested. Twizzr is a
quiz game interfacing via Twitter. One recieves news headlines and
needs to figure out the obscured word in them. They had some problems
with the Twitter API because it limits to 70 messages per hour.
The last talk was by Sacha Schlegl on his ebXML implementation
with a very clever name: Hefeweizen.
Then, Euruko 2007 ended and I have to say I really had a great time
this year. There was a very friendly and open atmosphere as well as
an excellent location in the University of Vienna where they have WLAN
that works and enough multiple sockets for everyone. I hope everyone
of the roughly 70 people that attended (there even were a few girls,
contrary to last year!) enjoyed it as much as I did.
Miscellaneous
Song of the weekend:
LaborCase—Vanille
(heard at the Metalab).
There were no videos made this year, but if you really want to see a
video, search for two girls one cup (NSFW).
NP: Bob Dylan—Winterlude
Off to Euruko 2007
This is the last post before traveling to Vienna for the European
Ruby Conference 2007, where I’ll be talking about
Rack this year.
Since Apple is slow with delivery at the moment, I don’t have a new
shiny MacBook to travel with yet. Someone will need to lend me his
notebook to do the presentation, and I’ll use the good old hippie PDA
to take notes.
I’m looking forward to meet everyone there.
Anarchaia will resume publishing on Monday, November 12.
NP: Bob Dylan—Driftin’ Too Far From The Shore
On Mail
I have just aborted a week-long oddisey of finding a good mail client
that can deal with pretty big IMAP mail boxes. (Of course, this is
because Gmail now does IMAP, which is a really nice idea.)
They all suck, are too slow, or both.
Before everyone now comes shouting, “Bah, just use Mail.app”, these
are my requirements for this use case (I’ll try Mail.app again as
soon as I get Leopard, and will tell you how it breaks down then…):
- Must work over SSH without X, which means console/line based
- Must support IMAP well (bye mutt)
- Must support big mailboxes (100k messages and more)
- Must be open-source
- Should be unixish in some way
One more word about the big mailboxes: I do not need to see all
headers at all times, and if the mailer can operate fast on a subset
(say, the last 2000 mails), this is fine enough. I’d rather use a
quick program with a smaller working set than a slow program which
shows all messages of this century. In fact, this is recommended by
the IMAP client coding
HOWTO. (I
think only Pine does it, and that didn’t work too well either.)
I tried all of these: Mutt (the only program
with nicer source than interface),
Pine (works well with smallish IMAP
boxes, but breaks down with my 172k-ruby-talk box),
Nail (same, and the UI
sucks), and Cone (I gave up
compiling).
As you will notice, most of these clients are written in C. It’s
probably because of their age, but really it is a waste of time.
Mailers written in C are the worst you can imagine, except for mailers
written in C++, which share the issues but take ten times as long to
compile.
Mail clients written in C usually means that they are
noncustomizable/untweakable (Pine) or they use hacky configuration
language (Mutt). Scripting languages exist, and given proper
algorithms and datastructures (which you need anyway, if you want to
make a scalable mail reader), they are fast enough to do anything mail
related, while still being proper, portable languages for extensions and
plugins. (There are a few mail programs written in Perl, but they
don’t seem successful.)
I’m back to Gnus/fetchmail/Maildir now. It can support IMAP, and
works relatively fast (see below for reason), but searching for new
mail is slow, and blocks my complete Emacs (I may end up just starting
two instances…).
And Gnus, I now realize, is a fine mail reader.
This probably is because it was made as a news reader, and the virtues
of a news reader are what counts in my case: Gnus asks you how many
messages to load (usually just the unread ones), and works zippy with
them then, but even with 10k of messages, it still *is* usable.
Furthermore, it has a seriously cool feature: expiring. You don’t
delete mail (I never do that, anyway, which is why my mailboxes are
getting so big), but you expire it, and if the mail is expired and
older than a week or so (configurable), it either deletes it, or moves
it into a different mail box, or does anything you tell it with elisp.
I now use this to make monthly mbox-archives of ruby-core and
ruby-talk, since HFS+ doesn’t really like 150k+ files in a directory.
Which gets me to a side note… one of my first
posts
on this blog was about mail storage formats, and Maildir essentially
was the winner. Maildir is rock-solid, but tools like rsync or
rsnapshot really have to work hard to back them up, if they reach a
decent size. And many file systems (still no ZFS in OS X) slow down a
lot. I’d like to propose a Multimaildir format that stores mails like
Git in Maildir/000/999 and the next one in Maildir/001/000 instead of
stuffing them all into one directory. Should be pretty easy to do,
and makes everything faster. (You also could move your old mail
easily, just move Maildir/000 somewhere else (O(1)), instead of
globbing like hell (O(n)).) End of sidenote.
I also had a closer look at MH, which always fascinated me. There is
a good O’Reilly book on it available online, and I like how it was
designed. Very unixish. I can’t really imagine using it, though. (I
read/skim lots of mailing lists, and apparently MH doesn’t thread, and
I guess it’s just too slow to vgrep a summary and read the few
interesting posts. Maybe with a really well-tuned Zsh
setup, with keybindings and
everything.)
For half a day I glimpsed the idea of writing an IMAP-based MH. In
fact, such a thing, written in Python, exists as
MHI. But I’m not sure I really want
to use it, and it would suck to spend a lot of time to reinvent the
wheel and not even drive with it.
So, I thought about my needs, did a bit of research with antique mail
clients. (Did you know jwz used Netscape 3.02 for a looong
time to read his mail? Not
console based, unfortunately.)
Now, I’m sucking it down and will write my own client, and I’ll use
something one rarely sees on Unix: lets call them “interactive
non-screen based interfaces”. Actually, that’s wrong, because you
probably use the shell every day. Mutt and Pine take all your screen
and are nontrivial to implement (you need to do a pager, and all the
curses stuff, yeech), while mail/mailx/nail are totally-line based and
you need to end each command by pressing return (which is one key too
many for lots of mails).
I think we should do it like this: make a small library that provides
a few widgets, like “line picker”, “item picker”, “line reader”, add
an Emacs-style (or, almost easier, vi-style) keyboard map system to
dispatch between these and make all input interactive (cbreak). Many
apps on ITS worked like that, and it’s pretty comfortable to use,
while still fast, flexible and text-based.
I’m pondering making a Gnus feelalike in Ruby based on this scheme,
with the following very limited function set: just IMAP (but that
well), and all configuration by editing/adding Ruby, threading like
jwz does it, and just the
stuff I need. One should have usable results within a week, who
knows.
I could end up in the history of men by writing the first mail reader
that doesn’t suck. :-P
NP: Bob Dylan—No More Auction Block
A RailsConf Europe '07 Diary
Flight STR–TXL, Sunday
Flying with air berlin is very pleasant: You
get to choose from five newspapers, get free coffee and cake, and they
show you the stupid (albeit rendered) security video on a TV screen.
Sunday evening
Time for some Bratwurst
(pics)! After
arriving at our
apartment
and figuring out how the WLAN is supposed to work, we take the tube to
Kalkscheune where lots of people are
already. The rug-b people made name tags for us. (Hey Vico!)
After we all had enough Bratwurst, some go play Werewolf while we
decide to go to the Tacheles (a.k.a. “shitty building”) and have
some beer.
Monday
Since I didn’t book any tutorial sessions, it’s time to sleep out. We
try to fix the WLAN but completely fuck it up. (You should have seen
us trying to even find the router!) Later, we go to the great
St. Oberholz (blog) cafe which has
good coffee, good food, free wifi and Bionade. Not to forget nice
waiters (Hey Ines!) and lots of Mac users. I had a heavy walnut
tarte.
Monday evening
We missed Dave Thomas’s keynote because had a big Thai dinner.
It was awesome and very tasty. And hot.
Some go play Werewolf. Later we tried to find the Havanna Club Club,
where there was a guy which a friend of a friend one of us knows.
We searched for an hour, and ended up at the Madonna
Bar,
where we had some beer.
Tuesday
Being a bit late, I rushed into the DHH keynote. He showed
evolutionary advancements on the way to Rails 2.0, for example
automatic database setup, easier-to-read ActiveRecord inspects (yay)
and partials by object type (which is pretty nice). He also
demonstrated how to add new content-types to create special output for
the iPhone. Finally, he announced a Rails 2.0 preview release to
appear shortly after the conference.
Then, I attend the first sessions: Deployment and Continuous Integration from the Trenches
by Fernand Galiana, who talked about
new features in Capistrano 2 such as namespaces, different deployment
strategies and events, which allow for seperation of aspects. After a
whirlwind tour of cap2 we learned about certain traps and how to avoid
them, for example by using lazy variable expansion. He also showed
best practices such as factoring common code with load, multistage
deployment and caches, which also can use rsync now. Fernand
concluded his talk by showing a quick example of how to write your own
tasks and announcing his Rails-driven Capistrano frontend dubbed
Capote. His talk was amusing and full of hilarious engineering
pictures.
Next up was Dr. Nic Williams with his excellent talk Meta-Magic in Rails: Become a Master Magician
which started with a list of
features he liked in Ruby and which help doing meta-stuff like the
flexible syntax and the highly dynamic behavior. He explained he
likes “a big number of complexity” and went on to compare Perl with a
puppy unconscious of itself, Java with Keith Richards, and Ruby with
Matrix’s Neo, who knows everything about himself and his environment.
He introduced his Magic Models which use const_missing to generate
ActiveRecord models on the fly and outlined a few important
meta-programming techniques. It was a really funny and instructive talk (at
least if you are not already a Ruby pro).
In the lunch break, I got to know some found the Havanna Club Club
later, and it was just where we searched. Sigh.
In the afternoon, I attended Really scaling Rails by Britt
Selvitelle, who works for flickrtwitter (thanks,
nec). After explaining to the audience that most of them probably
won’t need his hints yet, he explained their mongrel setup (they only
proxy one request at a time from Apache to each mongrel, so requests
won’t queue up) and gave tips on benchmarking actions. He insisted on
not over-architecting. Furthermore, he explained how to create
daemons for long-running tasks (such as informing 10000 followers of
twitter’s popular users) and how to cache DB queries. He also
introduced starling, which is an in-house queue server they wrote. If
you can, cheat, he recommended to us, meaning that users won’t notice
if things don’t update in real time or are totally synchronous. He
also told about essential things for deployment, such as monitoring
and easy deploy/rollback. Scaling is only needed where it matters.
Lastly, he explained the importance of an API for twitter and how it
was relevant for the big community they now have.
The next talk was Improving the Rails ecosystem by Evan Phoenix,
the leader of the Rubinius project. He talked about how a better Ruby
results in a better Rails and how Rubinius is focused on improving
some Ruby deficiencies, like full operator overloading (you can
overload != by itself), better memory usage (better sharing among
forked processes), .rba archives for easier code deployment and more
readable and informative backtraces. He announced they would release
a 1.0 at the end of the year and concluded the talk with an extensive
Q&A session. This was a very funny talk as well, last but not the
least because of his sole usage of made-up statistics. (Rubinius is faster
than three-legged dogs and turtles, but slower than the Space Shuttle,
you knew?)
The day ended with Roy Fielding’s keynote The Rest on REST2, who
once looked at the entire web—back when it was fifty sites. After a
short history of the web until 1995, we got to know he was the main
HTTP RFC editor and he went on outlining the web’s architecture. He
explained how REST implies hypertext in some sense and how it made the
web bigger. He also told he had a look at Rails and tried to show how
to make it more RESTful (he lauded the CRUD); most things already can
be done easily. It was a good talk (have a look at the slides, they
are self-explaining mostly) and I really liked the small quotes on top
of each slide.
Tuesday evening
We had some Schnitzel at a restaurant Unter den Linden which name I
forgot. Then, we headed to
RejectConf which took
place at the Pirate Cove (noone noticed that tomorrow would be Talk
Like A Pirate Day, though. Arrr!!) Some went to play Werewolf.
Dr. Nic praised me for even being able to talk about Ruby
meta-programming after some rounds of Jägermeister shots. No big
deal. ;-)
The caboosers also got a new set of t-shirts.
(Thanks, chrissturm.)
Wednesday
The second day of the conference sessions started with Best Practices
by Marcel Molina Jr. and Michael Koziarski of the Rails
core team. (We learned Jamis Buck wasn’t there because his wife got a
child.) They noticed most Rails projects stuff too much stuff into
the controller and not enough into models. They explained that the
controller merely should contain action code and most of the business
logic belongs to the models. Marcel recommened the Smalltalk Best
Practices book again, which is really worth a read. Michael talked
about how association proxies make you code easier to understand and how
to factor code into many descriptive methods.
Then, I attended JRuby at Thoughtworks by Ola Bini, who complained
about MRI having threading issues, bad unicode support, and speed and
GC problems. JRuby, which was started in 2001(!), tries to address
all these problems. He also told that Java 6 made JRuby twice as fast
without changing anything. JRuby will be compiled to bytecode to
allow obfuscation, which is important for certain businesses. It also
allows for easier deployment. At the end of his talk, he introduced
his new Apress book “JRuby on Rails”.
After this, I went to Ruby on Rails Security by Heiko Webers,
which was a lemon. He tried to shock the audience by telling he saw
lots of session ids on the wifi, but proceded to give a totally boring
talk about essential security concepts which would have been
demonstrated a lot better by, well, demonstrating them. More action
please!
In the lunch break, I met David Chelimsky of the RSpec team. We
talked a bit about BDD and the future of RSpec and test/spec. He also
explained the new StoryRunner to me. Then, I met Geoffrey Grosenbach
and we recorded a Ruby on Rails
podcast out of the blue!
The first afternoon session I attended was Browser-based Testing of Massive Ajax-using Rails Applications with Selenium,
by Till Vollmer of MindMeister, a pretty neat AJAX mindmapping tool. He explained
what Selenium is, and how usual tests don’t test browser behavior,
which is essential for them. After a quick overview of Selenium’s
features, he demonstrated their test suite for a live example.
Next was Functional JavaScript Development with Prototype by Ben
Nolan. He told about JavaScript lambdas and what binding them means
and went on talking about Prototypes enumberable extensions which have
lots of useful methods like invoke, pluck or inGroupsOf. He mentioned
taking some Haskell courses at university and stated JavaScript code
is much easier to develop and debug when it consists of small,
idempotent functions. Also, he recommended to store data in the DOM
and not in private properties of JavaScript objects.
After the afternoon break, I went to Jay Fields’ talk on
Extending Rails to Use the Presenter Pattern which was very fuzzy and mellow.
He couldn’t really get his point across and most of the audience left
the session without knowing what a presenter even is, which is kind of
sad since it surely could have been useful in some situations. Or
not.
The last session, PhD on Rails by Sam Aaron however saved the day.
It was such a refreshing, intelligent and humorous talk that I
completely forgot to take notes. Let me try to remember: He created a
database backed system to keep track of objects which are rendered in
a three dimensional spaces and then implemented a query language to
operate on them. Really cool. And the first person I met that uses VRML.
Wednesday evening
We tried to find a restaurant for roughly 25 persons which was not
that easy. We ended up in a pretty expensive French brasserie, but I
liked my dinner. Some went to play Werewolf. The rest went to
Ambulance
Bar
where we had half a dozen cocktails each. They were very good. We got
back to the appartment at 3am, just before the Werewolf players
finished.
Thursday
I decided to stay one more day after the conference, and we spent all
day at St. Oberholz again. I had a great tiramisu and a beagel. Yum.
Thursday evening
We decided to go to the Fernsehturm for dinner, had a Weizenbier
up there waiting until we could enter the spinning restaurant, which
was pretty cool. The food was far better than I expected and not even
that expensive.
After dinner, we went back to the appartment because we all would need
to wake up pretty early.
Flight TXL–FMM, Friday
I had to wake up 6am to get to the airport in time. I met Geoffrey
there again and we had another little chat. I flew back with tuifly,
which let me chose whether I wanted to be seated to the window or not
but had no free coffee or other features. They play the stupid
security video for you. It was a bit cheaper, though.
General points
git is gaining popularity among Ruby hackers, I
saw lots of them installing it and toying around.
Berlin: I had forgotten how great the city is. The complete and
utter lack of aesthetics actually is appealing, but the icky
typography in the subway hurts my soul.
NP: Bob Dylan—This Wheels On Fire
