Here are some notes from
Tel Aviv Open Source Club's meeting last week, in no particular order.
They are not exactly a report, but are probably better than nothing. I
them to the club's mailing list
them to to the Perl-IL mailing list, where it sparked a small (but funny)
discussion. I hope to expand upon them in this blog post.
About 20-30 people came in my approximation, some of them a little late, so
it was pretty successful. So hopefully it was a good decision to find a venue
which can afford starting at a later hour. We'll see if the trend of
successful presentations can continue.
I think I recognised most of the attendees, but there were some new faces,
which is a good thing.
Sawyer gave a very good presentation in my opinion, and I've learnt some
new stuff about git there. There was some good involvement from the audience.
Next time, I'll try to pass the baton to a different lecturer, because I think
Sawyer has been giving too many presentations lately, and we need to see some
At the moment we only have one proposed presentation for June (by cool-RR /
Ram Rachum ) and he still noted he may need to cancel. I've been considering
to prepare a presentation/demo about jQuery and also proposed to give a
"Bottom Up Subversion" presentation/tutorial. I'm not a good speaker so I'd
someone can give it instead. We can also have a session of short, volunteered
presentations on the spot
talks or somewhat longer.).
Nevertheless, it would be preferable if someone will volunteer to give a
Some logistics about the room - there is a keyboard and a projector, but no
screen. One can connect a laptop. The computer runs Windows , and we're not
sure if it has OpenOffice.org. There's an Ethernet connection and also some
Sawyer mentioned the fact that from his experience creating a branch in
Subversion (using svn copy) was time-consuming for him ("I went to prepare
coffee"). This sounds strange to me, because branching and tagging in
Subversion are reportedly cheap, constant-time ( O(1) ) operations, and
I've verified it from what I've read about the Subversion internals. I often
branched the Freecell Solver's trunk which is 26M in size and it didn't take
more than a few seconds. svn.kde.org has many branches and each of them keeps
the entire KDE source code and is positively huge with 100s of megabytes of
I mentioned the mini-repository Subversion pattern - each with its own
trunk, tags and branches which can be seen in action in the Web-CPAN repository. This is a single
subversion repository with several mini repositories - one for each project.
It can be done in git too by keeping each project in its own
sub-directory, out of the top-level sub-directory.
I should note that I also eventually decided against putting the files of the
program directly on the trunk, but rather always put them under a
sub-directory of the trunk, so if I need to add something else, they won't
clobber the trunk.
There was a short discussion about whether version control systems are using
databases as their repositories' back-ends. Someone said he wouldn't trust
a VCS that uses an off-the-shelf database, and I'd like to comment about that.
The first thing that one should note is that like
mod_perl" notes many data storages are in fact databases without us really
thinking about them. Even the file-system is a database that maps filenames
to the file contents. Furthermore, Subversion requires a transactional database
for its use: it started from Berkeley DB (which is a database with some
and deliberate philosophical limitations), and then got the ability
to use a backend called FSFS, which is a specialised, ad-hoc, database coded
specifically for use by Subversion; and the Subversion development team
have a distant goal of also creating an SQL-based backend for the
That's not all: Monotone has been using
SQLite since its inception as its local storage backend, and reportedly
is using a database called
"Raima". And naturally,
I expect that even git, Bazaar, Mercurial and similar version control systems
implement a database storage of some sort internally.
We discussed the
Simon solitaire, which I've introduced Ido (ik) to and to which he became
addicted to lately. I've ranted a
bit about how "Solitaire" (or what the British call "Patience games") is
actually a generic name for single-player card games, and that what Windows
calls "Solitaire" is actually just some variants of Klondike Solitaire.
We compared and contrasted both PySolFC and KDE 4's KPatience.
The one who introduced me to Simple Simon was
Stephan Kulow of KDE
fame, who when I told him that I'd like to adapt Freecell Solver to solve
Klondike said that "I don't think the world is ready for that." and then
added that he could really use a solver for Simple Simon. After playing
a few games of Simple Simon, and experimenting a little with the
fc-solve C code, I was able to create a satisfactory solver, but then I also
started to like Simple Simon and played a lot. And it was contagious as my
mother and my sisters also started to play it.
Right now, the KPatience's Simple Simon demo ends up in many practically
infinite loops of no apparent objective. I hope to work on converting it
to use my solver instead (which does not exhibit this problem), but it
will take some work.
About 5 of us went to eat at Spaghetim (an Italian restaurant in Ramat-Gan)
after the meeting. Besides me, there
were two Perl programmers ( http://szabgab.com/ and Sawyer, who was the
presenter) and two Python programmers and I was appointed as the referee. We
were able to explain some stuff from both languages to the other party.
Szabgab mentioned that when he asked some people he gave training to if
they know Perl, they said "No, I can only read it.", which to him seemed to
imply that maybe Perl's reputation as a write-only language was unfounded.
When we discussed Ram's Garlicsim ( http://garlicsim.org/ ) he mentioned
that he is mostly a web contractor, but that he would prefer to be hired for
writing simulations. Then Sawyer mentioned that often an invention brings a
necessity, which reminded us of
book "Guns, Germs and Steal". It is highly recommended. Then we discussed
some other books by the same author and I
ended up saying that I've also read
book "The Origins of Conciousness In the Breakdown of the Bicameral Mind" by
Julian Jaynes, which I enjoyed and found of a
similar interest to "Guns, Germs and Steel" because of its philosophy of
taking a bird eye's view of human history.
Also in the after-meeting, we discussed automated tests and test coverage,
and someone said that it may not be indicative of how well all the edge
cases were dealt with. For example we can test that the tests cover
the expression "z = x / y", but it won't warn us that we dealt with the
case that "y" is zero, which we should. Someone noted he likes the green
indication that he has 100% test coverage. On Perlsphere
recently wrote that a general piece of advice is that one should not strive
for 100% test coverage.
We saw a demo of GarlicSim (which is
LGPLed), and its Wx-interface (which is at the moment not open source,
but has the source available for download under restrictive terms). Ram
showed us how he started a simulation where the simulator calculated a line,
and then it was possible to branch it into a different line of execution
and continue from there. He intends to continue working on GarlicSim into the
near future and then hopefully be able to give some presentations about it
to the local open-source clubs.
To sum up, it was a great meeting, and I hope this trend will continue.