Le topic de la programmation, string, chaînes, cuir et compagnie

**ook4mi** · 22/07/2015, 10h12

Envoyé par FB74

"Veux-tu du boulot pour 1 SMIC ou espères-tu du boulot pour 3 SMIC ?"

Suivant ta réponse, tu seras pris ou pas.

Quand ils m'ont demandé combien je voulais, j'ai dis que je voulais 32-33K annu brut. Depuis on a jamais reparlé sousous dans la popoche :x

**ducon** · 23/07/2015, 10h50

Envoyé par FB74

"Veux-tu du boulot pour 1 SMIC ou espères-tu du boulot pour 3 SMIC ?"

Suivant ta réponse, tu seras pris ou pas.

Du boulot pour trois SMIC payé un SMIC ?

**ook4mi** · 23/07/2015, 10h52

Envoyé par ducon

Du boulot pour trois SMIC payé un SMIC ?

Tu as jamais entendu parler de gens "sous" payé pour le boulot qu'ils font ?

**ducon** · 23/07/2015, 11h01

Si, tu as dû mal lire mon message…

**Drlecteur** · 27/07/2015, 04h37

Bon je sais pas trop si je devrais poster ca ici, vu que je suis un gros newbie par apport a vous :D
En codeur amateur, j'ai un problème de réflexion sur la formation d'une Database MySql et PHP.

J'ai un nombre X de fils de message sur la même page.
Je relève l'heure du dernier passage d'un user sur cette page, et j'affiche pour chaque fil le nombre de message en plus depuis son dernier passage lorsque il revient.

Probleme: Si l'user décide d'actualiser sa page avant d'avoir tout lu, il perd les notif (son dernier passage devenant il y'a 10 sec) sur les fils qu'il n'avait pas ouvert.

J'aimerai donc traiter chaque fil séparément, mais je bloque... comment noter la dernière lecture d'un fil en particulier en sachant qu'ils sont tous sur la même page, juste affichable grâce à un bouton ?
j'ai pensé adjoindre à chaque message dans la db, un champs "Lu", recueillant tout les ids des users ayant lu le message, mais ça me parait lourd... Puis il parait que noter plusieurs info dans un seul champs, c'est pas bien, je crois

Sachant que:
Les messages sont tous dans une seule et unique table
Il y'a 150 users, pour une 40 fils
Les fils vont et viennent

J'imagine que ça se rapproche assez des forums et comment ils font pour noter que tel user est a jour sur tel topic

Si je suis pas dans le bon topic, hésitez pas a me jeter :D

**war-p** · 27/07/2015, 08h41

Non, ça va t'es à peu près sur le bon topic, bon par contre, fait gaffe, j'ai l'impression que t'as tendance à confondre la couche vue et la couche modèle, ensuite je dis peut être une connerie, mais sans trop réfléchir, je dirai que t'as une relation ternaire entre fil, message et user, en gros en db, ça se traduit par une table supplémentaire regroupant le fil, le user et le dernier message lu.

**kpouer** · 27/07/2015, 10h23

Bon, pour info j'en ai assez des langages de programmations qui servent à quelque chose, je me suis donc mis à l'ASM TIS-100 c'est trop bien, mes problèmes quotidiens sont aussi simples que de dessiner un rectangle à l'écran ou faire une multiplication, mais quand on réussit, quelle satisfaction

C'est là et c'est top
http://www.zachtronics.com/tis-100/

**Drlecteur** · 27/07/2015, 16h03

J'ai du mal a saisir la couche modele et vue: Puisque c'est une action dans la vue qui provoque l'activation du script, les deux sont de facto un peu mêlé, non ?

Donc une table avec une ligne par user, par fil; donc (Nombre de fil * Nombre d'user) lignes ?
Ca me parait simple comme solution, mais n'est ce pas un peu lourd ?

**kpouer** · 27/07/2015, 16h23

Drlecteur tu peux faire une table avec les colonnes
user, fil, nbMessages

nbMessages étant le nombre de messages qu'il y avait dans le fil au moment ou l'utilisateur a lu le fil la dernière fois. Pour afficher le nombre de nouveaux messages tu fais la soustraction.
Pour éviter d'avoir une ligne comme ça pour chaque combinaison d'utilisateurs et de fils tu peux limiter ça aux forums que l'utilisateur consulte, ou auxquels il a participé.

**war-p** · 28/07/2015, 00h09

Envoyé par Drlecteur

J'ai du mal a saisir la couche modele et vue: Puisque c'est une action dans la vue qui provoque l'activation du script, les deux sont de facto un peu mêlé, non ?

Donc une table avec une ligne par user, par fil; donc (Nombre de fil * Nombre d'user) lignes ?
Ca me parait simple comme solution, mais n'est ce pas un peu lourd ?

Heu, pour l'histoire du controlleur et de la vue, non, c'est pas vraiment lié, l'un vas avoir une influence et vice-versa, mais si un jour, tu décides de changer ton générateur de vue par exemple (je dis une connerie, c'est pour l'exemple), et bien ta couche contrôleur, qui est séparée, n'aura pas à bouger. C'est le principe du MVC, modele, view, controller. Chaque parties est modifiable sans affecter les autres. Tout ça pour permettre, en théorie, une maintenance aisée. Après t'as d'autres modèle, la plupart dérivé du mvc qui sont sur le même principe de séparation.

Enfin, kpouer, j'aimais bien ma solution avec l'id du dernier message, ça permet de faire comme sur ce fabuleux forum, et de charger la page avec une ancre directement sur le dernier message lu.

**kpouer** · 28/07/2015, 08h03

Oui ça marche aussi avec l'id du dernier message à la place du nombre de messages, dans ce cas on compte le nombre de messages avec un id supérieur dans le fil de discussion.

**Tramb** · 28/07/2015, 13h06

Moi j'éviterais d'utiliser l'ordre implicite des ids pour trier sur un autre critère mais bon.

**kpouer** · 28/07/2015, 13h34

Bof je vois pas trop de maison mais admettons, l'id donne une date de message et il cherche tous les messages avec une date supérieure.

**deathdigger** · 28/07/2015, 13h57

Ben autant utiliser la date de la dernière visite et la date des messages postés.

**kpouer** · 28/07/2015, 14h07

Ça marche pas si tu veux indiquer le nombre de posts nouveaux depuis la dernière visite dans chaque fil de conversation.

**Sekigo Le Magnifique** · 28/07/2015, 21h00

Je comprend pas pourquoi vous vous cassez la tête. La solution de kpouet me parait très bien, avec les colonnes user_id, thread_id, count_message_last_visited, uid_message_last_visited, datetime_last_visited.

Et pour les perfs, avec ~200 users et 50 threads, c'est peanuts (ça doit faire maximum 10 000 dans ta table de jointure. Mais si tu restes stable, ça ne fera jamais ce chiffre, on peut diviser facile par 10. Sauf si tu as des utilisateurs compulsifs). Sauf si tu as une machine vraiment anémique. Et encore, faut y aller pour avoir un bottleneck sur aussi peu de données. Je suis sûr que même avec sqlite sur un rasberry pi, ça passe les doigts dans le nez.

Edit: faut quand même penser à vider la table de jointure quand un thread est détruit, ou un utilisateur est anéanti.

**kpouer** · 28/07/2015, 21h14

Voir quand un utilisateur n'est pas allé sur un thread depuis longtemps histoire de faire un peu de nettoyage.

**Sekigo Le Magnifique** · 28/07/2015, 21h20

Avec des tas de cron

De préférence, avec des crons qui foirent

Et des crons qui fonctionnent, mais qui te balances des conneries sur stdout en te floodant /var/mail

Que dieu punisse les gens qui font des tâches cron en php, sans module de logging.

**FB74** · 28/07/2015, 21h22

Arrête de jouer au cron.

**Drlecteur** · 29/07/2015, 00h42

Salut et merci pour vos réponses !

Les cron jobs, sincèrement.... j'ai de moins en moins confiance

Je dois pas savoir paramétré le truc sur OVH, mais ça marche quand ça veux bien

J'ai gardé la solution de Kpouer, et ça fonctionne très bien.
Bon, quand je vois la précision de Sekigo, je me dis que j'aurai peut être pu faire mieux, mais bon, ca ira pour l'usage que nous en avons

Merci de vos réponses/suggestions en tout cas

**Sekigo Le Magnifique** · 29/07/2015, 21h01

Chouette. Je dois réaliser un truc qui permette d'analyser des statistiques via une interface web.
Il y a un peu plus de 1 milliards d'entrée à l'heure actuelle (sur ~5 ans, je dirais). Et on mise sur une croissance de plus de 50% dans les années qui viennent.
Et j'ai une semaine pour faire ça.

Pour la partie interface et calcul, ça va, c'est du calcul de stats bébête, et des trucs avec des tableaux et des graphiques qui en jettent trop tavu. Le problème, c'est le volume et la tronche des données. Tout est dans des BD mysql, il y a des dizaines d'entrées par ligne. Et au vu de l'historique, je soupçonne un tas de cas problématique que je vais découvrir au fur et à mesure. Le schéma est lol (mais ça va, j'ai l'habitude, ça fait partie du folklore local), avec des tas de jointures et sans aucune documentation.
C'est vraiment LA base de donnée que je craignais d'attaquer depuis que je bosse dans mon entreprise. Et ce jour est arrivé.

Je ne sais même pas comment attaqué le machin. En plus, l'OS qui supporte tout ce bordel est du Debian squeeze (et ça reste "moderne" par rapport à d'autres trucs qu'on a, on a encore des machins en prod sur du centOS qui date de 2005. On est même complètement passé à travers la faille hearthbleed, parce que nos OS sont trop vieux).
Ceci dit, j'ai pas mal de marges de manœuvre sur comment réaliser le truc qu'on attend de moi. Ça devrait aller, mais bon, une semaine, c'est un peu short. Je sens que je vais péter les records de dépassement de temps alloué sur ce projet. Et je pense qu'en négociant, je peux réussir à obtenir une bécane pas dégueulasse, au moins pour la partie applicatif (en une semaine, j'ai pas le temps de faire une migration de BDD ou de changer le système de stockage des données, sauf extrême urgence genre une machine qui crame ou une connerie comme ça. Ça m'est déjà arrivé et c'est pas marrant).
Le pire, c'est qu'ils veulent du temps réel dans le cahier des charges. lol no.
Donc, ça sera dans une pile qui calculera et mettre en cache les résultats. Qui sera mise à jour toute les <insérer ici temps après dev et tests>. Il y aura du temps réel, mais bien plus tard.

Avé César, ceux qui vont mourir te salut.

**kpouer** · 29/07/2015, 21h35

Ah j'imagine que tu peux pas modifier la structure de données, j'avais un problème similaire, des CSV de 1 million de ligne par heure, 550 colonnes, j'ai réussi à convaincre que mysql était une mauvaise idée, et utilisé Lucene à la place, plus compact et 100 fois plus rapide.

**deathdigger** · 30/07/2015, 09h06

Faut voir ce qu'ils veulent comme stats.
Déjà, je pense que virer MySQL serait une bonne chose. Si ce sont des stats qui sont toujours les mêmes, tu peux te lancer sur une base NOSQL pour "linéariser" un peu tout ça. S'ils veulent pouvoir créer d'autres stats au fil du temps, le mieux c'est de garder la structure actuelle, mais la balancer sur un moteur un peu plus pêchu. Dans ce cas, part sur du PostGre ou du MS SQL. Si vraiment, ils veulent garder du MySQL, demande leur un serveur dédié. Tu copies les tables qui t'intéressent dedans, sauf que tu les mets en mémoire (memory store engine). Si t'as une bonne machine de guerre, ça devrait passer crème. Vu que t'es sur un backup, tu t'en fous d'avoir une perte de ta base en cas de crash, le lendemain, tout est remis d'équerre

**war-p** · 30/07/2015, 17h23

PostGre se prête tout à fait à ce genre de délire. Surtout qu'il y a des factures sympa pour les très gros volumes de données, genre bigdata.

**Longwelwind** · 31/07/2015, 20h37

De plus, avec les récentes additions sur les colonnes de types JSON, ça rend pratiquement obsolète les bases de données NoSQL dans 99% des cas.

**Longwelwind** · 02/08/2015, 22h21

Un article de Gamasutra qui liste des "dirty tricks" de programmation dans les jeux-vidéos.
Il y a entre autre un programmeur qui a écrit:

Code:

#define const

**vectra** · 13/08/2015, 16h43

Je sais pas si c'est Nvidia ou ATI, mais j'ai une offre de poste pour une mission de validation de drivers graphiques sur kernel Linux à Montpellier.

Les délais font que je pourrais pas postuler et ça me tente assez moyen comme mission. Me MP si intéressés.
Ils attendent un jeune ingénieur si j'ai bien compris, pour une mission longue.

**ducon** · 13/08/2015, 17h12

Envoyé par FB74

Arrête de jouer au cron.

On m'appelle ?

**Tomaka17** · 13/08/2015, 18h39

Envoyé par vectra

Je sais pas si c'est Nvidia ou ATI, mais j'ai une offre de poste pour une mission de validation de drivers graphiques sur kernel Linux à Montpellier.

Genre ils testent leur drivers maintenant

**vectra** · 13/08/2015, 19h04

On m'a dit "un grand groupe américain".

Après, j'ai la fiche de poste, ça a l'air méga-chiant.

Discussion: Le topic de la programmation, string, chaînes, cuir et compagnie

Outils de la discussion

Règles de messages