Next Level Conspiracy Insanity: Direct Energy Weapons Allegedly Used To Start Australian Bushfires

I love a good conspiracy theory. Some of my favourite conspiracy theories include the Royal Family being shape-shifting lizards, part of some global reptilian elite controlling the world or Alex Jones’ famous rant where he claims the government is putting chemicals into the water turning frogs gay.

The late-2019 Australian bushfires which have burned into 2020 have attracted some crazy individuals claiming all kinds of crazy things. People have lost their lives, thousands of homes destroyed, towns completely wiped, millions of hectares burned, over 1 billion animals estimated to have been killed.

It all started when Barnaby Joyce helped start the rumour that the Greens were responsible for the bushfires by proclaiming they have stopped needed fire-reduction efforts and locked up national parks. In amongst all of this, another conspiracy has been spreading amongst the inner crazy circles of the internet.

Allegedly, some elite secretive entities with an agenda for a high-speed rail line started the fires in the needed areas where the line would go and furthermore, an agenda to force people in regional areas into cities so they can be “more easily controlled”.

I would say you can’t make this stuff up, but here we are talking about it.

One of Australia’s most well-known weather centric Facebook groups Higgins Storm Chasers has also helped spread the rumour to their 10k followers.

This post, in particular, loses credibility almost instantly by claiming that dry lightning is a new and made-up term. Ignoring the fact that dry thunderstorms are well-documented and occurring phenomena that happen in dry areas.

As can be expected, crazy attracts crazy. The comments section, things start to spiral out of control quite quickly. People start sharing images of what they believe to be chemtrails and planes spray chemicals in the sky, presumably to cover bushland in some kind of combustible material.

The thing is, the unprecedented fires we are seeing don’t need anything sprayed in the areas to make the fires spread. The fuel is the incredibly dry bushland catching alight.

Furthermore, there are much better ways to make money than a train line. Look to other established rail lines and services, Amtrak doesn’t turn a profit and it turns out in the UK private railway operators have realised that they’re not profitable either.

Whoever these elite corporate shadow entities are, they have a terrible business sense if they think a high-speed rail line is going to be their ticket to riches. Given the exorbitant cost of constructing such a line, it would take decades for it to earn the money back (if it ever manages to achieve profitability).

These bushfires are being spread by insanely dry conditions, caused by climate change. We need to be smart and plan accordingly for the future because this is just going to keep happening. We can let the crazies play in their little crazy corner on the internet while the sane ones try and come up with solutions to stop these fires from spreading as badly as they have.

What Comes Next After USB-C?

I have the weirdest and sometimes most profound thoughts about the most useless stuff. I actually asked myself this question whilst in the shower this morning: is there going to be a USB-D? Do we need a successor to USB-C or is it good enough for the time being?

When these types of questions pop into my head, I have to Google them. I actually stepped out of the shower and before reaching for a towel, I grabbed my phone and had to find out. With the water dripping onto my phone screen and floor, I set out to find the answer.

Given the iPhone doesn’t even support the USB-C standard yet (opting for its own Lightning Connectorâ„¢) I wonder if it’s due to limitations in the standard or fact Apple doesn’t want to have to change their cables again, after the controversy they generated a few years ago when they did it.

Anyway, back on the topic at hand. In terms of the USB-C specification, it is relatively quite new. It wasn’t published and finalised until August 2014, which isn’t that long ago.

It turns out the answer is not exciting at all, there is no publicly announced successor to the USB-C cable standard. In terms of capabilities, it seems USB-C is capable of supporting quite a high throughput with the recently announced USB 4 standard supporting speeds up to 40gbps (which is super fast) and will require compatible USB-C cables to take advantage of it.

It is naive to assume that USB-C will be as good as it gets. Once upon a time, USB-A and USB-B were probably considered enough and then technology evolved and times changes.

I wonder though, will they call it USB-D or something a little less silly-sounding opting for something like USB-Next or USB-Z?

Are We Finally Getting A New System of A Down Album In 2020?

All signs are pointing to yes. System of A Down frontman Serj posted an image of himself in the studio working on what appears to be music for a System of A Down.

Many might be quick to say this could just be Serj working on more solo material, the hashtags tell a different story at the end, using the band’s name as a hashtag.

For years there has been rumour and speculation a new album is happening. Then various members speaking out about the band’s inability to get on the same page musically, could they have found a way to work past the problems they were happening?

We have all been let down by the possibility of a new SOAD album, only for Serj or someone else in the band to come out and say it is not happening. Time will tell.

Select Change Event Not Firing When Using Characters On Keyboard

Here is a nice bug-not-bug to close out in 2019. One of my Trello cards detailed what sounded like an error:

When toggling between two options (yes and no) in a dropdown, entering “y” changes to yes and quickly entering “n” does not switch to no. However, waiting a second you can change between them.

Some initial debugging suggested this was not actually a bug in our application. But, I knew if I was going to get the ticket closed off as not a bug, I had to have an explanation.

It turns out that browsers (well at least in Chrome and Firefox) select dropdowns are searchable by offering a delay allowing you to type in long values. The way I highlighted this was creating a dropdown with four options:

  • Yes
  • No
  • YNo
  • NYes

To highlight the error I created a JSFiddle demo here. The first dropdown contains the above options. Try pressing “Y” and then “N” quickly after, the selected value will then be “YNo” highlighting the searchability. Similarly, entering “N” followed by “Y” will yield “NYes” selected.

There is also a second dropdown with some years from 1988 to 1993 in the above linked JSFiddle demo. Try selecting the dropdown and then entering 1993 (which is the last option) you will see the searching feature in the browser selects 1993.

So, not a bug, just a browser feature. Admittedly, I didn’t actually know you could search values in a dropdown this way. I usually use my mouse to select values in a dropdown. We have some people on our team who shun the mouse and navigate through our main app using their keyboard.

Google Chrome v79 Broke The Ability To Hover Variables In Developer Tools

Well, this is a pretty frustrating bug. The other day I and a few other people in my team noticed something peculiar while debugging some Javascript. The ability to hover over variables and function arguments in Chrome Developer Tools had stopped working.

At first, we thought this might have been a Webpack configuration issue or an update to one or more of our packages breaking the way in which Chrome parses our Javascript. The issue turned out to be Chrome itself. There is an issue recently created where many voice their frustration (myself included) over this bug.

As a developer, the ability to debug is everything. As a result of this simple bug, the time required to debug has increased exponentially.

Fortunately, this bug appears to have been fixed in Chrome Canary Version 81.0.4001.2. Even many of the developers I know do not use Canary because it can at times be unstable or introduce new features that seemingly get removed. So, until an update is released in the next couple of weeks, frustration will ensue for many.

All of this has just motivated me to consider moving back over to Firefox as my primary browser, given Google’s anti-ad stance and now a bug that should not have been introduced, I am driven by frustration.

Thoughts On Svelte.

The hype surrounding Svelte right now is inescapable. Every blog post comment section, the article comment section on Dev.to or Twitter thread/hot take seems to solicit a response about Svelte.

If you are not familiar, Svelte is a Javascript library which leverages a compiler to turn your Svelte code into plain old Javascript and HTML. You write your applications inside of .svelte files and they get compiled to something that has no runtime.

This puts Svelte into a similar league alongside Elm, Imba and a few others, not directly in line with React or Vue. However, being compared to React or Vue seems to be unavoidable in 2019 and will continue to be the case into 2020 and beyond.

In many ways, Svelte is an indirect competitor to the likes of React and Vue, both options which like to tout their small bundle and application sizes. On that front, they can’t compete with Svelte.

Where Svelte differs from other options like React and Vue is that it does not have a virtual DOM, no runtime or anything else non-standard after it is built. Syntactically, your applications end up looking like old-school AngularJS and Vue syntax and a little sprinkling of React’s JSX syntax thrown in:

<button on:click={handleClick}>

A lot of the examples you will see for Svelte highlighting its simplicity are not indicative of real-world applications. This rings true for many framework and library examples, showing as little code as possible. You don’t want to scare away users.

Where things start to look less HTML and Javascript-y is things like loops or conditional each statements. The following is an example of iterating over an array of users.

<ul>
    {#each users as user}
    <li>{user.id}: {user.name}</li>
    {/each}
</ul>

If you have ever worked with Handlebars templating in Javascript before, then this syntax will take you back to the mid-2000s right away. This is one example of a few other uses which also resemble Handlebars in Svelte.

Syntax aside, it is by no means a large criticism of Svelte. Every framework and library deals with looping over collections differently, except maybe for React and JSX which the community mostly uses a map to loop over items in collections.

In React’s JSX you will find the following approach is the most widely used:

    <ul>
      {users.map((user, index) => {
        return <li key={index}>{user.name}</li>
      })}
    </ul>

I actually would have loved to see Svelte adopt Aurelia’s approach to syntax instead of going down the path of Vue-like syntax and throwing in that Handlebars syntax.

In Svelte binding the value of a text input looks like this:

<input bind:value={name} placeholder="enter your name">

And in Aurelia, binding a text input value looks like this:

<input value.bind="name" placeholder="enter your name">

I realise my Aurelia bias is starting to show here, but in my opinion, I think the Aurelia approach looks a heck of a lot nicer and more JS syntax-like than the Vue bind:value approach. Not having to type a colon is a huge plus and it just looks neater.

Anyway, moving on. We are nitpicking here.

It is Fast.

There is no denying that Svelte is fast. The lack of runtime is the contributing factor here. The closer you are to the bare metal of the browser, the faster things will be.

The truth is, all frameworks and libraries are fast. When it comes to speed and performance, the contributing factor is rarely the framework or library itself, it is the user code.

Start pulling in various Node packages like Moment, adding in features such as validation and routing, and ultimately your bundle size is going to grow significantly. The end result might be the framework or library itself (even those with a runtime) accounts for 10% of your overall application size.

This is why I always tell people to be wary of benchmarks. Sure, benchmarks might look impressive, but they are not indicative of real-world conditions where things like latency, bundle size, what libraries you are using, and how you write your code are really the determining factors.

I think considerations to how a framework or library lets you author components and write code, what its features are, and what it allows you to easily and not easily do are more important than its speed.

To put things into context, there are still many AngularJS 1.x applications out there in production, which are still working fine. I also know of many Durandal, Knockout and Backbone applications still being used which are also working fine.

The generated code I have seen from Svelte applications is surprisingly readable as well. Usually compiled code is not easy to read (for humans) at all, so I was really surprised.

Svelte Exposes The True Complexity of React

For years, React has hidden behind the claim that it is the V in MVC, that it is a simple and a humble view component library. Anyone who has ever worked with React on an actual application will tell you that you never just need the view part.

I cannot recall a time where I have ever built a web application that didn’t have at least:

  • Routing (the ability to define routes to different screens)
  • The need to work with data from an API
  • Form validation (not always, but more often than not)

If you want to add these features into a React app, you have to glue them all together. Because React utilises a Virtual DOM, the ability to just drop in and use any library that touches the DOM is not possible.

The problem with React itself (without turning this into a post bashing React), is that it is too heavily invested into itself. It is also responsible for perpetuating FUD in the front-end ecosystem on quite a few fronts.

React popularising Virtual DOM (and later on, Vue) would result in a lot of FUD around the DOM. When people tell you that the DOM is slow, they’re responding as a result of being programmed by the React community which drunk the “DOM is slow Koolaid” a few years ago.

Svelte has proven that the DOM is not slow. Although to be fair, Aurelia has eschewed the Virtual DOM (in favour of reactive binding) since it launched in 2015 and managed to keep step with other frameworks and libraries for years (upcoming Aurelia 2, even more so).

Now that React has introduced the concept of hooks into their library, it is yet another thing for developers to learn. Solutions like Svelte which do not require you to learn abstractions and ways of authoring applications definitely feel lighter and saner in the face of React.

Cognitively React requires a few React-specific ways of working which just adds to the learning curve. The React of 2019 is not the React of 2014, that is for sure. Authoring applications using Javascript and HTML is kind of refreshing.

Lack of ability to functionally compose views

This is one of those downsides of Svelte that some developers will struggle to look past. It requires you to use script tags and HTML to build your Svelte components. This means you are forced to use its templating syntax like #if, having to use #each for looping.

For developers who have had a taste of “pure components” where all components are written in Javascript, this is going to be a hard pill to swallow.

No TypeScript Support (Yet)

Right now, there is no official support for TypeScript in Svelte. If you are not a TypeScript user or perhaps you work with Vue 2 which admittedly is not much better at supporting TypeScript, then this will not be a dealbreaker for you at all.

If you are like many other developers who realise the future is TypeScript and have switched over, the lack of TS support is going to be a dealbreaker for you. Some developers have gotten it to work sort of using hacks, but not ideal support by any means.

Conclusion

I think what Svelte has brought to the table is going to kickstart some innovation and competition in the front-end space. While React has been trudging along for quite a few years now and Vue picking up popularity as well, it’s nice to see some new thinking that doesn’t revolve around a Virtual DOM or leaky abstraction.

Rest assured, you best believe that other frameworks and libraries are not going to sit idle while Svelte comes in and pulls the table cloth right off the dinner table.

The AOT compiler coming in Aurelia 2, for example, is going to optimise your Aurelia applications to a high degree stripping away runtime and unneeded code. Angular has been focusing their efforts on improved AOT compilation with the Ivy compiler and renderer and other options are also focusing their efforts on the compilation as well.

Even after playing around with Svelete just briefly, the lack of resulting code and marketing spin was refreshing to see after years of other players in the industry seemingly perpetuating immense amounts of hype.

Having said that, the safety and stability that I get using a featured framework (in my case, Aurelia) still feels too hard to beat.

I think Svelte is definitely going to get more popular and for non-complex UI’s it would be a great choice over React or Vue, but I still have hope that one day that Web Components becomes the norm and we see light abstractions on-top of WC that just compile to Web Components behind the scenes.

I would love to see how Svelte scales in a large-scale web application. Not specifically in performance (because I think it would remain fast), but rather code organisation, maintainability, testability and how easy it is to bring new team members up to scratch with an existing codebase.

Massive kudos to Rich Harris and everyone else who has worked on Svelte. I can definitely see the hype around Svelte is more than warranted and in the end, competition is healthy. We need fresh thinking and solutions to help drive standards and the ecosystem forward as a whole.

Using Wallaby.js With Aurelia, Jest and TypeScript

Wallaby.js is one of the most amazing additions you can make to your testing workflow. I have been a happily paid user for a couple of years now and if you are looking to up your testing game, I highly recommend it.

Chances are if you are reading this post, you already use Wallaby and you are looking to get it working in your Aurelia applications with Jest and TypeScript. It’s a combination that is not all too uncommon these days, TypeScript is the future.

The Wallaby.js configuration itself requires very little code to work out-of-the-box with Aurelia and Jest.

module.exports = function (wallaby) {

  return {
    files: [
      '!**/*.css',
      'src/**/*.ts',
      'src/**/*.html',
      'test/unit/helpers.ts',
      'test/unit/mock-data/**/*.ts',
      'test/unit/stubs/**/*.ts',
      'aurelia_project/environments/**/*.ts',
      'test/jest.setup.ts',
      'tsconfig.json'
    ],

    tests: [
      'test/unit/**/*.spec.ts'
    ],

    compilers: {
      '**/*.ts': wallaby.compilers.typeScript({ module: 'commonjs' })
    },

    env: {
      runner: 'node', 
      type: 'node'
    },

    testFramework: 'jest',

    debug: true
  };
};

The above configuration assumes your files live in src and in my case, inside of my test/unit directory I have a helpers.ts file which has some functions making testing easier, a mock-data directory for mock data to import, a stubs directory for stubbing out certain mocks as well as my main Jest configuration file jest.setup.ts.

Do not copy the above file line-for-line. Make sure it reflects your project and the files inside of it.

In the compilers section we have to tell Wallaby to compile our TypeScript to commonjs format. In my case, I was originally targeting esnext as my module format and Wallaby does not work with modern JS syntax just yet. the rest is fairly explanatory.

Here is what Wallaby looks like running in an application I am currently working on.

My Experiences One Year (and counting) Working From Home

A little over a year ago I took a new job and because the office is close to an hour and a half away, I wanted to work remotely for most of the week. Commuting upwards of three hours a day five times a week would have destroyed me.

So, while I don’t work 100% of the week remotely, I work two days in the office and three days at home. Everyone has their own experiences working remotely, and I thought it would be interesting to share my perspective and experience.

Oh, and for context, I have a four-year-old son and a six-month-old daughter. My son goes to daycare three days per week, and there is some overlap with the days I work from home, my wife is a stay at home mother and also currently studying as well.

You need a dedicated space

You need a consistent working space. Working from home if you love what you do, it’s not hard to be disciplined, if anything, it is difficult to stop working once you start (more on that later). I often hear people remark when I tell them I work from home they would find it hard not to watch Netflix or slack off.

Working remotely while more relaxed, you should still act like you’re in an office. Get yourself set up with an office or corner of a quiet room, buy a comfortable chair and a sturdy desk.

Noise cancelling earphones are a must

If you work from home and you cannot guarantee that you will only ever be there alone in business hours, get yourself some noise-cancelling earphones. For me, it’s a crying baby and an energetic four-year-old running around the house, the TV going or music.

It’s not fair to expect everyone else to change their routine or how they go about their day for the sake of making it work office like for me at home. Also, if you live near a busy street, you’ll have outside noise like cars and motorbikes.

At present, I have to deal with a loud street sweeper making hourly trips up and down my street. This is because of some development work happening at the end of the road.

It can be harder to stop working

Some people have laughed when I tell them that working from home makes it harder for me to stop. With no commute to and from the office, I find I start earlier and finish later quite often because being in the comfort of your own home can be deceiving.

For me, this is really the only downside. Fortunately, my wife is great at making sure I finish at 5 pm a lot of the time, mainly because I help with the night time routine and I can help free her hands up to do other things not related to the kids.

Slack makes the distance more comfortable to manage, mostly

For some, the lack of office co-workers is a dealbreaker for them. And admittedly, at times not having a co-worker to bounce an idea off of or head out to lunch with can be a bit of a drag at times.

For those times, when I need to speak to someone, they’re only a Slack message or video call away. Because I live in Australia, and we have embarrassingly slow internet (my connection is decent compared to the average), sometimes there are technical difficulties getting on a video call because our main office can’t get a proper connection in the area yet (despite the fact it ironically is one of the first places in Australia to have 5G rolled out).

I highly recommend if you’re working remotely to install the Visual Studio Code LiveShare extension, it allows remote coding sessions (including the ability to share a terminal), so you can do remote pair programming and troubleshooting as well.

You save a lot of money

By cutting my commute time 80%, we are refuelling our car a lot less (once every 1.5 weeks). What felt like twice-yearly car services, has now become just the one annual service. We are putting fewer kilometres on the odometer, which is a considerable saving. Special shout out to the environment, I’m reducing my carbon footprint in the process.

And then you have the saved money on coffee and food. When I used to work in an office, I would eat out more often than I care to admit. This is usually how you bond and socialise with your colleagues, over a nice takeout lunch. My wife is the queen of food preparation, so we always have a good selection of lunches to pull out of the freezer for lunch.

Then you have the big wallet drainer, the big “C” coffee. I am not sure how much a cup of coffee costs where you are, but where I live it’s on average AUD $5, which is about USD $3.40. It adds up really quick when you can drink upwards of four coffees per day (especially during meetings).

At home, we invested in a coffee machine, and if you work remote and love coffee, I highly recommend splurging on a coffee machine and some quality beans of your choosing. The cost per cup is so low, the only dangerous thing you need to watch out for is drinking too much coffee.

The savings don’t stop there. Because I work from home, at tax time, I am allowed to claim some costs as work-related expenses. I can claim part of my internet bill, cost of buying stationery and other things your accountant can help you out with. Getting some money back from the government is always a good thing.

So, while I am probably spending more on AC during the summer months, using my electricity and water, it still works out cheaper than a commute to an office and eating out. Winning.

Increased productivity

Working from home makes you so much more productive if you can trust yourself to be disciplined and not sit on YouTube all day long. Working in a traditional office is full of interruptions, detrimental to productivity. There is nothing worse than getting in the zone and having someone tap you on the shoulder, or meetings that run overtime.

When someone wants to ask a question, they have to Slack me, and if I am set to busy aka do not disturb, I won’t even see the message until I check. I get to reply on my own terms.

You get sick less

If you have worked in open space offices (or any office), you will be familiar with office plagues. There is always that one or more persons who come into work sick (like it’s a badge of honour) and spread their sickness around like Germaclaus (an ill version of Santa that spreads sickness).

I have only been sick once this past year and like I said in the opening of this post, I have a son who goes to kindergarten three days per week. The fact I get sick less with a child in kindy than I do working in an office, it says a lot.

Last, but, not least…

I get to work in my pyjamas. On those three days, I am at home, I get into the shower and then put on some comfortable pants and a shirt. There is nothing like working in whatever you want to wear.

When I am in the office, I have to put on an ironed collared shirt and chino pants with a belt, but at home, I am one step away from being ready for bed.

GitKraken “Could not find a compatible repository” Error Fix

I recently encountered an error in GitKraken after a bad merge occurred when trying to merge in some changes from the main development branch, whilst I had quite a few local changes that GitKraken usually automatically stashes for me.

My problem was I was using Bash Ubuntu on Windows, which has a nasty habit of locking files. The merge and stashing seemed to fail because in the changes I was attempting to merge in, some files were deleted.
I tried closing and reopening GitKraken, but it was clear that GitKraken wasn’t going to let me open up that repo again.

The fix

I realise this is a bit of a nuclear fix, but you’ll need to open up PowerShell to fix this. For me, it was simply a matter of navigating to the project directory and running: git reset --hard however, if you need changes, your repo will be interactable just fine on the command line.

As far as I could see with everything I tried, GitKraken won’t ever fix itself, the command line is the only solution. The above, once I ran it and opened up GitKraken it worked just fine again as nothing had happened.

The Ultimate Programmer Super Stack

I generally avoid promoting things on my blog, but this month I am a part of the Infostack Ultimate Programmer Super Stack, my Aurelia book is a part of this fantastic bundle.

For $47.95 you get my Aurelia For Real World Web Applications book, as well as a few other programming books and courses. A whole wide variety of topics are covered, and if you’re like me, you lap these kinds of bundles up because you’re always hungry to learn something new.

The Ultimate Programmer Super Stack is a hand-curated collection of 25+ premium courses, bestselling ebooks, and bonus resources that will help new programmers as well as experienced ones.

One of my favourite additions to this bundle is the book Build APIs You Won’t Hate by Phil Sturgeon, which is a book I highly recommend every developer reads before they attempt to build an API. Because let’s be honest, API’s are complicated things to build and design right.

This is a time-limited bundle, so don’t sit on the fence for too long.

Grab the bundle here.