Maxime a écrit 2334 commentaires

l'obligation de dénéiger

Je suis en appartement, il n'a pas vraiment neigé ici l'année dernière ni cette année donc je ne sais pas trop comment cela va se passer mais dans mon ancien appartement je ne pouvais même plus sortir mon véhicule du garage car la pente était givrée.

Toute mon enfance j'étais en maison individuelle en campagne et je n'ai jamais connu ce problème. Bon faut dire que dans la région Toulousaine la neige c'est pas fréquent, mais quand même…

Je vis en appartement car je n'ai pas envie d'avoir des temps de transport longs. Mais clairement le jour où j'ai une famille, j'ai l'intention d'avoir une maison pour offrir à mes enfants le cadre de vie que j'ai connu quand j'étais jeune.

J'aimerais une source fiable avant de le commenter. Est-ce bien 1 million ? Dans quelle situation ? Que des trajets faciles ? Combien de fois le pilote a eu besoin de reprendre la main pour éviter un accident ?

J'y crois à terme, mais dans un premier temps on aura juste de la conduite sur parking et de l'assistance++ pour le conducteur du véhicule.

J'aime bien ce sujet car cela soulève plein de questions. Par exemple : qui est le responsable en cas d'accident ? L'assureur propose de prendre toute la responsabilité ? Le constructeur ? Le passager ?

Le problème c'est la phase de transition où il y a des voitures autonomes et des humains. S'il n'y avait que des voitures autonomes, on saurait déjà faire. Mais là il faut s'attendre à n'importe quelle connerie sortant du code de la route.

Je dis pas que python ou le typage dynamique c'est mal, mais juste que si tu te retrouves à réinventer le concept de types alors il y a un peut-être un problème dans ton choix de langage :)

L'intérêt du Python ne réside pas uniquement dans son typage dynamique, et on peut aimer faire du Python sans adhérer complètement au langage. La plupart du temps je pourrais préciser un type pour mes variables sauf quand une fonction utilise une méthode en particulier (c'est un peu plus flexible qu'une interface ou que de l'héritage multiple pour moi, donc c'est compliqué d'y affecter un type).

En tout cas, si le papa de Python travaille sur le type hinting pour Python, je ne pense pas qu'il s'agisse véritablement d'un problème de choix du langage.

À l'opposée, qui sait même où chercher la documentation pour écrire un programme simpliste dont la sortie soit un tableau sous LibreOffice ?

Heu, tu génères un CSV et puis voilà, c'est plus simple qu'un tableau latex. Et tu peux probablement utiliser libre office en ligne de commande pour convertir au format de ton choix.

Je ne suis pas sûr d'avoir compris le commentaire de Groumly, j'espère que je ne réponds pas à côté. En tout cas je suis d'accord avec flan sur la conclusion.

@Groumly : lorsque tu fais du polymorphisme en Java, tu ne testes pas les types, cela va appeler la bonne méthode. Et bien en Python c'est la même chose en encore plus flexible. Mais ce qui te gêne c'est donc si on balance un objet qui a le malheur d'avoir une méthode avec le bon nom. Et bien c'est incorrect et ça produira une mauvaise sortie. On peut regretter de ne pas voir le problème dès la compilation d'où le besoin d'annoter les types. Sinon on le verra au niveau des tests unitaires s'ils sont bien faits.

Donc vraiment, c'est très rare d'avoir besoin de filtrer et surtout ce n'est pas une obligation. Ce n'est pas parce que je fais une fonction foo que je suis obligé de la rendre générique pour tous les types imaginables.

Si en Java tu as le choix entre deux méthodes A et B avec la même signature alors tu peux remplacer l'appel à la méthode A par la méthode B sans problème de compilation. Ça ne fera certainement pas ce que tu voulais à l'exécution…

Bon et bien là c'est pareil (en pire car le type n'est pas précisé donc plus simple de se planter) : si tu n'appelles pas la bonne fonction, on ne peut plus rien pour toi.

Et bien ça va planter ou ne pas faire ce que tu voudrais… C'est pourquoi tu dois avoir un nom de fonction et/ou un commentaire qui te dit clairement avec quoi tu peux l'utiliser. C'est pas fait pour éviter les bugs, c'est fait pour permettre plus de flexibilité si nécessaire (genre tout le code est similaire et tu n'as qu'un truc qui dépend de si l'objet a telle ou telle méthode).

Ce qui me gène c'est cette phrase :

Sauf que le problème est là. Une variable pouvant être de n'importe quel type, il faut aussi s'attendre à recevoir n'importe quel type et dans le cas échéant filtrer sur les types que l'on désir traiter.

Non on est pas forcément obligé de filtrer, c'est moche. Soit on est en capacité de gérer la chose par polymorphisme et dans ce cas on ne filtre pas. Soit on fait des fonctions différentes. Comme en Java quoi.

Bref, rajouter de l'annotation de type dans Python c'est très bien cela permettra de catcher certains problèmes en amont des tests. Ce qui me gène c'est qu'on dit que le problème c'est de devoir gérer tous les cas possibles dans la fonction. Non c'est pas vrai, si on n'appelle pas la bonne fonction ça marchera pas c'est tout. Et le problème est simplement qu'en Python ça va casser à l'exécution et pas à la compilation.

Mais pour vérifier, au lieu de te reposer sur la compilation, tu te reposes sur les tests unitaires. Ma dernière phrase était une boutade de toute façon, pas la peine de chercher trop loin :D.

Ce qu'il faut retenir de mon message c'est que le problème n'est pas, comme le laisse supposer le journal, le fait qu'on puisse coder une fonction sans se limiter au niveau des types. Le problème c'est qu'à cause de ça, on ne peut pas attraper rapidement des erreurs triviales. Et je crois qu'on est d'accord.

Sauf que le problème est là. Une variable pouvant être de n'importe quel type, il faut aussi s'attendre à recevoir n'importe quel type et dans le cas échéant filtrer sur les types que l'on désir traiter.

Non, ce n'est pas un problème, c'est une fonctionnalité. Si tu veux faire des fonctions qui gèrent plusieurs types de manière transparente bah c'est cool. Et t'es pas obligé de filtrer, tu peux faire comme avec les langages un peu plus typés : faire plusieurs fonctions pour gérer les différents types.

Le seul problème c'est l'absence de vérification du typage au moment de la compilation pour attraper au plus tôt des problèmes. Mais si le code n'est pas buggué, ce n'est pas un problème.

Le typage des arguments des fonctions en Python c'est intégré dans Python 3 depuis 2006 : https://www.python.org/dev/peps/pep-3107/

PyCharm utilise d'ailleurs ce typage pour proposer de la complétion intelligente : https://www.jetbrains.com/pycharm/webhelp/type-hinting-in-pycharm.html

C'est con, d'un point de vue utilisateur je n'ai pas à m'en plaindre, ça fait pas longtemps qu'on a migré. Tu as des précisions sur cette migration ?

• Contact Office, le choix de l'Université Paul Sabatier à Toulouse et désormais le choix de l'Université de Toulouse dans son ensemble.

Qui est-ce que tu inclues dans l'Université de Toulouse ? Ici à l'INSA de Toulouse (membre de l'Université de Toulouse), nous tournons sur du BlueMind.

Avec l'intégration des contacts, il est possible d'ajouter manuellement un contact ou bien d'importer vos contacts Gmail.

Ça marche pour vous ? J'ai testé sur mes 2 machines sans succès, j'arrive sur une page d'erreur de google.

The OAuth client was not found.

        scope=https://www.google.com/m8/feeds
        response_type=code
        redirect_uri=urn:ietf:wg:oauth:2.0:oob:auto
        client_id=no-google-oauth-api-clientid

Ma source est : https://marketplace.firefox.com/statistics/apps-available-by-type/?start=2014-11-07&end=2014-12-07&interval=day

On peut voir que la majorité des applications disponibles pour Firefox OS sont de type "Packagée". N'ayant pas testé cette appli en particulier je ne vais pas en parler.

Ce slogan a toujours été accompagné d'une mention « mais sans les perfs. », non ? Je veux dire, on parle bien de Java là.

Ok j'avais oublié ce point. Mais je ne vois pas en quoi s'embêter avec l'hébergement de son appli est plus simple que de balancer un zip sur le MarketPlace. Surtout si on doit gérer le mode offline.

Pourquoi, une appli native c'est mieux? Parce que ca attend pas une réponse du serveur pour réagir…

Ce que tu dis est faux. La majorité des applications disponibles pour Firefox OS sont packagées afin d'être entièrement téléchargées et ne plus avoir besoin d'un accès au web ensuite. Donc ça n'attend pas spécialement une réponse du serveur pour réagir, c'est juste un gros code javascript.

Ca regroupe les desavantages natif + web (sotre pete couille a gerer, deployment non controles et mauvaises performances), sans avoir le moindre avantage.
Ya pas de mal a faire des applis web, mais deployez les sur le web, ca vous rendra la vie plus simple.

Heu, ça permet d'utiliser l'appli sans connexion internet ? Et pour des téléphones low-cost utilisés avec des forfaits avec peu de data, cela me parait essentiel.

Mozilla n'a pas les moyens actuellement de s'imposer et aucun gros développeur ne va proposer un jeu à succès sur Firefox OS sans le proposer sur Android et iOS.

Donc pour moi, Mozilla doit pousser pour qu'un maximum d'applis soient faites en HTML pour qu'au moins cela ne soit pas un frein supplémentaire. Ils devront alors faire la différence sur l'OS : plus simple / plus rapide / tourne sur smartphone low-cost…

Surtout faire attention aux nombres, il faut relativiser avec la concurrence.

Difficile de les comparer… Le "plus de" n'était pas ici un jugement, j'aurais pu utiliser "environ" à la place.

Que va-t-il se passer quand les anti-Google vont s'ennuyer de développer des apps non utilisées donc non monétisables alors qu'en face c'est monétisable? La haine de Google et Apple suffira-t-ell sur le long terme?

Alors attention, tu peux très bien développer en HTML et faire quelque chose de portable sur Android, iOS et Firefox OS. Les outils s'améliorent et très facilement j'ai pu faire tourner mes prototypes de jeu sur Android de manière native (je ne parle pas du hack de mozilla qui permet d'installer des applis Firefox OS sur Android).

Donc j'ai encore l'espoir que même si Firefox OS a du mal à percer, des jeux seront cependant proposés car ça coûte rien de les mettre à disposition s'ils ont été développés en HTML/JS.

Sinon, une question : qu'apporte le fait d'être sur le marketplace de Firefox plutôt que d'être simplement disponible en ligne donc "multi-OS"? Aussi pour relativiser les avantages par rapport à un Android ayant un navigateur web, niveau expérience utilisateur.

Alors l'un n'empêche pas l'autre évidemment, à condition de disposer d'un serveur pour l'héberger. Mais le fait d'être disponible sur le Marketplace cela permet théoriquement aux gens de tomber sur l'appli (voir mes critiques, ce n'est pas forcément gagné). Mais surtout, cela permet de jouer au jeu sans connexion internet ! Et comparé à un navigateur, tu n'as pas la barre d'adresse et tu n'as pas à demander à l'utilisateur de passer en full screen.

À voir en fonction des objectifs. En tout cas, pour tester il suffit d'avoir un navigateur, pas besoin d'un téléphone sauf si c'est pour utiliser les accéléromètres ou le multi-touch. Et pas besoin de Firefox OS, les applis peuvent s'installer sur Android si Firefox est installé.

Bon après, je préfère de loin le Python que le JS, mais c'est une question de goût :).

Au début c'était :

tu n'aimes pas le libre et tu es un control freak

et

OK tu détestes le libre.

Maintenant c'est :

Tu déformes, m'enfin c'est normal puisque tu es vexé.

Est-ce que tu es capable d'échanger de manière sereine ? Je suis ouvert à la discussion, je suis ouvert à tout point de vue, et je rappelle qu'initialement je ne souhaite pas simplement tout garder pour moi et que je cherche la licence la plus approprié pour moi.

Le seul message qu'on pourrait qualifier d'original, parce que véhiculé par les problèmes de Stallman avec ses drivers d'imprimante qui l'ont amené à créer le mouvement du Logiciel Libre, c'est "ce morceau de code, si jamais il vous est utile, et que je ne peux/veux plus le maintenir, eh bien vous n'êtes pas pieds et poings liés à moi pour continuer à pouvoir l'utiliser selon vos besoins".

Le message d'origine du logiciel libre, oui c'est celui-ci. Mais je ne parle pas de message d'origine ni de message unique mais simplement de l'une de ses significations actuelles. Et arrêtons un peu de jouer les bisousnours, lorsque quelqu'un passe un logiciel sous licence libre c'est pas uniquement pour la raison que tu donnes. C'est aussi pour l'une des raisons suivante :

• Mon code je ne compte pas le vendre et si en plus des gens veulent y contribuer tout le monde est gagnant.
• Mes clients veulent que le logiciel soit libre car ça leur apporte plein de libertés, si je ferme le code j'arrive pas à leur vendre de service.

Sinon comment tu expliques les décisions récentes de Microsoft ? S'ils veulent que leurs produits restent utilisés, ils n'ont pas le choix.

Si les gens de Phaser ont choisi MIT et non GPL, c'est parce qu'ils se sont dit que pour augmenter le nombre d'utilisateurs, GPL était trop restrictif. Ils ont choisi la licence qui permet d'augmenter la popularité de leur produit. Si les développeurs voulaient empêcher de faire du logiciel proprio avec leur outil libre, ils auraient choisi autre chose. Oh et je n'ai pas vu non plus dans les conditions d'utilisation de vim l'interdiction de faire du logiciel non libre. S'ils voulaient l'interdire ils auraient inventé une autre licence. Je n'ai pas à culpabiliser de faire du logiciel non libre avec un logiciel libre. C'est leur choix de me permettre de le faire.

T'arrivera à convaincre personne de faire du libre avec du « shaming », ce qu'il faut ce sont des arguments qui poussent le développeur à choisir telle ou telle licence pour les intérêts que cela peut apporter. Les entreprises qui font du libre le font à condition que ça ne plombe pas leur business et non par culpabilité de garder un code source pour eux.

Enfin pour moi, un choix de licence doit être raisonné et avoir un sens. Est-ce que tu mets tous tes bouts de code sur internet ? Parfois tu n'en vois pas l'intérêt non ? Je n'ai pas envie de choisir entre garder pour moi et autoriser le monde entier à réutiliser ce que je fais. Je veux pour ce projet en particulier proposer en lecture le code mais ne pas permettre sa diffusion.

Mais c'est le seul qui peut se targuer d'être d'origine. Les autres (dont celui que tu crois être le "message officiel" sont tout autant réducteurs pour la même raison, et en plus ne peuvent même pas prétendre être à l'origine du mouvement.

) Avoue, c'est fait exprès pour me pourrir la journée :P http://xkcd.com/859/

Je ne reviens pas sur ce point, je n'ai pas parlé de message d'origine ni officiel.

Pour la plupart de mes projets perso j'utilise une licence libre car je souhaite favoriser la diffusion et la réutilisation de mon code (en tout cas ne pas la freiner). Ici ce n'est pas le cas.

Merci pour les "tu détestes le libre" parce que pour un projet en particulier je ne vois pas l'intérêt de permettre sa réutilisation. Je ne savais pas que si je choisissais un jour de ne pas reverser à la communauté toutes les lignes de code que je peux être amené à produire c'était détester le libre. Je ne savais pas qu'utiliser un logiciel libre imposait systématiquement de libérer son code, j'ai du mal lire la licence MIT de Phaser. Je passe du temps à produire un code, c'est mon droit en tant que développeur de choisir la licence de mon choix.

Placer un logiciel sous une licence libre c'est envoyer le message : ce morceau de code, réutilisez-le ! Sinon j'en vois pas l'intérêt.

Nous ne parlons pas de la même chose. Je ne dis pas de remplacer "Répondre à l'expéditeur" par une icône. Je dis simplement qu'il existe déjà un gros bouton avec marqué "Répondre" sur la fenêtre du mail et que ça sert à rien de polluer le menu contextuel avec une entrée supplémentaire.