Clojure Web Application
I build up a Clojure stack for web application development.
First Results can be found here: https://github.com/kremers/Clojure-Memcached-Connector
Clojure + Sandbar + Enlive + spymemcached on membase server
Membase vs. other K,V Stores
- Not Master,Slave! Peer Replication
- Fastest, Supported and Tested Platform
- Also available at Heroku (5mb for free)
Enlive vs Hiccup
- Pure DRY code should be separated from the page markup.
- HTML should be semantic markup. CSS should work for the design.
- Sandbar creates stateful sessions in memory, but we want to scale. Let’s store the sessions in our k,v store. So we need an implementation of ring / ring-core / src / ring / middleware / session / store.clj for memcached
Logging
- Finally: Simple logging (Category, Message) to memcached, quota with flush to file
First experiments with Heroku
Heroku is an excellent cloud application platform. Because the Java platform has so much impact, I’ve never tried to write plain ruby applications. Now they have introduced Java, Node.js, Python, Scala and Clojure support. Cause I wanted to try Clojure anyway, this seems to be a nice place to run examples and prototypes. What I really like is the deep integration of Git into the project structure. Git commands are used to create / publish data on Heroku. Also the concept of omitting filesystem storage for scalability seems to be a big win.
I had problems installing the Heroku CLI on Debian (lenny) because of SSL Certificate problems. Heroku CLI developers commented out the “error” line with the important message, explaining what caused the error.
~> export RESTCLIENT_LOG=stdout ~> heroku create --stack cedar Enter your Heroku credentials. Email: xxx Password: RestClient.post "https://api.heroku.com/login", "password=hidden&username=kremers%40act-online.de", "Accept"=>"application/json", "Accept-Encoding"=>"gzip, deflate", "Content-Length"=>"50", "Content-Type"=>"application/x-www-form-urlencoded", "User-Agent"=>"heroku-gem/2.15.1", "X-Heroku-API-Version"=>"2", "X-Ruby-Platform"=>"i486-linux", "X-Ruby-Version"=>"1.8.7" /usr/lib/ruby/gems/1.8/gems/heroku-2.15.1/lib/heroku/auth.rb:96:in `ask_for_credentials': undefined method `[]' for nil:NilClass (NoMethodError) from /usr/lib/ruby/gems/1.8/gems/heroku-2.15.1/lib/heroku/auth.rb:133:in `ask_for_and_save_credentials' from /usr/lib/ruby/gems/1.8/gems/heroku-2.15.1/lib/heroku/auth.rb:71:in `get_credentials' from /usr/lib/ruby/gems/1.8/gems/heroku-2.15.1/lib/heroku/auth.rb:51:in `user' from /usr/lib/ruby/gems/1.8/gems/heroku-2.15.1/lib/heroku/auth.rb:11:in `client' from /usr/lib/ruby/gems/1.8/gems/heroku-2.15.1/lib/heroku/command/base.rb:22:in `heroku' from /usr/lib/ruby/gems/1.8/gems/heroku-2.15.1/lib/heroku/command/apps.rb:122:in `create' from /usr/lib/ruby/gems/1.8/gems/heroku-2.15.1/lib/heroku/command.rb:114:in `send' from /usr/lib/ruby/gems/1.8/gems/heroku-2.15.1/lib/heroku/command.rb:114:in `run' from /usr/lib/ruby/gems/1.8/gems/heroku-2.15.1/bin/heroku:14 from /usr/bin/heroku:19:in `load' from /usr/bin/heroku:19
After uncommenting the following Line (564 in /usr/lib/ruby/gems/1.8/gems/heroku-2.15.3/lib/heroku/client.rb):
error "WARNING: Unable to verify SSL certificate for #{host}\nTo disable SSL verification, run with HEROKU_SSL_VERIFY=disable"
After executing “export HEROKU_SSL_VERIFY=disable” everything worked.
Give Clojure a try
The first time I had contact with Clojure was in 2009, while writing my final piece of coursework for my degree on dynamic programming languages in big projects, focusing on Groovy. It was a bit hard for me to get to grips with Clojure, because the learning curve is quiet different to that of Groovy (which is very shallow if you come from a Java background). One of Groovy’s painful aspects appeared during performance tests. Possibly because the language hasn’t got the same academic background as LISP, Haskell or C++.
Why I have not choosen Scala
I tried Scala because I excepted it to be more academic and exact. A major reason was that I have been impressed by Martin Odersky working on Scala. My first functional attempts at Scala were unsuccessful, due to the lack of JVM TCO. It may be due to my lack of experience that the Scala code seemed to look like “write only” Perl code. Programming Scala felt more like writing in Java, but with a lot more capabilities and primarily more complexity. The language is really hard to understand, even the complexity of its type system is astounding. I’ve been quite happy using this blog post from Stephen Colebourne to help me. I had some of the same issues after some experiments with Scala. After seeing the answer from Martin Odersky I was a bit disappointed by how he deals with criticism. Blaming people who are investing time to point out weaknesses of a language and its problems to spread FUD.
How I started learning Clojure
Getting into a complete new environment with its own paradigms is hard. Especially if you can not reuse your knowledge from imperative / procedural and object oriented programming languages. Having seen a few real world Clojure applications, I was able to get an understanding of its Java interoparability. With the help of tools like “leiningen” it was easy to build my first applications.
Why I except it to be worth a try
Clojures built-in functionality to deal with the lack of TCO in the JVM (“recur, lazy sequences, …”). I searched a long time in the Scala API for such a feature. It’s not just a wide mix of object orientation with a few functional concepts, which feels like an advantage to me. The community is also adopting good libraries like these for website templates (Enlive, …).
Where to go from here
I will check out the samples for Heroku and Clojure, since Heroku is one of the most popular cloud providers and all of the infrastructure management is done for you. And now they are properly supporting Clojure. There are also goals to play around with the language such as the “petshop” and examples with database / NoSQL connectivity. Once I have tried writing these things myself, I’ll write another blog entry on it. One of my goals is to ensure that Clojure can be used in bigger web projects. I’m not sure Clojure should be recommended for such business projects yet.
[1] http://stackoverflow.com/questions/310974/what-is-tail-call-optimization
[2] http://blog.joda.org/2011/11/scala-feels-like-ejb-2-and-other.html
[3] http://entwickler.com/itr/news/psecom,id,58955,nodeid,82.html
[4] http://en.wikipedia.org/wiki/Write-only_language
[5] http://de.wikipedia.org/wiki/Fear,_Uncertainty_and_Doubt
[6] https://github.com/technomancy/leiningen
[7] https://github.com/cgrand/enlive/wiki/
[8] http://blog.heroku.com/archives/2011/7/5/clojure_on_heroku/
[9] http://thecomputersarewinning.com/post/clojure-heroku-noir-mongo
Where does JSF really add value? Event driven applications and the web, contrary paradigms.
The JEE Ecosystem got bigger and bigger due to the increasing market impact of Java. More and more frameworks were integrated into JEE. After JEE5, JSF became also a part of the standard set of frameworks. Most mistakes are made when deciding whether to choose JSF or not. SUN Microsystems defined JSF as “an API for representing UI components and managing their state”. So one of the primary goals was to build server-side user interfaces which react to events (like mouse-clicks) and manage states (e.g. caching form entries after leaving a dialogue). This leads to a Rich Internet Application (RIA) which should behave like a desktop application. Now two paradigms are connected to each other, and they do not really fit. An HTML Website sent over HTTP can not carry a state by default, it can not trigger events in a direct way and it is not possible to interact with the operating system (everything is running in a browser thread which isolates the website). Finally, the idea of JSF is to provide an event-driven architecture like that of desktop applications based on request-response driven distributed model of websites. To deal with the issues, JSF makes use of cookies, javascript, JSF User Sessions and a so called JSF component tree which represents the state of all components. The user session is saved in the RAM of the application server for every user until a timeout is reached. The “view” of the user also contains a component model which is synchronized with the session on the application server to reach the “sicky state” behaviour. If you descide to connect the two worlds (web application and desktop application) you have to live with the consequences of such a model. This may lead to different workarounds (for example working with bookmarks is difficult in such an architecture).
JSF only feels good, if it is used as it’s meant to be. I.e. for Internet Applications which behave like desktop applications.
Most poeple, companies or software architects choose JSF because it is part of the JEE standard. They assume that it is the industry standard and that it cannot be wrong to use it, regardless of the functional and non-functional requirements. There are several non-technically-related shaky arguments for such a decision. Like “enterprise support, a ‘proven’ solution, included in standard” which sometimes leads to self-protection of decision makers in case of a project failure. This does not minimize the project risk. Quite the opposite, it leads to shift the liability onto the software developers, by forcing them to think in paradigms that don’t fit the customer requirements. Other circumstances can also lead to similar sub-optimal decisions. For example lack of experience, fear of getting in touch with new technology or third-party regulations when choosing a framework. Also, having experience and expertise with a single product or technology can result in the assumption that this is the “silver-bullet”, meaning comparisons between the different frameworks and technologies are skipped. Result: The aim is the ability to deliver something, rather than aiming for quality and maintainability.
Decisions based solely on self-protection are really risky.
What else is omitted from the rose tinted articles about JSF? One thing is the Post-Back Pattern: JSF is based on the so called “post back architecture”. This is how it works: 1. A page is loaded. 2. All requests are now sent with HTTP-POST. 3. The client recieves the result and processes it with javascript. Steps 2 & 3 are repeated until the client leaves the page. After the client leaves, the session is still available until the JSF session timeout (and longer if resources are bound to the JSF session). This has several disadvantages:
- There are no direct ways to address resources like there should be in HTTP (HTTP-GET)
- No XML/JSON service interaction, communication made of proprietary javascript functions
- Memory consumption caused by session and component-tree synchronization
- Hard to test (This issue may not be up to date)
A lot of sub-optimal design decisions have been made in the JSF architecture.
JSF is a really complex framework, because a lot of things are affected under the hood. The complex six step phase-model is an example of how to handle states (see: step diagram). The complexity is not the only issue; cpu-time for processing the steps for every request and the RAM which holds the user sessions for each synch in the component tree must also be considered. Java-Script was a must have in JSF 1.0. After JSF 2 many things changed, for example graceful degradation was implemented to be more fault tolerant to users with java script limitations. Due to JSF’s complexity and because it is so expensive to fulfill simple requirements, frameworks like JBoss Seam are getting more and more popular. The goal of such frameworks is to eliminate complexity at architecture and API levels. If you are forced to work with JSF, JBoss Seam is one of the best solutions to get out of the complexity, though JSF is still running behind the scenes, which affects application speed and scalability.
Compared to other frameworks JSF is complex, CPU and RAM intensive.
Many business applications can be classified as “data capture / store and modify / CRUD” software. High Performance is not an issue here and a large part of the user interface consists of reusable components like input forms & text fields. Component Libraries such as IceFaces and MyFaces come into play. In this context the concept of a “plug and play” component solution works. Such applications can have complex data input tables and validation rules, resulting in large, complex calculations, but the design of the page is simple. On the other side are websites with a lot of design and content. If you are forced to implement such things with JSF you’ll end up with a bloated codebase, which is hard to maintain.
There are domains where JSF adds value.
However other people say that JSF is the silver-bullet and that all problems can be solved with JSF?! You should not trust these people! Most of the stuff that you can find (online articles, java-magazine, …) are from people who clearly recommend JSF. Most of them are biased because they work with JSF every day and their company advises customers to use it. So why lower their own worth on the market? They will not write about the workarounds in their software solutions, the bad experiences they had once JSF was in place and all the scalability problems. A long time ago I bought the “Java Magazine”, which is mostly full of articles from consultants to boost their own value. The quality varies a lot from article to article. The main article was called “Web Frameworks, Struts, JSF and ZK compared”. The author talks about JSF as a more modern framework than Struts. I think the paradigms of event-driven and request-response driven architectures are incomparable. Problems with the component tree or real world experience with big projects were not mentioned. I know from projects where custom JSF user-session recycle services have been developed to prevent memory overflows with only a few hundred concurrent users.
Trust yourself! Evaluate different frameworks. Read about technical details and do not trust the hype a technology is given.
So, what is the next big thing for the future? After the growing market impact of javascript due to application development for Apple IOS and Android, architectures like SOFEA have good chances in the future. The biggest problem is that there is no standard stack defined which brings all of the necessary javascript frameworks together. Until then it is better to stick with the Spring (MVC) stack or Grails.
MphasiS, an HP Company, has also done evaluations of JSF for big, complex projects. The results reflect my experience. Check out this excellent article by Mohan Borwankar. Click here to read the Article of Mohan Borwankar.
You shold also check out this presentation from reliabledesigns.
The Identity Template – XSLT 2.0 on steroids
Identity templates are arguably one of the most important things you should know about XSLT. Identity templates are really useful if you want to change only a part of the XML input data. The idea is not to create a explicit node copy of each item. The output of the identity transform is the same as the input, except for CDATA elements and attribute orders. Additional templates are created to define the exceptions for the matched elements which should be modified. This is mandatory if:
- The Interface / XML structure changes
- Output enriched with rule results in additional nodes
- Non-redundant template code is a must-have
Example of a XSLT2 Identity Transform template:
<xsl:stylesheet version="2.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:template match="@*|*|processing-instruction()|comment()"> <xsl:copy> <xsl:apply-templates select="*|@*|text()|processing-instruction()|comment()"/> </xsl:copy> </xsl:template> </xsl:stylesheet>
From now on, other templates can match nodes which should be modified. For example we wish to remove all nodes with the name “Bill”:
<xsl:template match="Bill"/>
Because the template is empty, the node is removed in the output.
If multiple transformations are applied, XML pipelines are better (XProc, …). Projects under active development include QuiXProc and Tabular.
XSLT 2.0 for Adobe LiveCycle / ADEP
Here I will show you how XSLT2 can be used in a Adobe LiveCycle / ADEP process. I found solutions where people put a saxon.jar into their application server library path. The whole application on the server uses the alternate XSLT processor, if you put it to the application server classpath. A test with JBoss resulted in errors which occurred during runtime (like the content of a modified process can not be saved). The working alternative is a custom plugin (called DSC). The classloader of the DSC component is isolated from the environment, so you won’t get into support problems (except for the DSC itself). I’ve choosen saxon as the XSLT2 processor (HE edition). The edition can simply be changed by putting replacing the saxon library in the jar file. You can download the DSC here.
Dovo shavette test
I’ve tested the shavette from DOVO as an alternative for my straight razors.
- Optic / Haptic: The first thing I’ve noticed is the weight; the shavette is a lot lighter than a traditional straight razor. It’s simply made of plastic, except the upper “golden” part (aluminium). The upper part holds a plastic carrier for the shaving system. There are three different systems (green, black and red). When the red system is attached, the blade covers only the half of the plastic holder as you can see in the picture below. The end of the holder was a bit longer than the blade and scratched over my skin, so I removed it.
- Systems compared: I tried the red system at first (with the bundled dovo blades). It is easy to set up (just break the double-edge razor blade into two pieces and add one of them to the holder). The sharpness of the blade is impressive but the feeling is not comparable to a straight razor shape. At first the blade is short, so the handling differs and you’ll need more time for the shave. In addition the blade is quite aggressive, compared to a straight razor. The black system feels better, it fits the whole length of the holder and you can handle it like a straight razor. At last I have tried the green system, which has the highest price per blade (factor 10x compared to the red system). The big blade seems to be as near to a straight razor as possible, but due to the design of the holder, only the last part of the blade is flexible, resulting in nearly no difference in comparison to the black system.
- To summarise: Each system is quite aggressive during shaving. The blades are very sharp and have a good ability to hold an edge. The blades are disposable which is not as ecofriendly as a straight razor. I wouldn’t recommend it, since the blade is too inflexible in every system. Compared to an real straight razor the shavette will cost you $ 40, where a carbon steel straight razor will cost $ 90 (I think it is worth it).
Picture 1. Different systems and blades.
Picture 2. Black system assembly
Phono tube amplifier
This is the first design of my tube phono stage. I worked on a second design and finished the PSU. I’ve build an external PSU and removed the parts from the chassis cause the transformer injected hum into my circuit. When I’ve moved to my new flat, I’ll test different Phono stage designs and rebuild the amp part.
Hornlautsprecher fertig ;)
Nach einiger Arbeit ist der geplante Breitbandlautsprechner (lt. Mikro Horn 2011) fertig geworden. Hier einige Bilder vom Aufbau bis hin zum fertigen Lautsprecher. Auf dem ersten Bild ist der Innenaufbau zu sehen. Die Teile sind noch nicht verleimt, alle Gehrungsschnitte habe ich mit einer Tischkreissäge von Einhell durchgeführt (höchst sicherheitsbedenklich bei dem Gerät) und mit einem Präzisionswinkelmesser auf 0.025 Grad kontrolliert.
Der Einbau der Frequenzweiche und des Dämmaterials hat probeweise nach dem verleimen erfolgt. Auf den nächsten Bildern wurden die Boxen bis auf die rechten Seiten verleimt, zusammengesteckt und verprobt. Getrieben von einem 13W an 8 Ohm Class T Verstärker spielte der Lautsprecher probeweise. Erheblichen Gewinn vom Ton her hat das Endverleimen, Schleifen, Spachteln und Füllern des MDF Materials gebracht.
Lackiert wurden die Boxen in drei Schichten mit 2x Füller und 1x 2K Kunstharzlack in Schwarz mit Kompressor und Sprühpistole. Vom Schleifen / Lackieren habe ich leider keine Photos gemacht. Merklich war aber, dass es gar nicht so leicht war den Lack mit einem Exzenterschleifer zu bearbeiten der keine Drehzahlreglung hatte.
Klanglich spielt das Horn sehr gut! Es ist kein Pegelmonster (5 Watt Maximalbelastung, 15W Invervallbelastung), sollte in Räumen bis 25m² aber gut spielen. Wie viel Tiefton mit diesen kleinen Boxen entsteht ist recht verwunderlich. Die Bässe sind wie vom Horn gewohnt staubtrocken. Bei Musik mit extremen Tiefbass und dem entsprechenden Pegel sieht man jedoch wie die Membranaufhängung anfängt Bläschen zu bilden. Also nichts für Dub-/Dubstep Fans mit Ansprüchen an hohe Lautstärken. Besonders der Klang von Instrumenten in Klassik, Jazz und Funk kommt aus den Teilen mit einer ungeahnten Natürlichkeit.
Passed PRINCE2 Foundation
I passed the PRINCE2 Foundation exam today.
PRINCE2® is a registered trade mark of the Cabinet Office.
The Swirl logo™ is a trade mark of the Cabinet Office