2018-04-11 14:33:32 +02:00
|
|
|
|
= render "pages/project/menu"
|
|
|
|
|
|
|
|
|
|
|
|
%h1= title "Join the fun"
|
|
|
|
|
|
|
2018-04-10 18:50:07 +02:00
|
|
|
|
%p
|
|
|
|
|
|
I am very open for people to join. Say hello at the
|
|
|
|
|
|
= succeed "." do
|
|
|
|
|
|
%a{:href => "https://groups.google.com/forum/#!forum/ruby-x"} list
|
|
|
|
|
|
%p
|
|
|
|
|
|
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.
|
|
|
|
|
|
%p As such i want it to stay fun. So i am looking for friendly, constructive, positive contact.
|
|
|
|
|
|
%p
|
|
|
|
|
|
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.
|
|
|
|
|
|
%p Then fork and work on a branch before sending pull request.
|
|
|
|
|
|
%p
|
|
|
|
|
|
If you don’t have an arm, here are instructions to run an
|
|
|
|
|
|
%a{:href => "/qemu.html"} emulator
|
|
|
|
|
|
(on mac)
|
|
|
|
|
|
%p I wrote some ideas in the about page, but here some more code related guidelines
|
|
|
|
|
|
%ul
|
2018-04-11 14:33:32 +02:00
|
|
|
|
%li Walk the straight line
|
|
|
|
|
|
Or “No futureproof” 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.
|
|
|
|
|
|
%li 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.
|
|
|
|
|
|
%li 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).
|
|
|
|
|
|
%li 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.
|
