Trying out Electron

I haven't tried out using a new language or tool in a while. I also have a new application in my mind that I'd like to build. So, I thought it might be cool to try out out this thing called electron.

What is Electron? It is a way to write desktop applications using webby languages (like html and javascript). But wait, there's more. You also get access to API's to the native operating system. And supposedly, those API's work in different environments, so you might be able to get the holy grail of writing once and then running everwhere...

So, let's give it a look. You start by asking node package manager to install electron.

npm install electron-prebuilt -g

When I tried this, I got some warnings about having an old version of node. It's been a very long time since I've used node, so that wasn't surprising. So, I uninstalled electron

npm uninstall electron-prebuilt -g

and then hit the keys to update node.

npm cache clean -f 
npm install -g n
sudo n stable

I brought myself up to node-v4.0.0. Then I ran the install for electron again, and it completed with no warnings.

I followed the quick start guide to build a simple hello world application.

Some initial impressions:

• This hello world app was simple and readable, as they all should be.
• The whole stack feels thin and light. In contrast, I remember trying the MEAN framework out and finding it be ridiculously heavy. There were tons of files, it took up a whole lot of space, and there were lots of abstractions. That framework felt so heavy to me. This one just feels so much nicer.
• This hello world getting started app doesn't really do much at all. I'm excited to get something going that does just a bit more.

It was a good start, and I'm excited to continue working with Electron.

A debugging story

Today, I was helping a coworker fix a bug.

At first glance, it didn't seem as if it would be too hard to fix.

The problem was easily reproducible. Sometimes reproducing a bug depends on rare race conditions or odd work environments. The bug we had appeared every time you did a certain sequence of steps. So, we were off to a good start.

I was able to find (and run) a version of the code where the bug didn't exist. So I knew, that somewhere along the way, some discrete code change created this bug. Maybe, all I'd have to do do was go through the list of changes until I found the nefarious one.

This is where things got difficult. Even though I had an old bug-free version and a new buggy version, there were too many changes between then and now. Running a diff between the two version was useless. I tried to undo half of the changes, to try to narrow down where the bug first crept in.
That didn't work so well, as the project failed to build due to all sorts of incompatibilities.

It was like searching for that proverbial needle in a haystack. I felt like I was on a wild goose chase. Everywhere I turned, it was another dead-end.

In the end, I never found the bug. My co-worker ended up figuring it out, before I could.

Even though I didn't find the bug or check in any code, I think it was still a worthwhile experience. I got to think deeply and learn about a piece of code that is related to things I work on. It's always good to have more code-context and knowledge.

I also spent a good deal of time thinking and being confused over some javascript language details. In particular, I thought the cause of our bug was that the code depended on a 'for loop' iterating over a javascript object in a particular order. As it turns out, this was a safe assumption, and not the cause of our bug.

My takeaway from this is the following: if you want an ordered list (when all else is equal), use an array instead of a javascript object. Both may work, but an array has a more intuitive order. Most people wouldn't question the order of an array, and wouldn't waste time trying to verify that iterating over an array in a specific order works or not. Just because the computer (and other language experts) will interpret something correctly does not mean it is the best way to code. Writing code that the average programmer can understand is almost always better.

All in all, this debugging session is typical of many debugging sessions. It's never as easy or as hard as you expect. The bug is often not where you expect it to be. You often feel like you wasted a lot of time.

But if all goes well, you have improved your code base and learned something along the way.

Understanding the Mean JS Stack

I began working with the MEAN.io javascript framework, but due to my ignorance on many fronts, I couldn't quite see how it all worked.

I was trying to figure out how it worked by reading the generated code; experimenting with small code changes to see the effects; and reading documentation from MEAN.io and questions from stack overflow. This didn't get me very far. I was either too deep in the code or too far above in the high level overviews.

The best learning tool for me was this youtube tutorial by Michael Moser. He went through each of the components of a MEAN stack application.

I'm finally starting to get it, I think. Here are two things that I'm starting to see.

Communication between the client and the server is done via http verbs. In your client side angular controller, you can do a few operations with your model like $get, $save, $remove and $update. These correspond to http verbs like get, put, delete, update and so on. It seems so simple now. My misconception was that I could define functions with my own keywords and I'd have to keep this in sync between the client and server.

The node package manager is only used on the server. This means, "npm install whatever" allows you to write
    var whatever = require('whatever');
in server side code. It doesn't work on the client (I think). This again makes sense now that I realized it. Node is your server, so you wouldn't install server side modules onto a client.

Working with new technologies is painful. But things are easier with youtube, tutorials, Q&A sites. After you become an experiment in something it is hard to remember how you felt when you were a newbie and what you didn't quite grok before.

This blog entry is just a reminder to my future self of how little I once understand.

Using ack

While developing my first MEAN.io app, I've found that I need to use grep alot.

The MEAN framework creates lots of files in separate directories. When you have a complicated project that uses a lot of modules and custom packages, keeping things organized is a necessity. However, as a newcomer, I am having a lot of trouble finding code.

To help alleviate the pain of tracking down code within the MEAN framework, I started using ack, which is supposed to be a version of grep that is optimized for programmers. I wonder how many non-programmers use grep? Anyway, here are a few optimizations that I noticed:

• It defaults to recursive searching (very important for frameworks that bury files in folders).
  So you use ack instead of grep -r .
• Results are returned with the search phrase highlighted in colors. However, if you try to pipe your ack results into another unix command like less, you'll lose that formatting.
• Syntax for adding custom flags seems more intuitive.
  Ex: searching for the word "debugger" in js files can be done like this:
  ack debugger --type=js

While ack certainly seems better than grep, I'm reluctant to completely abandon grep. Many times I need to log onto a bare-bones machine where ack might not be installed. On many of those machines, I don't even have access to the other flavors of grep like egrep or fgrep. In those cases, I'd have to remember how to use plain old vanilla grep again.

Mean packages are magic to me

I've been playing around with a Mean.io app for a few days now.

Working within a framework has had its advantages. For example, to set up a new model/view/controller package, I just entered this 1-liner command:

    mean package feeds

This created a nicely structured set of files that just worked. In the main menu of the app, a link is added which you can follow to discover how this new package works.

I wanted to understand how the framework was able to create a new package and how it was connected to the rest of the app, so I started diving into the code. Unfortunately, I couldn't figure it out. I'd account my inability to understand what is going on under the covers to a few factors: 1) I don't have and didn't spend enough time reading. 2) I'm a beginner to this style of Javascript coding. 3) Frameworks try to hide stuff from developers.

I should elaborate on that last point. Frameworks are not evil. Their goal is to abstract away difficult, messy, confusing parts of the code, so that you don't have to re-write or reconfigure those nasty parts. A side effect of this abstraction is that you may be left wondering, how does this all work? (as i am now).

As Arthur C. Clarke said, "Any sufficiently advanced technology is indistinguishable from magic." A lot of the MEAN framework is still magic for me. For now, I'll continue to rely on this magic, continue coding, and come back to it later when some of the magic starts wearing off.

Early reflections on MEAN framework

A few days ago, I initialized my first MEAN.io app.

It's fair to say that I'm a complete new comer to this style of programming. As a newcomer, I'd like to document what I think MEAN is, how it works and my overall impression on it. I'm sure there will be many misconceptions and inaccuracies. Over time, it will be funny to reflect on how lost I once was.

So MEAN is built on top of NodeJS. NodeJS is a server where you can write Javascript code. Why does it matter that you can write Javascript on the server side? The key point is that you program things such that everything is event-driven and everything has a call back.

For a developer like me, this makes the code look a bit gnarly. Instead of executing code in a linear path that matches the code in your text file, different functions are fired off as needed when things are ready.

Of course, the benefit of having event-driven code with callbacks is that the server keeps the UI thread free and clear as much as possible. This makes the application super-responsive. So, making things a bit harder for the developer, but nicer for the user is a good tradeoff.

Now on top of this event-driven server (NodeJS) MEAN uses ExpressJS. I have read that this is a web-framework. Since I'm not a web programmer, this is the component in MEAN that I am most unsure about. For now, I think of it as the plumbing or middle man that helps send messages between the UI screens and the backend server and databases. Is that a correct notion? I'm not sure. Like I said, this feels a little abstract to me.

So, I'll move on to the component I understand the best. MongoDB is a NoSQL database. You insert data and retrieve data as json objects, while they are stored in some binary format. Why is it json? I'm not sure, but it certainly fits into the idea of having this framework be javascript from top to bottom.

One of the nice things about NoSQL databases like Mongo is that you can easily add data to collections without a lot of painful schema designing. Any old json object is ok. The downside is that you can throw anything in, and that leaves model validation up to you.

And the final part of the MEAN.io web framework is AngularJS. AngularJS is a "new" way to do HTML and UI. So far, I've come across at least two new things that AngularJs adds to an HTML web page. Data binding allows you to use a variable directly in HTML code. (I think). Dependency Injection allows you to swap in different dependencies (pieces of code as needed). Did I define those correctly? What are the benefits to these things? I don't know.

I have a feeling that I not only said some dumb things, but that I will inevitably program some dumb things in the near future. Hopefully, I learn and can appreciate all of the magic that occurs within the MEAN framework.

If you are new to MEAN or to programming in general, take heart that your feeling of being lost is shared by me.

Playing with MEAN

I heard about MEAN some time ago, and today I finally installed it and played with it.

There's lots of reasons why I wanted to get into using MEAN. It's all Javascript, which means, it's good Javascript practice for me. Every self-respecting Javascript-developer should try to build at least one Node.js backed app, right?

It calls itself a Fullstack framework. I like the sound of that. I think it means that I'll have to think and learn about all the pieces involved in building a web application. Hopefully, MEAN makes the learning curve a little less steep, yet doesn't hide so much that I depend on the framework too much and never learn anything.

Just to hedge my bets, I also have a simple app that I'd like to build for myself. If all goes well, I'll 1) build an app that I find useful 2) learn. What more can a developer hope for?

And finally - the results of day 1:

The Good

I got the application running on my local machine. I was also able to set up a database on MongoHq and then I deployed the app with Heroku. My app, which is the same as the starting test app, is up on http://pocketfeeder.herokuapp.com/#!/ .

The Dumb

For quite a while, I couldn't figure out how to log into the test app. After an embarrassingly long amount of time, I realized that I just need to register a username first. When trying new things, it's impossible to not feel dumb sometimes; you just have to embrace it.

The Frustrating

Googling things with the term "MEAN" is horrible. If you didn't notice, MEAN is a real/common word, and searching with it gives pretty shoddy results. I know MEAN is a catchy acronym, but searching for a more unique word, perhaps NEMA or something like that, would have made Googling a lot easier. 

The Conclusion

The experience was positive, and I plan on playing with it in the future. So, there is no conclusion, just yet.

Into the unknown with Google App Engine

As mentioned before, I am setting up a cloud back-end for my mobile app.

This has involved writing code in a few different languages.  

• Java - for the android application.
• Python - for writing the Google Endpoints API.
• Javascript/Html/Css - for writing a web client for the endpoints API. 

Working from the tutorials, I have been able to progress without too much issue.  However, I ran into a little bit of confusion when trying to pass around a datetime object.  Specifically, I wanted to:

1. Start with a date / time value. 
2. Pass that to my endpoints api. 
3. Store it in the Google App Engine datastore.

I couldn't find solid documentation on how this works, so it took me a while to figure out. Here are the steps:

1. In javascript code pass in your date time for some field like so:
   { some_field : "2011-12-16T10:00:00.000" }
   The format is Year-Month-Date"T"Hour:Minute:Second.FractionalSeconds
   When I tested, passing in a time zone offset threw an error.
2. In python, when you construct your date time field use:
   from protorpc import message_types
   some_field = message_types.DateTimeField(1, required = True)
   # This is a little bit different from passing other fields which use protorpc.messages
3. Once you have the datetime field, you can use the type ndb.DateTimeProperty in your model that you will insert.

This all works by passing in a string, which gets parsed and converted to a datetime object.  If you didn't want to use protorpc conversion to a datetime object, you can pass in a datetime string that you'd have to encode and decode.

Update - After I set up an Android client to send data to my endpoints api, I got more errors about the datetime having a bad timezone format.  After some trial and error then googling for solutions, I decided that dealing with datetime data wasn't worth the hassle.  I changed the datastore to only save "Long" values.  Then I updated the API to send and receive long values.  Finally, when I get to the UI, I convert the long into date time format for display.  This made things much simpler and cleaner.

Effective Javascript

I've started reading my second "Effective" software book.

The first one I read before was Effective C++, by Scott Meyers,and the one I'm reading now is Effective JavaScript, by David Herman.

I like these books because:

• The books are light, literally!  I hate heavy books.  Heavy books look good in libraries, but are pretty crappy everywhere else.
• The reading is light, figuratively. Each of the points more or less stands alone and is only a few pages long.  This means you can read a couple of pages and still get something out of it.  
• For me, the best part of these books is when I find a specific point that clearly points out that I've been doing something wrong for the last few years.  In these aha moments, I can 'feel' my future code improving.  

Simple way to run javascript code

I was browsing StackOverflow and I came across an unanswered question about a Javascript function.  Before answering the question, I wanted to run the function to make sure I completely understood what was going on.

On Ubuntu

To run a simple Javascript function, in Ubuntu, I followed the advice in this earthviaradio blog post and installed node.js. On Ubuntu, here is what I did.

• Installed node.js.

sudo apt-get install nodejs

• Wrote a test function. (I saved the file as test.js).

var sys=require("util");
sys.puts("This is a test javascript file.  Hello world!");

• Ran the function.  ( You should see the output in the console terminal ).

  node test.js

On Mac

If you already have homebrew, you can install node.js with this command.
brew install node
Then, you can run it in the same way as I noted above.

I've heard about nodejs a while ago, but I never spent any time to learn what it was.  This looks like a pretty cool resource to learn about nodejs:
http://www.hongkiat.com/blog/node-js-server-side-javascript/