This is a bug I recently encountered with Karma and the Karma Sauce Launcher plugin. It plagued me for a week, finally I worked out the issue and I had to share the solution incase anyone else encountered the same thing.
The issue I encountered was none of the SauceLabs tests would run. It would say it was spinning up a remote browser on SauceLabs, but no proxy was being created and eventually everything would just time out.
Well, this one just stung me and a client after migrating from Bootstrap v3 over to v4 in a project.
In Bootstrap of yesteryear, you overrode colours using separately named variables like $brand-primary if you’re new to v4, you’ll probably try and use variables like these and discover they do nothing.
In Bootstrap v4 colours have been moved into a Sass map. This means separate variables for colours no longer exist. The theme colours are now defined inside of Bootstrap’s variables file here which is a map of colours using similar names from v3.
As a self-taught developer, it’s easy to feel like you missed out on something, and assume your colleagues who did get a degree know more than you. Your colleagues know about algorithms and CS concepts like data structures and you most likely don’t.
Does having a degree or not having a degree even matter? In my experience as a self-taught developer: no.
While having knowledge of algorithms might come in handy once in a blue moon, most of the time you’re just trying to get your CSS and Javascript to work in Chrome, Firefox and Internet Explorer.
I switched to Yarn a while ago, because Npm is incredibly limited. And while I enjoy fast speed on macOs and Linux, Windows has always been a bit slow.
I never actually thought to investigate the issue until one frustrated evening, I had the task manager open and noticed Windows Defender was going crazy when I was doing a yarn install on a pulled down SPA app.
Turns out disabling Windows Defender halved the amount of time it took to not only resolve dependencies but link them from the local cache.
When you think of the new version of Angular, you think of it as Angular 2. Every article you read about the follow-up to Angular 1.x refers to it as Angular 2.0.
Well, this might come as a surprise to some, but the Angular team released their December 12th meeting notes and contained within them, are some interesting tidbits which could have massive consequences.
The Angular team are dropping the version number. From here on in, Angular 2 will be known as Angular. They’re releasing two major versions per year. I believe this was mentioned a while back, but in all honesty, most people probably aren’t aware of the change.
I love Firebase. The power and flexibility of using it alongside my favourite client-side framework Aurelia, unrivalled. Recently whilst building the Built With Aurelia website which uses Firebase, I wanted the ability for logged in users to vote on particular submissions.
My Firebase structure is literally the following:
submissions: { pokegorun: { added: 1470919840796, category: "website" description: "Pokego.run is a Pokemon spotting map where you ..." name: "Pokego.run" repoUrl: "https://github.com/Vheissu/pokego.run-public" url: "https://pokego.run", votes: { TPdM9feOrbgNHVGHebBT7TBZ8Xj1: true } } } My submissions object contains submissions keyed by their name. Then inside some basic object properties for this submission and an object for votes which are keyed by the username (so the same user can’t vote twice).
Let’s cut the crap, as great as Npm is for front-end and Node.js development, it has some pretty glaring issues.
Firstly, code is pulled down without any kind of integrity checks being done, so you could be pulling down anything. Secondly, Npm takes forever to install dependencies (downloading as well as unpacking), it is the bane of my existence. Lastly, Npm has no concept of caching modules.
A lot of the Aurelia projects that I work with all use the same versions and I have a few Aurelia projects I am working on which all re-download the same packages every time I npm install which is painful.
I am all for developers pushing themselves, learning new things and refining their skills, but the one thing that really annoys me about front-end development right at this moment, is the opinion terrorists who are raving about functional programming.
A few examples of the pro functional movement can be seen; here, here, here, here and here is a TypeScript oriented one. There are more out there though.
I am a firm believer in using whatever it takes to get things done. Whether you still use jQuery or you prefer to write things from scratch without libraries or frameworks.
I am not the kind of developer who jumps on bandwagons and uses whatever new tool is released or replaces another. However, after using Aurelia for over a year now and putting up with the numerous breaking changes in Jspm and System.js causing issues with Aurelia, I have had enough.
This will not be a guide telling you how to upgrade to Webpack from Jspm or System.js, just detailing my thoughts around switching over to Webpack and the benefits it brings.
If you are using the TypeScript Skeleton application provided by the Aurelia team, then at the time of writing this, the project is still using TSD (well it has a tsd.d.ts file in the typings folder). The TypeScript Definition Manager as of a few hours ago of writing this post has been deprecated in favour of Typings instead which is a considerably more flexible and easier to use type management tool.