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
Labels:

Comments

Post a Comment

Popular posts from this blog

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 argu
Post a Comment
Read more

Learning Haskell, functional music

As you might have realized, I started to learn Haskell. One of the most fun things to do in any programming language is creating some kind of audible side effects with a program. Already back in the days when I started programming, I always played around with audio when toying around with a new language. I have found a wonderful set of lecture slides about haskell and multimedia programming, called school of expression. Inspired by the slides about functional music I implemented a little song. Ahh ... and yes it is intended to sound slightly strange . I used the synthesis toolkit to transform the music to real noise, simply by piping skini message to std-out. I used this command line to achieve the results audible in the table: sven@hhi1214a:~/Mukke$ ghc -o test1 test1.hs && ./test1 | stk-demo Plucked -n 16 -or -ip Sound samples: Plucked play Clarinet play Whistle(attention very crazy!) play As always the source... stueck = anfang :+: mitte :+: ende anfang = groovy :+: (Trans
2 comments
Read more

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,
2 comments
Read more