Removing the fear of shipping with automation.

I don’t like shipping personal work. Even writing this is hard. I think it’s a heady mix of fear of failure, change and being called out for the imposter that I am. Or it might just be my flare for the dramatic. Who knows? All I know is I can ship for other people all day long (this is good as that’s my job) but when it comes to doing projects for myself it’s always harder. It’s strange as I love making things. It’s the best.

I find adding a layer of automation between myself and the actual shipping helps. It’s took a long while for me to figure this out. For example: I now use a build process for this blog that removes me from actually hitting the publish button. It means I can just push this markdown file to a git repo and then some time during the night it will get published by a fearless build process. Magic. Then at some point next week WHEN I LEAST EXPECT IT I will tweet about it (without me doing anything and once I’ve forgotten about it). You may even have arrived here via that tweet.

Mood

Using async Node.js with Bubble to create simple mini projects

I love the idea of using no-code tools to make mini-apps for your team (and other teams). I knocked together a quick video manifest parser using Bubble and Node.js. A developer could do this on the command line easily but I love being able to open up these type of tools to people who aren’t quite as technical.

This tutorial shows you how to create a Bubble plugin that uses server side actions.

What do we want to achieve here?

  • An app that we can pass in a url of a DASH or HLS manifest
  • The app outputs the parsed manifest to the screen

How are we going to do this?

  • Create a Bubble plugin that takes a url paramater input
  • The Bubble plugin should download the manifest from the url
  • The manifest should then be parsed using server side actions using either m3u8-parser (if HLS) or mpd-parser (if DASH).

Create a Bubble plugin

  • On Bubble go to My Plugins page and click New plugin
  • Name your plugin something catchy. I called mine manifest-parser. Super catchy.
  • Fill in your plugin general details.screencapture-bubble-io-plugin-editor-2020-09-24-14_56_16.png
  • On the Actions tab click Add a new action. Name your action in the popup. In the drop down for Action type select Server side. This is where you can start using the power of Node.js. Exciting. Screen Shot 2020-10-13 at 11.29.57.png
  • Now we need to pass a couple of parameters to our server code. These are going to be the url of the manifest and the streaming protocol (DASH or HLS). In our server code we will load the url and parse the data loaded with the respective parser (https://www.npmjs.com/package/m3u8-parser for HLS and https://www.npmjs.com/package/mpd-parser for DASH). Fill in the Fields section like this: Screen Shot 2020-10-13 at 11.33.17.png
  • By doing this we are able to view these params in our test app. I have a Parse button, an input for the url and a dropdown to select HLS or DASH in my test app. Go to the app you are testing your plugin in and attach a workflow to a button. Now on the workflow you will be able to select your plugin from the Plugins menu. Beautifully illustrated here: Screen Shot 2020-10-13 at 11.40.55.png
  • Now as part of the workflow I can pass in the values from my manifest URL input and the HLS/DASH dropdown, like so: Screen Shot 2020-10-13 at 11.45.36.png
  • Yes! Time for the fun part. Running the server side code and utilising Node.js packages. Hop back into your plugin project. In the Returned values section add a parsedManifest key to be returned (this will contain a string representation of our parsed manifest - I guess that was kind of obvious from the name) Screen Shot 2020-10-13 at 11.51.41.png
  • This is the bit that seems to trip people up - doing an asynchronous call from the run_server function. The below is the basic outline of how to do this. (you’ll notice your dependencies are automatically updated - make sure the This action uses node modules checkbox is checked).
function(properties, context) {

  const fetch = require('cross-fetch');
  var url = properties.url;
  let manifest = context.async(async callback => {
    try{
      let response = await fetch(url);
      let plainText = await response.text();
      callback(null, plainText);
    }
    catch(err){
      callback(err);
  }});
  return {parsedmanifest: manifest}
}
  • Now create a textfield in your test app. I use a custom state from the workflow to display the return value of the above: Screen Shot 2020-10-13 at 13.34.08.png
  • Hit Preview and run your app. Drop in any url and it’ll display the source as a string in the text box - magic! Now all we have to do is flesh out the server-side code a bit and we’re done. Update with the code below and try dropping in a manifest url and running the app.
function(properties, context) {

  var m3u8Parser = require('m3u8-parser');
  var mpdParser = require('mpd-parser');
  const fetch = require('cross-fetch');

  var url = properties.url;
  var isDashProtocol = properties.streamingProtocol === 'dash';
  let manifest = context.async(async callback => {
    try {
      let response = await fetch(url);
      let plainText = await response.text();
      if(isDashProtocol) {
        var parsedManifest = mpdParser.parse(plainText, url);
        callback(null, JSON.stringify(parsedManifest, null, 2));
      } else {
        var parser = new m3u8Parser.Parser();
        parser.push(plainText);
        parser.end();
        callback(null, JSON.stringify(parser.manifest, null, 2));
      }   
    }
    catch (err) {
      callback(err);
  }});

  return {parsedmanifest: manifest};
}
Mood

I run today so that I can run tomorrow

Changing the way I look at things has been one of the most powerful and insightful things that I have done. I used to run a lot. Then I got fat and didn’t run a lot. When I ran a lot it was always for a goal - a half marathon or to hit a certain weight. This wasn’t sustainable for me over time and I didn’t find it fun (which is massively important for me).

Over the past year or so I have been running for a different reason. I now run today so that I can run tomorrow. I’ve been thinking a lot about Infinite Games and Systems over Goals and this fits into that way of thinking.

There was a point a got so unfit that running was becoming harder than hard. It hurt. But applying this system of running (or exercising) today with the only goal to be able to run (or exercise) tomorrow it has become fun and easy. I love it. I don’t give myself a hard time and I’ve kept it up for over a year and lost over 30kg with it. I’m never going to win any races but I’m definitely a happier tortoise than I was a hare.

Mood

Trajectory

If you are stuck in a rut and don’t think you are making progress focus on your habits and your current trajectory rather than how close you are to your goals (as this can be disheartening and might prevent you from even trying).

Try and remember that it’s not where we are, it’s where we’re going. If we can change our habits and systems to change our trajectory that is often better than being closer to our goals and plateauing.

Don’t worry about the past - it’s done, it’s one thing we cannot change. But we can change the future. Give yourself an edge by honestly evaluating your situation, looking at the choices you get to make every day and choosing the best one for that situation. If we make the right choices time after time we can find ourselves in a very different situation in a years time.

Mood

The three yous - past-you, present-you and future-you.

I saw this on reddit and thought it was too good not to write down as a gift to my future-self.

You should think about yourself as three different people - the past-you, the present-you and the future-you.

Be grateful and forgiving to the past-you. You should thank the past-you for doing things that have put you in the position you are in today. You should also be forgiving of the mistakes the past-you made, as you would forgive a good friend.

The present-you is where the magic lies. You can’t alter the past-you, but you get to shape the future-you. Do things as the present you that the future-you will be grateful for. Choosing between the couch and the TV? What will the future-you thank you for? Do that. Want to sit down and do some work on that side project you’ve been threatening to do for years or sit and veg? What will future-you thank present-you for? Do that. It’s easier doing a good turn for someone else.

When you become future-you remember to be grateful for past-you for all the good things past-you did. Past-you is pretty sweet. I like to picture past-you on a penny farthing.

Mood

Stopping the sleep screams

I have this sleep thing which is one part hilarious one part terrifying. When I’m in the first stages of sleep I have a startle reflex that makes me jump up in bed and start screaming at the slightest noise (even if I make the noise myself). Vicky my partner is often woke by me yelling “HELP, VIC” and it leaves me totally confused and thinking I’m dying. Every. Night. For 12 years.

Recently I’ve found a way of pretty much stopping it altogether. I’ve put together a cheat sheet below of how I stopped the old SLEEP SCREAMS. It’s a combination of information from Shawn Stevenson’s Sleep Smarter, Hal Elrod’s Miracle Morning, web research and personal anecdotal evidence.

Sleep Cheat Sheet 1.0

  1. Get up nice and early (I tend to get up between 5:30am - 6:00am)
    • Meditate.
    • Get outside. Natural light exposure triggers the production of more serotonin. The best time to get natural light is early in the morning - 6:00am - 8:30am for at least 30 minutes.
  2. Exercise
    • Lift heavy if you can bro. If not go for a walk or run - try to do this around 7am.
      • Use topical magnesium on anywhere that is sore before going to bed.
  3. Eat well
    • Alcohol - cut down or pack it up.
    • Cut carbs and sugar.
    • No caffeine after 2pm.
    • Use magnesium supplements.
  4. Winding down
    • Take a hot shower or a bath 90 mins - 2 hours before going to bed. After that wind down with a cup of camomile.
    • Go to bed at the same time each night. The best time to be asleep is between 10pm - 2am.
    • No screens an hour before bed. Or get some of them blue lensed glasses if you want to watch telly.
  5. Bedroom environment
    • Get a fan on or open the window.
    • Get yourself a weighted blanket. I love mine.
    • Get it dark - preferably so you can’t see your hand in front of your face.
    • Use red light if needed - it doesn’t affect your circadian rhythm as much as other lights.
    • Keep your room cool.
    • Put on some white noise - I use a river on my Echo - running water actually slows your heartbeat.

And one that I think is the most important. If you can’t fall asleep, don’t stress about it. It is what it is.

Mood

Forced remote - a tech leads guide to making the transition from the office to WFH

Over the course of the last month a lot of teams have gone from working in the office to working remotely. Teams have had to adapt quickly to the new situation and it’s nuances. This is my take on running a distributed team.

My current team was semi-remote - half of us were in the office, the other half spread across multiple timezones. I was based in the office so was involved in daily chit-chat about product and roadmaps - but since being remote I’ve noticed just how much of this I would’ve missed if I was remote. I’m currently dogfooding our remote culture and I’ve noticed a few places we’ve come up short.

The daily standup

Having people located across timezones meant we needed to have a standup time where everyone could attend - this was around 4pm everyday OT (office time). After reading this article by Jason Fried I proposed doing standup asynchronously over Slack - we did this for about 9 months. I was pretty happy with it - everybody got to update their days without being interrupted. The Slack channel was public so anyone else in the company who was interested could come and have a read.

Then I tried this async approach whilst being remote full-time. I had previously WFH one day a week but I hadn’t experienced being fully remote for any period of time. I found I missed interacting with the people in the office, I missed chatting and just connecting with my team mates. We’ve since implemented a standup/knowledge share/general hangout combo each day over Zoom at a time that is convenient for all - it generally lasts 15-30 minutes and in that time we let everyone know what we’ve been working and also discuss anything that comes up (we tend not to take it offline but talk it out there and then). So far the team likes it and the previously-fully-remote team members think it’s an improvement. This Zoom meeting is open to anyone in the business who is interested or who wants to discuss something with the team.

Slack etiquette

The way we use Slack hasn’t changed since we went into forced-remote mode. We try and use Slack asynchronously - we don’t expect answers right away. We have a pinned message setting expectations about the way we work: Ry slack message

I personally also turn off notifications and badges and minimise Slack whilst I am working. I also use encourage the use of Do not Disturb mode after hours (I tend to check-in in the evenings and people are able to force a notification to me if urgent).

Zoom/conference calls

Headphones with a mic is handy (rather than laptop speakers/mic) and we also mute when others are talking. I know## there is a bit of thought that everyone should not mute but get better headsets but I think with kids around due to homeschooling that might be tricky - I know it would be for me with my kids.

Managing your team

I’ve found the best way to manage a team remotely is similar to how I manage the team in house - giving trust and responsibilities whilst ensuring psychological safety for the team to discuss anything small or large. My team is awesome, they are skilled and driven. I bet yours is too. I’ve never been a bums-on-seats manager - If I can’t see you working then you aren’t working is not my style and would be hell in the current situation. I can imagine micro-managers aren’t having a great time of it currently.

LISTICLE TIME - top tools we use for remote work you might find useful

  • Slack
  • Zoom/Teams/Slack video/Google hangouts - video conferencing
  • Droplr - I use this every day for screenshots or sharing video
  • Zeplin - great for design teams to distribute designs and assets to devs
  • Decent headphones/mic
  • Jira or ticket tracking software so work is well documented and easy to pick up - this seems obvious for software teams but may be a new concept to those not in the software industry.
  • one of these for emergencies bat phone
Mood

How to use PUT or DELETE with a roUrlTransfer object in Brightscript

In any other languages using alternatives to POST and GET is a fairly simple operation. In Brightscript however using PUT and DELETE operations isn’t particularly well documented in the SDK docs.

To add PUT or DELETE we need to set the request type on our roUrlTransfer object. In a standard GET request you’d have something like this:

function httpGetRequest(url as String) as Object
 request = createObject("roUrlTransfer")
 request.setURL(url)
 response = request.getToString()
 return response
end function

But to use a DELETE or PUT request you need to set the request type as well as using the asyncPostFromString or postFromString call. So to use a PUT use something like:

function httpPutRequest(url as String, body as String) as Void
 request = createObject("roUrlTransfer")
 request.setURL(url)
 request.setRequest("PUT")
 request.postFromString(body)
end function

Or similarly a DELETE:

function httpDeleteRequest(url as String, body as String) as Void
 request = createObject("roUrlTransfer")
 request.setURL(url)
 request.setRequest("DELETE")
 request.postFromString(body)
end function
Mood

Exiting out of a Brightscript SceneGraph application

To exit a a SceneGraph application you have to complete executions of your main method. A nice easy way to do this is to observe a field on your scene and then fire a roSGNodeEvent via the port (Once you’ve read this you can download a full working app that demonstrates the below here. It’s pretty sweet).

You’ve probably got something like the following in your main app brs file.

screen = CreateObject("roSGScreen")
m.port = CreateObject("roMessagePort")
screen.setMessagePort(m.port)
scene = screen.CreateScene("mainScene")
screen.show()
scene.setFocus(true)

while(true)
  msg = wait(0, m.port)
  msgType = type(msg)

  if msgType = "roSGScreenEvent" then
    if msg.isScreenClosed() then
      return
    end if
  end if
end while

This would exit out if you clicked back on the RCU when the scene is focused as msg.isScreenClosed() would be true - but what if we wanted to close the app on another event? It’s actually pretty simple to do. The main challenge is exiting out of the while loop. A handy way is to add an observer to the scene and pass the port as the handler.

You could modify this main screen to look something like:

screen = CreateObject("roSGScreen")
m.port = CreateObject("roMessagePort")
screen.setMessagePort(m.port)
scene = screen.CreateScene("mainScene")
screen.show()
scene.observeField("exitApp", m.port)
scene.setFocus(true)

while(true)
  msg = wait(0, m.port)
  msgType = type(msg)

  if msgType = "roSGScreenEvent" then
    if msg.isScreenClosed() then
      return
    else if msgType = "roSGNodeEvent" then
      field = msg.getField()
      if field = "exitApp" then
        return
      end if
    end if
  end if
end while

By adding the observer scene.observeField("exitApp", m.port) on the scene a roSGNodeEvent msg will fire on m.port when we change the exitApp interface field. It’s a nice succinct way of handling this.

Set up your MainScene.xml so it has an observable interface boolean field called exitApp or similar:

<?xml version="1.0" encoding="utf-8" ?>

<component name="MainScene" extends="OverhangPanelSetScene" >
    <interface>
        <field id="exitApp" type="boolean" value="false" />
    </interface>

    <children>

    </children>
    <script type="text/brightscript" uri="pkg://components/MainScene.brs" />
</component>

Then you need to setup your MainScene.brs to alter the exitApp variable on an OK click:

function init() as Void
    print "ExitApp"
end function

function onKeyEvent(key as String, press as Boolean) as Boolean
    if key = "OK" then
        m.top.exitApp = true
    end if
end function

Download the source for this here.

Mood

How to calculate how much texture memory an image will use on a Roku box

Ever found your Roku app running sluggish or even crashing? If you’re building an image heavy application you may be bumping up against your texture memory limits. Since Roku introduced SceneGraph there have been massive improvements in memory handling and a visible reduction in crashes over apps that use SDK1 but have you ever wondered how to calculate how much texture memory an image will take? (Probably not you say? Well I’ll tell you how anyways).

It’s actually fairly simple and comes down to the dimensions of the image rather than any kind of compression technique.

To figure out how much texture memory an image will use in kilobytes just use the following formula (where numberOfChannels is always 4 - RGB and alpha):

(width * height * numberOfChannels) / 1024

To get megabytes just divide by 1024 again.

So if you had an image of dimensions 1280 x 720 you can calculate that this will take up:

(1280 * 720 * 4) / 1024 = 3600 kBs (Approx 3.5 mBs)
Mood