There are a lot of APIs out there, a lot of networking layers, a lot of abstractions, I’m going to offer just one way to start building Swift models backed by a RESTful API. Out of personal preference, PromiseKit will be used instead of callbacks and ObjectMapper will be used to convert between JSON and Swift objects.
Data mining is an interdisciplinary subfield of computer science used to discover patterns in complex datasets. The field has been widely studied since the 70’s since it can produce useful insights that can help to better understand underlying relationships and trends in data sets.
Most projects you will work on will have a database of some sort. For this reason, optimizing your queries allows you to use all that the database provides without having your application try to reinvent the wheel. In this blog, I’ll be using Postgres and Ruby on Rails to demonstrate some ways that you can optimize things. Much of the second section is Postgres specific, but the concepts should apply to whatever ORM you are using. Hopefully by the end you will have learned some new tricks to improve your project.
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.