For the past year, I’ve been working mainly with AngularJS and before that Ruby on Rails. I’ve never heard of Meteor until a few weeks ago. I am intrigued by the idea of tightly connecting the client and server together in a synergistic manner that allows for fast responsiveness, which is what Meteor is all about. I decided to go through Meteor’s tutorial online and get a feel for why the framework differentiates itself from other current technologies. From a very high level perspective, Meteor is a very good solution for quickly building an application from the ground up and provides some cool features out of the box.
It is a new year and I can exploit that to write a post proclaiming how
something ought to be done in 2015. We can use the new year to discard last year’s practices and mistakes as “the old way” and start fresh from lessons that we’ve learned.
The interesting (and also most frustrating) part about building frontend apps is
how fast the landscape changes. The tools, libraries, and frameworks that you
use today might not be the same as what you’d end up using on a new project only
a month from now. While we’ve ended up with this culture of adopting something
new as soon as someone posts that the “old” way is “dead”, I’ve found a few
pieces of the frontend stack that I do not plan on switching out anytime soon.
I would also like to preface this with stating that this post is highly
opinionated. The opinions expressed here are mine and formed through my own
experiences. These opinions may not reflect what I end up doing in practice, nor
does it reflect on what others at Grio may choose or use.
Continuous Integration at Grio
In the same way that testing code is more and more becoming table stakes for modern software projects, continuous integration is increasingly becoming standard on projects of any non-trivial degree of complexity. Here at Grio, we leverage continuous integration whenever possible, in order to eliminate time spent performing routine deployments and tracking down integration issues.
On a recent project I was tasked with creating a private CocoaPod to be used by several internal iOS applications. As I did my research to do this, I found that the information was spread across several sites and not 100% clear (the CocoaPods site’s documentation could use some love in places). I am taking this opportunity to assist those that follow to create, organize, test and distribute a private Pod. I’ll also throw in a few tips for general pod development.
How to Merge Code
Below is a guide that I wrote for a recent project explaining a git merge workflow on Github. Often times, when you develop a new feature, you will create a new branch off of master called a feature branch. On the feature branch, you might have many commits to save your progress, or when you complete certain milestones of that feature. Once you finish the feature, you will want to merge this branch back to the master branch. However, you might not want all your commits to show up in the git log history because they were only for development purposes. We can overcome this issue by using a feature of git called interactive rebasing which allows you to squash certain commits and customize the commits that will eventually show up once the branch is merged to master. I have described the steps to achieve this outcome below.
Table of Contents
This guide explains how to develop and commit your code using git and GitHub. A developer should create a feature branch when developing new code. In the feature branch, a developer may commit multiple times during development including making changes based on comments from a code review. When development is completed and the feature branch is ready to be merged in to the master branch, the developer should squash the commits in to one, so that the git log history is kept clean.
We’ve been working with Feed.FM, which allows you to quickly integrate their web-radio hosting service into your Android app! You’ll be able to Play, Pause, Skip songs and switch playlists; we’ve abstracted all the nitty-gritty details for you.
Creating Something Out Of Nothing
The task of creating something out of nothing is perhaps the most challenging aspect of a designer’s job. Beginning a new project can elicit apprehension about how to proceed and feel intimidating. It is comparable to a writer sitting at their desk, staring at a blank page, waiting for that inspirational first word or sentence to come forth.
Over the weekend I made performance optimizations to an internal web app that we use for time tracking and invoicing. The app runs on tomcat and is built using grails 2.4.2. Grails 2.4 included some major changes including asset pipelining. This is the first time I’ve tuned a grails app, and I had to do quite a bit of web crawling in order to find my way. I thought I would share some of the helpful tips I encountered, parts of the configuration I used, as well as some dead ends that could waste your time.