Spoiler alert: it's premature optimizations.
Whenever a web app has integrations with external APIs (which, let's face, happens most of the time nowadays), there's usually an increased complexity about it when it comes to testing.
I recently watched Greg Hurrell's screencast about Opening files in Terminal Vim, in which he showcases an OSX-only solution for being able to open files on Vim when using Finder.
Code golf is an interesting concept to me: to solve a programming challenge, using not the most efficient or readable code, or the most state-of-the-art solution, but with the smallest code size possible.
For this weekly, I want to recall how we first started doing code reviews. We were young and striving to follow the great minds in this field. So Miguel and I decided to revisit our old pull requests and read the comments.
I remember one particular class I had. It was late May and, as pretty much every Spring day in Portugal, the sun decided to greet us with a little too much enthusiasm.
This week on Ruby Bits we've decided to honour the Juno mission entering
Jupiter's orbit by discuss
another special operator in Ruby, commonly known as the spaceship operator
(because it looks like one). You've probably come across it at some point, but
if not, here's what I'm talking about:
If you thought that the
had to deal with, you were mistaken. We also have one in Ruby, even though it
differs immensely in terms of functionality, from its JS counterpart.
I have lately run into a problem with my editor of choice, vim (well, actually, it's neovim), and the syntax highlighting in Ruby files.
Debugging is something that (un)fortunately we as developers are all used to doing, but depending on the language, the techniques and tools might differ, if ever so slightly.
Have you ever had to implement arithmetic operations for an object? If so, there
is one little method you probably should be aware of, and it's called
The purpose of this article is to demonstrate how to use Redux on a Meteor application. You may find it is unnecessarily complex for your application, and that is ok, there are [other options][other-data-loading] for you.
If you've been writing Object Oriented code for a while (or any code really), you're probably familiar with expressions such as DRY, the Law of Demeter or Composition over Inheritance. One thing they all have in common is that the can be followed by using delegation (among other solutions).
Welcome back to the world of
Enumerable my friend. As Rubyists we are used to
spend a lot of time looking at and working with this module (even if you're not
entirely aware). This time we will be looking at a somewhat hidden feature of
most of its methods, they can be used without a block and have a return value
that is itself an enumerator.
If you've ever used Ruby you have probably used
Bundler through it's command
bundle. There's quite a few things you can do with
the more common
bundle install or
bundle exec, to the less frequently
Enumerable module is the core of everything in Ruby. It is often said that
if you know this module, then you know Ruby and that's not far from the truth, in my opinion.
I've been experimenting with
factory_girl lately, particularly to deal with test data that's not necessarily tied to the database. Did you know you can use it to instantiate any Ruby object, and not only
If you have ever built a Rails application, you probably have encountered
ActionMailer along on your travels. If that is not the case, then it suffices to say that it is the Rails way of sending emails. Here's a basic example:
I have a confession to make. A while ago I hacked my own company.
With recent advances in front end technologies, front end developers have been going crazy, pushing CSS to its limits and doing all sorts of beautiful animations. Seriously, there are some crazy things out there.
Crystal is a typed, LLVM compiled language that reads (mostly) as Ruby. It's a modern language that comes bundled with support for WebSockets, OAuth and other niceties.
Mobile web applications are expected to work differently from desktop applications. They need to feel responsive to the user's touch. Having worked on a couple of mobile web applications in the last year, I found that I always start by changing the browser's default appearance and behaviour. This article contains my setup to make a mobile web application feel more like a native one.
We're ready to announce that the 2nd edition of RubyConf Portugal is coming and it's going to be bigger, bolder and awesome-er!
I said it before and I'll say it again, several times: Automation is awesome.
I am privileged. I am able to navigate the web in all it's glory, with all the amazing animations, crazy stuff happening on scrolls, great videos and the latest style for input fields.
In the last couple of months I've been a part of Group Buddies. I joined this company as an apprentice, where I learnt how to work for the web and to follow high quality standards. I was already coding apps for fun, but I had no idea how the web worked.
In this blog post I'm presenting a solution to make Meteor apps work completely offline. In fact, Meteor apps already work offline, as long as the user doesn't close the browser.
I try to automate all the annoying repetitive things I can. And not long ago, merging Pull Request was certainly on top of my list.
Git is so awesome and packs so much power that I could hardly fit it all in a blog post (or 100 for that matter). What this post will talk about though, are a couple of ways to extend your git for it to better serve you on your everyday tasks.
I'm taking the time to write the tutorial I wish I had some months ago. My task was to set up some user voice recording mechanism in the browser. It should record for about one hour, non-stop, saving to a server. The idea was to use the [getUserMedia()][getusermedia] API. No browser extensions should be used.
Having written and read a lot of Ruby code, I occasionally come across some not-so-well-known features. Or even just a tiny detail that, as useless as it may be, I still find interesting.
Like most developers I know, there is a list of things I want to learn and experiment with. Mobile development was on the top of that list until last December, when we took a day off for an internal hackathon and some of us got to work on a mobile app.
Ruby 2.0 came with a feature that I love, that's the keyword arguments. They allow you to make your objects interface clearer, so you can call methods like so:
If you've been working with git for a while you've probably realised that it has a LOT of configs. A pretty nice one is the
push.default, which allows you to change the way your branches are pushed to a remote.
It's an almost impossible task to find a way to write consistent, future-proof and robust CSS. Our process has, until recently, consisted of appending CSS rules in an ad hoc manner to some sort of file organization.
Tired of being lost among our own bloated code and knowing how big a headache it was to maintain it, we've decided to evolve into a more modular architecture. An architecture that grants considerable improvements on productivity and maintainability.
On the second edition of the Open Source Fridays, here's what we've done:
Last friday we started a new project at Group Buddies, the Open Source Fridays. This means that for four hours every Friday, every one at GB will be contributing to OSS at some level. It can be by writing documentation, opening pull requests on other people's projects or creating our own.
If you were ever in charge of configuring a web server, you must know how painful it can be sometimes. During your first learning days, you probably spent an awful lot of time SSH'ing into the server, trying out something you just found online. It probably ended up being a slow trial-and-error process before you got your first server up and running.
If you implement responsive design then CSS's calc() is a must know feature. If you've never heard of it, here's a description from MDN:
One of the hottest topics of the moment in the rails community is application design or architecture. There is an obsession (a good one, I think) with clean, decoupled code, that is easy to maintain and extend. This has led to things such as presenters, service objects, to some extent even rails concerns.
If you've been in the development business for a while, especially if working with OO languages, you've probably heard of design principles. It's kind of hard to keep track of them all, and sometimes it is even impossible to follow them all. That's why, as with many things in the software area, you should use these principles as guidelines, not rules.
Imagine you have a class which gets XML data, parses it and then stores the parsed data on a database. You could very well write it like this:
A lot has been said in the past months, especially in the Ruby community, about the Sandi Metz rules for developers, so the purpose of this article is not as much to explain them as it is to show how we apply them here, at Group Buddies.