CouchDB from Src How-To

Well this was more effort than it should have been. I have been dabbling with Erlang for

Media_httpwwwstrangea_gvfsh
a while, and after struggling with MySQL, Tomcat and JDBC I was looking for an alternative web-app stack. CouchDB looks to be perfect, although sufficiently new that there is not a lot of documentation, both of the books available right now are OK, but not brilliant. In general I prefer the style of CouchDB: The Definitive Guide but prefer the examples from Beginning CouchDB. My personal preference with programming and software tool books is that they should provide detailed, hand-held, speak-to-me-like-I-am-an-imbecile walk-throughs of the most common basic use cases. Anyhow, CouchApp looks like a great way to develop apps for CouchDB, although documentation is fairly sparse. The main problem I found is that the versions of Erlang and CouchDB available from repositories for both Ubuntu and Debian are way behind the cutting edge to the point that the examples in the books won't run. I found that the best way to set up my CouchApp development environment is to completely avoid the repositories and build from source in a clean Ubuntu server VM using the following steps:

  • $ apt-get update
  • $ apt-get clean
  • $ apt-get upgrade

We are going to be building some software so the following tools are useful:

  • $ sudo apt-get install build-essential subversion git-core openssh-server

Install Erlang

Install CouchDB

  • $ sudo apt-get build-dep couchdb
  • $ sudo apt-get install xulrunner-dev libicu-dev libcurl4-gnutls-dev libtool
  • $ wget http://mirrors.ukfast.co.uk/sites/ftp.apache.org/couchdb/1.0.0/apache-couchdb...
  • $ tar zxvf apache-couchdb-1.0.0.tar.gz
  • $ cd apache-couchdb-1.0.0
  • $ ./configure
  • $ ./configure --with-js-lib=/usr/lib/xulrunner-devel-1.9.2.3/lib --with-js-include=/usr/lib/xulrunner-devel-1.9.2.3/include
  • $ make CouchDB
  • $make
  • $sudo make install

Final Setup & Running CouchDB

  • $ adduser --system --home /usr/local/var/lib/couchdb --no-create-home --shell /bin/bash --group --gecos "CouchDB Administrator" couchdb
  • $ sudo chown -R couchdb:couchdb /usr/local/etc/couchdb
  • $ sudo chown -R couchdb:couchdb /usr/local/var/lib/couchdb
  • $sudo chown -R couchdb:couchdb /usr/local/var/log/couchdb
  • $sudo chown -R couchdb:couchdb /usr/local/var/run/couchdb
  • $sudo chmod -R 0770 /usr/local/etc/couchdb
  • $sudo chmod -R 0770 /usr/local/var/lib/couchdb
  • $sudo chmod -R 0770 /usr/local/var/log/couchdb
  • $sudo chmod -R 0770 /usr/local/var/run/couchdb
  • $ sudo ln -s /usr/local/etc/init.d/couchdb /etc/init.d/couchdb

Put xulrunner-devel on your LD_LIBRARY_PATH

  • $ sudo touch /etc/ld.so.conf.d/couchdb.conf
  • $ sudo cat > /etc/ld.so.conf.d/couchdb.conf
  • /usr/lib/xulrunner-devel-1.9.2.6 (NB. Check the version that you have installed!)
  • <CTRL-D>
  • $ sudo ldconfig

Running CouchDB Manually

  • $ sudo -i -u couchdb couchdb

Running CouchDB As a Daemon

  • $ sudo /etc/init.d/couchdb start
Posted
 

Basic Linux Graphics Programming

I have been using C for many years, and OpenGL as a graphics toolkit for many different languages during that time, but am only just dipping my toes into alternative modern Linux GUI toolkits by trying out GTK+ and the Cairo graphics toolkit. To be honest for the last five or six years if I have needed a GUI I have used Java, it just works for me but your mileage may vary. Anyhow, to get the necessary header files that you need so that you can do development you should (assuming a Debian or Ubuntu oriented install) execute the following command:
sudo apt-get install libgtk2.0-dev
Which will install the development libraries and any supplemental tools that are required. This also assumes (again on Debian or Ubuntu at least) that you have also previously done a:
sudo apt-get install build-essential
To get some compilers and suchlike. From here all we need to do is write a simple C program, like the following:
 
#include &lt;gtk/gtk.h&gt;

int main( int argc, char *argv[])
{
  GtkWidget *window;

  gtk_init(&argc, &argv);

  window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
  gtk_window_set_title(GTK_WINDOW(window), "Center");
  gtk_window_set_default_size(GTK_WINDOW(window), 230, 150);
  gtk_window_set_position(GTK_WINDOW(window), GTK_WIN_POS_CENTER);
  gtk_widget_show(window);

  g_signal_connect_swapped(G_OBJECT(window), "destroy",
      G_CALLBACK(gtk_main_quit), NULL);

  gtk_main();

  return 0;
}
 
Save the code as gtksimple.c and open a terminal into the directory where your src is saved and execute:
 
gcc -o gtksimple gtksimple.c `pkg-config --libs --cflags gtk+-2.0`
 
Now execute the code with the following (assuming that you are still in the directory where you just created your executable);
 
./gtksimple
 
and you should get something like the following:
Media_httpwwwstrangea_japhp
  A good place to go to build on this with more windowing functionality is the GTK+ tutorial and for more drawing functionality the Cairo Graphics tutorial, both over at Zetcode.
Posted
 

Pattern Languages

Media_httpwwwstrangea_dmrrp
I have been aware of design patterns since my undergrad days, and learnt about them through a course on software engineering and refactoring which recommended the gang of four book. Much more recently I have discovered Christopher Alexander, the originator of the idea of pattern languages. Recently a colleague discovered design patterns and embraced them wholeheartedly. Unfortunately the experience was not good. Despite having a lot of experience teaching object-oriented programming and having developed several earlier versions of the software, the entirely new code-base developed around implementations of design patterns quickly became so unwieldy that the new version was abandoned. Every time a new feature was requested it took so long to understand the pattern-ated code that each new iteration took longer and longer to produce. Patterns were however meant to make the code-base simpler to understand and maintain. So what went wrong? Well to begin with I don't think that design patterns, despite their name, have much of a place in the initial development of software. The software design patterns that we have at the moment should not be used like recipes would be used when cooking. A better way to think of them is as a structured method of describing good design practices within a field of expertise. When you come to a problem, with the intention of developing software that provides a solution to the problem, then that is what you should do. Write code that solves the problem. If you happen to have produced the best solution to the problem then it should be added to the pattern language for that domain so that you may communicate your solution to others so that they may benefit. This is as opposed to working out which pattern you should implement in order to solve the problem. Of course if you are working in group then it is important to be able to communicate your solution, it is in this role that design patterns become very useful, as a communication tool for building consensus and understanding. However, if you find that implementing a pattern to solve a problem is adding to the complexity of your code-base then perhaps, either it was not the best solution to the problem or you have not produced the best implementation of that pattern. Perhaps though I have just not been exposed to a methodology that incorporates patterns as design elements or recipes which actually works to produce code of the sort that I like; where the code solves the problem and there is just enough code to solve the problem, and no more. I think that this is why the term pattern language is more appropriate than the term design pattern. It is better to think of the patterns not as actual elements of a solution but as descriptions of elements of a solution. When we think of them as descriptions of elements, as part of a language for describing things, then the utility of design patterns becomes self-evident. They give us a language for communicating elements of our solutions to others which is a very useful tool to have. However, as evidenced by my colleague, if they are seen as integral to the software design process, if you are always thinking in terms of the patterns that you will implement to provide a solution to your problem, then you are working one step away from the problem, and attempting to solve it as though through a filter or interface rather than wrestling with the problem directly. This is not to say that you cannot develop good software in this manner but that it is adding tools to the process, making it more weighty than it needs to be, and consequently making your code prematurely more complicated.
Posted
 

Moving from BlueJ to Java Proper

One minor irritation that I have is with the BlueJ package, or more correctly with the way it is used to teach introductory object-oriented programming. BlueJ is a good way to introduce new students to programming but I feel that the introductory course should finish by moving the student to Java proper. By this I mean that the student should be able to write and compile a Java application that does not rely on the BlueJ program.Whether the student is introduced to a more advanced IDE, such as Eclipse with the BlueJ plugin or Netbeans-BlueJ edition, or whether the student is introduced to the javac and java command line tools (ideally with Apache Ant) isn't important. My personal preference would be for javac and Ant as it is what I use for development myself, but the important point is that the student is able to actually create a Java application. My experience is that some students rarely progress past the introductory-level BlueJ based understanding of Java whilst others take it upon themselves to learn what is required to do more powerful Java development. I think that those that do not advance their Java understanding past BlueJ are at a disadvantage compared with those who do and the problem lies partly with the students who should be more proactive in their learning, but also with the introductory programming courses that just don't go far enough.
Posted