Category: Blog

Value Conservatism

no english translation

Ignorance does not prevent loss of rights

No english translation yet

Killergames in the Bundeswehr

When a 19 year old likes to play digital cops and robbers (aka Counter-strike)  here in Germany, our goverment is quick to renounce this as “killer game” that is totally not consistent with the human dignity our basic law holds so high. If he goes to Afghanistan with our military (“die Bundeswehr”) to bomb fuel trucks, it’s not only no war, he serves our democracy and an important mission in the war against terror. This hypocrisy totally makes me sick. Somehow no one could yet explain to me what we’re actually doing down there — apart from the obvious motivations to brown-nose the Americans. So we marched in with the UN to beat our democratic values into the taliban, but in the end we did not really want to go through with it. So now we’re defending a government, under which women still are stoned to death for adultery, with the lives of our soldiers — just because the enemy happens to be even more inhumane. I still don’t get it.

Majority of german welfare recipients wouldn’t move for a job

no english translation yet

.

Wahl-o-mat 2009

Just found out that the new Wahl-o-mat for the upcoming federal elections in Germany. The Wahl-o-mat asks you a couple of questions and tells you how similar your political views are compared to a number of political parties. The result was not really a surprise for me:

wahl-o-mat

Interesting is the even higher match with “the Left” party than with the pirate party. Principially I would not mind a left alternative in the elections, but “THE LEFT” isn’t going to be it. I don’t trust them.

fforw.de on WordPress

This blog has been relatively stale for a while now — mostly due to increasing work pressure and the limited amount of time I had left for it. What little time I had was mostly wasted on coding on it. The previous version was written in turbogears which seemd like a good idea back in 2006. Over time I kind of regretted that decision, which was not really Turbogears fault, but just caused by my laziness to really update it etc.

I’ve been frustrated with the old blog code and the old design for some time now and wanted to redo everything and already started multiple attempts in various technological reincarnations — the latest being an implementation in java/spring using my jcouchdb library. The design got more and more ambitious over time; so ambitious that it would basically require me to work full-time on it. Continue reading

Memory consumption changes in svenson 1.3

Implementing a streaming attachment feature for jcouchdb, I started to wonder whether it would be a good idea for svenson to support JSON parsing from a stream, too, as I don’t really need the complete stream to start constructing the java object graph.

Implementing stream parsing was really nice and easy thanks to the units test present in svenson. After that, I came upon two ways to generally cut down on memory use. All tokens with fixed values could just have a single instance. The recording of tokens to provide token based look ahead was not really needed in all cases. But how much does that save?

As a test case I wrote a small tool class to generate random, nested JSON datasets, generated two test files of 65kb and 4.5mb size and parsed these with svenson 1.2.8 and what now is svenson 1.3.

Measuring the actual memory usage for these two test files proved to be difficult. Somehow none of the programs I tried seemed to give me the data I wanted. Eclipse TPTP just ignored Strings that were no member of any class but just parameters, making stream and string parsing look exactly the same memory-wise. tijmp and others did not provide the data I wanted at all.

So in the end I wrote a little python script that parses a hprof ASCII output to

  • sum up all memory use
  • group allocations by class type, but only if the stack trace of it touches svenson
  • output the top 10 of those classes and the sums

This provided meaningful data and also showed some points for further improvement. There was a huge number of java.lang.reflect.Method allocations which turned out to be caused by svenson inspecting the target classes for annotations and appropriate methods which was done on a per target basis instead of the better per target class basis.

All in all the memory usage went down quite a bit:

memory usage for different svenson versions, with and without streaming

memory usage for different svenson versions, with and without streaming

45% less memory for the small file and 62% for the large file for all allocations. I think that is really good..

Below are some links to the files needed to repeat the benchmarking. The transform hprof script might also prove to be useful for other projects if changed appropriately.

The new jcouchdb release will also use stream parsing.

Links:

edit:
The command to generate the hprof file was something like

java -agentlib:hprof=heap=sites,depth=100,cutoff=0 -cp .. svensonperf.ReadJSONOld big.json

JsServ – Serverside Javascript and DOM emulation

I played around with some ideas about JavaScript on the server-side and came up with this little prototype. It’s a set a spring components that allow running the scripts in a website on the server side in case a user has no support for JavaScript or has disabled it.

The following diagram shows the way things work:

The parts of jsserv

The parts of jsserv

The DOMInterceptor intercepts the HTML output of other controller and initializes a dom state with it. The document itself is parsed into a DOM tree and the referenced scripts are loaded and executed. Additional patch scripts can be defined to alter the behaviour of other scripts.

The current version adds
<a class="eventHelper" href="/app/event?uuid=42">...</a>

Links around every element for which a onclick handler is registered. The links point to a DOMEvent Controller that triggers updates in the user’s DOM State.

A little example scripts implements a collapsable tree that changes the style classes of nested unordered lists. With the JsServ DOM Manipulation this works with JavaScript as well as without JavaScript on the client side.

While this code is only a rough sketch it promises a lot in terms of vastly reducing the amount of work for sites that must use javascript to get an optimal user experience but who cannot or want not to have a java-script only site. Although the link-as-click event method is rather limited, it is good enough to make a lot of DOM manipulations possible. Expressed only once in JavaScript. Running in it’s deluxe form for people with client-side JavaScript and in a basic form for people with the help of using server-side JavaScript. All is seamlessly integratable into all kinds of Controllers.

Links:

Dependencies:

Edit: code.google.com link added, update to 0.12

Demo Video Archive

Back in the day when I was involved in the demo scene, I was a coder for Haujobb and did some demos / intros for the Amiga1200. Demos are realtime rendered multimedia art. Today most demos are coded in C or even C with some scripting engine, but back in the days it was pure 680×0 assembler. The development took ages — Burning Chrome for example took me about 9 months of work which did not include the development of all effects included. All that work culminated in releasing the demo, usually at a demo party (My trusty old A1200 and me traveled quite some way across europe). If you were lucky, your demo really got one of the first places and you could return home with some fame *cough* and a bit of prize money.

Some time ago I started to capture some of my favourite works as videos to preserve them and finally got around to set them up here in my blog. Continue reading

© 2024 fforw.de

Theme by Anders NorénUp ↑