All posts by Zohar Stolar

Founder at and

Alternative layout using your own package

On of the coolest tricks I learnt recently (thank Yonatan!) is the ability to overide Tal, Alex and Jen from the community all asked me pretty much the same question yesterday.. How can I disregard the system package layout and roll out my own theme I just tried it out and it’s trivial! So have fun (and send me cool “theme” packages)

To load your own packages server side (node) swig based templates all you need to do is to add the following line to your app.js in your newly scaffolded (mean package $packagename) package. In this example I ran mean package mytheme – and enter my line after the Mytheme.register function

Mytheme.register(function(app, auth, database) {
  app.set('views', __dirname + '/server/views');

What this does is it overrides the default views of the app to the current (__dirname) package and thus renders the code in /packages/server/views/index.html

Ninja of the month aug/2014

It’s the last day of august and you know what it means 🙂

It’s ninja of the month time!

Last month’s winner – Pratik Bothra and his awesome peers from QED42 continued contributing and actually released the first non-linnovate package – The comments package. This package provides comments with push notification features for whatever object you want to enable comments for (typically you would do this for articles) This package is part of a larger product QED42 has build on which provides social interaction for business and now they are contributing back packages that have been used to build it (which is supercool).

Ninja of the Month – August – Taylor Thomas

In early july Pratik opened an issue about livereload not working and we where dealing with a funky situation of not being able to control the order of the packages being loaded and ensuring everything is loaded and ready before the modulesEnabled event is fired. Taylor used the Q library to better control the enabling of packages resolving the livereload pratik and other developers where experiencing as well as improving the overall flow of the mean bootstrap process.

We are working on features that will make contributing packages much easier so stay tuned and as usual anybody helping out on building packages or improving the documentation/tutorials will be a serious contender for Ninja of the month September (and will get our cool T-shirts and stickers).

Build a package – gmap casestudy

As we prepare to accept package contributions from the community we need to discuss and document what is the best way to build a package. I am building a google maps package and will log my steps and discussions along the way.

1. Look for an existing implementation

In my case because we use angular I looked for the existing big and stable integration between angular and google maps. Googling for “angular google maps” brought me to angular-google-maps which is the “official” implementation adopted by angular-ui.

2. Work with the dependency manager

angular-google-maps provides a set of directives to work with google maps in angular applications. I read the “quickstart” which is basically what we need to address within our package so users can setup this integration effortlessly. The first command in the quickstart is the directives installation through bower.

2.1. Execute bower install through your package

With packages that are installable by bower (there are tons! 🙂 ) we want to install through bower. To do so we need to create a bower.json with the dependencies.

2.2. Add a bower.json

So in the dependencies I state the exact package that the quickstart noted to install.

2.3. run it through the package installation as a postinstall script.

to run bower install using the bower.json above we need to trigger the bower install upon the npm install which is run when we install a package. This is executed just like bower gets invoked when you run mean init (and thus first npm dependencies and then bower dependencies are satisfied in

To check this and to actually run the bower install –

2.4 Change bower’s default installation location

When running bower install the default location bower installs to is bower_components. In mean we have the public/server convention and all client side code needs to go to public. This means we need to “tell” bower to install in a different location. This can be achieved by creating a .bowerrc file in the root directory which looks like this.

2.5 Check that everything works (npm install)

To do so run an npm install… 1. that is supposed to trigger the bower install 1. That is supposed to install the dependencies to public/assets/lib

3.App.js changes

The way we require missing dependencies, add aggregated resources, add routes,settings and menus is all through the packages main digest file – the app.js

3.1. Add the angular dependencies.

We need to expose to angular the dependent directives and services coming from the bower package. This is done by adding an “angularDependencies” function in the app.js
In our case it’s the line

3.2. Aggregate the files.

We need to add the javascript and css files that come with the dependencies we just mentioned, to do so mean packages have a neat trick of looking for js and css files and aggregating them to one file which is not physical but instead stored i nmemory aggreagted.js and aggragated.css – The idea is based on the fact that a modern web app might have dozens of packages installed providing dozens of javascript and css file.
It’s common practice to compress them to one file (this is done by the grunt uglify and the grunt cssmin tasks)
There are 2 ways to aggregate the js/css files either with a relative reference – like:
Gmap.aggregateAsset('js', 'googleapis/places.js')
or using an absolute path like –

Gmap.aggregateAsset('js', '/packages/gmap/public/assets/lib/angular-google-maps/dist/angular-google-maps.min.js',{
weight: 4,
absolute: true

The Roadmap

We want to share the directions and to where we think the energy should be focused. We plan to release the ability to give back and contribute packages from the command line so it will be convenient to share code and packages. And we have a list of packages we’ve completed and some that we think will be cool to build…

Feel free to come, comment and vote in the roadmap

Mean + Google Cloud Platform = ♡

We where deeply honoured to be approached by the GCE (Google Compute Engine) team that decided to include the Mean Stack as the fourth deployable open-source technology in their click to deploy program on the Google Cloud Platform They have just blogged about it here

To set up you mean instance on GCE follow the next steps…

  1. Go to
  2. Click on the Deploy the mean stack leading to here?
  3. Lean back and soon you will get your first 1 click deployment of mean in the cloud (first but not last 😉 )..

Ninja of the month is growing and maturing as an open source community, we (@linnovate) are trying to contribute back as much as we can but our main goal is for other developers to join the fun.
Throughout the project there have been people that have show considerable contributions to the project like Amos Haviv, Yonatan Ellman, Drew Fyock and more -Beyond the core team – developers like Liran Tal and Orit Persik have moved the project forwards with PRS and core work.
To take this team and make it even bigger I’d like to start a tradition in which I’m going to pick a noteable member that has made a generous contribution of time/code/packages/support/documentation and he will be our “Ninja of the month” Each Ninja gets our awesome meanio shirt (which is now out of stock until we print the next batch).

Ninja of the Month – July – Pratik Bothra

Sometimes just being active in the issue queue proposing ideas and then delivering on them is what an opensource project really needs. An example to that was this month with Pratik Bothra which raised again an issue that actually most of the community was in agreement of (the move from 4 spaces to 2 spaces indentation), after seeing this was the case in a facebook poll and upon our request – Pratik submitted a PR to change that aspect in – This is a great example of scratching your own itch.

Pratik gets the July Ninja – Anybody that submits a package we’ll include in the package repository will be a serious contender for August!

MEAN 0.4 released + upgrade tips

Well after some hard work and late night drama – we released Mean 0.4 yesterday. As usual you can find the release notes here but lets explain and iterate about the changes.

  1. Moving core logic into packages** based on the logic described here
  2. Uglify aggregated js
  3. Allow DB overriding of configuration files and created /config directory
  4. Moved core mean logic from express.js to meanio package
  5. Released mean-cli version 0.5.3
  6. Moved public/libs to bower_componets
  7. removed public and server directory logic to system and access packages
  8. Created JS and CSS grouping and weights to allow changing order of js and css files

For people that have been using mean-0.3x there are a few initial tips by developers from the community that have upgraded and have tips to share.

  1. Checkout Liran Tal’s experiences here
  2. Chekout Kyle Bowerman’s notes here

0.4 – The packageination of everything

In the past 4 months mean has been changing a lot. The reason driving this change is our mission to find the “just right” file structure which conveys the larger change in Mean has been changing from a boilerplate which educates and inspires developers on how to approach fullstack development – to a maturing development framework which is easily extendible by custom and 3rd party packages.

Packages are awesome and we are busy creating the infrastructure to let you manage them and publish them yourself. With these changes the core team has been busy on restructuring mean to be consistent in the way the core and the packages work and to complete the change towards being the best javascript full stack in the neighbourhood. This required consistency moved The work was born in a series of discussions between Drew (our latest addition to the core team) and Adrian in IRC which was summarised in the following document.

In the end of our changes the filesystem will look something like the embedded gist below. The main advantages we see are..

  1. Move everything to packages to create a more consistent behaviour between the core and the packages.
  2. Move a lot of the logic in to packages and thus slow down the core changes – and keep help
  3. Segment core to several packages and allow optional core functionality through a generator or a smarter “mean init” process.
  4. Moved tests in to packages which will hopefully hep people write testable packages as well.

Tell us what you think about these changes… A lot of have them originated from developer comments but it’s important for us to see how these changes are accepted by the community because in about a week all this is going to be 0.4 version of mean..


As MEAN progresses it has the ability to integrate packages and to extend the basic features with additional functionality without sacrificing the code size. This actually reduces the size of the core and moves the mean core to a package oriented structure. I’ll try to use this tutorial to explain about what types of packages are available, How to a package is structured and how you can extend packages to implement you own project.

Package Types

There are three types of packages. Mean comes with several preinstalled packages (we are in the process of breaking up the core functionality to even more core packages. Core packages can be found in the articles directory.

Core packages

  • Articles The articles packages provides an example for CRUD (Create, Retrieve, Update and Delete) actions for a model called article – this is the perfect package to copy and modify when trying to build your own functionality (as we’ll demonstrate in the next steps of the article).
  • Auth (0.4) All of the login/registration and user management code.
  • System (0.4) All of the base functionality of mean, all system related code.

Published packages

We have several published packages which we expose here , until we open the mean repository and let developers manage the code from the repository – you can manage the code and host it at github. Currently mean install looks for the package under the linnovate github user so if you have a package you want to publish and can’t wait for the repository – give us a heads up and w’ll fork it so all the community can use it. The current available packages are…

  1. mean-admin mean-admin provides a package which installs a blue administration side bar which lets you users with the admin role access to the packages, themes (powered by bootstrap), settings (currently empty) and user management.
  2. mean-tokens mean-tokens provides the directive that lets you or your client edit text online while you are in “edit mode” ( a toggle in the top left of the main navigation area).
  3. mean-translate mean translate extends mean-tokens and lets you set values for each of the mean-tokens according to the language we are currently in. It also provides a language chooser select box and a languages admin page for admin users.

Custom packages

The mean package lets you scaffold a new package based on the directory structure which exists in the meanio npm package. In the upcoming 0.4 installing a custom package will place it under packages/custom/packageName .

Package Structure

Once you create your own package the next file structure will be created

Application flow

When we want to create an application which introduces user interaction we think about the interaction as going “up the stack” – I created a gist that document the create article functionality in the articles core package. and Drupal

This article has been cross posted in it’s interesting for the crowd because this sort of integration could (and will) be implemented with othe cms’s like wordpress or magento ….

Maybe it’s just me.. But I see more and more DG’s (Drupal Geezers) find themselves introspecting and thinking about the technology they have invested their past 7-8 years in.

The web is exploding with tons of amazing javascript mvc platforms, crazy socket madness and stunning widgetry all running client-side (in the browser) with amazing sub-second speeds.

Our reality is that we still live in a world where 10% of the functions we use frequently in drupal end with .+_alter – Drupal typically will output whatever markup you want and then you find yourself wrestling with it and altering it to fit the semantic html you want. To actually get Drupal to come close to sub-second performance means to wrap it with so many caches it looks like an Egyptian mummy.


The main challenge I see with Drupal revolves around theming, because Drupal is a great CMS for beginners it bundles every layer of markup possible so it can be tweakable from the admin UI, but in the process if you want clean, simple semantic markup of blocks, menus, views, panels etc… – you really need to know what you’re doing. Thus you see more and more Drupal shops experiment with decoupling the front and back side of Drupal. Drupal is awesome in managing content, users, groups and processes but when it renders that information it’s sometimes heavy, bloated and inflexible. The way we approach this is through building the interface with angular.js an awesome MVC javascript framework and connecting through web services to the Drupal containing the data. In the past 2 years we have started to experiment with technologies augmenting Drupal – building apis powered by node.js and mongoDB for scalable mobile endpoints, and building angularjs based widgets that we’ve inserted in to existing Drupal sites. I talked about this in a webinar by acquia 2 years ago but as we reimplemented these fullstack javascript implementations we felt we needed to standardise around a common solution for our internal needs.

We’ve merged all of the best practices for fullstack javascript development within the project. MEAN is an acronym coined by Valery Koltarov from MongoDB and is used to describe applications built by MongoDB, Express, Angular.js and Node.js. We and over 3200 developers which stared the project in github are awed in the speed and quality that comes when you’re actual building what you need and not constantly altering what you got from Drupal. So we have this awesome js framework that knows how to serve content very well but lacks a CMS, and we have a CMS (that we still love) which does an awesome job of managing content but can do a better job serving it. We combined both worlds with the mean module providing a standard way to bi-directionly communicate between instances and Drupal.

The mean module

Although Drupal 8 is coming up there are tons of Drupal 6 sites out there that want to spice up the look and feel yet maintain the content, ccks and views involved. We thought how to expose the data within drupal to rich widgets or single page applications which either feed information in to drupal or use information fro within to provide a dynamic experience. The mean module (at provides the means to export blocks,menus views and variables to one big json file which is accessed by an angular.js service which reads it and makes it available to the mean application.

Integration Strategies

There are two types of patterns that can be implemented using the mean module.

Mean in front is used in many places as an engine for SPA (single page applications) now we can create applications that are built from information which is held in drupal. Mean provides an interface to load various pieces of data from a Drupal sites and to render a single-page application which uses Drupal as an additional data source. We implemented this approach lately with Strauss an established enterprise customer which had an OpenIdeal – Drupal 6 site which they wanted to face lift. You can browse here to see the result and here to peek in to the drupal in the backend which powers it.

After enabling the mean module you can browse /mean/json/help/me and see the following possabilities…

URL stucture: /mean/json/[TYPE]/[NAME]/[ARG1]/[ARG2]/[ARG3]
currently supported TYPE values and their arguments:
- view - returns results for requested Drupal view object, arguments:
  - NAME - view's name
  - ARG1 - (optional) display_name
  - ARG2 - (optional) items per page value (-1 for unlimited, 0 - skip arg)
  - ARG3 - (optional) arguments divided by '+' sign without whitespaces
- menu - output from menu_tree_all_data() function
- load - looks for load_[NAME_mandatory] function and returns its output
(node_load([ARG1]), user_load([ARG1]), menu_load([ARG1]) ...), arguments:
  - ARG1 - ID or name to pass to load function
- help - /mean/json/help/me will output current instruction
- user - /mean/json/user/logout - Logging current user out
  - /mean/json/user/login (along with name and pass values passed as post
  will log user in and return its object)
  - /mean/json/user/session - returns $_SESSION
  - /mean/json/user/me - returns global user object
- get-mean-packet
  - returns set of JSON objects, set at admin/build/mean-packets
  - NAME - packet's name
To skip any optional ARG, use 0, (example: /mean/json/forum_search/0/5)

Angular apps in blocks/panel panes

In many cases we have to continue hosting with Drupal – for instance if you have a governmental site that has been security cleared to run Drupal there is a very slim chance you could change that. With the next approach you can still get the “single page” behaviour or implement a complex widget that you’d rather implement on a client-side MVC rather then in a bunch of spaghetti code in jquery.


p>We have been working with a financial client from new-york for the past year which has a huge antiquated drupal-5 site and the ability to insert rich angular.js driven application that connect to the data within the drupal site – can create a modern feel even if you’re stuck in the past, it also can provide a clear path to fix sites that can’t be upgraded because their core has been altered.

Drush support

One of the concepts and tools we’ve built to help with both types of integrations – has to do in how to swiftly enter the Drupal data in to a mongodb based db so it can be served effectively to mobile devices, widgets and single page applications. We have bundled the mean shadow module with the the mean module which provides a standard way to sending drupal information upon content update to the Mongo/Node based service. To make the initial import of the data in to the mean easy we provide the drupal shanties (shadow entities) command…

Here are some examples of the possible usage..

     Standard example (all the user entities)  drush shadow-entities              
     Type example (all the node entities)      drush shadow-entities node         
     Id example (specific user)                drush shadow-entities user 42      
     Id example 2 (specific node)              drush shadow-entities node 42      
     Bundle example (all the entites of        drush shadow-entities node article 
     bundle article)    


To summarize – is an amazing way to develop cool and modern applications but the mean module integration lets us start building mean apps now and helps them co-exist and augment Drupal.