Detroit Day Of Functional

After a bit of discussion and debate a few of us have decided to go ahead with the Detroit Day of Functional on March 25, 2017. Detroit Labs is kind enough to let us borrow their space for the day so that’s where we’ll have it. We’re charging $30 a ticket but that’s mainly to cover lunch and maybe a t-shirt for the attendees if there’s enough left over for that.

We’ve also decided to do something a bit novel (well novel for me anyway). We’re organizing the event as an unconference. That means no pre-selected speakers or sessions. We’re running the whole thing on the principle of open spaces.

I know some people will wonder why we’ve decided on this approach. I can’t speak for my colleagues but for me there were a few good reasons:

  1. I wanted to keep the event relatively simple and I wanted to focus on content more than anything else. A call for speakers is a lot of work and frankly as much as I’m usually happy with the folks we end up with I also feel bad for those who submit great ideas that we can’t accommodate. This way if anyone’s got something really neat they want to discuss, they have the opportunity.
  2. I’ve observed that no matter what I pick for a conference there are people who feel that I’ve got some sort of blinders in regards to content. I’ve been told that my conferences are too “Microsoft-centric”. I’ve also had people express concerns that underserved populations aren’t represented enough by speakers at my conferences. Well here’s your big chance to show me what I’ve been missing. Literally anyone who cares to lead a session can do so. If, for instance, you don’t feel like there’s enough content on stack-based languages at conferences, here’s your chance to remedy that. Want to have a conversation on why functional programming stinks? Feel free. That’s the point of holding this as an unconference–you decide what we discuss, not the organizers (well, not only the organizers anyway).

I wanted to insure that people know exactly what to expect from the start. I wish I were a bit more glib because I think that sometimes people feel that I swing some pretty blunt language but I can’t think of a clever way to say “Hey, we’re not going to have speakers for this event. We will have lunch and we may have t-shirts but no set agenda in terms of speakers.” I’m tempted to set up a pool to see how long it takes someone to ask me “Hey why aren’t you guys going to have speakers at your event?” This is my attempt to forestall the question before it’s even asked.

How I Blew That Interview

  • They said they wanted a “Rock Star” developer but I think they got upset when I trashed the hotel room they had me put up in.
  • They said they wanted a “Rock Star” developer but you should have seen the expression on the face of the interviewer when I smashed my guitar on his desk.
  • They said they wanted a “Ninja” developer but then they insisted that I remove my black cowl during the interview.
  • They said they wanted a “Ninja” developer but I’m pretty sure they got a bit upset having to dig my throwing stars out of the paneling.
  • They said they wanted a “Rock Star” developer but I’m pretty sure I lost them about halfway through my twenty minute drum solo.

Left Side vs. Right Side Agile

We were discussing agile today and I came up with something that I thought might be worth sharing with others.

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

And I was saying to some of the folks on my team that it seems as if we’re getting right side agile and not left side.  While lots of firms these days are calling themselves agile they’re still very much on the right side of that list. As someone put it to me, lots of places are doing waterfall with daily stand ups and two week sprints.

So maybe we need to start calling out our managers and our VP’s on right side agile and tell them that we favor the left side and we want them to favor it too.

Premature Generalization

I’m sure most developers reading this post will be familiar with the term “premature optimization”. For those who may not be familiar, this refers to the tendency that some developers have to worrying about the performance of their code, usually but not always in terms of execution time, before their code is proven to work correctly in terms of customer requirements. It’s like saying, “Hmm, this function call may take 3 clock cycles to execute but if I inline the code it won’t take any extra clock cycles” before the developer has correctly defined the function to be called. It’s generally considered a poor way to write software. I believe it was probably Joe Armstrong, one of the co-creators of Erlang, who said “Make it right, make it fast, then make it pretty.” Getting the code right always comes before any sort of optimization should be attempted.

Risking the perils that may befall anyone who coins a neologism, I propose another premature condition which developers should try to avoid: premature generalization. I would define premature generalization as being the tendency to assume that what you see or what you want is what every other developer sees and/or wants. It’s the tendency of the novice developer to post messages like “Hey function x isn’t working. What’s wrong?” assuming that the rest of us also have the problem they have and we therefore don’t need any more detail to know what he or she is talking about. It’s also the tendency to assume that because they need to address some particular use case that most developers working in the language will need to address the same use case: “Hey I need library function x to return an error status when I pass it a bad argument but throw an exception when I pass it a good but out of range argument. Can we modify the standard library to do this?” In both cases, I believe they’re prematurely assuming their question is generic and therefore they don’t need to provide details to others.

Although I feel I’m flogging a dead equine I hasten to point out that as software developers we should usually proceed from the assumption that the error we’re seeing is due to something specific to us. We should also proceed from the assumption that any use case we have is likely to be a use case specific to us until we see evidence otherwise. Yes, I am aware of the irony of making generic statements here—but given what I’ve seen over 25+ years of software development I don’t believe that I’m indulging myself in premature generalization.

Quick Elixir Debugging Tip

HT: Dmitri Skliarov for sharing this tip with me.

You can quickly see the call stack being invoked when you call a given Elixir function via a quick and simple call out to the Erlang DBG module. The following tip is a very simple example of how to use this; there’s quite a bit more that can be done with DBG but you need to look at the module docs to see them.

First a little code that we want to trace:


defmodule Trace do

def add(n, m), do: n + m

end

Next you will want to initialize the debugger:


:dbg.tracer()

# => {:ok, #PID<0.66.0>}

NB: you are extremely unlikely to get the same PID I’ve shown here. Next we need to tell the debugger which item or items we want to trace:


:dbg.p(:all,:c)

# => {:ok, [{:matched, :nonode@nohost, 45}]}

Next we tell it precisely what we want to track:


:dbg.tpl(Trace,:add,:x)

# => {:ok, [{:matched, :nonode@nohost, 1}, {:saved, :x}]}

NB: the first parameter to tpl is actually an atom but since a Module name is automatically an atom it’s fine to pass the module name without a colon in front of it. Also note that you can pass the special atom :_ as the second parameter to trace all calls to all functions.

And finally we actually trace our code:


Trace.add(1,1)

# => (<0.57.0>) call 'Elixir.Trace':add(1,1)
# => (<0.57.0>) returned from 'Elixir.Trace':add/2 -> 2
# => 2

And for reference when we use :dbg.tpl(Trace,:_,:x):


Trace.add(1,1)
(<0.57.0>) call 'Elixir.Trace':'__info__'(macros)
(<0.57.0>) returned from 'Elixir.Trace':'__info__'/1 -> []
(<0.57.0>) call 'Elixir.Trace':add(1,1)
(<0.57.0>) returned from 'Elixir.Trace':add/2 -> 2
2

 

And finally when you’re done tracing:


:dbg.stop_clear()

There’s a lot of power using this technique so I’d advise that you take some time to look at the DBG man page before you start using this extensively.  Also, it’s my understanding that you should always be careful to use this technique only in development because if you trace the wrong thing you can cause deadlocks.

 

 

 

 

Quick Elixir Tip

I use Samuel Tonini’s Alchemist (and Elixir mode) to make myself much more productive with Elixir and Emacs.  But one thing that I’ve found to be a minor annoyance is that whenever I start up Emacs I have to set the scratch buffer to be in Elixir mode and I then need to change the comment characters.

Thanks to this excellent tip I no longer have to do this.  I’ve modified my ~/.emacs to add these lines to the bottom:


(setq initial-major-mode 'elixir-mode)

(setq initial-scratch-message "\
# This buffer is for notes you don't want to save, and for Elixir code.
# If you want to create a file, visit that file with C-x C-f,
# then enter the text in that file's own buffer.")

And when I get a scratch buffer I’m all good to go with Elixir!