Hi, folks. I’m in the market for a hand-me-down app. Specifically:
- Open-source or public domain
- Smallish, but real. Not just a “hello world” app.
- Does something that most people would understand without a ton of domain-specific background.
- Built with Ruby on Rails 3 or later
- Working (if there are bugs that’s OK)
- Doesn’t have to have tests
- If the code is a mess that’s fine. If it’s embarrassing, that’s fine. You can donate anonymously if you wish ;-)
Basically I’m looking for your first Rails app, or maybe that hackathon project that you launched and then lost interest.
Greg Wilson writes:
This painstaking study is the latest in a long line to find that test-driven development (TDD) has little or no impact on development time or code quality. Here, the authors repeated an earlier study with a couple of new wrinkles, and then blinded their data before giving it to someone else to analyze to remove any possibility of bias. The result: no significant difference between TDD and iterative test-last (ITL) development.
I think it’s really important to pay attention to studies like this. Which is why I’m so glad that Greg is out there drawing attention to empirical science being done on software engineering.
It’s also important to keep in mind that science is always limited by the questions being asked. In this case, my eye was drawn to the experimental design:
The baseline experiment utilized a single experimental object: the Bowling Scorekeeper (BSK) kata. The task required to participants to implement an API for calculating the score of a player in a bowling game. The development of a GUI was not required. The task was divided into 13 user stories of incremental difficulty, each building on the results of the previous one. An example, in terms of input and expected output, accompanied the description of each user story. An Eclipse project, containing a stub of the expected API signature (51 Java SLOC); also an example JUnit test (9 Java SLOC) was provided together with the task description.
A commenter on Greg’s blog already noted that this is an exceptionally tiny example coding problem, and questioned whether results on such a small, easy-to-conceptualize program scale meaningfully to real-world software projects. I think that’s a valid criticism.
But I’m more interested in just how well-defined the problem is.
For me, perhaps the greatest value in practicing Test-Driven Development has always been getting over the blank-page brain-freeze towards the beginning of writing a software component. And how, at the same time, TDD forces me to tightly define the problem before addressing it. My TDD process has always been dominated by these questions:
- Am I done yet?
- …well, do the tests pass?
- …and if they do, do the tests describe a completed solution?
This discipline has done more than any other I’ve tried to keep me focused, to help me whittle down the problem statement to specific essentials, and to avoid superfluous tangents.
In the experimental design quoted above, most of that mental work has already been done.
I also quipped on Twitter:
I'm still waiting for the TDD study that measures developer anxiety https://t.co/qNFKPRW31u
— Avdi Grimm (@avdi) October 6, 2016
…which may seem flippant, but I’m actually kinda serious about it. Research, understandably, tends to focus on questions that are easier to ask. But a lot of the most important questions (in my opinion) that need to be asked about software today have to do with difficult-to-measure externalities. Technical debt is one such tough-to-measure externality. But even more difficult, and more vital, to ask are questions like: how much of our developers’ happiness, wellbeing, and calm are we burning to achieve these easily-measured productivity/quality results? What state are we leaving developers in for their next project?
I’m glad research like the study cited above is happening. We need to be mindful of it. But we also need to be aware of the questions that aren’t being asked.
On RubyTapas, I occasionally need to demonstrate web application code. I often use little Sinatra apps for this purpose, because it allows me to illustrate a web app programming concept with all the usual features like routing, sessions, and templates without switching between lots of different files.
When I do this, I also like the demo web pages to look modern and attractive. For some reason, default browser HTML styling still looks terrible, so this means turning to a CSS framework.
Recently, as I was prepping another demo app, I reviewed several “micro CSS frameworks” for this purpose. Then I asked around for suggestions, and took a look over the recommendations I received as well.
Here are some notes. Keep in mind, these are in the context of a very specific and not terribly common use case: an aid to demonstrating web programming techniques. This is not an evaluation of these frameworks from the POV of production use.
This is also from the perspective of a developer, not a designer.
Skeleton: One of the oldest frameworks I’m aware of. Styles are a bit on the “delicate” side, not quite what I look for in a demo. More importantly, it’s a little too minimal. As far as I can tell there are no styles for form field errors or notifications.
Cutestrap: Quite nice looking. I started using this for my last demo app, but then realized that it too was a little more minimal than I was looking for. Like Skeleton, it lacked form error indicators or styles for notifications.
Spectre.css: I was initially pretty enthused about this one. It’s “batteries included”, with rich form styling, “toast”-style notifications, menus, and much more. I like this one because I know I could drop it into any demo app and have styles for any user interaction I might conceivably need to show.
What I don’t like about Spectre is that it requires the kind of markup verbosity I associate with Bootrstrap. For instance, a button might be marked up like so:
<button class="btn btn-primary btn-lg">Button</button>
Paraphrased: “here’s a button which is a button it’s also a primary button and also a large button“.
This kind of repetition is fine in large apps where the HTML is mostly generated, but in an exhibition it slows down typing and distracts from the purpose of the demo.
Bass.css: Billed as a “low-level” CSS toolkit. Looks to be of more interest to designers, with control over a lot of fiddly tweaks I don’t care about.
Kube: This looks pretty feature-complete, although I had to dig into the (copious) docs to realize this. The markup is pretty sane:
<button class="button primary big">Button</button>
Pure.css: This one also potentially falls into the “too much” category. In features, that is; it’s quite svelte in terms of download size. And if you don’t need all of it, you can cut down the size even more by selecting modules individually. Thankfully there’s a default single-file download that includes the whole ball of wax.
The website and particularly the layout examples are gorgeous. This CSS framework seems extremely flexible and powerful.
Also, the examples of form styling are delightfully free of framework-imposed boilerplate DIVs. E.g.:
<form class="pure-form pure-form-stacked">
<legend>A Stacked Form</legend>
<input id="email" type="email" placeholder="Email">
<input id="password" type="password" placeholder="Password">
<label for="remember" class="pure-checkbox">
<input id="remember" type="checkbox"> Remember me
<button type="submit" class="pure-button pure-button-primary">Sign in</button>
Bulma: Batteries-included, lovely to look at, comes all in one file. Also uses some quite understandable composable CSS styles:
<button class="button is-primary is-large">Button</button>
One thing that’s particularly notable about Bulma is that it is the Flexbox-based grid system that seems to make columns and tiles particularly easy to lay out.
The one drawback I’ve seen is that the examples of form styling seem to contain a lot of framework boilerplate:
<input class="input" type="text" placeholder="Text input">
<p class="control has-icon has-icon-right">
<input class="input is-success" type="text" placeholder="Text input" value="bulma">
<i class="fa fa-check"></i>
<span class="help is-success">This username is available</span>
<p class="control has-icon has-icon-right">
<input class="input is-danger" type="text" placeholder="Email input" value="hello@">
<i class="fa fa-warning"></i>
<span class="help is-danger">This email is invalid</span>
<textarea class="textarea" placeholder="Textarea"></textarea>
<input type="radio" name="question">
<input type="radio" name="question">
<button class="button is-primary">Submit</button>
<button class="button is-link">Cancel</button>
These are the mini/micro-frameworks I’ve run across. Are there others I should look at?