Healthcare in the United States costs far more than in any other country in the world, and yet the quality of the care Americans receive is rated 11th among first world countries. The high price of healthcare burdens employers, increases the national debt, and historically has left many without access to healthcare. We all want cheaper, better healthcare, but it is difficult to agree on specifics of how to get there. Why is healthcare so expensive?
At some point in March I received an email stating that I had roughly $40 in DigitalOcean (referral link – get $10 credit!) credit which was going to expire on the first of May. I wanted to do something cool, learn new things, and leverage a large portion of my remaining credits.
My initial plan was to spin up a CoreOS cluster, as it is something that I have had my eye on. Once running I would get Kubernetes running for management/orchestration of deployed applications. During this journey I learned a lot of new things, had a lot of fun, and even got a cool cluster running. However, I never made it to the end goal of Kubernetes in time for my presentation (and this post). Looking back, I don’t consider this to be defeat: I learned a lot of new concepts along the way. I can be certain that I will leverage and use that knowledge in the future too!
What is benchmarking?
Benchmarking is the process of measuring performance for a piece of technology against other pieces of technology. Typically, processors are benchmarked by running programs and software that heavily taxes the system. This allows the processor to truly shine (or, possibly, the opposite). For the purposes of this post, the i5 and i7 processors’ performance were measured in five different categories, each using one test:
The Relational Model & SQL
The relational model was proposed in a paper published in 1970 by Edgar Codd, a computer scientist working at IBM. In previous years, some storage systems had already emerged, but the relational model was first proposed with a strong theoretical basis.
As part of my exploration of a minimum set of devops tools, I’ve been learning how to stack containers full of Rails apps onto the Docker. There are plenty of examples of how to get started with Rails and Postgres on Docker, even one from the whale’s mouth, as it were. Working from this example, it was pretty clear to me that one of Docker’s major strengths is that it makes it really, really easy to get something running with a minimum of fuss; it took all of about a half day to learn enough Docker to hoist anchor, and even tweak a few things to my liking. One thing kept nagging me about the Docker example, though, and that was a warning from bundler when running docker-compose.
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.