Skip to main content

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

Comments

Popular posts from this blog

Keys, Values and Rules: Three Important Shake Concepts

The title was a click-bait! This article will actually try to explain five instead of three important notions in Shake.

These are:
RulesKeysValuesThe Build DatabaseActions
This short blog post was inspired by the hurdles with my Shake based build, after the new Shake version was released, which had breaking API changes.

Jump to the next section if you are not interested in the why and how of this blog post.

Shake is rule based build system much like GNU make. Like make it is robust, unlike make, it is pretty fast and supports dynamic build dependencies.

But you knew all that already, if you are the target audience of this post, since this post is about me explaining to myself by explaining to you, how that build tool, I used for years, actually works.

Although I used it for years, I never read the paper or wrapped my head around it more than absolutely necessary to get the job done.

When Shake was updated to version 0.16.x, the internal API for custom rules was removed. Until then I w…

Lazy Evaluation(there be dragons and basement cats)

Lazy Evaluation and "undefined"
I am on the road to being a haskell programmer, and it still is a long way to go. Yesterday I had some nice guys from #haskell explain to me lazy evaluation.

Take a look at this code:

Prelude> let x = undefined in "hello world"
"hello world"
Prelude>

Because of Haskells lazyness, x will not be evaluated because it is not used, hence undefined will not be evaluated and no exception will occur.

The evaluation of "undefined" will result in a runtime exception:

Prelude> undefined
*** Exception: Prelude.undefined
Prelude>


Strictness
Strictness means that the result of a function is undefined, if one of the arguments, the function is applied to, is undefined.
Classical programming languages are strict. The following example in Java will demonstrate this. When the programm is run, it will throw a RuntimeException, although the variable "evilX" is never actually used, strictness requires that all
arguments of a fu…

Erlang mock - erlymock

NOTE THIS POST IS OUTDATED!
The project has evolved and can be found here: ErlyMock


Some features

Easy to use
Design based on easymock
Works together with otp: can be used even if the clut is called from another process, by invoking mock:verify_after_last_call(Mock,optional: timeout)
custom return functions
predefined return functions for returning values, receiving message, throwing exceptions, etc..
erlymock automatically purges all modules that were mocked, after verify()
Custom argument matchers:

%% Orderchecking types: in_order, out_of_order, stub;
%% Answering: {return, ...}|{error, ...}|{throw, ...}|{exit, ...}|{rec_msg, Pid}|{function, Fun(Args) -> RetVal}
expect(Mock, Type, Module, Function, Arguments, Answer = {AT, _}) when AT==return;AT==error;AT==throw;AT==exit;AT==rec_msg;AT==function ->
call(Mock, {expect, Type, Module, Function, length(Arguments), {Arguments, Answer}}).

%% this version of expect is suited for useing custom argument matchers
expect(Mock, Type, Module, Fun, …