A popular and effective way of developing a complex application in a team setting is to make use of git feature branches and submitting a pull request to be merged into the develop branch. Sometimes, though, the pull request can become quite large. This may result in a lengthy wait to get your pull request reviewed, bugs being overlooked, and merge conflicts.
These difficulties can be helped by shrinking your pull requests using the following two strategies:
Stripe has a great API to manage subscription payments. Here we take advantage of it to implement recurring subscriptions in Rails 5.
Using the Stripe API means we do not have to store sensitive customer information like (credit card number or CVC), and the APIs are already set up to handle complex cases such as update plans, manage subscriptions, trigger refunds, and more.
Have you ever noticed how many discussions there are online about what programming language or framework is the best? People in forums are always praising one particular language and making fun of those who use a different language. I was guilty of doing that at an earlier point in my career. Ruby was everything, and anything other than Ruby was simply not as good.
Time passed and I came to the realisation that the programming language is nothing but a tool, and the real value of the software engineer is in their problem solving, thereby rendering the programming language used by the engineer simply a tool for solving problems. Different tools solve different problems, and some tools solve the same problems in different ways. With this in mind, I would like to draw a parallel between programming and music.
Recently, our founder and CEO, Mikel Lindsaar spoke at the Ruby Developer Summit on Standard Development. He discussed the role of testing in project work, and talked about when you should follow the textbook approach and when it might be better to relax those rules. You can watch his talk on our youtube channel.
This blog post details my thoughts on how to approach writing tests. To illustrate, I'll be using a Ruby/Rails example as Rails is a framework that embraces the culture of testing. However, I believe these concepts can be adapted to any language.
It’s a difficult question to answer comprehensively and succinctly in that moment. The answer may also vary with the relative skill of the person asking.
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.
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:
So you want to build an app? One of the first decisions that needs to be made is one of time and resources. For a business, it is crucial to know your market in order to successfully launch your product. But what about the App market? Which platform you do you choose to launch to first? Apple? Android? Web?
At this point you might have already considered a HTML5 web app so you can be cross platform and launch to everyone. Or perhaps you decided against it, due to poor performance and not having a “native app” feel.
We’ve recently run usability studies on an application for a financial product where, after a user inputs a couple of screens worth of data, a tailored product solution appears. We had a nice prototype, and all was well except for one thing…
During the usability study, we received the following feedback: the recommendation arrived too fast. Wait, what? Yes, the results arrived too quickly after the user hit send, which made people think that it wasn’t real. Some of the user feedback was “there’s no way it could’ve looked at my data in such short amount of time…”, “I don’t think this is real, because it hasn’t spent any time thinking about it…”, “I wouldn’t trust this product, it made me fill in screens of data but then ignored it all when giving me the recommendation…”, or, in some cases, people were expecting to continue filling in more data and didn’t entirely believe that the screen they were looking at was the solution and not just another screen requiring more information.
Note: This post is intended as a supplement to WTF Just Happened? A Quick Tour of Your First Rails App.