Embedded Development

Continuous Integration is the idea of running a full build every time someone on a team publishes new changes to source control (such as git).  The idea of setting it up allows for greater visibility into changes, by finding which build exhibits problems and which doesn't as every build happens immediately following a change in source.  This process allows QA to quickly and easily track the life of a bug. By marrying the CI server with other tasks such as Unit tests to check on the system, we get a higher level of confidence that the code under test is stable.  A competent CI system can run several tasks that are often viewed as a drudgery by developers to try and run at regular intervals.  Unit Tests, Integration Tests, code coverage reports, profiling, memory consumption reports, and quick / easy build deployment with automated publishing are just some of the common tasks a Jenkins server can be found doing. As we're embedded developers, we often will have to target both iP

As I'm heading towards discussions about C++ and some cool practical knowledge things for use in Embedded software development, I feel it's important to highlight how we got here by looking at the history of this science.  Let's start by defining Computer Science.  Computer Science is not about coding, programming or software development.  Computer Science is the study of automating algorithmic processes that scale.  Algorithms occur in nature, as everything from how the stars gather together to form galaxies to the spots of a leopard or freckles on a child.  All obey natural laws that are defined within the confines of flow dynamics and were discoveries made possible by algorithmic interpretations made by Alan Turing.  A computer is merely a tool in the same way a microscope is, a tool to observe and work with the natural world by viewing and controlling algorithms. So how did we get to this modern world?  Let's look at where the term "Computer" comes from.

It is time to dive into some software knowledge.  We're going to start by talking further about the tools described earlier and then get into how to work on the software of our practical project "magic mirror."  So let's start: Very often programmers, project managers and industry vets will go on about how much cheaper it is to fix a bug earlier in the software development lifecycle.  The thinking goes that if you equate money with the amount of time it takes to fix something multiplied by the number of people required to fix it you arrive at a logarithmic increase of cost for each stage of the development lifecycle. Over and above the cost of fixing bugs argument, personally, it takes me longer to fix a bug if I have to do a mental context switch and relearn code that I wrote.  The longer the time frame between when I developed code and when I am faced with fixing a bug in it, the harder I feel it is to come to the same level of competence.  Also, maintaining code