Welcome to my little book. In it, my goal is to teach you a way to think about computation, to show you how far you can take a simple idea: that all computation consists of sending messages to objects. Object-oriented programming is no longer unusual, but taking it to the extreme - making everything an object - is still supported by only a few programming languages.

Can I justify this book in practical terms? Will reading it make you a better programmer, even if you never use "call with current continuation" or indulge in "metaclass hackery"? I think it might, but perhaps only if you’re the sort of person who would read this sort of book even if it had no practical value.

The real reason for reading this book is that the ideas in it are neat. There’s an intellectual heritage here, a history of people building idea upon idea. It’s an academic heritage, but not in the fussy sense. It’s more a joyous heritage of tinkerers, of people buttonholing their friends and saying, "You know, if I take that and think about it like this, look what I can do!"

link

From the README:

Major features:

• Cholesky decomposition
• LU decomposition
• QR decomposition
• Schur decomposition
• Singular value decomposition
• Eigenvalues and eigenvectors of a general matrix
• Minimization by least squares
• Linear equation solving
• Stand-alone LAPACK bindings: call any LAPACK routine from directly from ruby.

Source: _why, yaml.freepan.org) YAML is extremely simple to learn. The basics are extraordinarily simple. You may even find that you have unintentionally used YAML syntax when building lists or simple file formats.

It also helps if you have experience with any agile language (such as Ruby, Python, Perl or PHP). YAML was designed to suit these languages well and borrows a few basic ideas from them.

And look at the clock before you start. Jot the time down and we'll see how fast you are. [http://yaml.freepan.org/index.cgi?YamlInFiveMinutes]

(Source: whytheluckystiff) The (Poignant) Guide is a new approach to teaching Ruby, emphasizing the lingual traits of Ruby and illustrating its uniqueness with comics, visual imagery, and songs with accompanying hand gestures.

This date marks the release of the first three chapters. Feel free to tell your friends and family (a.k.a. Slashdot) about the news. With enough input and support, this book could see completion by next year. Hopefully this is a step towards explaining to the world why Ruby is such an enticing and voluptuous gem to behold.

Go and enjoy the book

Okay, I’ll keep this short. If you want to read more about my motivation, head over to the announcement on my site. motivation

Sven C. Koehler, our hard-coding dataminer has sent me an email while his code was probably exploring the DNA of some beauty. I wonder whether it was the beauty the root-team uses in their logo? Hey, just because of the logo, one ought to give root a try.

 What I was impressed about:
 http://root.cern.ch/root/Mission.html
 ``We started the ROOT project in the context of the NA49 experiment at
 CERN. NA49 generates an impressive amount of data, about 10 Terabytes
 of raw data per run.'';

 ``Thanks to the builtin CINT C++ interpreter the command language,
  the scripting, or macro, language and the programming language are
  all C++. The interpreter allows for fast prototyping of the macros
  since it removes the time consuming compile/link cycle. It also
  provides a good environment to learn C++. If more performance is
  needed the interactively developed macros can be compiled using a
  C++ compiler.'';

 http://root.cern.ch/root/Architecture.html
 ``The backbone of the ROOT architecture is a layered class
 hierarchy with, currently, around 310 classes grouped in about 24
 frameworks divided in 14 categories. This hierarchy is organized in
 a mostly single-rooted class library, that is, most of the classes
 inherit from a common base class TObject. While this organization
 is not very popular in C++, it has proven to be well suited for our
 needs (and indeed for almost all successful class libraries: Java,
 Smalltalk, MFC, etc)''.

But, people working on DAV have had goals which extend beyond simple web page authoring. Some view DAV as a network filesystem suitable for the Internet, one that works on entire files at a time, with good performance in high-latency environments. Others view DAV as a protocol for manipulating the contents of a document management system via the Web. An important goal of DAV is to support virtual enterprises, being the primary protocol supporting a wide range of collaborative applications. Importantly, a major goal is the support of remote software development teams. A final goal of DAV is to leverage the success of HTTP in being a standard access layer for a wide range of storage repositories — HTTP gave them read access, while DAV gives them write access.

Well, the website clains WebDAV in 2 minutes .. I think 10-20 minutes is more realistic :-). A good starter.

Apache2 already comes with mod_dav.