And make sure your message is clear

Image for post
Image for post

I often see people speaking about programming and trying to describe its nature, classify it in one way or another. Some people say it’s an art, others claim it’s a skill, still others instist it’s a science. Don’t get me wrong, I’m not trying to argue against any of those statements. However, there’s one aspect of coding that often gets neglected during all those discussion: nowadays, your code is your way to communicate. And I’m not talking about communicating with a machine, but mostly about communication between programmers themselves.

Seriously, let’s consider a small project with two programmers working on the same code. They can start with a set of agreements they established during a meeting, a teleconference or in a chat conversation. But as the codebase grows, there’s a strong chance the team expands as well. Sure, it will be relatively easy to transfer all the conventions and assumptions at the beginning: if a new coder only comes in once in a couple of months tops, bringing him / her up to date won’t be an issue. But then something happens, could be good (you got to series A, for example) or not really (you ran out of money, had to let all your programmers go and get that copy of JavaScript for Dummies to do all the coding by yourself). Meaning you end up with some new people looking at the code without any access to the knowledge it is based on (in case of series A it can just mean, for instance, that the original programmers don’t have resources to transfer that knowledge to all the new staff). At this point some of you are probably ready to object, and most of the objections boil down to two things that should have been implemented from the beginning: documentation and comments. However, let’s face it: even if you’re lucky and your project gets proper specifications from the beginning, chances are at some point they will simply stop being updated. As for the comments, we’ll get back to it a little bit later, but the general idea is the following: the better you write your code, the less comments you need. …


Or how to make your Elixir application talk to a REST API in minutes, literally

Image for post
Image for post
Photo by Malcolm Lightbody on Unsplash

What is Elixir

If you don’t know that yet, I’m a bit surprised you are reading this article, but at the same time I’m kind of jealous, because learning about Elixir was one of the best moments in my professional career. After spending too much time with legacy code written in PHP or in Node.js’ callback hell, it was like a breath of fresh air: as if Ruby and Erlang suddenly got a child that inherited the syntactic beauty and simplicity of the former and the performance capabilities of the latter. Long story short, it was love at first sight. But instead of me telling you how wonderful Elixir is, just take a look at https://elixir-lang.org or https://phoenixframework.org, …


Or why knowing a little bit of everything can be better than knowing a lot about one thing

Image for post
Image for post
by Artem Sapegin from Unsplash

If you were ever looking for a programming job, I bet you’ve seen a lot of those ads requiring “X years of experience with framework Y”. I’m not even talking about the cases when a framework or a technology only appeared a couple of years ago and recruiters are asking for 5+ years of experience with it (which, unfortunately, is not that uncommon). Let’s consider some relatively legitimate experience requirements and figure out how much sense does asking for some specific experience with this or that particular tool make.

Situation

For sake of painting a more colorful picture we will imagine that we want to build a new software product and that upon conducting some analysis we decided to go with platform A as our main development tool. Great! So, what do we need now? Some developers, of course. Yeah, but what would we require from them? Obviously, first thing that comes to mind is that they must have some solid experience with the platform you’ve chosen. Right? Not necessarily. Huh? …


How to survive that informational deluge

Image for post
Image for post

Even three decades ago it was relatively easy. If you wanted to know about the most important events happening, you had 2–3 main newspapers. If you wanted to learn something on a specific subject, you could just go to the library and ask the most popular book about it. And if you wanted to watch some TV, all your channels were accessible within a single push of a remote button (that’s if you had a remote).

Of course, getting the information itself sometimes wasn’t easy at all: for example, if you were doing a research on a rather narrow topic, there was a chance the books you needed weren’t available at your local library, so you had to send a request to find them somewhere else. …


Image for post
Image for post

If you work in the industry for a while, you probably know there are different kinds of requests usually coming from the client (or your PM, or, hmm, sometimes your Founder/President/CEO, etc., but we’ll just call them clients as well for sake of simplicity). Some of those requests have low or normal priority, others are urgent (this includes super-urgent and not-going-home-until-it-is-done ones). Some make perfect sense to you and most of the end users of your application, others seem like someone’s exercise in procrastination or like the guys from marketing drank too much coffee while brainstorming. Nevertheless, after several years in this field, you sometimes feel like those kinds are so typical and even specific to software development. …


Introduction

In our previous experiment (part 1, part 2) we looked at a way to build a naturally scalable real-time application using Phoenix Framework, RethinkDB and Elm. Turned out RethinkDB makes going real-time quite simple and relatively painless. However, an interesting question occurred as a follow-up to that article: can we do the same with PostgreSQL? The short answer is yes, we can. But is it that simple? Well, let’s see it for ourselves.

The code

In case you’re not a fan of step-by-step copy-pasting / retyping or if you just want to share the working version of the code, you can find it here: https://github.com/bredikhin/phoenix-postgresql-notify-listen-example. …


Image for post
Image for post

There’s this book I read a while ago, Think Big, Act Bigger by Jeffrey W. Hayzlett, which essentially doesn’t have anything special about it: just like thousands of other marketing books, it has about 5% of meaningful thoughts burried in 95% of hyping, bragging and ambiguous use-cases. But as sometimes happens (and as it did this time), those 5% can actually contain some priceless ideas.

For me in this case it was the idea that if you start working on a big project, you should never ‘take it slow’: either it’s really important and you must dedicate a substantial amount of your resources or you have to seriously question yourself if you need to do it at all.


In the first part we saw how to set up all the components of our stack and glue them together. However, we’re not done with the gluing yet, and in this part we’re going to see how to make the data flow through a Phoenix channel from the Elm frontend to the RethinkDB database and back.

The code

Just a reminder: in case you’re not a fan of step-by-step copy-pasting / retyping or if you just want to share the working version of the code, you can find it here: https://github.com/bredikhin/phoenix-rethinkdb-elm-webpack-example.

Create a channel and connect to it using Elm

Phoenix channels are essentially a message passing engine that plays perfectly with Websockets in order to provide your application with real-time functionality. Using channels you can send and receive messages grouped by topics, broadcast to multiple clients, etc. …


In search of a perfect stack

I think it’s still a popular question that comes up whenever you meet new people in the industry: so, what’s your stack? And you answer with something like “LAMP”, or “MEAN”, or some other four-letter word. Every year or so you get to hear a new one, and other ones take exit (not LAMP though, this one just can’t quit for some reason), and finally you realize that there’s no such thing as the perfect stack. And the same applies to frameworks.

What you figure out instead is that some stacks work really well for a particular kind of tasks, but can easily fail for some other kinds. It all depends on the problem you’re trying to solve. …


I don’t know if you have ever been to Montreal in the winter, but the weather here this time of year is quite special. Not only the temperature varies a lot, but also humidity can drop dramatically. And those electric heaters in the appartment we’re renting dry out the air in the room really fast. Basically, without a decent humidifier you can end up with 20% humidity and even below, which is extremely bad for your health, not to mention little kids who start getting sick all the time.

Long story short, knowing temperature and humidity turned out to be pretty important for us, especially during the winter. And since Siri is already doing a lot of stuff at our place, I figured it would be nice to make her aware of the temperature and humidity in our rooms as well. …

About

Ruslan Bredikhin

Coding, cooking, parenting

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store