Sqitch uses the native database client applications (psql, sqlite3, mysql,
etc.). [...] The IPC is a huge PITA. Furthermore, getting things properly
quoted is also pretty annoying
I would expect this when you use SQL command-line tools in other tools. Of
course, this is Perl, which is better at this kind of thing than other
languages.
Still in a Perl application, I wouldn't use SQL command-line tools for
anything, except maybe a poke at the database or in a tiny (shell-like) script
that just needs one value. DBI is perfect for executing queries on the
database.
His main reason for using the database command-line tools is that these are
always installed on the servers for the people that want to use this tool.
That's probably true.
If I used the DBI instead, then Sqitch would not work at all unless you
installed the appropriate DBI driver for your database of choice. This is no
big deal for Perl people, of course, but I don’t want this to be a Perl
people tool. I want it to be dead simple for anyone to use for any database.
Making this a tool for everybody and not just Perl users is great and
important. It shouldn't matter to his audience what language this application
is written in. So using the CPAN to install modules, shouldn't be something
these people should have to learn to install this software.
I argue that these same people also wouldn't download a tar file and run some
strange build instructions. From the README:
perl Build.PL
./Build
./Build test
./Build install
They wouldn't even download the file. Package management is a wonderful thing.
And the apt-get install sqitch command should just work.
In this presentation Kent Beck talks among other things, about a development
technique called Keystoning. Someone from the audience asks him what it is. I
didn't know it either and that means someone else probably also doesn't know.
It's really useful for bigger features and I have used it many times without
even knowing it.
What is keystoning? Change the user-visible parts last. This way the changes
seem to have come really fast for the user. You can change a lot of code,
without making a change to the user inferface.
We should build towers of software instead of just replacing the platform every
few years. Many client software programs are the end of the line. It's not easy
to build new software on top of those programs.
The problem with this is that this way client programs will become better, but
it's not possible to build on top of them.
Each program should have an API that allows other programs to build on top of
them. There is a lot of functionality that is build in to programs, that could
just as easy useful to other programs.
For example, a download program could be called by your web browser.
Downloading files is a low-level functionality. An external program could show
a list of downloaded files. Also if you listen to podcasts you could have your
RSS reader send the url of the podcasts to you download program. When your
files are downloaded they could be synced to your music listener or just shown
as list of new files. By using an external download program it can be the
greatest download program and it doesn't have to care about complicating other
programs.
The API for such a program should at least have two pluggable points. The first
allows to send the url of the file you want to download. The second will be
called when the program is done downloading (or has failed).
I shouldn't be talking about this example too much, because that is not the
point.
Now that I have this nice
phone, I'm looking for a way
to synchronize my contacts, calendar items and todo lists. On Windows there is the
Nokia PC suite, but that won't work on linux.
I already found gnokii and Multisync,
but the first is not usable enough and I can't get the second working with my phone.
The first problem could probably be solved by using some scripts, but I was looking for
an easier solution, like a one click synchronize.
I problably have to script some things myself (that's no pain), but it would
have been nice to have something working already.