cela fais des mois que je voudrais avoir la même fonctionnalité pour un amd radeon / intel (machin truc inside). Des chances que cela se produise un jour ? :(
Car il ne se positionne dans aucun cas concret. Enfin si, la génération d'1 map, 1 fois, sans concurrence.
Partant du principe que tu écris en php, je suppose, site web, je suppose donc multi utilisateur.
Je me demande si la table est en lecture / écriture permanente, ou pas.
Autrement, le make du fichier.php pourrait être écris ainsi,
Qui donc génère un tableau php véritable, l'exporte en code php compatible via var_export, concatène le résultat avec un return et un point-virgule, puis écris finalement l'ensemble dans un fichier php itself.
Puis quitte à faire dans le pet de mouche, évite les balises php fermante si ton code n'est pas mixé avec du html.
Cela peut t'éviter pleins de problèmes potentiels extrêmement bizarre à debugger pour un non avertit.
PS : le parseur MD est total buggé les amis. il confond php et math…
A ta place, j'utiliserais cet algo automatique comme base.
Ensuite, pour les cas où cela ne rends pas bien, je me donnerais la possibilité de définir le comportement pour tel et tel cas en particulier. via un fichier de config comme cité précédemment.
Ainsi tu peux profiter du meilleur des deux mondes.
A voir après comment tu implémentes cela dans tes libs, aucune idée.
terminate called without an active exception End of script output before headers: api_compagnon.cgi
Moi ce que j'en comprends c'est que ton cgi n'a pas spécialement buggé, il a juste oublié de répondre les headers en-têtes avant le body corps.
HTTP/1.1 200 OK
Date: Tue, 11 Mar 2014 13:46:30 GMT
Content-Length: xxx
content goes here.
Ou peut être plus probablement, fermé la socket avant qu'httpd ne soit prêt à l'accepter.
Ne pouvant lire ton code, ne connaissant pas les arcanes d'httpd, à toi de nous dire.
Ceci mis à part, j'en reviens à quelques considérations superflues, mais que je tiens à partager.
Je rejoint l'avis formulé plus haut que de nombreuses solutions alternatives étaient disponibles.
A l'écoute de mon expérience et de mes capacités de développements, je n'irais jamais pondre un module apache pour livrer du contenu. AMHA, c'est exposé le projet, aussi petit soit il, à moultes complications supplémentaire sans valeurs ajoutés par rapport à l'objectif du développement initial.
Quand à la question du time-to-market, à ta place, j'y réfléchirais à deux fois, car l'inexpérience dont tu fais l'illustration ici au regard des arcanes d'httpd, j'ai malheureusement, toutes les bonnes raisons de penser que ton commanditaire va s'en mordre les doigts au plus mauvais moment.
D'un autre côté, cela ne le regarde que lui et sa décision, sauf si bien sûr, tu fais aussi le suivi du run =D
Le seul point ou vraiment je ne peux que m'incliner c'est la visibilité apportée par ces stores.
A l'hébergement je dirais qu'on peut faire quelque chose à base de torrent, de client léger et de communauté.
Pour le design… bah c'est et restera un handicap quelle que soit la plate forme de dév.
Après effectivement, il y a ce qui existe, et le reste, du domaine du possible, mais restant à concrétiser….
muè bref quoi, le journaliste sert à rien et suffit de sortir de chez soit pour aller parler aux ados pour probablement obtenir le même tissu de parole, tu as d'ailleurs les mêmes ados à la maison apparemment, cqfd:ctdlamerde sans intérêt.
Mais ! car il y à un mais, si suffisamment de gens comme toi sont d'accord pour continuer de payer pour ces âneries, qu'il en soit ainsi..
Posté par maboiteaspam .
En réponse au journal Small Issue Tracker.
Évalué à 1.
Dernière modification le 05 novembre 2013 à 15:22.
bah en local j'ai ça
ab -c 50 -n 1000 -C sessid=16816927778469308861804289383 'http://127.0.0.1:8080/things_to_do/issues'
This is ApacheBench, Version 2.3 <$Revision: 1430300 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking 127.0.0.1 (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests
Server Software:
Server Hostname: 127.0.0.1
Server Port: 8080
Document Path: /things_to_do/issues
Document Length: 17584 bytes
Concurrency Level: 50
Time taken for tests: 5.290 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 17628000 bytes
HTML transferred: 17584000 bytes
Requests per second: 189.05 [#/sec] (mean)
Time per request: 264.485 [ms] (mean)
Time per request: 5.290 [ms] (mean, across all concurrent requests)
Transfer rate: 3254.41 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.2 0 4
Processing: 2 260 167.2 240 1013
Waiting: 0 91 75.0 80 358
Total: 2 260 167.2 241 1013
Percentage of the requests served within a certain time (ms)
50% 241
66% 320
75% 371
80% 404
90% 490
95% 553
98% 641
99% 710
100% 1013 (longest request)
Maintenant c'est forcement biaisé puisque dans la vrai vie le client et le serveur sont physiquement distinct. Et puis certes les gens naviguent cette page issues list très souvent, mais est-ce la fonctionnalité dont ils attendent des performances extra ordinaire, pas sûr.
AMHA la recherche est beaucoup plus importante.
Donc, le test est il pertinent par rapport aux attentes probables des utilisateurs…. pas sûr.
Muè. Moi je suis choqué de ce choix, faire du web haut niveau (donc pas browser ni serveur ni protocole) avec une techno clairement faites pour programmer le bas niveau.
Par ailleurs à la lecture du code, ce que tu penses être une ré implémentation d'un serveur me semble plutôt être un mix qui à pour vocation de combler le manque d'un framework de développement côté serveur et des besoins fonctionnels.
A priori les parseQueryStringVar, getSessionIdFromCookie et d'autres probablement aurait toutes les places dans une entité externe plus générique.
On peut par ailleurs constaté dans la méthode ? fonction ? begin_request_handler (J'ai un doute je connait pas trop cpp…) que le front-controler est rudimentaire et oblige à faire des allers-retours de haut en bas dans le fichier pour sa lecture.
Bref, c'est pas tant que je voulais critiquer (…) c'est juste qu'il me semble pouvoir mettre en évidence par ces assertions mon idée de départ, /goeb/ aurait tout aussi bien fait d'utiliser des technos rompus à ces exercices.
A avoir ces connaissances en c++, j'aurais plutôt essayer de rendre portable le binaire php.
Avec son serveur désormais intégré, sa cross compatibilité, et la pléthore de librairie dont php dispose pour répondre à cet exercice, c'était un candidat de choix amha.
Nodejs aussi est un candidat de choix, cross plateforme, portable et tout aussi rompus à ces exercices du web, voir même beaucoup mieux équipé que php.
Mais il me semble que la techno est encore trop jeune.
Reste que, dans toute mes alternatives aucune ne répond à la demande de goeb de faire un développement avec le langage qu'il a décidé parce que ça lui plaît.
Bref de manière objective je ne suis pas d'accord les choix de goeb, mais si c'est ce qui lui plait alors je ne peux que le soutenir, et puis c'est tout !
A ce titre j'apprécie que l'outil fonctionne out of the box.
Installé et testé en moins de temps qu'il ne le faut pour l'écrire, c'est très très agréable.
Je ne sais pas…. Mais je me désole qu'un boulevard du thème de la socialisation et des biens commun comme celui ci soit encore une fois laissé aux bons plaisir d'une entité privée.
Comme c'est un objet qui sert l’intérêt général, aussi bien publique que privée, son coût de licence devrait faire l'objet d'une socialisation.
En effet, cela aide les gens avec des connections à faible débit à accéder à des contenus de meilleures qualités (visuel).
Cela aide les gros entrepreneurs à réduire leurs factures.
Les sociétés de moindre envergure pourrait fournir du contenu de meilleure qualité avec des coûts d'exploitation amoindris.
Dans un autre angle sa me gonfle ces miettes que les grandes entreprises nous laisse et de la merde qu'elles nous font bouffer à tout bout de champs.
…
Ainsi donc suite à cette petite mise en lumière d'un signe des temps actuels je retourne me percher dans mon arbre.
En fait je me rends compte surtout d'un certaine déphasage.
Vous me parlez de package, d'applications en mode client lourd, aurais je envie de dire, alors que j'avais en tête les applications en mode client légèr.
Je fait une distinction entre le package manager de ma distro et le google store.
Le package manager de ma distro est une fonctionnalité essentielle qui gère les composants de mon système.
Celui-ci a était étendu pour pouvoir y héberger des applications.
Il n'y à qu'à voir le devenir de la bien nommée logithèque d'ubuntu, qui auparavant était synaptic et précédemment encore la ligne de commande (schématiquement).
Je ne pourrais imaginer ce package manager s’arrêter de gérer les librairies du système, mais je peux totalement concevoir que celui ci s'arrête de fournir des applications (lourde).
Evidemment je me réjouis effectivement tout autant que toi/vous/tous de la pérennité et de la sécurité apportées par cette approche dans le cadre qui nous est proposé (gnu/linux, bsd, unix).
C'était bien des google store auquel je faisais allusion.
Il distribue des applications qui s’exécutent toutes dans des VM, s'appuie toutes à 80% sur des services en ligne, et lorsque ce n'est pas le cas s'appuie sur des stockage locaux avec des schémas de données relativement simple.
On à bien là à faire a des applications légères.
Ce que je mets en parallèle à ce store c'est l'application, et non le site web, accessible par une url et non un store.
En effet il possible désormais d'éditer une application, à la manière d'un site web, et de voir celle ci être auto hébergée au sein du navigateur même lorsque l'utilisateur est hors ligne (ou plutôt particulièrement lorsqu'il est hors ligne).
Et c'est bien dans cet angle de vue que je remet en cause ces stores.
Alors oui effectivement, effet visibilité, infrastructure prête à l'emploi et gratuité sont des éléments absolument nécessaire pour qu'un développement homebrew puisse émerger dans ces stores.
Mais je dois dire qu'encore une fois je ne me pose pas dans cette position………..
Mais plutôt dans la position d'un éditeur de site internet qui doit intégrer ces nouveaux usage à son environnement.
Et qui voit dans ces stores la prise de contrôle d'un espace auparavant relativement sauvage.
Et lorsque je regarde les solutions totalement hétérogènes prônées par chacun de ces stores et de la charge induite, je vis cela comme une véritable dictature.
Je ne peux évidemment pas en manquer de nommer mozilla et ces efforts pour revenir à des situations raisonnable avec ffos. Les standards mis en application.
Bref, j'aurais dû être plus clair dans mon message, pour la peine je vous signe une belle tartine avec ce post :D
Je ne remets pas du tout la qualité du noyau en cause. Je m'interrogeait sévèrement, vos réponses m'ayant depuis éclairé.
Au regard de ton argumentaire, j'ai envie de dire que c'est d'autant plus crucial de pouvoir faire tourner des tests d'intégration pour rejouer, voir inventer (fuzzer), des jeux de données sur lesquels s'appuyer.
Et que oui, étant donné le nombre de variable possible, se serait tellement bien de pouvoir /simuler/ finement tout cela histoire de ne pas avoir à déployer le système qui va bien (et dont on peut douter de sa capacité à jamais pouvoir reproduire fidèlement la réalité du paysage hétérogène PC passé présent et à venir O_o ).
Bref, maintenant je me pose la question suivante.
La QA à t'elle un jour jamais fait partie du scope fondateur des décisions conceptuel du noyau ?
Pas que je connaisse linus, mais au départ c'était bien une bidouille nés du génie? de la passion et de l’opiniâtreté d'un bidouilleur.
A t'il jamais pensé sa conception au regard des besoin de la QA, ou bien est ce que c'est le besoin et la réponse qui prime en tout temps.
parle de html5, ou comment adobe s'investit à fond dedans. Il faut voir les exemples autour de 6-8min, ce sont des choses relativement évidente pour qui connaît le monde de la PAO.
Mais qui sont toujours cruellement manquantes après toutes ces années de développement et tous ces experts techniques.
Encore une fois, un géant de l'informatique apporte son expertise au projet, et avec adobe on commence à toucher des désirs très intéressants pour la maturité de la plate forme.
Jeux, édition graphique, simplicité d'accessibilité.
On est plus dans l’établissement de standards ouverts prôné par mozilla, ni l'amélioration technique et fonctionnelle de google, ni encore dans la popularisation de ces langages comme yahoo à pu le faire avec JS.
Ici nous avons enfin un spécialiste de l'ergonomie et de l'édition graphique qui saute dans le bateau.
Je pense qu'à ré inventer leur cœur de métier autour de ces technos web cela nous promet encore pas mal d'évolutions à venir. Et qu'au regard de ce qu'ils font déjà de nos css et de nos GPUS, ça va roxer du ponay comme rarement.
Hello,
J'ai déjà rencontré ce problème sur des sommes SHA (hum hum), une appli java porté vers php (et oui.), la somme sha java était totalement foireuse.
Ce que nous avions fais à l'époque, merci le libre, était d'avoir un petit conteneur java que l'on pouvait appeler depuis php.
Celui ci nous permettait de reproduire les hash erronés fournit par la plate forme java et de les traiter ensuite dans la partie php.
Donc, je me demande de quels de backend tu disposes, et si cette expérience ne pourrait pas être reproduite.
J'ai bien conscience des problèmes de perf / maintenance. Mais bon, ça c'est à chacun de juger en fonction de son contexte.
Tu dis la même chose que moi. Tu l'as juste écris plutôt que de le laisser entendre ;)
Justement, je l'ai pas posté, mais je l'ai très fortement pensé ? Pourquoi tout ces sous entendus ? si je puis me permettre la familiarité..T'es en disgrâce, ou bien ?
En fait je voulais poster sur l'autre thread, que j'avais sauté à l'époque apparemment, alors qu'il est (merci crev) encore une fois hyper instructif et intéressant. Rapport au slides sur SQLite, rien de neuf en soit, mais d'avoir un support pour exprimer l'idée qu'un bug informatique, au delà d'être une erreur d'écriture-conception est d'abord et avant tout le stigmate d'un prolème de process. Idée qui me semble hautement importante, et dont je souhaitais évidemment vous rabacher les oreilles…
Pour ceux qui se demandent de Koi je parle : http://www.sqlite.org/talks/wroclaw-20090310.pdf
Mais bon. Le contenu à vieilli, alors j'imagines que si l'envie m'en reprend il me faudra m'y prendre autrement, histoire de polluer utilement la base de données de linuxfr (?).
C'est juste ça… Et oui sur le coup cela m'a semblait d'une crasse telle, que venir baver ici me semblât justifié.
La slide que tu cites est super intéressante.
J'ai fais trois fois du c++ dans ma vie, je comprends maintenant que c'est juste pas fais pour moi. http://fr.slideshare.net/olvemaudal/deep-c
Par contre la slide est très bisounours. Croire que le type lui demandera comment s'améliorer alors qu'il *** littéralement sur ces collègues deux slides avant est une vaste blague :)
Mais elle a le mérite de soulever cette question de l'investissement nécessaire pour appréhender les subtilités d'une technologie qui sont nécessaires pour répondre aux exigences de qualité.
Au final cela me semble moins casse gueule de le faire dans un environnement html.
Est-ce tu penses que je devrais arrêter de me préoccuper de tout ça et coder mes interfaces graphiques en nodejs/HTML5 et communiquer avec mon bancked à travers HTTP WebSocket ?
Oui totalement. Enfin, précisons pour les plus obstinés, qu'il y à certains outils pour certaines tâches.
Mais que ces technos ont certaines caractéristique intéressante.
Une relative ancienneté qui nous ont permis d'apprécier leurs capacités à tenter d'atteindre leurs objectifs de compatibilité à travers le temps et les appareils.
Le positionnement occupé actuellement par ces outils dans l'environnement de la production logiciel les mettent de facto à l'épreuve des balles.
Dès aujourd'hui il y à une myriade de personnes, utilisant ces technos, qui sont concrètement confrontées à ces problèmes, qui ont concrètement besoin de solutions.
C'est une vague de fond accompagnée et vécue par des acteurs tels que mozilla, google et d'autres.
Des acteurs qui sont expert et leader de ce domaine technique, mais aussi, dans un certain paradoxe, expert de ces lacunes puisqu'ils vivent ces outils.
Ils sont donc les mieux à même de comprendre le défi et d'y apporter une solution.
C'est déjà une bonne raison de donner un peu de crédit à ces solutions il me semble.
Ensuite, je constate avec étonnement la capacité de cross compatibilité de ces outils au regard de l'environnement hétérogène qu'ils subissent.
Je constate que si ils sont très bruts de décoffrages, la conception générale est saine, et que nous avons bien souvent était de piètres utilisateurs, pour diverses raisons.
Je constate aussi les difficultés avec lesquelles certains nouveautés qui semble mineure se mette en place, mais c'est pour notre bien, c'est démocratique et cross/retro-compatible, tant que faire ce peut, par un moyen ou par un autre.
La lenteur d’exécution par certains aspect, mais aussi la formidable amélioration qu'elle connait.
Je constate aussi toutes les directions empruntées actuellement par ces technologies le cas nodejs côté serveur, et tellement de framework côté client pour tenter de répondre à la même question : comment produire des ihm toujours plus rapidement, simplement, qualitativement, plus sexy que les précédentes.
Ce processus semble faire l'objet d'un tâtonnement permanent, par nature lent et difficile, mais tellement plus satisfaisant.
L'open source dans cette histoire joue un très grand rôle, et le fait que Js et Css soient deux langages overwritable au runtime aide beaucoup ces technologies à littéralement partir dans tous les sens pour répondre aux problèmes.
Là où Java centralise, unifie, et masque les problèmes de rétro compatibilité avec ces apis (du moins j'imagine sinon à quoi bon ?)**, dans le cas du web à 95% c'est réglé côté userland de manière totalement décentralisé, au choix des spécialistes du projet.
En quelque sorte le web est encore une fois l'expression d'une certaine horizontalité, en comparaison Java serait une technologie qui illustre les anciens systèmes verticaux.
Alors oui ça hack un peu, peut être beaucoup il faudrait comparer(…), mais les exemples de jquery/knockout nous montre que ces solutions sont concrètement fonctionnels.
Le tableau d'est pas totalement et idyllique, mais le projet dans son ensemble est dynamique et supporté.
Surtout, au regard de sa formidable disponibilité présente et future, il faut croire, amTha, que ces technos resteront supportées et continueront d'aller de l'avant.
Est-ce que tu penses que le Windows/Linux/MacOS sont morts et qu'il suffit de maitrîser l'API d'Android ?
Je ne la connais pas, je suppose cependant qu'elle fait le liant entre le matériel et l'interface par l'utilisation de webservice ? Ou ptet une api à utiliser dans un moteur v8, je ne sais pas.
Je dois dire que l'idée d'une api unifiée cross compatible pour accéder aux ressources de la machine me séduit beaucoup.
Ce serait la première brique posée pour produire une IHM d'OS pouvant reposer sur ces technologies comme pierre angulaire.
Après faut voir la capacité de webgl à convaincre.
Et enfin, ce sont les frameworks d'ui/ux qui séduiront les développeurs.
Le chemin est encore long, mais je signe plutôt deux fois qu'une.
De deux choses l'une,
soit j'ai un double sur le site,
mais dans ce cas là comment puis je l'identifier pour qualifier mon bug en 'collisions de pseudos' ?
Soit je suis affecté par un autre bug.
Je crois assez peu à un problème de casse, à moins que moi, mon clavier ou mon presse papier ne me joue des tours à mon insu lors de mes copier coller.
Enfin… Depuis le temps n'aurais je rien remarquer.. ?
Je pense que le mieux est que je produise un test reproductible, si tant est que celui-ci soit reproductible.
On verra quand j'aurais le temps ou la montée de chaleur nécessaire.
Pour l'instant je suis connecté jusqu'à ma prochaine session.
C'est déjà çà, comme disait l'autre.
Le bon côté étant que ça m'évite de poster trop de conneries :D
Merci tout de même,
a+
PS: bon j'ai pas était foutu de poster à la suite du fil…. mais c'est bien une réponse à vous deux.
[^] # Re: triste nouvelle
Posté par maboiteaspam . En réponse à la dépêche Full disclosure, c'est fini. Évalué à 1.
merci!
# triste nouvelle
Posté par maboiteaspam . En réponse à la dépêche Full disclosure, c'est fini. Évalué à 6.
amha c'est protégé de mauvaises pratiques et c'est l’intérêt personnel au détriment de l’intérêt général.
Est ce possible que quelqu'un copie colle le contenu de la lettre svp ?
Je n'ai plus de vpn dernièrement et non je ne peux pas y accéder….
# amd radeon
Posté par maboiteaspam . En réponse au journal PRIME s'améliore encore et encore !. Évalué à 2.
Hello,
cela fais des mois que je voudrais avoir la même fonctionnalité pour un amd radeon / intel (machin truc inside). Des chances que cela se produise un jour ? :(
# pas compris ton bench
Posté par maboiteaspam . En réponse au journal benchmark pour le fun. Évalué à 1.
Car il ne se positionne dans aucun cas concret. Enfin si, la génération d'1 map, 1 fois, sans concurrence.
Partant du principe que tu écris en php, je suppose, site web, je suppose donc multi utilisateur.
Je me demande si la table est en lecture / écriture permanente, ou pas.
Autrement, le make du fichier.php pourrait être écris ainsi,
Qui donc génère un tableau php véritable, l'exporte en code php compatible via var_export, concatène le résultat avec un return et un point-virgule, puis écris finalement l'ensemble dans un fichier php itself.
Tu peux ensuite te contenter d'un bête :
pour lire ta matrice.
Puis quitte à faire dans le pet de mouche, évite les balises php fermante si ton code n'est pas mixé avec du html.
Cela peut t'éviter pleins de problèmes potentiels extrêmement bizarre à debugger pour un non avertit.
PS : le parseur MD est total buggé les amis. il confond php et math…
# automatique + quelques re ecritures manuelle
Posté par maboiteaspam . En réponse au journal Les artistes, ce fléau ou l'invasion des profanateurs de GUI. Évalué à 3.
hello,
A ta place, j'utiliserais cet algo automatique comme base.
Ensuite, pour les cas où cela ne rends pas bien, je me donnerais la possibilité de définir le comportement pour tel et tel cas en particulier. via un fichier de config comme cité précédemment.
Ainsi tu peux profiter du meilleur des deux mondes.
A voir après comment tu implémentes cela dans tes libs, aucune idée.
[^] # Re: c'est probablement stupide
Posté par maboiteaspam . En réponse au message débugguer un CGI avec GDB ( sous apache2 ). Évalué à 1.
mhh effectivement, dans ce cas là c'est moche et mon intervention bien inutile.
Soit dit en passant, freem, as tu trouvé ?
# c'est probablement stupide
Posté par maboiteaspam . En réponse au message débugguer un CGI avec GDB ( sous apache2 ). Évalué à 4.
… on ne sait jamais cependant,
terminate called without an active exception
End of script output before headers: api_compagnon.cgi
Moi ce que j'en comprends c'est que ton cgi n'a pas spécialement buggé, il a juste oublié de répondre les
headersen-têtes avant lebodycorps.Ou peut être plus probablement, fermé la socket avant qu'httpd ne soit prêt à l'accepter.
Ne pouvant lire ton code, ne connaissant pas les arcanes d'httpd, à toi de nous dire.
Ceci mis à part, j'en reviens à quelques considérations superflues, mais que je tiens à partager.
Je rejoint l'avis formulé plus haut que de nombreuses solutions alternatives étaient disponibles.
A l'écoute de mon expérience et de mes capacités de développements, je n'irais jamais pondre un module apache pour livrer du contenu. AMHA, c'est exposé le projet, aussi petit soit il, à moultes complications supplémentaire sans valeurs ajoutés par rapport à l'objectif du développement initial.
Quand à la question du time-to-market, à ta place, j'y réfléchirais à deux fois, car l'inexpérience dont tu fais l'illustration ici au regard des arcanes d'httpd, j'ai malheureusement, toutes les bonnes raisons de penser que ton commanditaire va s'en mordre les doigts au plus mauvais moment.
D'un autre côté, cela ne le regarde que lui et sa décision, sauf si bien sûr, tu fais aussi le suivi du run =D
[^] # Re: pas mal !
Posté par maboiteaspam . En réponse au journal Small Issue Tracker. Évalué à 3.
muè.
On est passé de
(genre tu te cognes le bordel à la main), a
https://encrypted.google.com/search?q=search+engine+library
mais je suis ptet le seul à voir un glissement.
Bon après quand on se cogne 1000 lignes implémenter un storage layer avec la couche modèle qui va bien, cf
https://github.com/goeb/smit/blob/master/src/db.cpp, tout refaire c'est soulant, c'est sûr..
bref quoi =)
[^] # Re: Intégration
Posté par maboiteaspam . En réponse au message boutique d'applications : mac / google / mozilla, mais pourquoi ?. Évalué à 1.
Le seul point ou vraiment je ne peux que m'incliner c'est la visibilité apportée par ces stores.
A l'hébergement je dirais qu'on peut faire quelque chose à base de torrent, de client léger et de communauté.
Pour le design… bah c'est et restera un handicap quelle que soit la plate forme de dév.
Après effectivement, il y a ce qui existe, et le reste, du domaine du possible, mais restant à concrétiser….
[^] # Re: pas mal !
Posté par maboiteaspam . En réponse au journal Small Issue Tracker. Évalué à 2.
muè.
yapluka ré implémenter une recherche texte multi-critères avec pondération des résultats et approximation du terme…
Mais bon ré inventer la roue c'est bien aussi…
[^] # Re: pas la peine de dénoncer
Posté par maboiteaspam . En réponse au journal Les JT c'était déjà pas glorieux, mais là on atteint des sommets.... Évalué à 2.
muè bref quoi, le journaliste sert à rien et suffit de sortir de chez soit pour aller parler aux ados pour probablement obtenir le même tissu de parole, tu as d'ailleurs les mêmes ados à la maison apparemment, cqfd:ctdlamerde sans intérêt.
Mais ! car il y à un mais, si suffisamment de gens comme toi sont d'accord pour continuer de payer pour ces âneries, qu'il en soit ainsi..
[^] # Re: pas mal !
Posté par maboiteaspam . En réponse au journal Small Issue Tracker. Évalué à 2.
et pourquoi pas sqlite… tout simplement ?
[^] # Re: Les performances ne sont pas excellentes
Posté par maboiteaspam . En réponse au journal Small Issue Tracker. Évalué à 1. Dernière modification le 05 novembre 2013 à 15:22.
bah en local j'ai ça
Maintenant c'est forcement biaisé puisque dans la vrai vie le client et le serveur sont physiquement distinct. Et puis certes les gens naviguent cette page issues list très souvent, mais est-ce la fonctionnalité dont ils attendent des performances extra ordinaire, pas sûr.
AMHA la recherche est beaucoup plus importante.
Donc, le test est il pertinent par rapport aux attentes probables des utilisateurs…. pas sûr.
Sinon j'ai pas capté cette ligne….
$ ./smitc signin http://smit.herokuapp.com/signin homer homer
Il est multi threads ton serveur ?
[^] # Re: GitHub pour entreprise
Posté par maboiteaspam . En réponse au journal Small Issue Tracker. Évalué à 7.
Muè. Moi je suis choqué de ce choix, faire du web haut niveau (donc pas browser ni serveur ni protocole) avec une techno clairement faites pour programmer le bas niveau.
Par ailleurs à la lecture du code, ce que tu penses être une ré implémentation d'un serveur me semble plutôt être un mix qui à pour vocation de combler le manque d'un framework de développement côté serveur et des besoins fonctionnels.
A priori les parseQueryStringVar, getSessionIdFromCookie et d'autres probablement aurait toutes les places dans une entité externe plus générique.
On peut par ailleurs constaté dans la méthode ? fonction ? begin_request_handler (J'ai un doute je connait pas trop cpp…) que le front-controler est rudimentaire et oblige à faire des allers-retours de haut en bas dans le fichier pour sa lecture.
Bref, c'est pas tant que je voulais critiquer (…) c'est juste qu'il me semble pouvoir mettre en évidence par ces assertions mon idée de départ, /goeb/ aurait tout aussi bien fait d'utiliser des technos rompus à ces exercices.
A avoir ces connaissances en c++, j'aurais plutôt essayer de rendre portable le binaire php.
Avec son serveur désormais intégré, sa cross compatibilité, et la pléthore de librairie dont php dispose pour répondre à cet exercice, c'était un candidat de choix amha.
Nodejs aussi est un candidat de choix, cross plateforme, portable et tout aussi rompus à ces exercices du web, voir même beaucoup mieux équipé que php.
Mais il me semble que la techno est encore trop jeune.
Reste que, dans toute mes alternatives aucune ne répond à la demande de goeb de faire un développement avec le langage qu'il a décidé parce que ça lui plaît.
Bref de manière objective je ne suis pas d'accord les choix de goeb, mais si c'est ce qui lui plait alors je ne peux que le soutenir, et puis c'est tout !
A ce titre j'apprécie que l'outil fonctionne out of the box.
Installé et testé en moins de temps qu'il ne le faut pour l'écrire, c'est très très agréable.
# bonne chose ? Mauvaise chose ?
Posté par maboiteaspam . En réponse à la dépêche Cisco paie le H.264 en faveur de Mozilla. Évalué à 3.
Je ne sais pas…. Mais je me désole qu'un boulevard du thème de la socialisation et des biens commun comme celui ci soit encore une fois laissé aux bons plaisir d'une entité privée.
Comme c'est un objet qui sert l’intérêt général, aussi bien publique que privée, son coût de licence devrait faire l'objet d'une socialisation.
En effet, cela aide les gens avec des connections à faible débit à accéder à des contenus de meilleures qualités (visuel).
Cela aide les gros entrepreneurs à réduire leurs factures.
Les sociétés de moindre envergure pourrait fournir du contenu de meilleure qualité avec des coûts d'exploitation amoindris.
Dans un autre angle sa me gonfle ces miettes que les grandes entreprises nous laisse et de la merde qu'elles nous font bouffer à tout bout de champs.
…
Ainsi donc suite à cette petite mise en lumière d'un signe des temps actuels je retourne me percher dans mon arbre.
[^] # Re: Intégration
Posté par maboiteaspam . En réponse au message boutique d'applications : mac / google / mozilla, mais pourquoi ?. Évalué à 1.
OK.
Hello,
Merci, -6, mais des réponses c'est cool :D
En fait je me rends compte surtout d'un certaine déphasage.
Vous me parlez de package, d'applications en mode client lourd, aurais je envie de dire, alors que j'avais en tête les applications en mode client légèr.
Je fait une distinction entre le package manager de ma distro et le google store.
Le package manager de ma distro est une fonctionnalité essentielle qui gère les composants de mon système.
Celui-ci a était étendu pour pouvoir y héberger des applications.
Il n'y à qu'à voir le devenir de la bien nommée logithèque d'ubuntu, qui auparavant était synaptic et précédemment encore la ligne de commande (schématiquement).
Je ne pourrais imaginer ce package manager s’arrêter de gérer les librairies du système, mais je peux totalement concevoir que celui ci s'arrête de fournir des applications (lourde).
Evidemment je me réjouis effectivement tout autant que toi/vous/tous de la pérennité et de la sécurité apportées par cette approche dans le cadre qui nous est proposé (gnu/linux, bsd, unix).
C'était bien des google store auquel je faisais allusion.
Il distribue des applications qui s’exécutent toutes dans des VM, s'appuie
toutesà 80% sur des services en ligne, et lorsque ce n'est pas le cas s'appuie sur des stockage locaux avec des schémas de données relativement simple.On à bien là à faire a des applications légères.
Ce que je mets en parallèle à ce store c'est l'application, et non le site web, accessible par une url et non un store.
En effet il possible désormais d'éditer une application, à la manière d'un site web, et de voir celle ci être auto hébergée au sein du navigateur même lorsque l'utilisateur est hors ligne (ou plutôt particulièrement lorsqu'il est hors ligne).
Et c'est bien dans cet angle de vue que je remet en cause ces stores.
Alors oui effectivement, effet visibilité, infrastructure prête à l'emploi et gratuité sont des éléments absolument nécessaire pour qu'un développement homebrew puisse émerger dans ces stores.
Mais je dois dire qu'encore une fois je ne me pose pas dans cette position………..
Mais plutôt dans la position d'un éditeur de site internet qui doit intégrer ces nouveaux usage à son environnement.
Et qui voit dans ces stores la prise de contrôle d'un espace auparavant relativement sauvage.
Et lorsque je regarde les solutions totalement hétérogènes prônées par chacun de ces stores et de la charge induite, je vis cela comme une véritable dictature.
Je ne peux évidemment pas en manquer de nommer mozilla et ces efforts pour revenir à des situations raisonnable avec ffos. Les standards mis en application.
Bref, j'aurais dû être plus clair dans mon message, pour la peine je vous signe une belle tartine avec ce post :D
[^] # Re: Non, mais...
Posté par maboiteaspam . En réponse au message Le kernel linux il est testé à la main ?. Évalué à -1.
Je ne remets pas du tout la qualité du noyau en cause. Je m'interrogeait sévèrement, vos réponses m'ayant depuis éclairé.
Au regard de ton argumentaire, j'ai envie de dire que c'est d'autant plus crucial de pouvoir faire tourner des tests d'intégration pour rejouer, voir inventer (fuzzer), des jeux de données sur lesquels s'appuyer.
Et que oui, étant donné le nombre de variable possible, se serait tellement bien de pouvoir /simuler/ finement tout cela histoire de ne pas avoir à déployer le système qui va bien (et dont on peut douter de sa capacité à jamais pouvoir reproduire fidèlement la réalité du paysage hétérogène PC passé présent et à venir O_o ).
Maintenant, en regardant ce test http://ltp.cvs.sourceforge.net/viewvc/ltp/ltp/testcases/kernel/io/direct_io/diotest1.c?view=markup
je vois que la notion de mock n'existe pas.
A regarder cet autre test
http://ltp.cvs.sourceforge.net/viewvc/ltp/ltp/testcases/kernel/io/direct_io/diotest1.c?view=markup
J'en comprends que ce sont peut être des tests de non-régression auquel j'ai à faire.
Bref, maintenant je me pose la question suivante.
La QA à t'elle un jour jamais fait partie du scope fondateur des décisions conceptuel du noyau ?
Pas que je connaisse linus, mais au départ c'était bien une bidouille nés
du génie?de la passion et de l’opiniâtreté d'un bidouilleur.A t'il jamais pensé sa conception au regard des besoin de la QA, ou bien est ce que c'est le besoin et la réponse qui prime en tout temps.
# en furetant dans les depeches
Posté par maboiteaspam . En réponse au journal [Trolldi] Le langage plus approprié pour écrire des applications graphiques multiplateformes. Évalué à 2.
J'ai trouvé cet vidéo,
http://www.youtube.com/watch?v=TbXPPnfsq-c
parle de html5, ou comment adobe s'investit à fond dedans. Il faut voir les exemples autour de 6-8min, ce sont des choses relativement évidente pour qui connaît le monde de la PAO.
Mais qui sont toujours cruellement manquantes après toutes ces années de développement et tous ces experts techniques.
Encore une fois, un géant de l'informatique apporte son expertise au projet, et avec adobe on commence à toucher des désirs très intéressants pour la maturité de la plate forme.
Jeux, édition graphique, simplicité d'accessibilité.
On est plus dans l’établissement de standards ouverts prôné par mozilla, ni l'amélioration technique et fonctionnelle de google, ni encore dans la popularisation de ces langages comme yahoo à pu le faire avec JS.
Ici nous avons enfin un spécialiste de l'ergonomie et de l'édition graphique qui saute dans le bateau.
Je pense qu'à ré inventer leur cœur de métier autour de ces technos web cela nous promet encore pas mal d'évolutions à venir. Et qu'au regard de ce qu'ils font déjà de nos css et de nos GPUS, ça va roxer du ponay comme rarement.
# j'ai pas vraiment de solution
Posté par maboiteaspam . En réponse au message CryptoJS, PyCrypto et OpenSSL sont dans un bateau…. Évalué à 1.
Hello,
J'ai déjà rencontré ce problème sur des sommes SHA (hum hum), une appli java porté vers php (et oui.), la somme sha java était totalement foireuse.
Ce que nous avions fais à l'époque, merci le libre, était d'avoir un petit conteneur java que l'on pouvait appeler depuis php.
Celui ci nous permettait de reproduire les hash erronés fournit par la plate forme java et de les traiter ensuite dans la partie php.
Donc, je me demande de quels de backend tu disposes, et si cette expérience ne pourrait pas être reproduite.
J'ai bien conscience des problèmes de perf / maintenance. Mais bon, ça c'est à chacun de juger en fonction de son contexte.
a+
[^] # Re: Blog sur 42 de l'intérieur
Posté par maboiteaspam . En réponse au journal Un reportage radio dans la piscine de 42. Évalué à 0.
Justement, je l'ai pas posté, mais je l'ai très fortement pensé ? Pourquoi tout ces sous entendus ? si je puis me permettre la familiarité..T'es en disgrâce, ou bien ?
[^] # Re: Impossible de commenter un contenu vieux de plus de 3 mois
Posté par maboiteaspam . En réponse au sondage Les commentaires et vous ? . Évalué à 1.
En fait je voulais poster sur l'autre thread, que j'avais sauté à l'époque apparemment, alors qu'il est (merci crev) encore une fois hyper instructif et intéressant. Rapport au slides sur SQLite, rien de neuf en soit, mais d'avoir un support pour exprimer l'idée qu'un bug informatique, au delà d'être une erreur d'écriture-conception est d'abord et avant tout le stigmate d'un prolème de process. Idée qui me semble hautement importante, et dont je souhaitais évidemment vous rabacher les oreilles…
Pour ceux qui se demandent de Koi je parle : http://www.sqlite.org/talks/wroclaw-20090310.pdf
Mais bon. Le contenu à vieilli, alors j'imagines que si l'envie m'en reprend il me faudra m'y prendre autrement, histoire de polluer utilement la base de données de linuxfr (?).
C'est juste ça… Et oui sur le coup cela m'a semblait d'une crasse telle, que venir baver ici me semblât justifié.
[^] # Re: Blog sur 42 de l'intérieur
Posté par maboiteaspam . En réponse au journal Un reportage radio dans la piscine de 42. Évalué à 3.
Tout cela me fait penser qu'ils étudient dans des conditions totalement sur-réaliste, pour ne pas dire minable.
Au regard du peu de réactions ici, j'ai l'impression que je suis encore à la marge… Ou bien n'est ce qu'une impression ?
# sympa la slide
Posté par maboiteaspam . En réponse au journal [Trolldi] Le langage plus approprié pour écrire des applications graphiques multiplateformes. Évalué à 5.
La slide que tu cites est super intéressante.
J'ai fais trois fois du c++ dans ma vie, je comprends maintenant que c'est juste pas fais pour moi.
http://fr.slideshare.net/olvemaudal/deep-c
Par contre la slide est très bisounours. Croire que le type lui demandera comment s'améliorer alors qu'il *** littéralement sur ces collègues deux slides avant est une vaste blague :)
Mais elle a le mérite de soulever cette question de l'investissement nécessaire pour appréhender les subtilités d'une technologie qui sont nécessaires pour répondre aux exigences de qualité.
Au final cela me semble moins casse gueule de le faire dans un environnement html.
# // ----> | |[*o*] [*o*]| |
Posté par maboiteaspam . En réponse au journal [Trolldi] Le langage plus approprié pour écrire des applications graphiques multiplateformes. Évalué à 5.
Oui totalement. Enfin, précisons pour les plus obstinés, qu'il y à certains outils pour certaines tâches.
Mais que ces technos ont certaines caractéristique intéressante.
Une relative ancienneté qui nous ont permis d'apprécier leurs capacités à tenter d'atteindre leurs objectifs de compatibilité à travers le temps et les appareils.
Le positionnement occupé actuellement par ces outils dans l'environnement de la production logiciel les mettent de facto à l'épreuve des balles.
Dès aujourd'hui il y à une myriade de personnes, utilisant ces technos, qui sont concrètement confrontées à ces problèmes, qui ont concrètement besoin de solutions.
C'est une vague de fond accompagnée et vécue par des acteurs tels que mozilla, google et d'autres.
Des acteurs qui sont expert et leader de ce domaine technique, mais aussi, dans un certain paradoxe, expert de ces lacunes puisqu'ils vivent ces outils.
Ils sont donc les mieux à même de comprendre le défi et d'y apporter une solution.
C'est déjà une bonne raison de donner un peu de crédit à ces solutions il me semble.
Ensuite, je constate avec étonnement la capacité de cross compatibilité de ces outils au regard de l'environnement hétérogène qu'ils subissent.
Je constate que si ils sont très bruts de décoffrages, la conception générale est saine, et que nous avons bien souvent était de piètres utilisateurs, pour diverses raisons.
Je constate aussi les difficultés avec lesquelles certains nouveautés qui semble mineure se mette en place, mais c'est pour notre bien, c'est démocratique et cross/retro-compatible, tant que faire ce peut, par un moyen ou par un autre.
La lenteur d’exécution par certains aspect, mais aussi la formidable amélioration qu'elle connait.
Je constate aussi toutes les directions empruntées actuellement par ces technologies le cas nodejs côté serveur, et tellement de framework côté client pour tenter de répondre à la même question : comment produire des ihm toujours plus rapidement, simplement, qualitativement, plus sexy que les précédentes.
Ce processus semble faire l'objet d'un tâtonnement permanent, par nature lent et difficile, mais tellement plus satisfaisant.
L'open source dans cette histoire joue un très grand rôle, et le fait que Js et Css soient deux langages overwritable au runtime aide beaucoup ces technologies à littéralement partir dans tous les sens pour répondre aux problèmes.
Là où Java centralise, unifie, et masque les problèmes de rétro compatibilité avec ces apis (du moins j'imagine sinon à quoi bon ?)**, dans le cas du web à 95% c'est réglé côté userland de manière totalement décentralisé, au choix des spécialistes du projet.
En quelque sorte le web est encore une fois l'expression d'une certaine horizontalité, en comparaison Java serait une technologie qui illustre les anciens systèmes verticaux.
Alors oui ça hack un peu, peut être beaucoup il faudrait comparer(…), mais les exemples de jquery/knockout nous montre que ces solutions sont concrètement fonctionnels.
Le tableau d'est pas totalement et idyllique, mais le projet dans son ensemble est dynamique et supporté.
Surtout, au regard de sa formidable disponibilité présente et future, il faut croire, amTha, que ces technos resteront supportées et continueront d'aller de l'avant.
Je ne la connais pas, je suppose cependant qu'elle fait le liant entre le matériel et l'interface par l'utilisation de webservice ? Ou ptet une api à utiliser dans un moteur v8, je ne sais pas.
Je dois dire que l'idée d'une api unifiée cross compatible pour accéder aux ressources de la machine me séduit beaucoup.
Ce serait la première brique posée pour produire une IHM d'OS pouvant reposer sur ces technologies comme pierre angulaire.
Après faut voir la capacité de webgl à convaincre.
Et enfin, ce sont les frameworks d'ui/ux qui séduiront les développeurs.
Le chemin est encore long, mais je signe plutôt deux fois qu'une.
** j'ai un peu cherché, http://stackoverflow.com/questions/4692626/is-jdk-upward-or-backward-compatible, bref je ne sais toujours pas… :)
# merci !
Posté par maboiteaspam . En réponse au message identification linxfr qui bug. Évalué à 1. Dernière modification le 25 octobre 2013 à 14:57.
Hello,
merci pour vos retours.
De deux choses l'une,
soit j'ai un double sur le site,
mais dans ce cas là comment puis je l'identifier pour qualifier mon bug en 'collisions de pseudos' ?
Soit je suis affecté par un autre bug.
Je crois assez peu à un problème de casse, à moins que moi, mon clavier ou mon presse papier ne me joue des tours à mon insu lors de mes copier coller.
Enfin… Depuis le temps n'aurais je rien remarquer.. ?
Je pense que le mieux est que je produise un test reproductible, si tant est que celui-ci soit reproductible.
On verra quand j'aurais le temps ou la montée de chaleur nécessaire.
Pour l'instant je suis connecté jusqu'à ma prochaine session.
C'est déjà çà, comme disait l'autre.
Le bon côté étant que ça m'évite de poster trop de conneries :D
Merci tout de même,
a+
PS: bon j'ai pas était foutu de poster à la suite du fil…. mais c'est bien une réponse à vous deux.