Forem: Kenneth Larsen

How I Stay on Top of 1:1s

Kenneth Larsen — Mon, 23 Aug 2021 08:01:59 +0000

Keeping track of 1:1s, action items, feedback and important news to deliver can be quite overwhelming. 1:1s are so crucial, and while I've read a lot of how to do 1:1s, I did not find much on how to stay on top of 1:1s.

That's why I build a system that serves me instead of me serving the system.

Use a System That Supports You

Through trial and error, I've developed a system that supports me instead of supporting the system. Maybe this system works for you too, but the chances are that you need to make adjustments to make it fit your need and personality.

Since moving to a fully remote work mode, I don't take notes in notebooks anymore. The fact that I can have my notes next to the video call and look into the camera as I write has turned out to be way more comfortable for me.

To write and store my notes, I use the app Agenda. My system fully works in their free offering, though their paid version offers some nice-to-have features.

My system is built around these blocks:

Always have previous notes at hand
Make it effortless to track points for the next meeting
Make sure always to have feedback ready
Make it effortless to replay the last 6 months

Always Have Previous Notes at Hand

It's crucial for me to easily scan the last few weeks' worth of 1:1 notes. This is why Agenda is quite useful to me. I have a 1:1 section in the left sidebar with a notebook for each person in my team. Whenever I click on the name of the person I have a 1:1 with, I instantly see the last few week's notes, and it puts me immediately back in the context of what is important.

Make it effortless to track talking points

I might get ideas, feedback, or action items that I need to bring forward into 1:1s with my team members during my day. To make this easy, the first note in every 1:1 notebook is named "Next", and it always stays as the first note (in the paid version, you can pin it to the top). This is also a great place to store action items from the meeting itself.

Make Sure Always to Have Feedback Ready

Underneath the "Next" note, I have pinned a "Feedback" note. I believe great leaders provide continuous feedback, so my system needs to support me in this. Here I have two sections:

Needs Praise, which is where I add things I want to praise. Whenever I see them handling something well, I'll quickly add it here and make sure to tell them in the next 1:1.
Growth opportunities are where I add items where I see a growth opportunity for them. I'll add a quick note to remind myself but prepare it properly before the 1:1.

With all of my team members, I ask in our very first 1:1 how they would like to receive feedback. I store their answer at the top of this note as a reminder.

Make it Effortless to Replay the Last 6 Months

As we do half-year feedback sessions, it's important to me to quickly see the praise, growth, talking points etc., from the last 6 months. With this system, it only takes me a few minutes to be fully up to date.

Putting it all together, I have a full overview with just one click.

A bonus feature of Agenda is that all new notes will be put "On the agenda". This means by the end of the day, I can easily review all new notes and make sure I have transferred all my action items.

Want to get a weekly digest of the best in engineering leadership? Then sign up for my newsletter, The Weekly Retro.

Should I Become a Manager?

Kenneth Larsen — Wed, 18 Aug 2021 05:00:00 +0000

It's not always easy. I often get asked by senior developers if they should pick the management track or not. The management track is often used as a salary jump and not as the right career path. This often happens in companies that do not have any defined roles for principal or staff engineers.

But should you become a manager? First, you need to answer some questions.

1) Are you ready to give up coding?

While you might find the time here and there to do some actual coding, you will soon realise that it is not a productive use of your time. You should instead spend time enabling those in your team who code. You will still utilise your coding knowledge as a manager but in a very different way, and you need to be ready for that before you say yes.

2) Do you enjoy interpersonal activities?

When you change the track, you also change your main day-to-day tasks. It will differ from company to company on what exactly those tasks are, but for me, the tasks have always included:

Weekly 1:1 with team members
Quarterly feedback reviews
Coordination and planning meetings
Reporting to stakeholders

It's fine not to already be a master of these skills, but if you already know you don't like these kinds of tasks, then it's a red flag.

I have often seen senior engineers accept the role because it seemed like the only way forward in career progression. In the end, they hated the work. Remember to reflect on that before you accept.

3) Do I know any people who went through the same transition?

Talking directly to someone who has been through the same decision process can be tremendously helpful. This could be your existing manager, a colleague or a friend outside of work.

If you do not know anyone, I can highly recommend the free mentoring service The Mentoring Club. Here you can find a mentor with management experience and book them for a session.

Still not sure? Then I highly recommend reading a few chapters in The Manager's Path. It helped me make the decision.

Understand Your Users: Contextual Inquiry

Kenneth Larsen — Thu, 12 Aug 2021 13:39:02 +0000

Understanding and interviewing your users is a crucial part of delivering the right things. While there are many ways of doing this, there's a particular theory that I was encouraged to follow by my design professor that is still stuck with me: Contextual inquiry.

The contextual inquiry is not just about interviewing your users. It is built on the idea that systems design should be grounded in future users' work and aim to enrich the work through the new possibilities offered by information technology.

It is user interviews combined with observations. The goal is to construct a rich picture of the actual work situation: roles, responsibilities, problems with the work and existing tools, etc.

A few principles guide it:

Context: Start with the actual work, not with what people say they do
Partnership: Future users are experts in their work and should be jointly responsible for the inquiry.
Focus: Everybody focuses on something different in the same situation. Therefore it is essential to be aware of this fact and actively try to extend the total focus of the inquiry.

The interview is then best performed when the user is working on their daily tasks, and the interviewer is sitting next to them while they discuss what is happening and what that means. The interviewer should note what the user is saying and what they are actively doing. Especially if any issues arise with the tools and to what extend the tools are supporting the work.

3 Ways to Give Better Feedback

Kenneth Larsen — Fri, 16 Jul 2021 06:24:16 +0000

Giving feedback to your peers can be extremely difficult if you do not plan it right. Thankfully, there are a set of tools that can drastically improve those skills.

1: Use the proper format

"Your pull requests are really annoying to review!" is not feedback that is easy to accept or easy to act on. It is very confronting and blaming and thereby switches the focus away from solving the problem.

Instead, feedback should follow an observing formula:

Observation of behaviour + impact of the behaviour + question or request = actionable and specific feedback.

The formula turns the feedback from something blaming into: "Over the last three weeks, I've noticed that you have created large pull requests without any descriptions or instructions. This more than doubles the review time needed and has led to five production bugs. Can you help me understand why you prefer these large pull requests?"

2: Negative feedback should be given with a growth mindset

To ensure that people can use negative feedback, you must give it with a growth mindset. If the negative feedback does not have the goal of helping your colleague grow in that particular area, then it is not valuable feedback.

3: Do not deliver it as a script

It might seem like a good idea to write down the feedback and read it to your colleague, but it will often come off as ungenuine. Feedback is about being present and listening, not delivering a presentation.

With these three steps, you can easily take your feedback skills to the next level.

References

Huston, Therese; Let's Talk: Make Effective Feedback Your Superpower

Hogan, Lara; Resilient Management

Teams are not a constant, but a living and changing being

Kenneth Larsen — Wed, 14 Jul 2021 11:31:28 +0000

Dealing with team changes can be very frustrating. Sometimes, it leads to a lack of delivery, decreased team mood, or even people quitting. There are a few things to be especially aware of when your team is going through change. Being open-minded to these frameworks can make a difference.

A widespread mistake is to assume that your work is done once your team is delivering features. Teams are never in a finished or constant state but rather something living and ever-changing. Many events can cause a change in the team dynamics, productivity or mood:

New people joining the team
People leaving the team or the company
Changing priorities
Real-world events such as the Corona pandemic

Thankfully, there are also great frameworks to help you understand where your team currently is and how to help them move towards becoming a healthy and productive team:

To set up your team for success, you need to match the team changes with a change in expectations. Whether it is about changing the scope or team members, changes to a team should change expectations equal to the team change. This provides the much-needed space to get back on track to becoming a productive team.

References

Hogan, Lara; Resilient Management

Larson, Will; An Elegant Puzzle: Systems of Engineering

How to Distribute a Rust Binary on NPM

Kenneth Larsen — Mon, 30 Sep 2019 18:31:28 +0000

Recently I published a CLI tool called baelte. It's written in Rust, and it's aimed at frontend developers who make applications using Svelte. I wanted to write it in Rust as a learning project but also to utilize the performance benefits which Rust provides over Node.

When it came to building and releasing it, I was without a clue on how to do it. It seemed that I could push it to Cargo, but to me, that was not a good solution.

First of all, Cargo seems like a registry for packages used by other Rust packages and not for user facing applications.

Secondly, my target group most likely haven't installed Rust and doesn't know what Cargo is. I don't think they should need to know about an entirely different ecosystem to install my tool. Since they are frontend developers, the tool would need to be installable via npm install.

But how can I ship a Rust tool on NPM? Let's find out!

Building

Once my tool was ready to be build and shipped, I looked at what my options were. I wanted something that could be automatically triggered on Github and I did not want to spend too much time on building locally for several operating systems.

Thankfully, there is a project called trust that saved my day. In the trust repository, they have build configurations ready for you to copy and paste. They make Travis build and test for several operating systems when you create a pull request in your repository.

And even better, when you push a tag to your repository it will trigger a build for several operating systems, create a release on Github and push the binaries as downloads for your users to enjoy.

This is really, really awesome. But, I don't want my users to go to a release page on Github and download the binaries themselves. Trust has a small script that can install the latest release for you:

curl -LSfs https://japaric.github.io/trust/install.sh | \
    sh -s -- --git kennethlarsen/baelte

This will detect the user's operating system and fetching the related binary. While this is great, I still don't want my users to do this since this is out of their usual context.

Installing via NPM

Frontend developers expect packages and tools to be installable with npm install. Since my tool is written in Rust and not JavaScript that makes things difficult.

I decided to create a JavaScript file which triggers the install script previously mentioned:

let exec = require('child_process').exec;

exec('curl -LSfs https://japaric.github.io/trust/install.sh | \
sh -s -- --git kennethlarsen/baelte', (error, stdout, stderr) => {
  console.log(stderr);
});

Then in package.json I added a postinstall like this:

"postinstall": "npm run install"

which triggers:

"scripts": {
    "install": "node install.js"
  }

And just like that, it is possible to publish your Rust CLI tool to npm. Users can now download my tool with npm install -g baelte.

Rust for Frontend Developers: Modules

Kenneth Larsen — Tue, 30 Apr 2019 09:57:24 +0000

Not that long ago I decided to start learning Rust. While it has a lot of useful resources online and a very friendly community there's still things that are weird to me. That's because Rust is a very different mental model than the frontend mental model I'm used to.

That means that things that are obvious to a lot of people are not obvious to me. So I'll try to document some of these things from the perspective of a frontend developer. This time on using modules.

With Javascript using imports or modules of any kind is fairly straight forward. If you have a very basic HTML page with a couple of JavaScript files you can add them all with a script tag.

If you have a more fancy setup you can import JavaScript files (or modules) like this:

require('cool-module') or even import { function } from 'cool-module'.

If you use a framework like Ember.js there's a standard of separating code that also goes beyond these module imports. Components are isolated chunks of code that can be invoked like this: <CoolComponent @arg="wow" />.

The point is that there is a lot of ways of separating code on the frontend to make sure your codebase is manageable.

Modules with Rust

While trying to make my Rust clone of Ember-CLI I quickly discovered that the main() function was getting out of hand. I wanted to split the code into separate files to make sure that I could maintain all of the features I wanted to add.

There are a few things to keep in mind here.

Where's my `npm install`?

The good news is that there is an equivalent system in place for distributing and using packages. In the world of Rust that's called Crates. Crates is the registry of the Rust community. To consume packages from this registry or publishing you have to use the cargo package manager.

If you want a package installed globally like npm install -g cool-module then you'll run cargo install cool-module.

But what if you want to install a package for your project? I'm honestly not sure if there is an equivalent to npm install --save-dev cool-module since all documentation is proposing something different.

The documented approach is to add the package name and version to the project's Cargo.toml. This file is the equivalent of package.json. Then when you build your project it will fetch the dependencies.

Now you have to remember to import it where you need it like this:

use package_name::module_name{function_name}.

Separating Concerns

Back to my main issue. I wanted to split out the code into different modules that I could import when I needed it.

My project is currently like this:

main.rs containing the basics to run the CLI tool and process input from the user.
new.rs containing everything related to the new command for generating new Ember projects.
utils.rs for utility-like function such as creating a progress bar and replacing placeholder values with user inputted names.

First I saw that it was possible to use the same import style from the package manager but for local files. I wanted to use the create_new_application() function from new.rs.

In main.rs I tried use rember::new::{create_new_application}

But quickly got an error saying that rember::new wasn't found.

It turns out that these internal modules have to be declared first. Since I was building a CLI tool they had to go in a file named lib.rs like this:

mod new;

This made the new.rs available for me to use in main.rs.

Now I had another problem. I wanted to use a function from utils.rs in new.rs and just assumed that I had to use the exact same approach. But now I got the error with module not found.

I still don't quite understand why but it looks like that for modules not imported in main.rs they have to use super instead of the package name rember. So in new.rs it looks like this:

use super::utils::{create_progress_bar}; instead of use rember::utils::{create_progress_bar};.

How to turn a bash script into a Mac app

Kenneth Larsen — Thu, 18 Apr 2019 20:20:10 +0000

My dad joke app in the Mac dock

I had this stupid idea: At work, we love to share dad jokes. And I know that there is a site called https://icanhazdadjoke.com/ which when I curl it returns a dad joke. So why not make a mac app that fetches a dad joke and reads it out loud?

But I didn't even know where to start building a Mac app. I've built a lot of things, but never a Mac app. So I decided to start making a bash script instead. It looks like this:

JOKE=$(curl https://icanhazdadjoke.com)

say -v Daniel "$JOKE"

exit 0

This script will assign the dad joke from the website to a variable called JOKE. Then I call the say command which is a native Mac OS command that reads a string out loud. I pick the voice named Daniel to have a consistent British feel to the delivery of the joke.

I could easily run this and have a lot of fun. But, I wanted to share this with my colleagues. I wanted to turn the bash script into a Mac app.

It turns out that if you create the folder structure of a Mac app and use the bash script as the main.command it actually works. You can see the result here: https://github.com/kennethlarsen/dadjoke.app

Create Your Own App

If you have your own bash script you would like to turn into a Mac app then start by forking my dad joke app. Then:

Edit Info.plist to contain your name and info.
Add your bash script to main.command
Replace cmd.icns with your own icon

That's it! Now you can zip it and send it to your friends.

How to Contribute: Ember Times

Kenneth Larsen — Thu, 07 Mar 2019 12:40:26 +0000

Getting started contributing to open source isn't always easy. Usually, there's a whole new code base we need to understand before starting contributing. Sometimes it's well-documented, sometimes not. That's why I always recommend people to start with documentation first and code later. It's a perfect way to get started contributing without any specialized tooling or knowledge, and usually, open source projects always welcome updates to the documentation.

I've decided to create a guide on how to contribute to the Ember ecosystem starting with contributions that don't even require coding and ending up with something a bit more advanced. This is part one.

The Ember Times is a weekly newsletter made by a lot of different contributors. Some of them are members of the Core Teams, some of them have been writing for The Ember Times for a very long time, and some stop by to contribute once or twice. No matter which category you fall into, your contributions are always incredibly helpful and appreciated.

Usually, a contributor for the Ember Times will select a topic and then write a small section about that specific topic. There's often the misconception with contributions like this that we have to be experts to write about a particular topic. I can guarantee you that most people who contribute documentation - including me - don't know a whole lot about what they're about to document.

When I pick a topic, it's usually about something I don't know a whole lot about and that's perfectly fine. It's an excellent opportunity to learn.

The first steps

The first thing to do is to make sure that you're signed up for the Ember Discord chat. There is a channel named #support-ember-times. This is where all work regarding the newsletter is coordinated.

If you have never contributed to the Ember Times before it's a good idea to go and say hello. The Ember Times people are incredibly kind and will help you get started picking a topic if you need it.

For each week there is a work in progress pull request containing the draft of the newsletter as well as a list of potential topics to include. This pull request can be found in the channel topic of the Discord channel.

Let's have a look at one of the previous pull requests.

Here you can see that I have picked the topic "New guides are out containing angle bracket invocation syntax." This is not because I have a specific knowledge about angle bracket invocation syntax, but it's something I wanted to know more about.

When I've decided on a topic, I'll let the others know in the #support-ember-times channel.

Getting the Repo

Working with open source repositories does require some work with Git. If you haven't used Git before I suggest completing a small Git tutorial before you proceed.

First, visit https://github.com/emberjs/website and press the fork button. This will create a fork of the repository that you can work directly on. Think of this as a photocopy of an original document. You can draw all you want on the photocopy until you're satisfied with the result and it won't harm the original.

Once it's forked, it's time for some work in the terminal. In your terminal you need to clone your newly forked repository:

git clone URL

You can find the clone URL in your forked repository:

cd website/

Now, we have one remote source for this repository which is your newly forked repository. This is great for when we want to create the pull request in the end. But for now, we want to fetch the work-in-progress pull request containing the draft of the Ember Times issue.

Let's add the original repository as a remote source and call it upstream:

git remote add upstream git@github.com:emberjs/website.git

This means that we can fetch the branch containing the draft. The branch name can be found in the GitHub UI for the work-in-progress pull request.

git fetch upstream blog/embertimes-85

And then let's checkout to that branch:

git checkout blog/embertimes-85.

Now we're ready to create a branch that we want to work from. In my case I'll name it like this:

git checkout -b angle-bracket-guides

There are no rules for naming of your branch, but I like to include some reference to what it contains.

Writing The Section

The technical setup is done, and we're now ready to write some content. There are no rules on the length of the section, but I think the average is around 100 words. Ideally, we want to keep it short and sweet.

Even though I'll write about angle bracket invocation syntax, I aim to keep it non-technical. Any crucial technical information, code samples or things like this should ideally live in a separate guide or blog post that can be referred to in the Ember Times.

In this case, there's a new version of the Ember Guides containing this new syntax.

Again, there are no rules on how to do this but here's my process when I write:

I start by announcing the news right away while still keeping the reader interested.

"A new version of the Ember guides has been deployed, and it contains some exciting surprises."

Now since the new guides contain two new features I choose to start with the non-flashy one:

"First of all, the guides-source and guides-app repositories have become **one repository**. This makes it so much more convenient to maintain and contribute. It also now uses the Guidemaker technology which means that CLI-guides and the Ember guides are using the same tech."

And for the finale:

"And now for the big surprise: **The newly deployed guides now contains angle bracket invocation syntax**. So, if you're looking to use angle bracket invocation syntax in your Ember application, the guides are the place to look for help."

Now, as you might notice, this small section did not require me to have any special knowledge of the technical aspects of angle bracket invocation syntax for me to be able to write about the update.

Wrapping It Up

Now that we've finished the section there are only a few things left to do. As you'll notice in my pull request, I've added a few things besides the section itself.

In the very top, I add my name as an author. Everyone who writes a section for the Times should be credited as an author.

Next, I've added a one-sentence description of my section for the introduction. Don't worry about it being cohesive with the rest - that will happen in the final edit.

Lastly, I've added my name again at the bottom.

You're now ready to commit everything and push it to your fork:

git add blog-file-name

git commit -m "Added section on new guides"

git push origin angle-bracket-guides

If you visit your forked repository, you will now be able to create a pull request targeting blog/embertimes-85.

When that's done, you should post a link to the pull request in the #support-ember-times channel, and one of the team members will review your pull request.

Your Actions

Are you ready to get started?

Go to the Times channel, find the work-in-progress pull request.
Pick a topic and let the Times people know.
Fork and clone the repository.
Start writing a small section.
Add your name and an intro.
Send it for review.

If you get stuck or need any help, please reach out to the fantastic Ember Times people in the Times channel on Discord.

That's it for getting started contributing to the Ember Times. Stay tuned for the next post in this series where will write a section for the release post together.

Inclusive Documentation With alex

Kenneth Larsen — Tue, 19 Feb 2019 13:49:31 +0000

There is a lot of helpful open-source tools out there that can help us improve our documentation. In general, automated tools can help us remove the overhead that exists in maintaining documentation and let us spend our valuable time on writing the content. Sadly, these tools aren't perfect, and you have to be aware of a few things. In this post, I'll show you how to refactor our current documentation using alex.

The development community doesn't have the best reputation when it comes to being inclusive and considerate. Even though a lot of great efforts has been made to improve this, we're still far away from the goal. There is however one thing we can do to help promote this - and it all starts with documentation.

alex is an automated tool that enables us to catch inconsiderate and offensive language within our documentation and even our code base.

Getting started

To get started we have to cd into a directory containing one or more markdown file and run npx alex. (or npm install -g alex; alex). Now the output in the terminal should tell you if there are any current issues with our documentation.

If we want to have this working as a linter inside our editor there are a few integrations available:

Atom: atom-linter-alex
Sublime: SublimeLinter-contrib-alex (by @sindresorhus)
Visual Studio Code: vscode-alex (by @shinnn)
Gulp: gulp-alex (by @dustinspecker)
Slack: alex-slack (by @keoghpe)
Probot: linter-alex (by @swinton)
Vim: ALE (by @w0rp)

If we're using Ember.js there's even an Ember addon that will run alex within our test suite to also catch offensive namings within our code:

Ember: ember-cli-alex (by @yohanmishkin)

Refactoring Our Documentation

So, we have alex running, and it's listing a lot of issues - how do we proceed from here?

There will be words that alex catches that might not be inconsiderate or offensive at all - and that's fine. It's a linter, not a human. This is where we as a company or maintainer get to define our rules. Let's say we have written the following sentence:

To try out the new React hooks visit the guides.

alex will return the following:

Be careful with hooks, it’s profane in some cases

Now, while it's true that hooks is profane in some cases, some cases it's not. If we would like to ignore this warning since it's not profane in this context we add an ignore statement above the sentence like this:

<!-- alex ignore hooks -->
<p>To try out the new React hooks visit the guides.</p>

If we run alex once again, it will return no errors or warnings.

But what if all we write about is React hooks? It's quite cumbersome to add the ignore statement every single time we mention React hooks. Thankfully, alex supports an ignore file.

In the repository for the Ember.js website we have an ignore file that looks like this:

{
  "allow": ["color", "dad-mom", "her-him", "he-she", "hook", "hooks", "harder"] 
}

As long as this file is named .alexrc and placed in the root of the project it will automatically ignore these words.

Whatever is left after ignoring non-offensive words are things we should fix. Say we have a README.md that contained the following section:

It writes all changes to the **master server** thus, the slaves were read-only copies of master. 

If any of you guys would like to contribute please do so

alex will raise issues about this text. First of all, the use of master/slave is considered to be insensitive. Instead, we should use terms like primary/replica which - besides being more inclusive - is a much more precise term.

Another issue we have is the use of guys. alex tells us that "guys may be insensitive, use people, persons, folks instead". In this case, I agree that guys is insensitive and hinting that males are the ones being encouraged to contribute.

After a few changes we now have:

It writes all changes to the **primary server** thus, the replicas were read-only copies of primary. 

If any of you folks would like to contribute please do so

Much better.

Keeping It Clean

Besides having the linter in our IDE and running alex on our local machine, there is something we could do to catch errors going forward.

If we again have a look at the Ember.js website repository we find a script that is being run by the CI.

git remote add base https://github.com/emberjs/website.git
git fetch base
BLOG_HAS_CHANGES=$(git diff --name-status base/master source/blog/2*)
if [[$BLOG_HAS_CHANGES]]
  then
    alex $(git diff --name-status base/master source/blog/2* | sed s/^..//)
fi

This script checks whether the blog has any changes - since the blog is currently the only place where alex is being run - and if so alex is being run in the diff only. This is especially important when we already have a lot of documentation. Changing everything in one go is often not a possibility, but catching it going forward is doable.

So, every time a pull request is raised alex will make sure that we consider our language.

It might be overwhelming at first, but I do think it is worth investing in improving our documentation to be more welcoming and inclusive.

What Can We Learn From +50000 Tweets About Ember.js

Kenneth Larsen — Sun, 12 Aug 2018 16:40:30 +0000

Photo by freestocks.org on Unsplash

What Have You Done?!

I had a thought. I wanted to gain an overview of open source communities and their activity. A first natural place to look is Twitter since a lot of developers are sharing and discussing on that platform. I wanted to start a place that I thought was particularly interesting: Ember.js.

So, I decided to scrape every single tweet containing the hashtag #EmberJS. This contains everything (Well, except for the ones that have been deleted). I then used Elasticsearch with Kibana and started finding trends and interesting data.

The very first tweet in the database — and what seems to be the first tweet ever about Ember.js is:

Liquid error: internal

Now, there might have been earlier tweets but they have since been deleted. The latest tweet in the database is this one:

Liquid error: internal

Which gives a time frame of just about 7 years.

The goal of this post is to gain an overview of the Ember.js community just by looking at the tweet activity through 7 years. In total, this contains 51866 tweets. This is the first post in this series, but I intend to continue with other open source communities.

The Most Active Users

One way to understand a community is to look into the most active people in that community. So, I created a top ten of Twitter users who have used the Ember.js hashtag.

Top ten amount of tweets

@tarasm (16,280 tweets)
@michaellnorth (10,720 tweets)
@EmberWatch (8,163 tweets)
@EmberA2D (8,021 tweets)
@ladyleet (6,542 tweets)
@JavascriptFlux (4,817 tweets)
@dr_vitus_zato (4,442 tweets)
@EmberWeekly (3,848 tweets)
@TechWars_io (3,486 tweets)
@JavaScriptKicks (3,270 tweets)

Now one of the interesting things with this list is that we see accounts like @JavaScriptKicks and @Techwars_io. If we have a look at what they are writing it’s quick to see that they are just spam machines trying to ride the Ember.js wave. For example, @Techwars_io has written the following tweet 2.265 times:

We compared #batmanjs vs #emberjs — see results: http://www.techwars.io/fight/batmanjs/emberjs/

This is obviously spam and they have earned the first place in the spam list of the Ember.js community.

Thankfully, the other Twitter users are not horrible like this. The most active users also seem to be community profiles like @EmberWatch and @EmberWeekly though the most active users are actual profiles.

It’s interesting that the official Ember.js account didn’t make this list which would have made sense. Also, this top 10 seems to indicate the majority of the core team are mostly active in other places than the #EmberJS community. This might be the forum or Slack. Maybe their time is better spent there?

What Makes an Ember Tweet Popular?

Likes and retweets are a popular measure of success. Even though I agree that it can tell us something about what’s popular it’s not always significant in showing us what is valuable for a community. That being said, I still think it’s interesting to have a look at what makes an Ember.js tweet popular.

Top 5 retweets

@baaz: https://twitter.com/baaz/status/649587166247579648 (202 retweets)
@pocztarski : https://twitter.com/pocztarski/status/537078929916694528 (177 retweets)
@michaellnorth: https://twitter.com/michaellnorth/status/593564323865174016 (165 retweets)
@baaz: https://twitter.com/baaz/status/568136988093767681 (132 retweets)
@Evontech: https://twitter.com/Evontech/status/824130617776504832 (118 retweets)

There are a few interesting things about this list. First, it seems like the most popular Ember tweets still have a quite low retweet count. Compared to something like #reactjs this is really in the low end. Why is that?

It could be that the Ember.js simply is smaller and the possible amount of retweets is therefore smaller. Ember.js also has other active communication channels such as Slack where there’s way more activity which could result in Twitter not being as active.

Another reason might be the fact that Ember.js is not very good at hyping itself. If you look at this tweet by Dan Abramov stating that you can use React.js without npm you’ll see that it has twice the retweets as the number one retweeted Ember.js tweet. Something so simple, so hyped.

Dan Abramov

@dan_abramov

Did you know: you can use React as a <script> tag without npm! 🤔 Here’s a handy guide: reactjs.org/docs/add-react…

15:32 PM - 27 Jun 2018

Why is it that Ember.js cannot manage to hype itself like this? First of all, Ember.js already have a lot of amazing features but they are not all new. They are just there. And they work. And they’ve been there for a while. When there is something new and great it sort of just slips through the hype system.

This means that Ember.js could start rebranding existing features to gain the hype that React.js benefits from. This also means that future communication from Ember.js could be phrased in similar ways as React.js.

But maybe it doesn’t matter at all? Is the hype even worth it? One of the great benefits of Ember.js is that it’s consistent, conventional and stable. That is also the feeling I get when I read the community tweets. I get a totally different feeling when reading the React.js tweets and perhaps the two frameworks have found their different homes on Twitter and that’s all good. What I do know is that when I talk to developers about Ember.js they think it’s dead. And that’s mainly because of the lack of online presence.

If we go back to the retweets it’s also noticeable that two of the top five tweets are by @baaz on the same subject. He did write a great book on Ember.js and the fact that this book earns the most retweets might suggest a critical thing about the Ember.js community.

The fact the one book resource gains all the retweets might suggest that Ember.js suffers from a lack of good learning resources so that when there’s finally a great one it gets shared a lot.

Top 5 liked tweets

@pusherhttps://twitter.com/pusher/status/839052252417560576 (354 likes)
@lukedeniston https://twitter.com/lukedeniston/status/876873369970290688 (154 likes)
@jeffreybiles https://twitter.com/JeffreyBiles/status/791664130490937344 (135 likes)
@remi https://twitter.com/remi/status/984851429906178048 (131 likes)
@rwjblue https://twitter.com/rwjblue/status/799722020745441281 (123 likes)

Here the top tweets are about features and talks that are interesting for the community. But still the top tweet here only have 354 likes which is nothing compared to tweets in the React.js community. Reasons might be the same as for the retweets.

Engaging in tweets

So far it doesn’t look like that there’s a lot of engagement in sharing news about Ember.js on Twitter. So what about discussions? If we look at the tweets with the most replies we might get a bit disappointed:

Top 5 Replies Count

@joachimhs: https://twitter.com/joachimhs/status/376046831660068864 (34 replies)
@ryantotweets: https://twitter.com/ryantotweets/status/948228827230228480 (22 replies)
@michaeldegli:https://twitter.com/michaeldegli/status/458365260009705472 (20 replies)
@tarasm : https://twitter.com/tarasm/status/906935258909630464 (18 replies)
@ebryn: https://twitter.com/ebryn/status/463778352021508096 (16 replies)

These numbers are also on the low side which suggests that actual discussions about Ember.js are probably happening elsewhere. The fact that the most replied to tweet only have 34 replies and is about getting a free eBook says it all.

So… Is It Dead?

Of course not. Even though Twitter activity isn’t saying everything about a community I do feel that it provides a great insight into why a lot of people think Ember.js is dead. The majority of activity and engagement is happening in specific Ember.js communities such as the forum or the very active Slack channel. But that means you only see it if you’re already part of the community.

If I’m a React.js developer I will most likely never see an Ember.js retweet, like or discussion on Twitter. So why should I think it’s still alive? I personally don’t work with React.js but yet I see React.js tweets all the time in my timeline.

It might not be worth creating a more active Ember.js community on Twitter but it at least explains something about how other communities see Ember.js

Want to read more posts like this? Follow me on Twitter.

Five Minute Accessibility: Input and Labels

Kenneth Larsen — Sun, 16 Jul 2017 08:06:01 +0000

Photo: Christopher Gower

It seems that a lot of frontend developers either don’t know about coding for accessibility or they don’t care. Of course, it can be hard to implement in organizations with no focus on accessibility. But it’s always a developer’s (and designer’s) responsibility to develop an inclusive web.

In the series Five Minute Accessibility I will introduce one simple thing you can do to improve accessibility in your projects. In this post you’ll learn about how to use input and labels.

Even though you’ve been creating input forms for years it might be the case that none of them are accessible. Thankfully, it’s very simple to change this starting today.

To create accessible input fields you have to beware of labels. Creating a label which is uniquely tied to an input field is necessary to create accessible forms. Note that labels are referring to an id of the input. Screen readers do not support multiple labels associated with the same form element.

So you might normally see an input field like this:

<label>Name:</label>
<input type=”text” name=”textfield”>

As you might expect this works great for users of non-assistive technologies and this is a very common way of developing forms. However, this will be non-inclusive. So by simply wiring the label and the input we now have an accessible input field:

<label for=”name” >Name:</label>
<input id=”name” type=”text” name=”textfield”>

By adding for=”name” to the label we link this label uniquely to the id of the input. This is now accessible and also has some other nice features included. The user can now click on the label itself to set focus to the form element. This is useful to some with motor disabilities, particularly when selecting small checkboxes and radio buttons.

The good thing is that this is useable for other types of inputs as well. Let’s have a look at check boxes:

<fieldset>
<legend>Select your pizza toppings:</legend>
<input id=”ham” type=”checkbox” name=”toppings” value=”ham”>
<label for=”ham”>Ham</label><br>
<input id=”pepperoni” type=”checkbox” name=”toppings” value=”pepperoni”>
<label for=”pepperoni”>Pepperoni</label><br>
<input id=”mushrooms” type=”checkbox” name=”toppings” value=”mushrooms”>
<label for=”mushrooms”>Mushrooms</label><br>
<input id=”olives” type=”checkbox” name=”toppings” value=”olives”>
<label for=”olives”>Olives</label>
</fieldset>

Notice that each check box has an id which is matched by the label. By adding these few lines you have accessible forms — so why not start doing it today?

Check out my fail log or subscribe to my Fail Mail newsletter

You can also follow me on Twitter.

Forem: Kenneth Larsen

How I Stay on Top of 1:1s

Use a System That Supports You

Always Have Previous Notes at Hand

Make it effortless to track talking points

Make Sure Always to Have Feedback Ready

Make it Effortless to Replay the Last 6 Months

Should I Become a Manager?

1) Are you ready to give up coding?

2) Do you enjoy interpersonal activities?

3) Do I know any people who went through the same transition?

Understand Your Users: Contextual Inquiry

3 Ways to Give Better Feedback

1: Use the proper format

2: Negative feedback should be given with a growth mindset

3: Do not deliver it as a script

References

Teams are not a constant, but a living and changing being

References

How to Distribute a Rust Binary on NPM

Building

Installing via NPM

Rust for Frontend Developers: Modules

Modules with Rust

Where's my npm install?

Separating Concerns

How to turn a bash script into a Mac app

Create Your Own App

How to Contribute: Ember Times

The first steps

Getting the Repo

Writing The Section

Wrapping It Up

Your Actions

Inclusive Documentation With alex

Getting started

Refactoring Our Documentation

Keeping It Clean

What Can We Learn From +50000 Tweets About Ember.js

What Have You Done?!

The Most Active Users

What Makes an Ember Tweet Popular?

Engaging in tweets

So… Is It Dead?

Five Minute Accessibility: Input and Labels

Where's my `npm install`?