Sous macos/ios, ya des nouveautes qui sortent, genre sparrow ou mailbox.
Meme Mail.app s'est offert un lifting ya pas si longtemps que ca, avec une recherche diaboliquement efficace, et une vue en fil qui defonce tout.
Comment on sait que le texte "Contact" en haut à droite, ou "send" en bas à droite sont des boutons?
T'as prit la mauvaise appli a critiquer, les core apps d'iOS sont justement très bonnes la dessus, et de bons exemple de design epure très bien réussi. Ils sont pas cons non plus, ils ont passe beaucoup de temps dessus.
Ca marche très bien en pratique, parce que le concept de "tint color" est parfaitement respecte dans les core apps. absolument tout est helvetica neue black, SAUF ce avec quoi tu peux interagir, qui est de la tint color.
Ils se servent évidemment d'un minimum de connaissance, la flèche "back" est un bon indice par exemple que "bleu = action", le fait que le titre soit noir et le reste bleu aide a différencier et a comprendre que "Edit" n'est pas juste du texte (contraste). Pour send, il change de couleur quand tu commences a taper, et est en plein dans la region ou tu focalises ton attention, la encore un indice que c'est pas juste du texte.
Les quelques exceptions se basent sur un concept somme tout naturel dans une interface tactile: tu pointes du doigt ce que tu veux éditer. Tu veux changer la date de ton meeting? tu tapes sur la date, c'est assez naturel pour le cerveau le concept de "pointer du doigt pour ca la". Tu ferais pareil sur un calendrier physique - tu pointerais avec ton stylo ou mettrais inconsciemment ton doigt dessus en te demandant si la date convient.
Ce qui est sur, c'est que c'est vachement plus difficile de designer de cette façon, surtout après avoir prit les habitudes "méchant bezel, gloss de malade et ombre de 15pts sur tout ce qui est interactif".
iTunes a failli se faire avoir, et les designers ont fait marche arrière sur les bouton sans bordures. C'est pas interdit, c'est juste pas le look par défaut.
Ce qui est réellement important dans ce design, c'est la cassure nette avec le skewormophisme. LE fait que ca soit epure et des aplats on s'en fout un peu (et encore, ios7 est plein de gradients et degrades).
Les interfaces n'ont pas d'equivalent dans le monde réel, et ce genre d'analogie ne va que rarement très loin. Au final, tu peux faire un truc bien plus facile a comprendre avec beaucoup plus de feedback quand tu ne suis pas les analogies du monde reel. Genre les bouttons qui changent de couleur, puis morphent dans un cercle qui se remplit (App Store/itunes), par example. Ou les boutons qui se remplissent quand tu tapes dessus (plus clair et meilleur feedback qu'un état "appuyé" qui peut être difficile a distingue, et moins d'infos a parser). Les "checkbox" sont aussi bien plus agréables, et le morphing du bouton lors du changement d'état ne choque pas le cerveau parce que justement ca n'a pas un aspect reel.
Il faut juste bootstrapper les cerveaux sur les quelques, rares conventions de base.
Effectivement, t'en sais visiblement rien.
Dans le genre sobre et tristounet, macosx s'impose. tout est gris (ou noir), calme, pose. Les dégradés deviennent de plus en plus discret et les rares animations sont la pour donner une reference visuelle (genre le mail qui "sort" du thread quand on répond dans mail).
C'est sur que si ta reference, c'est panther ou tiger, ca a evolue depuis…
Le flat design n'est surement pas une revolution ergonomique… Tout au plus une evolution graphique…
C'est pas une revolution en soi, mais c'estla consequence d'une nouvelle ere.
La raison pour laquelle iOS était aussi skewomorphique, c'est parce que, d'une part, steve jobs avait parfois un gout de chiottes, d'autre part (surtout), parce que les interfaces soft ET hard étaient tellement nouvelle qu'il fallait vraiment enfoncer les portes avec de grosses aides visuelles.
Passes qq années, des centaines de millions de devices vendus, et le public qui passe plus de temps sur son telephone qu'un pc, ce besoin se fait moins sentir, et on peut donc passer a un design un peu plus plaisant esthétiquement et surtout moins lourd. J'ai rien contre la ronce de noyer et le cuir relie, mais bon… ca fatigue.
Note qu'apple insiste lourdement sur le fait que ce n'est pas "plat". Ya des plans et une perspective, leur blur le rappelle bien et leur effets de parallaxe aussi - tout l'os est bâti autour de différents plans.
J'oubliais: apple ici beneficie de son esperience avec sa transition 64 bits sur macosx.
Ca leur a prit longtemps pour operer la transition, et ils sont tres bien places pour savoir que ca ne peut pas se faire du jour au lendemain.
L'essentiel de leur gamme est 64 bits, attends 6 mois et ca sera 100%.
Dans 3-4 ans, on aura un parc 100% 64 bits. Imagine ou en sera le developement mobile dans 4 ans. la barre des 2Go de ram aura probablement ete explosee, et avec les besoins grandisssants, probablement largement exploitee.
Ca se discute.
L'a7 est visibilement un monstre (pour un cpu mobile, j'entends…), mais effectivement je doute que ca soit principalement du au 64 bits.
Le runtime objc, par contre, en beneficie enormement. Les pointeurs 64 bits, ca leur permet de stocker un paquet d'infos dans les pointeurs directement, ce qui fait gagner un temps fou en dereferencement (retain count, weak references et ce genre de choses accedees en permanence). Cf les articles de greg parker et mike ash. Ca par contre, c'est 100% grace au 64 bits.
L'abi est un aussi drastiquement plus simple, encore qu'a ecouter greg parker, c'est principalement parce qu'elle a ete concue autour d'objc, donc c'est un cas particulier.
Mefies toi un peu du web, ou en tout cas n'y entres pas en te disant que tu vas "faire du ror".
Le web est un milieu hyper dynamique, et les technos vont et viennent tous les 2 ans, donc tu feras "techno qui a le vent en poupe en ce moment", ou "techno qui avait le vent en poupe ya 3-5 ans", en fonction de ton creneau.
Ror etait chaud bouillant ya un an ou deux. Avant c'etait django. Avant c'etait je sais pas quoi.
Maintenant, c'est node le truc qui depote tout, probablement pour encore 12-18 mois.
Cote client, c'est pareil, ya un nouveau framework js qui depote tout qui arrive tous les 12-18 mois. Et yen a qui veulent compilo le js, d'autres pas, d'autres qui veulent dart, et ci, et ca. Personne est d'accord et rivalise d'imagination pour la techno du futur, sort un truc, le maintient qq mois et passe a autre chose.
Non, ror ne va pas disparaitre demain, ni apres demain, pareil pour django et tout le reste, mais c'est tres dangereux de miser tes billes sur une techno particuliere dans ce domaine.
C'est pas forcement une critique du milieu ('fin si, ce genre de conneries distrait de ce qui est vraiment important, le produit, mais c'est pas le sujet), mais faut apprendre a faire avec, et etre a l'affut du domaine pour ajouter une techno a son arc quand elle emerge.
Surtout si tu viens du milieu hardware, avec j'imagine des cycles produit plutot long. Dans le milieu web, moins d'une release tous les 15 jour et tu joues un jeu dangereux. Ca va vite, tres tres vite. La philosophie qui predomine c'est plutot "on sait qu'on va livrer une palanquee de bugs, alors plutot que de faire de la qa avant de mettre en prod, on met tout en prod, et on fait tourner tous les tests sur le site de production, avec une palanquee de moniteurs pour nous dire quand on a chie dans la colle".
Dit autrement, c'est pas grave de shipper de la merde, tant que tu reagit suffisament vite pour que ca fasse pas un gros impact sur le business. Bref, attends toi a plus qu'un changement de techno, mais a aborder l'ingenierie sous un angle tres different :)
Alors t'as réussi a googler un symbole obscure pour _stret_machin sur une DP sous NDA, mais t'as pas été foutu de faire "build for 10.6 on xcode5", qui te donne la bonne réponse en premier lien?
Ca va, arretes.
Non, tu trolles comme un fou, c'est tout. Cherches pas a te rattraper aux branches.
T'es pas oblige d'exprimer un avis sur tout, particulièrement sur les sujets que tu maitrises pas du tout, et qu'au final, t'as surtout un avis.
On va dire qu'il faut connaitre l'esprit de la chose :).
Effectivement, c'est un metier d'être developeur, faut connaitre les outils, et tout. C'est vachement plus dur que de troller sur linuxfr, tu peux meme pas lui raconter n'importe quoi au compilo!!!
Sinon, pour info, le base SDK c'est ce contre quoi le compilo fait les checks de deprecation et autres trucs du style. En gros, si t'as un base SDK a 10.9 et que t'utilises des API deprecated dans 10.9, il va te le dire. Si tu met le base SDK a 10.8, il te dira rien. C'est une aide pour dropper le support des anciens os, ni plus ni moins.
La deployment target, c'est, ben, la deployment target. Ce sur quoi tu vas deployer. 10.4 si tu veux, presque 10 ans.
En clair: tu choisis 10.6 dans le tab "Info" pour la deployment target, et t'es bon. 'tin, t'as pas du chercher bien loin quand meme.
Probablement pas non. pas un mal cela dit. Comme dit plus haut, xcode 4 et 5 ouvrent très bien les projets xcode 3.
Ca m'interesse, j'aimerai compiler pour Mac OS X 10.6 sur mon Mac OS X 10.9, et le plus petit SDK que j'ai est10.8…
gnii? Base SDK != deployment target. Va falloir aller faire un tour sur developer.apple.com mon canard.
Project settings, target, tab general, "min deployment version", ca remonte jusqu'a 10.4 chez moi… Marrant, ca correspond au premier OS x86 d'apple. C'est une sacre coincidence dis donc.
Effectivement, apple va pas se faire chier a te livrer le sdk 10.6, mais mon petit doigt me dit que c'est parce que 10.8 est backward compatible. Fouya, sont pas cons chez apple dis donc! Faut arrêter de troller 5 minutes des fois.
La, je viens de compiler sous 10.9, en utilisant aucune fonction 10.9, mais ça crash car le compilo a "optimisé" une fonction tout seul comme un grand.
Et t'utilises toujours la developer preview plus de 6 mois après la sortie de la GM?!?! Ca va quoi, arrêtes de raconter des conneries 5 minutes, soit tu ments, soit t'es un idiot de premiere.
Bon sinon, -mmacosx-version-min, c'est pas fait pour les chiens. C'est sur que si tu targets 10.9 depuis 10.9, ben le compilo il va linker contre 10.9. Et l'optimisation de LLVM elle va vachement moins bien marcher la (bourvil inside). Apres, si tu dit a LLVM que tu target 10.8 ou avant, il est pas trop con, et il va te chercher les bons symboles.
T'as lu et compris le lien que t'as copie ou bien?
Il ouvre, mais en fait… Non.
Ben ecoutes, je viens de ressortir du placard un vieux, vieux, vieux projet, datant de xcode 3.qqchose.
Ca date de debut 2010, au final ce que j'ai eu a faire:
- base sdk non present: une combo box a changer
- deployment target a choisir (10.6 donc, puisque tu tiens tant que ca a utiliser des os dépasses)
- correction de path hardcodes dans le projet. Ouais, /Users/groumly/projet/ dans le header search path, c'était pas très malin. J'etais jeune et con. Maintenant je suis juste con
- cmd r. Paf. media info sur mon mac, un projet vieux de plus de 4 ans.
En face, à Cupertino, c'est plutôt marche ou crève.
Apple distribue toujours xcode 3, vieux de 7 ans, xcode 5 ouvre les vieux projets (a toi d'installer gcc par contre), les applis macosx vieilles de 7 ans marchent toujours (et probablement plus). Idem sous ios, la premiere appli sortie sur le store fonctionne toujours 6 ans plus tard, sans modifs.
C'st pas un probleme d'opinion personelle, mais d'action publique.
Il s'est engage, et a agit, publiquement contre le mariage homo en 2008, des couples ont perdus des droits ce jour la.
Ca fait tache dans une boite qui promeut le choix et la liberte, et ca donne une horrible image a mozilla (le ceo est un peu le representant public de la boite).
S'il se contentait de pas aimer les pedes et les gouines dans son coin, il serait toujours big boss de mozilla.
ca fait chier quand meme, et ca apporte pas forcement grand chose.
Les bonnes pratiques sont la pour une raison, j'entends pas beaucoup de raisons autres qu'un apparent dogme "une chaine hardcodee c'est mal".
Tu crees pas un #define quand tu fais "var = valeur - 1;", ni quand tu fais un "originX = (view.frame.size.width - label.frame.size.width) / 2.0f;".
Ben pour les chaines, parfois, c'est pareil (c'est juste).
La chaine est unique, utilisée a un seul endroit, et se décrit mieux elle meme que par un nom tordu et tarabiscoté, écrit tout en majuscule.
sauf que ce path est utilisé ici, et surement ailleurs.
T'as été vérifier?
qu'aujourd'hui c'est /run/programme/fichier
mais qu'il y a pas si longtemps c'etait /var/run
et que parfois c'est /run/user/programme/fichier
Vu que systemd impose une restriction forte sur ou ses binaires se trouvent, c'est pas délirant de considerer ca comme une réelle constante.
Et le jour ou ca change, ils vont faire quoi?
grepper sur /run/machin. Le fait que ca puisse changer un jour ne justifie pas un #define public. Ce qui justifie un #define public, c'est que ca soit une constante publique, utilisée par different composant.
Si c'est une constante privée a cette implementation (et ca a l'air d'etre le cas, vu comment elle est precise), ca a rien a faire dans un .h, sinon ca devient une api publique, et c'est une très mauvaise chose de l'exposer publiquement si c'est du prive.
Si c'est une constante privée utilisée une seule fois dans le fichier, bah #define ou pas, c'est surtout une question de gout. Perso, dans ce cas, j'inline, point barre. J'ai pas envie de me taper une dégueulante de #defines en haut du fichier, ca masque les vraies constantes intéressantes, et ca fait chier quand je veux savoir ce qu'il y a précisément dans cette constante.
Les deux styles se tiennent, je qualifierais pas l'un ou l'autre de crade, en tout pas a partir d'un snippet aussi court, sans voir le contexte.
Et tant que t'en es a donner des leçons, tu l'appellerais comment toi, cette constante?
Ca se discute, et ca depend beaucoup de l'architecture et du code.
La constante va eloigner la definition de l'utilisation de la constante. Ca force a une indirection si on veut verifier la valeur de la constante, et si y'a pas de bonnes raisons pour que la valeur change un jour, ca fait pas une grosse difference que la constante soit dans Constants.h, perdue au milieu de 450 autres constantes, ou dans implementation.c.
Rajoute par dessus qu'il faut lui trouver un nom a cette constante, ce qui est pas forcement evident si le valeur suffit a se décrire très bien elle meme.
Je sais, t'aimes bien les règles strictes et rigides, mais la réalité ne marche pas comme ca.
Tu le sous entends tres fortement avec des trucs du genres
"Un bon produit ça ne suffit pas, et c'est à mon avis loin d'être nécessaire", on encore a pretendre que billou a gagne seulement grace a un gros budget marketing.
Sinon, il prend son temps le debut de windows phone, hein, ca fait qq annees qu'il est sorti quand meme, pas loin de 4 ans quand meme.
prend le nouveau mot de passe, retire le premier/denier caractère, genere des hash avec des numéros en premier/denier caractère, compares avec les anciens hashs.
Ca attrape probablement 95% des "réutilisations de mot de passe precedents". L'idee c'est justement que le mot de passe change a peine, c'est pas trop dur de tester une 20-aine de variations pour voir si on tombe sur un hash precedent.
Ben faut comprendre la config de l'outil, efffectivement, mais la ya pas grand chose qu'on peut y faire, c'est de la semantique.
La difference, c'est que le format est 100% specifie. Pas d'embrouille sur l'encodage, pas de question a la con "les trailing spaces sont ils inclus dans la valeur ou pas", si ma valeur contient "=", est ce que ca va pasrser, et c'est quoi les caracteres pour les commentaires deja, multiligne ou pas, imbriques ou pas, l'ordre des elements est il conserve, est ce que mon document est valide.
C'est ca l'interet de xml, en plus d'offrir une lib dans tous les languages qui existent pour que le developeur puisse se concentrer sur autre chose que de creer des bugs et des buffers overflow sur le code qui lit la config.
Le probleme de maven, c'est pas le xml, c'est maven.
Le xml de maven est en soit plutot simple et assez naturel, quelques top level element, avec des noms comprehensibles, des sous elements simple a comprendre.
La ou ca devient couillu,c 'est les 40 millions de features de maven. Bon, apres, ces features elles sont la pour une raison, mais ca c'est un autre debat.
Ben ouais, mais bon, en gros tu glisses sous le tapis la partie compliquee, a savoir stocker les cles et les rapatrier sur tes nodes.
Il va te falloir un encrypted databag pour ton pass de db, donc une autre cle a garder au chaud, faut bien mettre la db qq part, la backuper, va te falloir une interface d'admin parce que les insert values dans psql, ca va 5 minutes.
Pis apres tu vas te rendre compte que tu veux pas donner acces a tout le monde a toutes les machines du meme environment, alors tu vas commencer a rajouter des roles.
Je dit pas que t'as tord d'approcher le probleme comme ca, je dis juste que pbpg a raison, ca va pas te prendre 5 minutes, et pas 2 heures non plus.
Chef a un cookbook user qui fait ca pour toi.
Pas gagne que ce cookbook gere ldap ou une db, ca passe par des databags de base. Et ca fait clairement pas tourner les cles non plus (encore que ca, ca doit etre assez pete couille au quotidien).
Bon apres, chef, c'est de la balle, mais quand tu met le doigt dedans, t'es parti pour 3 mois a revoir toute ton infrastructure.
Non pas que ca soit une mauvaise chose, mais pbpg a pas tord de traiter l'autre clown de clown.
[^] # Re: claws-mail
Posté par groumly . En réponse au journal Thunderbird : j'en peux plus ! Qui arrive à l'utiliser pour de vrai ? Quoi d'autre ?. Évalué à 1.
Les clients lourds sont linux.
Sous macos/ios, ya des nouveautes qui sortent, genre sparrow ou mailbox.
Meme Mail.app s'est offert un lifting ya pas si longtemps que ca, avec une recherche diaboliquement efficace, et une vue en fil qui defonce tout.
[^] # Re: J'aime bien
Posté par groumly . En réponse au journal Et toi, t'en penses quoi du flat design?. Évalué à 5.
T'as prit la mauvaise appli a critiquer, les core apps d'iOS sont justement très bonnes la dessus, et de bons exemple de design epure très bien réussi. Ils sont pas cons non plus, ils ont passe beaucoup de temps dessus.
Ca marche très bien en pratique, parce que le concept de "tint color" est parfaitement respecte dans les core apps. absolument tout est helvetica neue black, SAUF ce avec quoi tu peux interagir, qui est de la tint color.
Ils se servent évidemment d'un minimum de connaissance, la flèche "back" est un bon indice par exemple que "bleu = action", le fait que le titre soit noir et le reste bleu aide a différencier et a comprendre que "Edit" n'est pas juste du texte (contraste). Pour send, il change de couleur quand tu commences a taper, et est en plein dans la region ou tu focalises ton attention, la encore un indice que c'est pas juste du texte.
Les quelques exceptions se basent sur un concept somme tout naturel dans une interface tactile: tu pointes du doigt ce que tu veux éditer. Tu veux changer la date de ton meeting? tu tapes sur la date, c'est assez naturel pour le cerveau le concept de "pointer du doigt pour ca la". Tu ferais pareil sur un calendrier physique - tu pointerais avec ton stylo ou mettrais inconsciemment ton doigt dessus en te demandant si la date convient.
Ce qui est sur, c'est que c'est vachement plus difficile de designer de cette façon, surtout après avoir prit les habitudes "méchant bezel, gloss de malade et ombre de 15pts sur tout ce qui est interactif".
iTunes a failli se faire avoir, et les designers ont fait marche arrière sur les bouton sans bordures. C'est pas interdit, c'est juste pas le look par défaut.
Ce qui est réellement important dans ce design, c'est la cassure nette avec le skewormophisme. LE fait que ca soit epure et des aplats on s'en fout un peu (et encore, ios7 est plein de gradients et degrades).
Les interfaces n'ont pas d'equivalent dans le monde réel, et ce genre d'analogie ne va que rarement très loin. Au final, tu peux faire un truc bien plus facile a comprendre avec beaucoup plus de feedback quand tu ne suis pas les analogies du monde reel. Genre les bouttons qui changent de couleur, puis morphent dans un cercle qui se remplit (App Store/itunes), par example. Ou les boutons qui se remplissent quand tu tapes dessus (plus clair et meilleur feedback qu'un état "appuyé" qui peut être difficile a distingue, et moins d'infos a parser). Les "checkbox" sont aussi bien plus agréables, et le morphing du bouton lors du changement d'état ne choque pas le cerveau parce que justement ca n'a pas un aspect reel.
Il faut juste bootstrapper les cerveaux sur les quelques, rares conventions de base.
[^] # Re: Bon goût ?
Posté par groumly . En réponse au journal Et toi, t'en penses quoi du flat design?. Évalué à 1.
Effectivement, t'en sais visiblement rien.
Dans le genre sobre et tristounet, macosx s'impose. tout est gris (ou noir), calme, pose. Les dégradés deviennent de plus en plus discret et les rares animations sont la pour donner une reference visuelle (genre le mail qui "sort" du thread quand on répond dans mail).
C'est sur que si ta reference, c'est panther ou tiger, ca a evolue depuis…
[^] # Re: pas de revolution
Posté par groumly . En réponse au journal Et toi, t'en penses quoi du flat design?. Évalué à 5.
C'est pas une revolution en soi, mais c'estla consequence d'une nouvelle ere.
La raison pour laquelle iOS était aussi skewomorphique, c'est parce que, d'une part, steve jobs avait parfois un gout de chiottes, d'autre part (surtout), parce que les interfaces soft ET hard étaient tellement nouvelle qu'il fallait vraiment enfoncer les portes avec de grosses aides visuelles.
Passes qq années, des centaines de millions de devices vendus, et le public qui passe plus de temps sur son telephone qu'un pc, ce besoin se fait moins sentir, et on peut donc passer a un design un peu plus plaisant esthétiquement et surtout moins lourd. J'ai rien contre la ronce de noyer et le cuir relie, mais bon… ca fatigue.
Note qu'apple insiste lourdement sur le fait que ce n'est pas "plat". Ya des plans et une perspective, leur blur le rappelle bien et leur effets de parallaxe aussi - tout l'os est bâti autour de différents plans.
[^] # Re: Pourquoi ?
Posté par groumly . En réponse au journal Canonical abandonne Ubuntu One. Évalué à 1.
J'oubliais: apple ici beneficie de son esperience avec sa transition 64 bits sur macosx.
Ca leur a prit longtemps pour operer la transition, et ils sont tres bien places pour savoir que ca ne peut pas se faire du jour au lendemain.
L'essentiel de leur gamme est 64 bits, attends 6 mois et ca sera 100%.
Dans 3-4 ans, on aura un parc 100% 64 bits. Imagine ou en sera le developement mobile dans 4 ans. la barre des 2Go de ram aura probablement ete explosee, et avec les besoins grandisssants, probablement largement exploitee.
[^] # Re: Pourquoi ?
Posté par groumly . En réponse au journal Canonical abandonne Ubuntu One. Évalué à 5.
Ca se discute.
L'a7 est visibilement un monstre (pour un cpu mobile, j'entends…), mais effectivement je doute que ca soit principalement du au 64 bits.
Le runtime objc, par contre, en beneficie enormement. Les pointeurs 64 bits, ca leur permet de stocker un paquet d'infos dans les pointeurs directement, ce qui fait gagner un temps fou en dereferencement (retain count, weak references et ce genre de choses accedees en permanence). Cf les articles de greg parker et mike ash. Ca par contre, c'est 100% grace au 64 bits.
L'abi est un aussi drastiquement plus simple, encore qu'a ecouter greg parker, c'est principalement parce qu'elle a ete concue autour d'objc, donc c'est un cas particulier.
[^] # Re: Un exemple
Posté par groumly . En réponse au journal Changement de domaine technique. Évalué à 6.
Mefies toi un peu du web, ou en tout cas n'y entres pas en te disant que tu vas "faire du ror".
Le web est un milieu hyper dynamique, et les technos vont et viennent tous les 2 ans, donc tu feras "techno qui a le vent en poupe en ce moment", ou "techno qui avait le vent en poupe ya 3-5 ans", en fonction de ton creneau.
Ror etait chaud bouillant ya un an ou deux. Avant c'etait django. Avant c'etait je sais pas quoi.
Maintenant, c'est node le truc qui depote tout, probablement pour encore 12-18 mois.
Cote client, c'est pareil, ya un nouveau framework js qui depote tout qui arrive tous les 12-18 mois. Et yen a qui veulent compilo le js, d'autres pas, d'autres qui veulent dart, et ci, et ca. Personne est d'accord et rivalise d'imagination pour la techno du futur, sort un truc, le maintient qq mois et passe a autre chose.
Non, ror ne va pas disparaitre demain, ni apres demain, pareil pour django et tout le reste, mais c'est tres dangereux de miser tes billes sur une techno particuliere dans ce domaine.
C'est pas forcement une critique du milieu ('fin si, ce genre de conneries distrait de ce qui est vraiment important, le produit, mais c'est pas le sujet), mais faut apprendre a faire avec, et etre a l'affut du domaine pour ajouter une techno a son arc quand elle emerge.
Surtout si tu viens du milieu hardware, avec j'imagine des cycles produit plutot long. Dans le milieu web, moins d'une release tous les 15 jour et tu joues un jeu dangereux. Ca va vite, tres tres vite. La philosophie qui predomine c'est plutot "on sait qu'on va livrer une palanquee de bugs, alors plutot que de faire de la qa avant de mettre en prod, on met tout en prod, et on fait tourner tous les tests sur le site de production, avec une palanquee de moniteurs pour nous dire quand on a chie dans la colle".
Dit autrement, c'est pas grave de shipper de la merde, tant que tu reagit suffisament vite pour que ca fasse pas un gros impact sur le business. Bref, attends toi a plus qu'un changement de techno, mais a aborder l'ingenierie sous un angle tres different :)
[^] # Re: Et alors ...
Posté par groumly . En réponse au journal Microsoft libère leur compilateur C#. Évalué à -2.
Ben voyons.
Alors t'as réussi a googler un symbole obscure pour _stret_machin sur une DP sous NDA, mais t'as pas été foutu de faire "build for 10.6 on xcode5", qui te donne la bonne réponse en premier lien?
Ca va, arretes.
[^] # Re: Et alors ...
Posté par groumly . En réponse au journal Microsoft libère leur compilateur C#. Évalué à 1.
Non, tu trolles comme un fou, c'est tout. Cherches pas a te rattraper aux branches.
T'es pas oblige d'exprimer un avis sur tout, particulièrement sur les sujets que tu maitrises pas du tout, et qu'au final, t'as surtout un avis.
[^] # Re: Et alors ...
Posté par groumly . En réponse au journal Microsoft libère leur compilateur C#. Évalué à 2.
Effectivement, c'est un metier d'être developeur, faut connaitre les outils, et tout. C'est vachement plus dur que de troller sur linuxfr, tu peux meme pas lui raconter n'importe quoi au compilo!!!
Sinon, pour info, le base SDK c'est ce contre quoi le compilo fait les checks de deprecation et autres trucs du style. En gros, si t'as un base SDK a 10.9 et que t'utilises des API deprecated dans 10.9, il va te le dire. Si tu met le base SDK a 10.8, il te dira rien. C'est une aide pour dropper le support des anciens os, ni plus ni moins.
La deployment target, c'est, ben, la deployment target. Ce sur quoi tu vas deployer. 10.4 si tu veux, presque 10 ans.
En clair: tu choisis 10.6 dans le tab "Info" pour la deployment target, et t'es bon. 'tin, t'as pas du chercher bien loin quand meme.
[^] # Re: Et alors ...
Posté par groumly . En réponse au journal Microsoft libère leur compilateur C#. Évalué à 1.
Probablement pas non. pas un mal cela dit. Comme dit plus haut, xcode 4 et 5 ouvrent très bien les projets xcode 3.
gnii? Base SDK != deployment target. Va falloir aller faire un tour sur developer.apple.com mon canard.
Project settings, target, tab general, "min deployment version", ca remonte jusqu'a 10.4 chez moi… Marrant, ca correspond au premier OS x86 d'apple. C'est une sacre coincidence dis donc.
Effectivement, apple va pas se faire chier a te livrer le sdk 10.6, mais mon petit doigt me dit que c'est parce que 10.8 est backward compatible. Fouya, sont pas cons chez apple dis donc! Faut arrêter de troller 5 minutes des fois.
Et t'utilises toujours la developer preview plus de 6 mois après la sortie de la GM?!?! Ca va quoi, arrêtes de raconter des conneries 5 minutes, soit tu ments, soit t'es un idiot de premiere.
Bon sinon, -mmacosx-version-min, c'est pas fait pour les chiens. C'est sur que si tu targets 10.9 depuis 10.9, ben le compilo il va linker contre 10.9. Et l'optimisation de LLVM elle va vachement moins bien marcher la (bourvil inside). Apres, si tu dit a LLVM que tu target 10.8 ou avant, il est pas trop con, et il va te chercher les bons symboles.
T'as lu et compris le lien que t'as copie ou bien?
Ben ecoutes, je viens de ressortir du placard un vieux, vieux, vieux projet, datant de xcode 3.qqchose.
Ca date de debut 2010, au final ce que j'ai eu a faire:
- base sdk non present: une combo box a changer
- deployment target a choisir (10.6 donc, puisque tu tiens tant que ca a utiliser des os dépasses)
- correction de path hardcodes dans le projet. Ouais, /Users/groumly/projet/ dans le header search path, c'était pas très malin. J'etais jeune et con. Maintenant je suis juste con
- cmd r. Paf. media info sur mon mac, un projet vieux de plus de 4 ans.
[^] # Re: Et alors ...
Posté par groumly . En réponse au journal Microsoft libère leur compilateur C#. Évalué à 1.
Apple distribue toujours xcode 3, vieux de 7 ans, xcode 5 ouvre les vieux projets (a toi d'installer gcc par contre), les applis macosx vieilles de 7 ans marchent toujours (et probablement plus). Idem sous ios, la premiere appli sortie sur le store fonctionne toujours 6 ans plus tard, sans modifs.
[^] # Re: Dérangeant....
Posté par groumly . En réponse au journal Journal bookmark. Évalué à 8.
C'st pas un probleme d'opinion personelle, mais d'action publique.
Il s'est engage, et a agit, publiquement contre le mariage homo en 2008, des couples ont perdus des droits ce jour la.
Ca fait tache dans une boite qui promeut le choix et la liberte, et ca donne une horrible image a mozilla (le ceo est un peu le representant public de la boite).
S'il se contentait de pas aimer les pedes et les gouines dans son coin, il serait toujours big boss de mozilla.
[^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
Posté par groumly . En réponse au journal Systemd vs Linux, quand l'intransigeance d'un développeur tourne au ridicule.... Évalué à 2.
ca fait chier quand meme, et ca apporte pas forcement grand chose.
Les bonnes pratiques sont la pour une raison, j'entends pas beaucoup de raisons autres qu'un apparent dogme "une chaine hardcodee c'est mal".
Tu crees pas un #define quand tu fais "var = valeur - 1;", ni quand tu fais un "originX = (view.frame.size.width - label.frame.size.width) / 2.0f;".
Ben pour les chaines, parfois, c'est pareil (c'est juste).
La chaine est unique, utilisée a un seul endroit, et se décrit mieux elle meme que par un nom tordu et tarabiscoté, écrit tout en majuscule.
[^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
Posté par groumly . En réponse au journal Systemd vs Linux, quand l'intransigeance d'un développeur tourne au ridicule.... Évalué à 0.
T'as été vérifier?
Vu que systemd impose une restriction forte sur ou ses binaires se trouvent, c'est pas délirant de considerer ca comme une réelle constante.
Et le jour ou ca change, ils vont faire quoi?
grepper sur /run/machin. Le fait que ca puisse changer un jour ne justifie pas un #define public. Ce qui justifie un #define public, c'est que ca soit une constante publique, utilisée par different composant.
Si c'est une constante privée a cette implementation (et ca a l'air d'etre le cas, vu comment elle est precise), ca a rien a faire dans un .h, sinon ca devient une api publique, et c'est une très mauvaise chose de l'exposer publiquement si c'est du prive.
Si c'est une constante privée utilisée une seule fois dans le fichier, bah #define ou pas, c'est surtout une question de gout. Perso, dans ce cas, j'inline, point barre. J'ai pas envie de me taper une dégueulante de #defines en haut du fichier, ca masque les vraies constantes intéressantes, et ca fait chier quand je veux savoir ce qu'il y a précisément dans cette constante.
Les deux styles se tiennent, je qualifierais pas l'un ou l'autre de crade, en tout pas a partir d'un snippet aussi court, sans voir le contexte.
Et tant que t'en es a donner des leçons, tu l'appellerais comment toi, cette constante?
[^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
Posté par groumly . En réponse au journal Systemd vs Linux, quand l'intransigeance d'un développeur tourne au ridicule.... Évalué à 6.
Ca se discute, et ca depend beaucoup de l'architecture et du code.
La constante va eloigner la definition de l'utilisation de la constante. Ca force a une indirection si on veut verifier la valeur de la constante, et si y'a pas de bonnes raisons pour que la valeur change un jour, ca fait pas une grosse difference que la constante soit dans Constants.h, perdue au milieu de 450 autres constantes, ou dans implementation.c.
Rajoute par dessus qu'il faut lui trouver un nom a cette constante, ce qui est pas forcement evident si le valeur suffit a se décrire très bien elle meme.
Je sais, t'aimes bien les règles strictes et rigides, mais la réalité ne marche pas comme ca.
[^] # Re: oh bah heu... merci :)
Posté par groumly . En réponse à la dépêche 100 développeurs : la part belle à l’Open Source. Évalué à 2.
Tu le sous entends tres fortement avec des trucs du genres
"Un bon produit ça ne suffit pas, et c'est à mon avis loin d'être nécessaire", on encore a pretendre que billou a gagne seulement grace a un gros budget marketing.
Sinon, il prend son temps le debut de windows phone, hein, ca fait qq annees qu'il est sorti quand meme, pas loin de 4 ans quand meme.
[^] # Re: oh bah heu... merci :)
Posté par groumly . En réponse à la dépêche 100 développeurs : la part belle à l’Open Source. Évalué à 3.
Ben voyons. Et l'apple II, il s'est vendu grace a la pub?
Ben voyons. Le succes de la surface ou de windows phone est la pour le prouver, le marketing et la pub les a propulse en haut des ventes.
[^] # Re: Et si c'était l'outil fourni qui était mauvais?
Posté par groumly . En réponse au journal So, you wanna be a sysadmin ? (Trolldi inside). Évalué à 3.
C'est pas bien complique de generer qq dizaines de variantes du nouveau mot de passe et de comparer les hashs aux anciens, hein.
[^] # Re: Et si c'était l'outil fourni qui était mauvais?
Posté par groumly . En réponse au journal So, you wanna be a sysadmin ? (Trolldi inside). Évalué à 2.
prend le nouveau mot de passe, retire le premier/denier caractère, genere des hash avec des numéros en premier/denier caractère, compares avec les anciens hashs.
Ca attrape probablement 95% des "réutilisations de mot de passe precedents". L'idee c'est justement que le mot de passe change a peine, c'est pas trop dur de tester une 20-aine de variations pour voir si on tombe sur un hash precedent.
[^] # Re: 2 poids, 2 mesures
Posté par groumly . En réponse au journal <3 goto. Évalué à 2.
Honnetement, je serais surpris que libsecurity ait plus de 2 ingenieurs full time.
Les equipes chez apple tendent a etre plutot petites.
[^] # Re: XML n'a jamais été fait pour être compréhensible par l'homme
Posté par groumly . En réponse au journal XML c'est de la daube!!!. Évalué à 2.
Ben faut comprendre la config de l'outil, efffectivement, mais la ya pas grand chose qu'on peut y faire, c'est de la semantique.
La difference, c'est que le format est 100% specifie. Pas d'embrouille sur l'encodage, pas de question a la con "les trailing spaces sont ils inclus dans la valeur ou pas", si ma valeur contient "=", est ce que ca va pasrser, et c'est quoi les caracteres pour les commentaires deja, multiligne ou pas, imbriques ou pas, l'ordre des elements est il conserve, est ce que mon document est valide.
C'est ca l'interet de xml, en plus d'offrir une lib dans tous les languages qui existent pour que le developeur puisse se concentrer sur autre chose que de creer des bugs et des buffers overflow sur le code qui lit la config.
[^] # Re: XML n'a jamais été fait pour être compréhensible par l'homme
Posté par groumly . En réponse au journal XML c'est de la daube!!!. Évalué à 2.
Le probleme de maven, c'est pas le xml, c'est maven.
Le xml de maven est en soit plutot simple et assez naturel, quelques top level element, avec des noms comprehensibles, des sous elements simple a comprendre.
La ou ca devient couillu,c 'est les 40 millions de features de maven. Bon, apres, ces features elles sont la pour une raison, mais ca c'est un autre debat.
[^] # Re: Un élément à ajouter à la liste
Posté par groumly . En réponse au journal Fin du support de MS Windows XP. Évalué à 3.
Ben ouais, mais bon, en gros tu glisses sous le tapis la partie compliquee, a savoir stocker les cles et les rapatrier sur tes nodes.
Il va te falloir un encrypted databag pour ton pass de db, donc une autre cle a garder au chaud, faut bien mettre la db qq part, la backuper, va te falloir une interface d'admin parce que les insert values dans psql, ca va 5 minutes.
Pis apres tu vas te rendre compte que tu veux pas donner acces a tout le monde a toutes les machines du meme environment, alors tu vas commencer a rajouter des roles.
Je dit pas que t'as tord d'approcher le probleme comme ca, je dis juste que pbpg a raison, ca va pas te prendre 5 minutes, et pas 2 heures non plus.
[^] # Re: Un élément à ajouter à la liste
Posté par groumly . En réponse au journal Fin du support de MS Windows XP. Évalué à 3.
Chef a un cookbook user qui fait ca pour toi.
Pas gagne que ce cookbook gere ldap ou une db, ca passe par des databags de base. Et ca fait clairement pas tourner les cles non plus (encore que ca, ca doit etre assez pete couille au quotidien).
Bon apres, chef, c'est de la balle, mais quand tu met le doigt dedans, t'es parti pour 3 mois a revoir toute ton infrastructure.
Non pas que ca soit une mauvaise chose, mais pbpg a pas tord de traiter l'autre clown de clown.