Reprise du message précédent :
Y en a qui ont déjà joué avec Grunt, usemin, uglify et les sources map ? Mon build se déroulent sans erreur mais je n'ai aucun .map de généré

Jai joué rapidement avec gulp et c'est de la balle

fépété ton gruntfile ( ou la partie uglify en tout cas)

Grunt, usemin, uglify oui, .map non ,c 'est quoi ?

Ca permet de mapper tes fichiers minifié aux versions de dev directement dans tes devtools : http://www.html5rocks.com/en/tutor [...] ourcemaps/

 
L'idée est de migrer un site existant, hébergé sur un dédié et basé sur un FW, vers GH pages + full statique vu le besoin limité.
GH page ne supporte pas les redirections ni le rewrite, la seule solution est de caler des fichiers HTML avec meta-refresh + redirect aux anciens emplacements.
La structure générale va un peu changer, et a minima les URL vont gagner un .html.
 
Je bloque sur ça, et le fait que les CNAME (solution préconisée par GH) n'ont pas l'air adaptés pour faire un root domain => GH pages et www => root, mais j'ai pas encore creusé le sujet.

 
Excellent, merci  

les sources maps c'est chiant, ca fout des 404 quand ils sont pas inclus (en tout cas sous chrome)

 
Plus ou moins.
 
grunt --verbose peut être utile

La tâche grunt-uglify génère bien le source map, par contre quand elle est précédée de grunt-usemin, ça ne fonctionne plus car il modifie la config de uglify à la volé pour y inclure tous les JS se trouvant entre ses balises dans le HTML

 
Tu peux jeter un oeil à Ember App Kit qui repose sur ces technos
 
https://github.com/stefanpenner/ember-app-kit

 
Ce n'est pas une obligation ça.
 
Sinon, tu peux gérer des "redirections" avec Jekyll
 
https://help.github.com/articles/re [...] thub-pages

Les bouts du Gruntfile qui nous intéressent :
 

// Reads HTML for usemin blocks to enable smart builds that automatically
// concat, minify and revision files. Creates configurations in memory so
// additional tasks can operate on them
useminPrepare: {
    html: '<%= yeoman.app %>/index.html',
    options: {
        dest: '<%= yeoman.dist %>'
    }
},
 
// Performs rewrites based on rev and the useminPrepare configuration
usemin: {
    html: ['<%= yeoman.dist %>/{,*/}*.html'],
    css: ['<%= yeoman.dist %>/styles/{,*/}*.css'],
    options: {
        assetsDirs: ['<%= yeoman.dist %>']
    }
},
uglify: {
    dist: {
//     files: {
//         '<%= yeoman.dist %>/scripts/scripts.js': [
//             '<%= yeoman.dist %>/scripts/6d585c90.scripts.js'
//         ]
//     },
       options: {
           sourceMap: true
       }
    }
}

// Reads HTML for usemin blocks to enable smart builds that automatically
// concat, minify and revision files. Creates configurations in memory so
// additional tasks can operate on them
useminPrepare: {
    html: '<%= yeoman.app %>/index.html',
    options: {
        dest: '<%= yeoman.dist %>'
    }
},
 
// Performs rewrites based on rev and the useminPrepare configuration
usemin: {
    html: ['<%= yeoman.dist %>/{,*/}*.html'],
    css: ['<%= yeoman.dist %>/styles/{,*/}*.css'],
    options: {
        assetsDirs: ['<%= yeoman.dist %>']
    }
},
uglify: {
    dist: {
//     files: {
//         '<%= yeoman.dist %>/scripts/scripts.js': [
//             '<%= yeoman.dist %>/scripts/6d585c90.scripts.js'
//         ]
//     },
       options: {
           sourceMap: true
       }
    }
}

Aucune idée. mettre un trailing slash pour la dest avec useminPrepare ?

EAK semble utiliser grunt-concat-sourcemap pour générer.

https://github.com/stefanpenner/emb [...] urcemap.js

J'ai l'impression que c'est lié à ça : https://github.com/yeoman/grunt-usemin/issues/30 et ça : https://github.com/yeoman/grunt-usemin/issues/220 mais il semblerait que ce soit corrigé à partir de la v2, j'ai du mal à comprendre.

je ne m'y connais pas assez.
 
Donc faut débugger, lancer les commandes à la mano une à une, vérifier les fichiers générés pour identifier la commande qui ne fait pas son job, et ensuite utiliser --verbose pour lire plus en détail ce qu'elle fait (ou ne fait pas).
 
Il reste toujours la possibilité de lire le code du module pour comprendre ce qu'il fait réellement et s'assurer qu'on a correctement configuré cette tache.
 
C'est pas pour rien que des projets comme Ember App Kit ou ember-cli existent, globalement tout le monde fait, donc il n'y a pas d'intérêt à développer sa propre solution.

C'est à dire que c'est yeoman
 
Les tâches, individuellement, fonctionnent toutes correctement

 
Effectivement, ce n'est pas une obligation, mais ça implique de la bidouille (répertoires + index) ou utiliser Jekyll + permalink.
Même chose pour les redirections, il me semble que Jekyll se chargera dans ce cas de la génération des pages que j'évoquais non ?
 
Au pire, je pense que je calerais quelques temps le nouveau site sur le dédié actuel avec les 301 qui vont bien, puis migration vers GH en temps voulu.

ca me semble une bonne solution si tu ne veux pas trop te casser la tête.
 
Et je pars du principe que tu as suffisamment de liens entrants pour que la redirection soit un vrai problème.

 
Oui et non, ça reste à l'échelle d'un petit site. Les backlinks représentent 21% du trafic, mais je pensais surtout au référencement qui est pas dégueu pour le secteur.
 

y'en a parmis vous qui ont testé Ansible ou Salt ? vu que Vagrant le gère, ça me permettrait de garantir que mon serveur de dev est identique à la PROD en terme de provisionning...
 
j'aime bien l'approche masterless d'ansible, mais ils ont pas de client windows . D'un autre côté, c'est surement plus simple de monter une VM linux que d'avoir un petit serveur master pour piloter les minions salt

Ansible de notre coté au taf. Comme souvent avec ce genre d'outils, une fois que t'as compris comment ça fonctionne et écrire tes différentes "tâches", c'est plutôt bien. On a du fabric pour déployer et par exemple je me tâte a faire tout passer sur Ansible (ce dernier est venu plus tard).

J'ai un peu testé Ansible, mais j'ai été charmé par Salt. La courbe de progression est très rapide, en 2J j'avais mon parc sous contrôle. En plus avec le shell distribué, c'est parfait pour faire de la maintenance sur toutes mes machines d'un coup (MAJ etc).
 
De mon point de vue, c'est le meilleur rapport temps/résultat possible

@Sekyo : t'as joué avec Tower (la UI), ou tu utilisais une control machine avec les scripts
 
@Plam : tu es sous linux ? en fait ce qui me fait chier c'est que ma machine perso est sous win, donc je peux pas trop utiliser ces outils sans me monter une VM linux...je me demande si le plus simple c'est pas de prendre un pauvre VPS genre DigitalOcean à 5€ / mois...

Yep, j'suis sous Linux. Si tu veux un SaltMaster, je te conseille en effet d'avoir un linusque sous la main.

Niveau RAM je te conseille pas moins de 1 gigo (le plan à 10$ chez DO).

La doc de départ qui fait l'intérêt de Salt : http://docs.saltstack.com/en/lates [...] rough.html (ce qui fait qu'en 2J j'avais mon infra sous contrôle).

Mon process : dépôt Git pour la conf du Salt master, comme ça avec mon associé on ajoute ce dont on a besoin tout en gardant trace de qui fait quoi (dépôt sur notre GitLab hébergé chez nous, c'est plus sûr). Et après ça crache tout seul. Ça me sert aussi à faire mes MAJ sur toutes mes machines d'un coup (« salt '*' pkg.upgrade » et voilà )

edit : et si ton master s'appelle salt.tondomaine.tld, rien à configurer sur les clients

Ce serait pour contrôler une poignée de machine, je m'en fou si c'est lent

Mais merci pour les explications

Pas d'UI de notre coté, on fait tout en command line et en éditant à la mano nos playbooks.

Edit : Après on y touche pas tous les jours non plus hein, on est dev à la base, l'admin sys nous fait tous chier, du coup maintenant que c'est en place...

Pour forcer IE à utiliser la dernière version disponible et pas un mode de compatibilité à la con, j'ai ajouté la configuration suivante (tirée de h5bp) dans le vhost :  
 

 
La balise meta n'était pas prise en compte à cause des commentaires conditionnels autour de la balise HTML.
 
Ca fonctionne mieux puisque le mode de document est à IE8 (oui, je teste avec IE8 ) mais le mode de navigateur est en compatibilité IE8 (ça reste mieux qu'avant lorsqu'il se mettait en compatibilité IE7).
 
J'ai un doctype html 5 classique.
 
Vous avez des pistes ?

commentaires HTML autour de la balise HTML ? est-ce qu'il y a un commentaire HTML avant le <doctype> ?
Si c'est le cas ton IE reste en quirks mode en principe

 
Même sans les commentaires autour de la balise le mode du navigateur ne bouge pas, et pas de commentaire avant le doctype.

Le truc bizarre c'est que je n'ai pas l'icône du mode de compatibilité dans la bar d'adresse, juste les devtools qui m'indiquent que le mode du navigateur est en IE8 Compatibility view. Le user agent est celui d'IE7 toutefois...

J'aimerais récupérer la valeur d'un cookie par CORS via angular

Mais je trouve pas comme faire. C'est possible ?

Je fais l'appel en local et sur la machine de https://un-site-a-moi.com/ jai configuré apache pour avoir

Mais pour l'instant je n'arrive pas à choper l'info cookie contenu dans les request headers/request cookies
Je fais quoi de faux ?

 
Personne   ?
 
https://developer.mozilla.org/en-US [...] redentials
 
Moi ce que je voudrais c'est récupérer la valeur de Cookie Ligne 11

http://stackoverflow.com/questions [...] t-via-cors
 

 
Mouais je vais me faire une page json qui me renverra l'info et basta ! Merci

J'en étais également arrivé à cette conclusion

Ou tu fous ça dans les responses headers

Sauf si tu as la contrainte IE9-

Sur nos services Angular nous appliquons le module pattern afin de n'exposer que les "vrais" méthodes des services.
Le problème c'est qu'en suivant ce design pattern je ne vois pas comment tester les fonctions privées.
 
Hier après une petite discussion sur IRC deux types m'ont expliqués que dans une API il ne fallait tester que la partie publique et que normalement celle-ci testait implicitement la partie privée.
 
Sauf que pour moi, c'est la partie privée qui est la plus importante, c'est là où réside toute la logique des services. Les fonctions sont le plus unitaires possibles et réalise de nombreux calculs sensibles pour l'application.
 
Si je ne teste que la partie publique (qui en gros ne fait que setter et tester des variables pour appeler les différentes fonctions privées) je ne sais pas ce qui pète, je ne teste pas unitairement mes fonctions sensibles et mon code est selon moi moins robuste.
 
Qu'est-ce que vous en pensez ? Vous feriez quoi à ma place, virer le module pattern, tout rendre publique et testable ? J'ai choisi un mauvais design ?

Alors c'est à l'api d'avoir ses propres tests, et normalement elle peut se tester elle meme,non?

 
Wut?
Oublie API, pense juste service, avec une partie publique et privée.