LinkedIn pas mal de contacts pertinant de boîtes/cabinets qui cherchent vraiment des mecs (screening sérieux + itw sérieuse + payement de tous les frais d'itw + suivi). Quelques cabinets de merde, mais on les repère vite, donc /dev/null plus la publicité qu'ils méritent. Par contre relocalisation requise pour la plupart des jobs. En même tant quand on va chercher des gens pour leur filer un bon poste avec un bon salaire, la probabilité que ce soit à coté de chez toi si tu n'habites pas un des 10 spots de dévelopeurs au monde est mince… Si c'est pour recruter en local, je vois pas forcement l'intêret de linkedIn. Annonce locale dans les trucs spécialisés + aller faire un tour dans les meetup du coin est vachement plus pertinant…
Viado, que de la merde de SSII ou cabinet-Francais-pattern matching tout pourri. Bref c'est Monster quoi, pas de raison de s'embêter avec ca.
On peut aussi utiliser linkedin/twitter dans l'autre sens pour identifier les RH/recruteur/directeur techniques plutôt que de passer par le système normal de la boîte.
Je pense qu'il n'y a pas de technique générale. Chaque situation est différente et qu'on est rarement capable de l'identifier quand on est du côté candidat. Ca reste de la loterie.
L'important c'est de réussir à arriver soit au screening téléphonique, soit au moment où tu peux montrer ce que tu as a vendre et échanger avec les gens. Avant c'est juste réussir à faire tomber un boût de papier au bon endroit et attirer l'attention parmis une pile de papier plus où moins identiques pour qu'on te laisse t'exprimer.
En fait quand tu postules tu as deux mondes différents qui vont utiliser les informations :
Les gens techniques qui cherchent à identifier les profils sortant du lot avant de perdre du temps à faire les interview
Le reste du monde qui ne comprend rien aux informations que tu fournis, et qui va plus ou moins faire du pattern matching pour filtrer et rediriger vers les bonnes personnes (HR, cabinet de recrutement, SSII, systèmes de traitement automatisé des grosses boîtes etc.)
Ces deux mondes ont des critères diamétralement opposés et c'est la tout le problème.
Vire tout le bullshit et tu as une chance sur deux que ton CV n'aille jamais nul part. Mais de l'autre côté si tu pousses sans pouvoir l'expliquer tu te feras défoncer direct en technique.
Tout l'art est donc d'essayer de doser et d'adapter un peu en fonction de chaque situation:
Processus de recrutement (qui va lire/filtrer)
Besoins réels de la boîte. Certaines vont chercher de vrais experts dans une technos très précises, d'autre non.
Niveau de la boîte
Pas mal d'aléatoire
Mais ca reste de la lotterie. Pour l'anecdote, sur mes deux derniers postes je n'ai jamais eu la moindre réponse à mes candidatures par la voie normale avec CV technique + mot clés. Par contre en faisant suivre par l'intérieur aucun soucis. Les équipes n'avaient jamais vu l'ombre de ma candidature par la voie normale…
Ca peut aussi être très raisonnable de mettre un mot clé d'une techno à la mode si tu as beaucoup d'expérience du domaine en général. Il faut juste être très clair quand tu parles avec les gens, leur dire sans détour et avoir quelque chose à vendre. Exemple typique le mec qui à X années d'expérience dans le calcul distribué/data mining/machine learning, il peut mettre Hadoop sans hésiter sur son CV par ce que c'est actuellement utilisé comme mot clé de filtrage, alors que c'est rarement la compétence directement recherchée. Un mec qui ne le met pas, va rester invisible aux radars alors que son profil est pertinant.
Note: Je suppose que le mec est compétent, et qu'il a une stratégie raisonnable. Pas comme la montagne de boulet dont tu vois les CV passer.
Un entreprise qui a besoin de recruter ne va pas attendre la rentrée
C'est surtout que tu ne maitrises pas du tout la date d'embauche. Entre le moment où tu ouvres le poste et le moment où le mec arrive tu as en général 5/8 mois (trouver le mec, lui faire une offre, qu'il se décide, qu'il solde ses congés ou prenne une semaine ou deux, qu'il fasse son préavis). Parfois c'est bingo en étant beaucoup plus court.
"pause" d'Août est tellement encrée dans les mœurs que tout le monde trouve ça normal
C'est pas une question de trouver ça normal. C'est un fait, en France il n'y a absolument personne en Août toute profession confondu. Ca veut dire possibilité de pas avoir de lead pour valider, pas d'équipe si tu fais passer plusieurs entretient, pas de RH pour faire les papiers. Et vu que certains postes ont beaucoup moins de doublons que d'autres…
Vu la difficulté de recruter en Informatique (je me base sur mon expérience et des discussions avec d'autres responsables), dans ce domaine ça ne doit pas être la crise, non
Je vois pas trop le rapport. La crise pour qui ? Si personnes ne met des salaires et des projets en adéquation aux compétences des mecs et aux autres pays, bin t'as du mal à recruter mais ca ne veut pas dire grand chose non plus. Après oui les bons profils en France, faut les chercher vu comment on leur à donné envie de partir et qu'on veut pas de remote…
j'ai le sentiment que ça doit tendre vers le zéro bugs, zéro besoins avec le temps, non ?
Tout à fait. D'ailleurs si tu regardes comme suggéré "les programmes de base dans /bin de FreeBSD (difficile de faire plus vieux et plus basique tout en étant toujours utilisé)" tu le constates facilement. Une nouvelle fonctionnalité tous les 5 ans, le reste c'est de la maintenance impliqué par un environnement ou des pratiques qui bougent de temps en temps. Plus tu es bas niveau et indépendant, le cas de nos outils, plus c'est stable et figé. Plus tu es haut dans la pile logicielle, plus tu passes ton temps à maintenir le truc même avec zéro bugs et zéro besoin par ce que ton monde évolue en permanence.
Bien sur ca ne marche que pour les briques logicielles extrêmement bien définie, et "petites". Dès que le scope est un peu plus large, ça ne se stabilise jamais ca fini par étouffer sous son poids et mourir.
Attention je parle pour des équipes de dev ou assimilé. Pour des métiers réactifs et a interruption c'est un peu différent.
Mais dans tout les cas il très important de toujours savoir ce qu'on cherche à optimiser et ensuite de décider des mesures et des actions pour y parvenir. C'est extrêmement important de comprendre dans quel but sont collectés les métriques afin de les choisir judicieusement, et de reporter ce qui est utile: granularité, type de reporting, analyse à faire etc. Il faut aussi réfléchir aux différentes approches pour essayer d'atteindre l'objectif qu'on se donne. Le reporting n'est jamais une solution. Ca peut par contre être un outil temporaire ou une mesure à long terme dans un processus d'amélioration et gagnant de la connaissance sur soi même.
Je ne connais Scrum et autres méthodes Agiles que de nom, jamais eu le temps/dispo/[ mettez ce que vous voulez ici ] pour apprendre et mettre en place dans mon équipe
Le passage "service IT d'une PME" m'en fait douter. Mais citer Scrum n'était pas le point fort, juste un mauvais exemple du à un biais de dev.
Par contre le "jamais eu le temps/dispo/[ mettez ce que vous voulez ici ] pour apprendre et mettre en place dans mon équipe" me semble souligner le syndrome . Je vais caricaturer vu que je ne connais rien de ton cas ne m'en tiens pas rigueur, mais en gros tu collectes des données à postériori sans avoir de but ou de plan assurer la qualité produire et améliorer constamment ton équipe. Pourquoi perdre du temps à demander un reporting à grain fin ? Si l'objectif est suffisamment important pour justifier une action de toute ton équipe pourquoi ne pas prendre le temps pour réfléchir sérieusement à ton organisation afin d'augmenter significativement la productivité, la qualité ou les conditions de travail de ton équipe ?
Si c'est pour détecter les imprévus, pourquoi ne pas chercher le moyen le plus efficace de suivre ce points. Ce n'est surement pas une métrique à l'heure qui t'intéresse; mais d'avoir une idée du volume que ca représente, du taux d'interruption, de la fréquence, des sources, pour pouvoir prendre les actions pour protéger ton équipe.
Si c'est pour de la facturation, selon la taille de tes projets une estimation "gros grain" peut largement être suffisante et peut être faite par le management. Par exemple à la fois mon manager, mon project manager, mon scrum master et toute mon équipe seraient capable de fournir la même facturation que si on demande à chaque personne de le faire. Pourquoi faire perdre du temps à X personnes ? De même notre organisation nous permet d'avoir une connaissance de nos capacité et de notre planning que ne nous donnerait pas du time tracking. Ce n'est donc que de la perte.
Si c'est pour mesurer la qualité des projets (reporting au type de tâche). Alors là c'est juste de la connerie pur et dure car il n'y a aucune corrélation entre la métrique et l'objectif, c'est ultra couteux à reporter, et tout le monde va biaiser les entrées pour rentrer dans le stats et pas être emmerdé.
Encore une fois ce que je dis est extrêmement caricatural. L'idée c'est que je n'ai jamais vu d'utilisation utile et raisonnable du time tracking dans le but d'améliorer la production. Après ça peut être imposé par une politique de boîte ou des contraintes légales et là il faut juste exploiter le système pour fournir des stats dans le bon ordre de grandeur à moindre coût (typiquement je rapporte à la semaine ou au mois en agrégeant plutôt que faire 200 entrées ce qui n'a aucune valeur). Mais si on reste à des échelles où la logique à encore un sens, faut bien réfléchir aux raisons qui feraient mettre ça en place. On ne peut pas s’améliorer sans mesurer, mais mesurer ne veut pas dire qu'on s' améliore ni que c'est pertinent…
soft leger sur le poste du dev, qui trigger les commits, la branche git (ou tout autre cvs).
Bof. Sauf à faire du support ou ce genre de tâches qui marchent au ticket le temps passé derrière un ordi n'est pas du tout significatif:
Temps de conception à la poubelle
Temps de discussion à la poubelle
Pair programming à la poubelle pour au moins l'un des deux
Proto / test à la poubelle
Lire la doc, proto à la poubelle
Tests manuels à la poubelle
Écriture des docs à la poubelle
La détection des abscence est par nature foireuse
Même pour les tâches de dev et avec des outils automatiques c'est assez foireux au final.
Mais la vrai question c'est pourquoi faire chier les gens et leur faire perdre du temps avec ces conneries ? Les données soumises sont toujours pourries par ce qu'on n'a pas que ça à faire. Il n'y a rien à y apprendre que ne pourrait savoir par ailleurs avec une gestion correcte d'équipe ou de projet. Exemple si tu fais du Scrum, tu as la liste de stories de ton sprint, ta vélocité et donc tu as les mêmes infos avec une marge d'erreur similaire pour… 0 travail supplémentaire. Pour les plus acharnés du reporting tu peux aussi aller voir les tâches, et si ton équipe estime les tâches tu as de quoi te palucher pendant très longtemps. Au passage plutôt que d'apprendre le lundi matin suivant ce qu'à fait ton équipe, tu peux avoir une bonne estimation à l'avance, essayer de comprendre le fonctionnement de ton équipe, ses problèmes, ses axes d'ameilloration, prévoir les choses et observer quand, où et pourquoi ca dérape bref du vrai boulot de management. Le time tracking bête et méchant est pour moi vraiment le syndrome du mauvais management.
Ca me rappelle une boîte où l'outil de time tracking proposait genre 50 types de tâches pour chaque projet où tu es assignés… Ca fait des jolis rapports certe; mais ca sert à rien et ca fait perdre du temps à tout le monde. Soit l'effet inverse de l'objectif. D'ailleurs les gens reportaient biens qu'ils métaient 10x plus longtemps que dans toutes les autres boites mais c'était cohérent avec les stats globales ! Et tant qu'on peut facturer à la minute ou se palucher en sachant qu'on passe 19.75% de son temps à écrire de la doc tout va bien…
mais plusieurs points sont rédhibitoires : c'est du Java ;
Donc en gros être en Java est rédhibitoire pour une application dont le but est d'installer des applications Java. Ca me semble aussi logique qu'imparable !
Posté par ckyl .
En réponse au journal FreeBSD un OS sans avenir?.
Évalué à 3.
Dernière modification le 18 août 2013 à 20:32.
Ensuite, Linux dispose d'autres mécanismes de sécurité, comme SELinux, qui rendent une comparaison délicate.
MAC est disponible depuis FreeBSD 5. FLASK/TE, soit le modèle de SELinux, était dispo comme module MAC dans TrustedBSD vers 2006 mais il me semble que le merge final de Flask/TE n'a jamais été entièrement fait (je n'utilise plus FreeBSD depuis des années).
Après encore une fois, chroot n'est pas une mesure de sécurité…
Tu me parles de LaTex, mais il y a aussi Libreoffice, Firefox, etc …
Tu sais libreoffice hormis ouvrir "britney_spears_nue.doc" de la cousine du roi du nigéria qui cherche à placer son argent la surface d'exposition est maitrisée et maitrisable… Reste les clients connectés à internet.
Maintenant on dirait que tu as eu la révélation du siècle alors que tu viens de découvrir l'eau tiède. Comme tu le dis ca fait plus de dix ans que c'est comme ca, et s'en rendre compte prend au pire un mois. Si le système ne correspond pas à tes besoins bha il correspond pas à tes besoins. Pas besoin de cracher de la merde sur le projet.
Posté par ckyl .
En réponse au journal FreeBSD un OS sans avenir?.
Évalué à 8.
Dernière modification le 17 août 2013 à 16:21.
Pour résumer, je trouve que l'article de ton blog n'est qu'un exutoire à une mauvaise expérience vécu, qui n'a finalement que peu d'intérêt et qui ne m'aura rien apporté, et encore moins convaincu de ne pas utiliser cet OS.
T'es vachement dur tout de même. Les punchlines en gras ca fait vachement pro, genre journalisme d'investigation. Ca donne tout de suite du contenu à l'article.
En plus c'est du travail de fond. Trois ans de boulot pour se rendre compte ce qu'impliquait d'utiliser un système basé sur les sources. Tant de dévotion ça force le respect.
C'est un choix. Après pour des petits/moyens projets à partir du moment où tu as les fonctionnalités d'import/export tu t'en balances un peu vu que tu n'as pas de processus forts.
Voir le nombre de projets qui ont migrés vers github depuis bitbucket/googlecode ces dernières années, et qui rechangeront sans problème si une meilleure offre apparait.
Pas confiance en Atlassian, éditeur de logiciels propriétaires/privateurs merdiques en java.
Propriétaires, oui. Merdique, par contre là tu dois avoir un sérieux soucis. La plupart de leurs outils sont plutôt dans le haut du panier.
Tu présentes ton projet, je regarde (ce que tu dis, la doc, le code), je m'intéroge et je demande. Excuse moi (nous) de chercher de comprendre ce qui a été fait, pourquoi, comment et où ca peut aller plutôt que jouer à l'école des fans. Les questions sont: quels sont les avantages, quels sont les inconvéniants, quels sont limites, qu'est ce qui se passe quand on revient à fonctionnalités et userland égal, est ce qu'on ne laisse pas un trou qui rend cela inutile.
Maintenant si tu trouves ca inutile comme questions, pourquoi le présenter ?
PS: Je vais pas suivre la classique comparaison foireuse de voiture, mais justement les proto du 24h du Mans répondent à un besoin très précis avec de fortent contraintes et si tu en sors… ;)
le système est déjà auto-hébergé dans ces conditions, donc, ben, utilisable, il l'est
Dans la réponse sur mon autre commentaire tu nous expliques spécifiquement que ':w toto' ne fonctionne pas. Une application ne peut donc créer de nouveaux fichiers. Des petites fonctionalité genre "nouveau document" ou "Enregistrer sous". Des problèmes comme ca on peut en trouvé une infinité.
Soit je suis trop bête pour comprendre les subtilités de ton modèle et comment ca tient debout en dehors de "J'arrive à éditer mon fichier texte", soit ca ne tient pas debout pour un cas d'utilisation générique.
Sachant que tu as déjà commencer à introduire de nouveaux concepts type "il suffirait de patcher firefox pour", ou que l'exemple du ':!ls' ne te fasse pas percuter que c'est ce que les applications passent leur temps à faire j'ai un peu peur de ne pas être complétemment dans le faux. Si le seul truc qui reste c'est du MAC sur l'accès/écriture des fichiers, c'est techniquement faisable depuis longtemps juste presque impossible à mettre en oeuvre en dehors des démons.
Tu passes d'un truc à l'autre, c'est grossier là ;)
Empêcher de modifier le logiciel c'est faisable sans problème sur plein de systèmes (ou même tout ce qui n'est pas explicitement spécifié).
Empêcher deux instances différentes d'une même application d'accéder au même espace de nommage du FS c'est quelque chose de différent. Mais tu dois faire un choix. Soit tu segmentes complétement, et ton système n'est pas utilisable pour autre chose que quelque chose d'extrêment spécifique (voir pas utilisable tout court faudrait y réfléchir vraiment). Soit tu ne segmentes pas tant que ca en mergant automatiquement en fin d'execution, en utilisant des mécanismes spéciaux etc. Et là ton truc est troué. Tu peux écrire sur le FS, comme sur un système classique…
J'avais donc bien compris où tu voulais en venir. Malheureusement je n'y crois pas une seule seconde pour un système généraliste. C'est soit inutilisable soit une passoire, encore plus si tu ne veux pas patcher tout l'userland.
D'un point de vu démon, c'est à peu près jouable. Mais soit tu vas obtenir quelque chose de moins fin que ce qui est possible via les policy MAC, soit plus casse gueule qu'une VM vu la complexité du bordel. Sachant que tout le reste du système est à refaire ca sent pas bon.
D'un point de vu utilisateur c'est mort. Les applications communiquent entre elles, sont intégrées, et ont des accès larges et légitimes au système de fichier. Déjà avec ton simple exemple de vim tout seul dans ton coin tu t'englues dans les explications en imaginant déjà des cas spéciaux de fichiers éditables ou non reposant sur des white/black-list par application et de lanceur spéciaux pour une application. Et là on à même commencé à parler de la fuite d'information. Un ':e' dans ton vim il peut ouvrir ou pas un fichier ? Si oui c'est mort. Un ':w' il marche ? Un ':!ls' il marche ? Alors c'est mort pour l'isolation. Si la réponse est non alors tu as un système simplement inutilisable. On se souvient que là on parle d'un pauvre éditeur de texte dans son coin. Ca va devenir rigolo en généralisant la chose, en introduisant les mécanismes d'IPC etc.
Les politiques MAC sont super contraignantes, c'est pour ca qu'elle reste confinée où elles font sens.
A moins bien sûr que tu n'aies un second exploit jour zéro touchant cette fois les fichiers de configuration de vim.
Heu les fichiers de configuration de Vim sont turing complet…
Et c'est bien la que je ne vois pas comment ton truc peu marcher par ce que c'est simple il y a deux solutions:
Soit tu as des environnements, donc applications pour toi, entièrement isolés qui ne peuvent jamais se parler et la tu contients les débordements dans chaque environnement.
Soit tes environnements ont moyens de se parler (accès à un seul même fichier éditable dans l'un et lisible dans l'autre) et la c'est game over pour la sécu. À partir du moment ou tu as à access au FS d'un uid il est compromis.
Donc si on résume soit tu as un truc totallement inutilisable vu que tu segmentes par appliquation, ca me fait une belle jambe d'avoir un vim tout seul dans son coin… Soit tu as un truc pas plus secure que n'importe quel autre système.
C'est bien pour ca qu'usuellement on cloisone par unité logique. Tu pourrais vraiment nous expliquer correctement ton truc au moins conceptuellement ? On pourra regarder si la technique suit après.
Les sites en javascript discriminent les aveugles. On pourrait pas leur faire un procès ?
[…]
Je n’y connais pas grand chose, juste des discussions avec un copain dont le web est le métier et qui voulait rendre accessible les sites sur lesquels il travaillait.
Vous faites un concours avec l'autre qui explique que le bouton pour désactiver le Javascript est absolument vital alors que visiblement il ne s'en sert au max 3x dans l'année et qu'il y a des alternatives 10x plus pratiques ?
Sérieusement pourquoi sortir des arguments foireux et rajouter une couche robin des bois défenseurs des aveugles. Par ce que c'est super vachement important les aveugles hein ! Mais pas tant que ca apparemment, car si tu t'étais intéressé une seule fois au sujet tu ne dirais pas des anneries.
Je t'invite par exemple à chercher de "Jaws + javascript", à regarder ARIA ou par exemple les travaux fait dans Dojo par IBM pour l'accessibilité, ainsi que les guidelinesgénérale d'accessibilité pour les sites webs et les webapps. Tu verras rapidement que Javascript n'est pas un problème si c'est fait correctement (comme tout quoi). Et je ne prétend pas connaître 10% du domaine (ni être webdev), simplement on m'a demandé une fois de faire de la webapp accessible alors j'ai pris 10 minutes pour regarder…
Pour ce qui est du javascript pur, je ne vois pas vraiment de contre indication, ma formulation se voulait surtout provocante.
Naïvement je continue à penser qu'échanger des choses justes sont plus intéressantes que de s'écouter. Ta phrase était donc " Les sites en javascript non accessibles discriminent les aveugles. On pourrait pas leur faire un procès ? ". C'est vachement moins sensationnel comme ca. D'ailleurs on se rendrait presque compte que c'est exactement pareil que pour les applis lourdres ou toute autre techno…
Linuxfr est un bon exemple
Et en dehors que toi tu préfères personnellement, tu as des informations factuelles comme quoi c'est un modèle d'accessibilité ? Qu'il n'y a aucun problème pour aucun type de handicap ?
Posté par ckyl .
En réponse à la dépêche 23 de Firefox.
Évalué à 6.
Dernière modification le 13 août 2013 à 08:16.
Les sites en javascript discriminent les aveugles. On pourrait pas leur faire un procès ?
Du peu que j'ai regardé le sujet quand je bossais sur des webapp qui devaient passer les certifs d'accessibilités, soit tu dis n'importe quoi soit ta phrase est volontairement tournée pour déformer la réalité.
De nos jour l'écrasante majorité des screenreader ont le support Javascript (> 90%) et tu peux faire des applications web complexes en JS parfaitement accessibles. Après comme avec du pur HTML/CSS tu peux faire de la grosse merde, tout comme tu pourrais coller ton menu dans une image avec une image map. Mais le problème n'est pas la techno, juste le gros boulet qui s'en sert.
Vu que tu as l'air vraiment concerné par la discrimination des aveugles, tu pourrais nous faire un petit topo ? Ca m'intéresse de savoir ce que j'ai loupé.
A l'heure des formats plus concis et rapide à parser (JSON, etc), le XML fait office d'éléphant à mon sens.
Sauf cas d'utilisation spécial la différence de vitesse est négligeable (et pas toujours en faveur de JSON) tout comme la taille finale. Dans tous les cas ce sont en général les API qui limitent la vitesse des parseurs, et un format custom et/ou binaire mets des ordres de grandeurs sur ces deux axes à JSON. Si ce sont des métriques pertinentes pour toi la question n'est pas XML vs JSON…
Après chaque cas d'utilisation est spécifique et on choisira l'approche la plus adaptée en fonction des besoins précis, du contexte et de l’environnement. Mais si on peut éviter d'écrire les mêmes inepties depuis 10 ans c'est pas mal aussi.
j'imagine mal des recherches fulltext performantes.
J'ai aucune idée de l'implémentation de PluXml.
Maintenant une DB c'est une très mauvaise solution pour de la recherche textuelle. Et en général vu le volume de données totalement négligeable que tu as dans un CMS tu as beaucoup de possibilité d'implémentations. Une bonne solution c'est une solution qui répond au cahier des charges, une excellente solution c'est une bonne solution qui en plus à une approche intelligente dans un contexte donné.
[^] # Re: etre ou ne pas etre
Posté par ckyl . En réponse au journal Ras le bol des plateformes d'e-recrutement. Évalué à 6. Dernière modification le 26 août 2013 à 20:03.
LinkedIn pas mal de contacts pertinant de boîtes/cabinets qui cherchent vraiment des mecs (screening sérieux + itw sérieuse + payement de tous les frais d'itw + suivi). Quelques cabinets de merde, mais on les repère vite, donc /dev/null plus la publicité qu'ils méritent. Par contre relocalisation requise pour la plupart des jobs. En même tant quand on va chercher des gens pour leur filer un bon poste avec un bon salaire, la probabilité que ce soit à coté de chez toi si tu n'habites pas un des 10 spots de dévelopeurs au monde est mince… Si c'est pour recruter en local, je vois pas forcement l'intêret de linkedIn. Annonce locale dans les trucs spécialisés + aller faire un tour dans les meetup du coin est vachement plus pertinant…
Viado, que de la merde de SSII ou cabinet-Francais-pattern matching tout pourri. Bref c'est Monster quoi, pas de raison de s'embêter avec ca.
On peut aussi utiliser linkedin/twitter dans l'autre sens pour identifier les RH/recruteur/directeur techniques plutôt que de passer par le système normal de la boîte.
[^] # Re: Suivi
Posté par ckyl . En réponse au journal L'index du moteur de recherche de LinuxFR est obsolète ?. Évalué à 2.
Plutôt que voter; y a t-il une explication technique du problème et de ce qu'il manque quelque part ? On sait jamais…
[^] # Re: Avec leurs salaires plein de charme
Posté par ckyl . En réponse au journal Où sont passé les offres d'emploi?. Évalué à 2.
Je pense qu'il n'y a pas de technique générale. Chaque situation est différente et qu'on est rarement capable de l'identifier quand on est du côté candidat. Ca reste de la loterie.
L'important c'est de réussir à arriver soit au screening téléphonique, soit au moment où tu peux montrer ce que tu as a vendre et échanger avec les gens. Avant c'est juste réussir à faire tomber un boût de papier au bon endroit et attirer l'attention parmis une pile de papier plus où moins identiques pour qu'on te laisse t'exprimer.
[^] # Re: Avec leurs salaires plein de charme
Posté par ckyl . En réponse au journal Où sont passé les offres d'emploi?. Évalué à 4.
En fait quand tu postules tu as deux mondes différents qui vont utiliser les informations :
Ces deux mondes ont des critères diamétralement opposés et c'est la tout le problème.
Vire tout le bullshit et tu as une chance sur deux que ton CV n'aille jamais nul part. Mais de l'autre côté si tu pousses sans pouvoir l'expliquer tu te feras défoncer direct en technique.
Tout l'art est donc d'essayer de doser et d'adapter un peu en fonction de chaque situation:
Mais ca reste de la lotterie. Pour l'anecdote, sur mes deux derniers postes je n'ai jamais eu la moindre réponse à mes candidatures par la voie normale avec CV technique + mot clés. Par contre en faisant suivre par l'intérieur aucun soucis. Les équipes n'avaient jamais vu l'ombre de ma candidature par la voie normale…
Ca peut aussi être très raisonnable de mettre un mot clé d'une techno à la mode si tu as beaucoup d'expérience du domaine en général. Il faut juste être très clair quand tu parles avec les gens, leur dire sans détour et avoir quelque chose à vendre. Exemple typique le mec qui à X années d'expérience dans le calcul distribué/data mining/machine learning, il peut mettre Hadoop sans hésiter sur son CV par ce que c'est actuellement utilisé comme mot clé de filtrage, alors que c'est rarement la compétence directement recherchée. Un mec qui ne le met pas, va rester invisible aux radars alors que son profil est pertinant.
Note: Je suppose que le mec est compétent, et qu'il a une stratégie raisonnable. Pas comme la montagne de boulet dont tu vois les CV passer.
[^] # Re: Avec leurs salaires plein de charme
Posté par ckyl . En réponse au journal Où sont passé les offres d'emploi?. Évalué à 6.
C'est surtout que tu ne maitrises pas du tout la date d'embauche. Entre le moment où tu ouvres le poste et le moment où le mec arrive tu as en général 5/8 mois (trouver le mec, lui faire une offre, qu'il se décide, qu'il solde ses congés ou prenne une semaine ou deux, qu'il fasse son préavis). Parfois c'est bingo en étant beaucoup plus court.
C'est pas une question de trouver ça normal. C'est un fait, en France il n'y a absolument personne en Août toute profession confondu. Ca veut dire possibilité de pas avoir de lead pour valider, pas d'équipe si tu fais passer plusieurs entretient, pas de RH pour faire les papiers. Et vu que certains postes ont beaucoup moins de doublons que d'autres…
Je vois pas trop le rapport. La crise pour qui ? Si personnes ne met des salaires et des projets en adéquation aux compétences des mecs et aux autres pays, bin t'as du mal à recruter mais ca ne veut pas dire grand chose non plus. Après oui les bons profils en France, faut les chercher vu comment on leur à donné envie de partir et qu'on veut pas de remote…
L'inverse est aussi vrai.
[^] # Re: Qu'est-ce qui est nouveau ?
Posté par ckyl . En réponse à la dépêche Sortie de Gnu Bison 3.0. Évalué à 3.
Tout à fait. D'ailleurs si tu regardes comme suggéré "les programmes de base dans /bin de FreeBSD (difficile de faire plus vieux et plus basique tout en étant toujours utilisé)" tu le constates facilement. Une nouvelle fonctionnalité tous les 5 ans, le reste c'est de la maintenance impliqué par un environnement ou des pratiques qui bougent de temps en temps. Plus tu es bas niveau et indépendant, le cas de nos outils, plus c'est stable et figé. Plus tu es haut dans la pile logicielle, plus tu passes ton temps à maintenir le truc même avec zéro bugs et zéro besoin par ce que ton monde évolue en permanence.
Bien sur ca ne marche que pour les briques logicielles extrêmement bien définie, et "petites". Dès que le scope est un peu plus large, ça ne se stabilise jamais ca fini par étouffer sous son poids et mourir.
[^] # Re: Contraintes pour l'utilisateur
Posté par ckyl . En réponse à la dépêche eHour, SO Planning: 2 logiciels de suivi d'activité. Évalué à 4.
Attention je parle pour des équipes de dev ou assimilé. Pour des métiers réactifs et a interruption c'est un peu différent.
Mais dans tout les cas il très important de toujours savoir ce qu'on cherche à optimiser et ensuite de décider des mesures et des actions pour y parvenir. C'est extrêmement important de comprendre dans quel but sont collectés les métriques afin de les choisir judicieusement, et de reporter ce qui est utile: granularité, type de reporting, analyse à faire etc. Il faut aussi réfléchir aux différentes approches pour essayer d'atteindre l'objectif qu'on se donne. Le reporting n'est jamais une solution. Ca peut par contre être un outil temporaire ou une mesure à long terme dans un processus d'amélioration et gagnant de la connaissance sur soi même.
Le passage "service IT d'une PME" m'en fait douter. Mais citer Scrum n'était pas le point fort, juste un mauvais exemple du à un biais de dev.
Par contre le "jamais eu le temps/dispo/[ mettez ce que vous voulez ici ] pour apprendre et mettre en place dans mon équipe" me semble souligner le syndrome . Je vais caricaturer vu que je ne connais rien de ton cas ne m'en tiens pas rigueur, mais en gros tu collectes des données à postériori sans avoir de but ou de plan assurer la qualité produire et améliorer constamment ton équipe. Pourquoi perdre du temps à demander un reporting à grain fin ? Si l'objectif est suffisamment important pour justifier une action de toute ton équipe pourquoi ne pas prendre le temps pour réfléchir sérieusement à ton organisation afin d'augmenter significativement la productivité, la qualité ou les conditions de travail de ton équipe ?
Si c'est pour détecter les imprévus, pourquoi ne pas chercher le moyen le plus efficace de suivre ce points. Ce n'est surement pas une métrique à l'heure qui t'intéresse; mais d'avoir une idée du volume que ca représente, du taux d'interruption, de la fréquence, des sources, pour pouvoir prendre les actions pour protéger ton équipe.
Si c'est pour de la facturation, selon la taille de tes projets une estimation "gros grain" peut largement être suffisante et peut être faite par le management. Par exemple à la fois mon manager, mon project manager, mon scrum master et toute mon équipe seraient capable de fournir la même facturation que si on demande à chaque personne de le faire. Pourquoi faire perdre du temps à X personnes ? De même notre organisation nous permet d'avoir une connaissance de nos capacité et de notre planning que ne nous donnerait pas du time tracking. Ce n'est donc que de la perte.
Si c'est pour mesurer la qualité des projets (reporting au type de tâche). Alors là c'est juste de la connerie pur et dure car il n'y a aucune corrélation entre la métrique et l'objectif, c'est ultra couteux à reporter, et tout le monde va biaiser les entrées pour rentrer dans le stats et pas être emmerdé.
Encore une fois ce que je dis est extrêmement caricatural. L'idée c'est que je n'ai jamais vu d'utilisation utile et raisonnable du time tracking dans le but d'améliorer la production. Après ça peut être imposé par une politique de boîte ou des contraintes légales et là il faut juste exploiter le système pour fournir des stats dans le bon ordre de grandeur à moindre coût (typiquement je rapporte à la semaine ou au mois en agrégeant plutôt que faire 200 entrées ce qui n'a aucune valeur). Mais si on reste à des échelles où la logique à encore un sens, faut bien réfléchir aux raisons qui feraient mettre ça en place. On ne peut pas s’améliorer sans mesurer, mais mesurer ne veut pas dire qu'on s' améliore ni que c'est pertinent…
[^] # Re: Contraintes pour l'utilisateur
Posté par ckyl . En réponse à la dépêche eHour, SO Planning: 2 logiciels de suivi d'activité. Évalué à 8. Dernière modification le 21 août 2013 à 21:17.
Bof. Sauf à faire du support ou ce genre de tâches qui marchent au ticket le temps passé derrière un ordi n'est pas du tout significatif:
Même pour les tâches de dev et avec des outils automatiques c'est assez foireux au final.
Mais la vrai question c'est pourquoi faire chier les gens et leur faire perdre du temps avec ces conneries ? Les données soumises sont toujours pourries par ce qu'on n'a pas que ça à faire. Il n'y a rien à y apprendre que ne pourrait savoir par ailleurs avec une gestion correcte d'équipe ou de projet. Exemple si tu fais du Scrum, tu as la liste de stories de ton sprint, ta vélocité et donc tu as les mêmes infos avec une marge d'erreur similaire pour… 0 travail supplémentaire. Pour les plus acharnés du reporting tu peux aussi aller voir les tâches, et si ton équipe estime les tâches tu as de quoi te palucher pendant très longtemps. Au passage plutôt que d'apprendre le lundi matin suivant ce qu'à fait ton équipe, tu peux avoir une bonne estimation à l'avance, essayer de comprendre le fonctionnement de ton équipe, ses problèmes, ses axes d'ameilloration, prévoir les choses et observer quand, où et pourquoi ca dérape bref du vrai boulot de management. Le time tracking bête et méchant est pour moi vraiment le syndrome du mauvais management.
Ca me rappelle une boîte où l'outil de time tracking proposait genre 50 types de tâches pour chaque projet où tu es assignés… Ca fait des jolis rapports certe; mais ca sert à rien et ca fait perdre du temps à tout le monde. Soit l'effet inverse de l'objectif. D'ailleurs les gens reportaient biens qu'ils métaient 10x plus longtemps que dans toutes les autres boites mais c'était cohérent avec les stats globales ! Et tant qu'on peut facturer à la minute ou se palucher en sachant qu'on passe 19.75% de son temps à écrire de la doc tout va bien…
# Imparable
Posté par ckyl . En réponse à la dépêche GooglePlayDownloader : télécharger les APK sans rien demander à Google. Évalué à 6.
Donc en gros être en Java est rédhibitoire pour une application dont le but est d'installer des applications Java. Ca me semble aussi logique qu'imparable !
[^] # Re: Un plus par rapport aux livres existants ?
Posté par ckyl . En réponse à la dépêche Livre : Développement système sous Linux . Évalué à 4.
Même qestion. Quelle est sa place entre l'historique Stevens et le récent The Linux Programming interface qui sont deux énormes références.
J'ai l'impréssion que c'est un peu plus orienté "débutant" et ratisse large. J'ai tort ?
[^] # Re: Rien à cirer
Posté par ckyl . En réponse au sondage Quel système d'exploitation mobile utilisez-vous ?. Évalué à 2. Dernière modification le 19 août 2013 à 20:10.
Mouler, transports en commun et liberté à moins de 5 mots chacun ? Je te laisse ma part de vraie liberté volontier alors ;)
[^] # Re: Si je puis ajouter mon grain de sel...
Posté par ckyl . En réponse au journal FreeBSD un OS sans avenir?. Évalué à 3. Dernière modification le 18 août 2013 à 20:32.
MAC est disponible depuis FreeBSD 5. FLASK/TE, soit le modèle de SELinux, était dispo comme module MAC dans TrustedBSD vers 2006 mais il me semble que le merge final de Flask/TE n'a jamais été entièrement fait (je n'utilise plus FreeBSD depuis des années).
Après encore une fois, chroot n'est pas une mesure de sécurité…
[^] # Re: Conclusion un peu hâtive, non ?
Posté par ckyl . En réponse au journal FreeBSD un OS sans avenir?. Évalué à 6.
Tu sais libreoffice hormis ouvrir "britney_spears_nue.doc" de la cousine du roi du nigéria qui cherche à placer son argent la surface d'exposition est maitrisée et maitrisable… Reste les clients connectés à internet.
Maintenant on dirait que tu as eu la révélation du siècle alors que tu viens de découvrir l'eau tiède. Comme tu le dis ca fait plus de dix ans que c'est comme ca, et s'en rendre compte prend au pire un mois. Si le système ne correspond pas à tes besoins bha il correspond pas à tes besoins. Pas besoin de cracher de la merde sur le projet.
[^] # Re: Notoriété
Posté par ckyl . En réponse au journal FreeBSD un OS sans avenir?. Évalué à 5.
Déconnes pas c'est basé sur des faits: les stats des recherches Google ! Faudrait publier un papier la dessus.
[^] # Re: Hotmail
Posté par ckyl . En réponse au journal FreeBSD un OS sans avenir?. Évalué à 10.
C'est d'ailleurs cette même année qu'on s'est rendu compte qu'écrire micro$oft était vraiment ridicule ;)
[^] # Re: Conclusion un peu hâtive, non ?
Posté par ckyl . En réponse au journal FreeBSD un OS sans avenir?. Évalué à 8. Dernière modification le 17 août 2013 à 16:21.
T'es vachement dur tout de même. Les punchlines en gras ca fait vachement pro, genre journalisme d'investigation. Ca donne tout de suite du contenu à l'article.
En plus c'est du travail de fond. Trois ans de boulot pour se rendre compte ce qu'impliquait d'utiliser un système basé sur les sources. Tant de dévotion ça force le respect.
[^] # Re: github
Posté par ckyl . En réponse au journal Un module noyau pour le support exFAT, en GPLv2 !. Évalué à 9.
C'est un choix. Après pour des petits/moyens projets à partir du moment où tu as les fonctionnalités d'import/export tu t'en balances un peu vu que tu n'as pas de processus forts.
Voir le nombre de projets qui ont migrés vers github depuis bitbucket/googlecode ces dernières années, et qui rechangeront sans problème si une meilleure offre apparait.
Propriétaires, oui. Merdique, par contre là tu dois avoir un sérieux soucis. La plupart de leurs outils sont plutôt dans le haut du panier.
[^] # Re: Licence, contrat, schmilblick
Posté par ckyl . En réponse au journal Annonce : Manux 0.0.1. Évalué à 5.
Trollesque ?
Tu présentes ton projet, je regarde (ce que tu dis, la doc, le code), je m'intéroge et je demande. Excuse moi (nous) de chercher de comprendre ce qui a été fait, pourquoi, comment et où ca peut aller plutôt que jouer à l'école des fans. Les questions sont: quels sont les avantages, quels sont les inconvéniants, quels sont limites, qu'est ce qui se passe quand on revient à fonctionnalités et userland égal, est ce qu'on ne laisse pas un trou qui rend cela inutile.
Maintenant si tu trouves ca inutile comme questions, pourquoi le présenter ?
PS: Je vais pas suivre la classique comparaison foireuse de voiture, mais justement les proto du 24h du Mans répondent à un besoin très précis avec de fortent contraintes et si tu en sors… ;)
[^] # Re: Intéressant
Posté par ckyl . En réponse au journal Annonce : Manux 0.0.1. Évalué à 7.
Dans la réponse sur mon autre commentaire tu nous expliques spécifiquement que ':w toto' ne fonctionne pas. Une application ne peut donc créer de nouveaux fichiers. Des petites fonctionalité genre "nouveau document" ou "Enregistrer sous". Des problèmes comme ca on peut en trouvé une infinité.
Soit je suis trop bête pour comprendre les subtilités de ton modèle et comment ca tient debout en dehors de "J'arrive à éditer mon fichier texte", soit ca ne tient pas debout pour un cas d'utilisation générique.
Sachant que tu as déjà commencer à introduire de nouveaux concepts type "il suffirait de patcher firefox pour", ou que l'exemple du ':!ls' ne te fasse pas percuter que c'est ce que les applications passent leur temps à faire j'ai un peu peur de ne pas être complétemment dans le faux. Si le seul truc qui reste c'est du MAC sur l'accès/écriture des fichiers, c'est techniquement faisable depuis longtemps juste presque impossible à mettre en oeuvre en dehors des démons.
[^] # Re: Intéressant
Posté par ckyl . En réponse au journal Annonce : Manux 0.0.1. Évalué à 4.
Tu passes d'un truc à l'autre, c'est grossier là ;)
Empêcher de modifier le logiciel c'est faisable sans problème sur plein de systèmes (ou même tout ce qui n'est pas explicitement spécifié).
Empêcher deux instances différentes d'une même application d'accéder au même espace de nommage du FS c'est quelque chose de différent. Mais tu dois faire un choix. Soit tu segmentes complétement, et ton système n'est pas utilisable pour autre chose que quelque chose d'extrêment spécifique (voir pas utilisable tout court faudrait y réfléchir vraiment). Soit tu ne segmentes pas tant que ca en mergant automatiquement en fin d'execution, en utilisant des mécanismes spéciaux etc. Et là ton truc est troué. Tu peux écrire sur le FS, comme sur un système classique…
[^] # Re: Intéressant
Posté par ckyl . En réponse au journal Annonce : Manux 0.0.1. Évalué à 8.
J'avais donc bien compris où tu voulais en venir. Malheureusement je n'y crois pas une seule seconde pour un système généraliste. C'est soit inutilisable soit une passoire, encore plus si tu ne veux pas patcher tout l'userland.
D'un point de vu démon, c'est à peu près jouable. Mais soit tu vas obtenir quelque chose de moins fin que ce qui est possible via les policy MAC, soit plus casse gueule qu'une VM vu la complexité du bordel. Sachant que tout le reste du système est à refaire ca sent pas bon.
D'un point de vu utilisateur c'est mort. Les applications communiquent entre elles, sont intégrées, et ont des accès larges et légitimes au système de fichier. Déjà avec ton simple exemple de vim tout seul dans ton coin tu t'englues dans les explications en imaginant déjà des cas spéciaux de fichiers éditables ou non reposant sur des white/black-list par application et de lanceur spéciaux pour une application. Et là on à même commencé à parler de la fuite d'information. Un ':e' dans ton vim il peut ouvrir ou pas un fichier ? Si oui c'est mort. Un ':w' il marche ? Un ':!ls' il marche ? Alors c'est mort pour l'isolation. Si la réponse est non alors tu as un système simplement inutilisable. On se souvient que là on parle d'un pauvre éditeur de texte dans son coin. Ca va devenir rigolo en généralisant la chose, en introduisant les mécanismes d'IPC etc.
Les politiques MAC sont super contraignantes, c'est pour ca qu'elle reste confinée où elles font sens.
[^] # Re: Intéressant
Posté par ckyl . En réponse au journal Annonce : Manux 0.0.1. Évalué à 7.
Heu les fichiers de configuration de Vim sont turing complet…
Et c'est bien la que je ne vois pas comment ton truc peu marcher par ce que c'est simple il y a deux solutions:
Soit tu as des environnements, donc applications pour toi, entièrement isolés qui ne peuvent jamais se parler et la tu contients les débordements dans chaque environnement.
Soit tes environnements ont moyens de se parler (accès à un seul même fichier éditable dans l'un et lisible dans l'autre) et la c'est game over pour la sécu. À partir du moment ou tu as à access au FS d'un uid il est compromis.
Donc si on résume soit tu as un truc totallement inutilisable vu que tu segmentes par appliquation, ca me fait une belle jambe d'avoir un vim tout seul dans son coin… Soit tu as un truc pas plus secure que n'importe quel autre système.
C'est bien pour ca qu'usuellement on cloisone par unité logique. Tu pourrais vraiment nous expliquer correctement ton truc au moins conceptuellement ? On pourra regarder si la technique suit après.
[^] # Re: Déception
Posté par ckyl . En réponse à la dépêche 23 de Firefox. Évalué à 7.
Vous faites un concours avec l'autre qui explique que le bouton pour désactiver le Javascript est absolument vital alors que visiblement il ne s'en sert au max 3x dans l'année et qu'il y a des alternatives 10x plus pratiques ?
Sérieusement pourquoi sortir des arguments foireux et rajouter une couche robin des bois défenseurs des aveugles. Par ce que c'est super vachement important les aveugles hein ! Mais pas tant que ca apparemment, car si tu t'étais intéressé une seule fois au sujet tu ne dirais pas des anneries.
Je t'invite par exemple à chercher de "Jaws + javascript", à regarder ARIA ou par exemple les travaux fait dans Dojo par IBM pour l'accessibilité, ainsi que les guidelines générale d'accessibilité pour les sites webs et les webapps. Tu verras rapidement que Javascript n'est pas un problème si c'est fait correctement (comme tout quoi). Et je ne prétend pas connaître 10% du domaine (ni être webdev), simplement on m'a demandé une fois de faire de la webapp accessible alors j'ai pris 10 minutes pour regarder…
Naïvement je continue à penser qu'échanger des choses justes sont plus intéressantes que de s'écouter. Ta phrase était donc " Les sites
en javascriptnon accessibles discriminent les aveugles. On pourrait pas leur faire un procès ? ". C'est vachement moins sensationnel comme ca. D'ailleurs on se rendrait presque compte que c'est exactement pareil que pour les applis lourdres ou toute autre techno…Et en dehors que toi tu préfères personnellement, tu as des informations factuelles comme quoi c'est un modèle d'accessibilité ? Qu'il n'y a aucun problème pour aucun type de handicap ?
[^] # Re: Déception
Posté par ckyl . En réponse à la dépêche 23 de Firefox. Évalué à 6. Dernière modification le 13 août 2013 à 08:16.
Du peu que j'ai regardé le sujet quand je bossais sur des webapp qui devaient passer les certifs d'accessibilités, soit tu dis n'importe quoi soit ta phrase est volontairement tournée pour déformer la réalité.
De nos jour l'écrasante majorité des screenreader ont le support Javascript (> 90%) et tu peux faire des applications web complexes en JS parfaitement accessibles. Après comme avec du pur HTML/CSS tu peux faire de la grosse merde, tout comme tu pourrais coller ton menu dans une image avec une image map. Mais le problème n'est pas la techno, juste le gros boulet qui s'en sert.
Vu que tu as l'air vraiment concerné par la discrimination des aveugles, tu pourrais nous faire un petit topo ? Ca m'intéresse de savoir ce que j'ai loupé.
[^] # Re: XML ?
Posté par ckyl . En réponse à la dépêche PluXml 5.2 le CMS propulsé à l'XML est de sortie. Évalué à 5.
Tout comme les trucs ressassés depuis 10 ans.
Sauf cas d'utilisation spécial la différence de vitesse est négligeable (et pas toujours en faveur de JSON) tout comme la taille finale. Dans tous les cas ce sont en général les API qui limitent la vitesse des parseurs, et un format custom et/ou binaire mets des ordres de grandeurs sur ces deux axes à JSON. Si ce sont des métriques pertinentes pour toi la question n'est pas XML vs JSON…
Après chaque cas d'utilisation est spécifique et on choisira l'approche la plus adaptée en fonction des besoins précis, du contexte et de l’environnement. Mais si on peut éviter d'écrire les mêmes inepties depuis 10 ans c'est pas mal aussi.
J'ai aucune idée de l'implémentation de PluXml.
Maintenant une DB c'est une très mauvaise solution pour de la recherche textuelle. Et en général vu le volume de données totalement négligeable que tu as dans un CMS tu as beaucoup de possibilité d'implémentations. Une bonne solution c'est une solution qui répond au cahier des charges, une excellente solution c'est une bonne solution qui en plus à une approche intelligente dans un contexte donné.