What are our responsibilities? When can we say no & how do we do it? When are we obligated to say yes? How do we get

better at what we do?

appreciated to hear "tales from the trenches", the book does have a fairly heavy-handed "do as I say" tone. Don't do

TDD? Well then you're not a professional. Do you create ambitious estimates? Well then, you're not a professional.

From a rhetorical point of view, the book does rely on this "proof by appeal to professionalism" approach, rather than

In the early days they were serious attempts at critique and understanding. Nowadays, however, they are just rants.

"QED". Hardly a conclusive argument in favour of TDD, and the off-hand dismissal of any critiques of the practice

really does hurt the point he's making.

to developers to be better. If you put aside the "if you don't do this you're not professional" rhetoric, at its core

this book is a call for developers to live up to the responsibility of the job they have been hired to do. Oftentimes

we as developers like to silo ourselves off, focus on our narrowly defined technical tasks, and that is simply

Java Puzzlers is not so much a book, but a collection of obscure corner cases in the Java programming language. The

author (Joshua Bloch) is well known as the author of [Effective Java](http://www.amazon.ca/Effective-Java-2nd-Edition-Programming-ebook/dp/B000WJOUPA/ref=pd_sim_kinc_2)

Each chapter of the book features a collection of "puzzlers" centered around a particular section of the language

(examples include loops, strings, exceptions, classes, etc). Each "puzzler" is formulated where a puzzle (typically in

This book frustrated me. I once had the fortune of seeing Sandro give a talk at the Software Craftsmanship North America

had been released it was an "instant buy" for me.

Ultimately though I was incredibly disappointed by this book.

I wanted to like this book. Rather I wanted to love this book. And honestly, much of what Sandro espouses in this book

the thing is when you make empirical claims (ie - if you do TDD you will reduce bugs and therefore reduce costs, or if

you pair with other developers you will create a culture of learning which will improve productivity, or if you hire

craftsmen your company will be better off), you need to back that up with empirical evidence, not just "I had this job

audience who's only vaguely familiar with the craftsmanship movement, and other parts feel like unless you've been

writing code for decades you'll have trouble relating.

movement. The thing is though there's nothing you won't get from simply reading the blogs or books of some of the people

in the craftsmanship community. If you've read Clean Coder by Bob Martin, there's no reason to read this book.

tags: shell

cover: static/imgs/default_page_imagev2.jpg

Provides a basic REPL that checks your shell scripts for common issues.  Kinda neat, and admittedly I learned a thing or

two while playing with it.

space such as Vagrant, Terraform, Vault, and others.

The talk started with a bit of a history lesson on how operations work has evolved over the last

in to an overview of [Terraform](https://www.terraform.io/) which is a really great tool for provisioning

webserver in Google Cloud with a DNS entry provisioned in AWS via Route 53. Simple, but really

was a nice little overview of the kind of stuff that's possible with Terraform.

I think this is why I really enjoyed Eduardo's talk. Eduardo works for

[Daitan Group](https://www.daitangroup.com)

a tools & automation perspective, but on the perspective of the human focus. Discussions of

the importance of empathy and communication, the challenges of collaborating with people from

very different cultures, and some of the lessons learned along the way. Really inspiring,

Peter, like Jeff who did the Serverless talk earlier in the day, also works at

distributed brute force login attacks where distributed botnets try to attack a login page

with leaked credentials trying to compromise accounts on their service.

This talk was just funny. Will's been in the industry for some time, and told the story

to and saw how the project had devolved in that time. Lots of humourous, cynical anecdotes

about the horrors of maintaining a system for a long time.

This again was one of the "human-side" talks of the day. Unfortunately the schedule doesn't

have the speaker's name, and I didn't make a note of it, but the presenter told the story of

how while working at a company as the head of the ops team, was in the hospital for the birth

Lots of discussion on techniques they employed to help improve their culture & process over

time (blameless post-mortems, release planning, etc).

That's all fine and good, but one of the complaints I've heard from

Django-ista's (is that a term? Djangoites? Django Devotees?) is that it means

technically it still works, but doesn't use Pytest).

So challenge accepted, as one can certainly create [custom manage.py

Pytest as a command line tool. As it turns out there's [docs on how to do this

on Pytest's site](https://docs.pytest.org/en/latest/usage.html#calling-pytest-from-python-code).

This works, in that now I can do `python manage.py pytest` and it'll run Pytest

as if I just ran the `pytest` executable in the current directory.

management command you define a `add_arguments` function and use the `argparse`

module to define the expected arguments for your custom command. In this case

though, I essentially want the interface to Pytest, which would be non-trivial

I recently listened to a recording of a webinar put on through the ACM titled

["Agile Methods: Agile Methods: The Good, the Hype and the Ugly"](https://event.on24.com/eventRegistration/EventLobbyServlet?target=reg20.jsp&eventid=937091&sessionid=1&key=5B3C11566E06BE6564E638C6DFE0F413&sourcepage=register)

might seem like splitting hairs, I think it an important distinction, and one I completely disagree with. I'd like to

elaborate why I feel the distinction matters.

But that's nothing:the real problem was that each one of those lambda calls represented

a PUT to a S3 bucket.

PUT's with S3 are actually one of the more expensive operations. For the `ca-central-1`


To give some context: this site usually costs me well under $0.50 a month, the biggest portion of

which is Cloudfront which clocks in around $0.24. Everything else is misc stuff: data

transfer, S3 storage costs, S3 request costs, I have some old data in Glacier, etc. So to

What really bugged me was how *dumb* I felt, such a silly mistake. What's kinda scary is

that had I not gotten that email from AWS indicating I was close to the free tier limit,

handy for displaying things like what branch you're currently on or similar

"contextual" items. For me because I do a lot of Python work and I'm constantly

switching between various Python virtual environments I have my badge display

in my `.bashrc` file:

than collaborative. One of the things I love about Sandya's article is that it shines a

light on bad habits that are common, particularly amongst experienced developers. I've

definitely been guilty of passing off opinion as fact as well as bombarding a review with

toxic) behaviours but offers constructive practices. Really, really good stuff.

The last one I have is more lightweight:

Everything I've run through Rosetta has been flawless from a functionality

perspective. Having said that though: anything run through Rosetta does seem to

example: I found that having Dropbox (which doesn't support M1), Itsycal, and

Spectacle constantly running in my menu bar all seemed to have a significant

drain on battery life. I've since switched from

fast, and (once you get rid of all your Intel apps) sips battery very

lightly.

were actually fairly small, anecdotal discussions about the difficulties of working with larger amounts of data with

traditional RDBMS systems. Partway through an attendee (who is an employee of Amazon) chimed in and gave an intro on

some of the concepts behind true big data (ie Amazon S3) systems. This was good and bad, while it was great to see

big data, what are the challenges associated with it" to "if you need to do big data, you can use Amazon S3 for the backend".

Union" discussion which has happened in prior years at the unconference. Unsurprisingly [React](https://github.com/reactjs)

was a technology mentioned a fair bit in this session, as was [Vue.js](https://vuejs.org/).

explosion of the sheer number of JS frameworks out there. I didn't stick around for the entire session, instead following

the law of two feet to switch to....