This time, I was working with a chart that is generated using C3.js, a D3-based chart library that is super cool, very well documented and really easy to use.

Using this library, you can quickly generate a beautiful chart such as this:

Using simple code that would look something like this:

var chart = c3.generate({
    data: {
        columns: [
            ['data1', 30, 200, 100, 400, 150, 250],
            ['data2', 130, 100, 140, 200, 150, 50],
            ['data3', 150, 80, 120, 250, 50, 10]
        ],
        type: 'bar'
    },
    bar: {
        width: {
            ratio: 0.5
        }
    }
});

Notice how each one of the columns corresponds to a legend for a group in the bar chart above.  The default behavior for these charts is really cool too; if you click on one of the legends, the corresponding group disappears from view.

My assignment was to extract information about what groups remained visible on the chart and then use that information to calculate an average.

As I mentioned before, this library is very well documented, yet it wasn’t really clear what I needed to do in order to obtain the information I needed. After some digging and a bit of trial and error, I realized it was possible to attach a handler to the click event of a legend, provided we make sure to toggle the visibility of the group in the handler. We can add something like this:

 legend: {
      item: {
        onclick: function(id) {
            chart.toggle(id)
            console.log(chart.data.shown())
        }  
      }    
    }

In the code above, chart.data.shown() returns an array of objects representing the elements/groups currently visible in the chart. The id passed to the function corresponds to the first element in each of the columns we passed to the chart as data. Here, I’m simply logging the array of visible elements to the console, but we can do just about anything else we need with this data. We can save it to a variable or, as I did, in the state of the React component that renders this chart. And that’s it! Really simple!

If someone offers you an amazing opportunity and you’re not sure you can do it, say yes – then learn how to do it later.   – Richard Branson

Recently,  I  was lucky to be trusted with a great amount of the back end work needed for a brand new site. As a junior developer, I’m used to being tasked with fixing what someone else built, developing small to medium features, or enhancing existing ones,  so I was very excited at the prospect of actually building something new.  Oh, but did I mention this needed to be done in record time? I’m not sure the specifics of why, but we had a very tight deadline.

Having such a short amount of time to get all the work done was tough. As the customer’s original requirements kept changing, more information was given in small increments, and even new requirements were added to the list, it became pretty hard to implement and make sure that nothing was left to chance. I don’t know if my previous experience in QA helped any, but I do know that as I wrote my code, I kept thinking and testing all the possible ways it could break. At times it felt that was all I could do. I didn’t have much time to write a complete test suite, and that made me feel very uncomfortable, but, sadly, days only have 24 hours and even excited coders need to sleep.

However, what  I did enjoy thoroughly from this experience was the act of creating. Even on those days when I was exhausted after putting 12+ hours of coding and testing and coding some more, I found myself feeling exhilarated, proud of the work I was doing.

When the site was finally released on schedule and the customer expressed their happiness,  I was beaming with pleasure. There’s no way to describe the feeling of satisfaction that comes from knowing that what you helped build is out there now, working exactly the way it was expected. That you were able to make it work, like iconic Tim Gunn would say. I may be on a stretch here, but perhaps it is the same way an artist feels when they see their piece hanging on a gallery. It’s awesome!

Now, I know for many devs out there this may not seem like a big deal, but it is when you’re a junior developer and you struggle with impostor syndrome from time to time. It is when you’re trying to claw your way out of that junior developer category, and you’re not exactly sure how to bridge the gap. There doesn’t seem to be a clear path between being junior and intermediate, or even a clear definition of who is a junior developer. It seems to me the category often includes recent grads, those that just taught themselves to code, those that just came out of coders bootcamp,  and even those that have been developing code professionally for a few years. How many years? Are skills vs. time even considered? If so, what sort of skills make you intermediate? Not sure…

I hope to get more assignments like this one in the future. I’m beginning to think that they are the best cure for that pesky impostor syndrome. Even when nothing else has changed about who you are in the eyes of your peers, that feeling of “I can” simply stays with you for a long time. More building, please!

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.

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.

And yet, there are those days when I kind of hate them. Those days when I’ve been working on the same issue for what feels like an eternity, yet instead of giving me their seal of approval,  my reviewers keep requesting more changes with every commit.  Those days when I wish my reviewers were not always trying to DRY everything or refactor everything and would just agree with my code… if it works… sort of. Ugh. Yeah, those are the days when I have to remind myself that it is a really good thing they don’t just agree with my code. Even if it’s frustrating. This too shall pass… and I’ll come out of it all a better programmer… after I’ve suffered a while. It’s the only way to learn.

Some time ago, I installed Ubuntu in an old computer I had that was pretty much  on its last leg. I used that machine for learning and experimenting, and I just loved how easy it was to install everything I needed using rvm.  But as luck had it, my older son’s computer broke a couple months ago and I loaned him that machine until his was repaired. Terrible mistake!  He immediately proceeded to install all sorts of junk in it, from Windows emulators to gaming clients, among a whole lot of other things, and when the time came to give it back he simply refused.  And why would he want to give it back?! That computer, although old, has a very nice nVidia graphics card that makes gaming a real pleasure for him. Sigh…

So, rather than continue fighting for the box, I decided to try other venues. I didn’t really want to do a dual boot of my Windows 7 computer or mess with the macbook pro that I use for work, specially after all the effort it took to setup my development environment in it, so I went with the virtual box option.

First, I tried to create a virtual machine using VMWare, which was very highly rather, but couldn’t make my installation of Ubuntu 14.04 work, so next I tried Oracle VM Virtual Box. I followed the instructions I had found in a few blogs that advised creating the virtual box without support for usb, network or python, simply to make your life easier. That seemed to do the trick.  The window is a bit smallish, but it’s better than no Ubuntu at all. And, I’m once again able to use rvm to easily  install, among other things, multiple versions or Ruby and Rails.

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.

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.

One more time, my favorite IT book publisher is having a fantastic sale. This time, Packt Publishing is celebrating 10 years of providing great learning and information materials for IT professionals.  According to their press release,  during that time Packt has  published over 2000 titles and helped projects become household names, awarding over $400,000 through its Open Source Project Royalty Scheme.

To celebrate this milestone, Packt is offering all their books and videos for only $10.00 each. There’s no limit how many books or videos you can purchase from them, but this offer will only last until July 5th.

More information is available at: http://bit.ly/1qqyquT

According to the definition of DRM on Wikipedia, Digital Rights Management (DRM) is a class of technologies that are used by hardware manufacturers, publishers, copyright holders, and individuals with the intent to control the use of digital content and devices after sale.

However, Packt Publishing firmly believes that you should be able to read and interact with your content when you want, where you want, and how you want – to that end they have been advocates of DRM-free content since their very first eBook was published back in 2004.

To show their continuing support for Day Against DRM, Packt Publishing is offering all its DRM-free content at $10 for 24 hours only on May 6^th – that’s all 2000+ eBooks and Videos.

So now you know, if you are as much a fan of great books and great sales as I am, take advantage of this offer and spread the word among your friends!  There’s no limit to the amount of books and videos you can purchase from their website, and all for only $10.00 each.  

Known for their extensive range of pragmatic IT ebooks, Packt Publishing are celebrating their 2000th book title `Learning Dart’– they want their customers to celebrate too.

To mark this milestone Packt Publishing will launch a ‘Buy One Get One Free’ offer across all eBooks on March 18th – for a limited period only.

Packt is one of the most prolific and fast-growing tech book publishers in the world. Originally focused on open source software, Packt contributes back into the community paying a royalty on relevant books directly to open source projects. These projects have received over $400,000 as part of Packt’s Open Source Royalty Scheme to date.

Their books focus on practicality, recognising that readers are ultimately concerned with getting the job done. Packt’s digitally-focused business model allows them to quickly publish up-to-date books in very specific areas across a range of key categories – web development, game development, big data, application development, and more. Their commitment to providing a comprehensive range of titles has seen Packt publish 1054% more titles in 2013 than in 2006.

Here are some of the best titles across Packt’s main categories – but Buy One, Get One Free will apply across all 2000 titles:

• Web Development
• Big Data & Cloud
• Game Development
• App Development