Reprise du message précédent :
sothink SWF decompiler, ya pas mieux (en MP chérie)
edit : mac ou windows ?

mac, mais c'est bon, merci.
En plus c'est pas trop trop dégueu en sortie, j'ai perdu les locales et les arguments, mais ça, va toutes les fonctions sont là.
Par contre, les classes de 5000 lignes (je soupçonne qu'elle avaient à peut près la même tronche dans le source)

C'est un peu mon ressenti aussi, mais vu que c'est super à la mode en ce moment, je me demandais s'il y avait pas une techno que j'avais loupée

Oui m'enfin ça, depuis les solutions de load balancing jusqu'au backup (à chaud, à froid, peu importe), ça existe déjà dans la pratique depuis longtemps, non ?

C'est-à-dire ? Que t'externalises ton infra, en gros ?
'fin si c'est juste un business model, perso ça m'intéresse pas des masses (et je vois pas trop non plus en quoi ça intéresse le user lambda).

pas du tout avec le même profil d'usage du capital. Si tu as des machines, il faut tout acheter upfront, donc t'es en complète sur-capacité et t'as calqué 30k€ sans avoir un seul client en face.
Avec un truc genre Amazon, t'as tout ça, sauf qu'à la fin du premier mois t'as presque rien utilisé et donc tu payes quedalle.  
Ensuite tu as la croissance, si ton trafic explose, tu auras toujours 2 semaines d'attente entre la commande et la réception des machines, avec un truc en ligne, c'est automatique. Si tu te fais slashdotter, tu vas pas commender des machines, tu vas utiliser un truc en ligne pour bouffer le pic.
 
ensuite, il faut payer un mec pour changer les alims qui crament la nuit dans le datacenter en zone de neige. S'il surveille 10 serveurs il coûte un peu cher. S'il surveille 30000 serveurs, il est de toutes façons en 3x8 et il bosse toute la nuit et tout le jour, t'as une économie d'échelle sur les providers de cloud. Pareil pour le prix d'achat des machines ou les changements d'alims.
 
Bref, ça va plus vite de changer de conf, ta conf matérielle est dans git, et tu payes ta facture à la fin du mois. Sinon il faut jouer du devis et du tournevis, du doc word et du schéma aimenté sur les baies et tu payes tes serveurs et tes admins qu'il bossent ou pas.
Ensuite quand tu commences à sérieusement grossir, tu gardes un oeil sur la facture et tu te barres dans ton propre datacenter quand tu sens que ça vaut le coup de payer un mec à changer les alim's à 3h du mat en zone de neige.
 

Ouais alors d'accord, on parle bien de capital/investissement (cf post de pop-pan et ma réponse), mais techniquement ba y a rien de bien nouveau.

si, parce que du coup tout change, on envoie pas des machin SNMP dans des routeurs, mais des appels dans des APIs, on a plus un mec qui sait changer des alims, mais un mec qui sait écrire du code qui modifie un système complexe, etc. C'est plus le même métier du tout.

Par exemple le code qui rajoute des serveurs quand y'a un problème de charge, il peut aussi aller matraquer un autre composant du système ou faire partie d'une boucle de rétraction qui va tout exploser. là où il fallait envoyer un devis, réceptionner le bordel et l'installer, on envoie une commande sur un site web, du coup l'idée de brancher cette commande sur le monitoring arrive. Et tout le monde a peur de créer un skynet, mais la réalité c'est que le premier instinct d'un système intelligent, c'est pas d'enchaîner les humains en esclavage et d'établir un ordre numérique nouveau, mais de se suicider dans une boucle de rétroaction en embarquant ses voisins de cloud et le CA de la journée.

d'un coup j'ai la vision d'un monde où les machines ont réduit les humains en esclavage, ils doivent changer les piles des RTC des machines toute la journée.

j'crois que l'histoire se finit bien, un esclave oublie de changer une pile, Mc Afee pète les plombs et reboot, et les humains sont sauvés.

OK mais ça concerne essentiellement les sysadmins non ? 'fin je veux bien que pour les petites boîtes ça soit mélangé avec le taf habituel des devs, mais dans les faits c'est pas trop le taf des devs applicatifs.

Ca c'est un truc qui fait un peu peur, ouais. Sur ton p'tit VPS, tout va bien, tu fais tourner ton serveur de mail et tout, et là paf, tout tombe parce que le Jean-Michel du VPS à côté mais situé physiquement sur la même machine a tout cassé.
C'est une réalité ça ou c'est de la parano ? (vraie question hein, j'y connais pas grand-chose)

les sysadmins on les aime bien, mais ils vont aller au musée, avec les rémouleurs.
les devs applicatif qui capte rein à TCP/IP vont aller les rejoindre, ou devenir super chers, comme les cobolistes.

c'est extrèment rare. par contre que ton process/machine se prenne une balle parce qu'il mordu la ligne, ça peut arriver.

parano, les outils d’administration permettent de contenir tout ça très bien , on n'est plus à l'époque des ovh mutualisés
 
Par contre, ça a un coup en perf de mettre une couche de plus, qui n'est pas a oublié ( licence, temsp d'accès, ... )

tout ça c'est transformable en argent dans ton équation, on s'en fout un peu finalement.
M'enfin au prix d'un load balancer matériel, t'as de quoi en acheter des années.CPU chez amazon ...

Tant que les dev sont à la manœuvre pour s'occuper de créer tout ce qui est back office, y'a pas de risque que les sysadmins soient mis à la retraite
Ils changent juste de profil, et évoluent avec les technos, comme d'hab
 
En fait, tant que ce sera aussi cloisonné, ça évoluera pas bcp. Faudrait agir à la source
Et donner un peu plus les moyens aux uns et autres de comprendre les interactions qu'on a sur un S.I, même à son "simple" niveau

Dans mon équipe tout le monde avait les clefs du camion
tu fais une grosse bouse indéployable -> pas grave c'est toi qui va écrire le script de déploiement quand même  
 
(enfin je filtrais, parce que certains ont tendance à penser que comme c'est scripté on s'en fout du millefeuille de complexité, donc j'aimais bien rappeler que quand le machin d'un collègue tombe en rade à 3h du mat', c'est pas un script qui va aller démonter le millefeuilles pour tenter de dépanner à moitié bourré, en ssh depuis un smartphone, planqué dans une chambre pendant la soirée de l'année de l'école d'infirmière)

C'est a peu près ça. Pour la redondance en fait t'as le choix. Dans vSphère y aurait une fonction qui permet à un host de miroirer un autre à chaud, et de reprendre, à la volée, toutes les VM si l'host tombe (sans même un reboot des VM en fait). En pratique ça implique donc une vraie redondance et d'avoir 50% des hosts qui servent "à rien".
 
Pour l'instant on a pas choisit/testé cette solution, trop couteuses pour notre besoin (on accepte de fonctionner en mode "dégradé" quelques minutes si besoin, le temps que reboot les VM et qu'OVH fournisse un host de remplacement, ce qu'ils ont fait en quelques minutes la fois ou c'est arrivé).

 
Tu parles des économies d'échelle, mais tout ça c'est pareil qu'avant quand tu achetais du hosting quelque part, sauf que ça s'appelait pas le cloud.

 
hum... oui et non, il est de la responsabilité l'equipe de dev de fournir un livrable correct.
un exemple tres concret est que pour faire du soft solide on passe forcement par des tests et du trace.
 
dans un schema capex tu va mettre en place une infra de test pour avoir tes metriques sur la charge par ex, si c'est pas bon faut la remonter pour ré-evaluer et faire un test GN pour isoler les goulots d'etranglement.
de meme si tu as besoin d'integrer des ressources sur une equipe/projet il peut etre nécéssaire de redimensionner.
ca a un cout machine/temps de dev tres important (tu va pas fausser tes tests hein ), alors bien sur tu peux toujours lancer ca la nuit mais en crunch c'est pas toujours jouable.
 
en mode opex ca consiste a deplacer un slider pour reconfigurer ton environnement et attribuer plus ou moins de ressources, tu peux sortir tes metriques pour un 2-cores/4Go avec une instance sharé entre app/api/dbb ou des 8-cores/16Go avec des instances différentes en tres peu de temps et manipulations.
 
la db rame sur un dualcore ? => tu bouge le curseur sur octo et t'appuie sur entrée
l'instance api est surdimensionnée ? => tu descends d'un cran tant que la charge est pas > 50%
 
en plus tu peux automatiser les reglages en fonction des heures de la journée
plein de builds a lancer ce soir? => 200% de ressources en plus sur ces horaires pour l'instance qui s'en occupe
ou alors que des scripts moisis en crontab? => tu baisse les resources sur les horaires d'execution
 
sinon dire que l'allocation de ressources c'est pas trop un taff de dev mais un taff de sysadm ca a pour moi autant de sens que dire que faire des requetes sql propres on s'en branle puisque c'est au dba de gerer.

Quelqu'un aurait un set d'icône du genre fb, youtube, linkedin etc... J'ai envie d'avoir un truc homogène au lieu d'aller chercher à droite à gauche si jamais ça existe.

Ca va au delà des économies d'échelles, ça a un impact significatif au niveau du dimensionnement/"provisionning"
Avant ce genre de services de type cloud, tu sautais souvent dans l'inconnu, et si tu voulais être "tranquille" tu choisissais le pire cas, celui de la charge la plus forte pour dimensionner

Mais ça a un coût significatif et un impact très fort au niveau économique, de même que d'adopter l'attitude complètement inverse complètement nonchalante/"jemenfoutiste" qui consiste à dire "on verra bien quand on y sera"  et de voire tout planter pour des pics de charge pas anticipés du tout, et donc de perdre pas mal niveau économique.
C'est ce dont parlais nraynaud

Un autre avantage du cloud, c'est que ça a généralisé ces "infrastructures virtuelles" et ce qui en découle : une bien meilleure rationalisation des moyens, et donc des coûts en baisse rapporté au besoin initial exprimé
Avant, on mobilisait des moyens (humains et techniques) qui n'étaient pas toujours exploité à 100%
Par exemple, en dehors des périodes d'activités significatives/voire intenses, un serveur qui sert au "e-commerce", ça passe pas mal de temps à attendre, donc ça coûte pour rien
Là on peux mutualiser les coûts (à condition que ce soient des activités complémentaires niveau utilisation des ressources, sinon on retombe dans le pb du dimensionnement "pire cas" ), et faire en sorte qu'une machine physique fournisse les ressources à plusieurs activités/services différents, par le biais de la dématérialisation/infrastructure virtuelle

Ce genre de service/système "puissance/ressources à la demande", ça existait bien avant le cloud et la virtualisation, ces histoires de mutualisation
Je me souviens qu'il y pas loin de 15 ans, Sun proposait ce genre de principe sur ses serveurs hauts de gamme

Genre t'avais 75 processeurs sur ton Sunfire, qui pouvait héberger un/plusieurs SGBDR, en transactionnel, mais aussi avec des activités de reporting, et de décisionnel plus "dur" encore

En journée tu pouvais allouer un bonne partie des ressources au transactionnel (en gros servir les commandes/écritures reçues des différents front) avec la possibilité de piquer encore sur les ressources des autres activités pour absorber les pics de charge et la nuit, quand c'était plus calme au niveau commercial, tu pouvais allouer la plus grande partie des ressources au reporting et au décisionnel pour produite toutes les stats de vente/reporting/etc ... qui atterrissaient sur les bureaux des différentes personnes concernées. C'était assez souple, et dynamique comme système de partitionnement logique, et dynamique avec possibilité de mettre des garde fous pour éviter qu'un service fasse tout péter pour x raison
Sun le faisait au niveau de ses machines hauts de gamme, au niveau des clusters même il me semble
Mais c'était réservé à leur haut de gamme, et c'était des machines qui coûtaient 10 reins par mois, sur 10 générations  
IBM/HP et d'autres ont poussé plus loin en te vendant une bête de course/monstre de puissance "pas cher," et en te vendant au les clés pour débloquer des processeurs/ressources en plus, fur et à mesure de l'accroissement de ton activité et augmentation de tes besoins, donc.

Maintenant, ça s'est démocratisé, et s'est généralisé et dématérialisé au point qu'on ne te vende que le service, sans que tu ais plus trop à te soucier de l'infra (humaine/technique/etc ...) qu'il faut derrière pour faire tourner tout ça.
Mais elle encore là.

nan, ça c'est la transposition des métiers d'aujourd'hui. Mais c'est faire manuellement des trucs que la machine devrait faire. Si y'a pas assez de RAM, c'est pas à moi d'aller bouger le curseur, mais à un programme. Si mes requêtes SQL rament par manque d'index ou parce que l'optimiseur est débile, c'est pas à moi d'aller mettre les index, mais au système.  
Parce que les choses changent, si d'un coup y'a un nouveau bout de mon site qui devient populaire, mon profil de requête va changer, et le système doit s'adapter en fonction des métriques.
Il a par exemple toujours été débile de définir la taille des extents à la main dans une base oracle (surtout qu'il existe un outil qui fait un rapport pour te dire la taille idéale, il peut pas finir le job en lui mettant la bonne taille au passage ?).
 
Il existe des pièges dans les systèmes automatisés, et c'est justement le coeur du nouveau métier, maitriser les points faibles de ses algos de sizing automatiques (j'ai fait de l'overfitting, ou j'ai lancé l'apprentissage sur des données non-représentatives de la prod, les boucles de feedback, la raisonnance etc.).
 
Clairement, par exemple cron n'a pas d'avenir sous sa forme actuelle, quand une machine risque de mourir n'importe quand, il faut stocker ses jobs dans un système un peu plus évolué que le disque local de la machine. Mais aussi au niveau philosophique, dans un monde de temps réel, quand tes clients sont dans toutes les time-zones, faire tourner un batch "à minuit" n'a aucun sens, il faut aller vers le temps réel et les réduire la taille des lots (ie le discours de l'agilité en plein business).

A te lire on a envie de te faire les fesses

disons que c'est pas un truc magique, ça a une histoire, on a évolué vers ça, en virant une limitation après l'autre dans un sens et une innovation après l'autre dans l'autre sens.
Par exemple les IBM 390 sont des vrais précurseurs en philosophie technique en faisant tourner plein de machines virtuelles sur le même hard. Puis d'autres gens on démocratisé en faisant ça sur le PC. Puis y'a un business man qui s'est dit: "putain, j'arrête les conneries avec les camions, les livraisons ratée etc. Et je vais les louer à la puissance utilisée", puis t'as les outils qui se sont améliorés, maintenant on a des API pour tout, on a viré le commercial entre le client et la machine.
Et progressivement, on a dé-humanisé le truc. Là où on avait des plans de continuation d'activité qui comprenaient des interventions dans le datacenter, ça a été scripté . Pour provisionner une machine il fallait des semaines entre le devis et la mise en ligne, sur amazon j'arrivais à le faire en 6min, et l'objectif c'est 6s.
 
Mais du coup ça change toute la philosophie, avant on défendait des machines qui contenaient des données importantes. Maintenant on laisse mourir des VM qui de toutes façons sont quasiment stateless. Backup offsite ? bah ça veut dire qu'il existe une copie chez Amazon et une autre chez OVH. Ton provider de cloud te fait chier ? si tu décides sur un coup de tête de te barrer et que tu mets tout le monde dessus, en une semaine t'as plus aucune VM chez ton ancien provider, essaye de faire ça dans une colocation. Mais comme c'est pas trop cher, tu peux aussi essayer de te préparer en ayant en permanence tes scripts qui sont prêts pour un autre fournisseur, ou même tout le temps en utiliser 2 en prod. On est passé de défendre des machines physiques contre l'incendie à laisser crever un datacenter entier en 15min (en tant que dev d'appli hein, les fournisseurs de cloud ont une vision un poil différente du risque d'incendie).  
Du coup si t'es une petite boite, tu peux avoir des machines sur des continents différents sans investissement, tout est toujours facturé à l'heure en fin de mois. Tu peux concentrer ton capital sur l'adaptation de ton produit à la culture locale.

Alors là pour le coup, je vois ça comme un truc assez ponctuel. Partir sans savoir si t'auras besoin de 2 cores ou 8, 3 Go de RAM ou 16, c'est valable en tout début de projet et encore. Si les architectes et les devs sont incapables de dire ce que leur appli va nécessiter en termes de config, c'est qu'il y a un pb. Et c'est pas un cas qu'on rencontre tous les jours (enfin, de mon expérience ; après y a p'têt des domaines où c'est plus fréquent, je sais pas).

Oui, ça je vois bien

Non, le job des devs/architectes, c'est de savoir sur quel type d'architecture infra va devoir tourner le soft. Sorti de là, c'est pas au dev de savoir resizer la cible. Au contraire, ça devrait pas être à lui de le faire, sinon on part sur un risque de "oula, y a une fuite mémoire, je vais bouger le curseur pour débloquer la prod et j'investiguerai ce qui va pas plus tard".
On est d'accord que les devs sont responsables des perfs, mais c'est pas une raison pour leur donner la main sur l'infra. Pour reprendre ton analogie avec les DBA, c'est comme si on donnait un accès DBA aux devs sur la base de données.

Je trouve mon bonheur sur iconspedia en général ils ont des set homogenes

Vector social Media Icons

 
Si l'alternative c'est une réunion houleuse de 3h avec un dev, un sysadmin et leurs chefs respectifs pour savoir quel département va accepter de faire l'effort c'est pas forcément mieux pour l'intérêt commun

Non, l'alternative c'est que le monitoring relève un pb de consommation mémoire et que le dev analyse si c'est réellement un bug ou une augmentation du volume de données Le pb de donner les clés aux devs sur la prod, c'est que ça permet de cacher des emmerdes sous le tapis au lieu de les prendre en compte.

 
Merci  

Moi j'ai l'analyse inverse, avec des devs qui développent un truc super chiant à déployer mais qui s'en foutent vu que c'est pas eux qui le font. Là le mec qui a une vue sur tout.
Quand je vois ce que fait l'analyse de new relic, ça commence à vraiment devenir intéressant.

Ba techniquement, quand t'as un environnement de test, de pré-prod, etc... c'est le dev qui se tape le déploiement, non ? 'fin perso ça a toujours été le cas.

chez PSA c'était fait par des mecs dans un autre pays.

 
Ça c'est ce qui se passe dans les 2 cas, la seule différence c'est qu'une fois que le dev a analysé le problème dans un cas il bouge le bouton lui même si c'est pertinent, dans l'autre cas il doit demander à quelqu'un d'autre de bouger le bouton.
 
Si le dev est un flemmard qui tente de cacher les problèmes plutôt que de bosser sérieusement c'est plutôt un problème humain, et si ça arrive il va te falloir le virer au plus vite le surveiller dans tout ce qu'il fait, pas seulement sur l'usage ram. Résoudre une mauvaise embauche ou un mec pas impliqué en embauchant une personne de plus et en alourdissant les process ça me semble pas une manière super efficace de dépenser le fric de l'entreprise
 
 
(Ici, on a les graphs de monitoring de ram/load/... visibles sur le chemin entre les bureaux et les chiottes, c'est nos serveurs, avec notre code dessus qui tourne pour de vrai devant des gens, on tient à nos serveurs et on aime pas quand ils sont en mauvaise santé, si y'a une courbe qui monte on va immédiatement voir ce qui se passe, ce serait probablement pas comme ça si on avait relégué la responsabilité à quelqu'un d'autre.)
 

Oui, ça me choque pas.

Je suis d'accord, sauf s'il planque le pb ba t'as aucun moyen de le savoir puisque c'est lui qui a la main sur toute la chaîne (un peu Kerviel-stÿle ).
Je trouve pas que c'est ajourdir le process tant que ça ; le process reste le même (i.e. bouger un slider au lieu d'ajouter des barettes de RAM), sauf que la responsabilité n'est pas centralisée. Donner tous les droits à tout le monde, ça marche dans le cas super sympa où tout le monde est compétent, impliqué, responsable ; ça doit arriver hein, mais pas très souvent.

Pourquoi ? Quelqu'un dont c'est le quotidien d'assurer le bon fonctionnement de la prod, tu penses pas qu'il va faire du bon travail ? En gros, un mec impliqué et motivé comme vous sauf qu'il dev pas. Je sais pas, ça me paraît pas aberrant.

J'aime bien donner les droits à tout le monde, par contre en échange on trace toutes les opérations, il faut pas pouvoir faire des trucs en cachette. (Et en pratique, si chef-chef voit qu'on claque 10x plus de thunes que le mois précédent il va vite demander une explication). Après ouais, j'imagine bien que c'est pas pour tout les milieux.
 

Je voulais dire que si le dev n'était pas responsable de la mise en prod, il peut être moins impliqué dans l'état en prod, je pensais pas à l'implication du mec qui s'occupe de la mise en prod, effectivement ce gars peut être impliqué aussi, les gens qui ne sont pas des devs peuvent être des gens biens quand même, des fois
 

C'est pas vrai, il bosse en équipe, il a un boss, la facturation fait apparaître l'usage des resources.
Et il a pas tout les droits, notamment les budgets sont défendus au niveau de la boite. Par contre l'équipe produit doit tout faire techniquement pour se démerder pour que le site web arrive sur les navigateurs des clients. ça veut dire qu'elle le créé et le déploie, et se démerde pour qu'il reste en ligne. Elle décide si elle utilise une lib ou si elle développe, elle décide si elle met un CDN devant, si elle utilise amazon ou OVH (encore que là y'a une partie budget et légale à voir aussi, donc c'est pas souverain). En particulier elle fait ce qu'elle veut avec la mémoire, elle peut décider de rebooter ses serveur ruby toutes les nuit si elle veut, elle peut faire du crash only, elle peut utiliser postgres ou mysql ou mongo etc. de l'extérieur il y quelques critères : la thune claquée, est-ce que ça arrive sur les navigateurs, est-ce qu'il y a des bugs et est-ce que le produit est utilisable.
 

il fait quoi s'il dev pas ? tout est géré par des appels sur des API. J'veux bien claquer un salaire mais il va falloir des résultats en face.

Disons qu'ici, je le ferais pas (vu récemment : un mec demande à ce que tel mail automatique d'erreur ne soit plus envoyé tous les jours, c'est que des warnings. Bilan : prod plantée la semaine suivante parce qu'une erreur critique n'avait pas été repérée à temps )

Ah OK Je dirais que tout dépend de la relation que tu (en tant que dev) as avec les utilisateurs. Si t'as une bonne entente avec les "clients", t'es plus motivé pour faire gaffe à ce qui se passe ; si tu vois jamais les mecs ou que t'as pas de retour direct, c'est plus dur ("pas de nouvelle, bonne nouvelle" ) ou en tout cas t'as pas la même réactivité. J'avais eu ça de 2001 à 2007, je bossais sur des softs sans interaction client, y avait 2-3 équipes entre moi et les utilisateurs. Quand y avait un gros bug dans un soft, genre le truc critique, bon ba fallait le résoudre en 2-3 jours. Aujourd'hui, je me verrais pas rentrer chez moi sans avoir résolu le bouzin

 
http://fortawesome.github.io/Font-Awesome/
 
Sinon tu as des sets d'icônes inclus avec tous les framework CSS dignes de ce nom.

je suis intervenu en pompier sur un probleme a la con l'année derniere, le site marchand scotchait regulierement, personne ne savait pourquoi (en fait si ils avaient tous une idée mais politiquement/commercialement ca se disait pas) archi capex : lb, frontaux, serveurs app, serveurs dbb
 
au final, une query faisait tout ramer (c'est pour ca que les devs flippaient)
... parce qu'elle etait appelée en callback apres un appel WS qui mettait du temps (c'est pour ca que le presta flippait)
... parce qu'il manquait des index pour le WS (et la le dba comprennait pas)
 
donc on commence a regarder les logs sql avec le dba, qui nous dit que lui ses index existent donc c'est chelou, on commence a discuter avec le presta qui nous dit qu'ils travaillent sur un fragment de la db exposée par le client lui meme, on regarde avec l'equipe de dev et le presta et le dba pour tester sa tout avec un acces sur replicat base fournie par le db et confirme que ca passe
apres une bonne semaine on se rend compte qu'en fait le client il expose pas un fragment mais une copie, sauf que comme il utilise pas le bon acces qui faut il peut pas exporter certains index...
 
ne serait ce que la cellule de crise ca prends pas 5mn a organiser et pendant ce temps le site est a la ramasse.
 
en elastic le premier truc que j'aurais proposé c'est d'augmenter les capa de facon a pouvoir avoir une QoS tenable pendant cette phase de resolution et de mesure, ca aurait pris 10mn et tout le monde aurait été plus serein, personne aurait joué du parapluie et on serait arrivé aux memes conclusions plus vite.

Dites j'aurais une question sur un choix de techno.
 
On a un client qui a un besoin de faire des mélanges d'images en passant au niveau du pixel (rgba).
On a validé le fonctionnement sur des frontaux javascript avec des png  / drawimage / etc dans des canvas.
 
Maintenant se pose la question de faire la même chose "coté serveur", pour plusieurs raison mais majoritairement pour protéger ses algos et ses fichiers source pour ne servir que le résultat final.
 
A l'heure actuelle ou ouvre une dizaine de png en XGA, on récupère les tableaux de pixels et on fait mumuse avec, on a un peu de délai au chargement mais on a quand même des rendus relativement rapide (< 5 seconde).
 
Mon premier réflexe, ça a été de regarder le seul langage serveur que je connaisse (PHP), mais j'ai vite vu que c'était pas du tout jouable : lire un fichier image et le transcrire en tableau de pixel prend plus d'1s,  taille des tableaux dantesque donc difficile de les serializer et stocker, etc.
 
Du coups je voulais vos avis sur le bon langage pour faire ce genre de truc, je pensais à Python (ça fait un moment que je voulais tester), est ce qu'il est possible de stocker directement des gros tableaux et de les récupérer "rapidement" pour les manipuler...
 
Une autre solution serait de stocker chaque pixel dans une BDD et de transcrire l'algo en SQL, enfin bref, quel solution verriez vous à mon problème...
 

TU as un truc qui fonctionne en js ?  
est ce que tu as testé avec nodejs côté seveur ? il ya de modules qui émulent canvas, si je me souviens bien

Je suis sur http://www.nodebeginner.org/#hello-world
 
Les cotés asynchrone / monothread sont un peu chaud à appréhendé mais je m'accroches...
 
Ça peut cohabiter avec un serveur PHP / mysql Classique ou pas (logiquement oui si je met un port à la con je pourrais l'utiliser que pour la génération d'image) ?