Cluj was the seventh CITCON I attended, and it's the second CITCON organized by people who first attended the conference series in Budapest (which I organized :)). But it's not about reunion of old friends, it's a super open and welcoming event, where I still keep learning, so without further ado, here are my learnings from the sessions I've attended.

Monorepos

(It was a lunch session, which I didn't attend, but we've talked about it Friday evening)

Ivan Moore suggested (and has done so in his past project(s)) not to break up your team's repo into different repos, but just have a single one and keep modules separated. Essentially he suggests a single repo per team.

The benefit of this is that you save a lot of time by not having to deal with a bunch of things, especially in the build, packaging and dependency versioning/management area - the compatible versions are always kept together.

It's recommended that you CD the artifacts, but it's actually not a requirement.

We disagreed whether the physical separation of repos is a better tool to teach people proper modularization, Ivan argued that it should be addressed on a team dynamic/process level (reviews, pairing, etc.), and not make delivery (and refactoring) harder. Note on refactoring: in Java, the equivalent of pip install -e <folder|git url> is much less practical than in Python.

Is there a limit to self organization?

It turns out that the team I work with is quite self organizing, but only within the unit of the team. @Jtf suggested to rephrase the question as Is there a limit to self organization or only to how big the self is?.

I also learned that one should be careful with terminology - the question of who owns the solution and who owns the goal is totally orthogonal to how any given team is organizes work.

At @Jtf's company they run something similar to how Valve operates - there is an internal project fair, where PO(s) propose projects, and then developers sign up for them - and it's perfectly OK if a project gets no signups.

To address the divide between who owns the goal and who the solution, properly cross functional teams can be the answer, i.e.: the PO should be part of the team and should really own goals and priorization of the goals.

There was a rather interesting quote from Alistair Cockburn that "Self organization is mutiny", because self organizing will inevitebly be pushing the boundaries.

The technique called Coherence Busting was suggested, which in high level translates to empathy/understanding where people's actions are coming from, i.e.: What has to be true for this behavior to make sense. But if you can, just ask directly :)

Randomized testing/random data generation

On the train ride to Cluj, I was playing around with py.test's test fixtures and how one can combine that, e.g.: in a shopping cart, how can one specify in a test that "I need an order for an electroncics items that is sold to an end user who paid by credit card and who used a fixed amount coupon". I've found that generating all combinations is rather easy, but to filter out the scenarios I need for a given test is hard if I don't want to write a lot of specific fixtures (e.g.: electronics_item_for_end_user_with_creditcard_with_fixed_discount), which could get out of hand fast.

One possibility could be to do some (model driven) code generation to generate all these specific fixtures, but I had the impression it might become unmaintainable/hard to understand quickly.

During the session, I used the analogy that "as if I was writing a SQL query to select the test scenarios I need", which - with the input from the other participants led to the realization that I could separate the generation of scenarios from the selection of scenarios, i.e.: I could generate all possible combinations, serialize the results somewhere before running the tests, and then inside the tests I could just query the generated ones and load them. Certainly something to experiment with further!

Continuous Delivery/Deploymnet side effects

This session was run by PJ, CTO of an online advertising firm, who described their one year journey to CD, and the kind of interesting side effects he has observed.

He has mapped out the full process from idea to profit, and looked where they could speed it up. As a CTO, he started in the domain under his control, i.e.: from commit to released to production, though as it turned out, that's quite a small slice of the full process. Later when he showed the chart to fellow executives, they were surprised by the complexity of the project. Most likely it was the result of organic growth that comes from the human/firm behavior that when one encounters a problem/road block, often the solution to fix it is to add more process to it. Quickly there was buyin to automate a solution to the root causes for which the processes were introduced.

PJ told the engineers to spend the bulk of their coding time refactoring. Which people initially didn't. So he then required that 50% of the time was to be spent on refactoring, as well as 50% of the time should be pair programming. The business did protest initially (this was before the full value map), but the results quickly proved it was worth it. Before this change, it took 12.5 days to from a time the story made it to the implementation backlog to production down to 3.5 days (average), which led to happy stakeholders.

They achieved this by:

• integrating devs, testers, operations, etc. into a mixed teams, now everyone's title is "Software Creator"
• slicing stories smaller
• ship the done story when it's done, and not the end of the two weeks iteration
• to fill out the refactoring time, they've actually reduced the pure build time from 90 minutes to 3 minutes, and the commit to build ready feedback cycle from 2.5 hours (due to pending builds) to just under a cup of coffeee

PJ's observation is that if you give people metrics to strive for, they will game the system to achieve it, so if you give the right targets, great things will happen (note: it's not always easy to get the right targets :))

The refactoring eliminated the fear people had before to change the codebase.

Once they got to the time where it took 3 minutes to deploy, and 1 minute to roll back, the team actually decided to get rid of the slow end to end tests, as they could get faster feedback from production than the time it took to run those tests. However, as an online ad agency, they do have 1000s of events per second (or minutes), so they have enough data. We couldn't pin down an exact formula when exactly one can switch to production monitoring to replace their end to end tests, but the ratio of the time the team needs to go from change idea to deploy in production (i2p, idea to production) and the time the team needs to get feedback whether the change was good once it was deployed (p2f, production to feedback) is a useful one to consider where to invest your time. E.g.: if i2p = 30 mins and p2f is 3 minutes, optimizing i2p could make sense. But if i2p is an hour, and p2f is a day, maybe it doesn't. If anyone knows of some mathematics that could help here, please let me know!

As they dropped their end to end tests tests, unit tests did skyrocket in number too.

Also, just to emphasize, while in retrospect and in this presentation it could sound like smooth sailing, it wasn't, there were many mistakes. But that quickly teaches the team to focus on resiliency and recovery, i.e.: they changed there processes around to reduce the cost of an error (fine-grained feature flags (on off, enable for only some groups, etc.), rolling out to a few servers and then to the whole cluster, etc.).

Apparently New Relic supports a/b testing with monitoring, so one could compare the new release against the old one, so that's something to look into.

How do you test your organization?

Andy Parker is an engineering manager in a self organizing organization, so the question arose: what exactly should a manager do there? His answer is to gather data that could be an additional input into the kaizen (continuous improvement).

When one joins the organization, it helps to map out the company - look at the org chart, as well as how actually work gets done. Who are the key communicators? Who are people actually working with (usually across the hierarchy, even whent he only common manager they have is the CEO). This is easy to do when one is starting out, but should be remembered an actualized even when one is already part of the "daily mill". See also: static vs. dynamic org. situation

Before one starts out collecting organization, one should always start with a hypothesis (as per the scientific method). This can be the null hypothesis, i.e.: there is nothing interesting here, so observing it I'll find that everything is OK and I will just confirm that.

Some tools to do this is

• take notes - raw data when possible, even though you can't be an impartial observer of course
• beware that observation changes things, but that in itself can be valuable information. E.g.: oh, people are pairing there, let's see what they are working on! Hmm, now that I observe them, they stopped pairing and went back to working alone. Why is that?
• (with permission), record conversations and re-listen to them

• in a meeting, draw a communication matrix -

• who talks to whom

• are they making statements or questions?

• how long do they talk?

• interview team members - what is your responsibility in the team? what is others' responsibility? You can find that not everyone has the same understaning

• one, especially developers/engineers, should be careful to start with qualitative analysis, and not quantitative

Elephant Carpaccio

It's a workshop that was originally run by Alistair Cockburn, but Douglas Squirrel has adopted it to fit the one hour session limit.

As we've walked into the room, everyone was required to add a single feature to the drawing of an elephant (which started out as with a circle (head) and 4 lines (body, two legs, and the trump)). Surely we didn't create the masterpiece, but it started to resemble the elephant more and more, and as Squirrel observed, it was looking like an elephant throughout the whole process, it was just getting better/more detailed with each iteration.

His client is working with a simple kanban board that has the following columns: idea, dev working on it, testing, and live. Their goal is (which they meet more often than not) to go from idea to live in a single developer day for a story.

E.g.: their app shows graphs, and they've introduced the color picker to allow users to choose the color of the lines of their graph via the following cards:

• behind a feature toggle, release a UI button for the color picker (to learn whether or not people will actually click on it)
• when clicked, pop up a static image (to learn whether people just close the dialog, or actually click on a color)
• a functional color picker widget, which allows choosing a color, but the selected value is not used anywhere (to do UX testing with real users over the phone)
• actually persist the selected color and display that on the graph (done)

In each step, they've implemented a slice which either provided value or provided fast feedback. One benefit of fast feedback is that you can discover early enough if you are working on a feature noone needs, and can concentrate your efforts elsewhere. As opposed to layered development, where first the data storage is implemented, then the backend is implemented, and finally something is shown to the users. It's important to slice the elephant not parallel to the ground, but vertically along the line from its trump to it tail, so that it keeps looking like an elephant.

Slices work even if you only release them internally or to selected users only.

It's important how you slice - e.g.: one could say we start with a single (or two) color(s) color picker, but that would require us to implement a rather thick slice.

There is a nice flowchart to decide on how to slice stories.

In Squirrel's experience people don't tend to slice too thin, but rather they often slice the wrong way

There can be tension and tradeoff in slicing whether we take the smallest next slice to implement or we take the thing that gets us to market/money fastest. That's why the slicing session happens together with the PO and the devs.

The benefit of this approach is that estimation is eliminated, and delivery becomes more predicatable (each card is one dev day).

Usually they only plan ahead like a week or so, so they can respond to feedback without too much rework.

Context: his client is a startup still getting to the proper product - market fit.

After this overview, we did a slicing/planning session for a price calculator (each drink has a price, and there is vat, which varies from country to country).

The following cards were derived:

• calculate price on command line, in ireland only, for 1 pint of beer with a fixed price and fixed percent tax
• for N beers
• at a variable price (coming from the user)
• move from the command line to a (web) API (assume CD infrastructure is present already)
• and whisky and wine, but calculation can only be done for a single type at a time
• multiple types per calculation
• expand to have the UK prices/taxes too

Summary

CITCON Cluj was a blast, I've learned way more than what I squeezed into this blog post, so many thanks to Adina and the local organizers for finding a great venue and making the event happen!

Hope to see you at a CITCON next year!

Books of CITCON Cluj

These are books that were recommended either during the sessions or conversations around the conf, in no particular order

• The Future Of Management Is Teal
• Why we can't learn anything from Google / Toyota (???)
• Gun, with Occassional Music
• Research methods in anthropolgy - qualitative and quantitative approaches

It's a good practice to gradually deprecate one's library's API, so that users get advance warning of coming changes. The built in way to do so is Python's warnings module

import warnings

if __name__ == '__main__':
    warnings.warn('deprecation', DeprecationWarning)

By default, they are not reported!

However, if I run this code, there is no output.

$ python3.5 demo.py
$ echo $?
0

The documentation on default warning filters explains:

By default, Python installs several warning filters, which can be overridden by the command-line options passed to -W and calls to filterwarnings().

• DeprecationWarning and PendingDeprecationWarning, and ImportWarning are ignored.
• BytesWarning is ignored unless the -b option is given once or twice; in this case this warning is either printed (-b) or turned into an exception (-bb).
• ResourceWarning is ignored unless Python was built in debug mode.

Forcing defaults from the command line makes them reported

However, if we force the default warning behavior from the command line, we get the warnings - even though theoretically we only specified how often the warnings should be reported, not which warnings to be reported!

$ python3.5 -W d demo.py
demo.py:4: DeprecationWarning: deprecation
  warnings.warn('warning', DeprecationWarning)
$ echo $?
0

Before reading the docs, I suspected the operating system maintainers didn't want to 'spam' the end users of their systems with python library warnings while going about their daily tasks, but apparently this is built into python itself.

So how should I deprecate things?

I'm a big fan of executable documentation, but this might be one of those cases where good old fashioned documentation might be more effective, as we can't expect users of our library to run with warnings enabled.

I would still leave in these deprecations for the project's developers as well as for the pedant users of the library.

Checking against deprecations of our dependencies

That's easier, as we own that code. I would run my builds and tests with -W d at the very least, but I would like to try to run with -W error. Except that I don't want to fail the build if one of my dependencies is using deprecated apis, so probably I would just have a custom main.py where I would explicitly set and reset my warning filters. E.g.: updating the above demo code would give me the following:

import warnings
import os

if os.environ.get('TEST', '0') == '1':
    warnings.filterwarnings(module='.*', action='ignore')
    warnings.filterwarnings(module=__name__, action='error')

if __name__ == '__main__':
    warnings.warn('deprecation', DeprecationWarning)

$ TEST=1 python3.5 demo.py
Traceback (most recent call last):
  File "demo.py", line 8, in <module>
    warnings.warn('deprecation', DeprecationWarning)
DeprecationWarning: deprecation
$ echo $?
1

I yet have to test how feasible it is when our library supports multiple versions of a dependent library, e.g.: Django, but my gut feeling is that it should be doable

Beware of the ordering of warning filters

If in the above example we got the order reversed, then our own DeprecationWarnings would be ignored too!

if os.environ.get('TEST', '0') == '1':
    warnings.filterwarnings(module=__name__, action='error')
    warnings.filterwarnings(module='.*', action='ignore')

Kevin Dishman wrote an article titled BDDon't, in which he raises a few objections against issues common with the tools and common practices of them. As recently at the Softwerkskammer Nuremberg user group we've just talked about Gherkin style testing after my polytesting talk, I'm now doubly prompted to blog some thoughts.

Context/Disclaimer

• I've only used behave, so it's entirely possible it has different behavior from the tool implementation(s) Kevin used
• I don't run the behave tests on the selenium level
• I have never worked for an airline, though flew enough times already. But to be consistent with Kevin's examples, I will use this domain to illustrate points
• I don't exclusively use only BDD tests

I agree with Kevin's problem statements

• Regular-expression mapping can become complex and error prone and should be avoided
• Global state and step interdependencies are also error prone and should be avoided

• If the business is really interested in participating in test specification, this would be a great opportunity for them to pair with someone familiar and comfortable with the test suites the team has created.

Despite that, I still like Gherkin tools

It forces separation of test, test glue, and app code

Writing readable tests are hard. While on a team with a great culture and strong discipline this isn't a challenge, on teams that are not yet experts in testing I find this constraint really helpful.

Gherkin docs can be useful beyond dev

As stated above, I've found that motivated stakeholders, BAs, etc. will be fine reading Java, Ruby, Python test code. However, other people can find value from an existing - and filterable/navigable (!) - Gherkin documents, e.g.: tech/customer support people could appreciate living documents. A new support person would need the same info as a new developer making changes in that area! Or imagine if your processes need to be audited - persuading an auditor to read natural text might be easier than getting them to navigate codebases.

Don't have to test things on the full stack level

Even if Gherkin is used for acceptance testing, some algorithms/calculations can be tested on the unit/component level, never even touching the UI to provide the confidence the developers (business) need(s). As time goes on, it's even possible to transition tests up and down the test pyramid (thanks to Stefan Clepce for bringing behave stages to my attention)!

Reduce the pain for Gherkin

Regular-expression mapping - Parameter variance

Different abstraction levels

The problem of complex test data isn't unique to BDD tools - integrated tests written in any tool will face the same problem. And the solutions are similar - in the tests where I care about the concrete values, I specify all the test values explicitly, and in tests where I don't care about those details and operate at a higher level abstraction, I create sample (random) data for that - a'la pytest fixtures

E.g.: instead of

Given I have booked 2 flights

I might say

Given I booked a valid flight
And I booked another valid flight

both these steps can match to the same step implementation - whether via regex, multiple methods calling the same actual implementation, or via some other way. Here I quite like behave's annotations, i.e.: I can say

@given('I booked a valid flight')
@given('I booked another valid flight')
def booked_a_valid_flight(context):
    ....

Or I might even test things in isolation, not even sharing step implementations - I might test that the OLTP model gets translated to the correct reporting model, and for the report I only test things on the report data model (see step tables below).

Relying on the application's own defaults

I have never booked a flight for an unaccompanied minor. Until reading Kevin's article, it hasn't even occurred to me that is a use case to consider, yet I've booked quite a number of flights.

I'm sure there is an option to specify that. However, that option by default is not check in the application for the checkout - the customer explicitly has to request it to be able to specify such a scenario.

Thus for such a scenario, I likely would include an explicit step for booking with an unaccompanied minor.

Using step tables (beware, this is defaults in disguise!)

Behave supports step table data

Given I have booked a flight
   | type                     | return |
   | with unaccompanied minor | true   |

technically, the above would need a header, but in the step implementation, the header could be treated as the first row, if that aids readability.

This can cause more complex test code, but if each step corresponds to an actual action in the application (a'la Page Object), then there should be no extra logic in the step handler - each line here corresponds to a form input (or HTTP POST) entry.

Global state

In behave, each step implementation method receives a Context object to store its state (changes) in,

This object is a place to store information related to the tests you're running. You may add arbitrary attributes to it of whatever value you need.

During the running of your tests the object will have additional layers of namespace added and removed automatically. There is a "root" namespace and additional namespaces for features and scenarios.

This is unlike it is implemented e.g.: in cucumber-jvm, and maybe that's why I haven't run into this issue (though external global state, such as a database can still be shared).

As per Wikipedia, a blueprint is something that allowed rapid and accurate reproduction of documents. I have heard it used (and used myself) for processes too.

They are powerful because they allow me or anyone else to recreate someone else's tried and tested idea, which in turn allows the idea to spread (scale) to unimaginable numbers and reach places (and provide benefits to) the original inventor could have never dreamed of.

It allows a complete novice to the field to organize a successful event. Think of it like a franchise. You yourself do put in the work, and your success benefits the franchise as well as yourself. However, you don't have to start from scratch; you have a process you follow, that has been proven to work. When advertising your event, there is the social proof that the brand exists that makes it easier to sell it.

Examples

Some such blueprints I've come across and worked with are

• the CITCON meta wiki about organizing the open space conference - and CITCON Budapest was quite a success, which I couldn't have pulled off without having the process to follow
• Coderetreats - I've participated and facilitated in public & firm-internal events. The educational sessions and the superb detailed documentation the coderetreat community provides make it almost too easy to run such an event - no surprise that in 2015 there were at least 158 events on a single day!
• Django Girls - it started in June 2014 in Berlin, and by now it already took place on all continents - simply because they have a wonderfully detailed tutorial on how to organize such an event!
• the Elephant Carpaccio also has a super detailed facilitation guide

... but I'm sure there are many more out there.

Benefits

If you are trying to bring change in your company/team, but you haven't done it before, you don't have to necessarily invent workshops yourself (of course, if you want, you can), but can simply take off established ones "from the shelf".

Caution: while you could theoretically run an event just from the tutorials, it might be beneficial to have attended such a workshop before running it. I've cooked my first paella from a cookbook, without ever having eaten one before. While everyone agreed I've cooked something delicious, later we had to acknowledge it had little to do with a real paella :)

If you are already organizing something

If you can afford it, I highly suggest you publicly document it (and license it openly), so others have a chance to do the same. E.g.: many user groups struggle finding speakers or sponsors - it would be great to have a handbook on your sponsor/speaker attraction tactics. It won't take away from the success of your event or the benefits to your reputation, you simply just enable more people elsewhere to do the same!

Due to our last minute advertising, the participants were Ruby heavy, but still, the eight people coded in Ruby, Python, C#, Haskell, JavaScript, and R throughout the day - quite a feat if you consider that two attendees were not professional programmers!

Due to a late start and time constraint we only had 5 sessions with the following constraints:

1. no extra constraints, just exploring pairing, TDD, 4 rules of simple design, and the game of life
2. evil ping pong pairing
3. void methods only + remote pairing with Nuremberg (Germany)
4. maximum 3 lines per method
5. no conditionals (later restricted to no booleans)

Remote pairing with Nuremberg

As I've known Marco from before, a few days before the GDCR we had a video call where we tested out the feasibility of remote pairing (we've tried tmate.io and FlooBits), and deemed it feasible for a coderetreat (i.e.: can be set up during the lunchbreak).

Aside: Planning is everything, but no plan survives first contact with the enemy. All pairs used TeamViewer and VisualStudio in the end.

We used the lunchbreak to pair people up using a direct videocall between me and Marco, but that is a cumbersome process and we'll try to come up with a better one for next time (maybe use a Google spreadsheet where each location can put down the interested parties' language, tooling and communication preferences before?), but nonetheless all remote pairs reported having had fun!

Facilitating remote pairs is surprisingly easy, but only when the pairs use the headphones which can be shared between two people - one bud in each person's ear.

While it does require some prior coordination between the hosts (sync session start times, agree on the same constraint for the session, etc.), I do suggest you try it out if you have the chance, especially if you haven't remote paired before!

Note it's a long list - but I don't hesitate to skip/delete an episode based on its description or its first few minutes (caveat: some casts by their structure are less exciting in the first few minutes).

I've grouped the list, but of course there are many of them that would fit multiple categories - no taxonomy ever is perfect.

Hope you find something you'll like!

Software Development

• .NET Rocks was one of the first podcasts I've listened to. As the name suggests, it's focused on the Microsoft development space, but the hosts are critical enough when needed, and many episodes are tech agnostic. Disclaimer: I'm a happy owner of a .NET Rocks mug
• The Tablet Show - the sister show to .NET Rocks, with focus on mobile and tablets. The Microsoft focus doesn't come through that heavily (though it's there)
• DevOps Cafe - there are some great interviews on here, though the format (sound quality?) took me some getting used to. It exposes me to topics I'm a total n00b about, whether its security or networking.

• Hanselminutes - Scott started this with the tagline "the podcast that doesn't waste your time". The episodes are limited to around half an hour, and while the topics stay around tech, they also touch on the social/human side, such as

  • Scott interviewing his wife about how it is to live with a geek
  • interviews with developers from publicly underrepresented developer groups (women, world class climbers, you name it :)

• Ruby Rogues - a panel discussion about things Ruby related, but many of the discussions are applicable to other programming languages, or at the very least inspire one to learn how the thing discussed works in the listener's language. Add on top of this they bring up cultural topics that should be discussed in the software development community.

• The Java Posse - it used to be a mix of panel discussion of java/scala programmers, and recordings of sessions from the yearly open spaces conferences of the same name, but lately it's just the conference stuff. So great for learning, but I miss the chat shows.
• The Ship Show - build and release engineering, devops, and everything else in between. Panel discussions, news and views, listener questions, as well as interviews. It definitely fills a niche.
• ThinkRelevance/CogniCast - anything and everything related to Clojure or Datomic, produced professionally by the company where Rich Hickey works. Sometimes it's too Clojure heavy for me (though you might find that a good thing), but it has blown my mind a few times.

(Pop-)Science

• A Brief History of Mathematics - a former BBC Radio4 programme archived in podcast form. Short episodes on the various influential people in mathematics. I'm planning to re-listen to this series soon.
• More or Less - Statistical CSI :) Produced by (among others) Tim Harford, this show takes a look at public statistical claims from any aspect of life, and go after digging up sources for these claims as well as verifying them and the methodology used. Listener topic suggestions are encouraged!
• NPR Planet Money - Awesome economics podcast, with short and entertaining episodes. They have provided the best economics coverage of the EU debt crisis for laymen like me.

Social, Politics

• Analysis - another BBC Radio 4 programme. Each episode presents one person's research and conclusion/opinion of a given topic. Expect lot of source interviews.
• Four Thought - personal speeches about personal experiences, delivered to a live audience, followed by a few questions and answers. It keeps reminding me how little I know about the world and people.
• Moral Maze - a panel hearing out witnesses on moral questions, arguing with the witnesses and with themselves, exploring different these difficult topics, which usually don't have clearcut answers. Great topics, great points, and some heated debate.
• Intelligence Squared - recording of live, superbly moderated debates, published as podcasts. The structure (uninterrupted opening statements, Q & A, uninterrupted closing statements, voting) is wonderful, and the moderator is on top of his game. The topics are timely and interesting, the debaters are amazingly authentic, and the voting results do show that people can change their minds.
• On Being with Krista Tippett - exploring open and tolerant faith. Whether by interviewing atheists, the translator of the Dalai Lama, a marine biologist, civil right movement participants, or marketing guru Seth Godin. Superb audio quality and Krista does have a voice which in itself makes it worth listening to any episode - not to mention the positive thinking that radiates from the talks.
• Thinking Allowed - short BBC Radio4 programme reporting on recent papers or books in the field of sociology on various subjects.

Outdoors

• The Outdoors Station - an irregular podcast. I tend to skip the product episodes, and prefer the interview ones. While irregular, the archive does hold quite a few gems - if you are into outdoor stories.

Business, chatting

• Startups for the Rest Of Us - if you ever wanted to understand how small software business owners and marketers think, and need an occasional reminder that we as software people are there to deliver solutions, not to write software, it's a great one. On top of this, there is a bunch of practical advice if you are trying yourself out in internet marketing. And you can follow Mike and Rob as they develop their respective businesses
• techzing - while lately it has become more of a weekly recorded talk of two friends, which presents new listeners with a steep learning curve during the first few episodes, in the past they had wonderful interviews - and even now their hobbies are exciting and inspiring enough to listen to (have you ever considered coaching your children's school's math team? They actually do that).

Career

• Career tools, Manager Tools - I would say this is mandatory listening to anyone who wants to make progress in an enterprise environment. Especially if you want to become an executive. Their advice is quite prescriptive (they are ex-military after all), but they present their reasoning in (sometimes too) much detail.
• Kalzumeus Software - the once-in-a-rare-while podcast of Patrick McKenzie (a.k.a.: patio11). There is everything from living in Japan to superb advice to furthering your career, especially if you are a freelancer. Since there aren't too many episodes, you can go back and listen to all of them!

Reference

These casts I don't regularly listen to anymore, but have them bookmarked in case I would want to dive deeper in the topics they address, for the episodes I've listened to convinced me of its quality.

• Being the Worst - for event sourcing and Domain Driven Design
• Marketing for Founders - Feels like marketing 10x-20x lectures. Not super exciting to listen to if you don't do this, but probably superb to pick up the basic ideas fast.

And the Best Podcasts Theme Music Award Goes To...

Hard to tell. Obviously, the Cognicast has the advantage that guests choose their own intro and exit music... So I have to disqualify it :) From the rest, I can narrow it down to the Ruby Rogues and The Ship Show, but not any further...

I just got around to listening to The Ship Show #37, and one of the topics they've discussed (47:00-48:00, 49:30-50:00) was adding new quality checks to the build. Or to be more precise, they've discussed talked about a case which exhibits the anti-pattern way of adding new checks to the build, namely:

1. Find a new quality check (e.g.: let's not have compiler warnings)
2. Get team buy in
3. Modify the build to fail on these violations
4. Have a broken build for the coming months - and have developers ignore real build failures (ah, it's broken only due to the new checks!)
5. Abandon this new quality check so that a failed build actually means the build is actually broken

One way to avoid the above scenario is to focus on gradual improvement, i.e.: after steps #1 and #2 (which shouldn't be skipped!), in step #3, instead of a zero-tolerance policy, you set the limit for the new check violations at the current level - i.e.: the team commits to not making the situation any worse, and trying to improve it. Exceeding this limit will make the build fail, and thus there are no more false alarms - all build failures have to be taken seriously.

If your monitoring/build tool doesn't support "continuously decreasing limits" out of the box, you'll have to adjust this limit manually, let's say every morning. Be careful to only ever lower the limit though!

And there are other things you should be monitoring about your build too!

Note that all of this was written at the time of Elixir 0.12.5-dev, so things might have changed since.

Since the tutorial covers the mechanics pretty well, this post is more about my impressions of Elixir's approach to this topic.

$ mix new myproject
...
Your mix project was created successfully.
You can use mix to compile it, test it, and more:

    cd myproject
    mix compile
    mix test

Run `mix help` for more information.

defmodule FooTest do
  use ExUnit.Case

  test "the truth" do
    assert(true)
  end
end

    test "survival - a living cell with 2 or 3 neighbours survives" do
        assert Gofl.Rules.next_state(:alive, 2) == :alive
        assert Gofl.Rules.next_state(:alive, 3) == :alive
        assert Gofl.Rules.next_state(:dead, 3) == :alive
        assert Gofl.Rules.next_state(:dead, 2) == :dead
    end

  1) test survival - a living cell with 2 or 3 neighbours survives (GoflRulesTest)
     ** (ExUnit.ExpectationError)
                  expected: :alive
       to be equal to (==): :dead
     at unit_testing_with_elixir_gofl.exs:18



Finished in 0.05 seconds (0.04s on load, 0.01s on tests)
1 tests, 1 failures

    def test_survival_a_living_cell_with_2_or_3_neighbours_survives(self):
        self.assertEquals(ALIVE, cell_next_state(curr_state=ALIVE, live_neighbour_cnt=2))
        self.assertEquals(ALIVE, cell_next_state(curr_state=ALIVE, live_neighbour_cnt=3))
        self.assertEquals(ALIVE, cell_next_state(curr_state=DEAD, live_neighbour_cnt=3))
        self.assertEquals(DEAD, cell_next_state(curr_state=DEAD, live_neighbour_cnt=2))

F
======================================================================
FAIL: test_survival_a_living_cell_with_2_or_3_neighbours_survives (__main__.GoflRulesTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "unit_testing_with_elixir_gofl.py", line 22, in test_survival_a_living_cell_with_2_or_3_neighbours_survives
    self.assertEquals(DEAD, cell_next_state(curr_state=DEAD, live_neighbour_cnt=2))
AssertionError: False != True

----------------------------------------------------------------------
Ran 1 test in 0.000s

FAILED (failures=1)

defmodule GoflRulesTest do
    use ExUnit.Case, async: true

Prior posts in this series:

• A New Look At End-to-End Testing - Polymorphic and Fast
• Going Beyond Regression - What Other Benefits could End-to-End Testing Provide?

Abstract concepts are always easier to learn with concrete examples. This is the first code-heavy post in the series, and it is intended to illustrate the mechanics of the concept, not yet how it is applied to the problem domain. For this reason, I use the example of Fibonacci Numbers, with a naive implementation - the business logic is not the emphasis here, but how we test them on multiple levels.

I chose Django to write the code, in because of its lovely built in end-to-end testing support, but knowing that not everyone is a Django developer (yet!), I chose not to use any of the more idiomatic Django class based views, since the purpose of this post is not to teach idiomatic Django.

Enough of the disclaimers, on to the code!

class FibonacciCalculatorTests:

    def test_cannot_calculate_sequence_elements_less_than_one(self):
        self.assert_cannot_calculate(n=-1)
        self.assert_cannot_calculate(n=0)
        self.assert_can_calculate(1)

    def test_currently_we_cannot_calculate_numbers_greater_than_10(self):
        self.assert_can_calculate(10)
        self.assert_cannot_calculate(11)
        self.assert_cannot_calculate(7895)

    def test_can_calculate_the_first_ten_fibonacci_numbers(self):
        self.assertEquals(1, self.get_fibonacci(1))
        self.assertEquals(1, self.get_fibonacci(2))
        self.assertEquals(2, self.get_fibonacci(3))
        self.assertEquals(3, self.get_fibonacci(4))
        self.assertEquals(5, self.get_fibonacci(5))
        self.assertEquals(8, self.get_fibonacci(6))
        self.assertEquals(13, self.get_fibonacci(7))
        self.assertEquals(21, self.get_fibonacci(8))
        self.assertEquals(34, self.get_fibonacci(9))
        self.assertEquals(55, self.get_fibonacci(10))

    def test_can_only_calculate_fibonacci_for_integers(self):
        self.assert_cannot_calculate(3.14)
        self.assert_cannot_calculate('not a number')
        self.assert_cannot_calculate(None)

    def assert_can_calculate(self, n):
        result = self.get_fibonacci(n)
        self.assertIsNotNone(result)

from django.test import TestCase
from simple_fibonacci import calculator, urls


class InMemory(FibonacciCalculatorTests, TestCase):

    def assert_cannot_calculate(self, n):
        with self.assertRaises(ValueError):
            self.get_fibonacci(n)

    def get_fibonacci(self, n):
        return calculator.fibonacci(n)

def fibonacci(n):
    # don't do this in production
    # use https://en.wikipedia.org/wiki/Fibonacci_number#Closed-form_expression
    if n < 1:
        raise ValueError('value (%r) too low' % n)
    if n > 10:
        raise ValueError('value (%r) too high' % n)
    if n in (1, 2):
        return 1
    return fibonacci(n - 1) + fibonacci(n - 2)

import simple_fibonacci
from django.test.client import Client
from django.core.urlresolvers import reverse
import json


class JsonHttpResponse(FibonacciCalculatorTests, TestCase):

    urls = simple_fibonacci.urls

    def assert_cannot_calculate(self, n):
        data = self.get_fibonacci_parsed_json_response(n)
        self.assertFalse('result' in data, data)
        self.assertEquals('ERROR', data['status'])

    def get_fibonacci(self, n):
        data = self.get_fibonacci_parsed_json_response(n)
        self.assertFalse('error' in data, data)
        self.assertEquals('OK', data['status'], data)
        return data['result']

    def get_fibonacci_parsed_json_response(self, n):
        client = Client()
        url = reverse('fibonacci')
        response = client.post(url, {'n': n}, HTTP_ACCEPT='application/json')
        data = json.loads(response.content)
        allowed_keys = set(['status', 'n', 'error', 'result'])
        data_keys = set(data.keys())
        self.assertEquals(set([]), data_keys - allowed_keys)
        self.assertEquals(unicode(n), data['n'])
        return data

from django.views.generic import View
import json
from django.http import HttpResponse
from simple_fibonacci import calculator


class FibonacciView(View):

    def post(self, request):
        n = request.POST['n']
        error = None
        result = None
        try:
            result = calculator.fibonacci(int(n))
        except ValueError as e:
            error = unicode(e)
        content, content_type = \
            self.get_response_content_and_type_function(request)(
                n, error, result
            )
        return self.to_response(content, content_type)

    def get_response_content_and_type_function(self, request):
        return self.json_response

    def json_response(self, n, error, result):
        response_data = {'n': n}
        if error is not None:
            response_data['status'] = 'ERROR'
        else:
            response_data['status'] = 'OK'
            response_data['result'] = result
        return (json.dumps(response_data), 'application/json')

    def to_response(self, content, content_type):
        response = HttpResponse(content)
        response['Content-Type'] = content_type
        return response

import re


class HtmlUserFriendlyHttpResponse(FibonacciCalculatorTests, TestCase):

    urls = urls

    def assert_cannot_calculate(self, n):
        response = self.get_fibonacci_response(n)
        self.assertContains(response=response, text='<p class="error">')
        self.assertNotContains(response=response, text='<p class="success">')

    def get_fibonacci(self, n):
        response = self.get_fibonacci_response(n)
        self.assertContains(response=response, text='<p class="success">')
        self.assertNotContains(response=response, text='<p class="error">')
        return int(
            re.search(
                r'<span id="result">(\d+)</span>', response.content
            ) .groups()[0])

    def get_fibonacci_response(self, n):
        client = Client()
        url = reverse('fibonacci')
        client.get(url, HTTP_ACCEPT='text/html')  # as the user, we first load the page
        post_response = client.post(
            url, {'n': n}, HTTP_ACCEPT='text/html')
        self.assertEquals('text/html', post_response['Content-Type'])
        return post_response

from django.views.generic import View
import json
from django.http import HttpResponse
from simple_fibonacci import calculator


class FibonacciView(View):

    def post(self, request):
        n = request.POST['n']
        error = None
        result = None
        try:
            result = calculator.fibonacci(int(n))
        except ValueError as e:
            error = unicode(e)
        content, content_type = \
            self.get_response_content_and_type_function(request)(
                n, error, result
            )
        return self.to_response(content, content_type)

    def get_response_content_and_type_function(self, request):
        return self.json_response

    def json_response(self, n, error, result):
        response_data = {'n': n}
        if error is not None:
            response_data['status'] = 'ERROR'
        else:
            response_data['status'] = 'OK'
            response_data['result'] = result
        return (json.dumps(response_data), 'application/json')

    def to_response(self, content, content_type):
        response = HttpResponse(content)
        response['Content-Type'] = content_type
        return response

I was struggling to understand the differences between anonymous and named functions in Elixir - only to eventually realize that a lot of it is due to the incorrect mental model I had about method overloading from before.

As the saying goes, "for every hard problem, there is a logical, yet completely wrong explanation".

public class MethodOverloadingArity {

    public static String join(String a, String b) {
        return join(a, b, " ");
    }

    public static String join(String a, String b, String sep) {
        return String.format("%s%s%s", a, sep, b);
    }
}

defmodule MethodOverloadingArity do

    def join(a, b) do
        join(a, b, " ")
    end

    def join(a, b, sep) do
        a <> sep <> b  # string concatenation
    end

end

foo = MethodOverloadingArity.join
foo.("a", "b")
foo.("a", "b", " - ")

** (UndefinedFunctionError) undefined function: MethodOverloadingArity.join/0
    MethodOverloadingArity.join()
    MethodOverloadingArity.exs:13: (file)
    (elixir) src/elixir_lexical.erl:17: :elixir_lexical.run/2
    (elixir) lib/code.ex:301: Code.require_file/2

import java.lang.reflect.Method;
import java.lang.IllegalArgumentException;

public class MethodOverloadingMain {

    public static void main(String[] args) throws Exception {
        Class<?> c = Class.forName("MethodOverloadingArity");
        Method[] declaredMethods = c.getDeclaredMethods();
        for(Method method : declaredMethods) {
            if (method.getName() != "join")
                continue;
            System.out.println(method.toString());
            try {
                Object result = method.invoke(c, "first", "second");
                System.out.format("... invocation result (2 args): %s\n", result);
            } catch(IllegalArgumentException e) {
                System.out.format("... (2 args) %s\n", e);
            }
            try {
                Object result = method.invoke(c, "first", "second", " - ");
                System.out.format("... invocation result (3 args): %s\n", result);
            } catch(IllegalArgumentException e) {
                System.out.format("... (3 args) %s\n", e);
            }
        }
    }
}

public static java.lang.String MethodOverloadingArity.join(java.lang.String,java.lang.String)
... invocation result (2 args): first second
... (3 args) java.lang.IllegalArgumentException: wrong number of arguments
public static java.lang.String MethodOverloadingArity.join(java.lang.String,java.lang.String,java.lang.String)
... (2 args) java.lang.IllegalArgumentException: wrong number of arguments
... invocation result (3 args): first - second