In the following post I’ll show a brief example on how to create a login page with Compojure 0.3.2 running on Clojure 1.1.0.

What is Clojure?

Clojure is a Lisp dialect. So it’s a programming language based on the principles of Lisp. The interesting part about Clojure is that it runs on the Java Virtual Machine. As a developer you can therefore use the bright variety of Java written libraries in your code without touching one line of Java. Use the power of Java libraries together with the power of Lisp.

What is Compojure?

Compojure is a web framework for Clojure. It handles incoming request, offers an easy way to create servlets and provides basic functionality for HTML templates. The current stable version 0.3.2. Compojure is a young project and things change fast there, so be aware that a 0.3.2 application might not run on 0.4.

What is a session?

Basically it’s a per-user store managed by the server. For example a server backend can store the credentials of a user that it received in a request in this store making it possible to identify the user again when he or she does a second request. Usually this functionality is achieved by a library or by the interpreter itself (for example in PHP) and is implemented by storing the session data either in memory or on disk together with a unique identifier that is then stored in a cookie at the users computer. So when the user comes back, the cookie is read and the identifier is used to find the data for the user.

The application

A basic example

Before we work with a session, let’s create a simple webpage that displays hello world for us.

The example is straight forward. We define a set of routes. In our example the route is “/*”, so it matches everything. The route then takes a function as a second argument. In our case we use the templating mechanism of Compojure and create a simple HTML response with the (html) macro.

We then start the server using the (run-server) macro and binding our routes to a specified mountpoint. I won’t go into details about servlets but usually it is sufficient if you have a servlet running on the mountpoint “/*” and then a set of routes.

To run the server you can use a small script like this one:

#!/bin/sh
CLASSPATH=.:~/dev/clojure/compojure.jar:~/dev/clojure/clojure.jar
java -cp $CLASSPATH clojure.lang.Script net/experimentalworks/clojure/serve.clj


Adding sessions

Before we can start adding sessions we have to be aware that Compojure has a mechanism called decorating. So you can decorate a set or routes with what Compojure calls a middleware. We will think of it as a way to enable advanced mechanism. To add the session mechanism to a set of routes use the (decorate) macro as shown in the following code:

Note the that we define a session decoration. At the moment sessions only support in-memory storage (which by the way should be usually the way you want to manage sessions). The :memory keyword here is to tell Compojure to store it’s sessions in memory. Although you can omit the keyword, I prefer writing it down so people can easily figure out how our session is stored.

Creating a login

Let’s create a login. We will first add a new route called /login/:user. This will tell Compojure that the last part of the query string is a parameter and it should extract it. We can then access the value using (:user params). We use the (session-assoc) function to associate our username with the session-key :loggedin. Here is what the code looks like:

You can then “login” to your site using http://localhost:8080/login/test and you Compojure will recognize you again if you go back to http://localhost:8080/

Logout

To logout, we clear the key itself. Let’s a have a look directly into the code. We use the (session-dissoc) function to drop the key (it seems that clear-session is broken in my Compojure checkout for whatever reasons..need to debug *debug*).

Use http://localhost:8080/logout to get rid of your session.

Conclusion

The basic idea behind Compojure sessions is simple and I hope you were able to grasp the idea a little bit. What can be annoying and what I didn’t show you is that you might run into problems within the actual implementation, although the basic stuff should work fine. Once you figured out the basics you can read and write sessions withing seconds and the code becomes clean and beautiful. Feel free to comment on this article if you like the post, it’s the only measurement for me that I can use to make sure I’m not writing stupid stuff.

• Dutch PHP Conference 2010
• Interntational PHP Conference

The talk will give a very brief overview how Git works, and will then give a more detailed insight in how Git handles commits, files, etc so that people get a very good understanding about the concepts that are needed to fully understand tools like git rebase, git reflog and git svn. The aim is to provide them will all necessary information and a few examples to get lost commits back, rebase their branches and design more complex git workflows in the future without needing to search the web or ask a guru.

A second talk will be more focused on beginners and developers coming from subversion. This talk will be part of a series of talks the german telekom is organizing. I’ll also give an extended version of this as an in-house workshop at a Munich based company.

So for me it seems that after five years, DVCS is mature enough to get into companies and that we can expect a bright variety of companies to adopt new tools and workflows. Let’s see what’s coming…

For sure I still offer Git and Mercurial trainings, so feel free to contact me (dsp ~at~ php ~dot~ net)

probably shameless self promotion

compile it

(set! *compile-path* "build")
(compile 'net.experimentalworks.clojure.outdegree)

Ah yeah and hsv2rgb transformation:

As I wanted to have nice a build system for my PHP subversion checkout, I used this need as a project to start coding Scala. So what do I exactly need? I want to build multiple versions of PHP from the same branch without checking out the code twice. I also want to configure these builds somewhere without always typing in the parameter list or so. For further versions I want to be able to configure these in a file that can easily be distributed to other machines.

I set down and wrote a parser for a configuration file that can configured build targets which is then build by
the program. The configuration file I used is specialized for this purpose, which is why I didn’t used something like ant or so. The result is called bauaffe-3.0.0a1.jar.

I’ll just show a few things done in the project, but mainly focus on what the nice script can do. Further blog posts will be about the actual implementation.

The configuration looks like this

$ cat ~/.buildmaker
begin default configuration
    define source "/Users/dsp/dev/c/php-src"
    define build "/Users/dsp/dev/c/php-src/build"
    define defaults as
        with "iconv=/opt/local"
    build trunk as
        "php60" using defaults
        "php60-debug" using defaults
            enable "debug"
    build branch "PHP_5_3" as
        "php53" using defaults
            environment PHP_AUTOCONF="autoconf213"
        "php53-debug" using defaults
            enable "debug"
            environment PHP_AUTOCONF="autoconf213"

.
Proper indention is not necessary (as e.g in python).

Did I mention that the actual parser is 170 lines of code with usual indention and formatting?

Configuration
The configuration file is searched in ~/.buildmaker, or if ~/.builmaker doesn’t exists, buildmaker.conf in the current directory. How do you configure the tool? First of all you can specify a configuration. It is usually called “default”. It is not yet supported to name it differently, although the parser is able to parse it. In further versions multiple configurations per file are allowed.

Variables
Variables are set using the define syntax. At the moment you can set the build and source variable as well the defaults variable, which is usually a block of statements that can be used in the branch configurations.

Branches
A branch is configured using the build syntax. You first have to specify which branch to build. Every branch can then configured to have build target with a given set of options. Branch options are:

• with string: Builds the target with the given extension
• enable string: Builds the target with the given extension
• environment string=string: Builds the target with environment variable

. You can specify using defaults which will cause the runner to use the options specified in the defaults define.

At the moment the parser will not do a good job in notifying you what you are allowed to do and what not, although pure parse error will be emitted. You can also not set any other variable than the described once.

Building
Calling

$ java -jar bauaffe-3.0.0a1.jar list
TARGET                         LAST BUILD
php60                          None
php60-debug                    None
php53                          Sat Jan 09 16:55:12 CET 2010
php53-debug                    Sat Jan 09 16:59:37 CET 2010

gives you a list of parsed targets and their last build date. You can build a target using

$ java -jar bauaffe-3.0.0a1.jar 

or build all using

$ java -jar bauaffe-3.0.0a1.jar all

Please notice that the current version requires that you now what you are doing. You might miss some error messages or find them not useful. I’ll change this before the first release, if I’ll do a final version of it. I hope you like the little tool.

Download It!

Scala (pronounced /ˈskɑːlə, ˈskeɪlə/) is a multi-paradigm programming language designed to integrate features of object-oriented programming and functional programming.[1] The name Scala stands for “scalable language”, signifying that it is designed to grow with the demands of its users.

In your .zshrc add the following line

RPROMPT='[%?]'

This will give you the last exit status on the right site of your shell.

My zsh now looks like this (with the additional stuff)

buenosaires:~/dev/c/git.git/>                                         (next)[1]


The following article will outline the current limitations of bi-directional dvcs to subversion bridges and shows a simple approach to implement a solution for a certain instance of the problem.

The bi-directional bridge
The idea of finding a way to interchange commits back and forth between a DVCS and subversion was born early in the development of tools like Git and Mercurial. The basic idea is easy to grasp. To initialize a repository the DVCS requests all changes between revision 0 and the current HEAD from the subversion server and imports every change as a regular changeset into the local repository of the DVCS. In addition it maintains a mapping between the local, DVCS specific, changeset IDs and the revision numbers in the subversion repository. If a developer wants to push his newly created changesets from it’s local repository back to subversion, the bridge determines the latest pushed changeset and then iterates over the unpushed changes, committing them bit by bit to the subversion server.

Depending on the DVCS you use it will then delete the local changeset and reimport the comitted changesets from the subversion server to ensure that the changeset contains the right date and comitter information as well as the right mapping to the subversion revisionnumber.

Example
To clarify what we just discussed. Assume that we are using git-svn. We are importing a subversion repository with just one commit using the command (I won’t get into detail how to use the command):

$ git svn clone svn://example.com/repo

This command results in a repository which in our example contains the following commit.

commit 7a730e9187becbe1979059cd9752fdea38e3cd9e
Author: david >david @cffdd316-8dd2-4046-8f43-d0df91842a18<
Date: Thu Jul 12 19:39:51 2007 +0000

Crescas in mille millia

Let’s asusme that we create a new commit on top:

commit 129e0e4239ac4d375f2a2132dee042a27f2fd70c
Author: David S. P. >dsp at php.ent<
Date: Fri Jul 13 12:23:42 2007 +0000

First Draft

If we push it using git svn dcommit, it’ll be committed into subversion and
reimported as:

commit 8200f32f61432004b488d063564ac9dae7bf6827
Author: david >david @cffdd316-8dd2-4046-8f43-d0df91842a18<
Date: Fri Jul 13 12:23:42 2007 +0000

First Draft


Limitations
Tools like git-svn or hgsubversion are working perfectly fine as long as you use them just as a subversion client. There is a serious limitation in what you can push and pull from and to a subversion server. Particularly, problems arise if you are using the usual DVCS push and pull method to exchange changesets. Why so? If you push and pull from other DVCS repositories you might have to create a merge. Modern DVCS like Git, Mercurial or Bazaar represent history as a directed acyclic graph (DAG). Therefore a merge is a commit which has two (or more) parents, which means that a merge is the resulting connection of two parallel strands of history. Now this is a very comfortable and powerful way to describe history in parallel development. Sadly subversion doesn’t handles history and hence merges the same way (at least not priort svn 1.5). As a result, it is not possible to represent the Merge from a DVCS in subversion.

Different bi-directional bridges have different approaches to this problems. Git-svn will commit the Merge but not the commits which are part of the seconds strand of history, while hgsubversion will abort if it has to push a merge. The fact that hgsubversion aborts in case of a merge is our actual problem. We want to use Mercurial and therefore need to find a way to push a merge to subversion.

A usecase
You shouldn’t care much about these limitations. Usually, people are using the bi-directional bridge locally to be able to do offline commits or bisect a bug. In that case, everything will work fine.

But why do I write a complete blog post about a hg to svn bridge if the problem is already solved? The answer is pretty simple.

1. Imagine you are working in a small team. Everybody in the team knows Mercurial and everybody likes to use it. Moreover you are working offline from time to time, and the members of the team sometimes have to exchange unfinished features with other members. In that case you will probably use Mercurial as your version control system. The problem here is the customer. He dictates the VCS and it has to be Subversion. Now subversion at all is not that bad, but in your particular case, it’s a huge drawback. You have to find a way to mirror your Mercurial repository to the Subversion server.
2. A second use case is that you are working on an OpenSource project which uses github or bitbucket to host it’s repositories. As you are using the OpenSource framework also at work. You have to use Subversion and you want to use svn:externals to integrate your fancy framework into the existing Subversion repository

As you see, there is a use case for DVSC to Subversion mirror. As no such tool exists at the moment, we’ll try to implement a (frankly, very stupid) mirroring mechanism.

The idea and it’s limitations
We see that we need to mirror a existing Mercurial repository to Subversion.
We also know that we cannot use the existing tools. Our requirements are the following.

1. Mirror a Mercurial repository into a Subversion repository
2. Track latest synchronized changeset
3. Handle merges

Note that we would have been able to do this with git-svn, while it’s not possible to do it with hgsubversion.

A few assumptions about the environment where we want to use our mirroring mechanism helps us to simplify the requirements.

1. We do not need to preserve the author information
2. We have a central Mercurial repository called Gate
3. No commit will be done into the repository other than our mirroring (and believe me, things get ulgy for you if you try to…)
4. We do not need to preserve all commits

So what is the end result? We just need to find a way to push all changesets and just ignore all merged changes, but commit the merge itself. This should be sufficient.

In our particular environment everyone has his own repository, but one person integrates all changes into one repository called the Gate. Commits reaching the gate are committed to Subversion.

The implementation
To make a long story short (it’s getting late). We are using Mercurials log command and it’s option to obtain a linear history that can be pushed. To get the the history, we use

hg log --follow-first

This will return the history omitting all merged changesets but including the merges itself. We silently drop the changesets that were merged, but retain the result. As we need to get just the SHA-1, we use the –template option to get the node. We then iterate over the history, updating our working copy to each changeset in the history, adding all newly created files and deleting all removed files and then comitting the current state of the working directory. So here is our final script

#!/bin/sh

lc=0
cont=0
if test -f "LAST_COMMIT"
then
	lc=`cat LAST_COMMIT`
	cont=1
fi

for hash in `hg log --follow-first --template "{node}\n" -r $lc:tip`
	do
		if test $cont -eq 1
		then
			cont=0
			continue
		fi

		echo "update to $hash"
		if ! hg log --template "{desc}\n"  -r $hash > COMMIT_MSG
		then
			echo "Canno get log" >&2
			exit 127;
		fi
		cat COMMIT_MSG

		hg up -C -r $hash
		for file in `hg log --template "{file_adds}\n" -r $hash`
			do
				echo "add $file"
				svn add --parents $file
			done
		for file in `hg log --template "{file_dels}\n" -r $hash`
			do
				echo "del $file"
				svn rm $file
			done
		svn commit -F COMMIT_MSG
		echo $hash > LAST_COMMIT
	done

It looks scary, and yes it is scary. But for the moment it works. Our simple hg to subversion bridge is finished.

Warning this is a potential boring blog entry. Apprx writting time was about 5min

I once tried writing applications for the iPhone and started to like the concept of Obj-C while still I hate the syntax and I don’t like the API that much. Android makes things simple for me, and I guess for most people knowing a little bit java. It implements big parts of the Java standard (although it doesn’t claim to be standard compatible) which makes it easy to start writing apps if you know the libraries a little bit. Android also includes the powerful HTTP libraries of the Apache project as well as Json and XML parsers.

Having said this, the most important factor why I started to love my phone and the Android system: I can easily deploy apps on my phone, I debug it on my phone, I have nearly the complete power of the java framework and I totaly enjoy seeing my first app starting on the actual phone after 1 hour of coding. The app itself is fairly simple. It’s a basic search interface phpMyFAQs upcoming Rest API.
So you can search an existing phpMyFAQ installation for a search term and display the result. Although the app needs phpMyFAQ 2.6.0-alpha it’s already available in the Android Market. So feel free to check it out. You can test it with the URL: http://faq.phpmyfaq.de/. The source can be found at http://github.com/thorsten/pmfMobileKit. Expect more updates to the app soon.

Inhaltlich ist das CRE eher technisch aufgestellt und befasst sich mit allem was den Nerd erfreut, sozusagen die Cub-Mate des audiophilen Tekki. CRE ist also gut für die Geek-Gesundheit, liefert einen Blick über den Tellerrand und, hepp, befasst sich sogar mit Soziologie und Politik. Und manchmal werden sogar langjährige Wünsche erfüllt.

Absolute Highlights sind natürlich Folgen wie die Bayrische Hackerpost, Internet Memes und der Mifare-Hack. So ist es kaum verwunderlich, dass man nach späterstens zwei Wochen CRE freie Zeit anfängt unruhig den CRE Blog anzusurfen und den Podcast Feed zu abonnieren. Leider fehlt immer noch was zum Thema PHP, aber das ist ja per se uncool, deswegen wird das wohl auch nichts mehr. Schade eigentlich, vielleicht gibts ja nochmal was dediziertes zum Thema Flamewars, da kann man PHP dann immer gerne einstreuen. Überhaupt gibt CRE immer Anlass zur Diskussion, meistens weil ein Detail in irgendeinem Nebensatz nicht stimmte oder allgemein der Gast inkompetent war, aber eh klar: man selbst ist immer der bessere Experte (vorallem wenn es um DVCS geht, wo’s vielleicht sogar stimmen würde *rant*). Aber auch “ranten” gehört zur Informatikerausbildung. Also immer brav CRE hören.

Was man am CRE verbessern kann?:
Ich finde die Idee mit einem Photo pro Podcast eigentlich ganz gut. Mehr fällt mir auch nicht ein.

Und jetzt weiter in der von Tim initiierten Blogkette:
Zurück zu Nummer 12 in der Blogkette.
Weiter zu Nummer 14 in der Blogkette.

und jetzt weitermachen!