Saturday, November 03, 2007

An Alle die dies tatsaechlich lesen...

... macht euch bitte lustig. Ich selbst nehme mich schliesslich auch nicht so ernst, ausserdem bin ich (und werde es immer bleiben) ein Anfaenger.

This is my zen.

Friday, September 14, 2007

on the path to enlightenment...

My (and others who I infected) reaction to playing around with erlang, scheme and common lisp, was frustration. Not because these languages are bad, but because they are so nice and fun to programm with! One could even argue, that this alone results in reduced development time and better programms, but while this is definitely true, it hides the fact, that the afore mentioned languages increase efficiency of sw development also by technical means. To provide evidence for this hypothesis is out of the scope of this document, please look for yourself, there's plenty of good material about common lisp, scheme and erlang on the web, there are even life lisp coding videos on google video!

I recently bought the new erlang book. It is great and I would recommend it without hesitation.
There are also great books online that I started reading: htdp and sicp.
Oh and not to forget to mention "little schemers" of wich the chapter about the Y-combinator is online ...(yeahh nice!)

Now, all I need to do is convince my boss to start using erlang or common lisp.

There is just no point in wasting my time with java (except for j2me!).

Wednesday, July 25, 2007

Blub Paradox

Ich habe da einen interessanten Artikel ueber das Blub Paradoxon gefunden.
Jenes besagt, das fast alle Programmierer der These zustimmen,
dass Programmiersprachen sich in ihrer "Macht" und Generalitaet unterscheiden, aber trotzdem
nicht bereit sind einzusehen, das andere Programmierespachen besser sind als die, die sie
habituell verwenden.
Verdeutlicht wird das am Beispieln eines eingefleischten "Blub" Programmierers.
"Blub" ist eine P.Sprache die im mittleren Bereich des Generalitaetskontinuums
liegt, das sich zwischen Maschinencode an einem Ende - und Lisp am anderen Ende
erstreckt.
Der Blub Programmierer kennt alle Sprachen, die schwaecher als Blub sind, und fragt sich,
wie man bloss ohne eine Feature "x" vernuenftig programmieren kann(- natuerlich verfuegt Blub ueber x).
Ausserdem findet er, dass Blub alle Features hat die er braucht, und ihm erscheinen features in
"hoeheren" Sprachen als verwirrend und unnoetig. Er denkt in Blub, und Blub ist sein Horizont -
und alle Probleme die er fuer loesungswuerdig befindet, sind in Blub loesbar!

http://www.paulgraham.com/avg.html

Sunday, July 15, 2007

functional vs oo

well it's been a while and I have come to trivial but usefull conclusions lately.
Once I thought functional programming was fundamentaly diffrent then
oo style programming, but I actually realized how well many aspects
of fp match to elements of oop;

Functions are simply Objects,
Closures are anonymous class,
certain design patterns ressemble
monads(decorator, chain of reponsibility,...)

oo style programming can be seen as a restricted variation of functional programming.

That matters because the key aspects of oop is encapsulation and
information hiding. This can easyly be achieved in fp through the
use of closures and the fact that functions can be treated like
any other data.

In oop very explicit notations usually exists, wich couple
certain functions to certain data through the notion of objects. Both, to increase readability of complex programms, and to lighten the restrictions that come with encapsulation, an explicit notion of inheritance is used.

While all this seems pretty obvious to most, frankly, I did not
appreciate oop after doing a a bit of fp, until I found myself reading through some javascript code that I wanted to optimize.
The code was using a many closures like this, which I removed
by placing the variables that the closures contained in
properties of objects, that also contained the functions
corresponding to the closures' code.

When I was finished I had not only increased speed by 40-60%
but was also surprised by the fact that my code looked a lot
like good oo-style code.

So in my opinion every programmer should learn to think functional
in order to get a hold of what the importance of encapsulation and code reuse.

That said, most javascript interpreters(javascript by itself not a purely functional language like haskell anyway) could do this manual optimization of closures automatically.

It is rumored that modern lisp systems and erlang(using HiPE) interpreters/compilers are very close to compiled "C" code performance:
See i.e. http://www.sics.se/~joe/apachevsyaws.html
or http://bob.pythonmac.org/archives/2006/09/21/erlang-binary-performance/

But to emphasis my point of oop vs fp regard this page:
http://openmap.bbn.com/~kanderso/performance/java/index.html

That's it for today.

Saturday, March 24, 2007

Recent Comparison of jMock 1.1 and EasyMock 2.2

My Colleges and me are in the process of figureing out wich mock frameworks to use. One of my colleges has experiences with jMock and I have used diffrent versions of easymock. We wanted a detailed comparison to help us decide what the strengths and weaknesses are of the diffrent Mockframeworks. During a web search we discovered this comparison between jMock and Easymock. Although, regarding the authors background not necessarily, but to me most likely, this comparison of Jmock to an unspecified version of Easymock is biased towards jMock.
Many diffrences/disadvantages in this comparison are obsoleted by more recent versions of Easymock, and speculating on the version used in favour of the author would imho result in 1.3 wich dates way back to 2005.

The desription of the link to the jMock project on the easymock project page, states that jMock opposed to easymock uses
another approach to define expectations that results in more flexibility to set expectations (you may specify almost everything imaginable) at the cost of less flexibility when refactoring (refactorings like method renaming and parameter reordering will break the tests) and loss of code completion when defining expectations or test-driving code.
Well this note is definitely true for older version of easymock, and probably stems from the same era as the comparision hosted on the jMock page. Since version 2.0 easymock started to look a lot more like jMock in terms of behaviuor specification. I found that the easymock approach helped me doing test first programming, in cases where I was not only specifying the class under test but also the mocked interfaces, because modern IDEs like eclipse 3.1 and higher may come up with some fancy hinting/auto fixing feature, that will create non existing methods and classes.

Back to the jMock hosted comparison of easymock vs jMock, one drawback the authour of the comparison states is:
EasyMock lets you change the way that arguments are matched on a call-by-call basis, but the syntax is awkward and same matcher applies to all arguments.
Luckily this is not true for Easymock versions higher than 1.3, but let's take closer look anyway.
As example of how (not awkward and brittle) one specifies the beahaviuor in jmock this code fragment send on its mission to insult its readers intelligence:
mock.expects(once()).method("method1").with( eq(a) );
mock.expects(once()).method("method2").with( same(b1), ANYTHING )
.will(returnValue(method2Result));

Did I just read that a mock object(wich really is NOT the mock object) expects an invocation of a local method called once()(wich it does not), and that the result of the expecation is some object that returns probably a method (wich it also doesnt) with something equal to "a"?
Of course I do understand what this behaviour specification is all about, but to be able to write such a specification, one has to learn a syntax/api not as Java-ish as EasyMock, where the only necessary quirk is the distinction between behaviour recording and verification(wich was clear to me at once when I first saw it).

The author continues to state that:
This means that expectations are more verbose but precisely and clearly specify the expected behaviour of the object.By precisely specifying expected behaviour you get flexible tests1 that break only when the actual behaviour is different from expected behaviour, and do not break when you make unrelated changes to application code.
To my knowledge it possible - without extensive API knowledge or awkward syntax - to specify any behaviour with abitrarily varied levels of precision with easymock. In jMock you were spoiled with this kind of flexibility right from the beginning, but this flexibilty is achieved only by introducing some drawbacks i.e.:
  • test development/refactoring is harder because mock-method invocation errors will only show up during runtime
  • after i.e. adding a parameter to method1 one has even more problems fixing this than merely changing the name of method1
The last point is especially dangerous in a multi developer team. The brittleness of the test cases is exactly what I want. There is added value in compile time checks.

Now let's have a look at the Easymock (2.0 and higher) version of the code snippet:
mock.method1(eq(a));
expect(mock.method2(same(b), anyInt())).andReturn(method2result);
Notice the subtile diffrences, in jMock one provides the method parameters in a non typesafe way through the "with" method, while in easymock one provides the arguments matchers where the actual parameters would be written. Also through the use of Java 5 generics in easymock the behaviuor definitions can be checked at compile time for type related mistakes.

Another great diffrence between the two examples are that in the jmock example "mock" is a control object and in the easymock example, "mock" is the mock object, that implements the interface we wich to "mock".

One drawback of easymock is that because method1 returns void we have to call "expectLastCall()" to get an object that allows us to specify some more expectation
like the number of invocations of the last method:

mock.method1(eq(a));
expectLastCall().anyTimes();

expect(mock.method2(same(b), anyInt())).once().andReturn(method2result);

Another more recent comparison dated around march 2006, seems to be done with a newer version of easymock, but it seems that also the author did not (yet) regard/compare more than the absolute minimum mock framework features one might want to use. The key point in favour of easymock were
  • method identification through actual method of the proxy
  • no extension of testcase base class
  • mixing of class mocking and interface mocking is very easy (you just use another implementation of MockControl)
  • very low API complexity
The points in favour of jMock were:
  • No control object is required
  • no replay/verify steps are necessary
Lets shed some more light upon this comparison:
The main point, that no control object is required in jMock is imho false. One exclusively operates on the control object and invokes a getter for the proxy. That is the reason just why
one cannot use the actual methods to specify behaviour. Easymock achieves refactoring safe actual method specification by introducton of its replay/verify concept. Furthermore, by exploiting new Java 1.5 features(static imports, generics, varargs) easymock almost completely frees the user from the burdern of being aware of this dichotomy in his daily work, and it even frees the user from the burden of subclassing some special test case base class as in jMock.

JMock on the other hand allows the user to specify behaviuor without having the recording/playback states, and mock behaviuor is automgically verified by base class methods after the method finishes. Also mock control object can be instantiated by a base class member method.
While this is for sure some helpful syntactic sugar, it is not so hard to do any of this with easymock because of the clever design of the easymock MockControl class and the usage of static imports.


Also the possibility to specify argument matchers was judged as "difficult" in easymock and easy in jMock.

Finally, I would like to point to an interesting article done by Martin Fowler, who explains some interesting aspects of overall applicability of Mock/Stubs/Dummies and Fakes, and tries to open a more general perspective on test doubles of all kinds. He also includes a small comparison of jMock and EasyMock. He also compares jMock to a very outdated version of Easymock it seems, as the code he provides as example, does not make use of the "import static" feature of Java 1.5, as well as some other features that could have been used to make the code alot more like typical jMock code. The article can be found here.
Although this article was updated 02 Jan 07
the easymock example he provides is also based on an obsolete version of easymock. Exactly why the author values mentioning some diffrences between jMOck and easymock is not clear to me. The article focuses on explaining the distinction between stubs and mock, not on comparing mock frameworks.
I will use this opportunity to rewrite this example of easymock:

public class OrderEasyTester extends TestCase {
private static String TALISKER = "Talisker";

private MockControl warehouseControl;
private Warehouse warehouseMock;

public void setUp() {
warehouseControl = MockControl.createControl(Warehouse.class);
warehouseMock = (Warehouse) warehouseControl.getMock();
}

public void testFillingRemovesInventoryIfInStock() {
//setup - data
Order order = new Order(TALISKER, 50);

//setup - expectations
warehouseMock.hasInventory(TALISKER, 50);
warehouseControl.setReturnValue(true);
warehouseMock.remove(TALISKER, 50);
warehouseControl.replay();

//exercise
order.fill(warehouseMock);

//verify
warehouseControl.verify();
assertTrue(order.isFilled());
}

public void testFillingDoesNotRemoveIfNotEnoughInStock() {
Order order = new Order(TALISKER, 51);

warehouseMock.hasInventory(TALISKER, 51);
warehouseControl.setReturnValue(false);
warehouseControl.replay();

order.fill((Warehouse) warehouseMock);

assertFalse(order.isFilled());
warehouseControl.verify();
}
}

Here is the rewrite:
import static org.easymock.EasyMock.*;

public class OrderEasyTester extends TestCase {
private static String TALISKER = "Talisker";

private Warehouse warehouseMock;

public void setUp() {
warehouseMock = createMock(Warehous.class);
}

public void testFillingRemovesInventoryIfInStock() {
//setup - data
Order order = new Order(TALISKER, 50);

//setup - expectations
expect(warehouseMock.hasInventory(TALISKER, 50).andReturn(true);
warehouseMock.remove(TALISKER, 50);
replay(warehouseMock);

//exercise
order.fill(warehouseMock);

//verify
verify(warehouseMock);
assertTrue(order.isFilled());
}

public void testFillingDoesNotRemoveIfNotEnoughInStock() {
Order order = new Order(TALISKER, 51);

warehouseMock.hasInventory(TALISKER, 51).andReturn(false);
replay(warehouseMock);

order.fill((Warehouse) warehouseMock);

assertFalse(order.isFilled());
verify(warehouseMock);
}
}



to be continued...

Friday, March 16, 2007

Future of Webdevelopment

The longterm future in Webdevelopment is for sure associated with fading boundaries between systems that provide a service wich incorporates distributed knowledge to form new knowledge, wich it distributes, probably only to one client in a secure fashion.

These boundaries are hard boundaries in terms of possible incompatibilities between interacting systems in heterogenous environment. We are confronted with securtiy issues, incompatibilies in protocol interpretations and service metadata propagation for automatic wiring of resources as opposed to hand crafted wiring as i.e. done with hyperlinks between dynamic system with a proprietary but similar structure, we are confronted wich diffrences on many layers of abstraction and orthogonal technical aspects like the necessesity to transform data not only to diffrent semiotic representationens but also to devices with diffrent availibility and diffrent means of human interaction.

As diversity greatly increases, the call for unification and simplification, that emerged from the complexity, gets louder and louder - and is eventually the root for the development of simple webframeworks of wich there are many(i.e. ruby on rails and groovy).
I think that while it is not the true path to oversimplifiy things, it is at the same time not much better to overcomplicate a specific system, that is the result of what can be refered to as webdevelopment activity to a state, where user recognized functionality of such a system is superseded by a system done by less less developers in less time.

It is also most often perceived, that many legacy systems exist, wich have grown old and big over many years, and wich are hard to extend or modify, but due to their long term presense have somehow proven to work and also have delivered ROI. They also mirror long time adaption to many improvements and changes that were realized required as the system faced reality year after year;
such a code contains real world experiences, that might be worth keeping. These nuggest often have the downside of not being documented properly, so that are hard to extract and a rewrite that preserves the current state of the system get expensive.

I see a need for some kind of methodology that allows to ¨pimp¨ existing legacy applications so that they are interoperable with modern web technologies.
I will have deeper look at REST based webservices, and means of simple object serialisation.
I am eager to create some utility that will adapt existing and new Java applications to web basesd interaction partners, be it a webbrowser rendering an Ajax based user experience or a machine utilizing a service offered by the Java application.

Tuesday, January 16, 2007

Back again

After a lot of meditation over efficient programming styles, some new ideas finally condensed in my defected mind:
  • always underestimated is the emotional aspect of coding, in a team environment one must be able to critisize and be critizised; also bad code pisses me of so much, that it pulls down my overall productivity
  • test driven development saves time, most of the time
  • clear structure and good documentation helps, because maintainance will be nicer (see 1.)
  • usefull integration testing is a far away dream, never to be reached in a pure XP manner including acceptance tests.
  • jira is cool - combined with good ole paper on the wall does best. customer requests - the customer(or any other person not a freak) will not put sufficient details for a bug or a feature request into the bugtracker or be helplessly faced with a complex and flexible task of specifeing an issue, here improvements to the GUI to reduce complexity by providing more project specific defaults would be nice)
  • wikis are usefull, although sometimes they suck!
  • eclipse on badly configured linux workstations sucks, too..
  • everything in the world could be modelled by interfaces ... but doesnt have to be....
  • doing today what you think, you might need next year, and hence imposing privations upon oneselves until next year, just to realise then, that you have to do it a diffrent way due to some fucked up details, well ... this actually does suck, also very badly
  • well, ... and last but not least... using Java for web applications sometimes sucks too: no higher order functions, no continuations, no cool typesystem, apart from some bright highlights: laborious and longnamed language syntax