Thx for coming! Also a big thx to all the people that emailed me the photos, descriptions, their slides, etc. .. might it make more ruby enthusiasts come to future Ruby conferences. The third International Ruby Conference (RubyConf 2003, for short) will be held in Austin, Texas, USA, November 14-16, 2003. Ruby Central, Inc.
Slides, photos and videos of the 1st European Ruby conference
Michael Neumann will convert the video into streaming and downloadable format as soon as time permits. A nasty thunderstorm killed some of his computing equipement earlier that week :-(.
Please email additional photos and slides to armin at approximity.com so that I can put it all online here.
Short German article about Euruko in Linux-Enterprise.
What makes a good API in Ruby?
Wise, a WIdget SEt for Ruby. overview, demo
more info here
Samizdat is an open publishing and collaboration engine based on RDF model and using Apache mod_ruby, Ruby, PosgreSQL via Ruby/DBI, and YAML. Samizdat RDF storage was started from ideas in Dan Brickley's RubyRDF, but was written from scratch with more focus on relational storage and performance and less focus on XML and other serialization. The talk will describe Samizdat RDF storage design, underlying algorithms, and use cases.
Ruby took some good ideas from Smalltalk . But it ignored the environment completly that made Smalltalk so powerful. Using Squeak as an example, this talk will give an introduction some advanced tools in the Smalltalk world (Refactoring Browser, StarBrowser, SLint, ...).
This talk will present an attempt to develop full-fledged resource management application for use in various appliances like firewalls, NAS and SAN: modularization, configuration tracking, transactions, independent multi-GUI, and security ideas will be discussed.
How to play nice with the garbage collector in Ruby extensions -- (includes: how does the GC work, patterns of managing extension library objects, using swig, common misconceptions)
Short introduction to YAML and why it is such a good
fit to Ruby. Two real-life Yaml uses stress the
simplicity of YAML and finally a short look into the very near
future where YAML is going.
These slides are a bit longer than the ones used during the
talk, as Stefan changed the program, so that the just-in-time
creation of the slides became an improvisation and towards the
end we all wanted to have some lunch :-).
Stefan has put a first sketch of a a gentle introduction to ruby on windows online. Please contribute to the version in the wiki.
Does anybody volunteer to move all that to the wiki, so that people can add and refactor the content easily? Tell armin the URL and he will put it up here.
Did the planning game (papers on the wall :-) Discussions
Go to the wiki
> * High-performance computing, druby, etc
> * Ruby for "other" platforms: PDA, Windows. Focus on multi-platform
> GUI, references to jruby, etc
>
> * Ruby & the world (non-technical): quick and dirty summary
>
> What do we need to increase Ruby awareness?
> * documentation
> * RAA:
> - categorization, keywords, etc
> -lower entry cost: interface
> -rate on dependencies: the more people depend on you the better you
> are (or should be :-)
> - fill in RAA w/ metadata from freshmeat?
> - extract RAA to a wiki to enable comments and collective description +
> dependencies?
> * lessons from CPAN?
> * too much duplication: why 3 if cpan makes it w/ 1?
> <= less maturity. Do we need 10 years to make another cpan?
> * comm. problem: division linux devels/ windows users
> have to think of the end user (?)
> * do we really want a killer app? find a niche market?
> hardly doable if we're a general language and act as glue, which you
> don't see when it works right
> * get beginners: why would they choose Ruby instead of say Visual Basic?
> * need bolts-included dist?
> * should include decent editor for windows within?
> * Java lessons
> - ads: we'll never get them
> -university: definitely. We've got Stefan Schmiedl to try it :)
> * try to leverage already existent technologies to be buzzword
> compliant yet still in the ruby way: JRuby
> We only had one large discussion today: "Ruby & the rest of
> the world (technical)". We were all quite tired, so the discussion
> didn't follow a clear track, and in the end, as people were leaving, it
> became a tough head to head daydreaming contest :-) No winners nor
> losers, but I can say I dreamed a lot :)
>
> The usual quick & dirty summary (this disc. took around 2H IIRC):
> Introductory question: what can we make to make Ruby play nicer w.r.t.
> the rest of the world?
>
> * interface w/ Java. Approaches:
> * RMI: needs deserializing Java objects. However code should be available
> (in Java) Cons: hard, objects have to be mapped (attr,
> etc), needs server code on the Java side. Pro: as easy to use as
> druby (essentially the same thing, communicating w/ java on the
> server side)
> * JNI: map the reflection API from Java through JNI into Ruby. Then
> access all of Java through that "pipe". I failed to see the merit of
> this at first but now I believe it's probably *the* idea of the day.
> Should be easier to implement. Already done in Dolphin Smalltalk:
> www.metagnostic.org (that was our starting point).
> Pro: *all* of Java accessible after a couple man-days!! Cons: at
> first, some convenience lost (if I got it right the API would look
> like ext/Win32API)
> * do we want to port things from Smalltalk? hehe, the Java through JNI
> thing :-) Things that would help
> - become: not really, not used a lot (only a dozen times in a live
> Dolphin Smalltalk image)
> - multiple blocks: convenience, forget proc { }
> - serialization of *everything*. Right now problems with
> * IO: it's OK, files are closed in Smalltalk on image save
> (actually impl. dependent)
> * Proc: the problem is not procs, it's *code* (the AST)
> => bytecode helps, we want Rite :-)
> * rule-driven systems à la Prolog
> - backtracking: w/ continuations (?)
>
>> From this point on we lost a little bit the track :) and started
> discussing whatever came through
>
> * formal specification of Ruby necessary?
> - Rubicon
> - C interpreter is specification. If somebody reimplements Ruby he
> could say "I match 1.6.8"
> - who's reimplementing Ruby anyway?
> - specification as guarantee for the programmer: example of Python.
> - however, if incompatible changes happen (as in Python), does a spec.
> buy you anything, instead of just seeing the code break? Why care?
> You have to keep the old thing anyway.
> * has any language ever been implemented following TDD?
> * how hard is creating a compiler anyway? => not really
> * yet getting AST from Ruby isn't widely done as of now
> <= node types in eval.c and no documentation on that
> * Ruby object model ~~ Smalltalk Object model
> Objective C ~~ Smalltalk + C and types
> what about Ruby <=> Objective C?
>
> * Embedding: what do we want to script?
> - everything: à la WSH
> - strategies:
> * per app, add Ruby interpreter and/or map existent object model to
> Ruby. OpenOffice (UNO), kparts, bonobo
> * globally: intelligent proxying X server that sends events to
> script apps. HARD
>
> * Graphic output
> - gnuplot: 3 bindings in RAA yet nothing satisfactory
> - generating PS: easy, similar to generation of Tcl/Tk in Rconf (see
> talk above)
> - SVG and/or flash: seriously cool
>
> We had implemented all of the above, but unfortunately the source code
> got lost in the black hole as we collapsed ;-)
>