Posts From Category: teams

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};
}

Read More

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

Read More