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.
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.
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.
D3 is so awesome. The other day a friend showed me Spotify Serendipity project, which used D3, and I was floored by the beauty of how visual data can show so much. A picture is truly worth more than a thousand words.
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.
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.
As science and software advances, we have the ability to fuse the two together to discover and treat diseases in the hopes of prolonging life. Tasks like sequencing the human genome, isolating genetic markers, and handling large amounts of data are now all possible through a scientific field called Bioinformatics – the study and process of biological data through software, engineering, and mathematics.
At the lastest Apple WWDC conference, Apple decided to suprise it’s developers with introducing a brand new language called Swift which will be used going forward in development all Mac and iOS applications. The good news for all Apple developers is that it is totally integratable with all existing Objective-C code. Another great positive for developers is that it also runs on the current version of iOS, iOS-7. Developers will still need to wait for Xcode-6 to come out of Beta before they can submit full Swift apps, but they will not require everyone to be running the latest iOS.
