When I'm home alone... I code.

Lifelong learning: Codewars

| Comments

We have so many tools to develop ourselves today that is unlikely to use each of them even once a week. I’ve decided to launch a new series here and it will be related to the process I’m pretty sure you’re familiar with: lifelong learning. This term is quite self-explanatory, but if you’re not sure what does it mean I suggest you to at least take a look on lifelong learning wikipedia explanation. The first sentence there actually does the job:

"Ongoing, voluntary, and self-motivated pursuit of knowledge for either personal or professional reasons."

As I’ve mentioned we have tons of tools and resources to help us grow and I personally tried and still use some of them. I use Duolingo for languages (not the programming ones! I have 339 days streak in Spanish today!), I renew my CodeSchool subscription from time to time (last week I’ve done that to see their React course), I spend some time on Codewars, I dived into edX resources some time ago, I explored the content of Codecademy and so on, and so on. Of course - these are the online resources, but the screen is not my siamese brother so I also read some papers and even wrote a post about the books I think every ruby/rails dev should read. Reading is obviously a part of the lifelong learning process and don’t forget about the traditional paperbooks. Anyway, today I’ll share with you my thoughts about Codewars - a place where you can try yourself with some real-world coding challenges.

Ruby symbols and its garbage collecting

| Comments

Symbols are one of the most mysterious things for Ruby beginners. When I was starting with Ruby I also wondered what is going on sometimes and what these symbols are at all. I’m not a programming veteran, but today I know a little bit more about some things and will share some thoughts here with you. This time about about Ruby symbols, not accidentally described as things above. We start with the basics about what are symbols and when to use them. Finally we’ll dive deeper to take a look on how they are managed by the Ruby GC.

Programming quotes vol.2

| Comments

I’ve finally made up my mind, I will definetely launch a subpage on this blog with all the quotes I think are worth to know. But before it happen, here’s the second part of the ones I like most:

"No matter how slow you are writing clean code, you will always be slower if you make a mess."

Uncle Bob Martin

"Make it work first before you make it work fast."

Bruce Whiteside

Books every Ruby/Rails dev should read

| Comments

Do you know how many programming-related books have been written so far? I’m not sure, but to calm down my curiosity I’ve checked amazon.com resources for the “programming” keyword. The result for today is 224,583! Try to read them all and you’ll become a hyper-ultra-expert of programming. Of course only in theory, cause you will spend all your time on reading rather than coding so your practical skills will be in fact equal to about 0. However, a good programmer should not only code. The well-known process of self development requires reading a lot, so I try to read something from time to time. Let me show you a list of books I think every Ruby web developer should read at least once.

A tribute to Ruby Rack

| Comments

“Rack is a beautiful thing” - that’s how Ryan Bates started his Railscast about Rack middleware in 2009 and I totally agree with him over 7 years later. Rack is indeed a beautiful thing and to be honest I’m happy I started my Ruby web development adventure from Rails 3.2. Why? Because it has already had Rack support! Of course, it’s not a perfect solution for every web app (is there any?!), but it is widely used thanks to its simplicity and power. By the way, I have recently started a new project based on Rails 5.0.0.beta1 and it still uses Rack. Do you want to know why Rack is so awesome? Go on!

My favourite programming-related quotes

| Comments

Who doesn’t like quotes? I think I have a perfect situation almost everyday (at least for me) to use one of the quotes I know. Even for a non-programming talk with my mother, the tech quotes fit quite nicely. Sometimes a quote inspires one, sometimes it makes one laugh. Anyway, here’s a list of some of my favourites. I think I’ll make a separated subpage soon to collect all of them in one place.

Here we go!

"Pasting code from the Internet into production code is like chewing gum found in the street."

Mike Johnson

"It's better to do a sub-par job on the right project than an excellent job on the wrong project."

Robert J. Ringer

Refactor your code with Form Objects

| Comments

I’m pretty sure you have heard about Form Objects, but in case you don’t, let me show you the advantages of using them and a simple way to do that. Why? Because I think a Form Object is like a good diet for your Rails models - it helps to keep it smooth and healthy. With Form Objects you can simply extract all the form-related logic out of the model (or wherever you have it) to make it at least a little bit more SOLID.

Rails CamelCase controller name to snake_case file mapping demystified

| Comments

Have you ever wondered how does your UsersController just work fine when when you place it in the app/controllers/users_controller.rb file? It’s one of the first things in the Rails world that we say it works “automagically”. This magic is not too hard to understand if you know some Ruby. As Rails is an open-source framework, we all can be magicians!

Do you still render your Rails views with ivars?

| Comments

“Convention over configuration” is the well-known Rails slogan. It helps you to launch your project quite quickly when you stick to the famous “Rails Way”. Unfortunately, not for free. Your code will be hard to maintain, extend and even understand. Sooner or later. My mate once told me that “Sometimes it’s better to repeat something important than to say something new”, so let me now repeat you something that you’ve probably heard before: render your Rails views with locals, not instance variables. And here’s why.

Why do I prefer MiniTest than RSpec

| Comments

I’m a lucky guy - I usually work alone so nobody is telling me what to use and how to do it. I have the freedom of choice from the very beggining of the project. Usually. There’s only one thing that remains the same: the need of testing. I won’t be writing here why you should test your code because you already know it. Instead of that I’ll briefly wrap up all my thoughts about MiniTest and RSpec. Before you start further reading I think it’s worth to quote Tenderlove’s conclusion on that:

"A professional developer should be able to work in either one of these because they essentially do the same thing: test your code."