It was 2004. Professional sail racing was undergoing a once in a lifetime transformation. Multihulls and foils were emerging as reliable options of open water sailing. The Round the Word sailing record had just been slashed to 58 days by Steve Fossett on the catamaran Cheyenne, Ellen McArthur was building her trimaran to attempt the single handed world record and every island and interesting sailing route was having its records set and broken. Except Iceland.

Iceland doesn't have much of a sail racing scene. The handful of sailing clubs that exist mostly cater to younger sailors with lasers and optimists. The one yacht club with an active membership hosts weekly races during summer and occasionally organizes other sailing events. From time to time sailing events from Europe arrive in Iceland livening the quiet of the Icelandic yachting life. Particularly from France.

At this time of rejuvenation in the world of sail racing all around the world, it was looking like the first crew to set the sailing record around Iceland would not be from Iceland.

We are “Synir Fokkunnar”. A group of sailors who in 2002 individually joined Brokey, the Reykjavík Yacht Club to get on the water and do some sailing. We each applied to have access to the 26 foot club racing yacht Sigurvon (Hope of Victory) during the summer months which is something the club offered to its members.

Sigurvon already had a crew who took part in the weekly club races. However they graciously offered us, the new guys the option to compete on Sigurvon every other week. We were very happy to accept and started racing every other week, taking turns skippering, navigating, trimming the sails and just being dead weight.

The original crew had broken the mast on Sigurvon racing for first place in the national cup the year before. When they again lost the mast that summer we gave them the nick name “Mastursbrjótarnir” (the mast breakers). Having given the old crew a name the new crew needed one too. Synir Fokkunnar (sons of the jib) was coined by one of the crew when standing on the bow battling the jib in heavy wind and it stuck.

In 2003 whilst watching sailing records tumble around the world and every island having a sailing record set I became cognizant of the fact that noone had yet set a non stop sailing record around Iceland and that it would not be long until one of the English or French crews would claim it just to be the first to do it. Although the sailing scene is small in Iceland it did not sit well with me that an Icelandic crew might not be the first to set the record around our own island.

To try an prevent this from happening I started talking to all the local crews that might have the skills and the means to do this. My dream was to create a sailing race around Iceland similar to the motorboat race my grandfather Einar organized in 1978 and 1979. A sailing race for line honors only to establish the fastest record.

The captains of Besta and Ísmolinn, the most active and competitive crews in Iceland at the time were interested and started exploring options with their crews. Both captains were keen but in the end their crews were not able to commit the time to do the race. We had no sponsors to provide money for winnings, the only win was going to be the bragging rights for having set the record.

I started floating the idea with Synir Fokkunnar of taking part in the planned race. Five out of the six crew members were interested and wanted to make it happen. One eventually had to pull out due to family commitments and so there were four. Me, Arnar, Halli and Haffi.

There was only one problem. We didn't have a boat!

Sigurvon is only 26 feet and designed to be a club racer. Although an overnight sail was an option everyone agreed that Sigurvon would not be a suitable boat for an 800 nautical mile race.

After scouting for a boat to lease in a country with few yacht altogether and no suitable yachts for racing we eventually convinced the owner of one of the cruising yachts to lease us his boat for the race. Snælda.

Snælda is of a Swedish design and intended for family cruising in the sheltered waters east Sweeden where there are lots of islands and beautiful natural harbors. Her owner had fallen in love with the boat while in Sweeden and sailed her solo back to Iceland. He described a sturdy, solid, reliable boat and that is certainly what she is.

With the boat secured we started making practical arrangements for the attempt. Finding sponsors was not easy as sailing get little media attention in Iceland. Eventually though, Haffi’s uncle who owns a food distributing company sponsored us with food items for the journey and got one of his brands McCain advertised on the boat.

Personal insurance, sailing gear, route planning, communications, etc. The next few months were spent on preparations for the attempt. As the crew was new and not well known to each other we held social events as well.

May 14th 2004

Finally the day of the attempt arrived. On the 14th of May 2004 we sailed out of Reykjavík harbor under the watchful eyes of our friends and family and commended sailing around Iceland. The chairman of the Icelandic sailing association officiated the start time and off we went.

The boat owner had handed us the boat only the night before. We had never sailed this boat before. There was not even time for a shakedown sail so we had no true idea of the state of the boat. Right off the bat we had a 30 knot south easterly with strong gusts of wind between the islands around Reykjavík.

Ironically given our crew name the front sail would not unfurl. The trimming lines has been incorrectly threaded and we had to fix that. As we worked our way between the islands the main sail came free of the track and we lost all control of the boat.

In order to regain control we had to abandon the attempt right there and then. We put the engine on and engaged the drive while we fixed the sails. We then went back to the starting line, killed the engine and started the again. This was not an ideal start but in Iceland we say “a fall at the start indicates a good journey ahead” so we kept going.

We got fair winds at first sailing up the western side of Iceland. Then we wind died down and we were cruising slowly towards the Snæfellsnes peninsula.

May 15th 2004

The next day we had good winds and were at the western fjords and approaching Ísafjarðardjúp. Halli grew up in Patreksfjörður and worked on a small fishing boat when he was younger. He knows the area well and has been out there in various conditions.

Haffi however had never done more than the occasional sail at the club before. He was new at sea and had no idea that he was prone to severe sea sickness. Being a medical doctor does not exempt you from such things unfortunately. Haffi had become violently seasick. He did not think he could continue the challenge and wanted to get back ashore. We contected a local sea rescue team and they agreed to meet us close to Bolungarvík to pick him up.

The engine, which we used to charge the batteries and run the electrical devices, such as the chart plotter, GPS and radio communications as well as the heating system died on us and would not start again. After a full day of sailing with no hope of getting the engine back we decided it was not tenable to continue the challenge. We decided to sail to Bolungarvík to have the engine looked at.

May 16th 2004

We sailed through the night with virtually no wind trying to keep the boat going in the right direction. As morning rose we attempted a final attempt to start the engine. Miraculously it started!

The jubilation was dampened though as we soon realised the generator was not charging the batteries. The plan remained, we were going to end the attemt and go to Bolungarvík. We got good winds that morning and made good progress. As we neared Bolungarvík though in the early afternoon the batteries did start charging again and we decided to continue.

Haffi was still seasick though and wanted ashore. The rescue team from Bolungarvík came out to meet us and Haffi jumped on board. We wished him quick recovery, thanked the rescue team and kept sailing.

As we back sailed out Ísafjarðardjúp the wind died down and we were finally able to cook a decent meal.

One of the issues with the boat was that the wind index at the top of the mast telling you what the direction of the wind is had not been installed. Now that the wind was down I climbed the mast and installed the device. Now we were able to see looking up the mast the direction of the wind. Although the electronic instrumentation was working now that the electricity was back, having the index is more intuitive and not prone to electric failures.

May 17th 2004

We eventually got a bit of wind again and sailed though the night. That wind however did not stop growing. As we worked our way past Horn and to the northern part of the Westfjords the wind just kept increasing. We reefed the main and gradually decreased the front sail area with the roller furler until there was nothing left. With a double reefed main, no jib, waves that looked like skiing slopes and Snælda still broaching we realised we had to completely take down the main sail.

Taking town the main sail would negate all control over the boat though. Also, taking down the sail without being able to point the boat into the wind using the engine is not easy when the waves are pushing the boat forward. We had no storm sails and no sea anchor, an unreliable engine and only the experience of the past couple of days to know what the boat could actually handle. We also had no offshore sailing experience between us.

Unfortunately Snælda’s deck was not fully waterproof. In those conditions we had water coming in at the bow wetting out sleeping bags and clothes.

In the conditions we found our selves in it was dangerous to maneuver on deck to take down the main without the engine. With no good options to continue I make the call to cancel our attempt and go back to Bolungarvík under engine.

The drive to harbor was cold and miserable. We were wet inside and out and the heating was not working. Once we got there, the first thing we did we go to the swimming pool and soak in the hot tubs there. What joy that was!

Bolungarvík was such joy. We were well received in town and got all the support we needed.

May 19 2004

After much deliberation we decided to attempt the record again. To be honest there was not much left in us and another attempt was really the last thing anyone wanted to do. Stubbornness is strong with Icelanders though and that is the only thing that kept us going. We were not going home defeated.

We started again from Bolungarvík at 17:17 on May 19th 2004 and I had the harbormaster Ólafur Svanur Gestsson officiate the departure. A local news reporter interviewed me during our stay in Bolungarvík and recorded our departure for Stöð 2. We had a decent departure but as soon as we got out of the harbor the wind completely died down. What and embarrassing start for the camera.

May 20th 2004

The low wind held well into the night but during the night Halli was on watch and got a decent winds which took us past Straumnes. Later, once I took the watch for a few hours the wind died down again and we made slow progress past Kögur and towards Hornbjarg. Later Arnar took the helm and eventually the wind picked up from the west giving us fair winds to round Hornbjarg. This was the northern most marker in the western fjords, now we took aim to Grímsey the arctic island.

We had good Westerly winds as we sailed across the North West of Iceland and we finally made steady progress. The wind steadily increased as the day went on. Fortunately it was all blowing from the back pushing us along.

Halli took over from Arnar and stayed at the helm for the afternoon and evening. Just before midnight I took the watch again.

Morale on board at this point was pretty good but the excitement and determination that we had at the start was all gone. Now we were all business and just getting on with things. Everyone was determined to do their bit and complete the challenge.

May 21st 2004

As I took the watch the wind had stayed up and but fortunately the direction of the wind was favorable. The waves had however built up and Snælda was surfing down many of the large waves. She had a tendency to want to broach so steering was a very active job.

As the night wore on the wind kept increasing. As there was no way to leave the tiller I had to rouse the crew to come on deck to reef the main in the middle of the night. As the reef leads had been damaged when we sailed around Hornbjarg for the first round we took down the main and sailed with the reefed genoa alone. The boat sailed very well with this configuration. Aside from constant attention to prevent broaching the sailing was pleasurable.

The wind was strong and the waves large but at least we were making great progress. As Snælda surfed I clocked her doing up to 11.5 knots which was the fastest we ever sailed. We passed north of Grímsey in the night, sailing north of the arctic circle and headed for Melrakkaslétta.

Halli took the helm at 4:30, about an hour after we took down the main. I came back on deck to take the helm at 11am. The wind slowly calmed down and by 3pm we were sailing just north of Melrakkaslétta in comfortable winds doing 3–4 knots with full sails up.

In the evening I cooked pasta for the crew. This is was first full meal that we cooked while under way. There is a technique to cooking in these conditions but it is something that you learn. After the dinner it was time to reef the main as the wind was increasing and we were expecting strong headwinds in the night. We fixed the reefing lines and put one reef in the main.

So far we have seen no sea creatures or even vessels. It has been storms and big waves and nothing else.

May 22nd 2004

Last night was hard. Not only for me trying to rest in the bunk but also for Halli and Arnar who took the night watch together. The wind had turned to an easterly and increased to a gale. The forward bunk we sleep in was jumping up and down and sideways all night and sleep was nearly impossible. The bow kept digging into the waves and the sea was constantly flowing over the front deck and the leaks were making the bunk wet. Keeping the sleeping bag and clothing dry was an impossible task.

The night was cold with temperatures at 0 degrees. Arnar and Halli were exhausted and cold by the time I took the helm in the morning. Snælda points poorly into the wind when sailing with reefed sails and we have had to do a lot of tacking. We are only able to point about 60 degrees off the wind in these conditions so the dead zone is about 120 degrees making progress very slow.

Once we got past Langanes we were able to point the boat at a much better angle to the wind as we were now headed South South east. The easterly direction of the wind then worked in our favor and we were able to sail 111 nautical miles in a day which was a new record for us.

May 23rd 2004

Progress was excellent for the whole day. Arnar and Halli took the night shift again and I came on deck at about 8am. Sleep was much better last night as the motion of the boat was much calmer even though we were making good progress.

As I started my shift we were passing Neskaupstaður and by 10pm we were approaching Höfn. During the day I made pancakes on Arnar’s new pancake pan. This was a great boost to morale and much enjoyed. Today we saw the first vessel since leaving Bolungarvík. There has been very little traffic on the water for the whole journey so far.

The weather was beautiful this day and the wind a comfortable 15 to 20 knots. Interestingly the fjords all had very strong gusts coming out the fjord. The wind has been blowing from the North East and the fjords funnel the wind making for really gusty conditions. Being further out at sea gave us more stable conditions.

We had dolphins playing at the bow of Snælda. That was the first time we saw any marine life. So for it had only been seagulls and a lonely bee that came onboard. Interestingly, as soon as we came south of the arctic circle the temperatures rose from 0 to 10 degrees making our lives much more comfortable.

This day I started feeling my muscles getting tired for the first time. The lack of rest and the constant action was making my my body tired and I could only assume the same for the others.

Arnar deceded that he is not able to continue. He has asked to be picked up at sea at Höfn. This is a problem for Halli and me as we are already getting fatigued and only half way to complete the challenge. Sailing with only two would be significantly more challenging that having three in the crew.

Fortunately for us, Haffi is keen to have another go at taking part in the challenge. He has found patches he hopes will do a good job of keeping the sea sickness at bay and he wants to join us when Arnar leaves. We have contacted the pilot at Höfn and he has agreed to come out to facilitate the swap of crew.

May 24th 2004

At 1:30 we met the pilot from Höfn in the waters just outside Höfn. Captain Óli navigated his vessel masterly as we met in the night with significant waves creating a huge discrepency between the two vessels. It felt like a bicycle and a trcuk jumping together on a trampoline but Óli drove his pilot vessel close enough to us for Arnar to jump over to the pilot and Haffi to jump on board. Maneuvering Snælda to be close to the pilot with only wind was near impossible so most of the heavy lifting was done by the pilot I just had to try and keep her as steady as I could.

As soon as Haffi came onboard he went to sleep as he was already seasick. Halli managed to sleep though the whole exchange, exhausted after the last few days of sailing.

Soon after the exchange the wind died completely and for the rest of the night I kept changing the arrangement of the sails to try and keep them as full as possible, or at least not banging from side to side. After the night I was near exhaustion and was very happy to be relieved by Halli at 10 am.

For the rest of the day Halli sailed with little to no wind making little progress. This continued when I relieved Halli in the evening. From Höfn to Skeiðarársandur was a very long sail against the breeze. Haffi has been extremely seasick the whole day.

May 25th 2004

In the night there was even less wind than the night before. When I took the helm at 8am there was a light but steady breeze which held for most of the day. As we changed watches at 4pm the wind was starting to pick up a little. The wind so far has been on the bow and so progress has been slow. We have been averaging about 3 knots and not always in the direction we want to go.

Haffi has shook the seasickness now and has taken the helm. Hopefully he will remain well. We have decided to try 6 hour shifts now.

We can see Hjörleifshöfði now. It is 23 miles out.

May 26th 2004

Haffi took the helm for a while last night. When the wind picked up he becase sick again though and went down below. When we reached Dyrhólaey the wind had become quite strong and I was having trouble managing Snælda with the full main. The wind was blowing from behind but the waves were difficult and threw the boat making accidental jibes a serious risk.

Eventually I took down the main and sailed using the genoa alone. The wind kept increasing and the waves too. By the time we reached Vestmannaeyjar Halli took the helm and steered until the morning.

May 27th 2004

I came on deck at 8am to take the helm. The wind was still up and the waves getting bigger. I stayed at the tiller until 2300 making this the longest watch I have ever done being 15 straight hours.

The wind was significant. At some point I took down all sail and sailed or surfed with the mast alone. Fortunately the wind was blowing us in the right direction but even the smallest area of sail was too much.

The ocean was a beautiful emerald green when the sun shone through the huge wavetops.

At just before midnight Halli took the helm and sails us through the dangerous Reykjanes röst rip while I navigate. We were lucky though as the rip was slack and we sailed though without issues.

May 28th 2004

As soon as we went though the rip the waves slow to almost nothing but the wind holds. Being in the lee of Reykjanes with good wind until morning, gave us a nice run up into the middle of Faxaflói. Then, however the wind died and we are barely moving for half the day.

In the afternoon the wind picks up and it blows heavily on the nose as we sail up past Snæfellsnes peninsula and across Breiðafjörður towards the western fjords. Progress was slow but we were moving.

Once we made it around Látrabjarg and to Patreksfjörður the sea became easier and the wind stayed giving us better progress into the night.

May 29th 2004

By morning we are becalmed again. Just outside Dýrafjörður only 20–25 nautical miles from the finish line in Bolungarvík we were becalmed and only drifting with the currents.

The night before the engine and electricity died and we have no electronics or heat anymore. I took the helm at 9am and we have been drifting since.

The water now tastes terrible. It seems to have been contaminated with plastic and is barely drinkable.

For the rest of the day we drift with occational breeze barely filling the main sail. By evening we drift along the coast towards Bolungarvík and the finish line.

May 30th 2004

Arrived in Bolungarvík harbor at 00:15, more carried by the currents than the wind. We however managed to sail to the dock setting the first non stop sailing record around Iceland at 10 days and 7 hours.

If you are managing work in an IT environment you may have come across this challenge; how do I plan and keep track of the work when I have to juggle Project initiatives, Product development and work allocation to Team members.

Small to mid size IT team managers are often in a position of having to juggle all three dimensions of work planning. Agile is great but at its core it is a work planning process that focusses on a Team of people. How do you provide a complete picture of the state of each of the products that the team is managing?

Prince 2 and other PM frameworks are also great but if you don’t have a dedicated project team how do you keep track of all the different requests for changes to the various Agile teams?

The role of the elusive Product Owner is a fantastic concept but where will you find that magical unicorn, for all the different products you support? If you can’t find that person, how will you keep a product backlog for all the products you support and make sure it’s kept up to date?

Firstly these are 3 different dimensions of work planning. Each of those dimensions requires a different approach. If you try to plan on all three dimensions at once you are likely to fail, or at least get gray hair sooner than you need to.

Projects are by their very nature cross functional initiatives created to achieve organisational benefits. They are established because achieving the outcome within one team is not realistic. As such an IT manager will have a number of project managers calling on their Teams time for a number of initiatives at any given time.

Products in the IT world are generally systems. In the Agile world we create backlogs and issue registers for products. That is how we keep track of what changes have been requested and what issues have been discovered in that product.

Teams are groups of people who work together (obviously). Most often teams are defined by the organisational hierarchy and have a line manager in charge. In Agile we may have cross functional teams with a Scrum Master but contention over resource capacity allocation often prevents that from being an option. In Agile the teams will do work planning every fortnight or so to clarify the priorities. Without Agile the line manager will allocate work to the staff or the staff will accept work from stakeholders. In the latter case prioritization and requirements clarification is left up to the staff member alone.

Secondly, if you pick any one of those dimensions and manage all the work though the lens of that dimension you will be able to find a plethora of tools and frameworks to plan and track the progress.

However, if you manage a team who oversee a wide range of products and deliver to many different projects at the same time how can you achieve the same?

The answer is not easy. The project has to keep track of the project milestones and outsource the deliverables to the technical teams. This means that the project manager is responsible for planning and tracking progress against the project milestones. To make this task more manageable the teams have to provide an interface for the project manager to be able to hand work to the team and get the outcomes delivered.

In order to keep track of the team’s commitments the manager or scrum master has to create a team backlog of work. This backlog then progresses and deliverables get handed off to the requestor when completed. This team backlog allows the team to know what they have committed to and where they are up to. Fortnightly work planning makes the task of managing the backlog much easier.

Finally, you also need a product backlog to keep track of the state of the different products. This is where the requests should go and where the technicians should update their progress. Project requests would generally go into the product backlog. Most of the time projects require changes to products so planning with a product mindset tends to be the better option for the IT managers and scrum masters.

Lastly you need to bring together the work out of the backlogs and into the team backlog. Ideally the tool you use can do this for you by adding a layer of team management on top of the product backlog, allowing you to plan the work of the team but link the work items though to the product backlogs. If your tool does not do that you may want to keep the team backlog separate but avoid duplicate data handling as much as you can.

In the end the best way to manage the work is by focusing on maintaining well groomed product backlogs. Project and team planning will then use these product backlogs to add their requests and track progress.

Project vs Product vs Team; which to use for work planning! was originally published in The Cloud Builders Guild on Medium, where people are continuing the conversation by highlighting and responding to this story.

Working from home works well from some but less so for others but there are number of things you can do to set your team up to be productive at home.

Create presence

Just as in the physical space presence can be felt online. Your team will come together on a chatty forum just like they do in the office. Pick a platform that the whole team will be using and set up one main channel for the team. Then create and encourage chatter on that channel. To get things started you can do a roll-call to give everyone a chance to get past their fear of speaking to the group.

Allow general banter and only moderate the conversation with gentle nudges. If you are lucky there will be a person or two who takes to this form of communication and gets really chatty. This is a good sign as it will rally the other participants and involve them. This will give your team the presence you are after.

Make your team members feel like they are a part of a team even when they are not physically located in the same space. By creating presence you can achieve that.

Create a rhythm

Consistency will create patterns that people will get into sync with. If you for instance kick off a chat on the channel every morning at the time that you normally get into the office at and involve every member of your team you will have established a bit of a routine for your team.

A daily 10 minute ‘stand-up’ is a good example of a productive rhythm. Ask everyone to say what they worked on yesterday, what they are working on today and if they have any impediments to getting the work done. Keep it short and succinct, not allowing for discussions about the work in the stand-up.

Manage the work

The nature of work is not uniform so this will mean different things to different people. There are however some things that can be done to make it easier to quantify the work and make progress more visible. When your team is working from home visibility is harder without measurable metrics.

If the work has a transactional component to it, such as consumer bookings or IT support tickets then create a way to keep an eye on the metrics from the system that you use. For each team member find or put together a report that tells you how many scheduled hours of service were delivered or how many tickets were closed. Then set a target for the team members and keep an eye on the metrics. This will not tell you the whole story but it is a good starting point to get a sense of the volume of work that is getting done.

If the work Is not transactional then try to describe the work that needs to be done and break it into chunks that take half a day to three days of effort (as opposed to elapsed time) to complete. Then create a list of all the work that needs to be done in the next period of 2–4 weeks. Make sure the work that has highest priority is a the top and ask your tem members to give you an estimate for each one. Then keep track of how the team is progressing with the list.

These are some very basic tips on how to manage the work. There are many approaches to this but the key is that you get a sense of how the work in your space is progressing and are able to pick up when a problem arises. When doing remote work you don’t pick up on issues allowing you to take corrective action as easily as when you are in the office so you will need to have a systematic approach to help with that.

Some type of work is better suited to WFH

The benefit of working from home is the lack of interruption. This allows you to get stuck into work that requires you to concentrate. Any type of analysis or transactional work such as processing invoices or writing proposals are very well suited to working remotely. Work that is best done collaboratively is generally best done face to face.

If you are able to then get your team to focus on work that can benefit from the deep concentration you can achieve when working remotely. If not, then spend time testing the tools that can help you collaborate better when not in the same space together.

Conditions at home

As you start talking to your team member over the messaging system you can quickly tell who is responsive and who is not. If you are feeling that a member of the team is having a difficult time being productive the first thing to look at is their personal circumstance at home.

Not everyone has a working environment at home that is conducive to getting work done. A disruptive environment or a poor workstation setup will have a huge impact on productivity. Talk to the staff member and work with them on strategies to get more productive time out of the day. Things that may impact on productivity are:

• Family members sharing the same space where your team member is working
• Noisy working area, including TV or other entertainment close by
• Bad seating or desk
• Poor internet or equipment

Look to help your team member set themselves up in a quiet space, with suitable seating and desk arrangement and make sure their technology is working for them. If they are having problems learning how to use the tools they are working with then seek help from your IT department or find training material online for them to get familiar with the tools. Udemy.com has a lot of courses that I have found useful.

How to keep your teams productive while working from home was originally published in The Cloud Builders Guild on Medium, where people are continuing the conversation by highlighting and responding to this story.

All I know about Quantum Computing is that it is faster. The theory of it gets people smarter than me talking excitedly for long periods of time and I never seem to be any closer to getting a handle on what it means. Now though it seems that the age of Quantum Computers might be drawing near. Google and NASA have claimed they achieved Quantum Supremacy and the big cloud providers are offering access to Quantum Computing, so it is time to get some understanding of what it is and how I can make use of it.

First the basics; What is Quantum Computing?

After looking at a few pages on Wikipedia I came up with the following definition. You can quote me if you like, or if you are smarter than me and found a flaw in my definition then let me know in the comments section and I will quote you.

“A quantum is the minimum amount of any physical entity involved in an interaction. It could be a photon of light or an electron of atomic matter. A quantum can be measured (quantized). Quantum Computing is when you use the quantized state of quanta (plural of quantum) to perform a calculation”

Classical computers use mechanical gates which are either open or shut to perform calculations. Each gate represents one “binary digit” or “bit”.

Quantum Computers use the quantized state of quantum to do the same thing. Each quantum evaluates to either 1 or 0 depending on it’s state. Each quantum evaluation represents one “qubit”.

However, the state of the qubits is not as certain as the state of a gate in a microprocessor and that is the biggest challenge of Quantum Computing. The qubits are considered to have a probability to be 1 and a probability to be 0. The state with the higher probability will be the state it is determined to be in. That’s it, that’s quantum computing.

This all sounds like you will be asking a piece of cheese what the time is. How is this actually going to work?

Despite the hype Quantum Computers are not yet a practical reality. As the state of the quanta is not as stable and reliable as gates on a microprocessor Quantum Computers are prone to err. Quantum computing devices have been created but the errors are still a problem that make them of limited functional value. Fault-tolerant quantum computers are believed by most to be quite a way off yet.

Quantum computing today, including cloud-based Quantum Computing is mostly about running Quantum Computing simulators on classical computers to develop algorithms and programs that will eventually be run on quantum computers when they become viable. The simulators are also used to validate the computations of current quantum computers to assess their fidelity (correctness) to gauge how close we are to having machines that work in practice.

Google AI Quantum team

Google has established a research team focused on quantum computing. The team is a part of the Google AI group and is called Google AI Quantum.

The team made quite a splash in October 2019 when in collaboration with NASA they published a paper in Nature claiming to have achieved “Quantum Supremacy”, meaning they were able to use a quantum computer to solve a problem that conventional computers could not have slved.

The paper abstract states that “A fundamental challenge is to build a high-fidelity processor ..” followed by “Measurements from repeated experiments sample the resulting probability distribution, which we verify using classical simulations”. In other words the experiment validates the results from the quantum computer using simulations in conventional computers.

The abstract goes on to make the big flag-staking claim of “Quantum Supremacy” success:

Our Sycamore processor takes about 200 seconds to sample one instance of a quantum circuit a million times — our benchmarks currently indicate that the equivalent task for a state-of-the-art classical supercomputer would take approximately 10,000 years. This dramatic increase in speed compared to all known classical algorithms is an experimental realization of quantum supremacy for this specific computational task, heralding a much-anticipated computing paradigm. — Arute, F., Arya, K., Babbush, R. et al. Quantum supremacy using a programmable superconducting processor. Nature 574, 505–510 (2019). https://doi.org/10.1038/s41586-019-1666-5

This achievement albeit limited in scope is likely to become the milestone when Quantum Computing became generally considered an inevitable reality.

The team has developed a number of Python libraries for developers to get started with Quantum computing. Published on GitHub under the account “QuantumLib” these open source libraries will get you started with Quantum Computing right on your desktop.

quantumlib

• Cirq; a Python library for writing, manipulating, and optimizing quantum circuits and running them against quantum computers and simulators.
• OpenFermion; an open source library for compiling and analyzing quantum algorithms to simulate fermionic systems, including quantum chemistry.

Google has also published a “Quantum Computing Playground” for learning and playing with Quantum simulators running Quantum algorithms.

Quantum Computing Playground

The Google AI Quantum team has done a lot to progress the evolution of Quantum Computing. In their mission statement they say “We want to offer researchers and developers access to open source frameworks and computing power that can operate beyond classical capabilities”. Doubtless we will be seeing more from them in the future.

IBM Q Network

IBM has a Quantum initiative. It is called IBM Q Network and it’s website is full of management speak.

IBM Q Network is a community of Fortune 500 companies, academic institutions, startups and national research labs working with IBM to advance quantum computing.

.. and ..

We are committed to accelerating and scaling quantum computing by partnering with industries and fostering a growing ecosystem.

Behind the dark suit of enterprise jargon however there is an ambitious Quantum initiative under way at IBM. They have created Quantum Computing Hardware, established a web based quantum computing simulator and developed a number of Python libraries under the GitHub account Quiskit.

The Qiskit initiative even has it’s own website at https://qiskit.org/ and it looks like a lively community.

Qiskit

Quite frankly looking at the artifacts and progress made by the Quantum people at IBM I am surprised that they allowed Google to steal their thunder by declaring Quantum Supremacy. In fact IBM scientists have debated the claim made by Google but marketing wise IBM have lost that round.

For those that have little patience for Qiskit IBM have provided a nice little Web Client called “IBM Quantum Experience”. This will allow you to create algorithms and circuits using a visual interface and cloud based Quantum Computer Simulators.

Through a service subscription on their website you can then run your code on an actual Quantum computer.

Beyond this IBM also has an initiative called “IBM Q System One”. This is presented as the first Commercial Quantum Computer offering. To explain how it works they have provided this press release. This offering appears to be aimed at large research facilities and intended to build up the Q Network.

AWS Braket

Amazon Web Services offer a Quantum Computing service called Braket. It is a managed service which helps you get started with quantum computing by providing a development environment to explore and design quantum algorithms, test them on simulated quantum computers, and run them on quantum hardware provided by partnering companies.

The service is not operational as yet but you can sign up for a preview. The hardware providers are IONQ, D-WAVE and Rigetti.

Q# and QDK - Microsoft’s Quantum Development-Kit and language

Microsoft has taken to the challenge of preparing for the age of Quantum Computing by releasing a development-kit including a new computer language they call Q#.

Get started with the Quantum Development Kit (QDK) - Microsoft Quantum

Microsoft supplement the kit with a cloud based Quantum service. It is not clear from their site whether they only offer simulators or if you can run your code on actual quantum computers on Azure but their partners certainly develop such hardware

Azure Quantum - Quantum Service | Microsoft Azure

Quantum Computing Simulators

There are a number of libraries that will allow you to simulate Quantum Computing on your own computer. In addition to Googles QuantumLib contributions on GitHub have a look at Quantiki’s list of simulators.

List of QC simulators

The number of simulators available is surprising, there are quite a lot of developers who have been working on solutions in this space.

Conclusion

The age of Quantum Computing is not quite here yet but it’s dawn is looking very near. Research teams are coming closer to creating reliable devices to perform quantum computations and the big vendors are readying their service and product offerings for when that will happen.

The landscape is confusing at present as the vendors race to prepare for a new age of computing that is not yet well understood. Vendor websites are not clear in their statements about product offering what actually is on offer.

However, IBM is probably offering the most cohesive products and solutions. If you are looking to get started with Quantum Computing in the cloud I would start there.

References

Definition of a Quantum
https://en.wikipedia.org/wiki/Quantum

Explanation of Quantum Mechanics
https://en.wikipedia.org/wiki/Introduction_to_quantum_mechanics

Quantum Computing
https://en.wikipedia.org/wiki/Quantum_computing

Wiki article on Cloud-based Quantum Computing
https://en.wikipedia.org/wiki/Cloud-based_quantum_computing

Quantum Supremacy
https://www.nasa.gov/feature/ames/quantum-supremacy, https://doi.org/10.1038/s41586-019-1666-5

Google AI Blog on the Quantum Supremacy achievement;
https://ai.googleblog.com/2019/10/quantum-supremacy-using-programmable.html

Cloud-based Quantum Computing was originally published in The Cloud Builders Guild on Medium, where people are continuing the conversation by highlighting and responding to this story.

From time to time I come across cloud type of offerings from vendors I had not realised were offering cloud services. These often look interesting but it can be hard to quickly evaluate the offering in comparison to the big three cloud providers. The big three being AWS, Azure and Google Cloud.

Gartner has made our job easier by analysing the six main offerings and created their famous Magic Quadrant placing IBM, Oracle and AliBaba so far behind the big three that there is little need to consider them for general Cloud purposes. If you have an account with Gartner you can find the report here, for the rest of us have a look at AWS’s article on the 2019 findings:

AWS Named as a Leader in Gartner's Infrastructure as a Service (IaaS) Magic Quadrant for the 9th Consecutive Year | Amazon Web Services

However, there are still additional Niche players in the market offering services or price points that the more mature platforms wont offer. Some of these are worth looking at while others seem to be just maintaining old equipment.

Compute

Before Cloud became a thing many companies offered “hosting”. This was in effect a server in a data center with VMware or similar installed to provide multiple servers on a single host. Companies would then rent space on one of the servers or a full dedicated server. The server would then be available to the company to operate. This is now talked about as Compute and Storage in the Cloud world.

Many “hosting providers” still exist but their business model is not as viable as it once was. However, offering Cloud “Computing” is still a relevant service offering and can be a better choice in many cases than using the big Cloud providers.

Hitachi Vantara

Previously called Hitachi Data Systems, Hitachi is offering a “modern data center” for enterprise customers. Looking at their website it looks like they are catering for VMware based traditional data center operations with a managed infrastructure. They use a lot of terms in their product offering that don’t quite fit today’s cloud world, such as “modern” and “object storage”.

Hitachi appear to have a niche amongst corporate enterprise customers looking for hosted infrastructure and specialised ETL/Analytics and video storage products called Pentaho and Lumata.

Not so much a cloud service as a managed hosting service and specialised software product provider.

Digital Ocean

https://www.digitalocean.com/

Rather than become stale or pull out of the race Digital Ocean are taking the Cloud Giants head on re-positioning their service offering to be in line with the Cloud offerings we expect today. They even have their own concept of “Droplets” under their Compute offering which can be compared to the EC2 of AWS.

Digital Ocean has 8 data centres and their product and service offering is significantly less than the big three but they are focused on competing on price and offer markedly cheaper services. See below for a reference graph provided by Digital Ocean:

Kamatera

https://www.kamatera.com/

VPS hosting across 13 data centres across the globe starting at US $4 per month for a Linux server. This is a traditional hosting service that is transitioning to compete in a cloud world. They offer things such as a load balancer and CDN which does lift their offering.

Cloudways

https://www.cloudways.com/

Cloudways are also a VPS type of hosted service but they offer specialist packages to tailor their offering to a niche market. Cloudways has 1-click offerings for things like PHP servers and even Wordpress and Magento.

Rackspace

https://www.rackspace.com/cloud

Rackspace were the market leader of premium hosted services. Today they still operated their data centres and offer “Bare-Bone” managed servers. However, rather than compete as a cloud provider Rackspace have positioned them selves as a premium Managed Cloud service partners. Today you can engage Rackspace to help you design and implement your Cloud solutions in AWS and Azure.

Storage

A different area area of focus in the Cloud Service space is Storage. Many providers have honed in on the need to store data and offer services and solutions specifically for this niche. The big three cloud providers have a range of options for storage depending on the purpose but there is still room for specialised offerings and price point competition.

pCloud

https://www.pcloud.com/

pCloud offers price competitive storage for individuals and small businesses. At the price of about US $100 annually for 2TB of storage pCloud is certainly cheaper than the US $552 that AWS will charge for the same amount of standard S3 storage. pCloud also has a “lifetime” subscription offer which will cost you a one off $350 payment to store 2TB for as long as they stay in business.

The service comes with an app that you install on your computer and mobile devices from where you manage your document. pCloud has an interesting encryption option that you pay extra for. The normal product offering comes with secure endpoints but file level encryption will be up to you.

Degoo

https://degoo.com/

Another low price point cloud storage competitor, Degoo offers 10TB storage for about $120 per year. Degoo focuses on your photos and offers cloud AI features relevant to your photo library.

Dropbox

https://www.dropbox.com/

Dropbox was the cloud storage disruptor who filled a gap between Peer to Peer sharing applications and operating systems like Windows and MacOS. We now have OneDrive, iCloud and Google Drive who swooped in and filled the market gap that Dropbox occupied but Dropbox still exists. Dropbox is still a go-to solutions for staff in businesses that do not have a document sharing solution readily available.

Dropbox offers a competitive market rate for their storage solutions. Charging US $140 per year for 5TB of data storage with 3 user accounts or US $220 for unlimited storage.

Dropbox occupies a niche in the cloud that has become smaller than it used to be but with the exponential growth the Cloud space has experienced there is still room for them in that niche. The main advantage of using Dropbox over other similar solutions is that as a first-player in this market their service is a household name that most users are familiar with. You probably have a Dropbox account your self. They also have a mature technical solution for desktop file management which was their competitive edge in the early days.

The big three in disguise

Microsoft, Google and even Apple offer Cloud storage as a service. This is separate to their IaaS/PaaS service offering for storage and is aimed and the individual as a service integrated with other product offerings. OneDrive, Google Drive and iCloud are most likely services you use today either personally or at work. These services come with a free tier but you can purchase additional storage.

OwnCloud

https://owncloud.org

OwnCloud is an Open Source storage and collaboration platform that puts emphasis on security and encryption. The community version gives you a tool to run your own storage solution but the Online edition offers 500GB of storage for about US $200.

Edge Computing (CDN)

Akamai

https://www.akamai.com/

Akamai were ahead of their time about 15 years ago when they spotted a need for a distributed network of web page caching for faster content delivery. I tend to think of them as the original CDN. They were very expensive to use and it was only for medium to large enterprise customers to use their service but it was worth it. When the internet was slow they made sure geography was no problem. Today AWS has a service called CloudFront that does this job just as well and costs very little in comparison.

Today Akamai still occupy the same space but refer to their offering a cloud service.

Conclusion

The big three Cloud providers offer a vastness of services and level of both redundancy and security that can not be matched by any other company on earth. These services as a whole are much cheaper than a company could build them on their own. However, not all solutions require that level of service. You do pay for the maturity of the big three platforms in the price of the service and that is where niche services can sometimes offer you a more suitable solution.

The Other Clouds; beyond the big three was originally published in The Cloud Builders Guild on Medium, where people are continuing the conversation by highlighting and responding to this story.

Operating your application services in the cloud as opposed to in your own datacenter is where we are all headed. What does that mean for the old DR plan?

“The Cloud is just someone else’s hardware”

That was a true enough statement in the early days of the Cloud but not any more. Even if your migration plans focus on “lift-and-shift”, “like-for-like” or “Hybrid-cloud” initially you will soon learn that you are entering a new era of infrastructure, application and data management.

Once it comes time to refresh those Disaster Recovery plans your SaaS, IaaS and PaaS solutions will make it hard to come up with a meaningful way to design your approach. In some cases you may have to ask your self: do we still need a DR plan or is it something else we need now?

SaaS, IaaS and PaaS, what is the difference?

Most organisations are using a combination of all three modes but each one requires a different way to think about how you ensure your ability to recover from adverse events. In the case of IaaS you sometimes have all the same responsibilities and approaches as before but SaaS and PaaS solutions will always require a different approach than on-prem DR.

Infrastructure as a Service (IaaS)

Using Cloud services to run your environment the same way as you did on-prem is IaaS. You open and account with AWS or Azure and provision Windows or Linux servers on a network you have set up and migrate your servers over to there. You may even keep some on your On-Prem Data Center and set up a Hybrid-Cloud with servers talking together over a secure link.

Your applications will still run on servers managed by your team and the way they are operated will look the same or very similar to how they were managed before.

If this is your scenario then the DR approach will be the same as it was before. You just have to update the procedures for how services are accessed and where your backups are now being stored and your done. Your RTO/RPO objectives will be the same, your plans will need updating but no major overhaul.

Platform as a Service (PaaS) and Serverless

The next level up in handing responsibility for running your services over to a third-party is using “serverless” technologies and PaaS solutions. The two are similar in nature. The difference between the two can best described as PaaS being the mature version of Serverless. AWS DynamoDB and AWS Lambda are Serverless technologies but AWS and Azure are Platforms as a Service.

In a PaaS world you don’t run or control the servers that your applications and data run on but you control its configuration and the data it handles. You are responsible for making sure the applications and data are running correctly and reliably but in the case of failure you have no access to to servers to make changes. This is where your DR strategy starts changing.

As your service will be dependent on the PaaS services that they run on your DR plans will have to take into account that the redundancy solution will require the same PaaS services to operate the shadow environment or restored backups. Your DR plans will have to articulate where the services are running in your production environment, where they are being backed up to or replicated and where and how you will restore them in case of a Disaster.

The important thing here is to consider the options available for recovery. If your service is running on DynamoDB and Lambda in AWS you will be able to design for redundancy across multiple data centres which will increase your resiliency but in the case of a Disaster that wipes out AWS in your region you will need a plan for how you can recover the services in a different region taking into account your RPO objective.

Further more your DR plans will have to make it clear that the services could not be restored in the Microsoft Azure Cloud in case there was a problem with AWS Globally or if your company had an issue with AWS commercially. The PaaS limits your recovery options to the platform they run on.

Software as a Service (SaaS)

The website you are reading this on is a good example of true Software as a Service. These words are written on a web based editor and saved on Medium.com. There is no application or data level backing up or restore that I am able to perform to recover from a potential disaster that Medium.com might go through. Everything I do is dependent to Medium to provide adequate confirmation of their ability to keep the platform secure, robust and redundant.

In this case it is important for your DR plan that you review the credentials the provider has achieved to that effect. This type of software is very easy to consume and anyone can sign up to use it. To what degree organisations manage the use of SaaS depends on the software and the nature of the organisation but any business critical SaaS application will require due-diligence to validate the providers ability to recover from adverse events.

Not all services that are called SaaS are true SaaS though. Many software providers have moved their applications to the Cloud but in reality they are just running a hosted application service in the background. In that case it will depend on the architecture of the solution and the details of the hosted service contract to what degree you can plan your Disaster Recovery.

If you are able to get access to or have a copy of the data-sets and application artefacts you want to explore storing them in your own cloud instance and having the ability to stand them up in case of a Disaster. This would allow you to have an independent DR plan that will look fairly similar to a traditional plan.

So, what now then?

Although DR plans are still relevant it is important to go back to the driver behind the requirement for having a recovery plan. Generally this would be found in a Business Continuity Plan or the Organisation Risk Register. Wherever it is that the business documents its level of tolerance for disruption and risk to the business processes that the services you operate support it is willing to accept, that is where you will find the true drivers and reason for having a DR plan.

In the new world of Cloud operated services we may sometimes find more value focussing on Redundancy and levels of Resilience than backup processes and Recovery plans. The drivers and tolerances your organisation has set will help you determine which areas to focus on.

For SaaS and PaaS services you want to to focus on reviewing the service providers compliance statements and audits as well as SLAs to satisfy the businesses defined business continuity targets in the case of disasters. ISO 27001, SOC1,2,3 and PCI are common accreditation to look for in a mature SaaS solution. These accreditation are confirmations of external validation of internal processes meeting the standards stipulated in those definitions. They are only a confirmation that the processes are in place, not a confirmation that they have been tested and verified by the auditors.

You will also want to get confirmation of DR testing that the organisation has done to validate that their processes work. This will often take the form of an auditors report.

Remember that even the best of organisations have blind-spots in their DR plans and real life testing is the only way that they get found and addressed. For a very insightful read about an incident and subsequent recovery by an open and transparent SaaS/PaaS company read GitLabs Postmortem of the Jan 31 2017 database outage.

The big Cloud platforms have focused heavily on attaining compliance with relevant standards. This and the focus put on security practises has been a winning formula to gain the trust required for enterprises to move their applications and data onto their cloud data centres.

• https://aws.amazon.com/compliance/programs/
• https://azure.microsoft.com/en-au/overview/trusted-cloud/compliance/
• https://cloud.google.com/security/compliance

Your Disaster Recovery plan will focus on providing certainty about what the business can expect in the event of a disaster and describe where to find relevant contact details and contracts to enforce these expectations when required.

Office 365 and One Drive

The big application platforms pose a particularly poignant dilemma. If the platform you are using for your core business documents has a long list of certifications that your organisation would never be able to achieve on their own and a number of data centres in a number of regions and countries with up-time track records that are close close to 100% then what is the point of planning for a Disaster?

Would it not be a better use of time and money to design for redundancy and leave any potential Disaster Recovery to the platform vendor to deal with? After all they have such plans and the certificates to prove that they have been audited.

For most small and even medium sized organisations that may actually be sufficient. As long as you set retention policies for all Microsoft Office 365 document you will be able to provide redundancy against accidental or deliberate deletion of documents effectively replacing the need to back up your documents to ensure their availability for the retention period your organisation requires.

However, if you run PaaS type of services in Office 365 such as Microsoft Dynamics 365 you will have databases that you must back up. This can be done using the platform it self saving backups that you can restore in locations separate to the region where the database is running. Your DR plan will then capture how you would restore the database and associated artefacts in a new instance of Dynamics 365 in the case of corruption or other type of disaster.

Medium and large organisations as well as organisations with increase legal responsibility will need a more robust DR plan than a small organisation. When planning for DR in a large organisation you may want to consider backing up all your artefacts including the Office 365 documents, emails and SharePoint websites on a different cloud providers disks. You may not be able to restore services to their previous level if Office 365 stopped working all together, or Microsoft closed all your companies accounts but at least you will have an independent copy of your data that you can restore to some extent using various tools.

In conclusion

This article has covered the considerations for how DR planning changes in the Cloud. When writing the plan however the details of how you approach it will depend on the particular services you are planning for. Office 365 and related services are particularly thorny and there is a lot of material to cover to understand your position and desired state. Please leave a comment if you are interested a particular cloud service and we will give you more advice on that particular service.

How do you plan for Disaster Recovery in the Cloud? was originally published in The Cloud Builders Guild on Medium, where people are continuing the conversation by highlighting and responding to this story.

For a while I had this idea of creating a VR experience for people with Arachnophobia or fear of spiders. The idea is for the person to experience the presence of spiders in a simulated environment to face their fear and overcome it. Psychologists call it ‘immersion therapy’. A psychological technique which allows a patient to overcome fears by experiencing the thing they fear in a safe and controlled environment.

The repeated exposure with no negative impact normalizes the experience and removes the fear, or so the theory goes. Apparently it can be quite effective and VR is the perfect medium to make it happen.

A few months ago I set my self a goal to build 12 games in 12 months. The first game took so much effort that I needed a long break after just one game! There was a lot to learn and progress was slow. I still have a few months left but I might have to reset the goal to 3–4 games in 12 months. My second game however took a bit less time. Mostly because I have been on leave from work and have had the time and energy to dedicate to making games but also because I am now more efficient with the tool I use, Unreal Engine.

The blueprint

To make and publish a game in a short amount of time you will need the following:

• A vision for the game
• Skills to use the tools you will be using
• The wisdom to know what part of the game making process you will not do your self and the ability to source that
• Know how you will publish the game and be set up to do so
• Accept that commercial success in 4 weeks is unlikely, this is just for fun

The game making process has many aspects to it. To do it all you will need a lot of diverse skills. I would call the different aspects out as Storytelling, Visual Design, Building and Publishing. It is important to figure out which aspect you are best at and enjoy doing the most and hot to source the rest. Given that you are reading an article about making games I’m guessing that you are a primarily a builder.

The game

Before you begin you need some vague idea of what you are going to build. There is no need to flesh it out in detail before you start but some starting point of inspiration is required. Once you start the game will emerge as you figure out how to make things happen and solve problems.

The ideas just present them selves like when you were a kid and saw a creek to play in. There was a creek, there was water, there were rocks and the rest took care of it self. Making a game is similar to that. The vision is there to keep you excited, like being by a creek.

The Storytelling is not easily outsourced though. Sometimes a story you read is your inspiration but you can’t use it without the authors permission. We are all able to tell a story but to do it well is a skill. I have not found a way to outsource this and it shows in my games.

Spider Fear is a game intended for a practical purpose. It is made with people who are afraid of spiders in mind and gives them an opportunity to be in an immersive space with spiders that they may find scary in a completely simulated environment. Exposure therapy is an approach to treatment of psychological conditions that psychologists commonly use to help people get over their fears. The idea is that if you experience the things that you are afraid of again and again with nothing bad happening then eventually you stop being afraid.

This approach can be very effective. A friend of ours has a child that was afraid of dogs. They then got a dog specifically to help their child get over their fear and now the child will confidently handle a dog twice their size.

This is a common sense approach to dealing with fear that psychologists use with supervision and in a structured way. Spider Fear is a casual way to allow anyone who is afraid of spiders to do the same thing at home and have a little fun while doing it. A word of caution though, immersion therapy is best done with professional oversight.

The build

My game is called Spider Fear. It is made using Unreal Engine and 3d models from the Unreal Engine market place. You can choose different software to build a game or even just use a vanilla language like the Minecraft team did when the chose Java. However, today there are a lot of tools that make the process easier. The two most popular are Unity and Unreal Engine.

Unity is the more popular tool as the time required to get started is shorter but Unreal Engine is the more mature tool. Choosing Unreal Engine has meant that I have had to dedicate more time to learning about the coding in more detail and possibly has also made it easier to make mistakes but it was a learning investment I was keen to make as I feel it will be the more powerful tool to learn.

Both tools allow you to make a game using visual design interfaces. You can make a whole game without ever writing a line of actual code. This makes it really easy for people with no coding or computer science background to get started on game design.

The tools are there to do the heavy lifting. They are the rocks. My current tool of choice is Unreal Engine. It has loads of built in capability that allows me to very quickly do things that I can’t believe I can do. Unreal has a very steep learning curve and I have had to dedicate a lot of time to learn how to build using the tool. There are simpler tools that get you started quicker but I like the maturity of Unreal Engine and enjoy learning to use it.

There are many places where you can purchase or download for free artifacts to build a game. The Unreal Engine Marketplace is one and TurboSquid is another. The same goes for sounds and some specific in-game behaviors. Using these can bootstrap your development further to shorten the development time.

Admittedly this was not the first time I use Unreal Engine. I have already put in a fair few hours to learn to use the tool. Udemy has some good courses that I have used and the internet is full of tutorial about specific tasks. Epic games put a lot of effort into creating learning material for the engine. If you are looking for good material to get started have a look at this article on Game Designing: https://www.gamedesigning.org/learn/unreal/

In the case of SpiderFear I spend most of the effort animating the spider and giving it some sensible enemy behaviors. Unreal comes with a great tool for building AI behaviors. Spider Fear uses the ‘sight’ component to move towards the player when they are close enough.

My VR headset is HTC Vive. Unless you have multiple types of headsets you will only be able to test on that device. This will limit what devices you should release for as you don’t want to say that you support devices you have not tested on. The main options today are:

• OpenVR on Steam; this includes HTC Vive, Index and any other VR headset that is not platform specific
• Oculus; Rift, Quest and Go. Oculus has a number of platforms.
• Windows Mixed Reality; HoloLense.
• Playstation VR

Steam is the only platform that all the devices can use but each device that is not OpenVR compliant will have support requirements that need to be considered. Oculus has the most headsets in the real world and currently Oculus Quest is the headset of choice for casual use. However the Oculus distribution platform is only open to large software vendors.

The release

Publishing a game is a craft. Figuring out the mechanism is not too hard and some of it is just an extension of the building process but getting it noticed requires business skills and marketing. These days there are publishing houses for games. However, for a game you made in 4 weeks part-time this will not really be a concern, just putting it somewhere for download will be a win.

In this case I chose to publish on Steam. Steam allows anyone to register an account and publish a game for about $100. Releasing on Steam makes your game available in a store. You can reference it and it will present as a finished product. This is a great way to give your game presence and put it in front of people who will be interested in taking a look.

A word of caution though, the gamer community will not take kindly to a product with little investment of time and refinement. Be ready to be judged.

A friend of mine worked in the game industry for many years but always dreamed of making his own game. Eventually he took a year off to make his game. He worked really hard. Once the year was up he shelved the game and gave up. He was too afraid of what people might say about the game to release it.

Spider Fear is not a refined game but I chose to release it for two reasons; firstly I wanted to to learn about the process of releasing a game and what it might take to actually make a commercially successful game. Secondly; I wanted to make the game easily available to those that might be looking for a way to deal with their fear of spiders.

To release a game on Steam you will need to register for a partner account. This will be a different account to your normal Steam account. You will pay a fee to register and you can release one game with that fee. Each additional game will cost just over $100 to release. The fee goes toward paying for the manual review process that all game registrations have to go though before being released.

This process takes a fair bit of time for a hobby developer so you might want to start the process early if you are looking to keep to a short time frame. You will need to create various visual artifacts and a video to show the game play, put in various descriptors including legal stuff and go though an internal Steam testing and review process.

Takeaways from this exercise

It is very possible to make and release a game in a short period of time. As with all software development however there is a lot more time spent refining various details of your product than you anticipate in the beginning.

Good Game Design relies much more on artistic qualities than other types of software creation. Although UX/UI are important when making applications they are not the very core ingredient. In Game Design they are.

Commercial success in the gaming space requires an obsessive amount of dedication to your vision. It also requires that you bring together people with different skills; coding, storytelling, visual design, modelling, music and sound effects as well as commercial marketing skills. One person can not do a good job of all these specialized areas that need to come together to make a good game and stock artifacts will never come together in a cohesive enough way to make a good quality game.

Virtual Reality is still at an early stage of its life cycle and it shows in the availability of solutions and even design patterns available for VR. This is what I find most exciting.

References

Spider Fear: https://store.steampowered.com/app/1219910/Spider_Fear/
Tinarastic Game Studio: https://tinarastic.studio/
About the author: https://www.linkedin.com/in/valberg/

How I made and published a VR game in less than 4 weeks was originally published in The Cloud Builders Guild on Medium, where people are continuing the conversation by highlighting and responding to this story.

Ever wanted to create a My Account page on a React website using AWS Cognito as your user pool? Today I wanted to do this for a website I am building and found that it was surprisingly easy to do.

I used Amplify to set up both my AWS backend and my authentication front end. The magic of Amplify is mind boggling after spending so much time provisioning resources in AWS by hand or even by editing CloudFormation templates. Amplify abstracts all the JSON/YAML editing and gives you a simple wizard to create the configuration for you.

Once you have a React website app set up and the Amplify Auth Cognito authentication configured we will allow the logged-in user to change their account details. The authentication data is in AWS Cognito as that is your user pool.

To get started with Amplify and React take a look at the Getting Started section on the Amplify website: https://aws-amplify.github.io/docs/js/react

We will assume that you have already set up the following dependencies: npm, nodejs and aws-cli. Now go ahead and set up a vanilla React app with react-create-app. The outline below will help make sure you have the basics set up.

Create a My Account page

To keep things simple we will use withAuthenticator on the App.js to magically add authentication capability to your app. The following App.js file shows you how.

To present and work with the My Account data we are going to create a page specifically for this purpose. Using the React single page app approach the best way to do this is to use React Router. Check the Router elements in the file above. One element will render the MyAccount component when the URL is /myaccount and the other will render a link to the My Account page from the front page.

One small thing to add. In order for the Semantic UI to have the CSS it needs on the public site open public/index.html and add a reference to the cloud distribution of the CSS file between the Head tags:

<link rel=”stylesheet” href=”//cdnjs.cloudflare.com/ajax/libs/semantic-ui/2.3.3/semantic.min.css”></link>

Now for the fun part, the My Account page. Create a new file called “MyAccount.js” in the src directory right next to the App.js file. Then use the contents of the gist below to get started.

This will be all you need to create a My Account section on your website but lets take a look at what is happening in the React code above.

As Amplify handles all the heavy lifting between the app and AWS all we have to do is capture the information and pass it to Amplify. React prefers to consider the state of the component that renders the input fields as the “single source of truth” so what we need to do it capture the input and put it into the React state. On form submission we then call Amplify Auth and pass the values to it to persist in Cognito for us.

In React, mutable state is typically kept in the state property of components, and only updated with setState(). We can combine the two by making the React state be the “single source of truth”.

— https://reactjs.org/docs/forms.html

You may notice the attribute “bypassCache: true” where we fetch the user information. This is important on a page where we intend to make updates but would otherwise cause an unnecessary performance hit. The purpose of this is to force a call to Cognito when we fetch the user data. By default the currentAuthenticatedUser method will cache the user details and fetch for cache rather than from Cognito. That would mean that the user would not see the updated information after saving even if the save was successful. By bypassing the cache and forcing a network request we refresh the cache and make sure the information displayed is fresh.

Beyond Cognito: AppSync & DynamoDB

Cognito is really just the starting point for the My Account page. It is where you keep the authentication details for your app. It is tempting to also think of it as the best place to keep all the account information including your application authorization. However, this is not a good idea.

Cognito is best kept simple. To extend the personal information, account details and application permissions use a different data store. Any data store will do but AWS DynamoDB is particularly well suited to this role.

The good news is that Amplify abstracts all this configuration and infrastructure provisioning into a wizard as well. We will provide a tutorial on this in the future but in the meantime take a look at the Amplify documentation at:

https://aws-amplify.github.io/docs/js/api

We hope you enjoyed this quick tutorial.

Create a “My Account” page on your React website with AWS Amplify and Cognito was originally published in The Cloud Builders Guild on Medium, where people are continuing the conversation by highlighting and responding to this story.

In the early days of the internet Amazon pioneered personalised recommendations. This was groundbreaking innovation at the time but it required serious machine power to crunch the data and make relevant revenue generating recommendations. However, the grunt work was not constant and the infrastructure investment would sit idle for significant amounts of time.

This was a form of waste and being wasteful goes against the Amazon grain so they started renting out the infrastructure. First internally and then spotting a market opportunity to earn revenue, to interested customers. This is how AWS was born.

Being thrifty also required minimising the total cost of running the infrastructure so AWS only used free Open Source software. Later in its life the AWS team felt they were paying too much for the market leading Cisco routers and only using a portion of the functionality available so again being thrifty they eliminated the waste by making their own routers! This is how Amazon rolls.

The one area where Amazon accepted that money had to be spent to make AWS a viable option for large customers was Security. Security is “job 0” at AWS and this was the real genius of their service offering. Not only did they have free top notch software and the cheapest hardware you can get with economy of scale but they also had data centres with more security credentials than any small to medium size organisation could ever achieve. This made the Cloud the obvious choice for most businesses and the data centre an outdated dinosaur.

While AWS was busy pioneering the centralised data centre model named “the cloud” the other computing giants were busy doing other things. None of them took much notice while Amazon slowly build up a business in the “hosting” space. Microsoft was busy being destroyed by Steve Ballmer and fighting windmills like Don Quixote in the form of Linux and Open Source software. IBM was busy capitalising on its strong but declining enterprise services reputation but doing some interesting innovation that never made it to market in the background. Google, who actually pioneered the Cheap data centre in it’s early days, did not see them selves as a “hosting” company and focused all its energy on consumer products. Then Alibaba true to the Chinese business model started copying the market leader to provide a clone of the AWS service offering.

Fast forward to 2020. AWS is still King. Their service offerings are the most comprehensive, easiest to use and arguably the cheapest option for most workloads. Cheapest bar perhaps Alibaba who have some of the service offering and slightly lower cost.

Second place is Microsoft Azure. The one advantage Microsoft has over Amazon when it comes to the cloud service offering is Active Directory (AD). AD has been the defacto Identity Management (IdM) solution for any business since Novell died in the nineties. AD is still a good reliable IdM solution and porting it to the Azure AD SaaS service offering is a fairly easy task. It supports federated integration with any modern identity protocol and is simple enough for any Level 1 IT support desk to manage. Simply an outstanding evolution of a widely adopted legacy technology that has decades to go yet. The only chink in its armour is that it is intended for managing staff identities and not suitable for managing your application users who do not work for your company. AWS Cognito does a much better job of that.

The biggest disadvantage of Azure as a service offering is how difficult it is to use. All the interfaces to the services on offer are designed from the perspective of marketing and licencing, not from the perspective of engineering and functionality. This leads to an enormous amount of technicians time and mental stability being spent trying to make sense of various limitations, false promises and stuff that just wont work.

Having said all that the Azure service offering is catching up with AWS. As mentioned earlier AWS got a large head start in the Cloud wars but Microsoft having fired Ballmer and hired the very promising Satya Nadella is catching up fast. Having made peace with the Open Source hippies and joined the revolution Microsoft is getting more relevant again. I have not mentioned their very successful Office365 port to the web based product offering and their killer SaaS app Teams or OneDrive as it is technically not Azure. This is not to be dismissed but it has little leverage on making Azure more attractive over AWS. Save for Azure AD as mentioned before.

Google Cloud. Where to begin. To this day I am still confused about what they are trying to do. Google’s beauty and curse is their commitment to intellectual pursuit. There is no doubt that they are the brains in the internet landscape. However, that does not necessarily lead to successful service offerings. Google has built a fantastic suite of end user productivity tools that rival and in my opinion surpass Microsoft’s Office 365. This is their “G Suite” product offering. Next to the “G Suite” button on the Google Cloud product page is the “Google Cloud” button. In my mind this says it all. Their focus is not on Infrastructure as a Service (IaaS) but Software as a Service (SaaS). The implication is that Google excels at creating products not services.

It has been a while since I used any of the “Cloud” offerings Google has. Things like Firebase and Compute Engine. When I did I found them confusing and difficult to use. In the case of Firebase it was seriously lacing in functionality, difficult to use and had no support at all. Things may have changed but what has not changed is academic attitude Google employees have about the intellectual superiority of their solutions. This means they don’t actually care if you can use their services or not, if you are smart enough you should just get it. If not, you are on your own. Another time I will tell you the story of when I proved an arrogant Google employee wrong. I am still savouring the victory.

If you have a reason to use Google Cloud then rest assured that once you get it working it will run optimally, until they decommission the service or unexpectedly change the terms of service. Both of these are notorious Google problems that you should take into account. Don’t expect much support or response to your specific problems. Just avoid Google Cloud altogether if you can. Google does have it redeeming qualities though and that it in their SaaS offerings. In addition to the G Suite their API services such as Google Maps are integral to your application development.

IBM has been offering Machine Learning and AI services in the cloud now longer than any of the other providers. This is one areas where AWS has been playing catch up with another provider. IBM has been working on AI service solutions now for a long time. Their Watson service was the first speech to text API for general use. Watson has given IBM an edge in the Machine Learning service offerings. IBM is still an enterprise focused company though. Expect to pay more than with any other Cloud provider. Their service offering is also far behind the AWS stack and innovations for software developers are not impressive. The API SaaS offerings are well worth looking at. As a comprehensive cloud offering though IBM is far behind Amazon.

Finally, Alibaba Cloud. The good thing about Alibaba is that they have largely kept the terminology of their service offering the same as the services they are copying from AWS. Their 9 data centres in China make Alibaba a good choice for services deployed in China. Their service offering lacks behind AWS though. As far as security and reliability is concerned I have to admit that I don’t know the company well enough to comment. Looking at their website though they do have many of the core international certifications. The price is slightly cheaper than similar AWS services but not enough to make much difference.

I hope this overview is useful to you. Please do leave your thoughts and insights to help others evaluate the different Cloud offerings.

Which Cloud is Best; AWS, Azure, GoogleCloud, IBM or Alibaba was originally published in The Cloud Builders Guild on Medium, where people are continuing the conversation by highlighting and responding to this story.

Last night I joined the AWS Programming Tools Melbourne meetup for a workshop on creating a serverless Gatsby blog site using AWS Amplify, GitHub and Apollo GraphQL via AppSync. The workshop was very professional with a lot of strong technicians supporting the attendees. The organisers Daghan, Milan, Nikola, Simon and Dawn have done a great job building a popular Meetup group and the event participation of 142 people demonstrated as much.

The presenter Julian Pitt was no stranger to running workshops. Until recently he worked for “A Cloud Guru” who provide technical training material online. I personally used their AWS Solution Architect training course to prepare for my exam which I passed the first time round.

Julian’s workshop was titled “Serverless blog page with Gatsby and Appsync” and based on his GitHub repository “Serverless Gatsby Workshop”.

julianpitt/serverless-gatsby-workshop

The repository has step by step instructions for setting up a serverless blog and we successfully completed the workshop in the meetup.

Recently I have started experimenting with using the browser based IDE Cloud9 on AWS as my primary IDE. The biggest benefit of this is that I can pick up from where I left off on any computer. This is a huge benefit for me as I have a number of machines with various operating systems that I use and I never know which machine I’m on when I finally have time to code.

In the past I have spent lots of time making sure I have all the dependencies installed on each machine and tried to make sure I always push my code commits when the leave the computer. However, sometimes getting the systems synced will take so long that by the time I’m ready to code I have ran out of time. With AWS Cloud9 all my setup is present no matter where I open my IDE from. I just start coding.

Cloud9 is an EC2 host with an IDE. That means you can do anything you normally do on a Linux server on the machine, including running docker containers or Apache/Nginx web servers. However, interfacing those services with your IDE and previewing or debugging your work can take some configuration.

Those of us who used Cloud9 in the workshop did find that the normal way of previewing the blog site would not work as the server would not respond to a request from a browser. This was a nice little challenge for a team of highly skilled technicians. In the end we found that the solution was to change the port used by the dev instance to 8080. For some reason the server would not respond to requests on the default port 8000.

To preview the blog add TCP port 8080 to your Security Group configuration that the Cloud9 EC2 instance and site start the gatsby site with the following:

gatsby develop --port 8080

If you are interested in AWS services and live in Melbourne the AWS Programming Tools Melbourne is a great forum to catch up with other AWS enthusiasts. The workshop format makes the meetups very practical in its focus and you walk away with new hands on knowledge every time.

5 stars!

AWS Programming Tools Melbourne Meetup — Serverless Gatsby Site with AWS Amplify in Cloud9 was originally published in The Cloud Builders Guild on Medium, where people are continuing the conversation by highlighting and responding to this story.