Using jQuery UI controls in MeteorJS

If you want to work with jQuery controls or third party controls for that matter, you can use them with single caveat. You need to have a package available for it to use in the Meteor application. I found an excellent blog on this here. So I am not going to repeat the whole thing here. But it was missing one important thing, you need to install the jQuery UI package first.

mrt add jQuery-UI


mrt add jquery-ui-bootstrap

Also if you want to create a package, here is great links

User management in Meteor is so easy

I was pleasantly surprised how Meteor makes the developers life so easy. The official documentation for data security is available at

When building web applications you might want to authorize users before using the application to the fullest extend. By default when you create the meteor application, any changes that happens at client and server will be seen by everyone else. By default, auto publish is enabled. When you go to production, you might not want everyone to see everyone’s changes. You want to authenticate and authorize users. This is standard task in any web applications. You end up coding once and then maintaining the code. Most of the time you create your own user tables and then perform email verification etc., As you can imagine, this is repeated task when developing new application and has clear pattern. Meteor framework team understood this pattern and provided you with easy to use solution. So in my code, with just 5 or 6 line of code, now I am able to provide login using,

  1. Creating user name and password.
  2. Creating user id with email and password.
  3. Twitter
  4. Facebook
  5. Google.

This makes developer life so easy. In the HTML all you have to add the new template provided by Meteor like the following

<div style="float: right; margin-right: 20px;"> {{> loginButtons}} </div>

Now this alone will not get you going, you need to add the meteor packages for making it work. So in the project terminal, add the following based on your requirement

By default you need to add following for option (1) and (2)

meteor add accounts-base
meteor add accounts-password
meteor add email
meteor add accounts-ui

Once you add all the above four packages, you will get Sign in option show up in the main page like the following


Now to make it work, you need to say, do you want to create users by just user id and password or email and password. This configuration need to happen in account ui configuration. You put the following code in client side javascript code

   passwordSignupFields: 'USERNAME_AND_OPTIONAL_EMAIL'

Lets suppose you did add twitter/google/facebook by adding those packages in the console with following command

meteor add accounts-twitter
meteor add accounts-google
meteor add accounts-facebook

then your sign in screen will look like the following


Now, if you you want to authenticate using facebook or twitter, you need to register you all application with those identity providers before you can allow the users to authenticate.

But overall, with few lines of code, I got my user authentication completed and now I can focus on my actual application development.

Getting Started with Meteor Javascript Framework– A Review

As you might have seen from my last post I started poking around Meteor. Meteor has decent getting started guide and videos. I was looking for some decent place for me to start as a total newbie and found Getting Started with Meteor Javascript Framework by Packt publishing. I went through the sample chapter and looked interesting so I ended up buying the book and read the whole book in single sitting (5 hours).  I am going to use this blog to write about my experience with this book as I started learning Meteor.

For starters, there are very few items specific to 0.8 changes are missing in the book Like Handlebar to Blaze, {{login to {{> login etc., nothing major but I am sure they will update Errata with those changes soon. Since the framework is still not in production there might be more changes coming along the way. Also if you are going to try in Windows, I am not sure it is going to work, I tried few times but ended up switching to Mac and then everything just worked. I used webstorm as the editor. Since I have bee using it to develop my Angualr Apps. Back to the book, Version specific things aside, my over all experience with the book is outstanding. Let me tell you why.

The whole book is arranged in such a way, you learn the basic building blocks progressively and then put them together to build a decent application. I would strongly recommend learn by doing and this book is written with that intention. Fire up your mac and start reading the book, by the time you finish chapter 4, you will have a working application build with Meteor and as a side effect now you understand the fundamentals of Meteor.

This book is short and sweet. This does not go into the internal working of Meteor that much, rather focus on as a developer how do you go about building an application. That is exactly what I expected from this book. This book has only 7 chapters and that’s all you need to learn and get your self running in Meteor, each chapter is well thought out and has an excellent flow. On the side note, it is also testament to the beauty of Meteor framework, it is easy to learn and hit the ground running fast.

The whole book was like a conversation between the author and the reader. The first chapter get to you setup Meteor and create simple application to showcase the components of Meteor and get you acquainted with their basic structure. It shows, with simple example, where does the view, controller and model go.

From chapter 2 to chapter 4, author walks us through building Lending library application step by step. This where he explains the meat of Meteor why it shines and why Meteor could change the way we think about web development altogether.  One of the core feature or its shining light is ‘Reactive Programming’.  In this model, client and server are aware of data and meteor automatically pushes the model changes to client and server with out us writing ton of code and learning another new protocol. It just happen. Like I said, since it is one of the core things of Meteor, the author explains this idea very clearly with very less code so that as a reader we can appreciate the power with out walking through too much code.

Chapter 3 started out with some theory on MVC, MVVM to explain how Meteor fit into MVVM model. Even though it make sense, I was not completely sold on the idea Meter falls in to MV* pattern. When I think about MVVM (Silverlight/Angular) though, VM was pure code and which is not aware of anything about View. The underlying silverlight framework glued the view model properties to view. But in Meteor, when I look at the controller code, there was so much of view bleeding to it. Again, I am still a newbie so there might be better way to do it so that view is totally isolated from controller. But do not skip this theory part since the section titled ‘Cached and Synchronized data’ is crucial to understand how Meteor keep the data in sync with client and server.

Chapter 4 is where we put lot of meat to the code to make it like an decent application. This chapter covers lot of ground and I did not like the flow on this chapter though. This is the only chapter I had some heartburn. In this chapter as you make changes, you have to wait till end of the chapter to see the fruit of your labor. So I ended skipping the author’s flow and start implementing view/controller at small yet complete so that I can see I am making progress. Even then I was making lot of mistakes (like missing . or _ or missing semi colons) so if I was going to put all together and then debug the code, it would have been miserable. Oh by the way, I was writing every line of code instead of copy pasting. I did on purpose so that I get used to what ad why am I typing? So as I said before, I jumped between this chapter to identify each feature associated in template/model and javascript code so that I can see my progress and debug the code in small chunks.

By the time you come to chapter 5, you already have a decent size application running. From here on out, next three chapters are required for you to understand, as we start building public facing website, how do we control our ‘Reactive Programming’ so that only the users who need to see the changes see the changes and also how to fine tune the data flow between client and server. They were explained very well and stayed at a level it made perfect sense. Also the additional links in the book for anyone interested to learn more also helped.

Chapter 6 and 7 closes the book explaining more about how to setup your project directory structure and how to deploy your application. Meteor deployment was really pleasant surprise. Author explained the three models how to deploy and what are the things to watch out for really helped as well.

Overall I really enjoyed the book and in 5 hours I was able to develop a good application and learned the basic fundamentals of Meteor and starting to love the new way to develop web application. The book highlighted the core features very well and as I developed the application, I really started to appreciate the simplicity of Meteor.

On the flip side, I thought one very important aspect was missing in the whole book. There was no mention of how to go about doing TDD or to write end to end testing. As a software developer I start to enjoy TDD and if it is not supported as first class citizen in the framework, we will be missing out a lot. I did search and found couple of videos on the testing but did not watch them yet.

But over all it is an great book for anyone new coming into Meteor, it is worth the money and time well spend.  I really looking forward to develop more application in Meteor.

Starting out in Meteor

Its been a long time, I blogged, I have been very busy at work, learning and doing lot of work on software architecture area like Domain Modeling and understanding overall structure of our application using Struct 101 and other goodies.

I am still learning and developing application on both Angular and CujoJS when I get time.

I am still enjoying cujoJS but for a change and to learn something new I started looking at Meteor framework. By the way, I recommend using Mac to learn Meteor purely because of the support.

As I was progressing through example, I did run into small problems but they are important ones so I though I will document them here for my future reference.

1. Make sure you have mongodb installed.

npm install –g mongodb

2. When you starting out to use Mangodb to get the collection, the collection definition must be outside isClient check like the following

People = new Meteor.Collection(“People”);
if (Meteor.isClient) {
    Template.People.PeopleCollection = function() {
            return People.find();

** Two things to watch out here.

** See there is no var infront of People in collection definition on line (1)

** Make sure the collection definition is outside if condition so that it runs on client and server.

There are ton of great videos, tutorials out there, as I go through them I will try to collect them and put them in a list.

angular.js vs cujoJS

I have been using Angular for a while.Few of my friends strongly recommended me to look at the cujoJS. I would never say I am good at Angular, I am still learning and long way to go. On the other hand, I have no idea how cujoJS works. Only exposure I have with respect to cujoJS is that I sat in a presentation. So as you can see I am in no way to make the decision on one over other that quick. I am planning to use my blog site to go over simple example and compare and contract each on of them from these two framework perspective. Now comes the other question why cujoJS why not ember or knockout. Unfortunately, I never spend much on that either. I started using Angular and I was hooked. As a Silverlight programmer I found it so easy to transition into Angular world than the other two. If any of you have any comments on comparing those three or any other frameworks, let me know, I am happy to add them to my list as I start work on cujoJS.

Angular.js and cujoJS both are SPA development framework. One of the main difference I see when I look at both the framework, Angular JS is all encompassing (IoC, Binding, etc.,) framework. I know that is not fully true. In Angular you can use other libraries as well. But compare to cujoJS, Angular looks like it is trying to do lot more things internally while in cujoJS each one has its own JavaScript library. What it means is that, if I don’t like how the binding is done, I could replace cola with something else, well I don’t know if there is another one, but the bottom line is that, these important components are separated out. So you are not married to one huge framework. Component models has its own pros and cons but pros outweigh cons so in that perspective, I think cujoJS implementation is better. That is been said, when you are working in enterprise development, there are couple of important things we need think about, we will have varying level of expertise in the team and we need to make sure, we use less number of components in the development tools set from that aspect Angular is better but then again, it is not a big win for Angular though.

Please disagree with me and I learn from you as well.

  angular.js cujoJS
Component Model   X

Always write unit tests from get go

‘Always write unit tests from get go’, this is nothing new. If you are following TDD pattern then it is the default style. But when we develop an application which need to be delivered in a short time frame, if you do not have TDD background and testing is not the first class citizen in the programming tool set, before you know it, product will be delivered with no tests. This is always the case if there is no one bugging you about unit tests. 

Let’s talk about building a brand new application. Most of the time, when we develop a brand new application, our application will be very simple compared to what we end up with in three or four years down the road. Most of the time, our initial applications are very simple, which does nothing but bring data from back end and display it in the front end. Nothing much to it. When you have four or five line methods, why would you want to write unit test for it? It is a very bad assumption. You might start with this four line and as the application start growing these four lines might end up becoming twenty to forty lines (of course you might end up re factoring), you increased the complexity 10 fold. Now try to write unit tests and you will be stuck. There might some dependency that need to be removed and need to re factor the code so that we could even start unit testing. Now, unit testing becomes an explicit task which is going to consume time and effort. If you would have written the unit tests as part of initial development then as we add more code to it, our tests will also evolve and when we get to this twenty or forty line of code, there will be plenty of supporting unit tests for it. When someone is trying to modify this forty line method, it has good unit test to back them up so that they know they are not breaking any existing code.

One of the very important benefit of the unit testing which most of the people forget is that it can show you your design flaws very early on. If you are not following SOLID pattern then writing testing is little difficult. We always need to develop application in a loosely coupled model. All the dependencies should be injected into the code, which lends itself to a very maintainable software. If you were writing unit tests early on and if you were stuck on a place where you cannot do unit test, then you have a hard dependency problem or breaking one of the SOLID pattern. Since this problem identified early on, we can change the design to make it testable, we also reduced the complexity during the course of re-factoring. This is a great benefit of adding unit tests in the green field development. Write unit test for any and all the public methods, someone will thank you when they have to add a new feature to the same code after four years.

I hear people say, ‘I will come back and re factor the code and add unit tests’. Trust me when I say this, you are not coming back to re factor, you will have some other better things to do and never will have time to do it. Even if you were to come back to the code, how are you going to justify the task that could have been done in the first time itself? So here is a rule of thumb, if you ever say, ‘ I will come back to code to do something’, then you are knowingly adding tech debt to the code. Don’t just say it, do it. Do the re-factoring add unit tests, take extra effort and do it.  If it take some extra time to do it, I will ask you to talk to the managers and tell them the benefit of the re-factoring. If the managers do not understand (I really hope it is not the case), reach out to the technology leaders of your team. They will help you make the case.

Testing in Angular World


This has been a hot topic for me lately. I covered testing AngularJS in couple of blogs but over the time I noticed people who are coming from .Net world who are not used to TDD model still fall back to the old style development that is without tests or tests have been added after the fact. I think, either of the approach is totally wrong. Testing is first class citizens in AngularJS and we should treat them that way. I want to go over couple of argument I got when I asked them about why there are no tests or not following TDD and lets discuss about it. I will try to answer the best of ability.

We are still learning AngularJS so I can’t write unit tests.

Ok it seems very valid point. I would strongly recommend understand and learn how to do tests first. Testing in Angular is simple and straight forward. I am going to focus on testing in the coming blogs. Angular support both unit testing and end to end testing (e2e) testing. It is easy to learn and get going fast. First understand AngularJS concepts like $scope, $http and others then learn how to mock them, the rest is nothing but writing simple tests. The bottom line, if you are trying to learn AngularJS, learn testing along with basic concepts and then go into the details of AngularJS features.

Now going back point made, if you want to do something and you do not know how to do it in AngularJS then you can not write test for it. Well that is not 100% true. If you are following TDD model, then once you get the requirement that you are trying write code for, you are suppose to write the test first. Now that you already know how to write test, go ahead and write the test first and then try to do the implementation. When you are trying to implement, you may run into problems, then modify the tests as you make progress to fit the model you are writing. This is true in end to end testing as well (e2e), you might have end to end test against a form and as you learn you realize that you need data table, change the e2e test for it. But write the test first. It will help. Again, with the tests, even when you are learning, it catch the unexpected errors that you might make when experimenting with new concepts.

We can’t write tests because there is no logic in the code.

Excellent point, AngularJS is used to develop client side code. So if you are developing application properly, client side should be as dumb as possible. So in theory, we will have MVC pattern applied to both client side and server side. So all the complex business logic will be in the server side controller. Since you do not have complicated logic at client side, client side code should be very simple. Normally when we start out the client side code will be very simple, we might make a webapi call to get some data, bind them to the variables and that is it. So for that we do not need any tests. Trust me when I say this, that is how all the projects start. Always they are very simple in the beginning and as project start to grow, you will have more complex logic in it and at that time, it will be difficult to add test to it.

In the above scenario, my suggestion is to add unit tests to all the functions you might add to client side code, even if it is single line assignment statement. You will also agree, it is easy to write test cases of single line assignment statement, so go ahead and add the tests for it. It might seem silly, but now when you run the test, you have code coverage for the functions you have written. The benefit comes in the next iteration you are asked to add some logic to that method with simple assignment. You already have tests so you know why that function exists to start with and with that understanding you can add more tests to support new functionality without breaking the old ones. In this case, you are trying to understand what that function suppose to do since you might not have written the code, so you do not know what it was suppose to do. With tests, it is easy to see the scenarios and understand what exactly those methods suppose to do. It gives the confidence in your change you are making.

AngularJS provides not only unit testing, it also gives e2e testing. So even if there are no logic in the client side, you are working with the data coming from server to display data. So you can write tests for it. Write your e2e test with mock data and verify if the UI elements display the data as it suppose to be. The cases where the developer thinks there is no logic in the client side, then you will have more e2e tests than unit tests.