I have another video series ready from Packt Publishing named Build Complex Express Sites with Redis and Socket.io. This course builds on the foundation from the other course I built for Packt Publishing earlier this year, The Complete Guide to Node.js.
It starts off by covering what and why of Redis. Then goes to building Express sites using Redis. After that, the course jumps to using Socket.io to build real-time sites.
I have just recently finished creating a video series for Packt Publishing named The Complete Guide to Node.js. The course focuses on taking someone completely new to Node.js and giving them a great foundation to start building real applications. There is a good mix of theory and practical application as the viewer goes through the course. First, an idea is introduced and explained. Then the idea is applied.
While I was waiting on Packt to send me some finalized videos as a preview, I received a twitter endorsement for the course.
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.
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.
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.
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.
We are going to continue our journey into the functional paradigm. In many posts I have made it clear that I like React. Which leads us to the question, why?
In the simplest terms, React is functional. It is best utilized when functional ideas are used to design and build components. This forces most programmers to have to think differently. Think in React, as it were.
What makes React functional? Functional programming gets its name from Mathematics.
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.
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.
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.