ruby-mine

JSON ist eine Alternative zu YAML, findet zunehmend Verbreitung und wird unter anderem von Rails benutzt, um Daten über die AJAX-Schnittstelle zu senden. Das Ruby-Core-Team hat sich jetzt entschieden, Ruby serienmäßig damit auszurüsten:

Mon Jun  4 21:15:45 2007  NARUSE, Yui  <naruse@ruby-lang.org>

    * lib/json.rb, lib/json, ext/json, test/json:
      import JSON library.

require 'json'

# To create a JSON text from a ruby data structure, you
# can call JSON.generate (or JSON.unparse) like that:
json = JSON.generate [1, 2, {"a"=>3.141}, false, true, nil, 4..10]
# => [1,2,{"a":3.141},false,true,null,"4..10"]

# It's also possible to call the #to_json method directly.
json = [1, 2, {"a"=>3.141}, false, true, nil, 4..10].to_json
# => [1,2,{"a":3.141},false,true,null,"4..10"]

$ irb19 -rjson
irb(main):001:0> jj Array('1.8'..'2.4')
[
  "1.8",
  "1.9",
  "2.0",
  "2.1",
  "2.2",
  "2.3",
  "2.4"
]
=> nil

Die Bibliothek wurde in C von Florian Frank geschrieben und gestern in den trunk importiert (das heißt, in Ruby 1.9.) Zu Weihnachten gibt es also schnellen JSON-Import und -Export in Ruby.

Na, sieh mal einer an: CodeGear (alias Borland) will die erste IDE für agile Ruby-on-Rails-Web-2.0-Entwicklung zur Welt bringen. TextMate, ArachnoRuby und RadRails nehmen die wohl nicht ernst? Na ja, schlechte Recherche und Enterprise-Arroganz sind nix neues; rescue nil.

Aber wir reden hier immerhin über einen neuen Bruder von Delphi und JBuilder. Man beachte, dass Python (zB laut TIOBE-Index) schon vor zwei Jahren so beliebt war wie Ruby heute; dennoch sah in Scotts Valley niemand die Notwendigkeit, eine Python-IDE zu entwickeln. Delphi for PHP gibt’s schon.

dsts.info schreibt:

Was lange schon als Gerücht kursierte, wird nun von CodeGear offiziell bestätigt: Die Firma arbeitet an einer Entwicklungsumgebung für Ruby on Rails, die in der zweiten Jahreshälfte 2007 veröffentlicht werden soll. Die IDE wird vollständigen Support von Ruby on Rails bieten inkl. Codevervollständigung, Refactoring.

Vor langer Zeit (muss so 2000-2003 gewesen sein) habe ich nur mit Delphi gearbeitet. Viele Dinge vermisse ich bis heute…vor allem Form-Designer, Debugger und Online-Hilfe :) Hoffen wir, dass CodeGear mit neuem Wind den Mief aus dem Ruby-IDE-Sumpf vertreibt. Im Allgemeinen lässt sich mit einer Rails-IDE doch auch sicher ganz gut Ruby programmieren ^^

Einen Namen hat das Kind aber bisher nicht. Hey, du da! Web 2.0! Vorschläge?

Weiterlesen

Nach neuesten Erkenntnissen von TIOBE ist es nun zu Ende mit dem Aufstieg von Ruby. Ist why deshalb geflüchtet?

Ich denke nicht. Es ist ruhiger geworden um Rails, das ist vielleicht gar nicht so schlecht. Das Ruby-Core-Team arbeitet fleißig an Ruby 1.9.1 (22 Commits in den letzten 7 Tagen), und der Weihnachts-Termin gilt weiterhin.

Vielleicht sollten wir bis dahin alle ein wenig kürzer treten, und uns mal wieder umschauen, was es sonst noch so in der Welt zu entdecken gibt.

Oder nicht?

Mhhhhhh, mir fällt nicht viel dazu ein. Auch wenn ich in letzter Zeit die Beiträge von _why nicht sonderlich stark fand, so war er doch die omnipräsenteste Person in der Rubyszene. Schade das er sich nun anderen Themen widmet. Schön das er eine zeitlang tolle Dinge mit Ruby gemacht hat. siiigggghhh

Was bisher geschah

Im Jahre 2004 began Jim Hugunin (Mitentwickler von Jython) ein kleines Experiment. Nachdem er für die JVM eine Python Version entwickelt hatten, kam Ihm zu Ohren, dass etwas ähnliches unter der CLR nur schwer möglich sei, da die Architektur der .NET Umgebung sehr schlecht auf dynamische Sprachen skaliert. Also entwickelte er einen Prototyp von Python für die CLR, mit dem Ziel diese schlechten Erkentnisse bestätigen zu können. Dieses Experiment scheiterte jedoch in der Hinsicht, als das sich herausstellte das .NET für dynamische Sprachen geradzu prädestiniert ist. So entstand die .NET Variante IronPython welche im letzten Jahr in der Version 1.0 erschienen ist und teilweise sogar performanter als CPython ist. Jim ist seit 2004 Mitarbeiter bei Microsoft.

Im Jahre 2006 rückte John Lam, mit seiner .NET Variante von Ruby (RubyCLR), ein wenig in das Rampenlicht. Er hatte eine Ruby Version geschaffen, welche es ermöglichte innerhalb von Ruby auf .NET Bibliotheken zuzugreifen. Wie wir im Oktober 2006 berichteten, wurde auch John auf die Gehaltsliste von Microsoft gesetzt und entwickelt seitedem in Fulltime an RubyCLR weiter.

Im Jahre 2007

Gestern wurde nun von Microsoft die neue Version von Silverlight vorgestellt. In der Version 1.1 entwickelt sich der ehmalige Flash Konkurrent in eine vollkommen andere Richtung weiter. Mit dieser wird nämlich die sogenannte DLR eingeführt. Bei der Dynamic Language Runtime hanelt es sich um eine Laufzeitumgebung (ähnlich der CLR) welche auf die Bedürfnisse dynamischer Sprachen ausgerichtet ist. Hiermit soll es Sprachentwicklern erleichtert werden Programmiersprachen mit dynamischem Typsystem zu entwickeln. Hauptakteure bei der Präsentation waren Jim Hugunin und John Lam, welche es sich nicht nehmen liesen, innerhalb einer Präsentation ein Programm mithilfe von vier unterschiedlichen dynamischen Programmiersprachen zu entwickeln. Hierbei wurde IronPython, JavaScript, Visual Basic und IronRuby (jeweils in einer .NET Variante) vorgestellt. Beim Erscheinen des offiziellen DLR Releases sollen diese vier Sprachen von Haus aus unterstützt werden. Bei IronRuby handelt es sich dabei um eine Weiterentwicklung von RubyCLR welche nun auch alle drei Wochen in einer verbesserten Version zur Verfügung gestellt werden soll. Mit Silverlight 1.1 wird es also in Zukunft möglich sein, neben JavaScript auch mit Python und Ruby Clientseitige Skripte zu erstellen, welche in normalen Webseiten eingebettet werden können. Tolle Entwicklung wie ich finde.

Ich weiss nicht wer die geniale Idee hatte Weekly Reports erstellen zu lassen und auch nicht wer meinte diese müssten in Excel bzw. Powerpoint gemacht werden. Ich weiss nur das ich zu den Leuten gehöre die einen Teil dazu beitragen müssen. Und da es nicht wirklich Spaß macht, Bugtrackingsysteme die auf MySQL basieren per Hand auszuwerten, habe ich mir gedacht “Versuchs doch mit Ruby” :-)

Mein erster Ansatz war Datenbank anzapfen und abfragen, Ausgaben formatieren und dann in eine Textdatei schreiben. Dann musste ich nur noch die Werte händisch in die Excel und PPT Dateien kopieren. Das funktionierte schon sehr gut.

Doch dann habe ich noch ein wenig im Internet gestöbert und bin auf diesen Blog (leider nur englisch) getroffen. Hier findet man einige sehr gute Beispiele zum Thema Ruby in kombination mit MS Office Produkten. Nun werde ich mich glücklich und zufrieden in mein wohlverdientes Wochenende begeben und am Montag mit neuer Motivation ans Werk gehen, und versuchen die Reports direkt zu generieren.

Sehr interessant fand ich auch die Idee als GUI-Ersatz für Messageboxen einfach Meldungen von Excel zu verwenden.

require 'win32ole'

def get_input(prompt='', title='')
    excel = WIN32OLE.new('Excel.Application')
    response = excel.InputBox(prompt, title)
    excel.Quit
    excel = nil
    return response
end

response = get_input('My Prompt', 'My Title')

Das funktioniert natürlich nur wenn auch Excel auf dem Rechner installiert ist. Da dies bei mir nicht garantiert ist (verwende auch rubyscript2exe ), werde ich wohl weiterhin auf Konsolen Ein- und Ausgabe setzen.

Eigentlich möchte ich ungern über jedes kleine Tool was in einer neuen Version released wird etwas schreiben. Bei Radiant kann ich es mir jedoch nicht verkneifen. Und zwar aus dem einfachen Grunde, weil unsere wunderschöne offizielle Webseite auf Basis dieses Rails CMS aufgebaut wurde. Das Programm ist zwar teilweise etwas gewöhnungsbedürftig, bietet jedoch nach der ersten Hürde eine sehr effektive Arbeitsumgebung um “Content” zu erstellen oder zu pflegen. Es wurde nun die Version 0.6 veröffentlicht. Eine beachtliche Liste an Änderungen und Neuigkeiten zeigt, dass die Entwickler nicht nur in der Nase bohren, sondern durch die intensive Nutzung der Applikation stark angeregt wurden.

Die Version 0.9.9 von JRuby wurde heute freigegeben. Damit nähert sich JRuby unaufhaltsam dem seit 5 Jahren wartenden Meilenstein 1.0. Laut Entwickler hat sich die Geschwindkeit teilweise von der 0.9.8 um 40% gesteigert. Es werden (wie schon in der 0.9.8) bis zu 98% aller Testcases von Rails erfolgreich absolviert und ab heute läuft sogar Mephisto auf einer JRuby Rails Platform (also die gleiche Blogsoftware die wir hier auch verwenden). Und nun kommt der Knüller! Wie ich erst Gestern durch Zufall in einem Gespräch mit Murphy erfahren habe, verwendet JRuby seit kurzem eine neue RegExp Maschine die eine höhere Kompatibilität zu der MRI Version besitzt. Bis dato wurde die Java Engine verwendet, welche sich teilweise stark von der Ruby Version unterscheidet. Diese Änderung führt dazu, dass Murphys CodeRay ohne schwerwiegende Probleme mit JRuby zusammen läuft. Die gesamte Scanner Testsuite wird fehlerfrei durchgeführt (bei einigen funktionalen Tests gibt es jedoch noch Probleme) mit dem folgenden Ergebnis:

Wie tief kann man sinken? Nun berichte ich hier schon über meine eigenen Domains :-(

Also folgendes Problem: der Datenbankserver wurde (ca. 12 Uhr) von Hosteurope gesperrt. Zu hohe Datenbankbelastung. Nun habe ich da angerufen und mir wurde gesagt, dass es keinen Sinn macht die Sperre aufzuheben da die automatische Kontrolle den Zugriff sofort wieder sperrt. Ist natürlich sehr schön, dass mir erst nach der Sperrung mitgeteilt wurde, dass Sie das ganze sperren. Aber nungut. Ich lade jetzt einen Dump (der überings ca. 90mb an Daten enthält) runter und schiebe alles auf meinen VPS und setze dort das neuste phpBB auf. Wir werden dann kurzeitig eine etwas merkwürdige Optik haben, da ich die ganzen Templates erst nachspielen muss.

[UPDATE] 27.01.2007 15:30: Forum und Wiki ist nun wieder erreichbar.

Frohes Neues Jahr, Ruby!

Du bist jetzt die elftwichtigste Programmiersprache der Welt. Keine andere Sprache hat im letzten Jahr so viel zugelegt.

Nippon, we have a problem.

Was ist passiert?

• 3. November 2006: DoS Vulnerability in CGI Library
  • Eine gefährliche Sicherheitslücke in cgi.rb wurde gefunden. Offenbar blieb das Problem seit Jahren unentdeckt.
  • Ein Patch wurde veröffentlicht.
• danach: Diskussion, wie man diesen Patch am sinnvollsten in ein Release umwandelt. Den Patch zu installieren ist einfach; aber es sollte eine Möglichkeit für Ruby-Programmierer geben, zu prüfen, ob der Patch installiert wurde oder nicht. Ruby 1.8.6 war keine Alternative; deshalb wurde eine vierte Versionsnummer vorgeschlagen: RUBY_PATCHLEVEL.
• 4. Dezember: Another DoS Vulnerability in CGI Library
  • Eine weitere Lücke, wiederum in cgi.rb, und offenbar in derselben Methode.
  • Ruby 1.8.5-p2, das erste Release mit Patchlevel.
  • Eine Warnung, dass der frühere Patch die Lücke nicht gestopft hat.
  • Ein Link auf eine japanische Seite, die alles erklärt -.-

Ich möchte versuchen, Licht ins Dunkel zu bringen.

diff -r

Folgende Änderungen unterscheiden Ruby 1.8.5-ps (2006-12-04) von Ruby 1.8.5 (2006-08-29):

Mon Dec  4 10:22:26 2006  URABE Shyouhei  

    * stable version 1.8.5-p2 relased.

Sun Dec  3 17:11:12 2006  Shugo Maeda  

    * lib/cgi.rb (CGI::QueryExtension::read_multipart): should quote
      boundary. JVN#84798830

Sun Nov 26 16:36:46 2006  URABE Shyouhei  

    * version.h: addition of RUBY_PATCHLEVEL.
    * version.c: ditto.

Sat Sep 23 21:34:15 2006  Yukihiro Matsumoto  

    * lib/cgi.rb (CGI::QueryExtension::read_multipart): CGI content
      may be empty.  a patch from Jamis Buck .

Jetzt sehen wir auch mal, wer die Lücke gefunden hat: Danke, Jamis!

@@ -967,6 +967,7 @@  
       def read_multipart(boundary, content_length)
         params = Hash.new([])
         boundary = "--" + boundary
  +      quoted_boundary = Regexp.quote(boundary, "n")
         buf = "" 
         bufsize = 10 * 1024
         boundary_end="" 
@@ -998,7 +999,7 @@
           end
           body.binmode if defined? body.binmode

  -        until head and /#{boundary}(?:#{EOL}|--)/n.match(buf)
  +        until head and /#{quoted_boundary}(?:#{EOL}|--)/n.match(buf)

             if (not head) and /#{EOL}#{EOL}/n.match(buf)
               buf = buf.sub(/\\\\A((?:.|\\\\n)*?#{EOL})#{EOL}/n) do
@@ -1018,14 +1019,14 @@
                 else
                   stdinput.read(content_length)
                 end
  -          if c.nil?
  +          if c.nil? || c.empty?
               raise EOFError, "bad content body" 
             end
             buf.concat(c)
             content_length -= c.size
           end

  -        buf = buf.sub(/\\\\A((?:.|\\\\n)*?)(?:[\\\\r\\\\n]{1,2})?#{boundary}([\\\\r\\\\n]{1,2}|--)/n) do
  +        buf = buf.sub(/\\\\A((?:.|\\\\n)*?)(?:[\\\\r\\\\n]{1,2})?#{quoted_boundary}([\\\\r\\\\n]{1,2}|--)/n) do
             body.print $1
             if "--" == $2
               content_length = -1
  

Hier stecken also die eigentlichen Fehler.

• Bug 1: stdinput.read gab einen leeren String zurück anstatt nil, wenn das Ende des Inputs erreicht war. Dadurch entstand eine Endlosschleife. Auslösen konnte man das einfach, indem man eine Multipart-Form an cgi.rb schickt, die nicht mit dem erwarteten Zeichen endet.
• Bug 2: boundary wurde nicht maskiert. Wenn man boundary auf (?!) oder so etwas setzt, wird es nie gefunden. Oder man fügt einer dieser "Milliarden Jahre Rechenzeit"-Regexps ein.

Ich weiß leider nicht, wer die zweite Lücke gefunden hat.

Bleibt noch das neue Patchlevel:

const int ruby_patchlevel = RUBY_PATCHLEVEL;
...
rb_define_global_const("RUBY_PATCHLEVEL", INT2FIX(RUBY_PATCHLEVEL));
...
#define RUBY_PATCHLEVEL 2
...
RUBY_EXTERN const int ruby_patchlevel;

Die Diskussion um die Einführung des Patchlevels und eines neuen CVS-Branches (er schient jetzt ruby_1_8_5 zu heißen) findet ihr im Archiv.

Für Programmierer

Baut folgende Prüfung ein, wenn eure Skripte cgi.rb benutzen (soweit ich weiß, tun das unter anderem alle Rails-Applikationen; laut Jeremy Kemper ist Rails aber nicht betroffen, wenn man im production-Mode unter FastCGI arbeitet.)

if not defined? RUBY_PATCHLEVEL or (RUBY_VERSION <= '1.8.5' and RUBY_PATCHLEVEL < 2)
  raise SecurityError, 'Please use Ruby 1.8.5-p2 or later!'
end

Echo

Based on how the cgi.rb file is coded it's most likely that there will be more of these kinds of defects in the future.

• Zed A. Shaw zum ersten Bug.
• Rubyforen.de-Thread
• Regexp.quote
• Ruby-on-Rails-Mailingliste zum Thema