The MEAN stack blog

Testing meanio/mean-cli branches (0.4.1 is a coming)

brace-yourself-winter-is-coming

We’re getting ready to release 0.4.1 and have a branch (0.4.1rc1) for meanio and mean-cli which you can test it locally…

But hey – how do you do that anyway. Let review – Mean is combined of 3 parts

  1. linnovate/mean-cli – Providing the cli commands + mean network access
  2. linnovate/meanio – Core of the project
  3. linnovate/mean – 5 core packages + configuration

When we install mean we initially install the mean-cli globally through

npm install -g mean-cli

When we run mean init – a linnovate/mean is cloned in to the directory you provided as you’re apps name. If we look at linnovate/mean/package.json – you see the dependency to meanio in the dependencies section. If we change the meanio that gets installed we’ll get the new capabilities.. The handy todo list by Yonatan can be helpful..

  1. mean init
  2. cd mean
  3. npm install
  4. sudo rm -rf node_modules/meanio
  5. cd node_modules
  6. git clone https://github.com/linnovate/meanio.git
  7. cd meanio
  8. git checkout origin/0.4.1-rc1
  9. npm install .
  10. rm -rf node_modules/mean-cli
  11. cd node_modules
  12. git clone https://github.com/linnovate/mean-cli.git
  13. cd mean-cli
  14. git checkout origin/0.4.1.-rc1
  15. npm install .
  16. //return to project root
  17. vim package.json
  18. //change post install to “node node_modules/meanio/node_modules/mean-cli/bin/mean-postinstall”
  19. //simulate postinstall by running “node node_modules/meanio/node_modules/mean-cli/bin/mean-postinstall”
  20. grunt

Daphne – The Ninja

Concept to Sketch

It’s been more then a year since our ninja logo was created by the super talented Maya and Idan from pixelwrapped.
When we developed it we iterated a few styles of ninja untill we got it just right ™.

The proud father

In may 22nd we where mentioned in the next tweet…

We offered to send some stickers and a shirt to that rad 8 yr old and we learnt her name was Daphne and that she liked coding with Ryan Carter her proud father. After a few weeks we got this cool pic showing Daphne with her ninja shirt in action!

daphna-2

Meeting Daphne

I got a chance to visit the US two weeks ago and it appears that Daphne (and Ryan) live a few blocks away from my sister in Aurora Colorado (a Denver suburb). It was totally clear that we should meet and hack on some MEANingfull code together So we met up, scaffolded the pinkninja package (coming soon!!) and had a good time. I used this experience to personally announce that the mean.io ninja will be name Daphne – A cool js ninja with attitude.

20141026_150652_HDR

Pixelated MineCraft Ninja

In the same evening I saw a post in Facebook that proved that indeed Daphne has super creative ninja powers when I saw the MineCraft version of Daphne the Ninja!

10441365_10152403019306596_8471453930464417517_n

We’re waiting eagerly for the publication of the pinkninja package and also are happy with the “proud fathers” growing involvement with mean.io and help in facebook and in the google group. Rock on Carters!

Better Documentation

Documentation is important.
It’s the way a developer perceives the value of an opensource technology, the mental checklist I use is

  1. Skim the site.
  2. Skim the docs.
  3. Try to install in 5 minutes
  4. Skim the code

If all four pass – dive in.

The docs we had were good but we where the only ones that maintained them. The code was in an angular view and was buried within the linnovate/meansite repository with hardly any contribution by the community.
We knew we needed the docs to be based on code from the repository and we knew we needed to have a way to simply merge a PR and get the docs out there.

Looking for open-source solutions I stumbled upon flatdoc which is a super easy way to build documentation upon the hierarchy of your README file. I built http://learn.mean.io as the new hub for documentation for mean.io.

What this means is that the community can directly contribute by submitting Pull Requests upon README.md and that we have developers more engaged in the docs and let the documentation team submit improvements on a much more rapid basis.

Documentation is #1 on my priority list these days and I feel we took a substantial first step in the right direction.

Ninja of the month – Sep/October 2014

The next contributors to win the super prestigious πŸ™‚ Ninja of the Month awards – are Andrija PetroviΔ‡ and Veljko Popovic which have initiated many ideas and improvements while refactoring the mean core and introducing the idea of core packages. Beyond enjoying geeking out and sharing linux kernel 2.0 war stories they have been doing an amazing job and are a big part of the performance and restructure imporvments coming up in release 4.1. To play around with that branch feel free to checkout the 0.4.1 branch – great job guys!

MEAN First experience changes

The current experience a developer has when he installs mean is welll… – terrible

Lets see what a developer that is all excited about the mean stack experiences and what probably goes through his mind…

  1. Installs the system and thinks “That was a breeze, cool asciiart!”
  2. He runs npm install and thinks “Why does this take so long? and why do they install so much stuff to bootstrap their application?
  3. Runs grunt and goes to localhost:3000
  4. Sees a page with – “This is the Homepage” and thinks… “Ok – now what??

Screen Shot 2014-10-06 at 2.14.57 PM

For that developer to actually figure out what the next steps would be he would need to.

  1. Assume this is a boilerplate – We are trying to transition to a framework
  2. Try to login to the site and fail (there is now existing users)
  3. Try to register to the site (they used to fail until we retouched the social auth plugins to not appear if they are not configured
  4. He registers locally and think “Ok – Now what??
  5. Confused he goes to the documentation or sees a video
  6. He Gets to the cli section and understand that he needs to add a role to his user.
  7. Opens a terminal and run mean user -a admin myNewUser
  8. When nothing happens he reloads the page and sees himself logged in.
  9. To understand what is installed or to change a theme he needs to browse the mean site or docs – figure out he can extend mean with some packages.

Obviously this is a nightmare! I have a new sense of appreciation to the existing community on how they actually needed to fight against the current to understand why mean is great (beyond assessing the code) – and we need to change this. The change proposed and which I’d like to share is the following

  1. The developer enters localhost:3000
  2. He gets routed to the sign up page with a title that states “Create your first (Administration) user
  3. A user with role admin will be created
  4. The user will be routed to the homepage that will look like this….

first-screen-with-sidebar

Eye Candy and Login logic

Hi Meaningful people! We are working in several ways on improving mean – A lot of stuff is happening around modularising and cleaning up the mean core, providing easier ways to contribute packages and general ongoing fixes. One thing that will surely be apparent is our redesign of the Login/Register and Forgot a password screens. Beyond looking better this is why this is important

  1. Better UX and Design – The login/register is one of the first experiences a developer/client sees when he approaches MEAN for the first time. Tyler Spartan Hollywood is helping out in the UX aspects and wording, we Implemented the design from PixelWrapped and basically it’s an important step forward.
  2. Theme package – Till now we did not have any cust css – everything was based on bootstrap – we added a 5th core package called theme – feel free to create your own themes and modify the way MEAN looks and behaves
  3. Login Logic – The whole idea of seeing 3-4 auth providers when you haven’t configured anything created non neccesary cognitive load – we have added some code checking the your config file and if you have DEFAULT_CLIENT_ID in the clientID of each authprovider it will assume that you did not configure it and that it should not be shown.

Have fun!

Tips for tinkering with the mean-cli

For people that want to enter mean core development (which happens on the meanio repository) Andrija Petrovic helped me create this list that can help people that want to hack with the mean core.

  1. Get the latest source of meanio by – git clone https://github.com/linnovate/meanio
  2. Create an app with mean init
  3. Go into the node_modules of the mytest proj
  4. Remove the existing meanio module and git clone mean-cli meanio
  5. Mean will break – the first error is that glob is not defined
  6. Get back to meanio and locally npm-install
  7. Then Mongoose will act up – it never calls back
  8. The problem is that meanio has a dependency in package.json on mongoose, so mean-cli gets its local mongoose. And nothing works actually
  9. To fix this After local npm install in mean-cli (that is meanio), manually npm remove mongoose :grinning:

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 mean.io 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 mean.io.

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
});