This post was originally posted on my dev.to blog account.

I’m going to take you on a wild story that I tell everyone because I find it so exciting. It’s been taking up the top spot as a pinned tweet on my Twitter and I just want to get my personal obnoxious story-sharing out of the way with this article so I can stop annoying people with it

The image

A few years back, I set it as my new banner image on LinkedIn when they introduced that feature on profiles. I thought it was kind of neat. I did not share that image anywhere else.

So what’s in it?

It’s my custom VIM setup that I used back then. In VIM, you can see that I have a project opened called popstar-cms and a file called reader.js. I mention this so that you know that the code written there is specifically my code.

Also note, I’m importing lodash at the top and that this project at this point in time has no license file.

The Ubisoft employee visit

At some point in time, I checked who viewed my profile on LinkedIn. Among a bunch of recruiters, unknown names, and whoever else, there was a single Ubisoft employee but I’d have to pay LinkedIn for a premium membership to reveal who that person is.

I didn’t think much about it. All kinds of people view my profile. Maybe it was one of their web developers. Who knows.

The Tweets

Sometime later, I saw a tweet by John-David Dalton (creator of lodash). Around this time, it was quite a meme that Lodash was in everything. Everyone was using it and that was the joke so it didn’t come as a surprise that lodash would show up in a random video game called Watch Dogs 2:

{% twitter 800569316575997952 %}

I remember idly liking the tweet without inspecting it. I was using lodash as well and the joke held true. I thought it was funny.

And then Dalton took the time to figure out that it’s my project and tweeted @ me:

{% twitter 800609800048574464 %}

I was really surprised to see a tweet from him and I was beyond ecstatic to find out that my code ended up in an AAA game! I’ve heard of Watch Dogs and its sequel, I’ve never played it but I thought it was really really awesome. And of course, I told everyone about it.

Let’s not forget to credit Paul who took the original screenshot.

(note: the project that Dalton tweeted at me was the wrong one, the banner app was a fork off the previously mentioned popstar cms)

The DedSec Screenshot

The screenshot is of a monitor at the hideout of a hacker collective called DedSec in a game called Watch Dogs 2 which was created by Ubisoft Canada — and noooooow the random Ubisoft employee visit makes sense!

So before I leave this story alone (I mean, the big reveal already happened), I wanted to compare the two screenshots:

Ubisoft altered my original in a few ways:

1. they removed my name and project name (which I’m truly bummed about)
2. the file tree just features a few copy/pastes of the reader.js and parser.js file listings
3. it looks like they selected only specific parts of each file buffer
4. under the file tree, we actually see a section of the findFile function
5. there are some random visualizations under the 2 buffers

Uhm, let’s talk about Reddit

I was really excited about all of this at the time so I decided to share the story on Reddit and WOW. I did not expect people to be so crappy. Long story short, most people thought that the code in the DedSec screenshot had nothing to do with my screenshot which is just weird to me. I mean, they even copied my JSDoc code comment. Anyways…

A lesson for everyone: just don’t go on Reddit. If you want to be part of a good tech community, stay here on dev.to or go to Twitter (if you dare).

Why mention the license?

Ok, so people on Reddit did have one good point. Ubisoft used my copyrighted screenshot without permission and they published portions of my code which was free to view on Github, but wasn’t free to be used/copied/etc. in any way. I’m sure that this qualifies under fair use; however, I’m not a lawyer .

I’m not mad about it, and geez, I won’t make a stink about it, but it is interesting to me and makes me wonder how many other assets companies use without letting the creator know, without crediting them, and literally erasing their name from the assets so they could use them.

The post How My VIM Setup and Open Source Code Ended Up In an AAA Video Game appeared first on AntJanus.

I always thought that as a developer, programming would either get less exciting with time but I prove myself wrong time and time again. In fact, I have been enjoying feeling like a beginner where putting time and effort into new technologies feels exciting and rewaring. So let me tell you about my year and how things went.

I should probably mention that this is more for me and to reflect back on my own accomplishments rather than a guide or an article for others to follow.

My 2019 Goals

My goals for 2019 were actually rather simple: focus on writing an app and become an instructor. Did I accomplish either of these? Nope, not really.

But I did get pretty far with both, at least in my opinion.

Building a side app

I wanted to finish building an app I’ve been working on for quite a while called Skok. Skok is a photo management app. Here’s the kicker: it works. Here’s what you can do with it right now:

1. scan a directory for photos and populate a database with them
2. look through a gallery of those photos
3. see the “photo of the day”
4. identify duplicate photos

So what’s the problem? Polish and keeping it up to date. I just don’t have the drive to do it. Over my July goal of doing a 30 days of commits, I refactored all of the ugly code, wrote a solid test coverage for the app but…then I got tired of it and went to do other things.

Life is very full right now (in good ways and not-so-good ways) and thus I dropped it when I got almost there.

By the way, if you want to see a quick walkthrough of that application, I have a video about Skok that I made early on in the year — before the big refactor that I did in the 30 days of commits.

Becoming A Dev Instructor

Did I become a full-time instructor anywhere? No. Did I become a part-time instructor? Also no. Wait but did I release videos on my YouTube channel with a course? Also no.

But I did keep my YouTube channel pretty busy. And I’ve been blogging quite a bit, too. So I’ve been happy with where things went.

I made a lot of videos this year, more than any other (I think?) and they resulted in an amazing number of views. I’m up to 730 subscribers right now and I’m happy as heck with that.

10 teeny-tiny developer resolutions.

At the beginning of this year, I posted a fun article called 10ish Teeny-Tiny Resolutions to Become A Better Developer in 2019 so let me update on that real quick, too!

1. Accessibility Course

I took it! And I became a proponent of accessibility at work and have been helping build things out with accessibility in mind. From color contrast, to using aria labels, and more. It’s been tough and there still isn’t much to show for it but being aware of the issues and solutions has made it easier to bring it up at meetings and to push for it in code.

2. Catch up with an ex-colleague

Definitely did that. I reconnected with an old co-worker and we definitely chat quite a bit more than we did last year.

3. Clean your keyboard

I took out all of the keycaps from my keyboard, I cleaned everything out, and put it together. It was heinous.

4. Watch someone use an OS you’re unfamiliar with

I kind of did that. I’m using Linux + Windows full time right now but I rarely venture into the realm of MacOS. I do rotate browsers and I recently switched from Android to iOS to see where iOS has progressed to in the past few years

5.Watch an online talk on a technology you have been interested in

I watched a ton of GatsbyJS stuff

6. Learn about RSI

DONE

7. Learn 1 new power-user feature of your code editor

I switched entirely back to VIM. But I learned a new power feature in tmux which I also switched back to. I use the ctrl+b d to detach from a session. I use this so that I can save what I was working on for work, close out the terminal, and call it back up the next day.

8. Learn Flexbox or CSS Grid

Done! While I still need to look up the properties, I’ve got a pretty good grip on how things work and how to make a quick layout from scratch.

9. Publish a package

I published the electron-transponder from all the work I did with Electron. I renamed it to electron-communicator but kept the package name anyways.

10. Enjoy the new year

I had a pretty decent year.

What did I actually do and learn in 2019?

React 100% forward

At my job, we ended up rewriting major portions of our application in React. It’s been fun and helped me get used to the React paradigm. It turns out, following Reacty people and subscribing to React-related newsletters has its pay offs because jumping into it, I had no issue running around and doing what I needed to do. — even using Hooks once I sold everyone else on the team on them.

What I did find, unfortunately, is that React libraries are still not of the same caliber as Angular’s built-in features and libraries. Angular kind of found all of the weird and obscure edge-cases and built tooling around it. While React library owners still tend to rule with an iron fist and yell “You’re doing it wrong” or “Build it yourself”.

Two very good pieces of feedback that we’ve used as fuel to rip out 3rd-party libraries and handroll our own solutions.

GatsbyJS All The Way

It took me quite a while to get into Gatsby. It just did not make sense to me at first. When things finally clicked for me, I built two separate Gatsby blogs, then I submitted a PR to a Gatsby plugin, and had a lot of fun with it.

Despite the initial hard learning curve, when things got to work, it was very fun to add new functionality, make changes to my blog design, and to actually write. If you want to, check out my Thoughts on the Grave of the Fireflies movie which forced me to add image support.

It also prompted me to write my NaNoWriMo in a format that would work with Gatsby so I could potentially write (or use, if it exists) a plugin to transform Gatsby content into an ebook. The very wild thing is that this is possible! I have…so much to say about Gatsby but that’ll be for another day.

Writing

One thing that surprised me this year is that without any goal to do so, I managed to write quite a few blog posts this year.I wrote around 18 posts (some questions) — which is a little out of my usual scope. And that’s just on my dev.to profile page.

To add onto it, I wrote 2 shorts stories and 2 articles on my writing blog. I edited good 15-20K words of a book I wrote a few years back. And I’m finishing up a 50K word NaNoWriMo in November (probably finished when you read this).

My total views on dev.to alone was around 60K views…which is pretty awesome

Skok & 30 Days of Commits

In 2018, I did an event called the Shippening along with a few other developers. We decided to spend the time between Christmas and New Year’s to try to build a shippable product. Most people failed it…well, because 3 days isn’t a lot of time.

Anyways, I decided to use the Discord we started to do another events: 30 Days of Commits. The idea was to commit once a day on a project that you wanted to work on. I think it worked quite well!

I worked on my project Skok, published a node package out of it, and wrote tests to cover most of the features in the app. I was pretty happy with the outcome — though I completely abandoned the project! Again!

Back To Linux…

At the beginning of the year, I shifted all of my development to Linux. And now, at the end of it, I shifted all of my computer interactions to Linux and my Windows machine runs as a media server of sorts.

It’s pretty amazing. I got a new laptop, the Thinkpad T480, and I set up Ubuntu on it from scratch — which is actually weird for me because I’ve been predominantly an Arch user for the past several years.

As soon as I installed it, I switched to using i3. Then I got into ZSH (which I’ve been hesitant to use), I started to use VIM again and abandoned VS Code, then I got into Tmux…and I spiraled further and further into the Linux ecosystem.

New Goals?

Every year, I get less and less enthusiastic about goals, mostly because those goals only apply to the first month or two of the year and after that life goes off rails. Not necessarily in a bad way, life and goals simply change.

I still try to set some because when I lose my focus, it’s easier to go back to a list of goals rather than start from scratch.

Ok, here are a few ideas for (tech) goals:

1. build a custom keyboard from scratch
2. try to build something in Rust
3. Webflow!

Custom Keyboard From Scratch

This has been a low-key goal of mine ever since I got into mechanical keyboards. I’ll be getting my first one sometime soon. I was really intimidated by putting my own together until I got test switched in the mail and hooked up to my Arduino with a few spare wires.

I figure that adding switches to a PCB, soldering them in, and then putting the PCB in a case will be a nice weekend project.

Rust

Rust has been on my radar for a bit. I’ve been a fan of some of the newer languages and have tried them out and even built apps on top of them. I currently use Elixir at work and I still have production Golang running somewhere.

Rust has been the natural next step in my language-learning. I succeeded at doing some Rust exercises (can we please stop using the word koan? It’s been appropriated from a zen practice by the same name).

Anyways, still a long way to go for me

Webflow

I honestly think this is where future is and unlike a lot of tools back in the day that tried to provide the no-code experience (Dreamweaver for instance), it lacked the data component. Webflow takes web design, web development, and data modeling and smashes it together to create a robust no-code web editor.

I’m psyched because I was super into Dreamweaver and Fireworks and Webflow is miles ahead of those. I was also a heavy Photoshop/Illustrator user and guess what? Webflow feels a lot like that, too. Finally, I did a bunch of work in Unity, Cinema 4D, and Blender…and again, Webflow captures the feel of those as well.

I stopped using all of the software above a while back because “code was the way” for so long that my specialization had no reason to broaden to use that software. Webflow changes that paradigm on its head

My top 2019 Articles

• My Top 10 Programming Proverbs
• Switching from angular2-template-loader to @ngtools/webpack – this is more fun to read as my journey through Webpack/Angular hell
• The Definitive React Hooks Cheatsheet
• Prototypes Don’t Get Thrown Out — Write Tracer (Bullet) Code Instead
• My Personal Git Tricks Cheatsheet
• How My VIM Setup and Open Source Code Ended Up In an AAA Video Game
• My Favorite Linux Tools

Links:

• 2018 retrospective and goals
• my article on yearly retrospectives
• DevsWhoDev Discord

The post 2019 Personal Retrospective On My Development Journey appeared first on AntJanus.

This post was originally posted on my dev.to account. It was migrated here for archival purposes. Checkout the original post for all kinds of awesome Linux discussions.

I wanted to list a few utilities that either help my productivity on Linux or make working in Linux more pleasant in some way.

I really enjoy setting up tools so that they’re easier to use when I use them — so instead of just saying “this tool is great”, it’s also worth noting how some tools can be very powerful once you spend the time to set them up, even if you don’t use them often.

You might notice that most of these are terminal based utilities. I primarily interact with Linux via the terminal and almost everything that’s not terminal based is just the usual cross-platform applications (Discord, Opera, Slack, VSCode, etc.) so I’m not mentioning any of those.

I asked the community for everyone’s recommendations.

NeoVIM

From git messages to quick file changes (or full development), it’s totally worth setting up NeoVIM with at least syntax highlighting. I often reach for VIM when I don’t want to bother opening VSCode or when VSCode is just too much for a quick edit.

Why NeoVIM and not VIM? NeoVIM retains full backward compatibility with VIM and exposes some new features. Either one works!

ZSH

I’ve had my bash config setup just the way I liked it but recently switched to ZSH. Why?

1. it’s quick and easy to setup
2. you don’t have to be a power user to take advantage of it
3. zsh command highlighting makes things easier to read
4. theme support is much better than bash/terminal theme support
5. lots of plugins

Make sure to check out oh-my-zsh which gives you the theme support and plugin support.

nmtui

A TUI (terminal UI) for network management. I reach for it more so than any other built-in utilities because of how simple and straightforward it is. For some reason, I also trust it more. When a GUI network manager freezes, I’m always paranoid that the GUI froze — not that the network manager is doing its job. With NMTUI, there’s more trust on my part for sure.

I know, I know, it looks like it’s from the 80s BUT, it allows you to manage all of your saved wifi settings, your ethernet connections, and so much more. It is fully-featured and lacking nothing as far as I can tell.

ncdu

NCDU is a terminal UI (an ncurses UI to be more specific) for the du command. What does du do? du is a disk usage utility. What’s cool about ncdu is that it scans everything in a folder or on your system and allows you to explore your file system with all of the computed size values.

This is so useful when you’re trying to figure out what’s taking up so much space on your drive, or when you’re trying to delete the space hogs.

htop

Another terminal utility. This one is an interactive process viewer. Think of it as your Activity Manager or Task Manager. It can filter, search, and sort through processes. It displays all of the relevant process information included full command path which started the process. This is so useful when trying to find runaway node processes.

You can then send commands to the processes but the only one I really use is the kill command to close stuck processes.

notify-send

notify-send is a utility that allows you to send notifications to yourself. This is super useful — so much so that I aliased it in my .bashrc:

alias lmk="notify-send 'Something happened!'"

Might seem useless but if you’re running a long-running process, it’s great to have a notification system that lets you know when it’s done. So I tend to use notify-send in conjunction with other commands, like npm install && lmk.

Rofi

Unlike others, this one isn’t a terminal application. This is an application launcher/window switcher/so much more. If you’re using something like i3, it is a perfect replacement for dmenu. If you’re using something else, it’s still a power tool.

What makes it special is that it handles command line utilities and GUI apps at the same time AND it’ll switch you over to a running instance of an app as well. On top of that, it’s insanely fast.

Other notable tools

I don’t want to go off to the deep end with every single tool I use so here are a few I’d check out:

1. bat – an alternative to cat with syntax highlighting and better display of file contents. Install and alias it to cat
2. notepadqq – inspired by the Windows-only Notepad++, a easy-to-use auto-draft-saving text editor
3. emacs org-mode – Emacs is a powerful text editor and org-mode is a plain-text productivity/task-management tool
4. conky – a desktop system monitoring tool – tells you CPU/RAM loads, active processes, etc. on your desktop
5. Archey – a cool utility that tells about your machine. It was used to generate the screenshot at the top of this post

Note: If you use any of my screenshots for anything, please let me know and credit me somehow. Especially if it’s used as a texture for computer hacker monitors in a AAA video game

Like my content? Follow me on Twitter or just buy me a coffee

The post My Favorite Linux Tools appeared first on AntJanus.

This post was originally posted on my dev.to account and migrated here for archival purposes.

I don’t usually write “utility” posts that describe a way to fix a very specific problem but I ran into something that doesn’t seem to have a good resolution path online.

A huge part of this article is all of the debugging/troubleshooting I’ve done to get everything to work. The entire project took me more than a week of focused work as well as bringing in another coder for pairing for several hours almost every day. I’ve had to switch from working on my laptop (which was getting overheated and stuttering at the constant recompiles) to my desktop which is currently heating my office way past comfortable temperatures. This was an excruciating process but…I did it!

The Problem

If you’re using Angular (or “Angular2+”), you might be using the angular2-template-loader which allows you to do some neat things such as require all of your Component templates and SASS files which you can then run through other loaders in Webpack.

You’ll send up with something like this for your components:

@Component({
  template: require('./button.component.html'),
  styles: [require('./button.component.scss')]
})
export default ButtonComponent {}

Whoa, check that out, we can use SCSS in our Angular components. That’s kind of the power of it. Angular2-template-loader will then load up the html/scss (or rather its post-processed versions) and inline them within the template itself.

The problem is that this effectively disallows AoT or Ahead-of-time compilation. So while the angular2-template-loader is very popular, often used in tutorials, and very easy to setup, it also creates a problematic solution for the AoT compiler.

The AoT compiler

AoT stands for “ahead of time”. The AOT compiler will look at the templates referenced in a component, parse them, and create the JavaScript logic to do what the templates ask it to do.

The best way for me to describe the AOT compiler is that instead of parsing through the HTML, figuring out where there are repeats, what components are referenced where, etc. at application boot time (when the browser loads the application), it happens during build time.

In our case at work, this process seems to take several seconds which is absolutely ridiculous. Plus, if you compile on application load, you have to include the compiler in your bundle.

But…angular2-template-loader doesn’t do AOT (it doesn’t claim it does!) and AOT can’t happen with it.

The webpack loader alternative

The immediate alternative I’ve found is the @ngtools/webpack package which not only does AOT but also serves as a TypeScript loader! It does some other things as well but I want to focus on this first.

First, we gotta replace the old angular2-template-loader and whatever typescript loader you’re using, this should look kind of like this at the end (and your TypeScript loader and your angular2-template-loader should be gone):

// somewhere in your webpack config
rules: [
  {
    test: /(?:\.ngfactory\.js|\.ngstyle\.js|\.ts)$/,
    loaders: [
       {
       loader: '@ngtools/webpack',
       },
    ],

  }
]

You also need to your webpack plugins:

import { AngularCompilerPlugin } from '@ngtools/webpack';

// and somewhere in your webpack config
plugins: [
    new AngularCompilerPlugin({
      tsConfigPath: './tsconfig.json',
      entryModule: './web/modern/main.ts#AppModule'
    }),
]

Fantastic! The only problem? All those requires..

Fixing the html requires

The problem now is that we have tons of components that have that fancy require for templates and styles. What do we do now?

Here’s why I’m writing this so I can share/document this info and come back to it. Phew. So, @ngtools/webpack allows us to do similar requires but without the require.

Basically, we have to change

@Component({
  selector: 'button-component',
  template: require('./button.component.html')
})

into:

@Component({
  selector: 'button-component',
  templateUrl: './button.component.html'
})

Note that we’re still referencing a templateUrl, not a template. NgTools brings that template in and does AOT on it. So how do we do this change on a large scale? By using the Unix tool grep and then using plain ol’ node to do the changes

Grepping for all files

Grep is a unix tool present in Linux, macOS, and other systems. You can also get it on Windows. Unfortunately, Windows’s Select-String will not the do the job we need it do to today (though go read about how to use Powershell’s Select-String like grep if you’re into that).

With grep we can select all the files that need updating.

grep -rl 'Component({' /path/to/application

The flag -r will make sure grep looks recursively through files in your application with the string Component({ in it.

If you just run this by itself, you’ll get a long list of files that you need to update; however, we can use node to do the replacement for us.

Change your files

Here’s the thing, I tried sed, I really did. But it took so long to do one small operation that I figured I might as well write a node script for it.

First, we need a really complicated Regex that can do the correct substitution and replace require('./template.component.html') with just ./template.component.html:

/Component\(\{(.*\n)+.*template: require\(('.*\.html')\)(.*\n)+\}\)/

Oh s***, wtf is that? Well, I hate to say this but this is our ticket to freedom. What this regex does is:

1. look for the Component({ string
2. it matches “however many newlines filled with characters” (that’s the (.*\n)+)
3. it finds the template string with the require. Note the extra parentheses
4. group matching allows us to identify just the HTML string via ('.*\.html').
5. and then we match for “however many newlines filled with characters”
6. and finally we match for the closing }).

Basically anything that matches this pattern:

@Component({
  something: else,
  doesnotmatter: whatshere,
  template: require('./path/to/template.html'),
  moreKeywords: withData
})

It doesn’t matter how many keys are in that object or what data, as long as it has a template that requires an HTML file, we’ll match on it.

Let’s write the node script. It’ll need to read the path of a file as an argument, do the substitution, and write to that file with the changes. I’m going to skip the craziness of explaining this step by step so here’s the final JavaScript file:

const path = require('path');
const fs = require('fs');

function run() {
  /*
   * Args which should look like ['node', 'path/to/this/script.js', '/path/tofile.ts']
   */
  const args = process.argv;
  const files = args.slice(2);

  files.forEach(file => {
    changeFile(file);
  });
}
function changeFile(relativeFilePath) {
  const filePath = path.resolve(__dirname, relativeFilePath);
  const fileString = fs.readFileSync(filePath).toString();
  const regex = /Component\(\{(.*\n)+.*template: require\(('.*\.html')\)(.*\n)+\}\)/;

  const match = fileString.match(regex);

  if (!match) {
    return;
  }

  const htmlPath = match[2];

  if (!htmlPath) {
    return;
  }

  const replacementLookup = `template: require(${htmlPath})`;
  const replacement = `templateUrl: ${htmlPath}`;
  const newFileString = fileString.replace(replacementLookup, replacement);

  fs.writeFileSync(filePath, newFileString);
}

run();

Basically, this script will:

1. read in script arguments to get the file paths
2. read the files one by one
3. use that fancy regex to find a match. match group 2 (3rd item in the array) will be our html url
4. do a replace on the file string where the original template value gets replace with the new one
5. save it!

Note This script is pretty handy. You can use it to update the styles as well if you run into that issue in the troubleshooting section.

Put it all together

Ok, so to put it altogether, we use one more unix tool, xargs. It’ll pipe the result of our grep into our node script which will then perform our replacement.

Caution This is a destructive action. Meaning that it’ll affect each file and run directly. I’m not responsible for whatever problems you might run into with these scripts. MAKE SURE that you’re using something like git and have committed all of your code changes up until this point so you can do a quick git hard --reset should you run into problems and get back to a working version of your project. PLEASE do make sure of this.

grep -rl 'Component({' /path/to/application | xargs node replace.js

The script will get each file as a separate argument so the xargs actually calls node replace.js path/to/component1.ts path/to/component2.ts and so on.

After this, you should be done!

The results

I want to share some preliminary benchmarks that I’ve done:

1. initial load time in a dev environment dropped from 10 seconds to 3 seconds uncached
2. initial load time (cached) dropped from 8 seconds to 1.8 seconds in a dev environment
3. compiler time is way more resource intensive (my office is a sauna)

I cannot wait to try this out in a production environment.

Template problems?

The compiler will call you out on your issues. I’ve mentioned it in Potential issues but it bears saying separately first: angular-cli will compile your templates. That means that it’ll check for variables, it’ll check for bindings, it’ll check for everything. And it will let you know if you messed up. Common issues that I’ve had to fix:

1. referencing variables in the template that don’t exist in the component
2. calling a function with the wrong number of arguments
3. passing in a variable to a component which does not have an input to receive that data

Potential issues

There were some issues I ran into during this conversion and I wanted to share how I was able to resolve them. Most of these have opened and/or closed issues on the angular-cli repo. :/ If you look up the errors directly, you can find those and follow the conversation. I wanted to provide you with how exactly I solved the problem and what other solutions were suggested.

IMPORTANT NOTES:

1. MAKE SURE you’ve saved your work and committed it in Git — and NOT to your master branch. SERIOUSLY. I had to keep referring back to the master branch and the clean codebase
2. MAKE SURE you don’t try to change things ahead of time. Look at the potential issues that YOU experience
3. It’s ok if you have to undo some of the solutions
4. I can’t fix this for you

ERROR in : Cannot determine the module for class AppRootComponent in /path/to/component! Add AppRootComponent to the NgModule to fix it.

I saw this come up in a few different places in issues and elsewhere. There are four solutions I’ve found to this issue:

Possible solution 1

You probably have bad import paths that webpack/node doesn’t care about but the compiler does. Most of the time, this is due to capitalization. Make sure if you’re importing a file that has capitalization in it (like AppRootComponent.ts) that you’re capitalizing correctly in your import path. You can actually do an import like ./path/to/approotcomponent, and node/webpack won’t complain.

Possible solution 2

The other possibility is that you have components that either aren’t part of a module or are simply unimported but still in the working directory. Check for either of those situations and either put those components into modules or remove them.

Possible solution 3

Lastly, and this was my situation, you’re using components in your main module. Urgh, I hate this problem because I think it shouldn’t be causing these issues. Basically, if you have an AppRootComponent and you’re using it to bootstrap Angular, put it in another module first, import that module, and then bootstrap.

Possible solution 4

There’s another hidden error. As I was working through making everything work and through all of the other problems, I found out that I was still able to bootstrap AppRootComponent at the end of my journey, as long as it was part of my entry module (AppModule). So…I ended up reverting the solutions above once that happened.

ERROR in path/to/component/button.component.ts.ButtonComponentComponent.html(1,21): : Expected 0 arguments, but got 1.

This usually means that you have a typing issue in your template itself. There are several situation this shows up in:

1. you’re calling a method or using a variable that was marked as private in your component
2. you have a typing issue. Eg. you’re passing the wrong number of arguments into a method (this was my situation!)

TypeError: Cannot read property ‘_ngToolsWebpackPluginInstance’ of undefined

This error occurred to me when using HappyPack with @ngtools/webpack. They’re not compatible so just use @ngtools/webpack directly rather than with HappyPack

Module not found: Error: Can’t resolve ‘./main.ts.ngfactory’ in ‘/path/to/application/directory’

Another strange problem that I don’t understand. Note that main.ts is my entry file so that name may be different for you (such as app.ts). There are three solutions that I’ve found to this:

1. adjust your rootDir parameter in tsconfig check out the relevant issue
2. install enhanced-resolve via npm install enhanced-resolve@3.3.0 here’s the relevant issue
3. you can add .ngfactory into the extensions that webpack needs to resolve in extensions.resolve in your webpack config

If none of this works, go ahead and adjust the @ngtools/webpack config by not specifying the entryModule and specifying an absolute path to the mainPath.

{
  mainPath: path.resolve(__dirname, '/path/to/entry/file')
}

This disables lazy route loading (automatic code splitting by route) which is a bummer but it was necessary in my case and the code splitting wasn’t an issue for me anyways because I use an Angular/AngularJS hybrid app where the router rests on the AngularJS side.

Phew, let’s keep going!

Potential issues in more complicated build chains

I wanted to split this section off because it’s more likely that it’s my own specific application architecture that causes these issues rather than something ngtools/webpack is responsible for.

TypeError: library_1.default is undefined

This issue basically means that a module is not available. It was an issue because the TypeScript compiler was compiling JavaScript files. Why is that a problem?

While Babel has no issue with this:

import _ from 'lodash';

TypeScript requires this syntax:

import * as _ from 'lodash';

What that meant for me was to switch to the TypeScript compiler entirely and adjust all of the import paths — I ripped out our Babel compiler and changed the @ngtools/webpack loader to match against all .js files.

Here’s the look up regex if you want to adjust the replace.js file I mentioned above: /import ([a-z0-9A-Z_]+) from/g;. I could write a whole article about the process so if you do get here, just comment below! And I’ll give you the step-by-step process.

But, make sure you don’t change the import paths for your own modules!

Host should not return a redirect source file from getSourceFile

There’s an open issue on Github for this error and it suggests patching the compiler… yeah. The patch does work (I’ve tried it) and it basically involves:

1. looking up ./node_modules/@angular/compiler-cli/src/transformers/program.js
2. finding a line that starts with if (this.hostAdapter.isSourceFile(sf.fileName)) {
3. and putting if (sf['redirectInfo']) { sf = sf['redirectInfo'].redirectTarget; } right before

That essentially replaces a source file redirect with the actual file it redirected to. doesn’t mean much to me; however, if you don’t want to manually patch stuff in node_modules (even with the useful postinstall script included in the Github issue), you can do what I did and instead of step 3 where you set the redirect, you can log out the problematic files!

if (sf['redirectInfo']) {
  console.log('SF: ', sf.fileName);
}

And then tackle the problems that show up. In my case, the library @turf/turf was having some issues and namely, each module in @turf/turf was importing @turf/helpers and that was causing issues. I was able to solve those problems by:

1. destructuring any imports from the problematic library
2. using/installing submodule of the library directly

And I’m gonna also throw this in there: look for alternatives if it’s not a huge cost to you.

SASS/SCSS not loading?

I encountered this issue as well. There’s a closed ticket for it with not much information; however, if you’re wanting to use SASS (and haven’t before!), check out the thread for information on the SASS loader.

However, if you’ve used it before and things aren’t working now, you just need to change how you load your styles:

// from
@Component({
    styles: [require('./path/to/component.scss')]
})

// to
@Component({
    styleUrls: ['./path/to/component.scss'] 
})

Additional Resources

There were a few resources that helped me along the way:

• Upgrading a project without cli to Angular 6

But Why?

Why am I sharing this long-ass article that has no clear path to navigate through it? So you can understand my journey. How I’ve struggled, what I’ve seen, and where I had to look for answers.

I’m a new person today. I look in the mirror, and I don’t see the Antonin that I saw two weeks ago when I was preparing to make this loader change. I’m not the same developer.

These were trying times. My sanity has been tested. My perseverance has been tested. There were many nights when I wanted to shout at webpack, at Angular, at Angular-CLI. To blame someone for this but I couldn’t. Code just…works this way sometimes. And sometimes, issues aren’t reproducible and so they can’t be addressed by the open source maintainers. And yet, it worked out. It worked.

Check out the screenshot at the top of the article. Look at how many changes I’ve had to make! It was…a lot of work.

Despite all of that…I’m glad that ngtools/webpack exists and that angular2-template-loader existed when I first started transitioning to Angular. Without the ngtools, I wouldn’t have been able to cut down on our load time enough for us to move onto the next stage of our application development: rewriting everything in React.

The post Switching from angular2-template-loader to @ngtools/webpack appeared first on AntJanus.

Without further ado, here are my favorites to brighten your day:

When you reach wizened-engineer level, there are at least a hundred wizened engineers above you.

A deployed MVP is worth two prototyped.

Sleep on a force push.

Sometimes you have to cut legacy support to allow the new product to bloom.

Good test coverage + automated workflows = quiet cell phones and better sleep.

There is no test without first a failure

Anger and stubborness make bad allies in code review

With commit and deploy access comes great responsibility

Don’t put all your logic in one method basket

A foreach loop avoided is a CPU cycle earned.

This post was originally posted on dev.to and has been moved to this blog for personal archival purposes

The post My Top 10 Programming Proverbs appeared first on AntJanus.

Table of Contents

• useEffect for lifecycle methods
• componentDidUpdate + componentDidMount
• componentDidMount + componentWillUnmount
• useEffect for general side effects
• useState
• useReducer
• Building Your Own Hooks

useEffect (for lifecycle methods)

useEffect, among other things, allows you to write your own side effects and trigger a re-render when needed.

But to make it simpler, useEffect also substitutes lifecycle methods. Let’s talk about them.

substitute for componentDidUpdate + componentDidMount

When does it run? On every render

What’s the catch? It’s not just a componentDidUpdate replacement, it also runs on mount. So it’s not 1-to-1

Important features? useEffect can take in a 2nd argument, you have to skip that argument. You can also return a function, we’ll cover that in the next section.

Code sandbox playground: Go play with it

Syntax:

import { useEffect } from 'react';

useEffect(() => {
  // whatever runs here will run on each re-render
});

substitute for componentDidMount + componentWillUnmount

When does it run? On component mount and unmount

What’s the catch? The syntax is very close to the previous use case. It threw me off several times but it makes sense once you read the docs. If the effect runs more than once, make sure you passed in the 2nd argument

Important features? This is an effect that runs only once. The mount logic goes in the body of the effect function, the unmount/cleanup logic goes into a function that you return from the effect.

Code sandbox playground: Go play with it

Syntax:

import { useEffect } from 'react';

useEffect(() => {
  // run mount logic here such as fetching some data

  return () => {
    // unmount logic goes here
  };
}, []); // note the empty array

You can leave either the mount or unmount logic empty to work only off one of those lifecycle substitute. Meaning that:

1. leave mount logic empty so that only unmount logic runs (substitute for just componentWillUnmount)
2. return nothing so that only mount logic runs (substitute for just componentDidMount)

useEffect for side effects

useEffect‘s primary goal is to encompass any side effect you might want to use. A side effect is essentially something that you do within your component which affects the world at large. Whether that’s a network request, setting the document title, or what have you.

Run when necessary

When does it run? when the component re-renders, useEffect will check dependencies. If the dependency values changed, useEffect will run the effect

What’s the catch? React does a shallow comparison. If you use an object or an array that you mutate, React will think nothing changed.

Important features useEffect skips running the effect when things don’t change. You don’t actually have to use the dependency values in the effect. You can pass in a prop value as a dependency.

Code sandbox playground: Go play with it

Syntax:

import { useEffect } from 'react';

function SomeComponent(props) { 
    useEffect(() => {
      // logic runs only when dependency variables changed
    }, [arrOfDependency, values, props.id]); // array of values to check if they've changed
}

Potential use cases

Since the hook is more difficult to explain, I’d like to offer a list of use cases

1. run a side effect (like a fetch) when a prop changes to get new data
2. run a resource-heavy calculation only when the calculation values change
3. update the page (like document title) when a value updates

useState

State is probably the reason why people switch from stateless (functional) components to class components. useState allows us to have stateful components without classes.

What does it return? Current state and a function that lets you set state

What’s the catch? The state setting function will replace the previous state with the new one rather than merging them as class state would have. You need to merge your objects yourself before setting the state.

Important features You can use as many useState hooks in your component as you want. Passing any value to useState will create the initial state. It’s also a convention to not call the variables state and setState but rather by contextual names (eg. user and setUser). useState accepts any value for state, it doesn’t have to be an object.

Code Sandbox playground: Check out the useState examples

Syntax:

import { useState } from 'react';

// setup
const defaultValue = { name: "Antonin" };
const [state, setState] = useState(defaultValue);

// scenario 1 usage
// resulting state only contains key `user` with value 'antjanus'
setState({ user: 'antjanus' }); 

// scenario 2 usage
// resulting state contains key `name` with value 'A. Januska'
setState({ name: 'A. Januska' }); 

// scenario 3 usage
// resulting state is a merger between `{ name: 'A. Januska' }` and `{ user: 'antjanus'}`
setState({ ...state, user: 'antjanus'}); 

useReducer

useReducer is an alternative to useState and if you’ve used Redux in the past, this will look familiar.

What are the arguments? What does it return? useReducer takes in a reducer function and the initialState. It returns the current state and a dispatcher (sound familiar?)

How does it run? On state change, dispatch an object with a type and a data payload (read about flux standard action for more info). The reducer we passed into useReducer will receive the current state and the dispatched object. It returns the new state.

What’s the catch? It’s a more complicated workflow but it works just like you’d expect if you’ve used Redux.

Important features The reducer gets run on every dispatch. It gets access to the previous state. useReducer also includes a 3rd argument you can use to create the initial state

Code Sandbox playground: Check out the useReducer example

Syntax

import { useReducer } from 'react';

function reducer(currentState, action) {
  switch(action.type) {
     // handle each action type and how it affects the current state here
  }
}

function SomeComponent() {
  const [state, dispatch] = useReducer(reducer, initialState);

  dispatch({ type: 'ADD', payload: data }); // { type: 'ADD', payload: data } gets passed into the `reducer` as the `action` argument while `state` gets passed in as the `currentState` argument
}

Building Your Own Hooks

A quick note on building your own hooks. It’s as easy as using the existing hooks and composing them together inside of a function that starts with use. Here’s a quick example of a useUser hook.

What are the requirements? That the function starts with the keyword use. Eg. useUser or useSomethingElse.

Important features: you can call any hooks within your custom hook and it works as expected.

Code Sandbox playground: Check out the custom hooks example

Syntax:

import { useEffect } from 'react';

function useUser(userId) {
  let [user, setUser] = useState(null);

  useEffect(() => {
    fetch(`/api/user/${userId}`)
        .then(data => data.toJSON())
        .then(data => setUser(data));
  }, [userId]);

  return user;
}

function SomeComponent(props) {
  const user = useUser(props.id);
}

What about the rest?

There are other hooks you can use such as useMemo, useCallback and so on. I would say that those are more advanced hooks and if you understand the basic hooks, go ahead and check out the official docs.

I also understand there are some advanced usage examples for many of these (like passing useReducer’s dispatch down several levels).

If you find something incorrect or some extra information useful that isn’t included, let me know! And I’ll include it!

Did you find the cheatsheet useful? Buy me a coffee so I can keep doing this and produce more content! You can also follow me on Twitter

The post The Definitive React Hooks Cheatsheet appeared first on AntJanus.

Three years later, I’m now here to expand on this and discuss why prototypes and spikes are foot-guns rather than solutions and how tracer code is a better approach to problem-solving, especially in a fast-paced environment.

If you’ve read the Pragmatic Programmer, you’ll find this concept familiar, that’s where I learned about it as well.

What’s a prototype? What’s a spike?

Let’s get definition for these first. The idea of both a prototype and spike is to write disposable code in order to learn and in order to test an idea/library/whatever out.

For example, you might write a “prototype” rewrite of your product in another language. Fancy Elm? You might rewrite a difficult section of your current product in elm as a test and then analyze the results:

1. Does it perform just as well?
2. What is the developer experience like?
3. Does it have community support necessary for long-term development?

And so on. Based on your “test” results, you might either go with that decision and write a permanent solution based off lessons learned during the prototype development/spike or you might realize that this is not the right decision at this time.

A spike is a similar idea but might require less development and more research. Basically, it has more to do with spending time on an idea/decision and investigating it rather than creating a functional prototype.

What’s great about prototypes?

Prototypes can be fantastic. Why? Prototypes encourage taking hard shortcuts in order to get a working idea out and to be tested.

For example, if you wanted to create a prototype for an image gallery app, you might heavily rely on off-the-shelf products in order to get you to the finish line as quickly as possible. You might cut corners on testing, cut corners on the development experience and so on.

You’re testing the image app idea and the only thing that matters is having a final product to show users in order to get feedback. Do people want a gallery app? Does it have any advantages over existing solutions? How does it differentiate? What technical challenges do you foresee after building the prototype?

The biggest advantage over regular development is that you don’t have to care about the details, you only care about the idea you’re testing and getting there. This means you get to develop faster and spend less time yak shaving.

And then you throw it out.

You take the knowledge you’ve acquired from development and feedback, and then you craft a long-term solution from scratch based on that information.

What’s terrible about them?

That last part, the “throw it out part”. Let me show you something:

I’ve been working on a “prototype” for 4 years. There are nearly 14,000 commits, nearly a dozen contributors over the years, 1300 releases. We’re on major version 9.x (we don’t follow semver but each major bump is a HUGE feature or huge rewrite).

The problems with prototypes have more to do with “culture” than anything else but the problems (in my head) are insurmountable in most cases:

1. prototypes often work and look “good enough” to encourage people to keep it instead of rewriting it
2. deadlines often push against the idea of rewriting prototypes
3. management sometimes doesn’t understand the idea of a “prototype” fully. If they see a functional product, they’re expecting “the final product” to take less time than the prototype took to develop.

The reason I stuck with a “prototype” for 4 years is because when it was time to do a rewrite, it no longer made sense. Things were “good enough”, we were a startup, we were burning bootstrapped money, and I made the development decision not to rewrite but instead focus on delivering features to clients.

I see developers trapped in this time and time again. “I’m testing out an idea” more often than not turns to having crap code with cut corners making it to production.

So my rule is:

Expect a prototype to become the basis for your final product. Expect your prototype to never be thrown away even though it should be.

An aside: what developers do to make prototypes to be more likely to be thrown away

This is semi funny but after talking to other developers, reading articles, and listening to podcasts, I’ve found an interesting pattern. Developers will create a prototype a specific way in order for it to be more likely to be thrown out using methods such as:

1. naming variables horrible things so that no one wants to work on the code base
2. using an unknown library/framework incompatible with existing products
3. writing it in a language no one else is comfortable using — thus making the prototype useless long term
4. naming the repository silly names (guess what? Naming something “prototype” apparently doesn’t work! )
5. using jQuery for a single page application prototype
6. using PHP in a non-PHP shop for server/back-end prototype

Don’t try the last one on me because I like PHP.

An exception to my depressing rule

If you have a culture centered around prototype development, then the downsides of prototypes don’t exist. I know some developers that are used to doing prototypes and spikes without the drawbacks of having to use them in production.

This can be fantastic. But it takes time and energy and investment to setup that culture.

A better alternative — Tracer code

There’s a decent short discussion on tracer bullets on StackOverflow but the gist is this:

Tracer code is not disposable: you write it for keeps. It contains all the error checking that any piece of production code has. It simply is not fully functional.

To break this down to the important components:

1. tracer is not disposable.
2. tracer is written similarly to production code
3. a tracer doesn’t have to be fully functional
4. a tracer is meant to be the base for the final product

You can already spot the differences and advantages.

Tracers are great for testing out ideas that you plan on having in the production environment. They’re different from prototypes in that you should be more “sure” in your idea. Tracers aren’t disposable.

In my mind, they’re supposed to be one of the final steps in building out a solution. A tracer ensures that your idea for a solution will work in a production environment. This is after you decide on architecture, after you ensure that your ideas are sound, and after you plan things out. But before you write any code.

Good Tracer practices

If you’re testing out a framework or a new language, you wouldn’t use a tracer. You’d use it to ensure that framework/language works for that one specific purpose in your application — and use that tracer as breaking ground for further development.

But here is my list of Tracer practices:

1. stubbing out functionality is okay as long as you have a solid plan for extending that stub
2. you don’t necessarily have to have tests, but write code as if you did
3. the most important code you write are the interfaces/endpoints which other code interact with
4. don’t leave major changes for “later”

The last one is especially important. When working on prototypes, it’s easy to leave things for “later”. If you’re planning on writing code that’ll live on in your codebase, you need to recognize when your code has gone awry and already needs a rewrite.

This is hard but these small rewrites pay off in the end. I’ve had this happen several times recently and while I was kicking myself in the butt for making an assumption that lead me to write code I had to rewrite, it was worth it because it saved me from writing legacy/bad/broken code before it even ships.

Bad Tracer Practices

Every practice has its issues and every practice has footguns. A footgun is essentially a “thing” that is seemingly designed to help you fail as badly or as quickly as possible.

So if you’re getting used to the idea of writing tracers, here’s what to watch out for:

Tight coupling with existing code

Tracers should ideally be semi-isolated systems that expose some interface or endpoint for other code to use. For example, if you’re writing a “tracer” focused on building out a helper toolbar for your app, it shouldn’t dive too deeply into existing code to modify store values, or state management, or change how services work which would impact the rest of your app.

It can rely on existing services, but you shouldn’t be making major changes to your main codebase.

Vague focus

Whilst prototypes encourage exploration, tracers are more focused. If you can’t identify the end-product of your effort, you shouldn’t be writing a tracer. You should probably do more research.

For example, a tracer shouldn’t be something “give management ability to increase conversion by changing things on the site”. No, it should be “create a feature wherein a manager can create an A/B test via simple CSS that is tracked via our analytics suite”.

Without a focus, you don’t really know what you’re writing. If you don’t know what you’re coding, you’re not writing a tracer.

Fear of throwing away bad code

This is that footgun I was referring to. Tracer are not meant to be thrown away but that doesn’t mean you can’t adjust course. Or bend the rules.

It’s happened to me several times before where scope changed over the course of coding a new feature. It’s not meant to happen, you should be pretty sure of what you’re trying to do beforehand, it doesn’t mean that you’d either finish a feature you no longer need, or try to avoid a rewrite just because this article says so.

A personal example

This whole article is fairly vague. It’s hard to actually write code snippets that demonstrate the differences or to describe an exact feature where you’d apply one concept over another.

However, I have quite some experience writing both tracers and prototypes. Both in my personal projects and at work.

I have a couple of personal projects that I’d like to share some info about to demonstrate the difference between a prototype and a tracer.

OMEN

OMEN was my markdown editing environment. Think IDE but for writers and in markdown, similar to Scrivener if you know it. I took the prototype approach, mainly because it made sense. I was working with a brand new stack: Angular 2 (which I had limited experience in), Electron (again, limited experience), and CodeMirror for editing (no experience).

All three technologies were new and before fully testing them out and learning about them, I took my limited experience and ran with it. I wanted to get something out.

So, I tirelessly worked on getting an MVP out. I picked an approach and immediately used it just to get that end-product that I could use to write a book (and I wrote a good 30K words in it!). I took really bad shortcuts. The developer experience sucked (and made me not want to return). My store had an architecture where I coded myself into a corner. And on top of it, CodeMirror wasn’t exactly what I needed.

I abandoned the project but learned SO MUCH about writing an editor. I really loved it and I took what I knew to my next project. I used my new-found Angular 2 knowledge to push our product at work to Angular 2. I learned enough about Electron where my next Electron use was pretty straightforward.

Skok

Skok was a recent project that I’m still working on. It’s a desktop photo manager app. I used a slightly different stack than with OMEN but I stuck to Electron.

And I did everything right because I took the time to research, plan it, and drill into my head that this isn’t to throw away. It made me acutely aware of places where I wanted to cut corners just to get that pre-Alpha out. Instead, I planned for the long-term.

I built a great architecture around Electron <-> React interactions, and I focused on the developer experience so that the project was pleasant to work with.

At the same time, I had a very tight focus on a minimal setup. My plan was: scan, display photos, and setup for more features. And I did. I got the initial photo indexing and photo viewing down very quickly and when I started working on more features, it was easy to plug them in.

The post Prototypes Don’t Get Thrown Out — Write Tracer (Bullet) Code Instead appeared first on AntJanus.

I figured it might be a good idea to put the list in a single post I can always link to.

Note: I am using Amazon affiliate links where I link to the books.

Clean Code: A Handbook of Agile Software Craftsmanship

While this book might be considered quite old at this point, it’s still very much on point when it comes to creating maintainable code. Some of its principles I no longer agree with but it really drives the importance of planning out code and writing it so that it’s much easier to maintain in the future. A few bits that still stick with me:

1. if a function has more than 2-3 arguments, split it up. That’s way too many arguments
2. keep functions short, easy to understand, and focused on a single goal
3. test driven development
4. use meaningful names

There’s so much more to learn from the book and it has become a staple among programmer.

If you don’t feel like reading it or can’t/won’t pay for a copy, look up the book title and you’ll find plenty of videos and articles of people discussing the various important parts of the book

The Pragmatic Programmer: From Journeman To Master

I’m still about halfway through this book. This book is amazing for anyone starting out a career in development — and anyone well into it. I found it shows and explains various scenarios you’d find in the real world and then it discusses strategies to tackle them. It features tons of ideas about how to keep your code clearly separated, how to think about concurrency, how to address code that needs to clean itself up, and so on.

Probably my favorite part of the book is the discussion around what “prototypes” are for, how to use them, and so on. And then it discusses the idea of a “tracer bullet” (which I’ve discussed in my post My Experience Running Development At A Startup) and totally won me over and changed how I do development.

Game Programming Patterns – GMP free to read on the web

Before I get into it, you might be thinking, but why game programming? I’m a web developer and this book is just as relevant to web devs as it is for game devs. This book is by far the best resource I’ve found that discusses common (and well-known) programming patterns — from their advantages, to their drawbacks, trade-offs, and their details. All neatly written to be easy to understand.

There are quite a few that I absolutely recommend reading about:

1. Object pool
2. Dirty Flag
3. Singleton — because that’s how your node imports work!
4. Observer

I also suggest reading the game loop and update method patterns if you’re into gaming.

Non-Violent Communication

This might seem off-beat but despite being a non-programming book, I found it extremely useful in terms of communication and applying empathy to my work. Not only that, but I found it useful in my interactions with my teammates and my other co-workers. It covers a few key concepts:

1. how to ensure both parties are in full understanding of a concept
2. applying empathy in stressful situations
3. value of honesty
4. value of expressing your own needs

All of those have been key in my career in one way or another. Here’s a dirty secret: my own team focused on communication with each other and with our manager heavily. Improved communication lead to greater job satisfaction (personally) but it also lead to better code, feature releases, better conversations around development roadmaps, and so much more. We didn’t use NVC but we did make big changes into how we’re organized

Books I haven’t Read (Yet)

I have a stack of books in my GoodReads that I want to read, and even a longer stack of books I keep in my head. I can’t personally vouch for these but I do see these come up over and over again on Twitter, here, and elsewhere:

CSS Secrets

A book that made waves when it dropped, CSS Secrets by Lea Verou is a book focusing on techniques and tips and programmatic solutions to your CSS problems and how to practically write CSS. If you’re not sure this is for you, check out one of her many talks.

Refactoring UI

Refactoring UI by Adam Wathan and Steve Shoger has been making rounds on my radar and I think it’s a worthwhile book to look into. I haven’t personally had time to check it out but I’ve heard of Adam’s courses that people love and I have closely followed the development of Tailwind CSS which is his CSS framework.

Got any books you’d like to recommend?

The post The Books That Made All The Difference To Me As A Developer appeared first on AntJanus.

Just kidding!

So first, this is a blog post in a pretty long series of personal updates that I started back in 2012 (and probably before that on my old blog). It has always given me the focus I needed to look back without judgement or bias, and organize my thoughts on what I’ve been up to.

Let’s review 2018 goals real quick.

Original goals progress

In summary:

• Website redesign
• Hugo blog
• ng-redux support
• unity tutorials
• finish several personal projects
  • D20 Elixir bot
  • Slack proverbs
  • Quick pomodoro
  • Dashboard
  • Newsletter revival
  • app ideas repo

So, errr….I didn’t get any of this done. I spent some time on ng-redux and pushed out a 4.X release but that’s about it. I didn’t get a newsletter together, I didn’t work on Unity. I basically just abandoned all of my goals in various states of disarray.

I do have a newsletter setup but I don’t use it. I keep wanting to use it but given how long this article took to write, it’s obvious I’m unlikely to write in any sort of regular capacity using a newsletter.

I’ve been thinking about a redesign but never did it. In fact, I abandoned the idea of migrating my site away from WordPress. Too much work, not enough pay off. I briefly tried to make GatsbyJS work with Netlify on my antjan.us domain but even that I struggled to keep working.

These days, I rarely ever dive into side projects. You might ask why. Well…

Fulfillment at work

One of the reasons I’ve always gravitated toward side projects has been the work environment. Either work was really stressful and thus I couldn’t enjoy development, or there was a technology I wanted to try but couldn’t, or I’d just plain find my job boring.

One of the biggest changes at my job since January has been hiring several developers. We’re a team of six right now. That’s a big dev team for a small startup. And instead of scrambling to push features out, we’ve become a machine moving ever-forward. We’ve been rewriting the original app I wrote: both back-end and front-end. And we’ve been rewriting it in technology that I’ve enjoyed using: Angular and Elixir.

Angular

I used to write my side projects in Angular or React. And that was fun but a production environment is truly fulfilling. It requires deep thought, organization, future-thinking, and requires a consensus among the team. That has been driving me forward with my front-end development without really pushing me away to learn/use something different.

Don’t get me wrong, I’ve written some React/Preact here and there but there’s nothing like writing a nice component in Angular that fits into a larger codebase which customers use every single day.

Writing for a production environment also means that this is part of my work and I don’t have to sacrifice my much-lacking free time to use this technology.

Elixir

The back-end work has been great too. For years, I’ve been on the fence about what new language to learn. I’ve been coding a Discord bot in Golang for the past year but that’s been about it. I’ve tried Elixir but failed. Then, one of our developers wanted to rewrite our codebase in it for its various advantages over JavaScript/Node. Our entire team rallied behind the effort and now, all new features go through our Elixir app.

Elixir is a lot of fun and doesn’t take a huge amount of time to learn. It’s the nuances of app development that really get you. The idea of separating apps, the idea that everything is a thread or something, that async stuff happens asynchronously but you don’t know that. Unlike in JS, where you have to manage asynchronicity.

There’s no way I could mount such a huge effort in my spare time to build an app that’d really test my skills and teach me how to use Elixir so this has been a ton of fun for me and has helped our development as well. We didn’t just write in Elixir for the writing in Elixir. We use its benefits to benefit our product.

Team Work

It might seem silly but team work and a positive developer experience can bring about fulfillment as well – even more so than the technology you might use.

We’ve switched to Docker at work and slowly reversed/fixed a lot of mistakes and holes in the workflow I’ve setup years ago. Right now, we have two separate apps that seamlessly interact locally and in production. We have a deployment workflow that smooths over any bumps along the way.

On top of that, we do dev meetings that really scratch the itch when it comes to progress, fixing and analyzing problems, and steering development in a positive direction.

All of this combined with awesome people on the development team.

I should mention that a lot of the “problems” we analyze and try to fix have to do with more than the Elixir/JS we write. We have been tackling project management, team structures, feature planning, and so on. So that satisfies the productivity junkie in me as well.

Things aren’t perfect but they’re definitely really good.

Unexpected progress

Content

The one thing I did that was unexpected was post several blog posts this year. I’ve been out of the blogging game for a while and writing anything was an accomplishment. I blame Dev.to for that, it’s a content/blogging platform for developers.

Scroll back through my feed and even check out my Twitter for some good content as well. I’m really active on there.

Outside of that, my Youtube channel is seeing some love with org-mode related videos and more.

Org-mode

I finally dove into org-mode. I killed off my old .emacs earlier this year and started from scratch. My config is super short and is used to enable some small options and include the bare minimum of packages I need for my daily use.

Over time, I learned Emacs and I learned to use it using its defaults, not via evil-mode, or thorugh spacemacs or other packages. What was great about that is that I’m writing this article via Emacs using absolute defaults. And it’s nice.

My “main” installation with its config works really well and I can always lean on generic emacs articles/youtube videos without having to worry about defaults having been messed with.

I still don’t use Emacs for development; however, Emacs + org-mode has pretty much replaced all of my todo apps, note-taking apps, etc.

Engineering Notebook

As part of migrating to org-mode, I’ve also started a software engineering notebook. I hope I can stick with it because it’s been pretty useful to look up error messages in my own personal notebook where I document solutions for problems I run into.

I hope to one day make it publicly available.

New Goals?

Confession time, I started writing this article months ago but I couldn’t finish it. Now that the year is coming to a close, I decided to update it. Originally, this section was empty with a quick explanation that I’m focusing on personal development goals (development as in personal growth) rather than tech goals.

A few things have changed since then so I figured I’d share:

try to become a development instructor

Between the YouTube videos I’ve been making, the Tweets I’ve been tweeting, and some encouragement from a friend, I found myself wanting to enter the game of teaching development rather than just consuming articles.

I’ve been on this path toward instructor-ship for a while and now it’s become a bigger goal for me.

one side app

I do miss side project development. One of my big issues has been focusing on one project and the idea that when I don’t have time to work on it, dependencies and the code goes to hell quickly.

I’m thinking of building a single app but I have three big ideas, each one with its own merits, each one having to do with a personal goal as well.

So here are the ideas:

• Skok – a photo management app whose main purpose is to take haphazardly put-together folders of photos and sort them out
• Omen – my markdown editor that I started a couple of years back. But this time, I’d like to finish it!
• Chislo – a super simple budgetting/finance app

2018 Personal

Goals Review

So last year, I had a few goals, nothing special; however, I did not get to most of those. My 52 sprint idea did not work out whatsoever.

But here’s the final tally:

• [X] finish Season 1 of Indigo League review for PUCL
• [X] vlogging/video creation
• [X] chore completion
• [X] back to working out – I’ve been semi-regularly running!
• [X] productivity prioritization
• [ ] get finance in order
• [ ] publish NaNo 2014
• [ ] publish NaNo 2016

And some unexpected progress:

• a good deal of gaming I’ve been meaning to get to
• way more fiction writing than I expected to do
• NaNo (idk which year) editing – currently on Chapter 6 out of 14

TV Shows and Movies

TV Shows

I watched quite a few fun TV shows but for some reason, I can’t recall most of them so here’s what I do remember watching:

• Supernatural
• Rick & Morty
• Handmaid’s Tale
• Naruto Shippuden
• Dragon Ball Super
• Disenchantment
• Badlands
• The New Legends of Monkey

Movies

I remember which movies I watched even less than which TV shows. I rewatched a ton of stuff I liked a while back and reaffirmed that I still like those movies:

• DOOM
• The Matrix trilogy
• All of Harry Potter
• Lord of the Rings and the Hobbit (both trilogies)
• Star Wars: Han Solo story – loved it!
• Beyond Skyline

Podcasts

• New Game Plus
• PUCL Podcast
• Nerd Poker
• Changelog
• Cortex

Books

Finished:

• 1Q84
• Star Wars The New Jedi Order: Vector Prime
• Insecure In Love

Still reading:

• Non Violent Communication
• A House Divided
• Return Of The King

Music

The past few years, I’ve posted individual songs, and while I can do that this year, I’d like to share the Spotify playlists that I’ve aggregated throughout the year:

• 2018 Favorites
• Secondary 2018 favorites – to mix things up
• 2018 Explicit favorites – I try to keep songs with any explicit lyrics in this playlist
• This is Tryo – not my own playlist but this is the music I started my day off to

Games

Playing/Played A Bunch/Finished:

• Overwatch
• Stardew Valley
• A Bird Story – finished
• Sonic Forces (Switch)
• Paladins (on Switch)
• Chrono Trigger
• Blockout II
• Halo: Combat Evolved
• Torchlight

Somewhat played/barely any progress:

• Might & Magic VII: For Blood and Honor
• Hexen
• Harry Poter And The Philosopher’s Stone
• Diablo
• Commander Keen
• Super Mario Land 2

Personal Goals for 2019

My biggest takeaway from life this year has been the importance of focusing one’s own development and how that solid foundation of “self” can translate outwardly as well.

But here are a few things I’d like to do:

general life management

That includes:

• finance management
• chores
• and other responsibilities

I’ve considered writing an app but it’d be too broad for anyone else to use. My main issue is that to manage my own life, I have to have either a very complicated system in a single app or spread everything out across too many apps.

continue running

Possibly run a 7K (I’ve got a 5K down pretty easy!) but I don’t feel confident that I can hit a 10K just yet. I’m not training in any way and simply run when I have time and feel the need to. Running a 10K would be quite difficult.

NaNoWriMo 2019

I’m not sure what I’ll write but I definitely have the goal to write yet another book. My hope is to make a standalone novel that doesn’t plug into any universe, story, or book I’ve already written.

Edit NaNoWriMo 2014/2016

I’ve been editing this book for a LONG time; however, I made some true progress this year. I’m at least a third way through my final editing pass and after that I’ll be bracing myself for some awkward self-publishing.

The quite wonderful thing about this is that my 2018 NaNoWriMo is a sequel.

The post How did 2018 Go, and What Now? appeared first on AntJanus.

TypeScript is awesome and I love writing it and over time, I’ve noticed my own style and my own patterns emerge one of which I’d like to share and, hopefully, justify why I stick to those patterns.

Local Interfaces > Global Interfaces

Interfaces in TypeScript are essentially object definitions that describe what an object should minimally look like. For example, if I had a DatabaseConfig interface, it might look something like this:

interface DatabaseConfig {
  host: string,
  port: number,
  password: string
}

function connectToDb(dbConfig: DatabaseConfig) {
  // database connection config
}

What that basically means is that whenever you call the function connectToDb, you need to pass in an object that looks like the DatabaseConfig interface (along with the appropriate typings for its properties).

A pattern I picked up from a Golang styleguide article (I can’t remember which) was the idea of “local interfaces”, interfaces that describe exactly what I need from an object within that single file.

This DatabaseConfig interface, if shared, will grow exponentially to encompass the needs of every function that might touch this object. A createDatabasePool function might additionally look for a poolSize property on that config which will now be required by every function that references this interface, whether they use it or not. Imagine that we also had a function that would return a driver for that particular database so we might need a type property which no function cares about except the driver one.

Basically, sharing interfaces (or using what I call global interfaces) causes interfaces to bloat and to impose artificial requirements on properties that might not even be used by the function/code block/whatever that references the interface. It creates a strange “coupling” between possibly unrelated pieces of code.

Instead, what I suggest is writing interfaces local to a file which describe only the necessary properties required to be in the object by the code in that file. Eg. if you have a createPool function, you might write something like this:

interface PoolConfig {
  poolSize: number
}

export function createPool(config: PoolConfig, driver) {
  // uses config.poolSize somewhere in the code
}

This way, we’re telling the developer working in that file that all we really need is poolSize and we don’t use anything else from that config object.

I’ve found this to be super useful in keeping with the idea that types are really just documentation that the computer can also view and utilize.

Exceptions

There are a couple of exceptions to this rule.

Those exceptions are that if you’re using object Models for your data, you might want to have those models available as interfaces as well to communicate to the developer (and the compiler) that you’re really requiring this model.

You might not care about the exact keys, you might care more about getting the actual Model (or something with the exact same shape).

The other exception to the rule is if you have complex objects that require keeping up with its complex shape. Imagine that you have an object that nests 5 levels deep. It’s more prudent to have a single interface that you import which describes this rather than writing out, quite uselessly, complex nested interfaces.

The post Keep Your Types And Interfaces Closer (In TypeScript) appeared first on AntJanus.