LupusMic a écrit 1481 commentaires

Avec le clavier.

:o) Oui c'était facile.

Sous Gnome, avec la disposition « France Alternative, eliminate dead keys » c'est <AltGR> + <Shift> + <Space>.

Sauf qu'il n'y a pas que le coût de développement et d'hébergement que tu devrais prendre en compte. N'oublie pas qu'il y a des clients pénibles qui veulent être servis comme des princes (même s'ils n'ont payé qu'un euro). C'est un coût important.

Tu auras un jour ou l'autre une catastrophe. On peut imaginer qu'un client mécontent dont l'activité aura été fortement malmenée par l'incident t'attaque. C'est aussi un coût qu'il faut prévoir, ainsi que le coût des assurances que tu auras souscrit. Et même si le statut d'auto-entrepreneur c'est bien pour se lancer, ça reste risqué puisque tu es redevable sur tes biens propres (tu n'es pas en repsonsabilité limitée).

En bref, je ne penses pas que tu devrais calquer le coût du service sur le seul investissement de base, mais que tu devrais à terme fonctionner avec un tarif basé sur les coûts de fonctionnement. C'est un bon filon que tu as là, correctement géré, tu peux rapidement croître et penser à adapter ton logiciel aux autres pays européens.

Je pense que tu sous-estimes l'aspect psychologique du prix. À 1€/mois on ne te prend pas au sérieux. Quand on voit ce que demandent les sites de rencontre (30 €/mois), on ne peut pas s'imaginer qu'un logiciel qui va te permettre de gérer une entreprise ne coûte pas plus cher. Si vraiment tu ne veux pas abandonner l'idée de l'abonnement à 1 €/mois, créé une marque blanche via laquelle tu vends le même service à 30 €/mois. Et compare. À la rigueur, tu pourrais considérer le 1€/mois comme un tarif social (pour les chômeurs auto-entrepreneurs). Une autre idée serait de facturer en fonction du CA, mais je ne sais pas si ce serait légal ou pratique, c'est une idée comme ça.

En tout cas le code est propre, bravo (même si en Python c'est dur de faire du moche). Il y a même des tests. Par contre je n'ai pas compris pourquoi tu mélanges des morceaux de vue avec le modèle (accounts.Invoice.to_pdf et accounts.Invoice.unicode). Enfin, je comprends pourquoi c'est là, je ne comprends juste pas pourquoi ça y est encore ;)

Je n'ai pas tout lu, mais c'est très encourageant pour le peut que j'ai lu (le module account).

Je suis bien d'accord avec ça. Mais je n'allais pas écrire une classe, ce qui aurait noyé le cœur du problème pour le néophyte auquel je répondais.

D'ailleurs, ce n'est pas tant le « gâchis » de le ligne que la violation du principe DRY qui me gêne dans la litanie de delete dans un destructeur.

Je crois que tu as marché dedans :D

Un smart pointer est un RAII…

Oui bon, pardon, j'ai toujours du mal avec certains acronymes.

D'ailleurs, à propos d'appel des destructeurs : il n'y a garanti de leur appel que si l'exception est attrapée. Si le programme avorte, le comportement est indéfini \o/

cEstVraiQueLeCamelCaseEmpecheTotalementDeFraireDesNomsEnormes

Pour relancer le troll, je dirais volontier que si le camelCase incite à limiter les noms de variable, c'est peut-être parce qu'il est illisible :D

Plus sérieusement, si un nom d'identifieur devient trop long, peut-être que la classe ou la fonction a un problème de conception ?

Il faut bien arriver à utiliser l'argument d'autorité de temps à autre :D

Ceci dit, lorsque les conventions sont mauvaises, il faut savoir les remettre en cause. Ça ne signifie pas de passer en force, mais d'en parler et d'argumenter le désir d'évolution.

Goto c'est très pratique en C. Je t'invites à aller fouiner du côté du code source de Linux.

Mon propos était de montrer du code qui compile, que ce n'est donc pas un critère suffisant pour déterminer la légalité d'un code source.

J'aimerais que tu m'expliques comment tu fais pour te passer de l'allocation dynamique en C++. Alors certes, l'usage d'un RAII et d'un helper sont conseillés, mais new et delete sont nécessaires à la vie quotidienne du développeur C++.

C'est vraiment détestable cette sale habitude de privilégier la popularité à la chronologie. Je n'aime déjà pas que la masse populaire censure les articles qui ne lui plaisent pas, alors qu'elle m'empêche de consulter ce qui pourrait m'intéresser. C'est un peut comme si les sites d'actualité ne parlaient que de ce qui intéresse la majorité. Le foot pour les sites d'actualité généralistes, MacOSX pour les sites d'actualités informatique.

Enfin, tant que le critère n'est pas caché comme l'horrible soupe magique de FB qui m'empêche de consulter les informations des amis les plus rares, ça ira.

C'est clairement une erreur de design.

En fait tu n'as pas compris où le problème se situe. C'est lors de la restitution de la valeur extrait de la queue que l'exception peut être lancée. C'est un point où on ne peut rien faire, et où on va perdre en cohérence.

Le but du mécanisme d'exception est de permettre la récupération d'une erreur en revenant dans l'état dans lequel on était avant la fonction qui a émis l'exception. Or ici, la fonction aura changé l'état de la queue lorsque l'exception pourra être lancée. L'état de la queue ne sera donc pas cohérente, une donnée aura été perdue.

Si la queue contient des ressources qui doivent être désallouées après usage, on aura également une belle fuite de ressources (mémoire, mutex, etc). Il est vrai que ces ressources devraient être gérées en RIAA, bon, soit. Mais le problème reste entier, puisque la ressource sera libérée mais qu'elle n'aura pas été utilisée comme attendu. Ce qui peut être un bogue très difficile à détecter.

C'est une préférence évidement. D'ailleurs Herb Sutter considère (dans C++ Coding Standard, chez Addisson Wesley) qu'un développeur sérieux ne devrait pas faire du camel case une barrière à sa compréhension du code. Après tout, nous arrivons bien à séparer les syllabes sans camel case quand nous lisons un texte en langue humaine.

Ceci dit, je déteste le camel case, je le trouve beaucoup moins lisible que le traditionnel style standard.

Que le code compile n'est pas une garantie de légalité. Il y a beaucoup de comportements indéfinis, qui supprime toute garantie de fonctionnement s'ils sont utilisés. C'est pour ça que l'argument « ça marche » n'a aucune légitimité dans un débat sur les technologies liées au développement.

class base { int n ; public:  virtual ~base() { } ; } ;
class derivated : public base { double d ; } ;

int main()
{
  base * a = new derivated [100] ;
  delete [] a ; // Oops
}

En fait, c'est surtout l'existence d'une implémentation correcte tant au niveau performances, portabilité et respectueuse de la norme qui posait encore problème en 2003. Surtout dans le cas d'un certain environnement propriétaire bien connu.

Ceci dit, depuis le temps, Qt aurait dû réécrire ces classes utilitaires en terme de classes standard, et conseiller l'usage des classes standard quand c'est possible.

De toute façon, Qt c'est moche, graphiquement :D

Certes, PḦP est une bouillie infâme au niveau des types numériques.

Un type numérique, c'est un type qui permet de représenter des nombres. En C les types numériques de base sont int, long, float, double et char. En PHP, effectivement, il y a int et float. Mais j'avoue que lorsque je pensais à l'expression « type numérique », je pensais à Javascript où seul le type numérique existe.

Les nombres flottant n'existent pas. float est un type numérique permettant de représenter de manière approximative les nombres réels. Mais en aucun cas on ne peut le considérer comme des nombres.

Bref, depuis j'ai testé quelques autres langages par curiosité. Avec CLisp, l'expression (/ 1 2) est évaluée à un demi, mais je ne connais pas assez LISP pour comprendre si CLisp retiens l'expression précise et attend pour évaluer par exemple. En Ruby, il faut qu'aussi bien le numérateur que le dénominateur soient un nombre décimal ou un flottant pour que l'expression soit évaluée à 0.5 (je ne connais pas le type par défaut utilisé pour stocker les nombres décimaux). Perl 5 évalue à 0.5 Bash évalue à 0, et ne comprends rien d'autre que les entiers. Lua évalue à 0.5.

Bref, voilà bien un détail à la con (ou gotcha) auquel il faut faire gaffe quand on apprend un nouveau langage.

Ce que tu ne sembles pas comprendre, c'est que le type std::string ne gère aucun encodage. L'autre chose que tu ne comprends pas, c'est qu'il y a beaucoup de code illégal qui compile, et qui semble marche étrangement sur ta machine. Par exemple, un buffer overflow est typiquement le résultat d'un programme « ça marche chez moi ».

std::string n'est pas dérivable publiquement. Comme tout les conteneurs de la STL, il n'ont pas été conçus pour être dérivables publiquement. La raison en est qu'ils ne disposent pas de fonctions virtuelles (tout le monde ne veut pas payer le coup de cet extra-pointer), et que du coup la dérivation publique n'a pas de sens (il n'est pas possible d'utiliser le polymorphisme).

J'ai écrit du Python ces 9 derniers mois, professionnellement, et je n'ai pas le souvenir d'être tombé sur ça.

Un certain nombre de langage bien connus utilisent des nombres réels et non des nombres naturels comme type de base pour les nombres. C'est le cas pour PHP, Javascript, XML (XPath), etc. Pour un langage tel que Python qui ne prétend pas surprendre, qui fournit par défaut un type numérique au delà des 2³², j'étais bien persuadé que lors d'une division, l'inférence de type fonctionnait correctement.

Tu as bien compris mon problème, mais alors la solution :D Tu aurais dit « ne pas utiliser l'outil pour sauter d'un nouveau commentaire à l'autre » revient à peu près au même. ;)

Il n'y a aucune différence entre un site web dont on contrôle le contenu et un site web dont on laisse les visiteurs poser des contenus. Considérer des données comme sur et n'y appliquer aucun traitement (ne serait-ce que pour éviter les bogues liés au parasitage du format de sortie) est une erreur grave.

Le fournisseur de flux est une donnée externe qui doit être filtrée. Si tu affiches les contenus provenant de sources externes que tu ne contrôle pas, tu t'exposes aux joies du javascript qui va venir prendre le contrôle du navigateur.

Je n'ai pas besoin de donner d'exemple. L'ensemble des appels à header, l'ensemble des formulaires sont des portes ouvertes pour les attaques.

Pour être plus concret, ce genre de construction est problématique :

./www/login-controler.php:36:   header("Location: http://$username.".DOMAIN_NAME."/auto-login.php?id=$id&verif=$verif_id");
./www/aggregate.php:17:header("Location:feed.php?id=$id&id_f=$id_f");

Dans ce cas, urlencode devrait suffire. Tu as 50 appels à header pour des redirections diverses. Plutôt que de toujours construire manuellement, tu devrais faire quelques fonctions utilitaires. Par exemple :

<?php
function http_redirect($url)
{
  header(sprintf('Location: %s', $url)) ;
}

function http_url($base, $path, $params, $secure=false)
{
  $base = urlencode($base) ;
  $path = urlencode($path) ;
  $searchpart = array() ;
  // Je ne prends pas en compte les paramètres à valeur multiple
  foreach($params as $name => $value)
    $searchpart[] = sprintf('%s=%s', urlencode($name), urlencode($value)) ;
  $searchpart = implode('&', $searchpart) ;

  return sprintf('%s://%s%s%s'
    , $secure ? 'https' : 'http'
    , $base
    , $path
    , '?' . $searchpart) ;
}

http_redirect(http_url('example.com', '/search', array('q' => 'Ceci est fou!')) ;

Ce n'est pas parce qu'il y a de moins en moins de personnes qui ne mettent plus de capotes que tu en fais autant. Du moins j'espère pour toi. Pour la sécurité c'est pareil. Quand je travaillais en support technique pour un hébergeur, mon plaisir quotidien était d'envoyer au client le message qui lui disait qu'il avait été détourné à cause d'un script mal fagoté, que les admin sys avaient dû suspendre. Les requêtes POST ne protègent absolument pas d'une attaque par CSRF. Il est possible de faire exécuter une requête POST par une requête AJAX sur un autre site visité dans le même navigateur, ou encore depuis un script que tu auras toi-même inclus via un flux RSS compromis. D'ailleurs, la protection contre les CSRF permet également de supprimer le bogue du double-post.

Ça fait longtemps que je n'ai pas craché sur le logiciel d'un débutant. Je vais donc en profiter pour souiller la nouvelle version de DLFP.

Mon opinion est que ce logiciel est un bon prototype. Les idées sont bonnes, ça fait des choses, et c'est bien. Mais le logiciel de doit absolument pas être utilisé en production car il n'y a aucune politique de sécurité appliquée lors du développement.

Lors de la construction des URL destinées aux redirections, les variables utilisées ne sont pas échapée. Étant donné qu'elles viennent de l'extérieur, il donc possible de forger des URL.

À la création du HTML, aucun contenu de variable utilisé pour la construction n'est filtré.

Aucun formulaire n'utilise la technique des token, ce qui rend les attaques par CSRF possibles.

Le formulaire de contact envoie des courriels, sans aucune protection aucune. Je prédis donc un grand avenir au robots spammeurs pour utiliser zenCancan. Car le logiciel aura du succès, il est très utile.

L'injection SQL semble évitée en raison de l'usage assez correct de PDO (oui, utiliser des statement n'est pas forcément une bonne idée, mais ça va au-delà de problèmes liés à la sécurité).

Bref, il y a du boulot :D

J'étais très content que la barre d'accès rapide au commentaires ait été intégrée dans la version normale de DLFP. Mais s'il y a bien une chose que je déteste, c'est le ralentissement de l'éffichage pour faire joli. C'est le genre de choses que je désactive d'office dans les interfaces graphiques (vous savez, les menus qui s'affichent transparents, ou se déroulent, les fenêtres qui se cachent progressivement dans la barre des tâches, etc).

Quand je parcours les commentaires sous une dépêche, j'ai besoin de quelques dixièmes de secondes pour décider si l'information est pertinente ou non. Mais le mouvement ralenti couplé aux performances catastrophiques d'un netbook, c'est tout simplement insupportable.

Ceci dit, la nouvelle version est plus jolie.

Le seul logiciel qui plante régulièrement sur mon ordinateur (un netbook avec 1GB de RAM), c'est le plugin Flash. Qui gonfle tellement que je suis obligé de le tuer régulièrement.

Je pense que ceux qui pensent que c'est Mozilla Firefox qui plante se fourvoient. C'est véritablement le plugin pourri d'Adobe qui fout le dawa.

Non, la solution est d'avoir une véritable politique de sécurité, en interdisant tout sauf cas exceptionnels. Dans mon cas, utiliser un mot de passe correct, même pour un utilisateur de tests est un premier pas.

Le soucis c'est que Jésus Christ est un personnage mythique, alors que Mahomet est un personnage historique.

http://www.zetetique.ldh.org/jesus.html