June Hackday - Lifx Smart Tiles (Part 3)

Last June we had a Hackday at Kogan.com! This Hackday’s focus on displaying information and providing useful alerts using hardware and software. Teams were asked to express something they find interesting through one of the available mediums.

In this third and final part of the series Jake will talk a bit about Team LifxnChill.

Team LifxnChill

Our team was given a set of 5 smart Lifx Tiles. These nifty light panels are 8x8 LED grids of dissipated lights. Five tiles can be chained together, arranged and animated. They’re programmable using an API (docs here). Each tile cannot be programmed separately. These have great potential for expressing all kinds of stuff.


Ideas proposed included the following:

  • Use github webhooks to do something with the lights when a commit is pushed, a pull request is merged/closed, or a deviant force pushes.

  • Standup Glow - Pulse when standup kicks off

  • Stretch goal - animations

Plan of attack

1. Write experimental commands

2. Create endpoints that use the commands

42. Create lambda functions for other stuff

We never got around to writing up steps 3 to 41. Steps 1, 2, and 42 were enough to get started!


Two APIs were available; LAN and HTTP:

HTTP - Send off basic requests, such as pulses, brightness and cycles. Authenticated by an oauth token. This was low entry and really fun to see ideas come together. Team members could POST requests and see the result immediately.

curl -X POST "https://api.lifx.com/v1/lights/all/effects/breathe" \     -H "Authorization: Bearer YOUR_APP_TOKEN" \     -d 'period=2' \     -d 'cycles=5' \     -d 'color=green'

Keep me POSTed - Lifx Tile

LAN - Limited to, you guessed it, the Local Area Network. The lower latency LAN API allows calls to map each individual light rather than a whole tile. This meant you could use animations. We initially tried this with an existing package called photons-core but opted for HTTP for reasons we’ll later explain.

Problems faced

The LAN API was looking promising, until we discovered the complexity involved in getting the tiles running. Remember we only had one day here, so the focus had to be on getting something out. Using a local network also made it difficult for a team member working remotely to participate. With these factors in mind we opted for the HTTP API.

 Getting into it

Getting into it

While developing with the tiles, we discovered often API calls were not coming through. We suspected it was to do with throttling, but cumulatively the team’s usage was nothing should have triggered it. It turned out the Tiles had a bug:

WHEN all Lifx Tiles are off
AND a cURL request is sent
Expected Result:
All tiles animate according to the options sent
Actual Result:

The first master tile ignites, but it’s daisy-chained titles do not

When all tiles are off, you can’t power them all on with a single request (Which was incredibly frustrating). As a proof of concept everything worked, but a dealbreaker for day-to-day usage.

At this point I decided to post on Lifx’s forums seeking an answer. Not long after they posted a firmware update and voilà! The Tiles became usable.


We now have a proof of concept standup reminder, an Orange/Red/Green status integrated with our jenkins pipeline and a glow each time a commit is made.

In the future we’d like to move these actions over the LAN API with endpoints that our pipeline can hit, allowing the use of animations.

June Hackday - Team KASX (Part 1)

June Hackday - Team KASX (Part 1)

Last June we had a Hackday at Kogan.com! Team KASX was given the task of creating an app using React Native for a mobile device that could be used to display information such as Kogan’s stock price.

Faster Django Tests by Disabling Signals

Django signals are a form of Inversion Of Control that developers can use to trigger changes based (usually) on updates to models.

The canonical example is automatically creating a UserProfile when a User instance is created:

from django.conf import settings
from django.db.models.signals import post_save
from django.dispatch import receiver

@receiver(post_save, sender=settings.AUTH_USER_MODEL)
def post_save_receiver(sender, instance, created, **kwargs):
    UserProfile.objects.create(user=instance, ...)

Signals are useful for connecting your own behaviour to events that you might not have control over, such as those generated by the framework or libary code. In general, you should prefer other methods like overriding model save methods if you have the ability, as it makes code easier to reason about.

Signal receivers can sometimes be much more complex than creating a single object, and there can be many receivers for any given event, which multiply the time it takes to perform simple actions.

Tests and signals

Often you won't actually need your signals to execute when you're running your test suite, especially if you're creating and deleting many thousands of model instances. Disconnecting signals is tricky though, especially if the disconnect/reconnect logic can be stacked.

An easier, but more invasive method for suspending signal receivers is to check a global setting, and return early.

from django.conf import settings

@receiver(post_save, sender=MyModel)
def mymodel_post_save(sender, **kwargs):
    if settings.DEBUG:

This has two drawbacks. Firstly, it's messy, and you need to remember to add the check to each receiver. Secondly, it depends on a specific setting that you might need to have turned off when running your tests, which makes it harder to test the actual receiver.

Selectively disabling signals

We can take this most recent idea of checking a setting, and wrap it up nicely in our own decorator. When running your tests, you can override the SUSPEND_SIGNALS setting per test method or class.

Here's a gist that does just that

import functools

from django.conf import settings
from django.dispatch import receiver

def suspendingreceiver(signal, **decorator_kwargs):
    def our_wrapper(func):
        @receiver(signal, **decorator_kwargs)
        def fake_receiver(sender, **kwargs):
            if settings.SUSPEND_SIGNALS:
            return func(sender, **kwargs)
        return fake_receiver
    return our_wrapper

And using this decorator in your test suite is straightforward:

class MyTestCase(TestCase):
    def test_method(self):
        Model.objects.create()  # post_save_receiver won't execute

@suspendingreceiver(post_save, sender=MyModel)
def mymodel_post_save(sender, **kwargs):

And just like that, we can skip signal receivers in our test suite as we like!

Kogame (Koh-Gah-Mi) - A real time game in Django

Kogame (Koh-Gah-Mi) - A real time game in Django

For our March hackday this year we decided to build a multiplayer game using

[Django Channels](https://channels.readthedocs.io/en/latest/). We've been keeping

an eye on channels over the time, and thought with the release of channels 2.0 that

it was the right time to dive in and get some practical experience. The organisers

didn't want to do yet-another-chat-system implementation, so they decided to make

things a bit more interesting, and look at writing a real-time game.

React JS Melbourne - May Meetup

The React meetup was on again at Kogan HQ last Tuesday!

Four presenters covered three exciting topics; including the use of React in non-profit organisations, understanding the new Context API and scaling a React team and their tools from 2 to 20 devs.

Due to the large waitlist for this quarter's event, we trialled a live feed via Google hangouts which went quite well!

 The event attracted 200 RSVP’s who consumed many burritos throughout the evening.

The event attracted 200 RSVP’s who consumed many burritos throughout the evening.

 Want to come along next time? Tune in to  our Meetup Page .

Want to come along next time? Tune in to our Meetup Page.



Harnessing the Power of Volunteers for Community Benefit - Mike King & Matt Wiseman (Back2Bikes)

Github repo - https://github.com/Back2bikes/attendance-app


Understanding the New Context API - Mair Swartz

Github repo - https://github.com/Mair/react-meetup-context-api