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.
Several weeks ago I tried to predict who would win the World Cup. I faced this interesting problem I want to share: how can we relate the outcome of the World Cup with the strength of the teams? Let me explain it better: How can we account for the fact that some “lucky” teams play easier matches than others and thus most likely will arrive to a better stage?
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.
In the past few weeks I’ve been using a new tool from Adobe that has significantly streamlined my workflow. The tool is called Parfait, and it takes a few of the most annoying elements of front end web development and makes them extremely easy.
Software development and software engineering are booming right now. Engineers are in high demand and commanding high wages. There are simply not enough software engineers available to fulfill the needs of companies looking to build applications and services.
While it seems demand for software developers will be strong for the foreseeable future, how long will it be before these engineers are replaced by the very software that they are tasked to create?
If there’s one rule to remember in iOS native programming, it is this: UI components can only be properly manipulated on main thread. Keep this in mind and I’m sure it will spare you from headaches in the future.
Let’s dwell deeper.
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.
I am always writing small tools to help me out on a daily basis. Sometimes shell scripts, but
other times I want something a bit more complex. When I need more than a simple shell script, I like to leverage ruby for its vast library of gems which can greatly accelerate and simplify the task of building these helpful tools.
This post will give an introduction to writing your own CLI tools in ruby and packaging them
as a gem.