Software Engineer and Architect. I've got things to do, and they sometimes end up here.
I found my happy place with the support, community, and testing in Elixir. I write in many languages, and beyond my internal resistance to slow down and interface and test everything properly, I don’t want to need to compete and select yet another integration to support the level of testing that I need to accomplish.
This article has some opinion mixed with real experience, but for some more background you can check out my earlier post about scalability and parallelism approaches here
This post is a reflection on a conversation I had with a co-worker. I had just switched jobs from coding Elixir full-time to doing low-level C++, and I was re-living a lot of the frustrations associated with going back to a language like C++. I was describing the Elixir language and the Erlang runtime, picking the low-hanging fruit of discussion: immutable data, strong but dynamic typing, no concept of memory allocation or pointers. We couldn’t talk long, but that last point, no pointers, led him to ask me “But how is it fast?”.
This post discusses what my first steps into Elixir were, and how I approached it from the perspective of a Node/Mongo Full-stack developer.
What is the concurrency model of the language or platform you are using? How does it compare to the other models? I’ll wager that most engineers and coders just run with what they know, and if the need to scale happens they go with the flow. However, knowing how a runtime handles concurrency, and how to scale it when you need to, is key when selecting what to implement your platform on, or what to migrate to next.
Excuses incoming: A lot has been going on, and I have neglected this blog. Surprisingly, I have also neglected myself. But as part of fixing what is wrong with me, I am also fixing this blog. I have updated the about section, which was over 5 years old. I had 2 posts after 2016, but one was an unpublished draft and the other is just a rant at the concept of using velocity to determine a team-members worth.
Velocity is a piece of information that is not only used, but heavily relied on as a part of scrum and agile processes. It is used to find underperformers, and measure increases in productivity. But Velocity is not only unreliable, even when it is relatively trsutworthy it is not a metric that should be used. Velocity on a scrum or agile team is a bellwether; no more and no less. I want to talk about it:
I faced a common problem this morning, but not in a place I would ever expect: Homebrew. There is a storm of negligence that came to a head with me unable to run any of my production APIs.
I have been working on web applications lately. Working independently or on small teams, I find ReactJS to be quick and easy to write. But in learning how to write better, and better performing React code, I should start using other libraries, such as ImmutableJS. All good things and I like what I see with only one glaring exception: I work in Typescript.
OK. I just created a new blog by cloning barryclark/jekyll-now, and now I have a blog post to overwrite. I wasn’t prepared for this, but that never stopped me before.