Don’t look now.. but I’m blogging!

I’ve been reflecting on a very diverse professional year. This year I’ve written or sustained codebases in the following platforms:

• Micronaut with Angular
• Golang with Gin
• Vue.js with Quasar
• Flutter for Android & iOS targets using MobX
• Bash
• and even large Classic Java EE codebase running on Wildfly

It’s a struggle to remember how to define a function these days!

Crunching the stats

I’ve been using a tiny git stats bash script discussed here to pull my numbers. Not large, but they do represent a decent amount of work (and a lot of learning).

Language	Commits	Files	Insertions	Deletions	Total Lines
Java	58	70	3224	316	3540
Dart	133	35	4388	2068	6456
Go	111	145	11228	1578	12806
Bash	58	34	1777	282	2059
Totals	360	284	20617	4244	24861

Some surprises from the year

And I’ve learned a few things along with the way…

• Micronaut is a delight. It’s all the things I love about Grails, but in Java form. It’s really straightforward to get things done. I’m yet to get stuck into GraalVM (on my list for first up next year).

• Go is verbose but relaxing. Yes, there’s lots of boiler-plate. And yes there are a few interesting design decisions, but overall I found it a really productive language and very easy to come back and maintain. Gin is a fab web framework with all the built-ins (including Swagger support). And compiling a single binary for the client’s numerous target platforms (including low memory embedded) has been something else…

• Flutter really does work cross platform. No, for reals. I built and tested on Android, and the client recompiled that codebase for their iPad and iPhone and everything “just worked”. Really. I was floored. Even the camera stuff worked! And the language is very Java-esque too. Super great stuff. Need to do more next year on mobile.

• Shell is awesome for client hacking. The scripts I developed were around letting a client hack their existing systems into talking with a third-party backend. They were slow, but super functional, and they let the client adapt them to other inhouse systems that I didn’t have access to. Super fun.

• Angular is awesome. Vue.js is awesome. Pick your awesome. Both super productive frameworks with great docs and examples. Great UI framework support via PrimeNG or Quasar. Produced some of the best-looking apps of my career this year.

• I need to code more in 2023. It brought me a lot of joy working on software this year - and it was probably less a part of my day-to-day than it has been earlier in my career. Really looking forward to leaning into it more in 2023.

I’ve just had a Sony XAV-5000 Head Unit installed into my teenagers 2006 Toyota Camry and it’s totally amazing!

The integration works great with steering controls, and whole Android Auto experience is fantastic.

However, it wasn’t always so.

If you’ve had the issue with:

• Frequent drops and reconnects on your Android phone
• Not even recognising your phone is connected

… well you’re not alone. I had the same problems.

There’s tons of threads about how bad the experience has been for people. The primary reason for the bad reviews is not the unit itself - it’s the constant dropouts. It makes the unit unusable.

But there is good news in this thread which captures the solution towards the end of the thread:

TL;DR: Replacing the USB socket with one that has a *much* shorter cable appears to have resolved the issue for me.

But I have even better news. This worked for me by just using a new shorter, high-quality usb cable and attaching to the USB extension provided with the unit. I didn’t need to open the dash again - just buy a new shorter cable!

Well it’s been a long year since I’ve posted anything here.. but it’s not because I haven’t been writing. Between studying at Uni, and keeping a chatty (and super helpful) personal journal, I’ve written more words in the last year than any other time in my life.

But it’s just that I haven’t been writing publicly. And I feel like I want to do more of that in this season.

So here we are.

And let me start by talking about some of my private writing…

For the course of this year, each workday I’ve kept a “Developer Journal”. It’s really just a scrapbook of the things that I have worked on each day.

Sometimes it’s documenting weird Angular stuff, or something I’ve learned about PrimeNG. It can be something I learned about refactoring or something I’ve read or realised in leveling up my professional skillset.

But often it’s simply documenting how I solved some problem that I ran into (with links to interesting stuff I discovered when I was researching it). Kinda like a personal blog but without the overhead. And super easy to search in later when I know the error message, but not how I solved it :-)

I use Microsoft OneNote since I can update it from client sites using OneNote online, as well as on my phone and laptop and everything just syncs nicely.

It’s been tremendously helpful to me - like a personal knowledgebase. I remember having friends who’ve kept personal Wikis back in the day - this is my modern version of that. But it’s also been useful to remind me of all the cool stuff I get to work on - and how much progress I’ve made on the days where I simply feel like “I’ve just got nothing done today.”

As my Pluralsight PWA Sensor Course leaps into record mode, I’ve been looking for ways to add visual interest to my camera shots - but without the overhead of mega-battery-drain client-side image processing.

Sounds like a great reason to dive into CSS filters as a lightweight way to transform captured images on mobile. After a little googling, I ran into CSSgram - a CSS filters library for Instagram style filters! How cool.

Import a CSS file, and you’re ready to filter:

Implementing a given filter is super quick. Pick one of the many style names, and add it the parent element of your image, and you’re off to the races. They recommend doing that via the figure tag, which I’ve done in the page above with:

<figure class="hudson">
    <img src="[[imageData]]" on-click="selectFilter">
</figure>

<figure class="inkwell">
    <img src="[[imageData]]" on-click="selectFilter">
</figure>

<figure class="kelvin">
    <img src="[[imageData]]" on-click="selectFilter">
</figure>

Definitely a cool way to add some pop to your PWA image capture stuff!

Have fun!

Whoa! I’m recording video and audio in my PWA app now! This is so crazy..

Turns out there is a MediaStream Recording API, so I’m putting it to good use on my PWA Sensors course (it will appear here one day).

Dude! I’m actually recording a video note - with audio - in-browser on my SurfaceBook at my local Maccas McCafe!

There’s an awesome Mozilla post that gives you a good nuts and bolts of the API - which I found super helpful.

The MediaRecorder stuff really builds on the MediaStream stuff I was talking about last week.

You take an incoming stream, then feed it into a MediaRecorder. Call mediaRecorder.start() to start recording - in my case I supply a “ms chunk size” with .start(1000) so chunks of video will arrive in my callback every second. Once started, your ondataavailable handler will start getting chunks of video. How cool!

When you’re done recording, invoke mediaRecorder.stop() (which I do from a button click - not shown here).

Once you call stop() on the MediaRecorder to stop the recording, your onstop handler will get called back. You then take that nice selection of video chunks that we have accumulated in the array, and Blob() it into an object that we can URL-ize.

Finally, assign your Blob URL to a stock standard vanilla <video> component and click play to playback your video!

I’m having a ball at the moment hacking around with the MediaDevices API in preparation for an upcoming Pluralsight Course on PWA Sensors (it will appear here one day). It’s just crazy what you can do in a browser these days!

One cool trick I’ve been playing with is populating a selectbox with a list of available cameras, then letting the user select the camera that they’d like to work with.

The API has an enumerateDevices() call which is handy for tracking down everything that’s available on your system. I iterate over the returned MediaDeviceInfo objects since having their label and deviceId is handy for my next trick…

navigator.mediaDevices.enumerateDevices()
    .then(function (devices) {
        let cameras = [];
        let microphones = [];
        devices.forEach(function (device) {
            console.log(device.kind + ": " + device.label +
                " id = " + device.deviceId);
            if (device.kind === 'videoinput') {
                cameras.push(device);
            } else if (device.kind == 'audioinput') {
                microphones.push(device);
            }
        });
        self.set('cameraDevices', cameras);
        self.set('microphoneDevices', microphones);
    })
    .catch(function (err) {
        console.log(err.name + ": " + err.message);
    });
}

Now I have that those list of MediaDeviceInfo, I can put them into a dropdown and we’re off to the races:

But what happens if you have more than one device? My Surfacebook has a front and rear camara, and so does my mobile handset. How do you tell the API which one to use?

The magic you need is the super-handy Constraints block. Pass this into your media acquisition, and can specify exactly which DeviceId you’d like:

let constraints = {
    video: {
        deviceId: selectedCamera.deviceId
    },
    audio: false,
};

That constraints object is all the secret sauce you need. Pass those constraints in your getUserMedia call and you’re in business:

If you’ve not heard Steven Pressfield talk about The Resistance, you need to spend three minutes and set that right.

Good. Now we’re on the same page..

I’m an avid daily journal person - I’ve been collecting daily posts for the last four years which I keep in OneNote. But this recent journal entry seems like something others may benefit from.

This post is about a bunch of my own internal resistance reasons that I use to procrastinate doing actual work on my next Pluralsight Course (which is on PWA sensors, and which I’m actually super pumped about)… and the rebutt to those lies so you can just get on with Turning Pro and actually doing the work.

Enjoy the journal!

---

Daily Journal. Tuesday, 20th February, 2018.

There is massive resistance on working on my Pluralsight course today - even though I have set aside the day to do just that.

So what’s under the waterline of this iceberg of resistance? What’s stopping the daily progress?

• Deadlines are creating fear and disappointment. I thought my accountability stuff - asking a friend and my editor to hold me to a deadline - would help me kick my own butt and make some progress, but the reverse has happened. It’s made me freeze. Scared to progress. Terrified of clicking record. Fearful I won’t ship anything in time and miss a great opportunity. BUT: that mindset takes hold when you forget: Habits make goals come to you!! Just fall in love with the daily grind and you’ll be done in no time. Just move the needle forward in some small way every day.

• Resentment that I’m not making hay while the sun shines. I have this awesome consulting opportunity at the moment that I could be monetizing every single day . But I’m busy tinkering on this slow-as-molasses course progress which I resent as anti-business-wisdom. BUT: will I resent this down the track? Absolutely not - I know the work an hour/get paid an hour thing is dead. I only do it at all because it’s a good way of keeping my dev skills applied in a real business team context - and grow my programming chops by working with other developers. Pluralsight scales out!

• Scared I don’t have the stuff. Ah, that old chestnut. That I “don’t know this area deep enough”. The truth is that I, like everyone, have many knowledge gaps - but I’m curious, and so will explore things with a beginners mind as I go along. My mind still plays the old, “there are better people out there in this area who will rubbish and ridicule this course”. BUT: of course, that’s all non-sense. Most real experts I know are gracious - and love to see others level up. And I’ll also be offering a ton of enthusiasm, a beginner’s mind, and a passion for levelling people up.

• Tension about having the (super large) tracts of time I (pretend I) need. I feel like there are constant interruptions, so how will I get in the flow for this course to progress? How will I move this forward in little blocks of an hour here or there? BUT: the truth of the matter is that I make great progress in a single Pomodoro - so there’s no risk of this lie really being true. Thinking in smaller blocks of time is very helpful.

• Zero self-compassion. No matter how much I track through, I’ll never feel like I’ve done enough, so why even start? Reality means other things do sometimes trump my courseware development. BUT: the other things that have trumped Pluralsight progress have been wonderful, and important, and it’s worth remembering my value is not measured by completed Pluralsight courses - I was created to enjoy life. Imagine if I treated myself the way that I would treat a friend who accomplished a similar amount of work in a day… I would give them a raise! So feel good about yourself, and crack on.

• Losing my why. I forget that I want to become a world class trainer, mentor and coach. BUT: the way that you do that is through mindful practice. I sometime resent “putting in the practice” on my Pluralsight work - since it’s not making immediate money. But then I remember that it’s not, and was never, about the money anyway!! It was about making the world a cooler place - levelling up developers in entertaining ways - and growing in my own potential - and getting better at doing online training!

• No next step. This one is actaully kinda true. I am a little light on the planning stage - and when you don’t have an immediate “next step” to move onto, you can spin the wheels working that out. BUT: I can grow in this area and I have great tools available to me in Kanbanflow or even Trello - so I’m going to develop my next steps as I go. Certainly having no plan doesn’t serve me - so I’m going to create a coarse grain plan and refine as you go. Live the agile dream!

• Not making it fun. First, learn to practice! BUT: the first step there is to make it fun. Give yourself little rewards. Set micro-deadlines that are actually doable - and then hit them and celebrate. No more Herculean epic tasks - those “I’m not allowed to celebrate without doing 40 hours of progress in 6 hours of work” mindsets. That’s ridiculous. And it doesn’t serve you. So leave it behind.

• No room for overflow. When I dive into Pluralsight, all my blogging/vlogging/whatever goes to zero. There’s no overflow to share. BUT: that’s crazy. I’m learning new things every time I sit down to work on the course, so I just need to work out a lightweight way to share those insights. No “massive tome” blog posts. Just punch out a few little sentences to encourage yourself. Or a quick vid to just demonstrate something cool. Or something from your journal. I’m going to commit to a Wednesday blog day.

These last couple of years I’ve been reflecting every day on a Vision Wall that I keep in OneNote. It’s just a page with a bunch of images that remind me of things I’m working to build into my life.

One of the these pictures this year is around innovation.

Innovate. That word used to conjure up “Elon Musk-ish” level innovation. But no more. I now tell a different story about innovation.

My new innovation story is more about friction reduction. And automation.

Removing the Friction

Imagine if you could remove a small percentage of the friction you experience every day delivering software. How great would that feel? Annoying tasks gone forever.

The crazy thing is that automation - using robots to do our boring work - lets us actually do that, but often we put it off since we figure we’re just doing a “one off”. Or it would be too fiddly or time consuming to automate.

Interestingly I used to work with a guy who was completely the other way around. He wouldn’t even copy a file to a floppy without creating a batch file to do it (since he figured he’d be doing it again real soon now).

I think he was onto something.

Wow! We’re into 2018 already and I haven’t blogged for months and months. That’s such a shame because I’ve been doing so much cool stuff. So it’s time to get back on the horse!

New PWA Pluralsight Course in Flight

I’m presently working on new Pluralsight Course related to Progressive Web Apps and Sensor Integration. I’m still scripting but there’s tons of cool stuff in there.

It’s called Sights and Sounds

But not just any travel app. We’ll be developing a lightweight PWA on your handset and:

• Taking photos;
• Recording videos;
• Lauching Notifications;
• Interacting with Fullscreen
• Doing Geo & directions;
• Launching native apps;
• Sensing network access and coping with it
• Doing offline sync magic with Firebase (including image upload)

I am so pumped about it. It’s pretty scratchy at the moment, but it’ll get there:

Discovering Polymer

So what’s really going on with all those dist/*.bundle.js files that Webpack spits out of the Angular CLI generation process?

This video will give you a five minute way to have a look for yourself - and get ideas to shrink your production build sizes. The magic tool you need is Source Map Explorer.

I learned this tip from Jim Cooper’s excellent Pluralsight course on “Angular Best Practices“ and thought it we be good to pass on in a way you can add to your own projects.

First then vid, or read on for the commands I added to package.json.

First we’re going to install Source Map Explorer. I’m going to do things locally, since I like the idea of the project being self contained:

npm install source-map-explorer --save-dev --save-exact

Because source-map-explorer is a lot to type, I’ll create a little alias for it:

"scripts": {
    ...
    "sme": "source-map-explorer"
    ...
}

Now to use Source Map Explorer, you’re clearly going to need some source maps! You generate those by adding --sourcemaps=true to your prod build. To keep things DRY, I like to just decorate the dist target with my own dist-with-maps target. Something like this:

We need to talk about email.

That’s what I wrote in my daily journal.

But really it was more about device checking. Desktop, Handset, whatever.

Constant. Device. Checking.

And I was exhausted. I needed an intervention.

But… I’m a programmer, right?

I get it. You need to be online, right? All the time, right?

I won’t speak for you, but living with this “constant on” mindset was just draining my batteries.

During the day the browser always had an email and twitter tab open.

My phone was always beside me in the evenings, just a quick check every so often for new email, twitter, and newsfeed action. Quick email replies and keep that inbox trimmed.

The last few months have been jam packed full of awesome. Totally living the dream right now.

On the back of my Pluralsight “Building Beautiful Angular Apps with PrimeNG“ course, I landed an awesome consulting gig building a very cool PrimeNG front-end.

The double-cool part of this gig is that the backend is totally asynchronous with lots of concurrent user changes coming over websockets. This was a great chance to apply a lot of the RxJS “Reactive Angular” stuff I’d been learning about over the last few months. That stuff is rocket fuel..

But everything has its limits.

I was soon lost in a maze of Observables and spiraling in a technical debt of state mutation.

Enter ngrx.

If you haven’t bumped into ngrx before, it’s about applying the new hotness of Redux-style applications to Angular, but built on RxJS.

The Benefits of ngrx

How does this ngrx stuff help my async plight?

Phew! It’s been a crazy few months and I have totally been off the blogging and the YouTube horse as I worked hard to get my first Pluralsight course off the ground: “Building Beautiful Angular Applications with PrimeNG”.

The great news is that PluralSight is pulling together the launch video right now - so we’re really, really close!

So what’s next?

That’s an awesome question.

And the answer is… more PrimeNG!

I’m excited to say that I’m currently working on a short-term commercial consulting gig using Angular/PrimeNG - so I’m definitely dog-fooding my enthusiasm for both frameworks.

I’ve decided to move toward online teaching for the next season of my life - but I’ve always felt the best teachers are the ones working in the field, so it’s important to me to keep my hand in professional development work (outside of just “professional training”).

It’s actually been really confronting to sit down and work out a professional growth plan for myself as a programmer. 20 years in, and there’s still so many fundamentals that I get slack about.. (blog posts coming on “leveling up” soon..)

But that’s what’s so great about our profession. There is always a growth goal to stretch toward - or something new to learn - and the disruption never stops!

The time has finally come!

After several weeks of scripting and code samples, the day has finally arrived to click record and get this show on the road. We’ve started recording this:

The good news is that I’m really happy with how this course has shaped up, and I think developers are really going to warm to it.

Inside this course we build a… TADA… Enterprise Timesheeting app called “Agile Times”. This app gives us a great showcase of everything PrimeNG.

We start out with learning about the Prime Grid system to create funky stats components for our Dashboard (thank you Font Awesome), then dive into a world of snazzy charting to get your motivated.

We then cover off all the common form controls people will want to use - all backed by Reactive Angular Forms to keep it real - along with matching DRY/low-ceremony validation techniques!

With some early wins up our sleeve, we dive into filterable, sortable, searchable, paginatable data grids. To make is a bit more real-worldy, but without the overhead of installing 3rd party Dbs, we back our grid with a sizeable IndexedDb (powered by Dexie) to give us that familiar ORM-styling querying that devs will probably be using. Plus we can marvel at Prime’s Lazy Loading magic which keeps it all zippy.

I’m deep into a Pluralsight course on PrimeNG, and have started to cover some of the niceties of PrimeNG charts.

The charting component is a wrapper around Chart.js, and one of the.. um.. interesting parts of the very cool Chart.js is that it has no default slice/bar colours.

Turns out this is a much requested feature and someone on that very thread went to the trouble of putting together a nice set of colours based around Google Charts.

But…

I don’t want to hand-assign the colours each time.

So..

The challenge: Write a function that will take an arbitrarily long pie chart dataset, and assign funky complimentary chart colours to each slice (so that the colour selection wraps around after depleting the set of funky colours).

Here’s my stab. First, setup a constant at the top of your TypeScript controller:

    const DEFAULT_COLORS = ['#3366CC', '#DC3912', '#FF9900', '#109618', '#990099',
    '#3B3EAC', '#0099C6', '#DD4477', '#66AA00', '#B82E2E',
    '#316395', '#994499', '#22AA99', '#AAAA11', '#6633CC',
    '#E67300', '#8B0707', '#329262', '#5574A6', '#3B3EAC']

Then inside the class, setup a routine to map the dataset into our set of default colours for each pie:

As you may know, I’ve been a big fan of PrimeNG for some time (and Primefaces before that!), so I’m super excited to announce that I’ve officially inked the paperwork and started working on a course for Pluralsight around PrimeNG.

I’ve done a bunch of YouTube training videos before, but have always wanted to try my hand at the Pluralsight training thing since I’ve always loved their style.

Pluralsight really do have a super high bar for production quality, so I’m looking forward to stretching out and leveling up my online training skills - which will also benefit my YouTube channel!

I’ve spend today digging into the sample code for the Charting module, where I’ll be teaching charting “from zero to hero” culminating with coding up real-time, mixed style charts like this bad boy:

As a side effect, I know finally understand switchMap() in RxJS! So much winning!

Anyways, can’t wait to get started recording. Will keep you all posted on the progress over the next two months or so.

Just a quick one for those struggling to get the PrimeNG charting components rendering. You might be importing the ChartModule just fine, and even setting up your component tags and data, but all you’re getting in the console is something like:

Error: Error in ./DashboardComponent class DashboardComponent - inline template:22:4 caused by: Chart is not defined

The bit of info you’re missing is that all of the PrimeNG charting components rely on you bundling Chart.js with your application. That’s the JavaScript library that supplies the Chart in Chart is not defined.

The easiest way to do that with Angular CLI is to first install the NPM package with:

npm install chart.js --save

Then bundle the library with your build by editing the angular-cli.json file in your root directory to include it in the scripts array like so:

"scripts": [
    "../node_modules/chart.js/dist/Chart.js"
  ], 

With those in-place, you’ll be ready to Chart up a storm.

Have fun!

I keep solving this problem, so it’s time to write it down for my future self!

I know your story. You want to use jQuery inside an Angular CLI app, but the whole WebPack magic is turning everything bad.

Or perhaps things are even more complex. You want to use a 3rd party product, like Semantic UI, which augments existing jQuery objects in global scope, from your Angular CLI app, and it’s not happening for you.

Your web searches are awash with old advice.

This is the page you have been looking for.

Here’s something that works with 1.0.0-beta.31 of the CLI (and probably earlier WebPack-based versions too).

Watch the vid on YouTube, or scroll down for the steps in text form

First, npm install the libraries you need

In my case, I’m working with Semantic UI. This framework both has CSS and JS component - and depends on jQuery for heavy lifting.

After a day of Observables on Day Two, the final day of the Masterclass was focused around forms and routing.

Here’s my typo-laden gitlog for the day to give you an idea of content pace and the type of exercises we worked on:

Both Kinds of Music: Template and Reactive forms

A good portion of the day was spent working with both Template-Driven and Reactive Forms in Angular - and getting a really good feel for where each of them shine.

I’ve never been much of a fan of Reactive Forms - they seemed like a separation of concerns that I didn’t want to separate - but I have a new respect for them after yesterday (I particularly love the idea of being able to unit test that validation magic in a vanilla unit test).

I now like both approaches - and look forward to road testing both in larger forms apps to give me a real feel for what has the lowest friction.

Here’s the vanity screencast of yesterday’s hacking efforts:

We also wrote our first custom validator - and used it in both Template and Reactive approaches. Validation code is another area where Reactive’s FormBuilder really shines - super straightforward and clear to read afterwards.

Wow. Things just got seriously master-level at the Masterclass! Day Two really did build on Day One, kicking off with the wonders of the Async pipe.

It was actually great to start out with Async Pipe, since it let us convert our little Contacts application to an Observable architecture and ditch all the dodgy *ngIf code and null checking we’d crammed into to play nice with the async http calls.

Getting Serious With Observables

Async was really the theme for the day, and the exercises came steadily throughout the day to make sure we were grabbing the concepts as they were introduced. There’s a lot to love about Observables, but it took the day to really appreciate what they bring to the table.

Here’s my typo-laden gitlog for the day to give you an idea of content pace and the type of exercises we worked on:

Making friends with RxJS - switchMap(), takeUntil(), Oh My!

Christoph and Thomas took us on a tour of the hardcore range of Rx operators that are helpful when working with Observables. Even with marble diagrams, some of these concepts pretty much blew our minds!

Major. Paradigm. Shift.

As a last mic drop before the switchMap() exercise Christoph told us “you’ll work it out” - then pointed it at the lab to learn-by-doing.

Well, yesterday was Day One of the thoughtram Angular Masterclass in Sydney and I’m having a ball and learning heaps.

I thought I’d write up a quick retro to give people an idea of the experience.

On our first day we build a thing! And that thing did CRUDing operations on RESTful service. And did Databinding and all that Angular-ish goodness.

In fact, the first day is called their “Jumpstart” day where you cover all the basics to get everyone on the same page.

This is what I spent the day building:

thoughtram’s Approach

I’ve always been a fan of the “Training from the Back of the Room” approach (actually all of Sharon Bowman’s stuff is awesome), and the thoughtram guys definitely train in that school - 20 minute intense “downloads” of information with Q&A, followed by labs to put it all into practice.

All their training presentation notes are browser-based and accessed by a participant login on their website. The notes are updated for the life of the course (which is awesome!)

Ditto for the lab exercises - which are all hosted on Github repos and constantly updated with tweaks.

I’ve had a cracker this year. It might well have been one of the best years of my life!

Didn’t write a book. Didn’t have a baby. Didn’t ship a world-beating app. Didn’t speak at any big gigs. Didn’t finish a marathon. Didn’t make a ton of money. Or even have something go viral.

Nope. None of those things.

This year I took bold actions toward things that matter to me.

That is all.

And that is more than enough.

Creating Software.

Wrote some great software for clients that makes their lives easier and more productive. Even delivered my own hobby app to make my own life easier.

Creating Video.

I’ve been a huge fan of Nexus for inhouse proxying of Maven artefacts for years. I’ve used it at heaps of government sites where it was a hassle to get internet access through content proxies, and it’s been a life saver. But you might not know that Nexus is also awesome for proxying NPM, Bower and even Docker images.

If you need to configure your local npm to point to Nexus, there’s awesome docs on that.

However, I’ve now started experimenting with yarn, Facebook’s drop in replacement for npm (but quite a bit faster!), and so was naturally wondering how to configure it to use my local Nexus proxy.

Turns out it’s simply a matter of:

yarn config set registry http://localhost:8081/repository/npm-central/

And you’re off and running. I thought I would write it down so I can google it later!

You can confirm that life is great, but tailing your /nexus/log/request.log and watch the traffic flowing (or try a yarn install --verbose and sit back!).

Have fun!

I have to say that Push Notifications are just super cool.

Think how cool would it be to make your Mobile ding with a custom sound every time a really important event happened in one of your systems?

• Just sold another one of your apps? Cash Register Ding.
• Just crashed your production server? Death Spiral ding.
• Just crossed an 100k subs? Happy Sound ding.

Way cooler than SMS :-).

And it turns out adding such features into your app is totally trivial thanks to the good folk at Pushover.net. And today I’m going to show you how!

Enter Pushover

Pushover is a web service (and suite of platform specific mobile apps for Android, IoS and the Browser) that lets you easily push Notifications to all (or one) of your registered devices whenever you would like.

It’s a one-off $5 subscription cost per platform, then you’re free to send up to 7500 notifications month forever. That’s a lot of events!

Integrating with Ionic 2 or Angular 2 (or whatever)