Github: the social coding experience

A couple of months ago, I joined an open source project called aurelia as a core team member. Like many open source projects, the project uses github for its source control…

I’ve been a Microsoft stack lover all my tech life, thus until recently my only visits to github were when someone (for reasons unknown to me at that time) hosted a sample on github. My only experience with git was clicking on the ‘download as zip’ button in github to grab that sample.
Microsoft really never trained me to think otherwise.
I’m a big believer of ‘sharing is caring’ though, that’s why a lot of my blog posts come with inline code samples, samples on MSDN or an extension on codeplex. Imagine where we, the LightSwitch community, would be now if LightSwitch had its source openly available from the start.

About 5-6 weeks ago, I started working on the aurelia validation plugin. It was an eye-opener, to say the least. After only a week of building out some core components, another aurelia team member created a pull request (pull requests are like a request to merge a provided changeset) to implement translations for the validation messages. Great, I thought at the time, a team working together on a project.
Yet, it was more than that. That same week, someone outside of the team submitted a pull request to turn the repository into a JSPM package so it can be easily installed using the JSPM package manager. Soon after, someone fixed some small typos in the documentation. More ‘language packs’ in Mexican, Swedish, Turkish and other languages arrived that week. Some bugs were reported as issues, with clear code sample instructions on how to reproduce it and sometimes even a code to fix the issue, and another issue was opened simply to discuss an integration strategy with another open source validation plugin.
Someone even wrote additional unit tests.
Unit tests!!!
Someone willingly sacrificed personal time to write… unit tests…

I slowly grew to realize the amazing truth: open source projects are not just projects where the source is publicly visible. Github isn’t just a source control website. The open source community, github in particular, are also, and perhaps most importantly, about the social coding experience. Working together with a variety of people to accomplish common goals, to share the creation of something awesome, to share and intensify the joy of our common passion.

Earlier this year, I was talking to some Microsoft folks and they were so excited about their recent announcement that Microsoft server stack is going completely open source.
I didn’t get the big deal at that point.
I use the technology already, and if there’s something I’d like to do different, there usually is support to configure my will or I reverse engineer the sources to see if I can monkey patch it, and carry on with my task at hand.
Yet now I understand: open source is not about having their source in the open, it’s about having an open invitation to join their coding experience.

Let’s hope that everyone and every team at Microsoft truly get that too. Let’s hope that their next products or versions of existing products, embrace the same love for the social coding experience. Lets hope that Microsoft can teach their somewhat traditional B2B LOB introvert application developer flock to embrace the social coding experience too.

Because, after all, what a beautiful experience it turns out to be.

Understanding aurelia.io development prerequisites from a .NET perspective (NPM, JSPM, GULP, KARMA, WTH)

There is this awesome javascript framework called aurelia.io that I’ve been working on and using for a little while now. At a certain point, I feel you’ll owe it to yourself (*if not then at least you owe it to me *) to download one of the sample apps and play around a bit.

Some time ago, when I was trying to do just that, I felt overwhelmed at first. I had limited experience with javascript, HTML and CSS. Aurelia itself looked (is) really easy to grasp, especially since it has a very C# + XAMLesque feel to it. The learning curve still felt steep though, but only because of the surrounding open source stack: NPM, JSPM, GULP, KARMA and the likes. I was like WTH are all of these, and I wish I took 3 minutes to read an absolute beginners blog post like this one to bring my vocabulary up to speed.

Your system

There are some things you’ll need to setup on your system before making the switch to this (or any) open source project…

Git

Git is a free and distributed version control system. In .NET speak: yes it is exactly the same as TFS but it’s totally different. Whenever you want to pull or clone a project (‘check out’) from a server (like github, you’ll need git so your OS understands what the hell pull or clone even means.
Additionally, you’ll often need to execute a command (more about that later). The normal cmd.exe or hipster mac OS alternative will at one point or the other drop the ball in understanding those commands, whereas installing git gives you a ‘git bash’ which looks and acts completely the same as your command prompt but understands how everything in this OSS stack fits together, better.

NodeJS

NodeJS is a platform based on Chrome’s javascript runtime. You could compare this to installing the .NET runtime on your system. To run your aurelia apps, users do not need to install NodeJS first, because your app will run in the browser and use that stack. However, when you are developing apps, you do need a runtime for your tooling to execute in. And that runtime, will be NodeJS.

IDE

You’ll also need an IDE. Your IDE should be an integrated bundle that can do three things: manage your project, execute commands and help you write code.

Unfortunately, Visual Studio ultimate super duper bundle, fails the third requirement as it does not (yet) support ES6 syntax. I know! What a shocker right!

My first alternative was going back to a simple text editor. According to stackoverflow’s 2015 survey, SublimeText is the second favorite one. Once set up with an ES6 plugin for next generation javascript syntax highlighting and intellisense and an integrated terminal/command prompt I realized going back to a text editor was the exact opposite of taking a step back. It’s really, really, really fast. Like: really fast!

A little later, we received a free OSS license for JetBrain’s WebStorm IDE. One of the biggest, noteworthy advantages for me was the integrated (visual) support for git&github. After using it for about 2 months now, it has my love, my official seal of approval, and I doubt I’ll go back to VS for javascript development…

Package managers

Managers… Plural.

NPM

NPM is a javascript package manager. In aurelia, we use NPM because of it’s ability not only to install packages in your project, but also in your tooling. Think of it as Visual Studio’s “plugins”, only you install the plugins in your build process/tooling instead of your IDE.

JSPM

JSPM is also a javascript package manager. In aurelia, we use JSPM because of it’s ability to manage dependencies not only in your project but also in your app while it’s running. Suppose your project uses package A and B. Both A and B have a dependency on package C, but they depend on a different major version: A uses C1 and B uses C2. Whoa, now what? Actually, JSPM will download both version 1 and 2 of C, then when you run your project it will load both C1 and C2 in a different ‘scope’. If some component in A needs something of C, it’ll get the C1 version, whereas a component in B will get the C2 version. WHOA! Think of it as a (really) advanced Nuget.

NPM Libraries

Remember: NPM is used to install tooling, so these libraries are your development tools.

Gulp

Using NPM, you can install Gulp. Gulp runs automated development tasks. gulp watch for example, is the equivalent of your Visual Studio’s F5. It will run several automation tasks like cleaning the code, building it, starting a NodeJS server (like VS starts an IISExpress) and serve up your website (the actual watch part). While you are developing, you can keep the gulp watch command running and any change you do in your code will trigger the complete clean, build & run task chain (in about 0.3 secs) so that your website is automatically refreshed and you can see your changes.

Wait: build? Is javascript built? Javascript itself is not built but it’s a scripting language that’s executed by the browser’s javascript runtime. However, you’ll often use a superset of Javascript (like TypeScript, Dart, … The aurelia team just code in ES6/ES7 (the next and next-next javascript spec)). Because your browser does not understand those, your TS/Dart/ES6 is compiled down (called ‘transpiled’) to plain vanilla javascript that works in any browser.

We use gulp for a number of tasks including building documentation, releasing, etc as well.

Karma

Karma is your test runner. It performs a number of tasks to build the code (like gulp), scan a directory for all test cases and run them lightning fast. Just like gulp watch, you can trigger your test runner with karma start and keep the command running. Any code change will trigger a rerun of affected tests (again: wow) so you can instantly check what you’re breaking/fixing. (More breaking than fixing in my case, but whatev)

Time to play

Armed with this knowledge, I hope you find it easier to go play with an aurelia sample. Set up git and NodeJS from the System chapter, then launch a git bash. Navigate to a working folder:

cd .. #go up one directory, or
cd someFolderName # go into a directory

Now, execute

git clone https://github.com/aurelia/app-contacts.git

This will clone (download) the contents of the a sample app into a folder called app-contacts. When done, navigate to that folder

cd app-contacts

Armed with the knowledge in this article, you should now be able to follow this little guide, and have the app running locally without screaming WTH once. 😉