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.

Android Studio - review after a few months

I've been using Android Studio for a few months now, and I've been enjoying the experience. Here are a few things that I have liked about this IDE.

I love Vim, and IdeaVim brings Vim to Android Studio as a plugin. I'm not sure how long I can tolerate using any IDE if it doesn't have Vim support. This isn't an indictment on any IDE that doesn't support Vim, instead, it's more of an handicap of mine.

A terminal is available as one of the windows in the IDE. I use it for doing quick unix commands like grep and git log. Screen real estate is always scarce, and having it inside the IDE is just a little bit tidier for me.

Viewing a layout in "Design" mode is great. You can drag and drop from a selection of Android widgets, which automatically updates the the layout xml. Conversely, if you update the xml layout file, you can see the changes in the layout in the design editor. This allows you to quickly browse through different widgets without having to manually type in names, and to see changes in real time.

Android studio allows you to create multiple run configurations. For any project, I create one configuration for running the app and one configuration for testing the app. I suppose it is just philosophical, but I like a single project to hold all of the stuff needed for running and testing.

One downside of moving from Eclipse to Android Studio is that it seems like an irreversible change. Maybe if you are an expert in migrating files, you can easily jump back and forth between them, but it seems like a one-way street to me.

After 6 months of usage, I have like using Android Studio. We'll see how I feel about it over some more time ...

Related Posts:

Android Studio - Preview of Future

Taking notes

In this post, I'll review the tools I use for taking notes. This is what I have been using for the last few months. It's been working for me, maybe it will work for you.

I start with Google Keep on my phone. With the on-screen widget, this app is the fastest thing for jotting down a note. It seamlessly syncs to a cloud backend without having to press save or send. Writing a note down as quickly and easily as possible is probably the most important thing for me. If it's too hard or slow to jot down a note, I will inevitably: 1) forget what I wanted to note, 2) forget what I was doing before I was writing the note, or 3) give up on writing down notes. 

 

With that said, another "killer" feature of Google Keep is the ability to set reminders. This feature transforms Google Keep into a light-weight appointment calendar. Another nice feature is the ability to archive notes. This helps me keep the most important notes in the foreground, while letting old notes fade into the background. I often combine these two features to push a thought into the background (archive a note), but knowing that I will revisit the subject later (by setting a reminder).

At the end of every day, I transition my notes in Google Keep to files in my Dropbox folder. I do this by opening the web version of Google Keep and using the terminal to view my local Dropbox folder. I review notes in Google Keep and update corresponding files in Dropbox. Where Google Keep is used for the more recent things that were on my mind, I use the files in Dropbox for more long term notes. Of course, the nice thing with Dropbox is that I edit local files that I know are being backed up in the cloud (all auto-magically). 

The last thing that I haven't found a good solution for is an app for sharing notes. Trello seems like the leading candidate, but I haven't used it enough, with others, to be sure. 

Display link issues

Today, I am giving a status report on my experience connecting my Macbook Air (running OS Mavericks) to a Anker USB hub with usb to display link adapters to 2 external Dell U2410. 

See the image for a schematic of the major pieces. 

DisplayLink has issued warnings that things aren't perfect: "Unfortunately there are still issues using multiple DisplayLink displays on OS X 10.9. A summary of these known issues can be found in this article."

My experience has been random. 

Sometimes, it works perfectly. 

Sometimes, only one of the external monitors get a signal. 

Sometimes, things work fine and then one of the monitors just goes blank. 

I think things work better if I start with my laptop completely OFF, and things work a bit worse if I start from a laptop that was just in Sleep Mode. 

I'm living with it, but I hope things improve in the next version of Mac (OS Yosemite).

*Update* - July 4, 2015 - I tried to use this set up today, and it didn't work. The external monitors were recognized, but they would show a blank screen. I tried restarting, unplugging, etc... but it was to no avail. I finally got it to work by reducing the resolution of each monitor several notches worse than their optimal settings.