Some time ago I published a post about the books I think every Ruby/Rails developer should read. This time I’ll briefly describe another one - the classic Pragmatic Programmer from Andy Hunt and Dave Thomas. It doesn’t fit the post I’ve mentioned above because it’s a book I think every programmer should read. Not only the web developers, or the Ruby/Rails ones.
From time to time most of the Ruby/Rails developers are facing a situation when an app is trying to call a method on a certain object, which out of nowhere appears in our system as
nil, instead of an instance of the desired class. The worst scenario in such situations, assuming that you want to solve this problem somehow, is to take advantage of Ruby’s open classes and achieve a
quick win by monkey-patching the
NilClass to avoid raising the famous
NoMethodError. Even if you’re new in Ruby world, you should know that it’s a really bad practice and do not do that. You can, of course, achieve the goal in a few different ways, and here we’ll be describing one of them. Have you ever heard about the NullObject pattern? Here’s a quick introduction on how to use it.
We all know JS somehow, how confident are you? Is
null equal 0? What is the result of adding two empty Arrays? If you know these ones, you’re really good, but still can find some more interesting JS facts by reading further. Let’s go!
Sometimes I really miss the times when everything was so simple, even though lots of things seems to be really easy today. I remember the days we had only HTML, no backend/frontend separation, no frameworks, no CSS*, nothing. So let’s talk about browser-level cross-origin HTTP requests performing some kind of pre-CORS ‘sanity check’ using
options method that allow us to e.g. fetch the JSON data from remote API for our node-powered Ember SPA. To be more clear, we’ll take a look on a CORS preflight requests :)
From time to time you have to wrap some magic code in an ActiveRecord transaction. In such cases it’s better to make sure your code does its job or you’ll face the problems sooner or later. Even if you code only for fun, it’s worth to know a few things about transactions before you fall into the deep forest of debugging strange issues you can avoid. Just to make sure we all know what we’re talking about, let me paste the Rails API description of the AR transactions:
Transactions are protective blocks where SQL statements are only permanent if they can all succeed as one atomic action. The classic example is a transfer between two accounts where you can only have a deposit if the withdrawal succeeded and vice versa. Transactions enforce the integrity of the database and guard the data against program errors or database break-downs. So basically you should use transaction blocks whenever you have a number of statements that must be executed together or not at all.
I love this description :-) it’s everything you basically need to know to understand what an ActiveRecord transaction is. Ready for a few quick tips? Go on!
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.
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.
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."
"Make it work first before you make it work fast."
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.
“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!