The long way through Software Craftsmanship

Hello World!

Dec 8, 2014 - 1 minute read - Comments - hello-worldmeta

This is the obligatory “Hello World!” post

To get here and create your own blog using octopress, follow the instructions below:

  • Install ruby, as explained on the guide here
    • I’ve used Ruby 2.1.5p273 (2014-11-13 revision 48405) [x64-mingw32] (ruby --version)
  • Configure your blog. See here
  • Install octopress: rake install
  • Start the server with rake preview. You should see a basic template (CSS) with your blog name, the author, etcetera
  • Create your first post.
rake new_post["Hello World!"]
  • Refresh the browser and see the new post appear
  • Edit the .markdown file in “source\_posts” using a markup editor
  • Execute rake preview to see your first post (this)
  • Execute rake setup_github_pages for every computer you want to publish from
  • Execute rake generate && rake deploy. After a few minutes, you should go to .github.io to find your new blog in there

  • Happy blogging!

Jan 1, 0001 - 2 minute read - Comments


published: false categories:

- draft

curiosities - so early, they talk: * about testing, reproducing cases: ensuring quality * store documentation and update it incrementally (in paper) * store versions of the software: version control system (VCS)

ideas to talk about: * no silver bullet - essence and accident - how to measure performance without control groups? - candidates: - the social coding (not silver bullet, still) - higher-level languages and frameworks (scala, play; python, django; ruby, ruby on rails) - open source packages * brooks’ law * nine women cannot make a baby in one month: the non-parallelizable tasks of a project * chapter #2: the idea of the waiting patrons on the french menu * investing a part of your time to sharpen your tools * * hypothesis: was the book (the mythical man month) a precursor to the agile movement?

others investigate the same: technion

Ideas from paper in [technion]: * not in year ‘75 but maybe ‘85 (approx)

The XP wiki page points to the C3 System: started in ‘93 and Kent Beck joined in ‘96

This other post: http://dhondtsayitsagile.blogspot.com/2010/01/mythical-man-month-by-frederick-brooks.html:

Though I found the book a bit dry and out of date, it was worth a quick read for the simple reason that it holds so many ideas that are so strongly advocated by Agile practices, and others that are not. Consistent with agile–we must use a process that assures us that “one always has, at every stage in the process, a working system. I find that teams can grow much more complex entities in four months than they can build”; “conceptual integrity is the most important consideration in system design”. Communication is critical–and exponentially more difficult with larger and larger teams. He advocates giving developers room to be creative, saying they need room for “invention and craftsmanship” […]

He also believes in “done-done”, in other words–“milestones musbe be concrete, specific, measureable…coding, for counterexample, is ‘90 percent finished’, for half the total coding time. Debugging is ‘99 percent complete’ most of the time…”. Though stand-up meetings weren’t called it at the time, he knew the wastes of “status-review” meetings, and started calling things problem-action meetings instead

XP values: * http://www.extremeprogramming.org/values.html * http://www.softwarereality.com/lifecycle/xp/four_values.jsp

Jan 1, 0001 - 2 minute read - Comments


published: false categories: - clean-code - startup-weekend

- tdd

In an epilogue in Clean Code, Robert C Martin talks about the “commitment to writing the best code I could write”

This is an interesting proposition, as to never “lower the quality bar” induced by constraints such as resouces.

This clicks with an idea that I heard some months ago, during the Startup Weekend, where you have 54 hours to develop a business idea out of the building. For us, software people, this usually means writing some kind of web-based product.

This is a time-constrained environment where it is important to produce some minimum viable product (MVP) at the end of the given time slot. Some people prefer sacrificing quality but I was talking to another developer in there and he said that even in that moment he did TDD, because it is worth it. Left me pleasantly surprised.

It also connects with the idea of throw-away code: in few cases I’ve encountered the situation where the code is only written (once) and never modified. Even in the hackathon scenario, you first produce an MVP and start adding more features. It is the essence of iterative and incremental development.

In a more pragmatic way, this has nothing to do with:

  • TDD, XP, agile or any other methodology
  • any specific language (e.g., java, c#, javascript)
  • your skill level (i.e., master, experienced, medium, beginner)
  • deadlines or other time constraints

It is only a commitment you can opt-in for. It is a commitment for valuing software that works but also well written, in the available timeframe. It is also related to being able to say ‘no’ to clients, as you cannot keep the quality at your desired level.

Other sources - further reading

[Angela Harms][angelaharms] has an article on this: here Jakub HolĂ˝ has an article on this: here

Jan 1, 0001 - 1 minute read - Comments


published: false categories: - sample - unfinished - clojure - algorithm - mathematical-notation - paradigm

- comparison

I’ve been doing some code jam exercises, some on paper, some on the computer and I generally use “pseudo-mathematical” notation: FOREACH, BELONGS, etc

I have realised that this is much simple for algorithm rather than start thinking on data structures and then adding behavior on top of it.

Also, that once the algorithm is outlined into this notation, is relatively straightforward to convert to clojure notation.

Also that (even I already knew it), maps are the most comfortable notation for objects in clojure and that the object representation is quite similar (in lighttable’s format) to JSON. Something to think about.

Some of these algorithms are only data transformations, therefore good candidates for the functional paradigm. When there is shared state (e.g., dynamic programming), maybe it gets out of the usual scope for functional languages.

The three main patterns in recursive algorithms (keep, filter, every) are useful in dealing with algorithms