Spoiler alert: CoinMesh is going to be a gamechanger.
When it comes to building decentralised blockchain based applications, admittedly it can get complicated fast. What libraries do you use, how do you safely makes calls to a wallet node and interact with the blockchain itself? This is something that Coinmesh aims to simplify.
Instead of having to worry about what libraries, adapters and tools to use, you get a graphical user experience that allows you to create a starting base for blockchain based applications via a simple UI.
If you are new to Aurelia or perhaps already building something with it, here are some tips and tricks I have learned over the last two years which have helped me write well-performing Aurelia applications.
Keep in mind that Aurelia is like any other framework or library and that it is very easy to write poor performing applications if you’re not careful. Never assume that a framework will stop you from writing bad code.
Let’s acknowledge the elephant in the room, if you’re a reader of my blog then you would know that I am a huge Aurelia fan and user. I’ve been working with Aurelia since February 2015, so 3.5 years now (wow).
I am on the Aurelia core team, I have contributed to the community through plugins/skeletons, answering questions on StackOverflow and I regularly do Aurelia consulting/freelance work (hire me). There is a good chance you’re reading this blog post because you’re familiar with my many previous Aurelia blog posts over the years.
All eyes are on Facebook at the moment as it was revealed that Cambridge Analytica a third-party company exploited loopholes in Facebook’s platform to obtain as much as 87 million Facebook users information through some fake survey application.
While this is a terrifying situation knowing that such a large amount of data was harvested, can we honestly say that we are really surprised something like this has happened?
Facebook isn’t alone It’s easy to blame Facebook, they’re the biggest social network and they know a lot about us, but they’re not the only online company with a trove of information.
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.