Makerdays Winter 2017!

Diederik Hattingh
Alphawave
Published in
6 min readSep 12, 2017

Makerdays this winter was the first time all the Alphawave companies came together to collaborate on our free form Makerdays projects!

What is a Makerday anyway?

When Polymorph joined the Alphawave family, we looked at the different software teams, and what they did to maintain their skills (besides building awesome products).

Completely independently, the Alphawave software team, and the Polymorph team came up with an almost identical way of keeping the creative juices flowing, and ensuring we don’t get bored with our day to day work.

The idea is simply: set aside some time (two days, 3 times a year) where people get together and work on an idea that might not have anything to do with what they do on a daily basis.

Working with a new set of people on a new problem (while keeping shipping in mind) usually leads to people using new and exciting technology stacks that they would otherwise not be exposed to. (Firebase! RxJava! MQTT! AWS Lambda!) As we know, getting our hands dirty is a very good way of learning, so there is lots of knowledge sharing from people with some experience in the respective areas.

Working with a new set of people can also cross pollinate ideas that might otherwise stay within the confines of a team. Makerdays is a good way of mixing the pot a bit.

Wait, this isn’t work at all!

Or is it?

I strongly believe that working on slightly less structured activities like this from time to time is very important.

Part of being a good software developer today means knowing what the latest trends are, but it can be easy to get lost in your day to day duties, and lose sight of what is going on “out there”.

Solving non-trivial problems even if it is only over two days, gives you an idea of what the obvious pain points are of a specific technology, and where it should and shouldn’t be used. Most of the time someone you work with on a team has some experience in it, so at the very least you know who to ask if you need more help.

The process

Ideas for what to build are submitted from anyone in the company, not just the software teams. We pitch it as “what would you build if you had free reign over a world class hardware and or software team for two days?!”

This generates a list of ideas (25 this time!). The teams vote on what they want to work on, and this list is reduced to about 5 ideas.

One more round of voting gets the teams sorted, and then the details of what to build/bring/buy get discussed by each team.

On the Thursday, we get together, and remind all the teams that SHIPPING IS A FEATURE. Trying to building something for two days, and then having nothing to show for it is lame. What works well to solve this is to aim for smaller bits of functional that you can demo reliably. Then when it is ticked off, move on to the next feature.

More happiness please https://mobidev.biz/blog/software_estimates_minimum_viable_product

Thursday afternoon there is a demo of progress so far. This demo is usually a hit and miss. Not all the teams has something to show, besides a functioning dev environment. Anything functional at this point is a good sign.

Friday is where the teams really come together, and try and get the envisioned feature sets finished off. Demo time is earlier as well, so the pressure is on.

The demo itself is an opportunity to show off what you have built, but also to share what you have learnt. All the teams will get an idea of what you used to build the solution, and come ask afterwards if their next idea might be a good fit for that stack.

The projects

To give you some idea of what we worked on this time round.

Home power usage

Hardware and software component to this one: install a gadget on the power inlet of your house (or only a plug) and the gadget will send the data to a server. After some calibration the app will be able to tell you what appliance is on, and how much kilowatt-hours you are using.

The simple demo worked very well: a gadget on the multi-plug, and a few appliances attached to it. As things get turned on and off, the signal gets sent to a Raspberry Pi, and send off to an MQTT channel. The app (web and mobile) gets the updates, and shows the new data as appropriate.

Two-way exercise equipment

Think of an exercise bicycle that knows how fast you ride. This can then be fed to a VR game, and give you a more interesting view than your living room. As you go uphill in the game, the gadget increases and decreases the resistance as appropriate.

Result was a gadget that works only one way: send the bicycle speed to a server. A manometer was placed on a bicycle wheel, and the speed was send to a Raspberry Pi (again). This was fed to a server, and connected to a basic, but functional VR game! Weeee!

VR Bicycle game lives!

Smart prepaid power meter

Idea is very simple: place a gadget on the pre-paid power meter at your house, and send the info to a server (current level and timestamp). Build an app that warns you if the level is too low. Version 2.0 will be able to enter tokens. Perhaps even an auto top up feature!

Outcome on this one was mixed — the OCR on a low contrast LCD display wasn’t great, so if OCR will work, it has to be calibrated for the specific prepaid box.

OCR here worked well, not so much for the LCD models unfortunately.

Property & Big data

Goal of this project was to give homebuyers a better idea of the vital statistics of a neighbourhood: what the crime rates are, what the schools in the area are, what the average selling price is in the area.

The data required is spread all over the place, and there exists no single way of accessing it. The focus for this version of the project was to get home prices from the deeds office. By law the municipality has to make this information available to the public, but it doesn’t have to be free. (R12 per title deed.)

The data this team worked on was made available in a painful printer friendly version. A team member applied themselves to getting the data in a machine readable format, and was quite successful. The data was plotted using Google’s fusion tables, and relative home prices are shown as a heat-map.

Weather station

Our one hardware product (built on site!) has narrow temperature and humidity bands in which it must operate.

A simple weather station was built to log this info, and is plotted on thingspeak.

Glorious data!

Makerdays success!

This was the first time the Polymorph, Alphawave, Honeybee Sozo labs and Etse teams have all participated together on a Makerdays, and I thought it was quite successful.

Let’s hope the next Makerdays will build on this, and be just as great.

--

--