Meanio version 0.4.0 does not work

I tried to upgrade to the new version of Mean.io, version 0.4.0. As of this writing, it has been a complete failure.

I began by trying to upgrade one of my existing applications. Since I did not touch any of the core components provided by Mean, I hoped the upgrade would be easy. 

Using git, I pulled in the latest code. I had to do some manual merging, but it looked pretty straightforward, so I still felt optimistic. I then used npm install to install everything. Then I ran grunt to start the server. No errors were given, so things were looking good.

However, when I try to open the web app on my local host, it stalls and I don't see anything happening. I spent a millisecond trying to debug what the problem was, but I realized I'd never make any progress. There were too many diffs due to the upgrade. And I wasn't going to spend time trying to figure things out. 

Instead, I tried to install a fresh new mean app. I used the basic commands:
  sudo npm install -g meanio

  mean init Mean.init.demo

  npm install

I got a slew of errors, and I gave up.

It's probably something I did. It almost always is. 

Maybe I should work harder to debug this, but I thought the framework was supposed to make my life easier. 

I'll try again next week. Onto something else.

Update
Following the debugging steps in http://enginx.com/blog/mean-io-v0-4-released-stay-synced/ , I was able to get my app using Mean 0.4.0 to work. 

Tiny versus Somm

I saw two movies over the weekend. Tiny - a movie about living small and Somm - a movie about sommeliers trying to pass the Master Sommelier exam. I like watching people putting forth great efforts, so I liked both movies.

Each movie explains the journey of people trying to achieve something. In Tiny, a couple attempts to build a house from scratch. In Somm, several sommeliers are trying to pass an extremely difficult exam.

Each adventure has clear rewards. Becoming a Master Sommelier opens career doors and subsequent financial gains. Building a tiny functional house gives you an economical place to live. 

The perception of being a Master Sommelier is different from building and living in a tiny house. A Master Sommelier is held in high regard. Owners of tiny houses are often met with ridicule and have to defend and explain their living choices to others.

Another difference in the two adventures was the way the participants viewed the journey. Tiny house builders seemed to appreciate the journey of building their houses. Whereas the Master Sommelier candidates viewed studying for the exam as a painful means to an end. In the Tiny House movie, a couple who was thinking of going separate ways was brought closer together by the process of building the house. But the journey of becoming a Master Sommelier put huge strains on the personal relationships of each candidate. 

I'm one of those people who think the journey is as important as the ending. I also prefer beer to wine, and my smelling and test sensitivity is unrefined. So, the story of the tiny house resonated with me a bit more than the one about sommeliers. But that's just my opinion. Go and watch and decide for yourself!

Related Posts

http://programmerdays.blogspot.com/2014/03/a-programmers-review-of-jiro-dreams-of.html

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.

Refactoring in Android Studio

I'm a bit of a dinosaur. My preferred development environment is unix. It's fast. I know how to use all of the tools I need to use. It's on both my home and work computers.

Nevertheless, I have been trying to evolve. I've been doing all of my Android development using Android Studio. It has been going well. I love the code completion. It's the only way to visually add widgets to an app and see the xml updates in real time.

Recently, I ran into a snag. I tried to use the "Refactor" feature in Android Studio to rename one of my classes from "Broadcast_receiver_handler" to "BroadcastReceiverHandler". The file and class name were updated and references seemed to be as well. Since it worked so well, I went on to refactor a bunch of other classes.

Today, while testing the app, I noticed some things weren't working so well. Without going into much detail, I found out that there was one place where the name for my Broadcast_receiver_handler was not updated, the AndroidManifest.xml.

One factor that made debugging more difficult was that Android Studio deleted and added files during the refactor process. I would have rather it did a "git mv" so that diff's would work better.

These are minor issues. I'll continue using Android Studio. It's only a 'beta' release now, so it should improve over time. But for some things, like global file and text manipulation as well as git commands, I will stick with a unix terminal.

Pros and cons of Unit Tests

I did a code review for a co-worker today.
I suggested that he refactor his code to make unit tests possible and then to add unit tests.

He argued against adding the tests. Here are some of his arguments against unit testing along with my responses.

Against Unit Testing	Responses.
You're making the code more complex! You want me to add factories and abstract classes and so on, just so things are more testable. You're asking me to rewrite a lot. I don't want to re-write code that already works.	This is true. Some things got more complex. But see, writing code to become more testable, has the side effect of making the code more modular. And making code more modular is good.
You have to learn a lot to get going. New frameworks, new tools, new concepts. All of these new things make things more confusing and complex. This might be a fad that we forget about in a month or two.	Learning is part of the job of being a programmer. It's one of my favorite parts. Maybe the framework and tools we use for testing will change over time. But you can't argue that the concepts are a waste to learn about. Even if you don't want to use the concepts, it's cool to understand and learn. No?
Writing test code is a pain in the neck. You are doubling my work load with no increase in production!	I disagree. Writing test code is fun.
I've already tested it. Trust me, it works. Why write a test?	Writing unit tests allow someone else (even a dumb machine) to test your code. Otherwise, if I have to change your code, I'll have to stop by your desk and you'll have to tell me about it. Isn't that a waste of your time?

Android Testing

For the last few days, I have been adding more tests to my Android projects. During this time, I have come to the conclusion that:

Unit tests are impossible in Android.

Maybe I should qualify that statement a little bit. Here's something that is more accurate:

For me, setting up unit tests in Android is so difficult, and running them is so slow, and learning and integrating external tools/code is so arduous, that it doesn't seem worth it to hack together a true set of unit tests.

In the mean time, here are the things I am doing in regards to Android testing.

1. Sticking with the emulator
I am running all of my tests and the app in the emulator or an attached physical device. The downside of this is that things are slow. I briefly tried to use Robotium, a highly regarded test framework that helps run your tests outside of the emulator. Maybe I will try again in the future. For now, I am wary of investing more time to hunt down external tools to get this to work.

2. Using the simplest test case that is needed.
I can't seem to keep track of all the test case classes. Here are the ones I use in order of increasing complexity and dependency on Android APIs:

TestCase > AndroidTestCase > ActivityUnitTestCase > ActivityInstrumentationTestCase.

For any given class that I'd like to test, I try to use the simplest test case that works. It seems like this would be the best way to isolate issues and keep things running as fast as possible.

3. Refactoring my code
In the hope of making each class as simple as possible, I have been refactoring my code. In the least, I have been adding comments to say what dependencies a given class has which tells me which test case class is required.

4. Waiting.
I started developing an Android App just to see how things work. It's a learning adventure, not a business one. This is why I can afford to simply wait for the product to improve.

In the future, I may upgrade my machine, which will speed things up. Google may add more libraries, update Android Studio or modify the testing framework to make things easier.

Google permissions

This morning, the Google Search app on my Android phone had an update. Upon reviewing the update, I saw that the app wanted access to just about everything.

I tried to take a screenshot of the things it wanted access to, but it wouldn't fit in one screen. In addition to the picture, it wanted access to "Device ID & call information" and "Other". 

It seems like they asked for permission to access just about everything on my phone. They will know who I am "Identity", where I've been "Location", who I've been in touch with "SMS" and "Phone", what I look like "Camera", and they can send it all back to the cloud "Wi-Fi Connection". 

If it were any other company, I wouldn't install an app that requires this many permissions. But they are Google, and I've already gotten used to the idea.

At what point does Google Search become spyware?

Disclaimer

After I took the screenshot, I, obviously, accepted the conditions and updated the app. 

Related Post

http://programmerdays.blogspot.com/2014/02/am-i-spy.html