Join the fun

I am very open for people to join. Say hello at the list.

I just want to mention that this is my hobby, something i do in my spare time, for fun. I don’t get any money and in fact, running 2 companies, have to carve the time to do this.

As such i want it to stay fun. So i am looking for friendly, constructive, positive contact.

Please read the pages and the code and find something that interests you, possibly from the todo list. Then talk to me what you are planning. Issues can be good to capture topic conversations. The list is good for more general discussion.

Then fork and work on a branch before sending pull request.

If you don’t have an arm, here are instructions to run an emulator (on mac)

I wrote some ideas in the about page, but here some more code related guidelines

• Walk the straight line
Or “No future-proof” means not to design before you code. Not to anticipate, only to do the job that needs doing. Better design should be extracted from working code.
• TDD extreme
Having suffered from broken software (small feature add breaks whole software) so many times, the new tdd wind is not just nice, it is essential. Software size is measured in tests passed, not lines written. Any new feature is only accepted with enough tests, bugs fixed after a failed test is written.
• Use names rightly
Or the principle of least surprise. Programming is so much naming, so if done right will lead to a natural understanding, even of code not read. Good names are Formatter or compile, but unfortunately not everything we have learnt is named well, like Array (should be ordered list), Hash (names implementation not function) or string (should be word, or bytebuffer).
• No Sahara
There has been much misunderstood talk about drying things up. Dry is good, but was never meant for code, but for information (configuration). Trying to dry code completely leads to overly interdependent functions, calling chains that are difficult to understand and serve only a misunderstood slogan.