Forem: Salted Bytes

Picking up Rust(y) habits: learning Rust as a JS developer

Chris Quinn — Thu, 04 May 2023 04:16:35 +0000

Do you work with Javascript? I do: let's first pour one out for all the idiosyncrasies of the language we know and love and acknowledge that for all its faults, the JS/TS ecosystem is thriving: https://2022.stateofjs.com/en-US/conclusion/

While there's plenty of frameworks, micro-frontends and full-stack toolchains to master, there's something to be said for broadening your horizons. You may be wondering what other programming languages are worth learning, not least to expand your skills and improve your career prospects.

I'm here to pitch one to you: Rust. Rust has gained a lot of popularity in recent years, let's explore why Rust is a good choice for Javascript developers to learn.

What is Rust?

Rust is a systems programming language, originally developed at Mozilla as a personal project in 2006 by Graydon Hoare. It's designed to be a safe, fast, and concurrent language that can be used for a wide range of applications. Rust is particularly popular for developing low-level software, such as operating systems, device drivers, and web browsers.

Yeah, that all sounds kinda dry, but how about this: Rust was named after a hardy fungus, due to one of its primary strengths being the enforcement of memory safety. This is a key strength of the language, we'll come back to it.

Why should I learn Rust?

Here are five reasons why Rust is a good choice for you to learn right now in 2023:

1. Performance and Safety

One of Rust's primary advantages is its speed and safety. Rust is a compiled language, which means that code written in Rust is transformed into machine code that can be executed directly by a computer's CPU. This makes Rust much faster than interpreted languages like Javascript. Additionally, Rust has built-in memory safety features that prevent common programming errors, such as null or dangling pointer errors, which can cause crashes or security vulnerabilities.

Hot take incoming: This means that Rust code is much less likely to cause bugs or security vulnerabilities than Javascript.

2. Compatibility with WebAssembly

WebAssembly (WASM) is a low-level, portable bytecode format that is designed to be executed in web browsers. WASM allows developers to write high-performance code in languages other than Javascript and run them in the browser. Rust is an excellent language for writing code that can be compiled to WASM, meaning that you can write Rust code that can run directly in the browser, alongside or instead of Javascript. Check out this guide for the how and why: https://developer.mozilla.org/en-US/docs/WebAssembly/Rust_to_wasm

3. Learning Rust can improve your Javascript skills

Rust and Javascript are very different languages, but learning Rust can (albeit indirectly) improve your Javascript skills. Rust emphasizes the importance of code organization, strict typing and modularity - for me personally, I enjoyed being shaken out of my comfort zone by developing in Rust and making small, simple projects that allowed me to learn (and fail) and iterate quickly.

4. Rust's growing popularity

Rust is a relatively new language, but it has been rapidly growing in popularity over the past few years. Many large companies, such as Microsoft, Amazon, and Mozilla, have adopted Rust for in-house projects. Learning Rust now can put you in a good position to take advantage of the growing demand for Rust developers in the future. There are some projects that track programming language popularity such as the Tiobe index, which ranks Rust in the top 20 languages.

5. Have your cake and eat it

OK, fine, you might not be ready to wholesale drop our beloved JS and jump ship entirely, I understand. But what if I told you that you can leverage all the power of Rust within your Node projects? Let me introduce you to Neon:

https://neon-bindings.com/

Wrap up

Rust is a powerful and versatile language: its speed, safety, compatibility with WebAssembly, and growing popularity make it an excellent choice for Javascript developers to learn.

Whether you're looking to improve your skills, build high-performance web applications, or explore new career opportunities, Rust is definitely worth checking out.

https://www.rust-lang.org/learn
https://www.youtube.com/channel/UCaYhcUwRBNscFNUKTjgPFiA

Meteor.js Bootstrap Project

Chris Quinn — Mon, 08 Nov 2021 21:47:11 +0000

Cover photo by Oziel Gómez on Unsplash

Over at https://github.com/chrisquinnr/meteor-bootstrap you can find a quickstart app to get you up and running with a few Meteor basics, including accounts, routing, collections and adding a UI library like Bootstrap.

We're using good old Blaze in this example but a shiny new Svelte version will be coming soon.

Quickstart

Get Meteor installed: https://www.meteor.com/developers/install
Clone the repo
meteor npm install
meteor

Why Meteor?

Meteor has been making an awesome comeback over the past 18 months after the original development team moved on to new GraphQL-flavoured pastures. After being bought out by a VC firm, the project has picked up pace and as seen a renewed focus on addressing some of Meteor's roadmap.

Meteor is full stack JS framework ideally suited to realtime applications. Its early advantages were zero-config websockets and ES6 that #justWorked, but now I find that it's a great tool for prototyping and building MVPs, since we not only get to leverage the wonders of NPM but also the framework lets you bring your own frontend. Blaze, React, Angular and now Svelte are all options.

Like any framework, Meteor's benefits come at a price, in that you need to buy in to Meteor's highly opinionated structure and concepts. Fortunately these aren't too crazy and most of the rules can be broken if you want, but there are plenty of gotchas that will trip first time users up.

Hopefully that's where this bootstrap project can help, getting you from zero to... something a little faster. I'm not suggesting this is a gold standard, and I'd recommend the resources below for the authoratative take on things like application structure and best practice.

Resources

In suggested order of reading for anyone new to the framework.

Once you're up and running, why not check out the following?

Forums
Meteor Devtools
2021 Meteor Impact conference, with some great talks from the community and previews of upcoming features

And if you're hungry for more packages, examples and great community content, check these out:

Packages

Over and above anything I've written below, you should check out the Meteor Community Packages repo. This is a welcome new endeavour to bring awesome community-created modules under one roof.

Styling

Ironically the first batch of packages this project depends on aren't Meteor specific, so won't be found in .meteor/packages. We use meteor npm install to add Bootstrap and associated dependencies.

Utility, Subscriptions

underscore

Currently only used for a simple randomise function, but I use it in most projects. Of course, you can replace this with [lodash] or any number of other helper libraries. Consider only importing the functions you use to avoid loading in the whole library (see tree-shaking).

meteorhacks:subs-manager

A very useful package for controlling how your application behaves based on when subscriptions are ready. I've used this package on several enterprise projects and it's well worth it.

simple:reactive-method

Meteor helpers are powerful, they allow you to reactively update your UI based on data mutations over the wire. Sometimes though, you need to listen for the result of a server-side operation. Meteor.call is not inherently reactive, meaning you'd need to continously poll the server for the result you want. Enter Reactive Methods, a neat solution to this issue. A reactive method can call any Meteor.method you've defined on the server and, if used in a Template helper, will update reactively.

Routing & Templates

ostrio:flow-router-extra && mealsunite:flow-routing-extra

You'd be forgiven for being a little confused about the state of routing in Meteor. I know I was. The catch-all community-created solution for many years was Flow Router, which was thankfully picked up by Veliov Group (https://github.com/veliovgroup). It remains my choice too, but needs a little help from sibling packages to play nice with blaze layout below.

kadira:blaze-layout

A neat way to declare and control layouts in conjunction with your routing solution, obviously for Blaze.

Accounts

useraccounts:core / accounts-password@2.2.0 / useraccounts:bootstrap

The combination of these packages gives us user accounts, authentication and more straight out of the box! Awesome right! It's even extensible with other packages to add oAuth login providers.

Login splash screen

I've added an artifical loading screen, just because, by delaying the result of a subscriptions listener, you can find this in client/main.js. Usually logging in is pretty much instantaneous. On that note, the accounts-password / useraccounts:core packages are great, and completely extensible including social media login.

Twilio

If you dig a little deeper I've added instructions for an SMS-based login handler using Twilio (this was the main motivation for building this project in the first place). You need to set up Twilio as noted in the comments in /imports/api/apimethods/methods.js and then trigger the SMS using the provided Meteor method e.g. Meteor.call("smsLogin");

Essential terminal packages in 2020

James G. Best — Fri, 26 Jun 2020 08:44:51 +0000

This is the start of a new series about maximising your terminal experience. I will write about what I think are essential packages for the CLI, a simple but super effective Vim setup and setting some sane Tmux defaults.

In this first article, I am going to list some of what I think are essential CLI packages. These are ones I use every day and could not live without. I am leaving Vim and Tmux off this list as they will get there own articles.

I spend all my time in a terminal. This is where I do all my development, hacking and note-taking. Spending so much time there I want it to work for me, providing a buttery smooth experience.

Here is a list of my top CLI packages.

1. ZSH and oh-my-zsh:

This is my chosen shell. It has way too many features to list here but here are a choice few:

automatic cd: Just type the name of the directory
recursive path expansion: For example “/u/lo/b” expands to “/usr/local/bin”. This is not one I use much because I lead on the tools mentioned below.
spelling correction and approximate completion: If you make a small mistake typing a directory name, ZSH will fix it for you
plugin and theme support: ZSH includes many different plugin frameworks. This is where oh-my-zsh comings in. Its a community drive framework for managing your ZSH configuration.

2. FZF

FZF is a command-line fuzzy finder. It is super fast, light and works so well with all my other tools.

3. RipGrep (rg)

RipGrep is a stupid fast replacement for grep. It does away with lots of the hard to remember flags that grep requires. By default, it respects your .gitignore, and skips hidden files.

4. Autojump

Autojump is a super-fast way to navigate your filesystem. It learns the directories you visit most and remembers them for next time.

5. HTTPie

HTTPie is a user-friendly command line HTTP client. It has JSON support, syntax highlighting and lots more.

6. Bat

Bat is a drop-in replacement for cat but with superpowers. It's highly configurable and supports syntax highlighting.

7. exa

exa is a modern replacement for ls. It is highly configurable, provides better defaults.

8. twf

twf is a tree view explorer inspired by fzf.

You can find my dotfiles here. This is how I use them, how will you?

Thanks for reading 🙏

If there is anything I have missed, or if there is a better way to do something then please let me know.

Check out our software focused podcast - Salted Bytes

Javascript robotics: The Johnny Five REPL

James G. Best — Fri, 05 Jun 2020 06:54:27 +0000

In the previous article, we discussed how to get up and running with Johnny Five and the ESP8266 micro-controller. If you are not sure how to get set up I recommend you read that article first.

Previously we created a simple script that allowed us to control the onboard LED with our keyboard. This required us to install the keypress package and listen in process.stdin. This is not a bad approach but there is a better one.

Johnny Five comes packaged with a REPL. A REPL (read-eval-print-loop) is an interactive language shell giving a simple interactive interface to the Johnny Five API. We can control our robots with the REPL but there is some set up first.

Setting up the REPL

We need to make the REPL aware of our hardware by injecting the instance of the hardware into our script. We are using the script from before but with the keyboard code stripped out:

const { EtherPortClient } = require("etherport-client")
const { Board, Led, Pin } = require("johnny-five")

const board = new Board({
  port: new EtherPortClient({
    host: "192.168.1.109",
    port: 3030,
  }),
  repl: false,
})

const LED_PIN = 2

board.on("ready", () => {
  console.log("Board ready")
  var led = new Led(LED_PIN)
})

Now, let's add the REPL code. Update the board ready callback to look like this:

[...]
board.on("ready", function() {
  /*
    Initialize pin 2, which
    controls the built-in LED
  */
  var led = new Led(LED_PIN);

  /*
    Injecting object into the REPL
    allow access while the program
    is running.

    Try these in the REPL:

    led.on();
    led.off();
    led.blink();

  */
  board.repl.inject({
    led: led
  });
});

With this simple addition, we now have access to all the functions available on the LED object.

Limiting access

But what if we don't want to give our users unfettered access? What if we only want to give access to specific functions or write functions that do more than just control the hardware. Maybe we want to add logging or provide more appropriate function names. Well, we can write our own functions that are available in the REPL and inject those instead.

[...]
board.on("ready", function() {
  /*
    Initialize pin 2, which
    controls the built-in LED
  */
  var led = new Led(LED_PIN);

  board.repl.inject({
    // Allow limited on/off control access to the
    // Led instance from the REPL.
    on: function() {
      led.on();
    },
    off: function() {
      led.off();
    },
    flash: function () {
      led.blink();
    },

  });
});

This script will make on(), off() and flash() functions available in the REPL.

And that is it. A nice, short intro to the Johnny Five REPL. Until you start hooking your scripts up to WebSockets or a REST API, I think this is one of the better ways to control your robots.

Thanks for reading 🙏

If there is anything I have missed, or if there is a better way to do something then please let me know.

Check out our software-focused podcast - Salted Bytes

This was originally posted on my website

Wireless javascript robotics with Johnny five and the ESP8266

James G. Best — Fri, 29 May 2020 13:49:51 +0000

Orignally post on my website

In this article, I will talk about the first steps needed to start building robots with Javascript. I will be using the infamous ESP8266 microcontroller, this is because it is super cheap and allows it not to be tethered to your machine in the way that an Arduino would be.

To allow us to write our robotics scripts in Javascript with will be using the Johnny-Five library written by Rick Waldron. The library supports a huge selection of boards and hardware. Although not all boards support all of the hardware.

Several other boards could be used as alternatives (Proton, Tessel) but these are considerable more expensive and not as easily available. It is also possible to use an Arduino attached to a Raspberry Pi (RPi) and you then interface wirelessly with the RPi but that seems a little unnecessary now.

There are better languages to build robots with, but being an engineer working primarily in Javascript, I was keen to keep things close to home. In this setup Javascript is not run on the microcontroller but is run through some custom firmware called the Firmata protocol. This does mean it runs slower than something like C would but generally for things like robots this is not much of an issue. The first step in this process is to upload the StandardFirmataWifi sketch onto our board but to be able to do that we need the Arduino IDE and for it to recognise our ESP8266 based boards.

Getting set up

The following instructions are based on using a mac. They will be very similar to other platforms.

Copy the following URL http://arduino.esp8266.com/stable/package_esp8266com_index.json. Open the IDE and go to the files menu and click on preferences. Add the URL to the ‘Additional Boards Manager URL’.

Close the preferences panel and click tools. Under tools select boards and then board manager. Navigate to esp8266 by esp8266 community and install the software for Arduino.

Once this has been done you should be able to program your ESP8266 based board, I am using the NodeMCU board.

Click the examples panel and select the Wireless Firamta sketch. We will be updating so make a copy now.

We need to update the header file wifiConfig.h with our network credentials. Update the values of char ssid[] ="" and char wpa_passphrase[] ="".

With this done we can now upload the sketch to our device. Once uploaded you can close the Arduino IDE.

Don’t forget that the ESP* boards have a different pin layout to the Arduino boards. See the picture below for an example.

Now that we are all set up on the microcontroller we need to create a new node project and install the needed packages.

Our first robot script

Create a new folder for the project and initialise a new node project

mkdir helloWorld && cd $_ && npm init -y

Now we need to install Johnny-Five and the ethernet client that allows us to connect wirelessly.

npm install johnny-five ethernet-client keypress

With this done we are set to write our first script.

const { EtherPortClient } = require("etherport-client")
const { Board, Led, Pin } = require("johnny-five")
const keypress = require("keypress")

const board = new Board({
  port: new EtherPortClient({
    host: "192.168.1.109",
    port: 3030,
  }),
  repl: false,
})

keypress(process.stdin)
const LED_PIN = 2

board.on("ready", () => {
  console.log("Board ready")
  var led = new Led(LED_PIN)
  console.log("Use Up and Down arrows for On and Off. Space to stop.")

  process.stdin.resume()
  process.stdin.setEncoding("utf8")
  process.stdin.setRawMode(true)

  process.stdin.on("keypress", (ch, key) => {
    if (!key) {
      return
    }

    if (key.name === "q") {
      console.log("Quitting")
      process.exit()
    } else if (key.name === "up") {
      console.log("Blink")
      led.blink()
    } else if (key.name === "down") {
      console.log("Stop blinking")
      led.stop()
    }
  })
})

We need to replace 10.0.0.49 with the IP assigned to our board. I use an app called Fing but this information can be found out from the Serial monitor in the Arduino IDE.

This simple script will make the allow you to turn the onboard led on and off. Nothing fancy but paves the way for much more exciting things. To execute the file node index.js. You should see something similar to this:

$ node hello.js
1590554783332 SerialPort Connecting to host:port: 192.168.1.109:3030
1590554783334 Connected Connecting to host:port: 192.168.1.109:3030
1590554793338 Use Up and Down arrows for On and Off. Space to stop.

Now that the board is set up we are ready to create some more interesting projects. Johnny Five provides such a gentle introduction to robotics in Javascript but allows you to do so much as you have the wealth of packages in NPM and hundreds of public APIs that you can lean on to create great projects.

The next article will be a nice short one, introducing the Johnny Five repl and why it is great for prototyping your next project.

Thanks for reading 🙏

If there is anything I have missed, or if there is a better way to do something then please let me know.

Check out our software focused podcast - Salted Bytes

Fixing coc-tsserver errors due to Deno

James G. Best — Thu, 28 May 2020 13:56:18 +0000

This is a quick post detailing how to fix issues with coc-tsserver.

I am a long term Neovim user and feel that the only Intellisense engine to use is CocVim. It is simply amazing. It breathes so much power into you Vim setup.

I write Typescript daily and so use the coc-tsserver plugin. It gives all the power of VSCodes typescript engine in NeoVim. But recently it broke. It was reporting errors when there was nothing wrong. I made sure all my dependencies we up to date and still nothing. All I was seeing was this:

The error message is: The error message is: [tsserver 2307] [E] Cannot find module <import-path>

Something was wrong.

Thankfully someone was having the same issue and had created an issue in the CocVim git repo. It turns out that there is a bug in the coc-deno plugin that has some problems with non-deno projects.

Thankfully the fix is simple. Disable the deno plugin for non deno projects.

With in Vim: :CocList extensions and find the Deno plugin. Press tab and select d to disable it. Restart Vim and all your issues should have disappeared.

Thanks for reading 🙏

If there is anything I have missed, or if there is a better way to do something then please let me kno

Time controlled colour schemes for Vim and Iterm2

James G. Best — Tue, 26 May 2020 20:46:19 +0000

This was originally posted on my own website

If you have read any of my other articles you will know that I live in a terminal. All my work is done in Iterm2, using NeoVim, Tmux and a multitude of other tools. You will probably also know that I have taken the time to get my terminal and Vim looking just how I like it. I have written a theme (Ariake) for both Iterm2 and Vim with light and dark variants.

The reason for the light and dark variants are to help with working through the day into the evening. During the day I find it easier on the eyes to have a light theme. In the evening, a dark is better. But I would rarely remember to make the switch. I figured there must be a way to automate the process. It turned out to be pretty simple.

Setting up Vim

The update to Vim was super simple. Simply add the following lines to your init.vim

if strftime("%H") < 17
  set background=light
else
  set background=dark
endif

This follows the 24hr clock so update the 17 (5 pm) accordingly. I have mine change at around 5 pm. Now every time you openVim the time would be checked and the background colour updated accordingly.

Setting up Iterm2

This was a little more involved but nothing to hard. Iterm2 gives the user access to a Python API. With this, we have access to a huge array of functionality and so we can programmatically update it. In our case, we want to update the colour schema of our profile.

From the menu select Scripts > New Python Script and follow the wizard. It does not matter what you select as we are gonna replace the whole lot anyway. Once you have completed the wizard, open the script and replace the contents with the script below.

#!/usr/bin/env python3.7

import asyncio
import datetime
import iterm2

# Clock time to change colours.
LIGHT_TIME=(7, 0)
DARK_TIME=(17, 0)

# Color presets to use
LIGHT_PRESET_NAME="ariake-light"
DARK_PRESET_NAME="ariake-dark"

# Profiles to update
PROFILES=["Ariake"]

def datetime_after(t, time):
    today = datetime.datetime(t.year, t.month, t.day, time[0], time[1])
    if today > t:
        return today
    # Same time tomorrow
    return today + datetime.timedelta(1)


def next_deadline_after(t):
    light_deadline = datetime_after(t, LIGHT_TIME)
    dark_deadline = datetime_after(t, DARK_TIME)
    print("light {} dark {}".format(light_deadline, dark_deadline))
    if light_deadline < dark_deadline:
        return (LIGHT_PRESET_NAME, light_deadline)
    return (DARK_PRESET_NAME, dark_deadline)

def get_duration():
    now = datetime.datetime.now()
    preset_name, deadline = next_deadline_after(now)
    duration = (deadline - now).seconds
    print("Sleep for {} seconds until {}".format(duration, deadline))
    return duration, preset_name

async def set_colors(connection, preset_name):
    print("Change to preset {}".format(preset_name))
    preset = await iterm2.ColorPreset.async_get(connection, preset_name)
    for partial in (await iterm2.PartialProfile.async_query(connection)):
        if partial.name in PROFILES:
            await partial.async_set_color_preset(preset)

async def main(connection):
    while True:
        duration, preset_name = get_duration()
        await asyncio.sleep(duration)
        await set_colors(connection, preset_name)
        await asyncio.sleep(1)

iterm2.run_forever(main)

The only things that need changing are marked with comments. I found the script console handy for debugging the scripts. Once the script is complete you can activate it Scripts > [you script name]. If you want it to run automatically, move the script to $HOME/Library/ApplicationSupport/iTerm2/Scripts/AutoLaunch. You may need to create this folder.

Now that the scripts are in place you should have a lovely self-changing development environment allowing you to code all day and night 😀.

Thanks for reading 🙏

If there is anything I have missed, or if there is a better way to do something then please let me know

Avoiding that awkward BBC interview moment with Google Calendar, IFTTT, Tasker and a Raspberry Pi.

James G. Best — Mon, 23 Mar 2020 17:13:35 +0000

Having experienced this in my first week of working at home I knew I needed a solution for letting my wife and kid know when I was going to be in a meeting/pair programming. I could just shout downstairs but where is the fun in that? By automating it, it is also one less thing to have to remember in what is shaping up to be a stressful time for everyone.

I wanted this to be a quick Sunday evening project that only took a couple of hours so needed it to be simple and use the kit I already had. I also wanted it to work without the Raspberry Pi (RPi) being accessible from outside my home network.

I could have completed this project in a much simpler way if I had allowed access to the RPi from the outside world but in a world where IoT devices are the target of cyber attacks I wanted to limit the exposure.

On the hardware side of things, it seemed obvious to use an RPi and Mote LEDs. I have them already and they are simple to work with.

Mote is a collection of components allowing you to easily work with LEDs. The visual side of this project could be anything you have knocking around. I just happened to have these.

I am using an RPi 3 for this but you could any Pi that has is network connected.

All my meetings are in Google Calendar so I just needed a way to trigger an event when my meetings start and finish. If This Than That (IFTTT) is perfect for this. Google Calendar is the THIS of IFTTT and a webhook is the THAT.

I wanted this to be a quick project with as little programming as possible so I needed a way to accept the webhook but also be able to perform actions on a device in my local network. This part took a little longer to figure out, but a combination of Tasker and AutoRemote was able to perfectly meet my needs.

Tasker is an automation app that allows users to perform actions based on an event.

AutoRemote allows devices to communicate with each other without any user interaction.

N.B This article assumes some previous knowledge of Tasker and AutoRemote and so the instructions may be brief

Tasker and AutoRemote are built to work with each other and so we can use AutoRemote as a way of triggering an action in Tasker. AutoRemote is available as a plugin in Tasker.

AutoRemote acts as our "server" for the IFTTT webhook to callout to. When it receives a request, an event is triggered in Tasker which in turn sends a REST request to a local flask app that is running on the RPi. This Flask app controls the Mote LEDs.

Setting up Tasker and AutoRemote

In AutoRemote we need to register IFTTT as a device. Click the phone icon in the tab bar and then click the IFTTT logo and follow the instructions. This will give you a URL that can be added to the IFTTT webhook. It will look something like this:

https://autoremotejoaomgcd.appspot.com/sendmessage?key=[***yourKey***]&sender=[***yourId***]&message=IFTTT_MEETING_BUSY=:=true

Notice message=IFTTT_MEETING_BUSY=:=true this is how we pass properties to AutoRemote. The left side of =:= is how we can filter incoming requests and the right side are any params you want to pass in.

With this set up we now need to trigger events in Tasker. Under the profiles tab create a new one profile selecting event -> plugin -> AutoRemote -> AutoRemote. Edit the configuration and add the name of the event (the left side of the request from IFTTT e.g IFTTT*MEETING_BUSY). Next, click back and add the action. In my case, I wanted to perform an HTTP request* to my RPi but there is a multitude of things that Tasker can do for you.

Once set up your profiles will look like this

The final step is setting up the local server to trigger the Mote lights. I wrote a really simple Flask app that listens to requests and calls the correct Mote methods. It looks something like this:

import motephat
from flask import Flask, jsonify, make_response

app = Flask(__name__)

motephat.set_brightness(0.5)
motephat.configure_channel(1, 16, False)
#motephat.configure_channel(2, 16, False)
#motephat.configure_channel(3, 16, False)
#motephat.configure_channel(4, 16, False)

colour = 'FFFFFF'
status = 0

def mote_on(c):
    for channel in range(1, 5):
            for pixel in range(16):
                motephat.set_pixel(channel, pixel, 255, 0, 0)
    motephat.show()

    return True

def mote_off():
    motephat.clear()
    motephat.show()
    return True

def get_status():
    global status
    for channel in range(4):
        for pixel in range(16):
            if motephat.get_pixel(channel + 1, pixel) != (0, 0, 0):
                status = 1
    return status

@app.route('/')
def hello():
    return 'hello'

@app.route('/mote/api/v1.0/<string:st>', methods=['GET'])
def set_status(st):
    global status, colour
    if st == 'on':
        status = 1
        mote_on(colour)
    elif st == 'off':
        status = 0
        mote_off()
    elif st == 'status':
        status = get_status()
    return jsonify({'status': status, 'colour': colour})

@app.errorhandler(404)
def not_found(error):
    return make_response(jsonify({'error': 'Not found'}), 404)

if __name__ == '__main__':
    mote_off()
    app.run(debug='true', host='0.0.0.0')

Now when you are about to go into a meeting your lights should look like this

Conclusion

I hope this was of some interest. I really enjoy these little projects that have limited time and scope. Obviously, there are so many ways that this could be done and some many improvements that could be made but this was only meant to be a little bit of fun on a Sunday night.

The Rise of No-Code (dude, where's my code)

Chris Quinn — Mon, 02 Mar 2020 20:49:12 +0000

On the latest episode of Salted Bytes, James and I tore into a veritable buffet of no-code web development platforms.

From Wix and Squarespace to Zapier via Google Sheets (did we just invent a new startup?), we talk about how no-code platforms provide much-needed glue between the myriad SaaS behemoths slugging it out for your time, attention and subscription dollars. But not everything is as rosy as some no-code proponents would say - we discuss some of the pitfalls of going all-in on no-code: anyone for some of that sweet vendor lock-in?

No-code is a polarising topic and super popular here on dev.to (check out https://dev.to/search?q=no-code), but contrary to some of the views we've seen James & I think no-code has it's place in a thriving digital marketplace and actually empowers business / product owners to either raise their game or push for that little bit of extra innovation (as a treat).

In researching this episode we found a whole bunch of super-salty takes on no-code from devs across the Twitterverse, from the thoughtful and considered to the downright savage - and we include them here for your pleasure. Enjoy.

Holy Salt!

How could you say something so brave and so true

Dadjoke.gif

It is like cloud

Low-effort Twitter screencaps aside, we're really interested to see what the NextBigThing^TM in no-code is, and even more interested to see if no-code continues to be such a polarising topic... or whether one day it'll sink into the doldrums of every day office life, like Clippy and and that guy who writes Excel macros.

James & I think no-code is a valuable part of the web dev ecosystem, and here to stay - what do you think? Why not check out our latest episode at the links below and let us know in the comments!

https://dev.to/salted-bytes-podcast
https://saltedbytes.rocks

Till next time

Chris

What (not?) to do in your new tech role

Chris Quinn — Fri, 07 Feb 2020 17:59:23 +0000

Recently on the Salted Bytes podcast we discussed what to do (and NOT) to do in your first few days at a new dev role.

Some of this advice was very applicable to most jobs:

"Get to know people"
"Always join in the first few social events after you start"
"Find and cherish your mentors"

For developers though, whether in your first role or your twentieth, we had some very industry-specific tips:

Don't cling dogmatically to your old tooling or coding style - it may be familiar but you need to learn the way things are done in your new place of work - it's very likely they've arrived at their stack for compelling reasons, which are worth hearing out, and respecting. One you've done that, if you still feel duty bound to evangelise your new colleagues on your perspective on tabs v space, go right ahead.
Get to know people outside of your immediate team. This can give you invaluable insight into your new role, either from top level strategy and culture or from the low to ground must know info like how the holiday calendar works and how to claim expenses. (most companies should absolutely cover this in your orientation, but let's be honest, it's not always thorough).
Be curious, and ask the obvious question. There's a great deal of pride, and conversely, imposter syndrome permeating software development. Don't be afraid to ask even the most humbling of questions: better now than 5 months down the line. There are myriad paths into development careers, not all of them computer-science based, and sometimes you'll encounter knowledge gaps that you didn't even know existed. Swallow that pride and ask the obvious question - clarity trumps assumption every day of the week.

James & I covered more tips & tricks on the Salted Bytes podcast. Why not go check it out?

https://dev.to/salted-bytes-podcast
https://saltedbytes.rocks

Till next time

Chris

A simple Elm, SCSS toolchain

James G. Best — Mon, 28 Oct 2019 08:51:30 +0000

Recently I have been knee deep in Typescript, React and Redux code. It is what I write every day at work and I love it! Typescript feels like one of those love hate things. You hate it until you try it and then you feel like writing Javascript without types is modern day savagery.

One morning during my daily morning scroll through Twitter I found this post. It talks about how if you use the stack I mentioned above (Typescript, React and Redux) that you would love Elm. I had looked at Elm before and although it interested me it never captured me enough to stick it out but this time I thought it might be different. This post is not about my journey into Elm as it is still in its infancy but about how I set up a simple project with Elm, SCSS and hot-reloading.

This post is not about my journey into Elm as it is still in its infancy. I am gonna run through how I set up a simple project with Elm, SCSS and hot-reloading. I realise there are lots of boilerplates out there but many of them just do too much. I want to learn in a simple understandable environment but with the perks of using something like CRA (create-react-app).

I required my starter package to do a few things.

Compile Elm
Compile SCSS
Create a dev server and hot reload I also wanted to stay away from the usual bundlers that we use in the JS world, like Webpack and Parcel. These tools are great but add a load of packages.

The project folder structure is as follows:

This is obviously personal taste, and this is how I like to set things up. SCSS folder structure is also personal taste but I use this as a starting point.

Most of the action happens in the package.json. We run and build our project with a number of npm scripts.

Elm

Watching Elm

The first task we are gonna cover is the compilation of our Elm code. We also need the compiler to be able to watch for changes and recompile. This is standard in JS projects these days and so why should it be any different in Elm. We are going to be using a file watcher called chokidar-cli. This is the same file watcher used in many of the most popular bundlers and task runners. First, let’s install it:

 # npm
 npm install — save-dev chokidar-cli

 # yarn
 yarn add -D chokidar-cli

and then add the following to the scripts section of the package.json

"scripts": {
   […]
   "watch:elm": "chokidar './src/**/*.elm' -c 'elm make ./src/Main.elm — 
     output ./public/js/elm.compiled.js' — initial"
   […]
 }

Here we are using chokidar to watch for changes to any file matching this regex ./src/*/.elm and then running the Elm make command elm make ./src/Main.elm — output ./public/js/elm.compiled.js

Building Elm

While we are dealing with Elm, let’s write the script to build the Elm project. This is very similar to the script above except we won’t use chokidar as we are not watching for changes. We are also adding the — optimize flag so that the js output is minified and optimised.

"scripts": {
   […]
   "build-elm": "elm make ./src/Main.elm — output 
     ./public/js/elm.compiled.js — optimize",
  […]
 }

SCSS

Watching and building SCSS

Next, we are gonna tackle watching and building our scss files. When watching we want the scss to recompile when changes are made. We will be using node-sass-chokidar for this. Let’s install the package:

 # npm
 npm install — save-dev node-sass-chokidar

 # yarn
 yarn add -D node-sass-chokidar

Dev server and hot reloading

This would not be a serious modern frontend toolchain without a dev server and hot reloading. For this we are gonna use browser-sync. Let’s install it.

 # npm
 npm install -g browser-sync

 # yarn
 yarn global add browser-sync

Let’s add another script. This once will start a server and watch all files in our public folder. Because the other watch scripts all compile into the public folder anytime we make any changes browser-sync will detect them and restart the server and refresh the browser.

"scripts": {
   […]
   "dev-server": "browser-sync start — server 'public' — files 
     'public/**/*.*'"
   […]
 }

Tying it all together.

Let’s tie it all together with a build and start script. For these, we want to be able to run multiple npm scripts at once. For this we will use one last package — npm-run-all. This allows you to run scripts sequentially or in parallel.

 # npm
 npm install — save-dev npm-run-all

 # yarn
 yarn add -D npm-run-all

With this installed we can write 2 final scripts. Let’s tackle the build script. We want to be able to compile both the scss and elm in a single command. All we do is pass the names on the scripts and we want them to run in parallel so we use the -p flag.

"scripts": {
   […]
   "build": "npm-run-all -p build-css build-elm "
   […]
 }

The last script is the one we will use the most. This starts our dev server and compiles (with file watching) both the Elm and SCSS.

"scripts": {
   […]
   "start": "npm-run-all -p watch-css watch:elm dev-server"
   […]
 }

And that is it. The complete scripts section should look like this:

{
  "scripts": {
   "start": "npm-run-all -p watch-css watch:elm dev-server",
   "watch:elm": "chokidar './src/**/*.elm' -c 'elm make ./src/Main.elm -  
     output ./public/js/elm.compiled.js' - initial",
   "build-css": "node-sass-chokidar sass/ -o public/css",
   "watch-css": "npm run build-css && node-sass-chokidar sass/ -o 
     public/css - watch - recursive",
   "build-elm": "elm make ./src/Main.elm - output 
     ./public/js/elm.compiled.js - optimize",
   "build": "npm-run-all -p build-css build-elm ",
   "dev-server": "browser-sync start - server 'public' - files 
     'public/**/*.*'"
   }
}

I am still really new to Elm development and I am sure there are better ways to build your projects but I wanted something simple that I could easily understand. I hope this helps in some way.

Running a python script on boot on a RPi

James G. Best — Mon, 14 Oct 2019 09:44:21 +0000

Once you are able to successfully run your python script from the terminal, what are your options to run the same script on booting the Raspberry Pi? This post details the issues I had getting my scripts to run on boot and how I fixed them.

TL;DR Make sure you are running your scripts as the correct user. Python scripts that use Pip packages will need to be run as the user used to install said packages or else they might not be available.

Writing python scripts is a relatively new thing for me. I love playing with the Raspberry Pi and generally write Nodejs. For most of the stuff I have been doing up until this point, Nodejs has been fine. But the Raspberry Pi is blessed with a wealth of hats performing a multitude of weird and wonderful things. The problem is that most of the libraries for these hats are written in Python. So I thought it was about time I start learning some python.

My first python script was controlling the Mote LEDs through MQTT. Writing the script did not take too long as the examples in the Pimoroni repos gave me enough to get started. I was able to run the script from the terminal and had it working fine. Obviously, we don't want to have a terminal session open all the time and we want to have the script start on boot (or reboot).

I had read that there are a number of ways to run a script on boot but that the preferred way was to add an entry into the /etc/rc.local file. This file is loaded when the Pi is booted and so should achieve our goal.

Have you ever seen the IP of the Pi print in the terminal output when the Pi is booting? This is where that command is run from.

So I added the following line to the file:

/usr/bin/python3 /home/pi/Code/desklights/desklights.py

and rebooted the Pi. Nothing! No logs, no error. Nothing! Very unhelpful. I tried every possible way of calling the script. And each one proved fruitless. Nothing.

What I needed was to see so sort of log output. I hoped that this would give me an idea of what was wrong. I updated the command to the following:

/usr/bin/python3 /home/pi/Code/desklights/desklights.py > /tmp/desklights.out > /tmp/desklights.err

This would write anything logging from the program to /tmp/desklights.out and and errors to /tmp/desklights/err. This was a key to solving the issue. The .out file was empty which indicated the script was failing. The `.err` file, on the other hand, contained this:

It was now clear what I needed to do. The python packages I had installed were install using the Pi user. This file runs as root and so does not have access to the installed packages. I need to make sure I am running my script as the Pi user and all should be fine and dandy.

sudo -H -u pi /usr/bin/python3 /home/pi/Code/desklights/desklights.py/home/pi/Code/desklights/desklights.py

Updating the script to include the change of user fixed my issue and allowed the script to run successfully on boot.

Thanks for reading 🙏