Of late, I’ve been updating my JavaScript knowledge and thought I’d share some tidbits and goody gumdrops. Here we go.

If you’re already knee-deep in ES6, this article is not for you. If you’re already proficient in JavaScript and are wondering what the ES6 fuss is about, this article is definitely for you :)

What frickin’ ES6??

ES6, ECMAScript 6, ES2015, ECMAScript 2015.. I’m sure you’ve already heard these terms being whipped around or seen them in job ads of companies that want to seem “disruptive”. Well, maybe not, but regardless, those terms are confusing at best.

So yeah, JavaScript is steadily evolving just like everything else. The confusing bit is that the naming conventions have changed of late. Read on.

Why do I care about ES6?

Well, you care because some guys are hard at work to make your Javascript development work more productive, your code more intuitive, manageable and readable, reducing headache and making you look cooler to your boss and your clients. Why not reap the benefits? Look at these features to get an idea.

New stuff is being added to JavaScript continuously by a group called ECMA using an approval process for each feature. That’s where the name ECMAScript comes from.

Guys from Google, Microsoft, Apple and the Mozilla foundation read the ECMA’s memos and debate about what cool things Chrome, IE, Firefox and Safari should support next. I’m suspecting that from their perspective, they‘re asking questions like “will consumers increase their preference for our browser over others, thus exposing them to our mind control techniques through an enhanced, personalised browsing experience if we support [cool functionality]?”. From my perspective, I don’t know about you but I just wanna work less and more effective :)

Weird naming conventions of ECMA and some history

As an example, ES6 is also called these things, and all of them mean the exact same thing:

• ECMAScript 6
• ECMAScript 2015
• ES2015

This will hopefully become more consistent in the future. Here’s a short history of the ECMA standards evolution so far. Not that anyone gives a hoot :) Anyway, on to the cool stuff: transpiling and the arrow function.

Transpiling with Babel

Now that you know browser support for bleeding edge JS stuff is inconsistent, but you’ve seen a cool ES6 feature you want to use, you might be frustrated because browsers haven’t kept up with the cool kids? Not to worry, Babel’s got your back.

Eventually all browsers end up supporting all the features introduced in new ECMAScript standards, but in the meantime you can get away with using these new functions by something called transpiling. Not to ne confused with compiling. Whereas compiling takes your code and creates something entirely different and unrecognizable (usually to binary from text), transpiling takes your code and translates it to a different dialect of that same language. Anyway, what you need to know is that

the current thingamajingy capable of transpiling bleeding edge to browser-supported Javascript is Babel.

Just go and test the playground and see for yourself what coolness you can get browsers to support with Babel. Then, read the setup section of the docs and discover that Babel is supported by a thousand build systems and frameworks such as Gulp, Grunt or Webpack.

Noteworthy about Babel is also that it translates something called JSX into Javascript as well. Outside the scope of this article, but read about JSX here.

ES6 by example: Arrow function and no prototype

Okay, so ES6 has way more features than this one below, but I’m hoping that as one example of many, you can get an idea of the difference ES6 makes.

There are two benefits to arrow functions.
First, they are less verbose than traditional function expressions.

Compare the two versions below:

Second, they pick up their “this” from their surroundings. Looking at this example from Exploring ES6 by Axel Rauschmayer. Not just using arrow function to simplify things, but you don’t even need to use prototype anymore.

See below:

Well, that’s it for me. Hopefully this post made ES6 less intimidating.

What cool new features have you discovered in ES6? Let me know in the comments.

Bleedin’ edge JavaScript: ES6/ES2015, transpiling and an arrow function example was originally published in Full stack development on Medium, where people are continuing the conversation by highlighting and responding to this story.

Okay.. BitBucket isn’t a cure for cancer. But it does offer a few nice hidden perks that are easy to set up and increase your productivity. Here they are.

NOTE: if you’re a swashbuckling BitBucketer that has done everything already, you probably know most, if not all, of this stuff. So, TL;DR: I’m touching on Pipelines, HipChat / SourceTree integrations, branch permissions and account-wide code search.

What frickin’ BitBucket?

An intro of BB for newcomers. Hint: nothing to do with Dwight and his beets as stated above. You might have heard of Git, GitHub, Subversion or code versioning before? This is up that same alley.

BitBucket helps you to store your code, and any version of your code that you’ve deemed worthy of saving. It also lets you share your code with others, and lets you control how others can contribute to your code, with any amount of approval bureaucracy that you may deem necessary.

It’s all about “your code” becoming shared code, but just how that happens is controlled by you. There are various workflows that have become a way of working amongst the community, although today, modern DevOps practices have begun to re-encourage an alternative, simplified approach that has been around for years. These workflows, their pros and cons and alternatives are subject to a fair bit of debate, which I won’t go into right now. If you’re up for it, grab some popcorn and read the comments thread at the bottom of this article or this Stack post, for example.

BitBucket supports both Git and Mercurial source control systems, and packs a ton of features, a few of which I’m about to reveal to you, free of charge :) Speaking of free, BitBucket is free (for smaller teams).

Looking at the fancy bagel below, BitBucket fits into a whole family of product development, task management, wiki, Continuous Integration and similar tools from the company Atlassian, hailing from Sydney. Go Aussies!

Feature 1: Pipelines

If you know GitHub’s Travis, then I can tell you that Pipelines are BitBucket’s answer to Travis. If you don’t know Travis, then just ask yourself this:

As a developer, if I had BitBucket grant one wish for me, what would it be?

At the top of my list is definitely “help to roll my code straight onto a staging and production server, just by me pushing it to a certain branch”. Right? Well, BitBucket Pipelines supports exactly that. The cool thing about it is that it’s integrated straight into your repository. All you need to do to activate this feature is to set up a bitbucket-pipelines.yml file in the root of your repository. Here’s a simple starter.

You can use BitBucket’s config validator to make sure it’s alright (YML files are crazy about whitespace). Here’s a simple example of a config file:

So, in the above file, “dep deploy” would point to a PHP Deployer script which has further instructions on what to do within the Docker container.

NOTE: To complete the release process and get Continuous Delivery going, you will also need to set up a deployment server, choose or create a Docker container for your server environment and set a deployment script using a framework such as PHP Deployer, topics which are beyond the scope of this post. Maybe I’ll post an article dedicated to that later in the year.

Anyway, sailing on to the next productivity tips: HipChat and SourceTree integration.

Feature 2: get BitBucket notifications into your HipChat rooms

If you’re a true Atlassianite and therefore are pro- stuff like this, you’ll probably already be hip to HipChat. Or Slack for that matter, this works for both. It’s just a tad easier for HipChat since BitBucket has native support, so you can just tick a few boxes and you’re done.

Go to your BitBucket repo Settings, choose HipChat Integration. If you’re logged into your HipChat account, you’ll get a list of rooms to pick from. Choose your room and tick some boxes on what’s notification worthy as shown in the choices below. No more flooding your emails, having to go peek in your repo or do git fetches to check whether that commit you’re waiting for your colleague in another country to finish has been pushed or not.. you’ll get pinged the second the code arrives in the repo.

Feature 3: see your pipeline progress in SourceTree

Again, if you’re an Atlassianite, you’re already using SourceTree. It’s hard to live without it once you, er.. git going :) It’s 100% free and works on both OS X and Windows, so download that thing and try it for yourself already!

The intricacies of using SourceTree warrant a separate post, so I won’t go into that much detail. What I want to point out is a really nice feature in SourceTree: you can see the progress of your currently running pipeline (Feature #1 in this article) right in your SourceTree branch view. How neat is that?

Feature 4: branch permissions

Have you ever had a team that’s dispersed over a large geographic area, and has had different levels of authority over code? I have.

Like, some devs shouldn’t be allowed to push stuff in the master branch, which would initiate a deployment into the production server, and some devs should. Some devs should have the authority to delete branches, some not. Enter branch permissions: it allows you to define each and every user’s access per branch, just how you want it. Read more about BitBucket’s branch permissions here.

Feature 5: account-wide code search

This thing is a beauty, especially if you’ve already been on BitBucket for a long time and have like 300 repos on your account.. You can search for a snippet of code within all those repos from one location! It’s hard to explain how awesome this is, you just need to try it for yourself. Just type in a search string on the Code Search page and BitBucket (after it has indexed all code in every repo on your account) will go scouring your repos for occurrences of that string. I know, sounds trivial, but it’s pretty sweet to find that snippet of code you needed, in some project you didn’t even remember existed.

From the search documentation page, it’s clear that you can choose an account as the search scope, which is what I’ve done in the below screenshot. I looked for a string and it went off on a quest to find it within all the repositories it had previously indexed and peppered up for an account-wide search.

Well, have fun and may you be more productive with these little tips.
Share with your fellow BitBucketeers!

Make BitBucket work harder for you in 2018: five productivity boosters was originally published in Full stack development on Medium, where people are continuing the conversation by highlighting and responding to this story.

If you’re a front end or full stack developer, you’ve surely come across this question: what Javascript framework would you go with if you had to pick one to build a JS application? There are many at first glance, but four of them stand out at the moment.

I’m not going to repeat what has been said in the excellent articles by Jens Neuhaus in his Angular vs. React vs. Vue comparison article, or the equally informative Mithril.js vs. React vs. Vue vs. Angular comparison on Mithril’s own site. Both of them go deep into history, file size, performance, documentation and other aspects of each framework in detail. The only copy/paste I’d add from that article here is the list of questions Jens summarises. It does highlight most of the important things:

How mature are the frameworks / libraries?
Are the frameworks likely to be around for a while?
How extensive and helpful are their corresponding communities?
How easy is it to find developers for each of the frameworks?
What are the basic programming concepts of the frameworks?
How easy is it to use the frameworks for small or large applications?
What does the learning curve look like for each framework?
What kind of performance can you expect from the frameworks?
Where can you have a closer look under the hood?
How can you start developing with the chosen framework?

I’d rather attempt to complement these articles by highlighting a few aspects that I saw in the comments below those articles as well as something that I saw missing in both of them:

1. What are the Github stats of each framework as of January 2018?
2. Can my JS compile into a native mobile app? (spoiler: YES!)

Github stats of React, Angular ,Vue.js and Mithril.js

Here they are, as of 28th January:

Stars show general appreciation, forks show involvement, watch shows interest.

So, at the time of this writing, in terms of GitHub love, React and Vue are en par, Angular is falling behind, and Mithril.js is still up and coming. Whatever. This is just one way to look at it, and probably will change throughout

Anyway, let’s look at the second question.

Can my JS compile into a native mobile app?

Short answer: yes, if you’re on React, Angular or Vue. If you’re on Mithril.js, good luck my friend, I have no idea :D keep an eye out.

Long answer: To clarify, there are are currently four ways to create a native mobile application for Android and iOS, in chronological order:

• Many years back, there was only one way: a truly native app. Java for Android and Objective-C/Swift for iOS. Developers, for various reasons, legacy being one, still take this approach to date. It’s an established practice, so why not? Well, today developers have made a web app and would like to benefit from that time investment in the mobile device world as well, recycling all that code somehow. Along came hybrid apps.
• As the next alternative, frameworks like the Ionic framework would create an app wrapper with a browser window and encapsulate your web app. This being a hybrid app, a combination of a web application and a nativer app. Ionic and its buddies are still around. However, recently (within the past 2 years) an even cooler way was born: compiled apps.
• Today, with the help of tools such as NativeScript and React Native, JS apps get a few added components and compile straight into native mobile apps. Hence the name compiled app. Or whatever you want to call it. The main point is that a significant amount of Javascript business logic and functionality code can be directly recycled, and still benefit from the native performance and components of mobile devices.
• In the background, workbenches like Unity can spit out mobile applications. Ignore that approach for now, that’s a whole separate article, and surely Medium will have what you need if Unity’s your bag.

All of these approaches have their pros and cons. To get an understanding of them, watch Academind’s highly informative video and thorough comparison of ways to create native mobile apps.

Now, the tools. NativeScript and React Native do pretty much the same thing. They take Javascript and compile it into a native mobile app. It’s up to you to decide which one of those two to use, really. If you’ve got existing React, Angular or Just make sure you try both Expo for React Native and NativeScript Playground.

Expo for React Native

React Native is a no-brainer especially if you’re already down the React path. Expo is a natural next step in that evolution. You can read Jani Eväkallio’s plug on React Native and Expo and then, head on down to the Expo test area and have a go. It’s a pretty fun place to be.

Playground for Nativescript

Originally, NativeScript made it easy for JavaScript developers to create mobile apps for both platforms, from one JavaScript codebase, using standard components. That codebase was then compiled into actual native app packages that could be released in the App Store and Google Play. As time went by, it also started supporting Angular code, so Angular code could be recycled. Today, it supports NativeScript, Javascript, Angular and (experimentally) Vue.js. I warmly recommend to check out the NativeScript Playground, it’s pretty awesome to see the native app update immediately on publishing the Javascript you write into the Playground window.

Anyway, happy trails with Expo or Playground. I hope this article increases awareness to your evaluation of JS frameworks: keep an eye out for GitHub love, and check out native mobile app possibilities of each framework.

Vue.js, Angular, React, Mithril.js.. GitHub love and Native Mobile Apps was originally published in Full stack development on Medium, where people are continuing the conversation by highlighting and responding to this story.

For those getting into AWS CloudWatch dashboards, I thought I’d share a few productivity tips on changing to your local timezone, using reference lines and comparing averages to peaks.

Tip 1: yes, you can get metrics using your timezone

Is this a relief or what! I spent too much time calculating what my time is compared to UTC so I could figure out when my latency peak is, until I found this little jewel at the top of the dashboard, in time selection. It’s not so easy to spot so here it is:

Tip 2: Put some reference (annotation) lines in there

Metrics in your charts change over time, so it’s helpful to set a few reference lines. AWS calls them annotations. You can set them in the Graph Options tab in the metric edit view.

You can choose the value, which axis to put them on, and whether to fill the graph above or below the reference line.

Very helpful when looking at a high-level view of several metrics on a page: is this thing over or under what I consider acceptable?

Tip 3: Look at peaks instead of averages

By default, the metrics you create in the AWS CloudWatch dashboards are averages. This is good information, but what if you need to identify peaks, for example CPU peak times? They don’t show up in the averages at all. Consider this visualisation:

In this graph, four things are displayed: The Latency Peaks for all three servers, as well as the average latency per server. As you can see (or can hardly see, by the looks of it), average latency is extremely low, sub-second low actually, whereas the servers do have occasional latency peaks, even up to 24 seconds at times! Huge difference, yeah?

So, it’s important to look at both averages, but also consider peaks. Combined with tip #1, you’ll know exactly at what time your peas occur. That’s useful information for example for CPU, disk throughput or in the above case, latency metrics.

This is how the above graph is set up. It’s measuring the latency metric for an Elastic Load Balancer:

Anyway, that’s all the AWS CloudWatch tips for today. Thanks for the read, please share with your AWS friends!

A few AWS CloudWatch tips was originally published in Full stack development on Medium, where people are continuing the conversation by highlighting and responding to this story.

Just a handy money-saving tip here.

Ever had a mysterious problem on your Linux server where you’re getting “disk space full” but don’t seem to have maxed out your disk space? Do you have a bunch of small files on your drive? You may be maxing out your iNode usage.

This maxing out is a question of quantity, rather than size. There is an iNode allocated to each file in the Linux filesystem, so if you’ve got a very large number of small files (we’re talking hundreds of thousands or more), the iNode allocation will start to suffer. Obviously one solution is to increase your volume size, but before you dish out those $$, consider that you may just need to remove some 100,000 redundant files and you won’t need to invest more money into a bigger volume.

When you’re checking your disk, use df -ih instead of df -h.

I discovered that iNodes, not disk space, were actually the reason my disk was full.

/$ df -ih

Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/xvda1 512K 512K 0 100% /

When iNode usage is 100%, the amount of options to investigate this are slightly limited as the server considers disk space completely unavailable. You can’t apt-get install tools of any kind to assist you with your quest to find all those files.

I ended up trying this command, to look for the directories with most files:

/$ sudo find . -xdev -type f | cut -d “/” -f 2 | sort | uniq -c | sort -n

However, as disk space is full, sorting doesn’t work, so I added this:

/$ find . -xdev -type f | cut -d “/” -f 2 | sort — buffer-size=10G | uniq -c | sort -n

The buffer-size parameter attempts to put the whole search in memory instead of saving it to a temp file. This quickly gave me a list of root folders and recursively the total amount of files within those folders. Going into that folder under / and re-running the command gave me a nice list of folders, each which had thousands of files. I could safely delete a bunch of those folders as I knew they were old and redundant (actually left there by the previous server guy) so, after removing some 30,000 files from that directory my df -ih command looked like this instead:

/$ df -ih

Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/xvda1 512K 304K 209K 60% /

Voila! Problem solved. Only 60% usage, and that was just by deleting a few redundant directories that had thousands of unneeded files.

So, when you see your disk is full, but df -h doesn’t agree, remember to check your iNode usage before you increase your disk space.

Is your Linux server disk space maxing out, but still isn’t? Check your iNodes! was originally published in Full stack development on Medium, where people are continuing the conversation by highlighting and responding to this story.

I recently got Laradock’s XDebug and MS Code to talk to each other. Setting it up, was a slightly crooked path and a discovery that getting it to work is a sum of its parts. Sharing is caring, ladies and gents, so I figured I’d give you all the bits and pieces here in one place.

What you’ll need:

• Laradock set up and already running an Nginx server and PHP. Soz, setting up Laradock is too lengthy to cover in this tutorial. There are plenty of resources out there, mainly Laradock’s own installation tutorial.
• basic knowledge of OSX terminal commands
• MS Code installed
• You also need the excellent Php-debug for MS Code extension by Felix Becker installed.

Assuming you’ve got Laradock up and running, this tutorial should take you about 30 min to complete.

Laradock

Just a brief section for those who ended up in this tute and don’t yet know about Laradock.. I won’t spend much time advertising it, just a little :) If you’re a PHP dev, you already know about it or at least have heard about it. If not, take a look. Laradock is basically a collection of Docker containers that can be orchestrated to build into a PHP/Nginx/MySQL environment with minimal effort. It provides every developer with the same basic environment, regardless of whether they’re on Linux, OSX or Windows. Goodbye, “works for me”. And because it’s running off Docker, it won’t mess up your system defaults and you get to decide how much system resources its virtual machine uses. Pretty neat. Laradock is actually a lot more than a PHP stack: it comes with Symfony, Laravel, Redis, Mongo and goshdarn what else bundled. And, with a little tender love and care, you can base your Continuous Deployment setup on the same containers. Nerdalicious.

XDebug

Have you ever needed to find out some variables within a whole nested array of other variables, and confirm some variable gets updated? And, have you had to use var_dump or print_r or echo to see your vars? Painful and time-consuming. Enter XDebug. It integrates with the code in your MS Code environment and gives you the option of stopping a PHP script mid-stream and examining all the system and user set variables, as well as step forward, into and out of functions. You’ll see, wondrous events doth transpireth before thy very eyes.

How this thing works

For those who have done a local setup and used XDebug in the past and have just recently started using Docker, here’s a short explanation to why this is slightly different:

A virtual container, in this case Laradock’s PHP-FPM container, is an entity that’s separated from your machine’s native environment. Therefore, when you’re wanting XDebug to do something useful from a container, you need to make sure that XDebug (running in the Laradock container) can reach your MS Code environment (running on your machine), which is now listening to incoming connections. That’s why you need to define the rules of this connection differently to running everything on your localhost.

Just wanted to get that off my chest :)

Step 1: Activate XDebug in Laradock

In your Laradock .env file (the one with all the central configs) set

WORKSPACE_INSTALL_XDEBUG=true

Then, edit the Laradock xdebug.ini files. Yeap, it’s in two places, don’t ask why. The locations are Laradock/PHP-FPM/xdebug.ini and Laradock/workspace/xdebug.ini. Insert this config:

xdebug.remote_enable=1
xdebug.remote_host=docker.for.mac.localhost
xdebug.remote_port=9000
xdebug.remote_autostart=1
xdebug.remote_connect_back=0
xdebug.remote_handler=dbgp
xdebug.max_nesting_level=250
xdebug.remote_log=”/var/www/xdebug_log/xdebug_docker.log”

What’s happening in the above config is that you’re:

• enabling remote debugging
• defining the remote host to be your localhost’s IP address (yeap, special namespace defined for macs, see https://docs.docker.com/docker-for-mac/networking/#i-want-to-connect-from-a-container-to-a-service-on-the-host)
• setting remote debugging to start automatically and
• using the dbgp handler (you don’t need to know what that is)
• The max_nesting_level has to do with the depth of variable/array structure that XDebug drills into, I think. I’ve never needed to change that.

Lastly, I’ve enabled XDebug logging, so I can.. debug XDebug :) For that to work, create an xdebug_log folder for the log file into what you’ve defined as your synced workspace, i.e. what folder /var/www/ is mapped to in your folder structure. Mine is Users/lauri/code/xdebug_log. That will make sure that everything XDebug does (or fails trying to) is logged into that folder.

All done configuring Laradock! Now it’s time to rebuild and restart your Laradock PHP-FPM container, since you’ve made some fundamental changes. Normally you’d just restart, but since you’re including a new module, you need to actually build the container so Xdebug gets added.

So, run this from the terminal in your Laradock root:

laradock $ docker-compose build php-fpm

You’ll get a bunch of building output. You’ll see some red, but the reds I’ve gotten are notification only.

After that, restart:

laradock $ docker-compose down && docker-compose up -d nginx mysql

Alrighty, moving on to MS Code.

Step 2: MS code setup

We’re using the excellent php-debug plugin built by Felix Becker. Props!

Here’s the Gitter forum for the MS Code php-debug extension, full of like-minded individuals, more knowledgeable than yours truly, many of who have gone through the same process of setup and are glad to offer advice. As a matter of fact, they inspired me to write this tutorial :)

Then set up MS Code to listen to incoming connections from Laradock:

1. Go to Debug view
2. Add a config
3. Fire up Debug with that config

Adding a config creates a launch.json file that MS Code uses for its settings (all configuration of the MS Code environment is by using JSON files). Here’s what launch.json needs to contain:

So, explaining the above:

• I’m logging what happens in my launch config
• This launch config is specifically for PHP
• An incoming request (from Laradock) launches the MS Code debugger,
• Those requests are expected to be coming from port 9000 as previously defined in xdebug.ini.
• The code xdebug is supposed to be using for the session is mapped into this folder.

About the last item: you need to explain to XDebug where it can find its equivalent Laradock-synced files on your local system so it can open them up in the editor and allow stepping forward, in and out. This is achieved by the pathMappings array in your launch.json. Remember, for each project you need to set up one entry here. Think of this as the holy union between your project workspace files and MS Code.

Example: I work on project1 that’s in folder Users/lauri/code/project1. Laradock is set up to /var/www which is mapped to my directory Users/lauri/code. Therefore a project that’s in Users/lauri/code/project1 has a mapping that looks like this:

“pathMappings”: {
“/var/www/project1”:”/Users/lauri/code/project1"
}

Now, after you’ve added the config and fired up MS Code debug, an orange bar should appear at the bottom of your MS Code environment:

What you can also look out for when reloading your page is output in the debug console of MS Code. You should be seeing incoming request threads like this:

Okay, time to place some breakpoints.

Step 3: place a breakpoint

Add a breakpoint to your file. For the purpose of this tute, I’ve created a simple file, which contains just one line. The important thing is that you place the breakpoint onto a legit line of PHP, such as a function execution or a variable declaration. Make sure you validate the breakpoint by reloading the ms code XDebug listener.

If the breakpoint is a hollow circle, that means you need to refresh the debugger to validate that breakpoint. You can do so in the debug bar that’s now appeared when you started listening to incoming connections.

Step 4: toggle XDebug on and off

Laradock provides a simple way to add or remove XDebug to or from your project. It’s handy, because you don’t always need XDebug and it slows down things slightly so you’ll want to switch it on only when you’re actually debugging. Laradock has provided these handy commands, which are run from the Laradock folder:

laradock $ ./php-fpm/xdebug start
laradock $ ./php-fpm/xdebug stop
laradock $ ./php-fpm/xdebug status

Step 5 (optional): adjust your Nginx timeout

As an additional thingy for your xdebugging pleasure, you may want to adjust your keepalive_timeout in your nxing.conf file. That’s optional, but I’ve found it to be helpful to set that to something like 300 seconds, so your script doesn’t time out while you’re debugging. Remember to restart (no need to rebuild) your Laradock instance after changing that.

Here’s a tutorial on using the MS Code debugger. That’s a good read on how to get the most out of your new setup.

Happy XDebugging!

Kind Regards,
Lauri Jalonen

Laradock + XDebug + MS Code? No problem! was originally published in Full stack development on Medium, where people are continuing the conversation by highlighting and responding to this story.