Tag Archives: ruby

In search of a faster query

Posted on by Posted in MySQL, Rails, Ruby

Recently, as I was fixing a minor bug in one of our applications at work, I had the opportunity to witness what a great difference a simple query can make.

The bug involved a very slow query, that was doing a join between a couple of tables that had grown too large in size. The query, in Rails, was as follows:

 

Model1.joins(:model2).order(:attribute1)

That query alone was taking nearly 2200 ms to complete,  kind of showing that it really is the devil to make a join between two large tables. The table for Model1, for instance, had nearly 90,000 rows and 10+ columns, while the table for Model2 was slightly smaller, with nearly 30,000 rows.

After examining the code, I realized we really only needed the id and attribute1 of Model1 records, so I modified the query slightly to retrieve only that:

 

Model1.select('attribute1, model1.id').joins(:model2).order(:attribute1)

 

Wow! This simple change brought the time down to around 520 ms, which was still sluggish, but a great improvement from the 2200 ms we began with.

It was a third iteration of the query, however, that  made the most impact. We had a third table, for Model3,  with an association to Model1  that we could use to our advantage. Although with no association between them, Model2 and Model3 both had a model1_id column, allowing us to do something like this:

 

model1_ids = Model3.joins('INNER JOIN model2 on model2.model1_id = model3.model1_id')
                   .uniq.pluck('model3.model1_id')
Model1.where(id: model1_ids).order(:attribute1)

 

That last query brought the time down to around 40 ms. Not bad at all!

I felt very pleased by this results, mostly because I learned  it pays to play around with different ways to do the same, and to keep an eye on the query times reported in the console. It’s also worth thinking about how large the tables are likely to grow, although I know it’s hard to predict the future. It is possible when this part of the application was written, some time ago, that first query used to be fast enough, most likely because the table was small too.

 

 

Living la vida Ruby

Posted on by Posted in Blogging, Ruby

Last Monday I attended a hangout meeting with the CodeNewbie community. Something they call Ruby Monday. It was my first time trying this sort of virtual community interaction, but I had such a great time that I think I’ll be joining them again real soon.

I think what I enjoyed the most was the atmosphere of respect for all members in the group.  It is something nice and incredibly encouraging when your contributions are considered important and your voice is heard, regardless of what your level of experience may be.  Thank you, guys! You rock!

As a Junior Engineer, I find that I often feel unsure about the value of my own contributions, be it to a coding community or even to the company I work for. Sure, I’ve gradually gained more confidence, as I’ve developed new skills and acquired experience over the years, but there’s still that part of me that will always wonder how much experience is enough experience for my peers to even consider that I have something interesting to say.

As I meet more people in the coding community, coders of all backgrounds and  skills levels, I learn that most often than not we are our own worst judges. Yes, it is true there are a few jerks out there, and people that enjoy putting newbies down to make themselves look good, but most people are not that like that. I do believe, however, that many of us may still suffer from certain bias, even if we don’t know it.

I remember reading some time ago about a study that attempted to determine the bias against women in leadership roles. It was shocking to read how exactly the same actions or circumstances made a man appear as a great leader, hardworking and dedicated, while a woman was perceived as bossy or selfish.  Sometimes, I wish someone came up with a similar experiment involving coders.  I wonder what would happen if the same solution to a bug or issue, or even a feature, was presented as authored by a newbie programmer, an experienced programmer, a younger person, someone over fifty, a programmer who is new to the community, a programmer who is very well known,  a man or a woman. Would it make any difference?

We can’t control any bias that anyone may have against us, but we can certainly do our best to avoid being biased against others and even against ourselves.  We are biased against ourselves when we avoid opportunities to contribute because we think we have nothing to give, when we feel like the impostor that crashed the party,  or when we allow negative feedback and rejection from others to keep us from doing what we love, simply because we interpret it as a confirmation of that fear of not being good enough.

That’s why I find communities such as CodeNewbie so amazing. Like a safe haven! Before attending that meeting I had considered revamping this blog many times, and many times I had abandoned the effort, second guessing myself, wondering if I really had anything good or useful to blog about.

Well, I am just someone who enjoys coding, who likes the Ruby language, who is working hard to build herself a career as a web application developer (of the Rails persuasion),  and who also enjoys writing. While my experiences may not seem relevant to some, I believe someone out there may find them useful enough to keep coming back for more. If you’re one of those, thank you! I promise to update frequently.

Oh, just to end in the purest community style of sharing, here’s a tiny something I learned recently. Until recently, I didn’t know you could evaluate multiple values in a case statement (in Ruby) simply by separating them with a coma,  like this

case word
  when "first", "last"
    # do something
  when "second"
    # do something else
end

That’s cool, but even better is that you can do something similar with regular expressions, and you’re even able to make use of whatever value is matched by the regexp, for instance, as the argument for a method call. Like this

case url
  when /products\/(\d+)/, /products\/special\/(\d+)/
    call_to_method($1)
  when /events\/(\d+)/
    call_to_other_method($1)
end

This last statement will match an url such as  /products/56 and then use the value 56 to call the method. It would also match the url /products/special/78 and call the same method with the value 78. Pretty simple, I know, but useful.

 

 

Diary of a Junior Ruby Developer

Posted on by Posted in personal

I was introduced to Ruby and Rails during the time I spent working for Manilla.com. Those were four really great months in my life that I  will never forget. Back then, working as a robot developer,  my goal was to slowly acquire  the skills that would allow me to eventually move into the Rails team.  Sadly, Manilla closed its doors before I could get a chance to achieve that goal.

Shortly after Manilla closed, I found another job working remotely for a company that provides enterprise publishing solutions. I was hired as a Junior Ruby on Rails Developer and now I work  mostly troubleshooting, fixing bugs and occasionally implementing customers requests. The job is challenging because tickets are hardly ever about the same issue and there’s so much to learn about their codebase and, in the process, about Rails and Ruby, as well.  I am very fortunate that there’s plenty of knowledge to go around and the other members of the team are always happy to help you or at least point you in the right direction. I love peer reviews! It’s a great way to learn from others that have been writing code longer than you and have tons of tricks under their sleeve. Still, learning takes time.ah728

It’s like drinking from a fire hose. That’s the analogy our CTO used recently when talking about the sheer amount of information that gets dumped on you during your first days or weeks on the job. It gets better with time. I do my part by reading everything Ruby or Rails that falls in my hands, watching videos, following tutorials, etc. As a matter of fact,  I am incredibly lucky I finished reading  ‘Everyday Rails Testing with RSpec’  just in time to put all those newly acquired testing skills to good use on my first week on the job.  I highly recommend that book! The railscasts have been a great help, as well, but there’s plenty that can only be learned while on the job. Nothing beats that kind of experience.

Perhaps, my next update will find me a lot more confident. For now, I’m enjoying the job, because this is what I wanted to do and every step is getting me closer and closer to where I want to be someday, but I am also  in “survival mode”, spending most of my spare time trying to learn more and learn faster.