Dapeng Li

Hungry, foolish and passionate – yet another software developer.

Archive for the ‘Programming’ Category

Some ideas from Full Stack Fest 2016

leave a comment

Early this month I attended a conference called Full Stack Fest in Barcelona, this has been my third consecutive year visiting the city in summer, and I want to write some summary for this conference.

I did a short presentation about the same topic at work, here’s just a memo.

The conference was about software development, and was divided in two parts, the first two days were about Backend (everything that’s not Frontend), and the last two days on Frontend (basically the code runs in your browser).

Personally I don’t see the division of Backend and Frontend as significant, because on writing software we share some of the basic principles, patterns and practices, no matter where the code runs. I see the talks in the conferences as in three groups:

  • On operations: about security, scalability…
  • On development: about languages, specifications, tools…
  • On interesting things: not necessarily technical, but are interesting ideas

I would also like to see the talks from another perspective. In each talk, the speaker presents a problem and addresses how we could solve it. The problems and solutions can be very specific, or general. Talking about solving conflicts in event system between two VR libraries is obvious at a different level than talking about how you are going to access and share data in the future. In this sense, I see the talks in the following levels:

  • About a project: could be a work or personal project
  • About a technical herd: about language, specification, protocols…
  • About a discipline: about computing, software engineering
  • About human kind: about preserving, sharing knowledge, about freedom

In the context of categorizations above, my four topics are:

I won’t go into details of them, in the slides there are some short comments, nothing significant.

I want to share some personal observations over the years on technology and software, from a regular developer’s point of view.

  1. The web keeps getting better: New web standards, language specifications, tools and ways of doing things keep coming and show no sign of slowing down. I am happy and proud to witness this progressive change.
  2. Functional programming is waiting for the killer move: Functional programming has been a topic more and more important, not only because its paradigm works better for parallel computing (our CPUs are not getting faster, but are having more and more cores), but also it offers a way to design and reason your application easier. I can see developers are looking here, but we still miss something to make its name like Rails did for Ruby.
  3. P2P computing could be the future: From BitTorrent, to cryptocurrencies and IPFS. They have really ambitious goals and are showing signs of promise.

So this has been a quick summary. Hope it can be of help.

Written by Dapeng

September 20th, 2016 at 9:22 pm

Posted in Programming

Tagged with

Things I learned from Kent Beck’s TDD screencasts

leave a comment

Recently I watched the screencasts by Kent Beck on Test-Driven Development (TDD).

Being glad to see I had been doing TDD similar to Kent, I learned quite something from the screencasts. Although my notes are just bullet points here and there, neither comprehensive nor introductory, I believe they can be of value to programmers and would like to share with you in this post.

Top-down or bottom-up

When adding tests and features, you can go with the top-down or bottom-up approaches.

  • Top-down: write code calling the non-existent method, create the method stub, implement and make the test pass.
  • Bottom-up: with some kind of implementation, extract part of it as a method and invoke that method. This is refactoring, build something then break it down into pieces.

Isolated tests

Tests should be isolated, means they should be able to run on their own, without affecting others. Kent puts clean-up code after the test methods.

Isolated here is not about dependency injection or faking, which is very important in TDD, but unfortunately Kent’s screencasts didn’t cover it.

Prediction game

Predict if the test will succeed or fail before running it, this way you are more engaged and not just programming by coincidence.

Finer grain tests as scaffolding

When it’s not green (there are failing tests) for a method, it’s OK to write finer grain tests to test the helper methods to be used by that method.

So at some point, you will have multiple tests failing, and you fix the finer grain tests first.

Those smaller tests can be considered scaffolding, if later you decide the helper methods should not be publicly accesible, it’s OK to delete those scaffolding tests.

“Yes” is an expense, “No” is a risk

Kent thinks carefully about whether to write the test for a method.

To quote (paraphrased from his summary in the screencast):

Every test is an expense, short and long term, it needs to pay back in Informational or Emotional Feedback; on the other hand, every test that you don’t write is a risk.

Interestingly, Kent plays a betting game with himself about that. I suggest you watch the screencasts and find it out.

Generalizing TDD

Kent generalizes the approach in TDD, the problem-development-cleanup cycle, to a larger context. He argues that this is not only the way we do TDD with a method (for a couple of minutes), but also how we implement some features (maybe for about 30 minutes, the length of one episode of his screencasts), how we solve a larger problem (for days, weeks, or longer).

I agree with him. Begin with the end in mind, seek short feedback loops, and review, that is how we solve problems. It seems so natural and simple, yet TDD – which applies this approach in a micro level – is so powerful however strange it seems when being first encountered.

Practice, practice, practice

Kent practices TDD on the same problem again and again. It goes like this: write some code, erase it, write in a different order, erase it, until it’s efficient and gives a lot of feedback.

This reminds me of the code kata and Chad Fowler’s book.

I would like to finish with a quote from Kent:

I’m not a great programmer; I’m just a good programmer with great habits.

Kent, thank you for the sharing and ispiration.

Written by Dapeng

January 3rd, 2015 at 6:46 pm

Posted in Programming

Tagged with