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.
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.
One of the main reasons for having coding standards is to keep your code readable by everyone. By enforcing standards and formatting, the code base becomes consistent, and anyone can easily understand the structure of the code because he will be more familiar with what to expect. It is also very useful when a new developer joins the team because once he is familiar with the patterns, he will be able to easily read the existing code, which results in a more pleasant experience.
This is Part II of my series on writing awesome CLI (command line interface) tools using ruby (Part I). In the first part I described how to create your project layout, add an executable binary, and get started. In this next part I will cover:
- How to structure your code to be usable as both a tool and a library
- Building your CLI frontend to your library.
Here are some of the JS libraries that have made my JS development life much easier. I know that libraries change and new ones sprout, but currently here are a few that I have kept in my toolbox.
Let’s face it, creating web graphics takes time and is often tedious, especially if you have to slice images from detailed web page layouts. Sometimes it’s even necessary to copy and paste graphics from a Photoshop layout into a new Photoshop document just so you can isolate graphics and save for web. Recently I began experimenting with creating web graphics automatically from Photoshop layers using the new Adobe Generator feature, which was released in Photoshop CC version 14.1 (to check your version launch Photoshop and go to the menu and select Photoshop/About Photoshop and this will open a panel that includes the version number). When Generator is turned on it will monitor the file you’re working on and generate web graphics based on how you name layers. The cool thing is that as you continue to work in Photoshop and make changes Generator will automatically update assets.
Heroku is one of those really great tools to help you get started fast with hosting. They support a variety of stacks and save you blood, sweat and tears when it comes to deploying an app. But what about those times where you need to mess with filesystems or have custom binaries that you want to run? How about just having more control of your servers?
As a consultant, approaching new code bases is something that happens every day. As exciting as it sounds however, working on many different projects can be really tough. This is because in many occasions we are not provided with all the details that we need, but we just requested to fix something that is broken.
What makes these tasks difficult is that the data and code structures can be very large and not very intuitive. Also, it might not be clear who holds the knowledge on them, or in some cases the knowledge can be even lost; for example being held by people who left the company.
This is for anyone who has to build an AngularJS application that needs to support IE9 and below.