Here at reinteractive, I feel very privileged to have access to some of the most awesome and talented Rails devs. I still have much to learn and through flowdock, our group chat app, I am regularly treated to some great tips and techniques as our devs uncover new and clever ways of doing things.
Last week, for example, I learned that the plural of corgi is corgwn. Yes, I know that sounds totally random and not at all useful, even at trivia night. But it is a great example of the wonderful culture we have here at reinteractive.
Recently I set up the Rubocop gem for a project. I wanted to use it to ensure that my code base aligned with the community Ruby Style Guide. When I ran the tool, I came up against the following error message:
This message didn't give me any idea of what the problem was, nor what I should do to avoid it in the future.
Today I was asked by a client to give them some reasons why they should outsource to reinteractive instead of hiring an in house team. They needed to convince their Board the pros and cons of setting up an internal software development team from scratch versus using reinteractive. The project under discussion was the implementation a bunch of key features for their platform as well as a partial rewrite of key aspects.
Unsurprisingly, I've been asked this question several times by our clients, and my response has almost always been the same; do both.
by Leo Liang
There might be times when you need to mock a certain value for ENV without overriding other values. This can be easily achieved as follows:
Today, AWS just announced per second billing on their EC2 instances and EBS volumes. It's great news that AWS have continued to innovate their product, this was one of the areas where the Google Cloud Platform previously had an advantage over AWS.
We are especially happy about this at reinteractive as our OpsCare Ruby on Rails hosting system utilises a prebaked deployment process, which you can see a demonstration of here.
As most developers know, there are many problems that can come up with CSS in a project. I will discuss a few common examples, and then share with you our solution to managing these issues.
Many projects will have at least one old CSS file that no-one knows what it does. People are scared to touch it, or delete things from it, just in case everything breaks. And so this mystery file remains.
by Leo Liang
There might be times when you need to mock a certain value for ENV without overriding other values. This can be easily achieved as follows:
Today reinteractive took an important step in our support of the Ruby Community by becoming the world's first Ruby Member of the RubyTogether project representing a $60,000 USD donation to this open source project annually.
I'm very proud that we are able to do this.
Recently my colleague Daniel wrote an article about Our Code Review Guidelines. But there is another component to this equation: the quality of the Pull Request (PR) that originated it.
Several years ago, when I was a newbie Rails developer, I submitted my very first pull request to an open source project. It had only a very basic description about what it was doing, with no further details about why or how. This was my PR in its entirety:
Here at reinteractive, we care deeply about the quality of our code. We have many processes in place to ensure that the code we produce for our clients is of the highest quality, one of which is a mandatory code review. Before any feature makes it into staging, it must be reviewed by at least one, and preferably two, other developers.
To quote Wikipedia, a code review is a systematic examination of source code. It is intended to find mistakes overlooked in the initial development phase, improving the overall quality of software.
