The seventh week at QA began with me completing a couple of tasks using a software known as Docker. These tasks included installing Docker, creating a Jenkins container from the local directory, and then creating a Dockerfile.

Installing Docker and Jenkins were very simple tasks. Obtaining Jenkins in the local directory was done with the pull command. The task was then completed simply by running the Jenkins container and checking that the software had properly installed.

After these introductory tasks, I was then assigned a project that involved creating various Dockerfiles and launching them simultaneously with the use of a docker-compose file. At first I found that the Dockerfiles were harder to write than the Puppet modules I had written before, but as I got used to the syntax and the different commands, I quickly grasped what to do and completed the project at the end of the eighth week.

The tasks for the project included making Dockerfiles that installed different software. The software that needed to be installed included Jenkins, Jira, Nexus, Urbancode Deploy, and Zabbix. Zabbix needed both a server and an agent to be installed. Most of the software was simple to install and a couple even just needed an archive to be downloaded and an installer file run.

I ran into many problems while completing the project, but most of these were simple mistakes that were fixed in a matter of minutes once I noticed the problem. The main software that was difficult to install was Urbancode Deploy. This could have been simply due to the fact that I had never used it before, and everyone had problems installing this specific software.

This week will have a main focus on the quantum suicide thought experiment, and how it differs in both of the main quantum mechanical interpretations.

Quantum suicide is essentially the Schrodinger's cat experiment, from the point of view of the cat. For this experiment we will define an event as a chance that the atom has at decaying. Assuming that there is a 50% chance for the atom to decay, then from the Copenhagen point of view, after the second event, there is a 75% chance that the atom has decayed, and so the longer the cat stays in the box, the lower the chance it has of surviving the next event.

However, in the many-worlds interpretation, the universe splits after each decay and each subsequent decay still has a 50% decay rate. Events in this interpretation are thus not dependent on previous events like they are in the Copenhagen interpretation. This leads to the cat always having a 50% survival rate for the next decay, no matter how many decays have occurred before.

At the beginning of the fifth week at QA, I found out that I was to be doing DevOps. I started the path of DevOps with a task that involved me going through a set of tasks from a program called Puppet Quest. Puppet Quest is a guide to Puppet and was very helpful in learning the software. Puppet is a software that runs modules hosted on a master, these modules are run on agents, and perform various tasks, such as installing software.

After I had gone through all of the tasks in Puppet Quest, I have to make a module in Puppet that installs Java onto an agent machine. Puppet runs by using blocks of code to perform various tasks, such as executing a command, or checking a file is in place. Using those two types of block, I was able to get Java to install on the agent machine. First checking that the .tar file was in the shared directory and then copying it to the place where it was going to be unpacked using a file block. Command lines to unpack the .tar file were then implemented using exec blocks. Once the module was completed, it was pushed to an agent machine which ran the module and installed Java.

The next task was to create two agents, one which would install Java and one which would install Java and Maven. The Maven module was very similar to the Java module, but did not need command lines for the compiler. Getting the agents to install a unique set of modules was fairly easy. All that needed to be done was to edit a site.pp file to include the names of each node (agent) along with which modules were to be installed.

In the middle of the fifth week, we started a group project on Puppet which was to last until the end of the sixth week. The first aim of the project was to install several software through modules using Puppet. These modules ranged from being very quick and easy, such as Git, to being fairly long and arduous, such as Nexus. The process needed to be automated as much as possible, and my group managed to get it so that when all the files are in place, you only need to double click one file to set up the master and the amount of agents specified in the vagrantfile, and install all of the modules on the agents. The next part of the project was to install and use Puppet Enterprise and use that to install the modules. This took a while to complete and there were a few problems, but we eventually managed to get this working, although we could not find a way to get Puppet Enterprise to automatically accept certificate requests from the agents. The following task was to set up MCollective. This was an easy task as most of the things needed were already installed with Puppet Enterprise. The final task for the project was to set up Zabbix. This took a while, but there were not too many problems with it. My group set up a Zabbix server and agents, and provided access to the server through the web GUI. The last thing to be done in the sixth week is to give a presentation on the project.

In the last technical blog, I discussed some basic concepts of quantum mechanics. This time, I shall expand on the Schrodinger equation and introduce the many-worlds interpretation.

As I mentioned in the last post, the Schrodinger equation is one of the main equations used in quantum mechanics. It is used to describe a particle in full detail. However, as the equation is a wave equation, this leads to the particles becoming probabilistic in nature. The modulus of the wavefunction gives the probability for a particle to have the characteristics described in the solution. Leading on from this, it is easy to deduce that there are many solutions to the Schrodinger equation, an example of this being the many possible solutions to the Schrodinger equation for a hydrogen atom, each solution represents the electron in a different energy level.

The many-worlds interpretation describes the probabilities as the universe 'splitting' into many different paths. For each quantum event in which there is a choice to be made, the universe splits into a number of paths equal to the number of possible outcomes. Each path is real and is completely separate, no longer interacting with each other after the split. Each of these worlds branches off orthoganally to all other worlds, making travel between them impossible. I find an easy way to visualise this is to think of a line, constrained to one dimension. You then add another line at a right angle to this line, and while traveling in the direction of the first line, you cannot travel down the second line. The same would happen with a third line, this time added in the third dimension, and the process continues for however many lines you need.

Schrodinger came up with a thought experiment to explain quantum mechanics. Known as Schrodinger's Cat, the experiment is set up as a cat in a box, with a vial of poison and a radioactive atom. The vial of poison is set up to break when the atom decays, the box is closed, and the cat is quiet. The idea is that the observer has no idea what is going on inside the box, the cat could be either alive, or dead. The wavefunction for the cat then has two solutions, known as eigenstates, one for each possible state. The Copenhagen interpretation states that cat is a wavefunction while not observed, and is thus neither dead nor alive, but that once observed, the wavefunction 'collapses' and the cat obtains a definitive state. The many-worlds interpretation states that the cat is a superposition of universes in which some it is dead, and some it is alive, thus the cat is both dead and alive. As time passes, the atom has extra chances to decay, at each of these chances, the universe splits into two, one world where the atom has decayed and the cat died, and the other where the cat has survived for another chance. Both of these interpretations show that the longer the cat stays in the box, the less chance of survival it has. However, things get a bit different when viewed from the point of view of the cat, and so in the next post, we shall delve into quantum suicide and see how.

The end of my second week at QA consisted of a project where I had to create a virtual machine using Vagrant. I had to configure the vagrantfile so that the virtual machine would automaticall install various programs. These programs included ones such as Java, Maven, Git, Jenkins, and Jira. It was fairly simple to set up the first four programs. Java and Maven simply needed the source file to be in the same directory as the vagrantfile, Git was downloaded and installed, and Jenkins was unpacked into a folder and ran from there. To allow the user to access Jenkins, I then had a line of code that copied the password to the desktop into a file that the user could then open and copy from. Jira first needed to be installed manually, then it created a file that recorded which options were chosen for installation. Using this file, I was then able to edit a few lines of code to enable the virtual machine to automatically install Jira using the settings that I had used previously. The file that it had generated needed to be placed in the same directory as the vagrantfile.

Although this was the main task of the project, there was also a bonus task of linking together Git, Jenkins, and Jira so that they would work together automatically. I was able to configure downloads for the plugins that would allow Jenkins to interact with the other two programs, but found it a bit more difficult to find ways to connect Git and Jira to each other, and back to Jenkins. I believe I would have needed to figure out a method to control a web browser in order to complete those final tasks. Unfortunately I did not have enough time to figure out how to complete this task, which is a shame, as I could have then set up Jenkins without the need to copy the password to the desktop.

The third and fourth weeks consisted of learning about Enterprise Architecture (EA). This consisted of creating many different types of documents, and going through various activities. This work was completed in groups. The aim of the course was to create an EA for a fictional company. To start with, we had interviews with some of the higher ups in the company, to figure out what was going wrong. We then moved on to interviewing members lower down, in order to gain more specific details that the more senior members did not know. Some of the documents that we created were a Business Model Canvass, a Terms of Reference, some Business Process Model and Notation diagrams, and a few others.

I unfortunately fell ill and missed the first half of the second week of EA, although this consisted of activities such as making and holding a workshop, creating User Stories and Use Cases, which are methods of explaining what goes on in a process, and various other tasks. The second half of this week ended with each team giving a presentation on what they had done, and a test on the EA course that we had just undergone.

At the end of the third week at QA, we were able to choose what specification we would like to go into, with the choices of Cloud, Mulesoft, DevOps, and Pega. As I had enjoyed learning about it previously, and it seemed the most interesting, I decided to choose DevOps. I believe we are to find out at the end of the fourth week or the beginning of the fifth in whether or not we were able to follow the path we would have liked to.

Welcome to the first of four posts that are designed to develop an understanding of the many-worlds interpretation of quantum mechanics. Quantum mechanics is a vast subject in itself, and while the Copenhagen interpretation is taught most frequently, I personally find the many-worlds interpretation to be easier to understand and a more logical approach.

But before we delve into the specifics of quantum mechanics, we should first look at the connections to classical mechanics, namely decoherence, wave-particle duality, and the uncertainty principle.

Many people will be familiar with the concept of wave-particle duality, most commonly exhibited in the diffraction pattern of a beam of electrons when fired through a double slit. However, it is also present in light waves, which come in quanta of energy, known as photons. Many experiments have been carried out in order to determine whether light and electrons are definitively either a wave or a particle, but depending on the conditions, both answers can be achieved. Just look at the diffraction pattern for an electron, and it seems to be a wave, but look at which slit it goes through, and it behaves as a particle.

A key term in quantum mechanics is operators. Operators are simply a function that relates to a classical observable. For example, the position function in the x direction is given simply by x, but the momentum in the x direction has a partial differential in the equation. The uncertainty principle states that when two operators don't commute (it matters in which order they are applied), then these two observables must always have a product uncertainty of ħ/2. So position and momentum in the x direction would be an example of this, as it matters when a differential is applied. The most difficult thing to understand about this is that this uncertainty is a distinct property, and not a result of inaccuracies during measurement.

Most people who have heard the term quantum mechanics will have also heard of the Schrodinger equation. This equation is used to describe the physics of a quantum mechanical particle; it is essentially the quantum mechanical equivalent of Newton's Laws and conservation of energy. The Schrodinger equation comes in the form of a wave equation, and consists of a wavefunction, denoted by the Greek letter Phi, which precisely describes a particle, and a few operators. Operators describe a physical observable, everything has one, position, momentum, spin, energy, the list goes on and on. The Schrodinger equation employs two different energy operators. One side of the equation contains the Hamiltonian, denoted by H, which in turn consists of the Kinetic and Potential operators, which again consist of even more basic operators, moving down to just position. The other side contains an energy that depends only on time, denoted by E. A solution of the wavefunction that solves the equation is then found, and this describes the particle in varying degrees depending on the complexity of the Hamiltonian. The second equation here shows the expanded form of the time-independent Schrodinger equation. Time-independent simple means that we are assuming the energy to be constant over time.

Quantum decoherence is a theory that brings together many of the phenomena found through quantum mechanics. Put simply, it is an effect where many quantum particles in a system coalesce into an object that follows classical laws. Expanding on this slightly, when quanta collide with each other, they form an entangled state, and this reduces the amount of interference that they can experience, and so these quanta start to obey the classical laws of physics. This is showing that in fact, there are no classical laws, just quantum laws adapted to a large scale. This also explains the diffraction pattern of the electron, while passing through the slit to produce the pattern, there is no decoherence, and so the electrons are free to interfere with each other. Yet when a detector is placed nearby, the huge system of quantum particles affects the electrons in such a way that forces them to no longer interact with each other, thus displaying particle like properties[1]. So instead of the environment affecting the system, it is actually the system affecting the environment, with the electrons joining the system and so being in an environment that allows no interference.

1. Joos E. Decoherence Website [Internet]. 2012 [cited 21 September 2016]. Available from: http://www.decoherence.de/

The first week and a half at QA Consulting has gone quite well. I have made new friends and learned new things.

The first week was focused mainly on Java, and while I had done projects in this language before, I only ran the program through the command prompt. Using and learning Eclipse was a new and fortuitous occurrence, for I was able to quickly adjust to the ease in which a class file could be compiled and ran. The syntax highlighting and auto-complete commands were also new and highly useful. With the help of these, I quickly re-learned what I already knew of Java and had the first four tasks done within the first day.

But then came the problem, although I had done work with Java before, I had not delved much into using multiple classes. While the concepts are familiar to me, the implementation was not. The topic was broached only briefly during my learning, and practiced a small amount, but not significantly. As such, I had some trouble with task 5, which involved creating multiple classes and objects which would all interact with each other.

After a couple of days of scouring the internet for information and examples, I became more accustomed to the use of objects, and when it was announced on Thursday that we were to have a test the following day, I felt confident that I could employ the use of these methods that the test was sure to contain.

And indeed, come Friday I was able to create a program that while inchoate, was functional to the point that I had made it. The only aspect that caused my final project to be incomplete and non-functioning was the lack of time permitted to the task. I worked with barely a pause and yet only achieved perhaps a 50% completion.

During the second week we started to learn about DevOps, in which I had no prior knowledge. To start with, we had to look up the uses of various software and create a Pipeline diagram for a generic system. We were then tasked with creating an Ubuntu system using a program called vagrant that assists in the installation. I found these tasks to be fairly easy.

The second day consisted of creating a CentOS virtual machine without the aid of any programs such as Vagrant. I found this task to be relatively simple and did not have much trouble with it. We then used the terminal to do a myriad of tasks, including making folders and files, and generating a new admin user.

The next day involved installing and running programs. This was a bit tricky as the files first had to be sent to the virtual machine, and then installed via the console, for which we used PuTTy. The programs were all new to me, but after some perseverance, googling, and asking my neighbours, I managed to finish all the tasks.

We have been told that on Thursday we are to start a project which will carry through to Friday, and that we get to finish at lunch time on said Friday!