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.