Nothing stays the same

This is my personal blog, I try to write in english but isn't my natural language.

[agustinvinao]

Rails Tip #1

One of the biggest issues when you try to find how to fix a problem in your code is not easy to surf all the information, this tips tries to solve that.

has_secure_password is a great way to handle passwords in rails, but if you want to save a user without provide the password it fails.

Here is the original code for has_secure_password

# File activemodel/lib/active_model/secure_password.rb, line 53 def has_secure_password(options = {}) # Load bcrypt gem only when has_secure_password is used. # This is to avoid ActiveModel (and by extension the entire framework) # being dependent on a binary library. begin require 'bcrypt' rescue LoadError $stderr.puts "You don't have bcrypt installed in your application. Please add it to your Gemfile and run bundle install" raise end include InstanceMethodsOnActivation if options.fetch(:validations, true) include ActiveModel::Validations # This ensures the model has a password by checking whether the password_digest # is present, so that this works with both new and existing records. However, # when there is an error, the message is added to the password attribute instead # so that the error message will make sense to the end-user. validate do |record| record.errors.add(:password, :blank) unless record.password_digest.present? end validates_length_of :password, maximum: ActiveModel::SecurePassword::MAX_PASSWORD_LENGTH_ALLOWED validates_confirmation_of :password, allow_blank: true end # This code is necessary as long as the protected_attributes gem is supported. if respond_to?(:attributes_protected_by_default) def self.attributes_protected_by_default #:nodoc: super + ['password_digest'] end end end

To avoid this and use your own validations and save users without provide password

class User < ActiveRecord::Base has_secure_password validations: false validates :password, presence: true, on: :create, length: { minimum: 4 } end

[agustinvinao]

Rails 5 - Minitest Spec - Fixtures

Rails edge / Rails 5 if you want Minitest + Specs + Fixtures

require 'minitest/spec' class ActiveSupport::TestCase # Setup all fixtures in test/fixtures/*.yml for all tests in alphabetical order. fixtures :all # Add more helper methods to be used by all tests here... extend MiniTest::Spec::DSL register_spec_type(self) do |desc| desc < ActiveRecord::Base if desc.is_a?(Class) end end

[agustinvinao]

Rails5 mock/stub minitest

I love tests and rails, is one of those combination where all goes better than I expect, but sometimes all the love I have it transforms to angry in one line of code.

I needed to stub my “current_user” method I’ve defined in ApplicationController, Im using minitest and my tests uses TestCase.

Yes, I know all of you use Specs, but I was a bit busy when I created some part of my app and I’ve used Scaffold and my tests now are like that, shame on me.

I’ve tried many ways of stubing this method but only one works, and is using mocha:

@controller.stubs(:current_user).returns(@user)

Please let me know if you have any other way to do it. It should be better if I only use minitest and minitest/mock.

[agustinvinao]

Gulp is not ready for Angular

Is part of my workflow try to know any new technology, and I was talking about Grunt/Gulp with some people and reading about it too. Many people is saying to change to Gulp, than its faster than Grunt, its better code, its this and that.

I’ve tried to replace my current Grunt tasks with Grunt and I found this problems:

1. 10 times slower to compile my code

Yes, it was ten times slower. All my deploy process takes 1m 55s with grunt, this is for compile, upload, update bower and node, etc (if I dont need to update package, only run the commands to verify it).

When I finish to rewrite all my Gulp task, it was the moment to do a deploy, and I couldn’t do it, after more than 5 min of waiting when it was running the ‘build’ task with gulp I knew something was wrong.

The way I was using gulp to integrate it with angular was using the code from generator-gulp-angular, is you create an proyect with this generator, your build task in gulp, looks like this for the part where it compiles:

return gulp.src(path.join(conf.paths.tmp, '/serve/*.html')) .pipe($.inject(partialsInjectFile, partialsInjectOptions)) .pipe(assets = $.useref.assets()) .pipe($.rev()) .pipe(jsFilter) .pipe(debug()) .pipe($.sourcemaps.init()) .pipe($.ngAnnotate()) .pipe($.uglify({ preserveComments: $.uglifySaveLicense })).on('error', conf.errorHandler('Uglify')) .pipe($.sourcemaps.write('maps')) .pipe(jsFilter.restore) .pipe(cssFilter) .pipe($.sourcemaps.init()) .pipe($.replace('../../bower_components/bootstrap-sass/assets/fonts/bootstrap/', '../fonts/')) .pipe($.minifyCss({ processImport: false })) .pipe($.sourcemaps.write('maps')) .pipe(cssFilter.restore) .pipe(assets.restore()) .pipe($.useref()) .pipe($.revReplace()) .pipe(htmlFilter) .pipe($.minifyHtml({ empty: true, spare: true, quotes: true, conditionals: true })) .pipe(htmlFilter.restore) .pipe(gulp.dest(path.join(conf.paths.dist, '/'))) .pipe($.size({ title: path.join(conf.paths.dist, '/'), showFiles: true })); });

Gulp pipes tasks, thats the big thing of gulp, but if you have a hard task like this, all the gulp magic goes to the trash. I couldn’t find a good way to track pipe time, trace errors, or put some info to debug (the only thing I’ve found was gulp-debug and it not very helpful)

My current grunt task to build my code code looks more or less like this:

module.exports = function(grunt) { grunt.registerTask('build', [ 'clean:dist', 'env:all', 'injector:sass', 'concurrent:dist', 'injector', 'wiredep', 'useminPrepare', 'autoprefixer', 'ngtemplates', 'concat', 'ngAnnotate', 'copy:dist', 'cssmin', 'uglify', 'rev', 'usemin' ]); }

And it takes 10% or less of the time used by Gulp.

Trying to find if I was doing my worst code in my life, I started to look for this issue and I’ve found many more with the same issue:

https://www.tildedave.com/2015/01/07/i-find-gulp-extremely-frustrating.html

http://stackoverflow.com/questions/24456189/gulp-suddenly-compiling-extremely-slowly

And when I tried to see which module was the biggest problem I got this: https://github.com/terinjokes/gulp-uglify/pull/31 where you can see a pull-request to start to understand the Gulp slow problem.

2. Better code

not comfortable with Grunt, but from my experience if you can not track time per pipe in an easy way, debug whats going on, and avoid 10 pipes only to maintain in memory your process… is not the solution I’ll use.

PS: If you are using Angular and your project has more than 100 js files, and you use Gulp with a compile time below to 3m, please provide a link to your gulp config/tasks to build that example. It should be great to see a good AngularJS app working with gulp.

[agustinvinao]

NeoVim

Desde hace bastante tiempo estaba intentando volver al mundo VIM, habia cambiado a Sublime después de no haber podido resolver algunos problemas en la configuracion que tenia de VIM.

Algunos otros problemas tenían su origen en en la falta de actualización de VIM que a padecido en el último tiempo. Querer usar un editor para programar cosas en el año 2015 que no es actualizado a la velocidad de los avances que vivimos - o a una velocidad al menos útil- me llevó a dejarlo de lado.

NeoVim plantea soluciones fundamentales a muchos de los problemas que me hicieron alejarme. 

En el sitio de github (https://github.com/neovim/neovim) podemos leer:

Neovim es un proyecto que busca rehacer VIM para lograr:

Mantener y promover contribuciones.

Dividir el trabajo en múltiples desarrolladores.

Habilitar la implementación de nuevos y modernas interfaces de usuario sin modificar el núcleo del código fuente.

Mejorar la extensibilidad con una nueva arquitectura de plugins.

Dicho esto, pueden ir viendo las ventajas de NeoVIM. Casi un mes o un poco más de usarlo de forma continua, no volví a abrir sublime.

[agustinvinao]

Preparandose para Angular 2.0

No falta mucho para que AngularJS vea la versión 2.0. Este cambio plantea grandes desafíos y una reescritura de los proyectos existentes que quieran migrar a esta versión.

Se va a mantener el soporte para 1.x, esta ha sido una decisión por parte de google para no “matar” la comunidad y verla forzada a migrar en un apuro y con grandes posibles errores.

Parte de esta decisión también sostiene que muchos proyectos nuevos dejarían de lado AngularJS como opción si se vieran en el camino de tener que ser reescritos al poco tiempo de crearse con la salida de una cambio tan amplio.

Desde el equipo de desarrollo de AngularJS estan generando varios contenidos para hacer mas facil el cambio, pero es la misma comunidad quien va a ir aportando pequeños textos para esta migración.

Antes de ponerse a leer, intentar, o lo que sea con Angular2, recomiendo hacer dos cosas fundamentales:

1. Adaptarnos a la guia de estilo propuesta por John Papa https://github.com/johnpapa/angular-styleguide

2. Angular2 está pensando con una filosofía de componentes, lo cual indica que todo, o casi todo, será un componente. La mejor forma de preparar nuestro código, si es que tenemos uno, es reescribirlo usando directivas que simulen componentes.

Para que se entienda mejor el punto 2, lo que necesitamos hacer es extraer cuanto podamos a directivas como si fueran componentes. Por ejemplo, si tenemos una parte en nuestro proyecto para crear un item y visualizarlo, podemos crear una directiva que haga todo este trabajo.

Así es como iremos abstrayendo partes de nuestro proyecto hasta llegar a tener una colección de directivas -de ahora en adelante las llamaremos componentes-.

Para una mejor organización, podemos separar estos componentes en dos categorías:

1. Widgets: son componentes que responden a un propósito general o que no son específicos de una sección de nuestro proyecto. Ejemplos: el Perfil del usuario, la Barra de Navegación.

2. De aplicacion: son componentes totalmente especificos a la aplicacion que estamos desarrollando y que generalmente solo se usan en solo una parte de esta (es posible que un widget solo sea solicitado en una parte de nuestro código pero su entendimiento es mas generico). Ejemplos: es una aplicacion de facturacion el componentes Factura, en una aplicacion de un hotel el componente Habitacion.

No todos los componentes van a poder aplicacion a lo que pensamos como un objeto. Si tenemos una aplicacion para hacer el tracking sobre un mapa, podemos tener un componentes que cumpla con esta funcionalidad que sea mostrar el recorrido en el mapa. Y dicho componente sería de la categoría dos.

Bien, con esta tarea de usar directivas con la idea de componentes, es bastante el trabajo que tenemos por delante.

En los próximos posts iré comentando otras cosas que nos serán útiles para llegar a migrar a Angular2 de la manera mas sencilla posible.

[agustinvinao]

Persistir queryString entre vistas

Me encontre con la situacion de tener que mantener el queryString entre distintas vistas cuando necesito navegar una paginador y contener links dentro de lo que voy actualizando segun las paginas.

Por ejemplo para este blog, cuando en el menú de la izquierda tengo que ir cambiando de página, los links a los posts quiero que mantengan el número de la página que estoy viendo en ese momento para si navego uno de esos links no ir a la página 1 del paginador de posts.

Para lograrlo hay que:

Exponer nuestro $location.search() a las vistas. Este $location.search() nos devuelve todo el contenido del queryString en formato de objeto {id: 1, slug: ‘test’}.

Actualizar lo que vamos a exponer para los links que mantengan ese queryString si cambiamos algún parámetro de nuestro $location.search()

En las vistas poner nuestro queryString que expusimos en el controlador.

Por ejemplo, en nuestro controller:

function MainCtrl($log, $routeParams, $location, PostService) { // con $.param convertimos todo el contenido de $location.search() vm.search = $.param($location.search()); // si tenemos una funcion que llamamos al cambiar la pagina en algun paginador y // queremos mantener dicha infomacion en los links podemos hacer function pageChanged() { $location.search('page', vm.currentPage); vm.search = $.param($location.search()); } }

Y en la vista los links vamos a armar los ng-href para mantener ese queryString que nos interesa:

ng-href="/path-to/?{{vm_main.search}}"

Esta fue la forma mas prolija que encontré hasta el momento.

[agustinvinao]

Deploy a JS Project - Part VI

As we saw in my last post, this is the extension I’ve wrote to deploy using Shipit.

// This script adds tasks to the original Shipit flow // to run this script we need to use: grunt shipit:environment deploy 'use strict'; module.exports = function(grunt) { var async = require('async'); var path = require('path'); var isNull = require('lodash').isNull; function getEnvironment(){ var tasks = grunt.cli.tasks[0]; var environment = tasks.split(":"); return environment[1]; } // Clean & Build and Initialize a respository with the content in /dist grunt.shipit.on('deploy', function () { grunt.task.run([ 'clean:dist', 'build:dist', 'init-repository' ]); }); // Initialize a respository with the content in /dist grunt.registerTask('init-repository', function() { var done = this.async(), source = grunt.config('shipit.options.source'); return grunt.shipit.local('cd ' + source + ' && rm -rf .git && git init --quiet && git add . && git commit -am "intial commit"').then(done); }); // Update Node Modules and Bower Components grunt.shipit.on('updated', function() { grunt.task.run([ 'update-node-modules', 'update-bower-components' ]); }); // update node_modules // This task use a shared folder named node_modules to hold those modules grunt.registerTask('update-node-modules', function() { var environment = getEnvironment(), done = this.async(), deploy_to = grunt.config(['shipit', environment, 'deployTo'].join('.')), shared = path.join(deploy_to, 'shared'), node_modules = path.join(shared, 'node_modules'), node_bin_path = '/home/deployer/.nvm/v0.10.31/bin/'; grunt.shipit.remote(['ln -s', node_modules, path.join(grunt.shipit.releasePath, 'node_modules')].join(' ')).then(function(){ grunt.shipit.remote(['cd', grunt.shipit.releasePath, '&&', node_bin_path + 'npm install'].join(' ')).then(done); }); }); // update bower_components // This task use a shared folder named bower_components to hold those components grunt.registerTask('update-bower-components', function() { var environment = getEnvironment(), done = this.async(), deploy_to = grunt.config(['shipit', environment, 'deployTo'].join('.')), shared = path.join(deploy_to, 'shared'), bower_components = path.join(shared, 'bower_components'), node_bin_path = '/home/deployer/.nvm/v0.10.31/bin/'; grunt.shipit.remote(['ln -s', bower_components, path.join(grunt.shipit.releasePath, 'public', 'bower_components')].join(' ')).then(function(){ grunt.shipit.remote(['PATH="$PATH:/home/deployer/.nvm/v0.10.31/bin;" && source ~/.nvm/nvm.sh && node --version && cd', grunt.shipit.releasePath, '&&', ' nvm run v0.10.31 bower install', grunt.shipit.releasePath + '/bower_components'].join(' ')).then(done); }); }); // Restart our nodeJS server grunt.shipit.on('published', function() { grunt.task.run('forever-restart'); }); // We need to stop any previous process to the app.js script and start a new one grunt.registerTask('forever-restart', function() { var environment = getEnvironment(), done = this.async(), node_bin_path = '/home/deployer/.nvm/v0.10.31/bin/', deploy_to = grunt.config(['shipit', environment, 'deployTo'].join('.')); grunt.shipit.remote('source ~/.nvm/nvm.sh && ' + node_bin_path + "forever stop " + deploy_to + "/current/server/app.js" ).then(startServer).catch(startServer); function startServer() { grunt.shipit.remote('source ~/.nvm/nvm.sh && export NODE_ENV=production && export PORT=9000 && ' + node_bin_path + "forever start " + deploy_to + "/current/server/app.js").then(done); } }); }

This extension of the original Shipit flow adds a few steps to install npm modules and bower components.

A good thing about this is that we can add anything we want to our deployment process extending the original flow.

We only need to add it to the flow.

[agustinvinao]

Deploy a JS project - Part V

Now that we have our webserver configured, our NodeJS consuming Tumblr API and ready to respond to our AngularJS application, we can work with our deploy script.

We are going to use SHIPIT (https://github.com/shipitjs/shipit), this is a tool in Javascript to do a deploy to a server. It has the same philosophy as Caspistrano.

The shipit deploy task is in a different repository (https://github.com/shipitjs/shipit-deploy). We need to write something else in order to have the flow what we need.

Shipit flow

Starting from the original flow that we have from Shipit:

Checking the Deploy process we need to change some steps.

Our shipit config looks like this:

module.exports = { options: { workspace: '/tmp/path-to-temp', source: '/path-to/dist', deployTo: '/path-to-server-destination', repositoryUrl: '/path-to/dist', ignores: ['.git'], keepReleases: 5, key: '/path-to/.ssh', shallowClone: true, dependencies: ['node_modules', 'bower_components'], symlinks: ['node_modules', 'bower_components'] }, development: { servers: 'user@ip', deployTo: '/path-to-server-destination' }, staging: { servers: 'user@ip', deployTo: '/path-to-server-destination', } }

Initialization

We need to prepare the code that we need to send to our server, to prepare this code we need to do:

Clean any previous distribution code

Build the new distribution code

Initialize a git repository for the new /dist code

An important note about point 3, we need to create a git repository for the code we are going to deploy to the server, the code that we need to deploy to the server is a compiled version of our application (server+frontend), is not necessary to send this file to an external repository.

We can initialize a git repository in our /dist folder in order to use it as the source to fetch the code in the tmp folder.

Updating with dependencies

After the code is ir our server, it needs to update any bower component or npm module. We need to run ‘bower install’ and ‘npm install’ and share the folders with that content, this is necessary to only install or update new packages.

We need to allow the possibility of rollback, to do this, we have bower.json and package.json per release, with the same idea as before, after update our code in the server -with a new deploy or a rollback- we use those files to do the ‘bower install’ or ‘npm install’. We only can use one release and is not a problem to have only one folder for bower and one folder for npm.

Publishing

As our last step, we need to reinitialize the NodeJS server. To do this we need to cancel our previous forever instance and run a new one with the new app.js file we have in the new release.

Events to connect the dots

A good thing about Shipit is the possibility to change the original flow or add thing to the flow to achieve our goal.

We need to use the events defined in the flow to add our steps.

For example, in our case this are the steps we add to the original flow:

Clean

Build

Initialize repository

grunt.shipit.on('deploy', function () { grunt.task.run([ 'clean:dist', 'build:dist', 'init-repository' ]); });

Update Node Modules and Bower Components

grunt.shipit.on('updated', function() { grunt.task.run([ 'update-node-modules', 'update-bower-components' ]); });

Restart our forever process

grunt.shipit.on('published', function() { grunt.task.run('forever-restart'); });

When we create our task we can define to wait until the task its done to continue with the next. To do this we use “async” library.

As an example we can see:

grunt.registerTask('init-repository', function() { var done = this.async(), source = grunt.config('shipit.options.source'); return grunt.shipit.local('cd ' + source + ' && rm -rf .git && git init --quiet && git add . && git commit -am "intial commit"').then(done); });

The full script to change our shipit flow looks like this:

// This script adds tasks to the original Shipit flow // to run this script we need to use: grunt shipit:environment deploy 'use strict'; module.exports = function(grunt) { var async = require('async'); var path = require('path'); var isNull = require('lodash').isNull; function getEnvironment(){ var tasks = grunt.cli.tasks[0]; var environment = tasks.split(":"); return environment[1]; } // Clean & Build and Initialize a respository with the content in /dist grunt.shipit.on('deploy', function () { grunt.task.run([ 'clean:dist', 'build:dist', 'init-repository' ]); }); // Initialize a respository with the content in /dist grunt.registerTask('init-repository', function() { var done = this.async(), source = grunt.config('shipit.options.source'); return grunt.shipit.local('cd ' + source + ' && rm -rf .git && git init --quiet && git add . && git commit -am "intial commit"').then(done); }); // Update Node Modules and Bower Components grunt.shipit.on('updated', function() { grunt.task.run([ 'update-node-modules', 'update-bower-components' ]); }); // update node_modules // This task use a shared folder named node_modules to hold those modules grunt.registerTask('update-node-modules', function() { var environment = getEnvironment(), done = this.async(), deploy_to = grunt.config(['shipit', environment, 'deployTo'].join('.')), shared = path.join(deploy_to, 'shared'), node_modules = path.join(shared, 'node_modules'), node_bin_path = '/home/deployer/.nvm/v0.10.31/bin/'; grunt.shipit.remote(['ln -s', node_modules, path.join(grunt.shipit.releasePath, 'node_modules')].join(' ')).then(function(){ grunt.shipit.remote(['cd', grunt.shipit.releasePath, '&&', node_bin_path + 'npm install'].join(' ')).then(done); }); }); // update bower_components // This task use a shared folder named bower_components to hold those components grunt.registerTask('update-bower-components', function() { var environment = getEnvironment(), done = this.async(), deploy_to = grunt.config(['shipit', environment, 'deployTo'].join('.')), shared = path.join(deploy_to, 'shared'), bower_components = path.join(shared, 'bower_components'), node_bin_path = '/home/deployer/.nvm/v0.10.31/bin/'; grunt.shipit.remote(['ln -s', bower_components, path.join(grunt.shipit.releasePath, 'public', 'bower_components')].join(' ')).then(function(){ grunt.shipit.remote(['PATH="$PATH:/home/deployer/.nvm/v0.10.31/bin;" && source ~/.nvm/nvm.sh && node --version && cd', grunt.shipit.releasePath, '&&', ' nvm run v0.10.31 bower install', grunt.shipit.releasePath + '/bower_components'].join(' ')).then(done); }); }); // Restart our nodeJS server grunt.shipit.on('published', function() { grunt.task.run('forever-restart'); }); // We need to stop any previous process to the app.js script and start a new one grunt.registerTask('forever-restart', function() { var environment = getEnvironment(), done = this.async(), node_bin_path = '/home/deployer/.nvm/v0.10.31/bin/', deploy_to = grunt.config(['shipit', environment, 'deployTo'].join('.')); grunt.shipit.remote('source ~/.nvm/nvm.sh && ' + node_bin_path + "forever stop " + deploy_to + "/current/server/app.js" ).then(startServer).catch(startServer); function startServer() { grunt.shipit.remote('source ~/.nvm/nvm.sh && export NODE_ENV=production && export PORT=9000 && ' + node_bin_path + "forever start " + deploy_to + "/current/server/app.js").then(done); } }); }

[agustinvinao]

Deploy a JS project - Part IV

Now we need to configure two tools: Nginx and Forever.

In my case Im using nginx as my webserver, you can use Apache too. You only need to replace the server config for Apache if you decide to use it.

The first important thing its to understand what we need to do in this case. Because we have a NodeJS server to provide our API -in my case a NodeJS server to consume Tumblr API and expose it to my AngularJS client-, we need to redirect all our API requests to the NodeJS server, this server response to 127.0.0.1:9000.

As an important thing to have in mind, not all request are going to be to our API in the NodeJS server, a good example I’ve found is for example when you want to share a post to any of the social networks, as Facebook, Twitter, etc. Any of this Social Networks are going to request some data in order to share our content, and is not necessary to run our frontend application. This case is part of our server too.

In our case, my nginx config its:

// av.conf server { listen 80; server_name agustinvinao.com; location / { proxy_pass http://localhost:9000; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection 'upgrade'; proxy_set_header Host $host; proxy_cache_bypass $http_upgrade; } }

With this configuration and running our NodeJS server in the same machine an using port 9000. 

For most of our request we’ll response with:

res.sendfile(app.get('appPath') + '/index.html');

When we send this response we send our AngularJS app. We have two other kind of requests:

API requests

Robots or any other different request that can be detected checking headers.

For [1] we have routes defined in our NodeJS server file:

app.use('/api/things', require('./api/thing'));

For [2] We check if the request its that group before send the index.html, if the request its in that group we send a different response than our index.html

if(req.headers['user-agent'] === 'facebookexternalhit/1.1'){

We can use that line to detect when Facebook does a request in order to share a content.

We will need some other tool in order to start our NodeJS server, for that we can use Forever https://github.com/foreverjs/forever. 

To run our server we use:

forever start app.js

After all this configuration and considerations, we have all our servers and tools to run our application.

[agustinvinao]

Deploy a JS project - Part III

Im using NPM and Bower to handle my libraries. As I’ve said before, I’m using Angular Fullstack Generator, this generator uses Grunt and it uses grunt-contrib-copy in order to prepare the files we are going to need our app.

This can be found in /dist folder with a structure like this:

/dist

     /public (our AngularJS Application)

     /server (our NodeJS server)

     /bower_components

     package.json

I have some observations about this:

If we have our bower components in our /dist folder it should be only if we want to run our application directly from that directory, for example, if we point our webserver to this folder and the application needs to look in a specific place where to find those components.

The problem with the previous point its when you want to deploy this compiled version of your application. In you maintain this folders and files as the original generator you will have more problems than solutions:

Every time you want to upload you /dist folder to your server, its going to take more time to upload /bower_components folder too.

You’ll need to run “npm install” in order to get any package defined in package.json

In order to fix this points, I’ve changed my original configuration of this copy plugin to:

Original version

dist: { files: [{ expand: true, dot: true, cwd: '<%= yeoman.client %>', dest: '<%= yeoman.dist %>/public', src: [ '*.{ico,png,txt}', '.htaccess', 'downloads/**/*', 'bower_components/**/*', 'assets/images/**/*', //images/{,*/}*.{webp}', 'assets/fonts/**/*', 'index.html' ] }, { expand: true, cwd: '.tmp/images', dest: '<%= yeoman.dist %>/public/assets/images', src: ['generated/*'] }, { expand: true, dest: '<%= yeoman.dist %>', src: [ 'package.json', 'server/**/*' ] }] },

New version

dist: { files: [{ expand: true, dot: true, cwd: '<%= yeoman.client %>', dest: '<%= yeoman.dist %>/public', src: [ '*.{ico,png,txt}', '.htaccess', 'assets/images/{,*/}*.{webp}', 'assets/fonts/**/*', 'index.html' ] }, { expand: true, cwd: '.tmp/images', dest: '<%= yeoman.dist %>/public/assets/images', src: ['generated/*'] }, { expand: true, dest: '<%= yeoman.dist %>', src: [ 'bower.json', 'package.json', 'server/**/*' ] }] },

I don’t copy bower_components folder, downloads folder, and I copy bower.json file.

With my /dist folder ready to upload to my server I need to prepare some other things.

One tool I was using before to do my deploys is Capistrano and a good thing I remember about how Capistrano works it that you have a “shared” folder with any file or folder you want to share between differents releases.

We are going to share our bower_components and our node_modules folders, if we do this our deploy time it should be better after our initial deploy, this initial deploy its the only one who needs to do the “npm install” and “bower install” from scratch.

How we are going to do that is going to be in Part XI.

[agustinvinao]

Deploy a JS project - Part II

Some of the basic tools are:

Angular Fullstack Generator

In this case, I’ve started with a skeleton from Angular Fullstack Generator. You can see this tool here https://github.com/DaftMonk/generator-angular-fullstack.

When you use this generator you’ll have a good division in your front code and your server / backend.

NodeJS

In this case, the backend explanation, the generator creates the server and an API structure of components to expose through the server. This components are exposed as json endpoints.

This is not a NodeJS tutorial or any like that. This is all I need to say about the use of NodeJS here.

AngularJS

In the last 2 or 3 years I’m working with AngularJS, part of my choice to use AngularJS over any other JS framework like this reside in the ability of AngularJS of structure your code, the facility to maintain and the good practice applied.

Note: I’m currently using AngularJS 1.x, I need to check how all its going to be in AngularJS 2.x.

MongoDB

Angular Fullstack Generator uses mongodb as a storage if you like, in my case storage is not something I need to worry in this case, mongodb is more than I need and is perfect for now.

[agustinvinao]

Deploy a JS project - Part I

After many years working with Ruby and tools like Capistrano, when I've started working with AngularJS my first question was "How can I deploy my code?".

You may have a lot of things to deploy, your stack may be different from the common projects you read on each blog online.

I will try to expose a solution for a particular case, but explain each part in order to let you use what you need in you particular stack.

In my example I have:

An API developed with NodeJS (Backend). Explained in Part II

AngularJS to consume my API (Frontend). Explained in Part II

MongoDB.  Explained in Part II

NPM and Bower to handle my libraries.  Explained in Part III

Forever to run my API server in background.  Explained in Part IV

NGinx to run my webserver.  Explained in Part IV

Shipit.  Explained in Part V

Personal Shipit extension.  Explained in Part VI

All this posts are a suit to explain how to handle a project based on Javascript technologies, is not necessary to have exactly the same tools. I’ll try to put all the information to let you replace any part with the tools you want.

Part of the replacement philosophy needs to have a balance, if you want to use some other tool to do the deploy, as Capistrano for example, this is not the best article for you. You may have some information about the way I’ve used to create all my deploy process.

[agustinvinao]

Actualizando

Ya esta andando parte de la actualización del blog.

Detrás de la actualización hay una combinación de:

Node para el backend.

AngularJS para el frontend.

Deploy de la aplicacion usando Shipit.

Tumblr para el manejo del blog.

* El blog y sus contenidos estan sobre Tumblr, Node consume la API del blog. 

[agustinvinao]

Updating...

I’m updating my blog, personal site, photography section, cv profile, etc.

It’s going to be working in a few days. 

New version with Node, AngularJS and some other tools I always trying to learn, use, etc.

Sorry if you find broken links, menues, or any other problems this days.

[agustinvinao]

AngularJS - UiRouter - Abstract state karma unit test UPDATE

I found a case when i return a promise inside a resolve function I need to look the final value in a new place.

For example, if we have a resolve function like:

return $q(function (resolve, reject){ products .$promise .then(function (_products) { resolve(ItemFactory.method(); }); });

We need to do our expect like:

it('should have barStart inside resolve', function() { var state = $state.get(state_name); Item.method = jasmine.createSpy('method').and.returnValue({}); expect($injector.invoke(state.resolve.resolveFnName).$$state.value).toEqual({}); });

See the ".$$state.value" at the end of the invoque fn, I need to check something to see if we can simplify this case, but at least for now tests still going on and this change is easy to see the reason.

[agustinvinao]

AngularJS - UiRouter - Abstract state karma unit test

I've seen very little example of this case. I need to test my abstracts routes and I was some time looking for some documentation or any help about it.

This kind of routes in many cases are used as parent of other routes, and generally are going to have data shared between the children. The data its loaded in as part of the resolve block of the route.

Here an example of how to test an abstract route with one item in resolve:

'use strict'; describe('Abstract route test', function() { var $rootScope, $state, $injector, ItemFactoryMock, state_name = 'dashboard'; beforeEach(function() { module('AppName', function($provide) { $provide.value('ItemFactory', ItemFactoryMock = {}); }); inject(function(_$rootScope_, _$state_, _$injector_, $templateCache) { $rootScope = _$rootScope_; $state = _$state_; $injector = _$injector_; $templateCache.put('path/to/template.html', ''); }) }); it('should respond to URL', function() { expect($state.href(state_name, { id: 1 })).toEqual('/dashboard/1'); }); it('should be abstract state and url /dashboard/:id', function() { var state = $state.get(state_name); expect(state.name).toBe(state_name); expect(state.abstract).toBeTruthy(); expect(state.url).toBe('/dashboard/:id'); }); it('should have items inside resolve', function() { var state = $state.get(state_name); ItemFactoryMock.query = jasmine.createSpy('query').and.returnValue({}); expect($injector.invoke(state.resolve.items)).toEqual({}); }); });

Its not part of the the route test to verify 'state.resolve.items' or the data we return from that promise (all resolve blocks needs to return a promise), that kind of thest are unit test of a factory, service or provider we use inside.

If we do many things inside that resolve it should be moved to a factory/service/provider.