It's been a while and I wasn't sure if I should bring back this site or not. As you can tell: I've brought it back!

So from here on out I plan on writing again, but more like in the early days over a decade ago, with mixed topics, varying quality, and anything that helps this site to live up to its name - being a useless homepage.

Introducing the home lab

Typically a server environment does not consist of a single machine (those were the LAMP day for small web presences – but we are now way past that ;), but a collection of servers that provide fundamental infrastructure (database server) or individual (micro-)services. I use this for production but also in my own home. Let’s look at a common scenario:

You are on the road with your laptop – connected to the internet. Your production environment – or your home lab – is connected to the internet through a single point of contact. Let’s say we use the network at home, where you will most likely have some sort of (DSL) modem to connect to the net. This modem is completely accessible, all your servers and machines are hooked up to the modem or router. They can all get out, but it is not possible to directly address an individual server from the interwebs.

The problem

Now how can you access files on the private network from the internet? One technique is to use port forwarding from the router. If you ping the address 91.52.206.66 in our example you will get a response from the router, regardless which port you try – unless you define ports to forward you’re always talking to the router.

You could forward a different port for each server – say port 2022 goes to the test server, port 2023 to the application server. Then you could set up ssh on those ports for each machine (or you could simply map port 2023 on the router to port 22 on IP 10.0.0.120). Unfortunately that gets really confusing really quickly – especially if you do network redesigns like adding or moving servers and forget to update the port forwarding. Let’s quickly forget about this approach (which is great for making single purpose machines like a web proxy available, though).

The solution

Instead, you can set up a gateway machine (technically this could be your router, but in many cases those devices are too limited, so I prefer a dedicated machine. Plus in a production environment you will not have any routers…). Forward port 22 (ssh connections) to a proxy machine so that each ssh user@91.52.206.66 will log you into that proxy, not the router. Once you are logged into the router you can ssh into the next machine, which can be any IP inside the private network because technically you are now behind the wall.

While technically you can accomplish all you want by server hopping via ssh, it is cumbersome. It’s much nicer to let you access Application Server directly from your workstation, without explicitely logging into Web Proxy first. If only you had a VPN connection to that home environment? No problem – you can accomplish a similar effect just by using SSH and establishing a tunnel.

How to establish an SSH tunnel

An VPN tunnel will route all(!) traffic from your box for a specific port through the tunnel endpoint. This is done securely and nobody will be able to tell what you do – which is also great for hotel WLAN or corporate networks which block sites and you wish to still access them 😉

Once the tunnel is established you are still active on your workstation – not inside a Terminal session. All actions on the tunneled port are going through the remote machine, even if you address it via localhost.

If you want to establish a tunnel that connects your local port 2345 directly to the SSH server running on Application Server (port 22) you use the command:

$ ssh -L 2345:10.0.0.120:22 homeuser@91.52.206.66 -p 2222

Now you can do a ssh user-on-app-server@localhost -p 2345 and you log into the Application Server. Your local port 2345 is tunneled into the private network! For copying the file you can use scp:

$ scp -P 2345 user-on-app-server@localhost:/home/user/file local-copy

Note that the port is now specified with a capital p, unlike the lower-case p used by the ssh command!

Practical usage with MongoDB

I do not trust the security model of many applications, for example I am reluctant to expose MongoDB and its port 27017 to the world. What I prefer is to go through a ssh tunnel and then access the database. Doing this each time I need to send a command to the database is exhausting, so I set up the tunnel to forward a local port to the database.

The benefit of accessing MongoDB that way is that I get all the benefits from connecting locally from the console. It acts as if I am directly logged into the Mongo host.

When you do not want to actually establish a Terminal connection, but want to have the SSH tunnel available in the background, pass the -f option to the command for setting up the tunnel. This will send it to the background, but complains that it does not have to execute a command. Hence you also need to pass the -N option, which means that no specific command will be passed immediatebly, but the tunnel should remain open in the background.
If you need to close the tunnel runinng in the background the simplest way is to use killall ssh or (on Mac OS X) use the Activity Monitor to search for the ssh process and quit it.

Browsing the private nets – SOCKS proxy

Point-to-point tunnels are nice. However, what if you have multiple webservers running behind a proxy (like Meteor upstreams in nginx) and all of them are only accessible from the private network? If you want to check they are all working correctly it would be nice to be able to browser the web as if you were in the private segment. For this purpose you can use SSH to set up a SOCKS proxy.

The command is simple:

$ ssh -D 2345 remote-usr@91.52.206.66 -p 22

The -D option establishes a SOCKS server on your local port 2345. All requests to that port will go through the SSH tunnel established with host 91.52.206.66 on port 22 (of course you can leave out the -p option if your SSH server listens on the standard port).

Configure the browser (or system settings) to use a SOCKS proxy. In OS X simply use the networking settings under Advanced. Now you can access all private sites as if you were inside the same net.

Take it further

There are many ways to use SSH tunnels more efficiently – like using scripts to execute the required commands for you or using SSH config file. Now that you got a glimpse at the power you already have at hand with a simple SSH server go forth and tunnel all the machines!

]]>Meteor is an amazing tool to create applications for the mobile devices. This guide shows you how to use Meteor to build, test, and send an app to the app stores.

Note This tutorial is a bit long and goes through all required steps from initial app creation to download

]]>http://www.yauh.de/the-illustrated-guide-to-mobile-apps-with-meteor/1867794e-f84d-4e84-bf78-ddf4cdddd983Wed, 06 May 2015 08:28:00 GMTMeteor is an amazing tool to create applications for the mobile devices. This guide shows you how to use Meteor to build, test, and send an app to the app stores.

Note This tutorial is a bit long and goes through all required steps from initial app creation to download from the app stores! You’ll need to walk through several steps that are listed in this agenda:

The app: Reactive H-Ball

In this tutorial you are going to build a simple application that helps you answer life’s most pressing questions, such as “Will I be pretty?” or “Will I be rich?” My last name starts with an H and the image we’ll use is that of a ball, so it’s probably a good idea to give it a name to resemble that. Because it uses Meteor’s reactive powers it shall be called the Reactive H-Ball. Not to be mistaken for a magic 8-ball, of course.

Building the application

We implement limited functionality on purpose to focus on the specifics of mobile applications. All the app should do is to display an answer to a yes/no-question when the device is shaken. We’ll use an animation to make the otherwise quite boring application more mysterious.

The basics

This leaves use with the new application and the three file structure:

reactiveHBall.css

reactiveHBall.html

reactiveHBall.js

Because the application will be so simple, we may keep this structure. All we need is to add a folder named public/, which is where the graphics file shall live.

Next, let’s take care of the core functionality. We’ll use a single template named hball, which will be used to display all content. It needs a single template helper {{answer}} and a button. Why a button? It’s easier for us to test this for now and only later substitute the type of event we’re listening to, so the button fullfils essentially the same purpose as a shake in the final app.

Adding more style

Now that the core functionality is in place, let’s add some style.

First, we need the H-Ball to be an actual ball. We are dealing with various screen sizes, so we must ensure that the ball scales well to various resolutions. Therefore we need a responsive approach, however we keep it simple (put this in your CSS file):

Simple enough, right? Let’s check out how it looks in an actual mobile device. There is an easy way to do so if you are using Chrome. Open up the developer tools and click on the icon next to the magnifying glass that looks like a smartphone. That brings up the device emulation that allows you to check how the screen looks on various devices.

Add mobile platforms

Back to the shell, we need to issue some commands to add support for iOS and Android. For adding iOS support you must have a Mac OS X machine and downloaded and opened Xcode at least once (opening it will make you accept some licenses, plus it guides you through creating the required Signing Identities and Provisioning Profiles – you need this for publishing to devices and it requires an Apple Developer account).

Issue the following commands for iOS support:

$ meteor install-sdk ios
$ meteor add-platform ios

Issue the following commands for Android support:

$ meteor install-sdk android
$ meteor add-platform android

Now the application can be run on both Apple devices as well as Android phones and tablets.

Running on device emulators

Let’s run on a device emulator first.

Run the app on the Android simulator:

$ meteor run android

Can you see it? We have too much text in the upper half of the screen. We should fix that. Maybe it helps to remove the shake button, but first, how does the app look on iOS? Run the app on the iPhone simulator!

$ meteor run ios

That looks nice enough. Now shake it, baby!

Adding the shake

There are many ways to add device-specific functionality to a Meteor application. The simplest is to add a Meteor package (Isopacks). That way you do not have to deal with Cordova plugins (although you could) and deal with the limitations regarding version management (tl;dr: Meteor is not smart enough to determine version constraints from Cordova plugins, only from proper Isopacks).

Running on hardware devices

Do you know your machine’s IP? Find it out, mine is 192.168.2.123. You’ll need it because the mobile device must connect to your machine somehow.

First, we need to create a new file named mobile-config.js in the root of the project. For now it will only contain a single line:

App.accessRule('http://192.168.2.123:3000/*');

By default, Cordova applications (this is the technology used by Meteor to create mobile applications) may not access any URLs unless they are whitelisted. Adjust the line above to your IP address and port where Meteor runs.

On Android you must first enable debugging over USB on your phone. Connect your Android phone, unblock it and start Meteor using

$ meteor run android-device --mobile-server http://192.168.2.123:3000

Of course the device must be able to access the IP address. You can check first by running meteor without any mobile options and trying to open the page using the mobile browser.

It takes a couple of seconds, now you will be able to run the application on the device. I’m testing with a Nexus 5 and here comes the big surprise: The ball is a square!

This is one of the reasons you must test not only with a simulator, but also on actual devices. Otherwise this square would have gone unnoticed, perhaps even get published to the Play Store!

Is iOS any better? Connect your iPhone/iPad and rush to the shell:

$ meteor run ios-device --mobile-server http://192.168.2.123:3000

The previous command opens XCode and does not actually run the app on the device. Once Xcode is opened you can select any of the simulated or connected devices. I select the hardware device and test. Fortunately all looks as it should and even the shakes work fine.

Optimizations

Now that the core application is done, we can focus on some nice-to-haves.

Fix the appearance

Let’s address the issue with the circle being a square on Nexus first – it is as simple as adding the proper viewport to the HTML head section:

Next, get rid of that shake button. I simply uncomment it, so I can easily re-enable it for debugging purposes later.

Finally, we’ll use an image from the public/ folder instead of the <h1> title:

<img src="title.png" alt="The Reactive H-Ball" width="100%" />

Now why do we use an image? In this application we do not need any images, but in most other apps you will have some resources in public/ you’d want to share, so this sample app should cover that use case.

Offline applications

This application is so small and simple, it does not even take a server to do what it’s supposed to. In fact, many mobile applications should be able to survive without a network connection.

The first thing our Reactive H-Ball app should do upon startup is disconnect itself from the server. This is because Meteor does not currently allow/support client-only applications, and as just mentioned, Reactive H-Ball just doesn’t need a server. So, yes, we’re creatively working around the current limitations of Meteor a bit, but it’s okay. If app needs to connect to a server you should skip this part.
Add this line to the startup block:

Meteor.disconnect();

When you run on a device now, you do not have to pass the mobile-server parameter anymore, it isn’t used anyway. Note: This will disable our ability to update the application code without re-submitting the app to the Play/iTunes Store!

All application files should come from the device itself. There is no need to request them from a server and, in fact, there is no server to request them from since you’ve already disconnected. Adding the appcache package enables the application to store those application files in the localStorage. This also includes the contents of the public/ folder, which is where the title image lives:

Meteor offers a package called appcache which uses localStorage to store our apps’s assets. Since Reactive H-Ball is a mobile application it will not benefit from adding the package because it already has all asset in the app that was installed. Using the appcache package is only recommended for applications that run in the browser and require support for offline usage.

Note that, if we were utilizing any MongoDB collections in our app, we’d want to add a means of persisting our data when the app closes. Currently, GroundDB is the most suitable solution for handling that situation.

Preparing for distribution

The app is almost finished, but we have a few final steps to complete before it is ready for the app store shelves. That includes adding some meta information, images, and submitting a binary build of the app to the stores (which you need to have an account for, obviously).

App information

Remember the mobile-config.js file we used for whitelisting the URL? It’s also used to set all meta information for our app. Adjust the block as needed:

Build and deploy the application

That will ensure that a) the building process works and b) the files necessary for submittal to the app store get created.

Let’s assume that at some point the H-Ball application should contact the server. In that case you may want to deploy it on the web. The simplest way is to use mup.

Take some screenshots

When putting the app on the app stores you want people to see what the app looks like. Now’s the time to take a few screenshots of your app in action on both Android and iPhone devices.

Submitting to the stores

We start with the following file structure:

app contains the actual application sources

build contains the output of the meteor build command

build/android holds the necessary files for submitting to the Play Store

build/ios holds the necessary files for submitting to the iTunes Store

Google Play

You need a Google developer account (one-time fee of $25). Once you have an account you can submit your applications at the developer console. Before we can do so, you must sign your application bundle or apk file.

Step 1 is to create a key. This key is essential and you mustn’t lose it. If the key is lost, you will then lose the ability to publish updates! Create a key via the shell command:

Step 2 is to sign the unaligned application file. Using the command in the previous step (when we used meteor build) created an android/ directory inside our project. There you can find a file named unaligned.apk. This needs to be signed.

Open a shell and cd to the android directory. The command used for signing the apk-file is

Now you have a new file production.apk. This should be submitted to the Play Store.

Step 3 is done in the Developer Console – a web interface for submitting your app. I hope you like filling out forms, because you need to do this quite a bit.

Once you have uploaded the apk file you need to fill out the product details and upload some screenshots and icons. Green checkmarks will let you know when you’re done. Once all is green you can hit the Publish app button.

iTunes Store

You need an Apple Developer account, which will need to be renewed annually or else your apps will be removed from the store! That also means you need to pay $99 each year to stay listed. Got that? Then you’re ready to submit your app.

Next, head over to the iTunes Connect site. You will need to set up your application before we need to open Xcode. Go to My Apps and click on the + sign to add a new iOS app. Most of the fields take whatever you want, except for the bundle identifier. Make sure to use the correct one (case matters!).

If you like, you can start digging through even more forms to prepare your marketing collateral to publish the app. You might as well do it now, because you’ll have to eventually. Fill in all information and upload screenshots and come back here when you’re done.

Open the Xcode project file Reactive H-Ball.xcodeproj. Make sure an iOS device is connected via USB; you will need it.

Check the project settings under General and make sure there is a team selected for Identity and the correct bundle identifier is used. If the bundle identifier is wrong, you can adjust it in the Info settings.

One more thing – set the deployment target to be iOS 7.1. Dealing with legacy versions of iOS requires some more work and a minimum of iOS 7.1 requires less icons and splash screens, hence making life easier overall.

Select the hardware device just like you did when running on the device. Now open the Product menu and click Archive.

Another window pops open with a list of all available archives. Perform a validation of the archive before you submit it to the App Store.

If that went well, you should now (finally!) be able to click on Submit to App Store… You’ll be rewarded by a “Submission Successful” message.

Unfortunately, in my case I saw an error message. There were some app icons for iPad missing, so I needed to fix this. Back to the project settings and clicking on Use Asset Catalog for the App Icons.

A new screen will open and you can drag the missing icons (in my case icon-76.png and the retina version) into the asset library).

Alas, the app will still not go to the app store. More hoops to jump through! Return to the iTunes Connect site. Before the app can be released, it must be tested. D’oh. You need a user with the “Internal Tester” role and active Test Flight (All under the prerelease tab).

Once you invited a user (go to internal testers and select one or more users and click Invite) all testers will receive an email that they can start testing:

Install the TestFlight app on your device and then inside of it, open up your new mobile app.

Once everything is tested, you should add the build in the iTunes Connect Versions tab of your application under Build.

With a build added you can finally submit the app to be reviewed by Apple. Let the waiting begin.

Now might be a good time to check the current wait time for app reviews at appreviewtimes.com.

Apple will send you emails about status changes for your app. Be prepared to wait a few days.

Get the apps

]]>Recently I prepared yet another introductory presentation about Meteor, the platform for building web and mobile applications. Alhough it is not fully self-explanatory it may be useful if you want to introduce the platform to friends or co-workers.

**[Meteor – not just for rockstars](//de.slideshare.net/stephanhochhaus/meteor-not-just-for-rockstars "Meteor -

]]>http://www.yauh.de/meteor-not-just-for-rockstars/627125f1-1bf3-414e-b993-376c6b5474cfThu, 23 Apr 2015 06:12:19 GMTRecently I prepared yet another introductory presentation about Meteor, the platform for building web and mobile applications. Alhough it is not fully self-explanatory it may be useful if you want to introduce the platform to friends or co-workers.

**[Meteor – not just for rockstars](//de.slideshare.net/stephanhochhaus/meteor-not-just-for-rockstars "Meteor - not just for rockstars")** from **[Stephan Hochhaus](//www.slideshare.net/stephanhochhaus)**

]]>Meteor.js is an open-source platform built on node.js for rapidly creating reactive web and mobile apps. It is designed to allow programmers to create applications in a modern fashion, using up-to-date paradigms, most importantly reactive programming. Meteor became v1.0 on October 28th, 2014.

]]>http://www.yauh.de/best-learning-resources-for-meteorjs/f94ff49b-74df-4513-87ef-33eaa6a43656Thu, 26 Mar 2015 07:00:00 GMTMeteor.js is an open-source platform built on node.js for rapidly creating reactive web and mobile apps. It is designed to allow programmers to create applications in a modern fashion, using up-to-date paradigms, most importantly reactive programming. Meteor became v1.0 on October 28th, 2014.

Code Examples

Sometimes it is best to study some existing sources to become more familiar with coding conventions, patterns, styles, and what not. Here are some interesting repositories you can learn from and -who knows? – possibly even contribute to.

Books

The internet is great for up-to-date information, but sometimes a book (on paper or electronic) provides better structure and didactic concept, so that you may wish to use one in the beginning to make the most of your learning experience.

Discover Meteor is an excellent book written by Sacha and Tom, that will teach you all the basics you need. (Also, if you use this link here you can save 20% when you purchase the book!)

]]>Quick results with the Meteor platform and amazing success stories with Node.js lead to more developers slowly turning into sysadmins. Unfortunately being able to quickly deploy something to the web does not always mean you’re doing it right. One of the most often discussed topics when running Meteor]]>http://www.yauh.de/do-i-really-need-nginx-with-my-meteornode-js-app/296a6bad-d9be-4b1c-bb62-96d57d475889Mon, 23 Mar 2015 10:56:12 GMTQuick results with the Meteor platform and amazing success stories with Node.js lead to more developers slowly turning into sysadmins. Unfortunately being able to quickly deploy something to the web does not always mean you’re doing it right. One of the most often discussed topics when running Meteor on the web is whether to use a proxy such as nginx or not. As it happens, this topic was brought up again in Josh Owens’ Meteor Club over the weekend so I finally got around to do some benchmarking.

tl;dr: YES!

Let’s talk about proxies

A proxy is a middle-man, just like Postman Pat. It improves the process of delivering data over the web in one way or another. Typically it comes down to various flavors of caching frequently requested data.

nginx, haproxy, varnish and even Apache can be used to proxy requests to other servers. They each have advantages and focus on other areas, but this should not be our main topic for today.

How to determine whether I need a proxy?

We’re going to focus on the Meteor platform for the sake of argument. Basically once deployed, it is nothing more than a Node.js application, so all said for Meteor applies to Node.js and io.js (more or less).

In order to determine whether you need a proxy you can rely on expert opinions or look at the numbers yourself. Let’s do the latter as there are no experts around right now. To generate some numbers we need to conduct a couple of tests. But first we need to pick our proxy of choice.

Why choose nginx?

For me choosing nginx is a no-brainer because it does all I need and I have worked with it for so long now (think PHP) that I know many of its pitfalls and capabilities. It brings certain qualities to the table:

Testing performance

Let’s only focus on a tiny aspect of running a Meteor application: Serving static assets. That means we shall limit our tests to the root path and static images. Certainly this is not a spot-on real-world scenario, but it gives a good overview of the differences in this specific use case.

Setup and Scenarios

We will use two machines, one that is the system under test (let’s call it meteor) and another to test the first (named comet). As a test tool we use the simple but proven Apache Bench, also known as ab. To simulate users we set the concurrency level to 100 and run through a series of 100k requests to the server.

The systems have a single CPU core, 2 GB RAM and are KVM machines on the same host. They connect via a virtualized Intel E1000 NIC.

There are three environments to test:

Accessing Node.js directly at port 3000

Configuring nginx to pass all requests to Node.js, no additional optimizations but adding gzip compression at port 80

Configuring nginx to serve all static files directly at port 80

Two test cases shall be executed:

Request /

Request a 100k image.jpg file

Results

The results for the root path are not as clear as I’d hoped. Using nginx it seems that requests are just passed to Node.js, regardless of what happens then, while all requests that went straight to Node.js brought some additional side-effects. I will have to re-do this test with some proper monitoring in place to see whether Node.js got swamped or if it was capable to responding that much quicker (which I highly doubt).

That leaves us with the results from the static image.jpg tests. Here the results are quite clear:

Node.js alone takes 145 seconds to complete the test, nginx serves the same within 62 seconds. It more than twice as effective at serving static content than Node.js is!

Let’s compare the results over time. This is how Node.js answers the requests:

And here’s nginx:

As you can see both respond well within 200ms, but (unfortunately it’s hard to see due to the two outliars) nginx does most of its work even below 100 ms (99% get served at 98ms or better) while Node.js serves 50% at 139ms or better.

Many people put nginx in front of their Node.js app, but don’t care at all about serving static assets by nginx. They lack a configuration block like this:

Since this is where the magic happens for serving images, let’s look at the picture without this optimization:

Wow, these response times are all over the place! This is even worse than using Node.js on its own. The test duration was actually longer than before, and the mean times significantly slower. Sure, for a low number of requests this does not matter, when Node.js was done the proxy-only nginx was already at 98% finished, but nonetheless – these requests can (and will!) stack up and leave a tail in your performance reports.

Verdict

For serving images you gain impressive performance benefits when coupling Node.js with an optimized nginx configuration. Simply using nginx as a proxy but not serving images will even give you a penalty that can be easily avoided by adding static resources to the same machine than nginx and serving them directly.

Potential improvements on the root path seem impressive at first glance as well, yet I am not sure this is the honest truth. Once I have proper monitoring for all components in place I shall repeat this test to verify that initial requests see a comparable benefit than images.

Raw results and config files

You can find all details for this test and results at my GitHub repo https://github.com/yauh/meteor-benchapp. This includes more graphs and – most importantly – the configuration files used for nginx.

]]>When you are starting out as a programmer you are happy for every bit of success, no matter how small. The least thing on your mind is writing pretty code, all that counts is functionality. Quick results. Sometimes advanced programmers find themselves in a similar situation. During a hackathon or]]>http://www.yauh.de/writing-clean-javascript-code-with-eslint-and-js-beautify/88f493fa-3ab8-4def-8e7f-201208445ac0Thu, 26 Feb 2015 08:03:06 GMTWhen you are starting out as a programmer you are happy for every bit of success, no matter how small. The least thing on your mind is writing pretty code, all that counts is functionality. Quick results. Sometimes advanced programmers find themselves in a similar situation. During a hackathon or when customers pressure you into impossible deadlines, style is the least of your worries.

Unfortunately neglecting good and clean style can quickly come bite you in the behind. To avoid dumb mistakes and make projects scalable in the first place, you should introduce proper style early on in your development life.

Look at your code

Before you continue take a good look at some of the code you have written today. Now consider these two:

Is your code compliant with the JavaScript rules and conventions? What would the compiler say? Is it legal?

Is your code consistent and self-explanatory? Would other developers be able to quickly grasp what you’re doing?

Introducing linting

Humans are good at doing creative things, like writing, painting, or breaking the rules of programming languages. As such it is a good idea to analyse our code using programs that are much better at playing by the rules than we are. That brings us to the linting tools of the JavaScript world.

Linting is the process of examining your code and identifying syntax errors and style anomalies (also known as static code analysis).

JSLint

First there was JavaScript, and it wasn’t all good. Douglas Crockford identified the good parts and distilled them into a tool called JSLint. It’s strict, it’s been around a while, but it gets the job done.
It has 22 documented options that you can use to customize its reporting behavior.

JSHint

A bit younger, improved adaptation to your own rules – that is JSHint. It is probably the most used linter in the JS community. Everytime you find a github repo with a .jshintrc file you know they care about linting. Files and directories that should be excluded from linting are mentioned in .jshintignore.
With 69 documented rules it is more customizable than JSLint.

JSCS

If all you really care about is style, then JavaScript Code Style is your companion. They work closely with the JSHint developers and there is consensus that JSHint will eventually focus on correctness only while JSCS is all about (personal or team) style.
At 100 documented rules pretty much any style guide can be matched, just put them inside .jscsrc and the linter will automatically pick them up. It also contains an option to exclude files.

ESLint

The new kid on the block is ESLint. It is pluggable and can easily be extended. It combines the power of JSHint and JSCS and even though it is not as mature as those two it is ready for serious action and sports 169 documented rules that can be extended quite easily by plugins or own rules. It differentiates between warnings and erroOut of the linters presented here ESLint is the only one that will tell you which rules have been violated in the reporting process, making it the easiest to work with in my opinion.
All configuration can be done using .eslintrc and .eslintignore.

Performing a static code analysis

In order to install any of the linters you need to use npm and install them as regular modules:

Command line linting

You can now invoke analysis from the command line by calling the linter with the file or directory name of the code to inspect.
To analyze all files in the current working directory using ESLint issue:

$ eslint .

That will output a list of all found problems.

Personally I do not find this command line reporting to be terribly helpful, as I need to go back to my editor and look for the files and lines to fix them. Fortunately there is a better way.

Linting in the editor

Most editors have plugins that allow you to use these linters during the editing process instead. Be it Sublime, Atom, or any of the IntelliJ editors, all support linting tool messages inside the editing workflow, which greatly increases productivity.

Worry less about fixing style issues

In an ideal world, editors should make it simple to write code in style and hard to violate rules. This is when some of the fixers enter the stage.

When working in a team or you are switching machines or even editors often you want all their settings to be the same. Editorconfig is a small but very versatile tool that can set 6 common options via an .editorconfig file. Once you have a configuration file and the editor plugin installed, everything works automatically.

Full blown IDEs usually have a code reformatter or beautifier, but also leight-weight editors such as Atom can be extended to use JS-Beautify (heralded by some as the de-factor standard for producing clean JavaScript code) which allows you to tweak 17 settings inside its .jsbeautifyrc config file. Beautification will not happen automatically, but usually it is initiated by pressing a key-combination (or selecting a menu entry). This affects either a selection, a whole file, or even the entire project.

For a more powerful beautifier take a look at esformatter. It comes with a whooping 286 documented settings and can bring your code into good enough shape to pass any of the linting tests, regardles how careless you code. In Atom it becomes a bit more complicated to use since you need to bring up the Command Palette and enter esformatter for it to perform its magic.

Installing them is again done via npm install.

Bottom line of linting

As you see there are many tools available to support writing clean, stylish code. It needn’t be all complicated, even beginners can greatly benefit from a little effort on style.

To get started I suggest the following:

Install ESLint and use the minimum set of rules

Install Editorconfig and JS-Beautify to automate formatting as much as possible

Get used to performing lints within your editing workflow – don’t use them as a quality check after you’re done

Start with a small ruleset and introduce rules only as needed to avoid false positives. Nobody listens to a linter that reports thousands of violations

]]>http://www.yauh.de/where-can-i-discuss-meteor/8da1acc3-265b-4a22-b85c-fbc73534838bWed, 28 Jan 2015 11:45:02 GMTUpdate In February 2015 the situation has changed – the Google Groups are no longer, please move over to the new Discourse forum for discussing Meteor. Of course, crater.io, IRC, Reddit and the others still exist. Only Google Groups has been abandoned 🙂

The beauty of communities is that you can exchange ideas, discuss problems, ask questions, and eventually extend your own and others understanding of the topic in question.

The Meteor community is no different – it is a rich, vibrant group of individuals that care deeply enough about the Meteor platform that they want to contribute their time and energy to make it truly the best tool to build realtime web applications.

Especially to newcomers in this community it can be a bit confusing when starting out, so it is natural they need some guidance where to go. Great blog articles like How do I become a web app developer – Meteor style by Ben surely get people on the right track – but where to go when you are lost?

There are various places (and even more than I list here) where the Meteor crowd gathers. These include:

The meteor-talk Google group, used for general and technical questions, requests for help, and new project announcements.

The meteor-core Google group for discussing Meteor internals and proposed changes.

Last but not least, you can look people in the eye at one of the Meteor meetups that take place in many major cities worldwide.

Because it can be hard to determine when to visit which place I connected my brain to OmniGraffle and create a simple flow chart to illustrate the way I think whenever I want to discuss Meteor with more than just a single person (which is when I usually phone up Manuel on Skype).

This is how I decide which of the many community places to vist. Please note: The flowchart leaves out some of the mentioned resources simply because it represents my personal choice and I do not frequent some of the listed places.

Which are your favorite place to connecting with the Meteor community? How do you decide what to post where?

]]>In 2014 I was a slob. Don’t get me wrong, I got stuff done, but I feel I was way below my actual capabilities. This year, as I am sure everybody else out there thinks as well, will be so much better. Why? Because Apps!

I decided to bet

]]>http://www.yauh.de/apps-that-will-help-me-stay-organized-in-2015-2/aa97f800-62ca-48f2-bbdf-ce41acbd5a07Fri, 02 Jan 2015 14:33:31 GMTIn 2014 I was a slob. Don’t get me wrong, I got stuff done, but I feel I was way below my actual capabilities. This year, as I am sure everybody else out there thinks as well, will be so much better. Why? Because Apps!

I decided to bet on a low-tech/hi-tech combination for increased productivity in 2015. While I stocked up on Moleskine notebooks I also decided to load these nifty helpers onto my iPhone for the coming year:

Things

I will use Things to track most of my daily tasks. All project related things will live in either Jira or Trello, depending on their complexity, but everyday chores and todos go into Things as soon as they cross my mind. We will see how that goes.

Habit List

I am a huge fan of building new habits. Habit List is a tool to apply the “Don’t break the chain” method developed by Jerry Seinfeld. I use it to track recurring things like working out, taking my vitamins, doing my weekly plannings, etc.

Day One

After several short-lived periods of excessive Day One usage as part of my daily routine I try one final attempt to track achievements and other note-worthy things during the day. I have still high hopes I can combine it with Launch Center Pro somehow to streamline the daily journaling process.

Trello

It’s been on my phone for a while, just like I have been using Trello for ages. Being a huge fan of Kanban boards it comes almost natural to use Trello to organize all smaller or not-so-technical projects with this instead of the mighty Jira. Sometimes Trello boards are even more fun when viewed as lists.

Withings Health Mate

Last but not least I am wearing my digtial companion on my wrist and I use Health Mate as its interpreter. Ever since using my Jawbone I got intrigued by collecting quantified numbers documenting my behavior, but I feel I am growing a bit tired of it. Mostly for tracking weight I will be using the Health Mate and see if it is convincing enought to support me throughout the entire year.

These 5 are my starting team. From experience I am almost sure that these will not stay with me for an entire year. Let’s see how long they last and how useful they turn out to be.

You may not even know it, but if you sell digital goods on the internet in 2015 you are affected by new tax laws. That is, if you have a single customer in the EU. Germany, Denmark, Spain, the UK, Poland – there are plenty of places. A market of roughly 500 million people.

You are affected! Deal with it!

These new laws require you to collect VAT (value added tax) from each non-business customer and pay it to the country of residence of your customer. Sounds complicated? Trust me, it is!

We got at least 6 ways to address the problem, but unless you live outside the EU member states, you should probably comply eventually. (If you are based in Sri Lanka or the US, lucky you – even though technically you must participate in this madness, who is going to make you? Probably nobody. But perhaps it becomes part of TTIP? Who knows!)

Bringing in UX

The biggest challenge for implementing the new VAT rules lies in user experience (UX). How do you implement all regulations while still maintaining good conversion rates and preventing your customers from cancelling the process out of frustration?

The new rules are few. If you are selling to customers outside the EU states, nothing changes. If you are selling to businesses (VAT-registered) inside the EU, things stay the same as well. No need to add VAT. But for private citizens, the ones who dread complicated checkout procedures, you need to jump through several hoops.

Determine if your customer is from a EU member state.

Collect two independent pieces of evidence they are really from that member state. You may use IP address (hello VPN and corporate lunch-break shoppers), billing address, location of the bank, country code of SIM card, and location of the fixed phone line (if they still own one, that is).

Show the final sales price to the customer. I am not sure whether you must already tell them how much VAT is included at this stage. Probably not.

In some member states customers must receive a simplified invoice, stating the details of their purchase, including the VAT amount charged.

Keep this evidence for at least 10 (!!!) years.

Let’s leave out the fact that every quarter you must declare how much VAT you collected and pay it out to the (now) 28 member states, that is what MOSS will hopefully help with. Again, theoretically everyone on this planet must do that, if they sell to Europeans.

I have left out all business sense, just focused on UX until here. Of course, you might not be willing to have varying margins on your product just because the EU is crazy. The alternative would be to have significantly varying prices across all of the EU. Keeping things simple I assume you always charge the same amount from everyone, only your share is best for businesses and customers from Hungary (27% VAT) pay significantly less than people from Luxemburg (17%).

I also left out the nitty-gritty details of determining the exact tax rate, updating tax percentages in your system when they change, whether purchases take place from inside a plane (tax-free) or on the ground (see this nice list to understand how to charge VAT on a train from Buxelles to Warsaw) – the typical tax nightmares you pretty much had to deal with in 2014 as well. Well, now you need to worry about an additional 27 states, with a plethora of rules and regulations. Let’s keep things simple for now.

The devil in the details

To illustrate things, and because I am a visual thinker, I have created a small flow chart what I think (no guarantees, this might still be missing the most important aspects as I am in no way a tax accountant) covers the basic approach.

You can see what a mess the flow is for anyone resident in the EU. Also, what about those pesky Europeans on a trip overseas willing to purchase something? Actually we also need to check requests from the US, because if they come from European citizens we need to show them how much VAT they pay. Or, if you prefer the hard way, show a different price.

Hence, before we can show a price to website visitor we need to ask them several questions. Imagine going into a store and asking how much the chair is and they ask you where you’re from. Charging the Hungarian more than the German sounds like discrimination? Because it is. But it seems to be intended by the EU commission, so I am all for fighting these stupid tax laws. In the short-term it appears we must comply, or else risk mighty high fines.

What should we do?

Coming back to UX. I recently tried to do some research on technical implementations and I was shocked that less than a month from those laws becoming effective there are no good solutions available. Because the community is quite large I looked at WordPress in more detail as I know many content marketers based their business on both digital downloads and WordPress. Again, most solutions pretend that there is no need to address this complex requirement.

I think it is time to discuss approaches to design UX for small shops and startups that complies with the laws of 2015. Any pointers to existing UX approaches are greatly appreciated in the comments. A clever bunch like the start-up scene must be able to come up with a way to jump through this ridiculous hoop.

What’s so special about Meteor?

As the creators of Meteor revealed on their website, they consider their work to be comparable to that of the Apache Foundation or the Free Software Foundation. The Meteor project is in fact an umbrella organization that provides:

libraries

tools

standards

services

As such, Meteor is not yet another JavaScript framework like we have seen so many rise to fame in recent months. Meteor is an entire ecosystem.

Meteor boldy claims that developers can now build an app with just a few of lines of code where previously they needed thousands. This claim is based on the assumption that for each project you spend a large amount of time assembling your tool chain, then writing basic infrastructure code to provide event handling, view rendering, and low-latency data synchronization.

When you first start using Meteor, you will see how much non-functional code you needed to write in your previous life.

Put on a business hat. Meteor allows you to fully focus on implementing business functionality that benefits the user. That makes it an amazing tool for building MVPs. Don’t worry about laying the pipes first.

Meteor is like an empty house. Bring your furniture and settle in right away. Electricity, plumbing, and even a kitchen are already there. Hell, even Wifi. Or do you prefer to buy a patch of land, hire an architect, develop the plot, and build the entire house from scratch?

Other frameworks give you much freedom and flexibility. Meteor gives you a headstart. It’s important to understand when to use which. Most of the time it makes no sense, technologically and economically, to build an entirely new house. Also Meteor allows you to swap out parts for others, except you don’t have to.

Why would I want JavaScript on the server anyways?

Over the last several years, we have seen very different frameworks mature — Symfony in the PHP realm, Rails for Ruby, Spring for Java. You could argue that these are highly optimized for development ease, but they take a legacy approach to developing for the web. They are built around the idea that the server is the smartest person in the room and should do all the processing. The client is just a consumer with some tricks to send back data. Occasionally. It’s like newspapers. Or libraries.

The way we use the web today is in realtime, collaborative and always-on. How can this be supported by a legacy foundation that is based on a single server sending pre-rendered information out to passive clients, adding cumbersome Ajax-calls to somehow get bi-directional data flow?

The new web is event-driven, and so is JavaScript.

Using JavaScript for a modern web is not a neccessity inside the browser. Why implement a disruptive interface between front- and backend to handle data handoffs via REST, using one language on the server and another on the client? The resulting code-duplication makes maintaining (and extending!) applications much more costly and painful.

I am still not convinced

As much as some people despise it, have you seen WordPress? Sure you have, it ubiquitous on the web. For some of us it is even synonymous with the web. Chances are you visit at least a dozen wordpress sites a day without realizing it. WordPress has democratized web publishing for the rest of us. Every person, heck – even my mom! – can start publishing their writing to the web in minutes.

I believe that Meteor will do for web developers what WordPress did for the average Joe. It does not take weeks to work on a side project you can actually show to friends and family. It only takes a weekend to put your ideas into code (perhaps even a single night if you are into sleep deprivation). Meteor significantly lowers the entry barrier to building apps that meet today’s user expectations.

In addition Meteor, allows you to build for different targets easily, the web is just one. Thanks to a clever integration of Cordova (also known as PhoneGap) into the platform, packaging your application as an Android or iOS app is a breeze. Don’t worry, you don’t need to learn Java and Swift and code native apps to make great mobile apps.

Also, if you have read until here, you could have already installed Meteor on your machine.

Dive into Meteor today

Meteor is not only an efficient tool for building applications, it is also a lot of fun to use for both newbies and experienced developers alike. The quickly visible results are highly motivating, which makes Meteor an ideal tool for getting your feet wet with an isomorphic JavaScript architecture. Something to do for the upcoming long winter evenings for sure.

Meteor will eventually turn the web into a reactive, distributed realtime platform. Be a part of it!

]]>This time it is all about the music. With Samhain coming up some folks are sure to be celebrating Halloween and they should do so with the appropriate tunes. Here are my suggestions for spicing up your 2014 playlist:

Tune #1: Halloween in Heaven by Type O’ Negative

Tune #2:

]]>http://www.yauh.de/spice-up-your-halloween-playlist/8f5afe14-b59a-46d4-9f35-518ab5effa23Tue, 28 Oct 2014 08:58:07 GMTThis time it is all about the music. With Samhain coming up some folks are sure to be celebrating Halloween and they should do so with the appropriate tunes. Here are my suggestions for spicing up your 2014 playlist:

]]>The introduction of the first iPhone has changed the internet forever with the introduction of mobile apps. Many people predicted in 2012 already that native apps (applications specifically written for iPhone or Android using Objective-C or Java) were soon to be extinct by a flood of HTML5 hybrid web applications.]]>http://www.yauh.de/top-mobile-apps-you-didnt-know-where-built-on-html5/184aca88-8f55-4393-b28a-9c0476cc4231Tue, 09 Sep 2014 11:41:16 GMTThe introduction of the first iPhone has changed the internet forever with the introduction of mobile apps. Many people predicted in 2012 already that native apps (applications specifically written for iPhone or Android using Objective-C or Java) were soon to be extinct by a flood of HTML5 hybrid web applications. Until today, this hasn’t happend. Or has it?

Honestly, I am too inexperienced with either type of mobile applications, which is why I ha to do some research on who actually uses (hybrid) HTML5 apps these days.

The list is far from complete, and many – particularly smaller – apps favor hybrid over a native approach. Why is that? Typically when people talk about mobile apps and why they should be native instead of HTML5-based three main arguments come up:

With HTML5 you can have full access to all functionality of the mobile device beyond what HTML5 can do.

Unless you go native you have to deal with differences between the mobile browsers to ensure your app looks alike across platforms.

Now if you think it’s time to get started on your own mobile applications and you are still worried about the three arguments above, let’s see what we can do about it:

Argument #1 is supposedly taken care of by projects such as famous, which intend to bring 60fps (as in full performance) to any mobile device. Hence resulting in a native look-and-feel that is as responsive as you could expect from a native app.
An answer to the second argument can be found in using not only HTML5 inside a mobile browser windows, but instead utilizing the power of Cordova.
The third being very valid, but then again it does not matter whether you have to take care of 3 different types of native apps or the way 3 different devices render your onw application – there is still effort involved.

]]>I recently had the chance to take most of my hardware offline so I could perform some overdue maintenance. Out of curiosity I conducted some benchmarks, just to see how the different boxes compare.

I thought I might share them with you in case you are looking for some computing

]]>http://www.yauh.de/benchmarking-my-hardware/2d769a5e-1066-4485-9fd9-e1d3503efb27Tue, 02 Sep 2014 15:35:53 GMTI recently had the chance to take most of my hardware offline so I could perform some overdue maintenance. Out of curiosity I conducted some benchmarks, just to see how the different boxes compare.

I thought I might share them with you in case you are looking for some computing resources. Also, this article serves as my external memory should I ever want to look up the results.

How to benchmark

Testing a system used to be tedious work, but now it is very simple to a) test a machine thoroughly and b) easily compare the results. I used the open source test suite Phoronix. It also produces a nice little report which I am going to show you later.

Dramatis machinae

Powered by a single AMD Athlon II Model NEO N36L with 2 cores running at 1.30 GHz and 1MB L2 it is the lowest powered machine I own and it is used as a small server that does little more than serving files.
In my configuration it uses 8 GB RAM and has 4 2GB HDs as a RAID-10 using software (mdadm) instead of dedicated hardware.
Tests ran on Debian Wheezy.

Although technically it is not hardware I own this is my preferred web server as of now as it is affordable and yet has great specs. Powered by an 8 core Intel Core i7-4770 (3.40GHz) with 32 GB RAM it can easily serve all my projects and still idle around most days. Two 2 GB hard drives as a software RAID-1 store any and all data.
Tests ran on Debian Wheezy.

Test results

Depending on what tests you decide to let run, there are a lot of results and diagrams produced. This is only a subset of the full suite I ran with Phoronix.

As expected, the HP is the slowest of the bunch, but it does not need much energy and it is a true work horse. It is a great machine for serving files.
The Zbox ID 91 did quite well, considered it is basically a laptop which doesn’t cost all that much. The SSD surely helped giving it a slight edge in some cases. However, while the ID 91 is great for many development purposes where you need some (limited) power and no high-availability it cannot act as an actual server. Not even with the dual NIC setup.
Both the Hetzner EX40 and the TS-140 with an E3-1245v3 did a very good job. There are some cases, when the i7 from the EX40 had the upper hand, in some (less) cases the E3 took a minimal lead.

]]>Meteor is the new isomorphic JavaScript framework that will make developer’s lives so much easier and make users fall in love with your app again. I recently published a rather sarcastic article based on all the FUD I have been hearing the last couple of weeks about what I]]>http://www.yauh.de/10-reasons-to-start-using-meteor-today/96988193-22f5-4f89-8fc2-683b5b2a2bbfSat, 12 Jul 2014 13:56:52 GMTMeteor is the new isomorphic JavaScript framework that will make developer’s lives so much easier and make users fall in love with your app again. I recently published a rather sarcastic article based on all the FUD I have been hearing the last couple of weeks about what I believe will change the way we work the web. This article intends to set the record straight and I shall tell you 10 reasons why you should start using Meteor today:

Meteor is an awesome platform for building web applications, but it can also be used to go beyond the web. Using its modular approach you can use Meteor as the backend for your iOS and Android apps as well as use it to power the internet of things. You can build virtually any kind of app and to make life easier out of the box it is just perfect to build web applications really quickly. Meteor delivers.

Meteor is built on top of on Node.js, which is used for some of the biggest sites on the internet. PayPal relies on it for their payments infrastructure, and also many other big names. Here’s a fun fact: Did you notice that Node.js is still a v0.something? So don’t worry about Meteor not being 1.0 yet. Node.js is taking over and Meteor will too, eventually.

Meteor can be learned in hours. You can get almost instant results which is not only a great motivation if you get started with programming, but also if you are experienced you will not have to spend a lot of time to actually accomplish anything with Meteor. Probably the best way to find out how you can use it in your next project is to invest a day or two and start learning Meteor!

Meteor brings its entire infrastructure with it when you start. A single command installs Meteor on your system, a second creates a new project and a third starts the full stack, with Node.js and MongoDB. There is no need to request any development systems or waste time configuring servers, ports, and paths. Need to change something? You can use the command line to easily change ports, database instances, etc. Get started with Meteor. (Of course deployment into scalable architectures is entirely possible, even if it takes more than a couple of seconds to set up.)

Instead of bundling all functionality in Meteor’s core it uses packages to extend your application. And there are a lot of packages available on Atmosphere, but you can also use any npm module you like!

Internally Meteor also uses packages, which makes it even more flexible as you can just take a subset of functionality and substitute it with something else. Like having an Angular frontend using a Meteor backend. Or running Meteor against a Java backend. Now, how clever is that? (You see what I did here?)

During the early development stages your life will be made so much easier by automatically sharing all data between the server and the client and not having to worry about permissions on either end. Before you send a Meteor application into production you obviously have to make it secure, so not everybody can access your database from the browser. So you start with a less secure development environment where you can quickly bootstrap an application and then make it production ready, which includes securing access.
For the go live you simply need to remove 2 (as in two!) packages from your application, namely autopublish and insecure. By the time you go into production your app will not be any less secure than any other PHP, Java, or Rails application.

Still not convinced? By using its magical reactiveness Meteor is sure to amaze your users (well probably more the developers)! Any changes made by other users, like adding comments, may be automatically pushed to all connected clients. It just works – pretty much out of the box without writing that specific code to push data across the wire.
Not having to write specific code to manage data distribution makes development so much quicker and more fun, because you can simply focus on your application logic, not worry about logistics. That’s the beauty of transparent reactive programming.

Being an isomorphic framework you can save even more time: You write code once and it becomes agnostic of where it is executed. Write a function to validate a credit card number and let it run on the client and use the exact same code to validate on the server. Less coding time, less lines of code, less errors.
Sharing code is as easy as putting your file in a common folder of your app. All specific code (like secret API keys or mapping mouse events) may go inside a server/ or client/ folder. Meteor blurs the line between client and server to get you even more DRY.

In the end of the day, Meteor is nothing more than a collection of software. Of course you could build it all by yourself, but why should you? You don’t build your own linux distro, so why spend days or even weeks to evaluate and pick a frontend framework, a rendering library, a build tool accompanied by a server framework, a WebSockets library, then deciding for a database, creating your own format to exchance messages between server and client, define a REST api, only to create a small client project. Pick Meteor and you are ready to go in an instant.

Meteor is certainly not the holy grail of development frameworks and it sure will not make either Java nor Angular go away any time soon. But it shows that there is clearly a better way to create at least 80% of all the apps worked on today. If you can spare a day or two you should give it a chance, perhaps even for a paying customer project. The community is great and the technology simply amazing.