In the past we would often treat a server as a machine which has a variety of roles. A single server may be responsible for serving web content, email, processing background jobs, and even hosting a database system. Your application is really only one of the many things that runs on that machine.
A common way to describe requirements on Agile projects is through the use of user story mapping, and, as a result, user stories. This post will not cover this process, but rather the process of taking an existing set of user stories and leveraging them within our development workflow to ensure that an application is built as accurately and efficiently as possible. To this effect, we will set up tools (Rails, RSpec, Capybara, FactoryGirl, and Guard, to be precise) for implementing our app using behavior-driven development. Structuring our app in this way gives us much better odds of producing robust, low-defect code that delivers on the requirements we set out to build.
I work from all over the place: Home, on public transit, the office, coffee shops, etc.
A big challenge to developing android apps in an environment where my laptop and phone are on different networks (wifi vs. LTE, or laptop tethered through phone) is the inability for my phone to see the API server that is often running locally on my laptop. Here is a simple tip to allow your phone to hit the backend over ADB and a usb cable.
To get a better handle on Erlang’s behavior, I decided to install a popular set of tools for debugging and performance profiling: EPER. I think it stands for “Erlang PERformance tools”, but it could also mean “Everything Proves Erlang Rules” or “Egrets Prefer to Eat Robots” or really anything for that matter. One thing is for certain, however: getting these tools built and running on Mac OS X was fraught with danger and build errors.
Many people know about services that allow you to ping your website to be sure it’s always online. The idea behind those is that they check every 5/10 mins sending a GET request to the given website and if they get an answer 200 they send you an email.
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.
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.
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.
Recently, I had the opportunity to work on an exciting in-house project for Grio called Filedart. This service, which will launch in the near future, affords the denizens of the web the ability to effortlessly upload content to the cloud by dragging photos or files to a small icon in their taskbar. After the file is uploaded by the client, the service automatically copies a mini-fied URL to the client’s clipboard. This URL leads to a brand-new, public web hosting wrapper for that file that they can easily distribute to their friends of colleagues to share. The service is free, and users don’t even have to log-in to use it.