Firebase Cloud Functions are fantastic, but the URL that you get to run them isn’t so nice. You’ll get given a URL that looks like the following when you create some cloud functions:
https://us-central1-demoapp.cloudfunctions.net/functionName If you are wanting to use Firebase to build an API for your application for example (like I wanted to), then you would probably prefer your URL looks like this:
https://myapp.com/functionName Fortunately, you can. The only downside is you have to use Firebase hosting if you want to be able to alias your functions to your name. If you’re self-hosting your own site somewhere else and using Firebase, then you can’t alias cloud functions.
As a developer, I love Github and use it to not only contain my public and private development projects, but also follow other interesting projects. Sometimes I’ll fork a project if I want to contribute to it or star a repository if I am interested in using it now or later.
I joined Github on August 18, 2010 so I have been an active member of Github for seven years now.
If you’re using the fantastic Ubuntu Bash terminal in Windows 10 which gives you a proper Ubuntu Linux terminal window and subsystem, you’re probably wanting to access files on your main drive.
To get to your C drive which has your files, you can just type:
cd /mnt/c I don’t know about you, but typing that is painful. By creating an alias in your .bashrc file which is a configuration file for the Ubuntu terminal instance, you can create a shortcut to the C drive (and other mounted drives as well).
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.
The hardest part about blogging is thinking of what you should say. For me, this blog has become focused heavily on Aurelia and Javascript, blogging about other things occasionally. I tend to stick within the front-end development niche.
When it comes to blog post ideas, believe it or not: Stack Overflow has been a very influential part of my writing. I’ve written blog posts that were inspired by problems with cool solutions or niche features in a framework not many are aware of.
Aurelia supports the element provided via the HTML Web Components specification, which allows you to define placeholders in your HTML that can be replaced.
A lot of examples around seem to wrap a slot with a DIV, perhaps a class. The issue with this approach is if you have a styled DIV wrapping a slot and that slot is empty, your DIV will still be affecting the space around it. This is where the ability to check if a user has provided a slot or not helps.
Recently in an Aurelia project, I was working with nested repeaters (3 levels deep). The problem was I needed to get the $index from the top level repeater (so, level one). Instinctively, I presumed that you could do this:
$parent.$parent.$parent.$index This does not work. The $parent variable only extends to the parent and cannot be chained.
I asked in the Aurelia team chat if anyone had a solution and thankfully core Aurelia developer Ashley Grant chimed in with a great solution that he learned from one of Rob’s intermediate training videos, that I had to share.
In your Aurelia applications, you might have two or more roots defining different entry points into your application. I personally create a public facing root which has public routes and an auth protected shell which has routes for logged in users only.
Let’s say for this example you have two roots: publicRoot and privateRoot. Your publicRoot view-model has your login/logout and other public routes, and your privateRoot view-model has routes for an administration panel.
Introduced in TypeScript 2.4 is support for the ECMAScript dynamic imports feature. If you didn’t see the announcement or read it properly, you’re probably here because you’re getting the following error.
In my case I use Webpack and I was trying to add in some dynamic import goodness and getting this error: Dynamic import cannot be used when targeting ECMAScript 2015 modules.
You’re probably thinking, this is crazy considering dynamic imports are an ECMAScript feature, not a TypeScript one. The tell is in the error, if your module is set to es2015 you’re targeting ES6 and dynamic imports are a feature not due for release until ECMAScript 2018.
Admittedly, Google’s developer event IO has grown to be quite interesting the last couple of years. This year (2017) I was excited to see what would be announced in the world of Firebase.
I’ve been using Firebase on and off for the last couple of years. Recently, I’ve found a renewed sense of excitement in using Firebase again (especially after cloud functions were released).
A few of the new features are more mobile-oriented, Firebase likes to focus on mobile developers and applications but it has value for all platforms.