DEV Community: Daniel Elkington

Teaching coding to kids

Daniel Elkington — Sun, 28 Aug 2022 12:54:25 +0000

Recently I was invited to teach an 80 minute programming class to a small class of high school students with special needs. I'm aware of some fantastic resources such as Hour of Code, which provides free short coding activities designed for absolute beginners. However, I find that these activities don't always feel "real" - you're usually writing code within a web app that feels like a game, and after writing the code required it feels more like you've simply won a game instead of having actually created an app that can be run and shared with others. Hour of Code is great for teaching students the logical thinking required when coding, but I feel like it misses the potential excitement that one could have in finding that they can actually build an app like the ones they use each day.

So I decided to try designing my own class to introduce students to code. My aims were:

Zero setup - students should not need to install anything new on their laptops
Students should use a real programming language
Students should start with an empty file, type some code in it, and run it to see the result
Students should need to copy as little boilerplate code as possible
The code should do something visual and fun
The code should use very simple programming concepts such as function calls, and basic control flow

And so I created Tribot, a library that allows programmers to easily create a website where a triangular robot (or Tribot) attempts to retrieve some treasure.

I wasn't sure how it would go. I was worried that my class might be too advanced for the students, and they would just become frustrated. Or maybe they would find it boring compared to the more game-like Hour of Code activities that are available.

Anyway, here's how it went.

First I introduced myself, explaining that I was a software developer who makes apps and games. The students all had laptops, and I got them all to open up Chrome and showed them how to open the DevTools, which they'd never seen before. They then followed along as I executed some basic commands into the console. They learned how to do a JavaScript alert, a prompt, and basic control flow as we wrote a very simple program like the following:

let name = prompt("What is your name?")
if (name == "Bob") {
  alert("Hello Bob!!!")
} else {
  alert("What an interesting name!")
}

Having experienced the basics of JavaScript, it was time to introduce the Tribot. I got them to open up TextEdit/Notepad, and they copied the following boilerplate, which imported the library I created:

<script type="module" src="https://unpkg.com/tribot"></script>
<script type="module">
// Your code goes here
</script>

I then showed them how to save this as index.html and open the file in their browser, and they saw this:

Clicking "Start" didn't do anything - it was up to them to make the robot go to the treasure. I showed them a few commands, and they soon got the hang of it - they could move the robot with commands like the following:

moveForward()
turnRight()
moveForward()

They could also have fun running functions to change the Tribot's colour and make it beep.

At this point they quickly got into the hang of changing some code, saving the file, and refreshing the browser to run it.

(If you know JavaScript you may be confused about how the code is working under the hood - how can they call synchronous functions to move the Tribot without freezing the browser? The answer is that when we load the page we run the whole script but simply save the actions performed, and then gradually replay them with some delays to animate the Tribot.)

Soon enough some of the students were able to get the Tribot to reach the treasure. At this point I told them that there was another function they could call at the start of their script - setRoom(2) to change to another room. And there were 3 rooms in total for them to try.

Some of the students were able to quickly get the Tribot winning in these rooms, so I then revealed that they could create their own custom rooms:

setRoom([
  [S,_,_,_],
  [W,_,_,W],
  [T,_,_,W]
])

And finally I challenged them to see whether they could write some code for a Tribot that could find the treasure in any room without needing its code changed.

Overall the students seemed to enjoy the class, and were all able to get through at least part of the activity. Some of them were asking really good questions about how they could go about putting this web app on the internet, or how they could add keyboard controls to the Tribot.

Very exciting to see how fast these students were able to learn some simple programming - I'm sure they all have bright futures ahead of them.

The Tribot code is open source and freely available on GitHub.

Vue Camera Gestures - add AI powered gesture controls to your app in 1 line of HTML

Daniel Elkington — Sat, 19 Oct 2019 10:52:28 +0000

Consider a basic Vue application. There's a ball, and clicking "left" or "right" buttons make it move left or right.

We'll suppose that you have a component called MovingBall that deals with displaying the ball and moving it, and we are using that component as follows:

<template>
  <div>
    <moving-ball :direction="direction"></moving-ball>
    <button @click="left">Left</button>
    <button @click="right">Right</button>
  </div>
</template>

<script>
import MovingBall from './MovingBall'
export default {
  components: {
    MovingBall
  },
  data: function () {
    return {
      direction: null
    }
  },
  methods: {
    left () {
      this.direction = 'left'
    },
    right () {
      this.direction = 'right'
    },
  }
}
</script>

Controlling the ball using buttons is a bit boring. What if you could instead control it by gesturing a direction to your device's camera?

If you think that would take a lot of code to achieve, think again! I've just released a library, Vue Camera Gestures, that will let you do that in just one line in your component's template. We just need to install the library,

npm install vue-camera-gestures

import and register the component,

import CameraGestures from 'vue-camera-gestures'
export default {
  components: {
    CameraGestures
  },

and put the following line into our template, under the buttons.

<camera-gestures @left="left" @right="right"></camera-gestures>

And that's it! When the user opens the page, they'll be prompted to train a left and a right gesture, verify them, and then they can control the ball using the trained gestures.

Note that the gestures don't have to involve pointing - the user can do basically anything they're comfortable with. Under the hood, the transfer learning technique is used to retrain an existing image recognition library. We then use a KNN classifier algorithm which, after training, takes a frame of video, and finds the 10 nearest frames from the training phase that match. We assume that the user is performing the gesture that has the most matching cases.

But you don't need to know any of that - you can just use the component, and have all the AI complexity abstracted away. The camera-gestures component's events are completely configurable, and you can have as many of them as you like. So if you had a blogging app, you could do something like

<camera-gestures
  @newPost="new"
  @savePost="save"
  @enterBoldText="bold"
  @undo="undo"
  @redo="redo"
></camera-gestures>

and the user will be prompted to train the five gestures, and can then use them to control the blogging app. After training, the specified events will be fired whenever the user performs the associated gesture.

Give it a go! Easily make your app more accessible/fun! Find a demo and full documentation at vue.cameragestures.com and explore the source code here.

Vue's Darkest Day

Daniel Elkington — Fri, 21 Jun 2019 12:33:18 +0000

Today I was amazed to see the usually positive and friendly VueJS community descend into a bitter war. Two weeks ago Vue creator Evan You released a Request for Comment (RFC) for a new function-based way of writing Vue components in the upcoming Vue 3.0. Today a critical Reddit thread followed by similarly critical comments in a Hacker News thread caused a flood of developers to flock to the original RFC to voice their outrage, some of which were borderline abusive. It was claimed in various places that

All Vue code would have to be rewritten in a totally new way because the existing syntax was being removed and replaced with something else;
All the time people had spent learning Vue had been wasted given everything was about to change;
The new syntax was worse than the old, did not enforce structure, and would lead to spaghetti code;
The Vue Core team had suddenly implemented a huge breaking change without any consultation;
Vue is turning into React!
No, Vue is turning into AngularJS/Angular!
All HTML now needs to be written as a giant string!

With walls of negative comments on the Reddit Thread one may be surprised to discover on going to the RFC page that You's RFC has an overwhelmingly high ratio of positive to negative emoji reactions, and many of the initial comments were quite positive. Indeed, the very first comment is particularly full of praise.

I was the person who wrote that first comment. I happened to get a notification that there was a new RFC, read it straight away, saw that it was just what I wanted from Vue 3.0 and that it would help immensely, and left the first comment within 15 minutes of the RFC being published to express my gratitude. I hope to expand here on why I think the new proposal is such a great idea, but first, to address some of the criticism.

I suspect that many people got a little worked up after reading the Hacker News or Reddit threads which had some somewhat misleading comments, and voiced their outrage without reading the original proposal. Evan You has now updated the proposal with a Q&A that addresses many of the issues people have, but to summarise,

You don't need to rewrite any code if you don't want to - the new syntax is additive, and the old syntax will remain valid throughout Vue 3.0 and as long as it is still widely used. Even if it eventually gets removed from the Core code, plugins could easily allow the old syntax to be still 100% valid.
Time spent learning Vue was not wasted - the new component syntax uses the same concepts that you spent time learning, and other concepts such as Single File Components, templates, and scoped styles work exactly the same.
A change hasn't been made without consultation - the RFC is the consultation. The new syntax is still a long way from being released.
And no, HTML code doesn't need to be written as a giant string.

A slightly more subjective point is that the new syntax is inferior to the old, and will lead to less structured code. I hope to demonstrate with a simple example why I got so excited when I saw the RFC, and why I think it is superior and will lead to better structured code.

Consider the following fun component that allows a user to enter details of their pet. Note that

A message gets displayed when they finish typing their pet's name;
Another message gets displayed after they select their pet's size.

You can try out a demo of the component here and can view the full code using Vue 2.x here (see components/Vue2.vue).

Consider the JavaScript of this component:

export default {
  data() {
    return {
      petName: "",
      petNameTouched: false,
      petSize: "",
      petSizeTouched: false
    };
  },
  computed: {
    petNameComment: function() {
      if (this.petNameTouched) {
        return "Hello " + this.petName;
      }
      return null;
    },
    petSizeComment: function() {
      if (this.petSizeTouched) {
        switch (this.petSize) {
          case "Small":
            return "I can barely see your pet!";
          case "Medium":
            return "Your pet is pretty average.";
          case "Large":
            return "Wow, your pet is huge!";
          default:
            return null;
        }
      }
      return null;
    }
  },
  methods: {
    onPetNameBlur: function() {
      this.petNameTouched = true;
    },
    onPetSizeChange: function() {
      this.petSizeTouched = true;
    }
  }
};

Essentially we have some data, properties computed off that data, and methods that manipulate that data. And notice that in Vue 2.x there is no way to keep related things together. We can't keep the petName data declaration next to the petNameComment computed property or the onPetNameBlur method because in Vue 2.x things are grouped by type.

Of course this doesn't matter too much for a small example like this. But imagine a bigger example, that had multiple pieces of functionality that needed data, computed, methods, and even a watcher or two. There's currently no good way to keep related things together! One might use something like Mixins or Higher Order Components but these have issues - it's hard to see where properties are coming from and there are problems with namespace clashing. (And yes, in this case it would be possible to split things into multiple components, but consider this similar example where it isn't.)

Rather than organising components by option type, the new proposal allows us to organise components by actual functionality. It's similar to how you organise your personal files on your computer - you usually don't have a 'spreadsheets' folder and a 'word documents' folder, instead you might have a 'work' folder and a 'holiday plans' folder. Consider the above component written in the proposed syntax (as best as I am able to without seeing the output - let me know of any bugs you see!):

import { state, computed } from "vue";
export default {
  setup() {
    // Pet name
    const petNameState = state({ name: "", touched: false });
    const petNameComment = computed(() => {
      if (petNameState.touched) {
        return "Hello " + petNameState.name;
      }
      return null;
    });
    const onPetNameBlur = () => {
      petNameState.touched = true;
    };

    // Pet size
    const petSizeState = state({ size: "", touched: false });
    const petSizeComment = computed(() => {
      if (petSizeState.touched) {
        switch (this.petSize) {
          case "Small":
            return "I can barely see your pet!";
          case "Medium":
            return "Your pet is pretty average.";
          case "Large":
            return "Wow, your pet is huge!";
          default:
            return null;
        }
      }
      return null;
    });
    const onPetSizeChange = () => {
      petSizeState.touched = true;
    };

    // All properties we can bind to in our template
    return {
      petName: petNameState.name,
      petNameComment,
      onPetNameBlur,
      petSize: petSizeState.size,
      petSizeComment,
      onPetSizeChange
    };
  }
};

Note that

It's ridiculously easy to group related things together;
By looking at what gets returned by the setup function we can easily see what we have access to in our template;
We can even avoid exposing internal state ('touched') that the template doesn't need access to.

On top of that, the new syntax easily allows full TypeScript support which was difficult to achieve in the Vue 2.x object-based syntax. And we can easily extract out reusable logic into reusable functions. Something like

import { state, computed } from "vue";

function usePetName() {
  const petNameState = state({ name: "", touched: false });
  const petNameComment = computed(() => {
    if (petNameState.touched) {
      return "Hello " + petNameState.name;
    }
    return null;
  });
  const onPetNameBlur = () => {
    petNameState.touched = true;
  };
  return {
    petName: petNameState.name,
    petNameComment,
    onPetNameBlur
  };
}

function usePetSize() {
  const petSizeState = state({ size: "", touched: false });
  const petSizeComment = computed(() => {
    if (petSizeState.touched) {
      switch (this.petSize) {
        case "Small":
          return "I can barely see your pet!";
        case "Medium":
          return "Your pet is pretty average.";
        case "Large":
          return "Wow, your pet is huge!";
        default:
          return null;
      }
    }
    return null;
  });
  const onPetSizeChange = () => {
    petSizeState.touched = true;
  };
  return {
    petSize: petSizeState.size,
    petSizeComment,
    onPetSizeChange
  };
}

export default {
  setup() {
    const { petName, petNameComment, onPetNameBlur } = usePetName();
    const { petSize, petSizeComment, onPetSizeChange } = usePetSize();
    return {
      petName,
      petNameComment,
      onPetNameBlur,
      petSize,
      petSizeComment,
      onPetSizeChange
    };
  }
};

In Vue 2.x I often find myself writing a "monster component" that is hard to break up into smaller pieces - it can't be decomposed into other components because there is too much happening based on a small amount of state. However using the proposed syntax it's easy to see how big components could have logic broken up into smaller reusable pieces, moved into separate files if necessary, leaving you with small, easy-to-understand functions and components.

Is this Vue's darkest day so far? It looks like it. What was until now a community mostly united behind the project's direction has splintered. But I have hope that people will take another look at a proposal that doesn't break anything, still allows them to group things by option type if that's what they like doing, but allows for so much more - clearer code, cleaner code, more interesting library possibilities, and full TypeScript support.

Finally, when using open source software, it's good to remember that the maintainers are putting a lot of effort into something that you get to use for free. Some of the borderline abusive criticism seen today is something that they really shouldn't have to put up with. Thankfully the disrespectful comments were a minority (albeit a sizeable one) and many were able to express themselves in a more respectful manner.

Update June 23 2019:
I wrote the original post very quickly and without expecting it to receive the attention that it has. Since then I've realised that the code example was too complex for the point I was trying to illustrate, so I've simplified it greatly. The original code sample can be found here.

A bot that tweets new DEV articles about Vue

Daniel Elkington — Sun, 03 Mar 2019 10:41:33 +0000

So I love VueJS. And I love dev.to articles about Vue. And I don't want to miss any. I could just keep constantly refreshing the #vue tag on dev.to, but instead I decided it would be more convenient to see all new Vue articles in my Twitter feed. So I wrote my a Twitter bot - @TheVueDev.

Basic architecture and flow

The basic flow I decided on was the following

An Azure Function written in Typescript runs every minute,
The function scrapes dev.to/t/vue/latest to check for new articles,
If new articles are found, they get automatically tweeted!

An Azure Function is Microsoft Azure's "serverless" offering that allows you to run a small piece of code in response to some trigger. There's a generous free tier (1 million free executions per month!) that means this project is very cheap, though not entirely free as the Function requires an Azure Storage account to store some things related to the function. Still, the overall cost for this project is less than US$1/month.

Setting up Twitter

Setting up the Twitter account is relatively straightforward (you just need to be prepared to answer a lot of questions that Twitter understandably asks to try to prevent abuse). After setting up a Twitter account for the bot at twitter.com, I went to developer.twitter.com and followed the prompts to apply for a developer account. Finally, I created a new "app", filled in some more details, requested some access tokens, and was presented with a page that looks like this:

That's right, there are four tokens/keys, and we're going to need all of them!

The Function

I followed the quickstart guide in the Azure docs to create an Azure Function in Visual Studio code, selecting "JavaScript" as the language. I then ran tsc --init to add TypeScript, and was ready to start coding!

Running code every minute

For each function you create, you need to specify what will trigger it (find all the options here). In my case I wanted to trigger the function every minute, which could be done with the following code in the function's function.json file:

{
  "disabled": false,
  "bindings": [
    {
      "schedule": "0 * * * * *",
      "type": "timerTrigger",
      "direction": "in",
      "name": "everyMinuteTimer"
    }
  ]
}

Scraping dev.to

I want to thank Sarthak Sharma for his amazing Vue CLI - check it out if you haven't already. The code he used to scrape dev.to gave me a lot of pointers for this project.

Article No Longer Available

Like Sarthak, I used the x-ray library to help with scraping. Every minute I want to load up https://dev.to/t/vue/latest and scrape details of the latest VueJS articles. With the help of the Chrome devtools, grabbing things like the article title, author details, and a link to the article is quite straightforward - querying the page uses syntax very similar to CSS.

const xray = Xray()
const articleScrapeData = await xray(
  'https://dev.to/t/vue/latest',
  '#substories .single-article',
  [
    {
      title: '.index-article-link .content h3',
      author: 'h4 a',
      link: '.index-article-link@href',
      tags: ['.tags .tag'], // need the tags so we can strip them out of the title
      authorLink: '.small-pic-link-wrapper@href'
    }
  ]
)

That will return an array of the articles on the page. There's a bit of cleanup of the data I needed to do (here's the code if you're interested). Of course, it makes sense to tweet out the author's Twitter handle if they've provided it, so I scraped that from the Author page.

  const socialLinks: string[] = await xray(article.authorLink, [
      '.profile-details .social a@href'
  ])
  const twitterLink = socialLinks.find(x => x.includes('twitter.com/'))
  if (twitterLink != null) {
    // twitterLink is in the form https://twitter.com/{blah}
    const twitterURL = new URL(twitterLink)
    const twitterHandle = '@' + twitterURL.pathname.substring(1)
  }

For each article, I could then construct the tweet. I decided that tweets would contain the article title, then the author's twitter handle or name, and finally a link to the article (which dev.to very nicely formats with a beautiful card).

const tweetContent =
`${article.title}

{ ${article.twitterHandle || article.authorName} }
${article.link}` // Yay for Template Literals!

Now all we need to do is Tweet the articles!

The dilemma

The problem was that the function can't just tweet all the "recent articles" we find each minute, or we'll end up tweeting heaps of duplicates. Compounding the problem is that dev.to doesn't seem to provide an easy way to see when an article was published to anything more granular than the nearest day. I came up with three possible solutions:

Only run the function once every 24 hours, and tweet out any articles with yesterday's date. Problem is that if the function fails for some reason we'll miss a day, and if it works followers need to wait up to 24 hours for new articles!
Implement some sort of storage to keep track of the articles that have been tweeted. But this seems like a bit of overkill for a project like this. ^{(You could argue that Typescript is also overkill for a project like this, but I wanted to use it for learning purposes ☺️)}
Use the Twitter API to get the latest articles that the account has tweeted, do a comparison with the latest ones found on dev.to, and tweet out any that haven't yet been tweeted.

Option 3 seemed the most straightforward. Scraping dev.to/t/vue/latest only returns the last 8 articles, while the Twitter API returns the last 200 tweets from the account, so the function should always be able to accurately determine whether an article has been tweeted.

Using the Twitter API

Omar Sinan's article on building a Twitter bot was very helpful - check it out!

Article No Longer Available

Like Omar, I used the Twit library to help with tweeting. Connecting it to @TheVueDev was as simple as pasting in the four keys and tokens from the Twitter app page (as environment variables of course!).

this.t = new Twit({
  consumer_key: process.env.twitter_consumer_key,
  consumer_secret: process.env.twitter_consumer_secret,
  access_token: process.env.twitter_access_token,
  access_token_secret: process.env.twitter_access_token_secret
})

Then we just tweet out our articles if they haven't yet been tweeted!

// Get recent tweets
const res = await this.t.get('statuses/user_timeline', {
  screen_name: 'TheVueDev'
})
const recentTweets = <any[]>res.data
// Determine if article has been tweeted yet
// Need to look at entities.urls.expanded_url because Twitter 
// automatically shortens the URL in the tweet itself.
if (recentTweets.find(x =>
  x.entities.urls.find((u: any) => u.expanded_url === articleLink)
  ) == null) {
  // Article hasn't yet been tweeted - tweet it!
  await this.t.post('statuses/update', { status: tweetContent })
}

(Find the more efficient version of this code here.)

Deployment

Deploying the function to Azure can be done right from within Visual Studio code with a few button clicks using the Azure Functions extension. Neat!

And with that, I have a functioning Twitter bot, and can now easily know about all the new VueJS articles as they appear on dev.to!

Here's the Twitter account, and here's the full code, with step-by-step instructions for deploying your own bot to tweet out any dev.to tag of your choice!

danielelkington / twitter-vue-dev

A bot that lives in Azure Functions and tweets all dev.to VueJS articles

twitter-vue-dev

A bot that lives in Azure Functions and tweets all dev.to VueJS articles. Find it @TheVueDev.

dev.to article explaining how this was created.

This same code can be used to create a Twitter bot that tweets new articles from any valid dev.to tag.

Deployment

Follow these instructions to create your own Twitter bot that tweets dev.to articles for the tag of your choice. It will probably cost you a few cents a month in Azure Storage fees.

Setup Twitter account

Go to twitter.com and make a Twitter account for your bot.
While signed into your bot's Twitter account, go to developer.twitter.com, click "Apply", and then follow the prompts to apply for a developer account.
- When asked to "Select a user profile to associate", ensure your bot's account is selected.
- Fill in the requested information about what your developer account will be used for, accept the terms and…

View on GitHub