Category: Uncategorized

It seems that I make this post every so often. My last post was made all the way back in February. That was already 5 months ago. I don’t think that many people “follow” my posts, but I know there are some that use RSS. Ultimately my plan is, as always, to have quality content that people find informative. I just get sidetracked at times from making blog posts.

I have a regular 9-5 development job that takes up most of my time. When I come home from that job I also write software. I usually choose things that are outside of what I do day to day. Projects that help expand my skills. After I build something, I then write it up here. I have been doing that since 2011.

I also do contract work, author books and video series. These account for the stretches of time I do not post anything. This last stretch is no different. The good news is that I have some open time and plan on making more posts. I know this is completely a first world problem. The point I want to make is that I do care about the content that is on my site. Quality is always the first concern, but I know that quantity matters as well. There is no point in making one post every two years.

What type of posts? Well, for starters I will finish my functional JavaScript videos. Then I plan on making more Docker posts. I recently had to setup Docker on a new server and found out that Docker has changed a lot since the last time I made a post.

I have not posted in awhile, but I have been busy. I find that this is a recurring theme with my blog. I make a string of posts on time and then I get caught up writing code. Back to the post at hand.

Over the holidays I spent some time to learn Swift and write an iOS app. Trecco was the app that I built. It will record a voice note, use IBM’s Watson to transcribe the voice note, and then save it to a Trello board as a card. The name Trecco comes from recording a note and saving it to Trello.

I do recommend that you download and use it. Especially if you use Trello. Furthermore I am using this opportunity to create a new book! While I do not have a title yet, the book will focus on building a Swift iOS app from the ground up. This means starting from an empty folder all the way through submitting it through the app store. Every part will be covered.

I am hoping to release a sample chapter and video, so you can get a feel for what the book will be like.

Technically this one is late. I did not account for all the things I would have to do on Christmas eve. Picking a subject and writing around 200 words on it every day for eleven days was more difficult than I expected. I had chosen some subjects before, but 3 were pretty much day of selections.

I wanted these posts to be about the things that I learned or focused on for 2015. I think the main thing I tried to do this year was focus on programming more functionally. The more I learn about functional programming the more I like the way it makes you think. This is especially true from a testing point of view. When writing code I can easily create a lot of little edge cases and then you have to write tests for all of them. If I change how I think about the problem I can usually cut through all of that and make a simpler codebase. I think functional programming does that.

The other thing I have embraced is Docker. I love the ability to have my application running exactly the same in development as production. In my mind this is another simplification of development like functional programming. Once I have it working exactly how I want it in development there is really no work to get it working anywhere else.

This last year has been about writing and developing simpler software. I am not even close to where I think I can be. In 2016 I plan on continuing this. Hopefully you will come with me as well as you read my blog!

Today we are going to talk about a subject that relates to Docker and how projects are setup. A few years ago, managing a software project was more difficult. Every piece of software that is not a few lines of code relies on other software usually written by someone else. Managing the versions (if the software was even versioned!) was very difficult. In .NET things went into the GAC so that you had to prep your environment before deployment. PHP was whatever you downloaded and threw in your project. JavaScript was essentially the same. I remember many times downloading jQuery for a project. I will cede that many of these methods were not the best ways at the time.

Things started to get better. Python has virtualenv. This allows developers to virtualize entire dependency stacks. You can work on the same project with different dependencies on the same machine. .NET has NuGet. In addition to embracing NuGet Microsoft has started to break large monolithic dependencies into small packages. Look no further than ASP.NET 5 to see this in action.

Software projects are now composable. This is a key concept that I felt the entire industry forgot about for a long time. Unix has a philosophy of small sharp tools. This means creating some small tool that does one thing and does it well. We seem to have come full circle back to this idea. We do not want large libraries that try to do everything, we want one tool that does something well.

I have one aside to this. Pin your dependencies! I see many projects, I am looking toward Node.js projects, where dependencies are loosely defined. For example a dependency referencing anything over version 2 when the latest version is 4. If you built your project with version 2.2.0 then explicitly define that in your dependencies. Small rant over.

One of the reasons why I have been doing so much Docker stuff is that I feel this is the current step of this idea. Docker is a virtualenv that is a little larger in scope. I know that the idea of containerization is not new. The tooling and by extension, the ease, is new though. We have made development environments a commodity. We can wrap an entire production stack, download it to a new system, and then just start it up. I am excited to see where we as a community will go next.

Yesterday we finished the post with questions about how to store and use state. All applications have state and have to manage state otherwise they would be static documents. This becomes even more difficult if we try to make our application functional. Functional applications try to minimize state changes as much as possible. How do we do this in a functional application like React?

The best way to visualize what functional state looks like is to imagine a series of actions with facts. Each fact is a small immutable piece of data. We had a simple example last post about a list of items. An action with a fact would be, “here is a new item”. The action would be add an item and the fact being the actual item. An application then is just a stream of actions with facts.

This idea allows us to reason about state using the idea of a reducer function. A reducer function is a way to summarize or aggregate a list of data. In our example each action will be run through a reducer which will then summarize what the state should be. This means that the list is being built as the application runs.

A great benefit of this is that we can now store each action with its data and have a complete picture of what happened. We can easily create an exact state we want to test or even playback errors.

When using React there is a great library that we can use that implements state in this way. It is called Redux.

My hope is that I have explained this enough. If not here is a great video series that goes more in-depth with creator of Redux.

I would say that I am like most programmers, in that I have been trained to program in an imperative way. There is nothing wrong with this.

There is another programming paradigm and that is functional. If you have only programmed imperatively, functional programming forces you to reason about your application differently. Functional programming relies on the concepts of immutable data and creating no side effects.

I am not making this post to declare a winner between these two. I feel they both have their places in this world. I do feel very strongly that knowing both is strictly better than just knowing one of them. Especially if the only one you know is imperative.

Let’s look at a short functional vs imperative exercise here. We will use JavaScript, which the language itself is almost a mixture of functional and imperative ideas all thrown together, for this example. The main concept we will look at here is not modifying state.

We will compare JavaScript’s array methods slice and splice. slice is functional in that when executed it does not modify the array. splice is not because it modifies the array. This may seem like much, but it is a very important distinction.

Imperatively the thought is that we need to remove an element from the array. That is exactly what splice does. Functionally we will create a new array with the elements that we need. There are no side effects by doing this.

We will continue in this post covering system related content. Not that long ago it was very difficult to have a development system match a production system. The task of making your local system match any other build was essentially impossible. There were steps you could take, but there was always a small amount of differences. These differences could introduce issues. Those issues would then be very difficult to track down. The cliche, “it works for me”, comes from this.

Docker is a great start at mitigating this. In fact, I would say a properly designed Docker setup goes almost all of the way toward fixing those differences. The next step past Docker is using something like Vagrant.

Vagrant is just a wrapper around VirtualBox that can automate the creation and provisioning of virtual machines. Vagrant allows us to have, for all intents and purposes, a version of production on our local machine.

Are you using Ubuntu 14.04 for production? Use Ubuntu 14.04 for Vagrant. Provision it with the same tools and configurations. At this point, to your application it is exactly the same. You will never run into any new or strange bugs because of a difference between environments.

If you look over my post history (pushing 5 years already!), hopefully you will see a growth in my projects. This is something that I have really tried to embrace because I personally have been bitten by these issues. My last project included a way to completely run it locally in Vagrant, in addition to be being able to push to the cloud. I also plan on updating some of the more popular projects to utilize Vagrant as well.

Today we will are continuing the topic of system orchestration. When using service discovery you need to be able to register your services for them to be discovered. This is difficult in any case, but even more so with Docker.

For the most part I subscribe to the one process per container paradigm. If we need a service registration process that runs along side the container’s main process then that immediately breaks one process per container. In addition to this every container you spin up will need to be a custom container. You won’t be able to just grab the official Docker image of anything.

This is where Registrator comes in. Registrator automatically registers your container as a service with a few service registries, Consul being one. Registrator does this by listening for container start and stop events. It allows us to bring up containers and have them automatically added to Consul.

I recommend going through the quickstart. You can have this going in just a few minutes.

We are going to move away from JavaScript for a few days. The last few months I have been making quite a few posts about Docker, Ansible, and Vagrant. The main reason for this is because I recently moved my blog from a Linux server that was setup by hand to some Docker containers that are automatically configured.

In this post I will touch on Consul. Consul is a service discovery tool. Service discovery allows us to uncouple the creation and linking of Docker containers. In my setup I felt that my containers are too dependent on each other and the Docker-compose definition. This makes scaling horizontally very difficult. In addition to this adding new services, like say another web server for proxying is harder than it should be.

This is where Consul comes in. This means that when a container comes up it can query Consul and find all the web servers it needs to know about. The container can also be alerted when a new container is created and react to it.

Unfortunately I do not have any real examples other than you can play around with Consul in Docker with this command.

I have been away for the last two weeks on a wonderful trip to Europe with my wife. The planning, the actual trip, and the recovery has slowed down the writing of my posts. I was hoping to have the Docker post done before I left, but it did not work out.

This is not a travel blog, but I do want to note a few things I learned on our trip. The things I learned are not what spots to go see as people like Rick Steves already has that covered better than I could ever do. They are more specific to things about each city or country that would have been nice to know. Here is where I went and what I learned.

Google Maps

I just want to make a quick shout out to Google Maps. It was indispensable on our trip. First and the most obvious was using it to get around every city. We would use GPS and the map of the city to plan out a walking path and/or determine if it was better to call an Uber. Second is Google Maps public transportation. The app will show you which subway line to use (using the correct color), which direction, and how many stops. We would search it and then take a screenshot to use later. This was very useful. Here is an example.

Airbnb in Europe

We used Airbnb(referral link) for every night except for the final night. Airbnb gives you the best apartment and location for the value. Instead of staying in a hotel that looks like every other hotel you have stayed in, why not stay in a local’s apartment? I recommend only using the listings that have good reviews as a stay could be ruined by a poor host.

An important thing to remember when booking is that you will not have the exact address of the apartment. You will only have a neighborhood (although it is precise enough to make plans). It is not until you have booked the apartment will you receive the address.

Before booking you should ask about things like towels and if you can store your luggage after checkout. I found that most hosts try to be cooperative and flexible. Once you have booked and the date is approaching you should message them to let them know an approximate time a few days before. Finally let them know when you are close, for example you are at the train station, on the day of.

London

We flew to London from O’Hare on Virgin Airlines. I would definitely recommend Virgin. I have flown a few times before and Virgin was the best airline I have used. It was the best 8 hours I have spent in an airplane in my entire life.

Getting around London

The Tube system is great in London. I recommend purchasing an Oyster card as it will halve your fares and has a ceiling on how much can be charged. We did not get one at first and because of this we wasted many pounds. Continue reading “A trip to Europe”