Ce qui est critiquable c'est la différence de traitement par linuxfr.
C'est minable.
C'est ton avis, et il n'engage que toi. Tu as le droit de ne pas être d'accord avec les modéros, certes, et même de le faire savoir à travers les journaux comme tu le fais ici... Mais rappelle toi qu'ils ont été désignés spécialement et uniquement pour décider ce qui doit ou non passer en news. Leur avis est donc souverain sur la question, et aussi stupide qu'il puisse te paraitre tu te dois de le respecter.
C'est au cas par cas suivant l'appli que tu choisiras... souvent c'est intégré à un moteur de templates pour la génération HTML/JS, les traitements étant gérés via un objet global (formulaire) avec des sous-objets (les champs). Mais je n'ai pas étudié le cas particulier de celui-là.
Est-ce qu'on gagne vraiment beaucoup de temps ?
Au début non, il faut apprendre à se servir de l'outil qui peut paraître exotique (c'est quand même assez abstrait). Mais dès la deuxième utilisation, quand tu commences à maîtriser la chose, les avantages apparaissent clairement et le gain de temps est réel, sans compter la maintenance ultra-aisée et unifiée sur l'ensemble de tes sites utilisant ce type de soft (si un test d'email est incomplet ou pose problème, il est facile de le modifier et/ou de l'étendre en répercutant directement les modifs sur l'ensemble de tes créations).
j'avais cru comprendre que tu avais quasiment terminé le lycée...
[...] bientot le lycée est fini pour moi. [...]
[mavie]ce n'est pas un exemple à suivre, mais j'ai dû passer l'essentiel de mes dernières années de lycée à coder en assembleur sur ma calculatrice :) [/mavie]
Ce qui est sûr, c'est qu'à part le lycée tu as du temps pour faire autre chose et découvrir ce qui te plaît. Profites en pour approfondir ton apprentissage de php, ou pour découvrir autre chose (ce que je te recommande)...
Il ya bien moyen d'etre embauché chez mandrake soft ou bien redhat non ?
Oui, bien sûr, encore faut-il avoir des compétences qui les intéressent et te pointer au moment ou ils ont besoin de quelqu'un avec le CV qui colle bien. Mais bosser dans le libre, c'est certain, c'est possible ! et il n'y a pas qu'eux qui en font, loin de là... Par contre, si tu n'as qu'une petite expérience php/mysql à présenter, sans aucun diplôme pour en attester, je doute que tu sois un candidat très intéressant pour eux... Ou alors pour un poste qui n'est probablement pas ce dont tu rêves.
Quand tu as fait deux sites webs (certains s'en apercoivent meme avant, d'autre après...), tu constates que certaines tâches sont à la fois particulièrement sensibles et répétitives à la fois : exemple, un formulaire permettant de s'inscrire à une mailing-list. un bête champ de saisie de texte et un bouton me diras-tu.... Oui, mais encore faut-il pouvoir vérifier que l'utilisateur ne rentre pas n'importe quoi pour que les données en base, nourries par le formulaire, restent valides. Et la validation d'une adresse e-mail est sans doute l'exemple le plus typique de tâche répétitive qu'on a à faire sur quasiment tous les sites webs.
Il est donc intéressant de se tourner vers ce type de logiciel qui te propose des méthodes unifiées pour :
- générer le code (x)HTML de tes formulaires
- Recevoir et traiter les données après la soumission du formulaire
- valider les données côté client et fournir des tests javascript adaptés
- valider également côté serveur (la validation javascript n'étant qu'un confort pour l'utilisateur et aucunement une sécurité)
- gérer intelligemment les erreurs (l'utilisateur s'est trompé dans son mot de passe ? ok, on lui redemande le mot de passe, mais pas besoin de lui faire resaisir son login, alors on réaffiche le login et on balance un message d'erreur adapté au pépin).
Tout ceci non seulement doit marcher impeccablement bien, pour la sécurité de ton site et le confort du visiteur, mais aussi fait appel à des compétences pointues en (x)HTML pour créer les formulaires, en PHP pour gérer les données et valider coté serveur, en javascript pour les messages d'erreur et le premier niveau de validation... C'est complexe et tout refaire à chaque site prend beaucoup de temps et entraine le risque d'une erreur qui peut tout faire péter (une possibilité d'injection SQL suite à des données mal ou pas validées par exemple).
Voilà pourquoi il est intéressant de se tourner vers ce type de programme, orienté composants. En gros, tu te bornes à dire "Je veux un champ de texte qui s'appelle email et qui doit être rempli avec une adresse email" et le programme se charge quasiment de tout le reste. C'est un gros gain de temps, surtout sur des formulaires complexes.
PS : ce genre de système devient encore plus intéressant s'il est extensible et s'il te permet de développer tes propres composants pour les utiliser selon le même schéma que les champs de formulaire ordinaires du HTML (par exemple : un wysiwyg, un calendrier...).
Je te conseillerai également une filière courte, en deux ans, type IUT/BTS (pourquoi pas en alternance, si tu veux être exploité gagner un peu d'argent et une première expérience professionnelle) éventuellement suivie d'un cursus plus long si tu es encore motivé par les études. Mais attention, quand on goûte au monde du boulot, on a plus du tout envie de bosser le soir... et souvent on a plus vraiment envie d'étudier. C'est donc un choix important.
Si tu te destines vraiment à devenir développeur, je te conseillerai une filière courte donc, déjà parceque tu y sauras très vite si ca te plait réellement ou pas, (mon premier choix en études supérieures était un IUT GeII sur les conseils d'un copain développeur et ca m'a pas emballé du tout, je suis parti après la première année), d'autre part les développeurs que je rencontre ont souvent une expérience et un niveau de maîtrise inversement proportionnels à la durée des études qu'ils ont fait... Ce n'est surement pas vrai dans 100% des cas, bien entendu... mais à ce que je vois c'est souvent comme ca.
Aussi, sans vouloir casser ton rêve, il faut bien que tu te rendes compte que si tu deviens effectivement développeur tu seras amené à travailler sur des projets qui ne te plairont pas du tout (Un exemple imaginaire ? Allez, embauché par macromedia pour pondre une version GNU/Linux, x86 uniquement, propriétaire (évidemment) de leur usine à cliquodromes, au hasard...). Parfois, tu auras la chance de travailler sur un projet qui te plait, mais c'est loin d'être tous les jours comme ca !
Réfléchis bien donc. Et saches que le métier de développeur peut s'apprendre bien avant d'avoir mis le pied dans une classe dédiée à cet enseignement... Pour voir si c'est vraiment ton truc, commence donc à développer dès maintenant ! Tu as de grandes vacances devant toi pour faire tes premiers pas, pourquoi ne pas essayer ?
J'avous que quand j'ai lancé Bulix.org (et par la même Zwe) il y a un an, je ne pensais pas que ca irait jusque là. A l'époque très peu de monde tenait un blog, maintenant celui qui n'en a pas passe pour un attardé du web multimédia interactif :)
J'apprécie le compliment. J'en connais un autre qui appréciera s'il tombe là dessus, il se reconnaïtra ;)
La documentation d'installation que tu as rédigée est particulièrement claire et complète, à mon avis, mes compliments.
Je ne sais pas ce que ton application vaut, mais ca a l'air bien. Comment l'estimes-tu par rapport à DotClear notamment ? (je n'essaierai probablement pas, car j'apprécie mon statut d'attardé du multimédia interactif et je tiens à le rester).
Parceque ca rend le prix de revient de chaque offre difficile à calculer et à mesurer objectivement sur un simple tableau.
Du coup, le consommateur que tu es n'a pas de vraie réponse à la question "lequel des opérateurs est le moins cher", ce qui leur évite d'être placés en concurrence frontale et en guerre des prix les uns envers les autres... Et ca leur fait donc plus de sousous.
Merci, ton post m'épargne un clic de curiosité (et une frustration potentielle une fois que j'aurai eu l'info d'avoir été chercher pour finalement m'apercevoir que ca ne m'intéresse pas).
L'internaute de base est d'un naturel curieux, soit, mais abuser de cette curiosité engendre des frustrations souvent irréversibles... (A méditer pour tous ceux qui ont ou auront un jour à diffuser des informations sur le web).
Avant d'émettre un jugement de valeur du type "c'est bien/c'est pas bien", il faudrait peut-être considérer les différences entre les deux produits : SQLite met l'accent sur la légèreté pour une intégration aisée dans la plupart des applications. PostgreSQL, lui, possède une grande richesse de types de données et de manières de les manipuler nativement (par exemple les dates, mais tout particulièrement les coordonnées).
Je ne parlerai pas des différences tellement flagrantes entre les deux SGBD que tout le monde ici doit connaître (PostgreSQL est un serveur tandis que SQLite est une bibliothèque, etc...).
Si tu prends en compte cette différence d'objectif (qui indique clairement que les deux projets partent dans des directions opposées dépouillement<>richesse), ca veut tout simplement dire que le choix entre l'un est l'autre t'es permis, suivant tes besoins et l'application sur laquelle tu veux greffer un SGBD. Mais déclarer unilatéralement que l'un n'est pas un "vrai" parcequ'il n'offre pas toutes les caractéristiques de l'autre, c'est une critique totalement aveugle et partisane (autant que le ton général de la news tu me diras...).
Autant soutenir que la smart n'est pas une voiture car elle n'offre que 2 places et un tout petit coffre, une voiture étant à la base faite pour le transport de passagers et/ou d'objets, c'est aussi stérile que ta remarque.
Oui, la question est ambigüe. Avant de donner son point de vue sur cette question, il faut d'abord voir comment on la comprend : soit "la science peut-elle venir en aide aux homosexuels" soit "l'homosexualité est-elle un problème médical". C'est quand même pas tout à fait pareil et la réponse dénote une pensée bien différente suivant la manière dont on a compris la question... Et ca m'étonnerait que le traitement de la réponse tienne compte de cette ambigüité !
ca dépend le diplôme, le boulot, la boîte, les avantages et le bonhomme...
Un bac+5 qui n'a jamais travaillé est souvent peu payé dans ses premières expériences, c'est "normal". De plus tout le monde ne trouve pas forcément le travail qu'il veut avec le salaire qu'il veut... du coup, les gens prennent ce qu'il y a pour avoir de quoi manger à la fin du mois.
J'ai connu aussi des bac+5 dont le travail fourni valait quelque chose comme ca, mais c'est un autre problème.
Si tu en es là il me semble que tu peux arrêter de disserter sur la gestion de la sécu. Le minimum c'est de mettre ta db en dehors de l'arbre exporté par le serveur Web. Les autres SGBD le font bien non ? :)
Ça c'est vraiment des mauvas arguments que tu nous sors
Ben moi je pense que tu ne vois pas de quoi je parle. Je parle à ceux qui nous lisent et qui n'ont pas tous essayé SQLite, en particulier sur un hébergement web mutualisé (sujet que je connais particulièrement bien). Si tu vas chez l'hébergeur du coin les bases MySQL sont stockées dans un répertoire inaccessible depuis le web, cela va de soi, c'est l'administrateur du serveur qui a fait les choses dans ce sens (un type sensé avoir les compétences en sécurité pour faire les choses qui vont bien). Je te rejoins quand tu dis que les fichiers ne sont pas plus sécurisés sur un SGBD que sur l'autre, mais la différence est que dans le cas de MySQL, l'admin a fait tout le boulot pour sécuriser les fichiers : dans le cas de SQLite, tout est à la charge de l'utilisateur. C'est lui l'administrateur qui gère la sécurité de sa base, sachant que le fichier concerné doit bien sûr avoir des permissions suffisantes pour faire des choses dessus avec le serveur web... Je ne pense pas qu'il soit inutile de le dire ici, sans doute tu as suffisament joué avec la chose pour considérer cela comme acquis, mais ce n'est certainement pas le cas de tout un chacun.
Je ne cherche pas tant à argumenter avec toi qu'à apporter de l'information utile à ceux qui ne se sont pas encore fait leur idée sur SQLite et sur des cas pratiques. Regarde en bas de cette page, il y en a... (Y'en a même qui vont acheter des bouquins sur le sujet, tu imagines ?)
> Ceci dit, je n'ai encore jamais crashé un apache bien configuré...
J'ai pas du etre assez clair en parlant de "bien configuré" : mon apache 1.3.27 d'easyphp sur ma machine de dev du boulot (sous windows, désolé, pas le choix), je le crashe au moins une fois par mois... ne serait-ce qu'avec la GD. Idem chez moi.
Mais un apache 2, sous GNU/linux, configuré et compilé convenablement, c'est autrement plus résistant, je maintiens.
Ça me parait une superbe ouverture pour rajouter des bugs ou pb de sécurité, enfin bon.
Tout dépend des patchs. Dois-je réellement t'expliquer à quel point ca peut rendre service de pouvoir modifier les sources et recompiler à volonté les programmes qu'on utilise tous les jours ?
Parce que ce n'est pas vrai pour le SGBD qui tombe dont tu parlais plus haut ?
également, ceci dit, un site dynamique sans sa base de données a peu d'intêret, tout comme un SGBD sans site pour l'attaquer. Je pense qu'il est plus aisé de gérer la sécurité et la fiabilité d'un seul démon plutot que de deux (qui de surcroit n'ont pas grand chose à voir l'un avec l'autre).
Sans compter que pour du mutualisé classique SQLite évite beaucoup de choses inutiles, notamment les phases de connexion/authentification. Coté perf ça joue beaucoup, surtout sur des petites applis.
Tout à fait, et tu as bien raison de le préciser : il y a là une considération importante à prendre en compte, à savoir que la sécurité d'une base SQLite comparée à son équivalent MySQL est nulle par défaut... C'est un simple fichier qui peut se retrouver accessible et téléchargeable par http si on n'y fait pas gaffe. La sécurité des données se trouve du coup à la charge du développeur, à grands coups de .htaccess.
ça ne changera rien pour les mutualisés, on foutra le process Apache par terre (vu que c'est lui qui fera le boulot). Je ne sais pas si c'est mieux.
J'avoue que je n'ai pas essayé. Ceci dit, je n'ai encore jamais crashé un apache bien configuré... Tu as testé ? Si oui, raconte nous ton expérience stp, ca m'intéresse beaucoup.
Ça c'est plutot le contraire, vu que tu ne pourras pas savoir qui provoque la charge (avec un serveur central tu peux compter les connexion ou regarder à un instant T qui est connecté).
SQlite ne génère qu'une requête d'ouverture de fichier en lecture/écriture, sauf à patcher les librairies systèmes je vois mal comment tu peux savoir qui charge ton serveur.
Patcher les librairies, quand tu prends en charge un tel hébergement, c'est pas un gros boulot et ca devrait être dans les cordes de tout admin qui se respecte. Je pense même que la plupart des serveurs mutualisés sont patchés à un moment ou à un autre de leur existence... Mais il y a bien d'autres façons d'y arriver.
Et dans le pire des cas, si, comme tu le décris plus haut, SQLite arrive à faire crasher le process apache (ce que je ne pense pas), Trouver le responsable et envoyer un mail automatique à l'admin n'est pas bien difficile à faire... Pas plus que de redémarrer apache immédiatement d'ailleurs, de sorte que la coupure soit la plus courte possible.
Pour avoir bossé chez un hébergeur web, je peux te dire que SQLite est certainement une bien meilleure idée de SGBD que MySQL pour les hébergements mutualisés. Pour quelques raisons simples :
- Il est facile de foutre un serveur mysql par terre avec une requete bien lourde qui ramène 3 millions d'enregistrements avec des jointures débiles, et là tous les hébergés souffrent du serveur qui tombe, pas seulement le crétin qui l'a fait tomber.
- La charge des serveurs mysql chez les gros hébergeurs mutualisés est souvent énorme et là aussi, tous les clients en souffrent (c'est encore plus vrai chez les hébergeurs gratuits, je pense notamment à free...). Les webmasters installent des scripts genre phpnuke sans se poser trop de questions et s'étonnent après que le serveur ralentisse jour après jour...
SQLite devrait contribuer à régler ces problèmes : on ne pourra plus crasher le serveur de bases de données commun, on pourra seulement crasher son propre process sans impacter les autres clients. De plus, cette individualisation de la charge rendra plus facile sà débusquer les clients qui abusent, par ignorance ou par bêtise, des (précieuses) ressources du serveur mutualisé.
Enfin, toujours dans le contexte spécifique du web, SQLite s'installe très facilement puisqu'il s'agit d'une simple extension php : on devrait donc la trouver absolument partout, alors que tous les hébergements web GNU/Linux
-apache-php actuels ne proposent pas systématiquement de base mysql associée (très souvent, mais pas toujours, notamment pour les moins chers et les gratuits, en partie à cause des raisons que j'ai évoquées plus haut).
Ce point était valable pour les versions 2.X de SQLite. Ca évolue dans la version 3.x, cf changelog dans cette news. L'auteur a surement oublié de mettre à jour ce point de la FAQ.
Faudrait quand meme nuancer un peu ton point de vue : si on a codé son modèle relationnel comme un goret (et ca existe, les gens comme ca, j'en connais...), si on a jamais eu quelques cours d'analyse pour savoir comment se servir efficacement d'un SGBD et des jointures, le gain de perfs risque d'etre très mince, voire meme négatif.
Les SGBD, c'est bien seulement quand on sait s'en servir.
Pffff, c'est limite du mauvais esprit ca :) Il faut prendre les bonnes choses là ou elles sont, et même avec ce genre de fonctionnalités, SQLite resterait beaucoup moins lourd que MySQL et garderait ses qualités parfaitement adaptées à l'embarqué.
Blague à part, tous les SGBD font face aux mêmes problèmes (le stockage et la gestion d'accès concurrents) avec les mêmes moyens (un système de fichiers X ou Y). Il est normal qu'on arrive parfois, voire souvent, aux mêmes solutions, non ?
Bémol. La limitation fondamentale de SQLite est son modèle de verrouillage rudimentaire, même comparé à MySQL. En effet, toute requête en écriture et même toute transaction ouverte sur la base verrouille toute la base de façon exclusive.
Bémol sur ton bémol : si tu lis un peu plus loin, tu verras qu'une solution est proposée pour pouvoir verouiller sur des tables : stocker une table par base (donc par fichier) et attacher les bases entre elles pour que le SGBD les voie comme une base unique :
A limited form of table-level locking is now also available in SQLite. If each table is stored in a separate database file, those separate files can be attached to the main database (using the ATTACH command) and the combined databases will function as one. But locks will only be acquired on individual files as needed. So if you redefine "database" to mean two or more database files, then it is entirely possible for two processes to be writing to the same database at the same time. To further support this capability, commits of transactions involving two or more ATTACHed database are now atomic.
c'est sûr, c'est quand même assez contraignant...
L'idéal serait, je pense, de pouvoir spécifier le mode de stockage des tables lors de la création de la base (dans un fichier unique pour toutes les tables, ou dans un répertoire unique avec des fichiers distincts par table). Et là on aurait à moindres frais un verouillage au niveau de la table...
Je vais envoyer un e-mail au mainteneur pour lui proposer l'idée.
Marrant, cette news me rappelle que je cherchais il y a quelques temps à acheter en ligne un ou plusieurs jeux de cartes à jouer standards (des vrais jeux, avec 54 bouts de carton imprimés). J'ai googeulisé tant et plus, je n'ai pas trouvé...
Vous connaissez des sites qui vendent ca, vous ? (si possible pas trop cher)
[^] # Re: Journal
Posté par Cali_Mero . En réponse au journal MERDE !!!. Évalué à 1.
C'est minable.
C'est ton avis, et il n'engage que toi. Tu as le droit de ne pas être d'accord avec les modéros, certes, et même de le faire savoir à travers les journaux comme tu le fais ici... Mais rappelle toi qu'ils ont été désignés spécialement et uniquement pour décider ce qui doit ou non passer en news. Leur avis est donc souverain sur la question, et aussi stupide qu'il puisse te paraitre tu te dois de le respecter.
[^] # Re: gestionnaire de formulaire ?
Posté par Cali_Mero . En réponse à la dépêche Formsess, pour les formulaires et les templates. Évalué à 2.
C'est au cas par cas suivant l'appli que tu choisiras... souvent c'est intégré à un moteur de templates pour la génération HTML/JS, les traitements étant gérés via un objet global (formulaire) avec des sous-objets (les champs). Mais je n'ai pas étudié le cas particulier de celui-là.
Est-ce qu'on gagne vraiment beaucoup de temps ?
Au début non, il faut apprendre à se servir de l'outil qui peut paraître exotique (c'est quand même assez abstrait). Mais dès la deuxième utilisation, quand tu commences à maîtriser la chose, les avantages apparaissent clairement et le gain de temps est réel, sans compter la maintenance ultra-aisée et unifiée sur l'ensemble de tes sites utilisant ce type de soft (si un test d'email est incomplet ou pose problème, il est facile de le modifier et/ou de l'étendre en répercutant directement les modifs sur l'ensemble de tes créations).
[^] # Re: Les écoles d'ingé diversifient de plus en plus leur voies de recrutement.
Posté par Cali_Mero . En réponse au journal [Boulot] Gnu Linux / BSD / HURD ?. Évalué à 3.
[...] bientot le lycée est fini pour moi. [...]
[mavie]ce n'est pas un exemple à suivre, mais j'ai dû passer l'essentiel de mes dernières années de lycée à coder en assembleur sur ma calculatrice :) [/mavie]
Ce qui est sûr, c'est qu'à part le lycée tu as du temps pour faire autre chose et découvrir ce qui te plaît. Profites en pour approfondir ton apprentissage de php, ou pour découvrir autre chose (ce que je te recommande)...
Il ya bien moyen d'etre embauché chez mandrake soft ou bien redhat non ?
Oui, bien sûr, encore faut-il avoir des compétences qui les intéressent et te pointer au moment ou ils ont besoin de quelqu'un avec le CV qui colle bien. Mais bosser dans le libre, c'est certain, c'est possible ! et il n'y a pas qu'eux qui en font, loin de là... Par contre, si tu n'as qu'une petite expérience php/mysql à présenter, sans aucun diplôme pour en attester, je doute que tu sois un candidat très intéressant pour eux... Ou alors pour un poste qui n'est probablement pas ce dont tu rêves.
Terminer ta formation tu dois, jeune Skywalker (© Maître Yoda)
[^] # Re: gestionnaire de formulaire ?
Posté par Cali_Mero . En réponse à la dépêche Formsess, pour les formulaires et les templates. Évalué à 10.
Quand tu as fait deux sites webs (certains s'en apercoivent meme avant, d'autre après...), tu constates que certaines tâches sont à la fois particulièrement sensibles et répétitives à la fois : exemple, un formulaire permettant de s'inscrire à une mailing-list. un bête champ de saisie de texte et un bouton me diras-tu.... Oui, mais encore faut-il pouvoir vérifier que l'utilisateur ne rentre pas n'importe quoi pour que les données en base, nourries par le formulaire, restent valides. Et la validation d'une adresse e-mail est sans doute l'exemple le plus typique de tâche répétitive qu'on a à faire sur quasiment tous les sites webs.
Il est donc intéressant de se tourner vers ce type de logiciel qui te propose des méthodes unifiées pour :
- générer le code (x)HTML de tes formulaires
- Recevoir et traiter les données après la soumission du formulaire
- valider les données côté client et fournir des tests javascript adaptés
- valider également côté serveur (la validation javascript n'étant qu'un confort pour l'utilisateur et aucunement une sécurité)
- gérer intelligemment les erreurs (l'utilisateur s'est trompé dans son mot de passe ? ok, on lui redemande le mot de passe, mais pas besoin de lui faire resaisir son login, alors on réaffiche le login et on balance un message d'erreur adapté au pépin).
Tout ceci non seulement doit marcher impeccablement bien, pour la sécurité de ton site et le confort du visiteur, mais aussi fait appel à des compétences pointues en (x)HTML pour créer les formulaires, en PHP pour gérer les données et valider coté serveur, en javascript pour les messages d'erreur et le premier niveau de validation... C'est complexe et tout refaire à chaque site prend beaucoup de temps et entraine le risque d'une erreur qui peut tout faire péter (une possibilité d'injection SQL suite à des données mal ou pas validées par exemple).
Voilà pourquoi il est intéressant de se tourner vers ce type de programme, orienté composants. En gros, tu te bornes à dire "Je veux un champ de texte qui s'appelle email et qui doit être rempli avec une adresse email" et le programme se charge quasiment de tout le reste. C'est un gros gain de temps, surtout sur des formulaires complexes.
PS : ce genre de système devient encore plus intéressant s'il est extensible et s'il te permet de développer tes propres composants pour les utiliser selon le même schéma que les champs de formulaire ordinaires du HTML (par exemple : un wysiwyg, un calendrier...).
[^] # Re: Les écoles d'ingé diversifient de plus en plus leur voies de recrutement.
Posté par Cali_Mero . En réponse au journal [Boulot] Gnu Linux / BSD / HURD ?. Évalué à 4.
Si tu te destines vraiment à devenir développeur, je te conseillerai une filière courte donc, déjà parceque tu y sauras très vite si ca te plait réellement ou pas, (mon premier choix en études supérieures était un IUT GeII sur les conseils d'un copain développeur et ca m'a pas emballé du tout, je suis parti après la première année), d'autre part les développeurs que je rencontre ont souvent une expérience et un niveau de maîtrise inversement proportionnels à la durée des études qu'ils ont fait... Ce n'est surement pas vrai dans 100% des cas, bien entendu... mais à ce que je vois c'est souvent comme ca.
Aussi, sans vouloir casser ton rêve, il faut bien que tu te rendes compte que si tu deviens effectivement développeur tu seras amené à travailler sur des projets qui ne te plairont pas du tout (Un exemple imaginaire ? Allez, embauché par macromedia pour pondre une version GNU/Linux, x86 uniquement, propriétaire (évidemment) de leur usine à cliquodromes, au hasard...). Parfois, tu auras la chance de travailler sur un projet qui te plait, mais c'est loin d'être tous les jours comme ca !
Réfléchis bien donc. Et saches que le métier de développeur peut s'apprendre bien avant d'avoir mis le pied dans une classe dédiée à cet enseignement... Pour voir si c'est vraiment ton truc, commence donc à développer dès maintenant ! Tu as de grandes vacances devant toi pour faire tes premiers pas, pourquoi ne pas essayer ?
# Du feedback...
Posté par Cali_Mero . En réponse au journal Zwe v1.1. Évalué à 2.
J'apprécie le compliment. J'en connais un autre qui appréciera s'il tombe là dessus, il se reconnaïtra ;)
La documentation d'installation que tu as rédigée est particulièrement claire et complète, à mon avis, mes compliments.
Je ne sais pas ce que ton application vaut, mais ca a l'air bien. Comment l'estimes-tu par rapport à DotClear notamment ? (je n'essaierai probablement pas, car j'apprécie mon statut d'attardé du multimédia interactif et je tiens à le rester).
[^] # Re: Et QuickForm
Posté par Cali_Mero . En réponse à la dépêche Formsess, pour les formulaires et les templates. Évalué à 6.
PHPLib : http://phplib.sourceforge.net/(...)
OOHForms : http://www.sanisoft.com/phplib/manual/oohforms.php(...)
# icones
Posté par Cali_Mero . En réponse au journal icones. Évalué à 8.
[^] # Re: vers la telephonie mobile
Posté par Cali_Mero . En réponse au journal AOL et les clauses abusives.... Évalué à 3.
Du coup, le consommateur que tu es n'a pas de vraie réponse à la question "lequel des opérateurs est le moins cher", ce qui leur évite d'être placés en concurrence frontale et en guerre des prix les uns envers les autres... Et ca leur fait donc plus de sousous.
[^] # Re: ahma
Posté par Cali_Mero . En réponse au journal besoin d'une todolist ?. Évalué à 1.
L'internaute de base est d'un naturel curieux, soit, mais abuser de cette curiosité engendre des frustrations souvent irréversibles... (A méditer pour tous ceux qui ont ou auront un jour à diffuser des informations sur le web).
[^] # Re: lire attentivement
Posté par Cali_Mero . En réponse à la dépêche Ça bouge du côté de SQLite !. Évalué à 2.
Je ne parlerai pas des différences tellement flagrantes entre les deux SGBD que tout le monde ici doit connaître (PostgreSQL est un serveur tandis que SQLite est une bibliothèque, etc...).
Si tu prends en compte cette différence d'objectif (qui indique clairement que les deux projets partent dans des directions opposées dépouillement<>richesse), ca veut tout simplement dire que le choix entre l'un est l'autre t'es permis, suivant tes besoins et l'application sur laquelle tu veux greffer un SGBD. Mais déclarer unilatéralement que l'un n'est pas un "vrai" parcequ'il n'offre pas toutes les caractéristiques de l'autre, c'est une critique totalement aveugle et partisane (autant que le ton général de la news tu me diras...).
Autant soutenir que la smart n'est pas une voiture car elle n'offre que 2 places et un tout petit coffre, une voiture étant à la base faite pour le transport de passagers et/ou d'objets, c'est aussi stérile que ta remarque.
[^] # Re: Hyper Caricatural
Posté par Cali_Mero . En réponse au journal Politique en deux dimensions.. Évalué à 2.
[^] # Re: Grosse bidouille
Posté par Cali_Mero . En réponse au journal graphe de dépendances d'un source php. Évalué à 3.
[^] # Re: Ca dépend
Posté par Cali_Mero . En réponse au journal Quelle salaire pour un Bac+2. Évalué à 2.
Un bac+5 qui n'a jamais travaillé est souvent peu payé dans ses premières expériences, c'est "normal". De plus tout le monde ne trouve pas forcément le travail qu'il veut avec le salaire qu'il veut... du coup, les gens prennent ce qu'il y a pour avoir de quoi manger à la fin du mois.
J'ai connu aussi des bac+5 dont le travail fourni valait quelque chose comme ca, mais c'est un autre problème.
[^] # Re: Aussi pour de petits sites
Posté par Cali_Mero . En réponse à la dépêche Ça bouge du côté de SQLite !. Évalué à 1.
Ça c'est vraiment des mauvas arguments que tu nous sors
Ben moi je pense que tu ne vois pas de quoi je parle. Je parle à ceux qui nous lisent et qui n'ont pas tous essayé SQLite, en particulier sur un hébergement web mutualisé (sujet que je connais particulièrement bien). Si tu vas chez l'hébergeur du coin les bases MySQL sont stockées dans un répertoire inaccessible depuis le web, cela va de soi, c'est l'administrateur du serveur qui a fait les choses dans ce sens (un type sensé avoir les compétences en sécurité pour faire les choses qui vont bien). Je te rejoins quand tu dis que les fichiers ne sont pas plus sécurisés sur un SGBD que sur l'autre, mais la différence est que dans le cas de MySQL, l'admin a fait tout le boulot pour sécuriser les fichiers : dans le cas de SQLite, tout est à la charge de l'utilisateur. C'est lui l'administrateur qui gère la sécurité de sa base, sachant que le fichier concerné doit bien sûr avoir des permissions suffisantes pour faire des choses dessus avec le serveur web... Je ne pense pas qu'il soit inutile de le dire ici, sans doute tu as suffisament joué avec la chose pour considérer cela comme acquis, mais ce n'est certainement pas le cas de tout un chacun.
Je ne cherche pas tant à argumenter avec toi qu'à apporter de l'information utile à ceux qui ne se sont pas encore fait leur idée sur SQLite et sur des cas pratiques. Regarde en bas de cette page, il y en a... (Y'en a même qui vont acheter des bouquins sur le sujet, tu imagines ?)
> Ceci dit, je n'ai encore jamais crashé un apache bien configuré...
J'ai pas du etre assez clair en parlant de "bien configuré" : mon apache 1.3.27 d'easyphp sur ma machine de dev du boulot (sous windows, désolé, pas le choix), je le crashe au moins une fois par mois... ne serait-ce qu'avec la GD. Idem chez moi.
Mais un apache 2, sous GNU/linux, configuré et compilé convenablement, c'est autrement plus résistant, je maintiens.
Ça me parait une superbe ouverture pour rajouter des bugs ou pb de sécurité, enfin bon.
Tout dépend des patchs. Dois-je réellement t'expliquer à quel point ca peut rendre service de pouvoir modifier les sources et recompiler à volonté les programmes qu'on utilise tous les jours ?
Parce que ce n'est pas vrai pour le SGBD qui tombe dont tu parlais plus haut ?
également, ceci dit, un site dynamique sans sa base de données a peu d'intêret, tout comme un SGBD sans site pour l'attaquer. Je pense qu'il est plus aisé de gérer la sécurité et la fiabilité d'un seul démon plutot que de deux (qui de surcroit n'ont pas grand chose à voir l'un avec l'autre).
[^] # Re: les isos?
Posté par Cali_Mero . En réponse à la dépêche Les ISO de SuSE 9.1 version personnelle sont enfin disponibles.... Évalué à 3.
je n'en vois qu'une
Passe faire un tour chez afflelou, un de ces jours.
[^] # Re: Aussi pour de petits sites
Posté par Cali_Mero . En réponse à la dépêche Ça bouge du côté de SQLite !. Évalué à 2.
Tout à fait, et tu as bien raison de le préciser : il y a là une considération importante à prendre en compte, à savoir que la sécurité d'une base SQLite comparée à son équivalent MySQL est nulle par défaut... C'est un simple fichier qui peut se retrouver accessible et téléchargeable par http si on n'y fait pas gaffe. La sécurité des données se trouve du coup à la charge du développeur, à grands coups de .htaccess.
ça ne changera rien pour les mutualisés, on foutra le process Apache par terre (vu que c'est lui qui fera le boulot). Je ne sais pas si c'est mieux.
J'avoue que je n'ai pas essayé. Ceci dit, je n'ai encore jamais crashé un apache bien configuré... Tu as testé ? Si oui, raconte nous ton expérience stp, ca m'intéresse beaucoup.
Ça c'est plutot le contraire, vu que tu ne pourras pas savoir qui provoque la charge (avec un serveur central tu peux compter les connexion ou regarder à un instant T qui est connecté).
SQlite ne génère qu'une requête d'ouverture de fichier en lecture/écriture, sauf à patcher les librairies systèmes je vois mal comment tu peux savoir qui charge ton serveur.
Patcher les librairies, quand tu prends en charge un tel hébergement, c'est pas un gros boulot et ca devrait être dans les cordes de tout admin qui se respecte. Je pense même que la plupart des serveurs mutualisés sont patchés à un moment ou à un autre de leur existence... Mais il y a bien d'autres façons d'y arriver.
Et dans le pire des cas, si, comme tu le décris plus haut, SQLite arrive à faire crasher le process apache (ce que je ne pense pas), Trouver le responsable et envoyer un mail automatique à l'admin n'est pas bien difficile à faire... Pas plus que de redémarrer apache immédiatement d'ailleurs, de sorte que la coupure soit la plus courte possible.
# "C'est sur, ca va les changer"
Posté par Cali_Mero . En réponse à la dépêche Les ISO de SuSE 9.1 version personnelle sont enfin disponibles.... Évalué à 4.
Voilà une bien bonne nouvelle :)
[^] # Re: Aussi pour de petits sites
Posté par Cali_Mero . En réponse à la dépêche Ça bouge du côté de SQLite !. Évalué à 7.
- Il est facile de foutre un serveur mysql par terre avec une requete bien lourde qui ramène 3 millions d'enregistrements avec des jointures débiles, et là tous les hébergés souffrent du serveur qui tombe, pas seulement le crétin qui l'a fait tomber.
- La charge des serveurs mysql chez les gros hébergeurs mutualisés est souvent énorme et là aussi, tous les clients en souffrent (c'est encore plus vrai chez les hébergeurs gratuits, je pense notamment à free...). Les webmasters installent des scripts genre phpnuke sans se poser trop de questions et s'étonnent après que le serveur ralentisse jour après jour...
SQLite devrait contribuer à régler ces problèmes : on ne pourra plus crasher le serveur de bases de données commun, on pourra seulement crasher son propre process sans impacter les autres clients. De plus, cette individualisation de la charge rendra plus facile sà débusquer les clients qui abusent, par ignorance ou par bêtise, des (précieuses) ressources du serveur mutualisé.
Enfin, toujours dans le contexte spécifique du web, SQLite s'installe très facilement puisqu'il s'agit d'une simple extension php : on devrait donc la trouver absolument partout, alors que tous les hébergements web GNU/Linux
-apache-php actuels ne proposent pas systématiquement de base mysql associée (très souvent, mais pas toujours, notamment pour les moins chers et les gratuits, en partie à cause des raisons que j'ai évoquées plus haut).
# une idée
Posté par Cali_Mero . En réponse au journal Portable 386 4MoRAM. Évalué à 2.
http://www.ordinosaure.free.fr/index.php?SystemedExploitation(...)
[^] # Re: lire attentivement
Posté par Cali_Mero . En réponse à la dépêche Ça bouge du côté de SQLite !. Évalué à 4.
[^] # Re: SQLite ca accèlère l'Internet ?
Posté par Cali_Mero . En réponse à la dépêche Ça bouge du côté de SQLite !. Évalué à 3.
Les SGBD, c'est bien seulement quand on sait s'en servir.
[^] # Re: Oui, mais... [workaround]
Posté par Cali_Mero . En réponse à la dépêche Ça bouge du côté de SQLite !. Évalué à 2.
Blague à part, tous les SGBD font face aux mêmes problèmes (le stockage et la gestion d'accès concurrents) avec les mêmes moyens (un système de fichiers X ou Y). Il est normal qu'on arrive parfois, voire souvent, aux mêmes solutions, non ?
[^] # Oui, mais... [workaround]
Posté par Cali_Mero . En réponse à la dépêche Ça bouge du côté de SQLite !. Évalué à 6.
Bémol sur ton bémol : si tu lis un peu plus loin, tu verras qu'une solution est proposée pour pouvoir verouiller sur des tables : stocker une table par base (donc par fichier) et attacher les bases entre elles pour que le SGBD les voie comme une base unique :
A limited form of table-level locking is now also available in SQLite. If each table is stored in a separate database file, those separate files can be attached to the main database (using the ATTACH command) and the combined databases will function as one. But locks will only be acquired on individual files as needed. So if you redefine "database" to mean two or more database files, then it is entirely possible for two processes to be writing to the same database at the same time. To further support this capability, commits of transactions involving two or more ATTACHed database are now atomic.
c'est sûr, c'est quand même assez contraignant...
L'idéal serait, je pense, de pouvoir spécifier le mode de stockage des tables lors de la création de la base (dans un fichier unique pour toutes les tables, ou dans un répertoire unique avec des fichiers distincts par table). Et là on aurait à moindres frais un verouillage au niveau de la table...
Je vais envoyer un e-mail au mainteneur pour lui proposer l'idée.
# Limite HS
Posté par Cali_Mero . En réponse à la dépêche Premier jeu de cartes en SVG pur. Évalué à 2.
Vous connaissez des sites qui vendent ca, vous ? (si possible pas trop cher)