Recently, we have decided to expand our DevOps stack with the addition of Terraform for creating Infrastructure as Code manifests. It became obvious from the start that local backend is not an option, so we had to set up a remote one.
If you've ever been working on an application with a domain concept like organizations I bet you had to struggle with custom features, behaviors and complete white labels. Most young fellows start such with the if-else construction which quickly can fall into monster-spaghetti. Can we do better?
There are only two hard things in Computer Science: cache invalidation and naming things. This old truth is surprisingly significant about web development today since it doesn't mention one underestimated topic - security. Developers are often scared by and completely ignore security considerations in their estimations and planning. We like to think about security as a thing that is covered for us - e.g. Rails is considered as a framework with default settings adjusted to quite high security standards and we like to think that this is enough.
Every young developer gets to know the most common rules in programming quickly, either by their own research or by code review comments. Write small classes and small methods/functions. Be SOLID, Don't Repeat Yourself, Keep It Simple Stupid and a lot of other programming principles.
A recent confession by Piotr Solnica started another bit of drama in the Ruby world. I started writing this post just after reading Fabio Akita's response to Piotr's post - for me it shows all the problems with Rails' defensive mindset, but it also reminded me that Rails is still a pretty cool framework. Feel confused? Let's solve that.
A year after the first European Elixir conference, the language doesn't rule the world just yet. Nonetheless, the recent edition of the conference shows that alchemists are on the right way to making it happen. Let me explain why.
I grew up in the golden era of monthly magazines about computer games (rest in peace Reset and Świat Gier Komputerowych). I was so crazy about them that I would look through the window by telescope to verify if a new issue had landed at the nearest newsstand.
There are dozens of articles about Code Review (you will find some links at the bottom of this article), but from time to time it is a good idea to revisit the basics or just find everything you know about the topic for industry newcomers.
So you are a young developer. You are close to or have already finished your studies and decided to get your first job. You will start working in a team - that's the main difference between the job which you will be paid for and projects made at home or ones for educational purposes. A team will consist of two or probably more people (we at Monterail have teams with size of 2 up to 10 people). Regardless of the company that you will join and the programming language and tool set you will learn, you will need to become familiar with the word
teamwork and its meaning.