Elon Musk has not made it a secret that he is against the idea of artificial intelligence, and believes that it poses a great threat to the world.
Recently at South by Southwest or SXSW as the cool kids pronounce it, Elon put forth his plan for the second coming of the Dark Ages by saying, “AI scares the hell out of him”.
“This is a case where you have a very serious danger to the public, therefore there needs to be a public body that has insight and then oversight to confirm that everyone is developing AI safely — this is extremely important,”
As many of you know, I love working with Aurelia and I love working with Firebase. I have been combining both of these together to create personal projects for a while now.
Newly introduced server-side rendering also strengthens my toolbelt with the ability to quickly spin up new Aurelia applications without having to worry about configuration and tooling.
This is why I have open sourced my Aurelia Firebase SSR Skeleton on Github. A starter for creating Aurelia applications, think of it as being similar to the skeleton applications Aurelia currently offers, but more up-to-date and easier to work with.
One of my favourite Aurelia changes isn’t a new feature, nor is it a long-awaited bug fix or new tool: it’s the fact the CLI now supports Webpack by default.
Why is this a big deal? Previously, the CLI took a RequireJS first approach to bootstrapping new applications, meaning if you didn’t choose to customise your au new generated application, you would get RequireJS as your default bundler.
Now, there isn’t anything wrong with RequireJS as a bundler, but the issue with RequireJS is given its age there are issues dealing with different file formats, especially styles and static assets like images and fonts (which it cannot handle).
Now that Webpack 4 is out, it supports a plethora of new things and features, one of those is the native handling of JSON. In theory, this is great, but in a particular application I am working with which is JSON heavy, the native JSON loading caused a trove of errors.
Obligatory photo of some code
Fortunately, inside of your module.rules section of webpack.config.js you can disable the native JSON loader and use the json-loader package which seems to be more reliable at present.
I have migrated over to Webpack 4 for Built With Aurelia and I am using the fantastic Aurelia Store plugin.
During development, everything worked fine, but when I would do a production build the state management aspect would fall apart, complaining about something to do with the function that notifies Redux Dev Tools about the change (what the action name and state value was).
It took a lot of trial and error (a solid day) for me to work out what was going on.
I have been asked this question a few times and it can be hard to see things from the perspective of a newcomer to Aurelia, given how long I have been working with it. What is obvious to me is not obvious to everyone else.
When you’re deciding to build an Aurelia application, you’ll discover there is a CLI tool called Aurelia CLI and on Github, a collection of different skeleton applications for building an Aurelia application (preconfigured with testing, some routes and other logic).
The answer to this isn’t scientific, you should choose the CLI. The skeletons are representative of a time when Aurelia didn’t have a CLI, when it was still in alpha, beta and release candidate stages.
Recently whilst I was attempting to port over a TypeScript/Webpack based Aurelia application to work with Aurelia’s newly released server-side rendering functionality, I encountered an annoying error with Firebase Firebase App named '[DEFAULT]' already exists.
Previously, my code looked like this:
import * as firebase from 'firebase'; const config = { apiKey: "", authDomain: "", databaseURL: "", projectId: "", storageBucket: "", messagingSenderId: "" }; export default firebase.initializeApp(config); Because of the way server-side rendering works, it meant that Firebase was being spun up multiple times in my app. This previously wasn’t a problem because of one codebase. To fix it, you just need to alter your default export a little bit.
For years, I have greatly undervalued my own time as a developer. In the beginning, I did not want to set my hourly rate too high because I did not have much consulting/freelancing experience. I wanted the work (chicken and egg problem) but lacked the experience.
As a freelancer, it can be hard to figure out your hourly rate. If you are new to freelancing or not sure what you are worth, you will probably settle on a fairly low rate. You might actually look around and see what other people are charging, which can be a mistake.
When you are building an Aurelia plugin and you want to test it, you will want to use npm link or yarn link to create a local symbolic link to your module and then use it in a test application.
If you are working with Aurelia and Webpack, then you’ve probably run into an issue with linked Node modules can’t resolve files correctly. You might have some code in your plugin that looks like this in an index.js / index.ts.
Towards the early part of 2017, I embarked on creating a bunch of quick single-purpose web applications to keep myself busy and sharp. One of those apps was a temporary file storage web application called Tempfile.cloud.
The premise was simple: you get 1gb of free upload space and your files have an expiry of 24 hours.
I threw some advertisements on there and then shared it around. Surprisingly, it got some traffic. Turns out file sharing sites not covered in malware-laced banner ads/widgets, require you to signup and have no Russian tracking scripts resonate.