From my personal experience organizing EFLBA this year and watching Monika organize many Erlang factories over the years:

Preparing the bags and swag is not a simple task. You have to schedule some time for it in advance, talk to your sponsors about how to gather the stuff (particularly in Argentina, remember customs are tricky, to put it lightly).

You will need volunteers for the day of the conference. You might have a nice team, but you and your team will also be exhausted from the stress of the last days prior to the event and willing to watch some talks or even speak or present them. Volunteers are an invaluable help to deal with the minor tasks through the conference.

Gather feedback! All the feedback you can. From speakers, from the audience, from your co-organizers, even from the tech crew. It’s super important, being this your first conference, to learn from it. And on this topic, you have to get the feedback as fresh as you can. If you wait for a week after the event to send a survey… nobody will reply.

If the event is in Buenos Aires, don’t forget that everybody working on the event (even the volunteers!) must have insurance. And insurance here is not a cheap nor an easy thing to procure. Plan for it in advance.

Hire a professional tech team. Recording the conference/talks properly goes a long long way to promote the next year’s version of it. Check the videos of EFLBA, they have links to the tech team if you want to hire the same one.

Don’t forget speakers’ dinner (especially if you have international speakers). To care for your speakers is super important. In most cities, there are many things you can tour around for free, and that would be a plus for anybody visiting the city for the first time.

I read this, waiting for some kind of story payoff, and it never hit. Basically, instead of fixing an error it was embraced and became a joke. As far as I can tell, it was never fixed. I didn’t get any insight into even trying to find the error, nor did I get much about the culture, that is, how it became a joke.

Yeah, the error was never fixed, mostly because it was not a single error. It was a group of errors: -0// was the symptom of something going terribly wrong and totally untrapped somewhere.

I’m not really interested in discussing how we debugged the many different situations in which -0// appeared and of course I don’t even remember most of them.

Nevertheless, I’m super happy to expand on how it became a joke as much as needed. I’m just not sure what to say. So, what would you recommend I add to make the culture part more complete and interesting? Any particular questions you think I can answer to give a better view of the cultural implications of -0// would be much appreciated.

I think if I were to relive my Erlang education, it would be to go against the severely pushed agenda of `no matter what, use behaviors from the get-go.’ gen_server is a great pattern, but it feels counter to everything functional programming and for that matter concurrent programming is all about. Sure, now knowing how the behaviors are implemented, it all fits, but for the first while, the behaviors felt magical (like OOP), stateful-feeling-ish (like OOP), and imperative (after all, 1. a gen_server is embodied within a single named process, despite that Erlang touts: go ahead, create millions of processes; 2. the most common thing to do with said servers is use =call= which is blocking/synchronous). In the end, of course, use the behaviors, but just blindly using them from day-one is a crappy lead-in to Erlang/OTP, and probably comes with many hidden costs as far as how fast & deep one learns the paradigms of FP and all things OTP.

I can’t agree more with this feeling. It is, in part, the inspiration behind this blog post. The idea is to first find the problems, try to solve them, figure out they’re always the same ones and somebody before you found them too, and only then using the tools that solve most of the problem for you and write your specific code.

IMO interviews are all about social signalling. This is why blind interviews are useful: they prevent us from confusing social signals that are similar to our own for high technical aptitude. NoRedInk is one of the only companies I know of that do these kinds of blind interviews, but surely there are others.

I’m receiving visits from a client and my boss (both super unusual things, considering we work at Buenos Aires and they live in the US). More importantly tho, I’m organizing a conference this Thursday/Friday.

I’m honestly curious why this article is flagged as off-topic or spam.
My intention when I wrote it was to ask for comments on a problem I had as a CTO in a funny way.
The problem was real and it was very much related to something that we (as developers / tech leads) face regularly.
Was it the tone of the article that doesn’t belong to lobste.rs?
Is lobste.rs not the place where I should be asking for advice on how to be a better tech lead?
Or is it something I else I’m missing, maybe lost in translation here?

I’m helping a client debug a super weird bug that destroys their entire cluster of erlang servers in about 10 minutes, but only happens when they move their servers to better (i.e. More powerful) machines.

This week is all about yearly appraisal meetings at my company.
As the CTO, I’ll meet for an hour with each employee (and the CEO) to review their 2016 performance and talk about goals for 2017.
Even when I have regular monthly meetings with each employee, this is no doubt the most exhausting time of the year for me.

Writing some Erlang code to add Swagger to a RESTful API for a social network app for dogs and dogsitters.
Also, conducting yearly appraisal meetings with the employees at my company.
Finally, if I manage to find time, I’ll start writing Inaka’s REST guides

I’ve become more and more in favour of hardcoding these things. A good language should allow you to express a structured value in a way that doesn’t look “magic”. And your release/deploy infrastructure should be such that you can make a change and release to prod quite quickly. Software exists to solve business problems and has a lifecycle associated with that: when the requirements change, so should the software. And the concerns of audit trail etc. are handled automatically by whatever mechanism you use to handle code changes. No, this doesn’t let users change settings, but most of the time that’s the wrong call IME: most setting changes are behavioural changes that impact the functionality of a piece of software and ought to go through the same release/testing process that any code change would.

I think in our case it’s particularly important not to require a developer intervention to make such changes, because we build systems for our clients and we like to just give the systems to them at some point and move on to our next project. Therefore, whatever we can do to avoid the need of involving our devs in those small changes, the best.

That doesn’t mean they need to be “hardcoded”, assuming you mean in the code. They can be in a config file that the code reads, but it’s still in the same repository as the code and only changes in the code. I, personally, prefer to separate them out because I find it easier for testing, easier to get a view of what the configuration is, and easier to analyze or consume by other tools.

I don’t see what difference it makes to testing? If everything’s just code it’s easy to swap out a value with a different one. As for getting a view of what the configuration is, configuration as a value should be readable if the language is any good.

What kind of analyzing/consuming are you talking about? Again, if it’s just a value, one can integrate with other systems the same way one integrates for anything else (e.g. JSON, ProtoBuf, …)

It depends on what “hardcoding” means to you. Generally these are not very changeable. I often run tests for which the service is configured different than production, in such a case I like to test the same binary artifact as I would run in prod, so the configuration becomes separate. But, like I said, it depends on what you mean by hardcoding.

Analyzing/consuming is actually wrong, I shouldn’t have said that. But what I do more often is I programatically generate a config file that is then consumed by the application when run. I prefer to have the config format as an inbetween so it can be inspected by a human when debugging.

It depends on what “hardcoding” means to you. Generally these are not very changeable. I often run tests for which the service is configured different than production, in such a case I like to test the same binary artifact as I would run in prod, so the configuration becomes separate. But, like I said, it depends on what you mean by hardcoding.

My preferred approach is a class with a few (static) instances, and then just a bit of code to pick which one to use at runtime (based on a commandline arg or environment variable or the like) - I agree you do end up with a few things that need to be different between blue/green/dev and these things need to be to a certain extent segregated from the code proper (though to my mind a separate package is more than enough). I agree that humans need to be able to view the config, but I tihnk a language always needs a good syntax for structured value literals, because so much of programming ends up being that. If JSON or the like is substantially more readable than what the same value would look like in code, I think that’s a real deficiency in the language.

If JSON or the like is substantially more readable than what the same value would look like in code, I think that’s a real deficiency in the language.

For myself, the value is in what you cannot do. I do not want to have to parse code to try to figure out what configuration is actually being used, that is why I like the config file as an intermediate. That way I have a turing complete generating the config and a turing complete language consume it but the config is just values. With discipline you can just get rid of it and use configs direct in the code like you are doing.

I guess the trouble is that > is polymorphic, otherwise we wouldn’t need the is_integer test in the first place. But since everything is comparable, and atoms > integers, the guard will actually pass non-integers:

4> is_integer(false) and false > 0.
true

Minor wat there, so if you pass a boolean to the original function, you actually hang up on the subtraction inside: