Eric Terpstra

On web development. Mostly.

Show menu Hide menu

Tagcloud9

The $50 JavaScript Dev. Server – Node .8, Yeoman, and Cloud9 on ARM

October 6, 2012 / / 8 Comments

MK802 II

I recently bought a Mini PC. It’s one of those ‘Android on a stick‘ devices from China, that cost anywhere from $50 – $90. This one in particular is a . It’s got an Allwinner A10 System on a Chip (ARM Cortex-A8, Mali400 Gfx), 1GB DDR3, and a 4GB of onboard storage with Android 4.0 pre-installed. It came with some USB adapters and a nice box, all for $55 shipped. The best part is, you can slip in a micro SD card with an ARM compatible Linux image, and it will boot!

Linaro 12.07

Miniand.com has several SD card images ready to download for this particular device, and I settled on a custom build of Linaro. It’s an Ubuntu 12.04 derivative with support for ARM devices. The custom build on Miniand has Mali 400 gfx drivers, and apparently a bunch of ARM related kernel optimizations and drivers for the MK802.

It was super easy to install – just download, unzip, and write the image to the card using a single dd command.
File: linaro-alip-armhf-t4.7z
Commands:

dd if=/dev/zero of=/dev/sdz bs=1M count=16 conv=fsync
dd if=linaro-alip-armhf-t2.img of=/dev/sdz bs=16k conv=fsync

NodeJS 0.8.11 and Yeoman

With the MK802’s primary function being a web development sever, my first task after getting the OS up and running was installing Yeoman. Linaro includes apt-get, so the installation process was mostly identical to what I have outlined in this earlier post. There were a couple key differences, though, that nearly derailed the installation.

Because most default build configs are set up for x86 systems, I had to take an alternate route with Git, NodeJS and PhantomJS due to the ARM based architecture of the MK802. For Git and Phantom, I went with the pre-compiled packages available in the apt repository. I won’t get bleeding edge versions, but from what I can tell so far, the repo versions work just fine.

Except Node. The apt repository installs NodeJS 0.6, and does not make 0.8 available. Problem is, Yeoman requires 0.8, and the default NodeJS 0.8.11 build instructions fail on the MK802. Luckily, there’s a pretty solid community of very-tiny-pc enthusiasts, and I was able to find a solution on . All that’s needed is adding a couple lines to a file before building.

Open up /deps/v8/build/common.gypi and change:

{
  'variables': {
    'use_system_v8%': 0,
    'msvs_use_common_release': 0,
    ...

to this:

{
  'variables': {
    'armv7%':'1',
    'arm_neon%':'1',
    'use_system_v8%': 0,
    'msvs_use_common_release': 0,
    ....

Compiling NodeJS took about an hour on the MK802. I think there were some additional arguments for the make command, but unfortunately I didn’t write those down. They probably weren’t that important anyway. Sorry :P

Cloud9

Here’s where things got really hairy. Cloud9 just did not want to cooperate. In retrospect, it really only came down to one (maybe two) issues, but working through the entire installation took the better part of my Saturday.

It all started with the ‘sm’ module from npm. Apparently ‘sm’ is the smallmint package manager used by Cloud9 to keep its own node packages separate from those of npm. Installing sm via npm went OK, but downloading the Cloud9 source with sm failed. I had to use git instead.

Download and install Cloud9:

git clone https://github.com/ajaxorg/cloud9.git cloud9
cd cloud9
sm install

A ton of scripts and package installations executed, and I eventually ended up with an error like this:

Checking for program g++ or c++          : /usr/bin/g++
Checking for program cpp                 : /usr/bin/cpp
Checking for program ar                  : /usr/bin/ar
Checking for program ranlib              : /usr/bin/ranlib
Checking for g++                         : ok  
Checking for node path                   : not found
Checking for node prefix                 : ok /usr/local
'configure' finished successfully (0.970s)
Waf: Entering directory `/home/root/o3/build'
[1/3] cxx: hosts/node-o3/sh_node.cc -> build/default/hosts/node-o3/sh_node_1.o
16:01:40 runner system command -> ['/usr/bin/g++', '-g', '-O3', '-msse2', '-ffast-math', '-fPIC', '-DPIC', '-D_LARGEFILE_SOURCE', '-D_FILE_OFFSET_BITS=64', '-D_GNU_SOURCE', '-DEV_MULTIPLICITY=0', '-Idefault/include', '-I../include', '-Idefault/hosts', '-I../hosts', '-Idefault/modules', '-I../modules', '-Idefault/deps', '-I../deps', '-I/usr/local/include/node', '../hosts/node-o3/sh_node.cc', '-c', '-o', 'default/hosts/node-o3/sh_node_1.o']
cc1plus: error: unrecognized command line option "-msse2"

Luckily, I discovered a related issue reported on GitHub. The libxml submodule is the offending culprit. The module depends on Ajax.org’s o3 project, which cannot compile on ARM as-is. The problem has something to do with ‘msse2’ not being present on ARM v7 CPUs. I’m not entirely sure what that means, but fortunately, someone has figured out how to modify o3 and libxml so they will build properly.

I checked out a customized fork of libxml into cloud9/node_modules/ and ran the build script (build.sh). Then I re-ran sm install for Cloud9 and everything went off without a hitch.

Thanks to Ian Corbitt’s blog and libxml fork. Below are the useful commands that got things going for me (start from the cloud9 directory):

cd node_modules
git clone --recursive git://github.com/iancorbitt/node-libxml.git libxml
cd libxml
./build.sh

After the installation was complete, I could start Cloud9 with ./bin/cloud9.sh -w /var/www/myProject. Then firing up a web browser and going to localhost:3131 brought me to the IDE.

Access Cloud9 Remotely

Running a web browser on the MK802 is painfully slow, and I don’t always have physical access to it anyway. I would much rather use my laptop or desktop to run the Cloud9 client. The first time I attempted to open Cloud9 from a remote computer, I was very dissappointed. All I got was a 503 error with no information. Turns out Ubuntu does not allow connections willy-nilly on random ports.

Enter Apache and reverse proxying. I never knew about this before, but I’m glad I ran across it. With a simple VirtualHost file entry, Apache can accept requests for specified domains & ports, and forward them elsewhere. So in my remote browser, I can call the IP address or domain alias of the Cloud9 server over port 80, and Apache will forward that requests to localhost:3131. Great!

All that’s needed are a couple Apache mods enabled

sudo a2enmod proxy_http
sudo a2enmod proxy
sudo services apache2 restart

Then create an empty file in /etc/apache2/sites-enabled, fill it with the information below, and restart Apache:

<VirtualHost *:80>
    ServerName c9.mk802
    ProxyPreserveHost On
    ProxyPass / http://localhost:3131/
    ProxyPassReverse / http://localhost:3131/
</VirtualHost>

Then in the /etc/hosts file of my remote computer (where I will be using Cloud9), I add the entry: c9.mk802 192.168.1.xxx (where xxx is the last 3 digits of my mk802 IP address).

Opening up Chrome and tapping http://c9.mk802 into the address bar brought up the Cloud9 interface running on my tiny PC in another room. Excellent!

Except I couldn’t type anything or create any new files. Bummer :(

Cloud9 had started in Read-Only mode. After a bunch of trial and error, I finally found some advice stating that local installations of cloud9 would only be fully accessible to a single user via the host specified in cloud9/configs/default.js.

Open default.js and change all instances of “localhost” to “0.0.0.0”. Restart Cloud9, and all should be good and merry. Just make sure that Cloud9 is safely tucked away, as this really is not very secure.

It was pretty satisfying being able to create a fully functional development environment with two commands:

/var/www/myProject/yeoman init angular
~/Applications/cloud9/bin/cloud9.bin -w /var/www/myProject/

Now whether standing at my beefy desktop, or lounging with my li’l notebook, I can access the same codebase with the same IDE. Pretty nifty!

Code HTML5 in the Cloud with StackMob, Cloud9 and GitHub

May 15, 2012 / / 0 Comments

In my recent efforts to learn more about modern Javascript I’ve been looking around at different Backend-as-a-Service (BaaS) companies.  They presumably would provide a dead simple server option for whatever I’m working on so I can focus all my attention on the front-end.  I signed up for a number of different accounts to explore the feature set and documentation, and settled on StackMob due to the perceived ease of use, and the fact that their Javascript SDK is built on backbone.js (another current interest of mine).  After creating (and deleting) some dummy apps to get a feel for things, I eventually got a very simple, but usable, database put together.  What is interesting about StackMob is that they will host your front-end app, as well as provide the back-end.  Not only that, but you deploy to your front-end development server directly from GitHub.  It’s a pretty slick system.  And as soon as I realized that GitHub projects can be edited via the Cloud9 IDE, I had a nice little dev environment fully hosted in the cloud.

I’m not saying this combination is at all practical for serious use, but it could be useful in a pinch, or when monkeying around with some prototypes while using multiple computers.  Plus Cloud9 is just fun to look at, and this provided a good excuse to use it for real once in a while.  Oh, and it’s all free (as in beer).

To get started, sign up for a Stackmob account, and a GitHub account.  Both sites have amazing documentation for getting up-and-running on their respective services.  GitHub has very detailed instructions for setting up your account with a git client on Linux, OS X, and Windows.  If you haven’t already, follow those instructions, but do not yet create a repository.

Getting started in StackMob is just as easy.  Sign up for an account, then create an app.  Every app generated by StackMob starts with a Users table, which is enough for now.  Grab the Javascript SDK from the Get your SDK page, and follow the setup instructions in the Setup your JS SDK Dev Environment section.  Step 2 is optional if you just want to edit your app in the Cloud9 IDE.  Otherwise make sure you have Ruby installed and give it a try.  In Step 3, you will be instructed to create a GitHub repository. Do that.  While you are logged into GitHub, also set up automatic fetching, so your code will get deployed to your development server every time you push to GitHub.  The Hosting Your HTML5 App… page has all the necessary instructions. Make sure you have committed and pushed some files (likely the StackMob SDK) to your GitHub repository.

By this point, you can edit files locally, push the files to GitHub, and see your changes reflected online.  To start editing online, go to c9.io and log in using your GitHub account.  When you reach your dashboard, you should see a big green button that says Create New Project in the left-hand sidebar, as well as a section in the sidebar labeled Projects on GitHub.  The URL for your dashboard is http://c9.io/yourgithubusername.  If you cannot see your GitHub project, click the refresh button in the far lower left corner of the screen.  Select your StackMob GitHub project from the sidebar menu, and click Clone to Edit.  In the modal window, select Shared Development Server and click Checkout. It will take a minute, but your project should be created and listed under My Projects. Select your project and click Start Editing.  You should be taken to the editor window where you can open and edit your project files.  Take a few minutes to admire the lovely UI and its many features, and edit a file or two.

To test out your edits, open the console window (Menu: Windows > Console ) and run your usual git commands – e.g. git commit -a -m “msg” and git push. The Cloud9 git client will push your changes to your GitHub master branch, and those changes will then propogate almost immediately to your hosted StackMob application.

This is creating a web application in the cloud.  Development-in-the-cloud is not quite cut out for daily use, but if you really need to try out some code or get in a quick change from any computer (or tablet, or phone), this is a nifty way to do it.

 

© 2018 Eric Terpstra

Theme by Anders Norén — Up ↑