Il y a quand même une sacré dose de mauvaise fois dans tes arguments, mais bon je met ça sur le fait que tu as du avoir une approche très légère du dev natif
Ce qui est bien dans tes commentaires c'est que tu crois vraiment tout savoir et que l'autre en face de toute façon n'est pas compétent pour répondre. Finalement je comprends que sufflope soit parti en couille.
D'ailleurs, si je lis la suite :
beaucoup plus simple que l'usine à gaz que devient le développement web.
Faut croire aussi que t'as une approche très légère du dev web finalement.
Mais je vois surtout que t'as rien compris à des problématiques de design ou d'ergo finalement.
Qt Designer qui te permet de pauser des widgets graphiquement en quelques clics, pas besoin d'un homme/femme designer.
Ha oué, pas besoin d'un designer ? Et be, on va pas aller bien loin.
Ensuite pas besoin de looker ton app le toolkit va utiliser le thème du système choisi par l'utilisateur.
Ce qui n'est pas toujours souhaitable si tu veux une ergo ou un design différent, mais bon vu qu'un designer ne sert à rien…
Je constate qu'en natif on architecture, on imagine ce qu'on veut même des choses qui n'existent pas encore comme l'on fait les dev de kaaza à l'époque ou bitcoin plus récemment.
Ha oué, c'est vrai, architecturer, imaginer ce qui n'existe pas encore, tout ça ça n'existe que dans le monde natif. Pauvre de nous qui s'évertuons à réimplémenter encore et encore les mêmes outils sans jamais les architecturer ni imaginer.
Tu te rends compte à quel point la critique est ridicule ? Et en plus du parle de mauvaise fois ?
Histoire dans remettre un bonne couche sur le design, je te dis qu'il est plus complexe d'intégrer un designe en Qt que d'avoir un designer qui bosse avec de l'html par exemple. Réponse : de toute façon ça sert à rien on a Qt designer. Genre, dis moi ce dont tu as besoin je te dirai comment t'en passer. Supaïr !
donner un peu un nouvel air frais à ce débat
Ben ça ferait pas de mal plutôt que de rejeter tout ce qui n'est pas natif pour des raisons à la con, finalement juste parce que tu as décrété que le web say de la merde. Mais bon…
Le simple fait de balancer une voiture ne va pas fournir immédiatement la bonne donnée. Comment tu gère les parties administratives, les numéros de rue, type de voie, etc ? Comment tu gère un tunnel un poil complexe ? Comment tu gère l'information d'itinéraire (vitesse à utiliser par exemple) ?
Et ça c'est pas juste un boulot d'ingénieur, il y a des métiers pour ça (des personnes qui font du SIG)
Et pourquoi ça m'étonnes ? Parce que ça m'étonnerais très franchement qu'ils aient balancé leurs voitures sur toutes les voies présentées dans Google Maps. Et d'ailleurs dans ce cas, pourquoi n'y a-t-il pas du street view partout ?
l'investissement doit être rapidement rentabilisé
Quel investissement ? Celui de balancer une personne dans chaque rue du monde ? (ok pas le monde entier mais bon)
Bref tout ça pour dire que les procédés utilisés par OSM pourraient surement être optimisés.
Oué enfin pour du natif aussi, plus tu rajoutes de fonctionnalités plus c'est complexe.
Pour illustrer, lorsque je parle d'applications complexes en JS je parle quand même d'applications de 30 ou 40 000 lignes de code (lib non comprises). Et d'applications métiers d'ailleurs.
l'exemple le plus terrible est l'ajout d'une image dans tous les documents "en lignes" (wiki, forums, éditeur texte …), impossible d'utiliser le copier-coller; tu est obligé de faire une première étape d'upload de l'image.
Hum, si je fais un client natif pour un service distant, faudra bien que j'upload aussi.
En html on peut aussi uploader des répertoires et faire du drag and drop maintenant. Donc l'écart se comble de plus en plus.
ça ne te parait pas illusoire voir irréel ?
Non, pas forcément.
Qui a encore des clés usb ? Ca doit faire un an que j'en ai pas touché une. Les gens ont du dropbox maintenant (par exemple et pour le principe) du picasa, du facebook, etc.
Le vraie multiplateforme/multi-navigateur ça coute cher, aussi bien en natif qu'en applis web; Sortis des exemples triviaux je doute qu'une technos puisse prétendre être radicalement plus facile qu'une autre.
De mon expérience, c'est quand même plus lourd de debugger du C++ sur différents linux et windows que du css dans plusieurs navigateurs. Après, en effet, ça dépend beaucoup des applications.
il est bien plus simple de faire une interface "sympa" en natif
Si on ne parle pas de 3D (peu représenté dans les interfaces) les applications natives sont en général pas du tout agréables visuellement. Ca change petit à petit, d'ailleurs ça change en général en intégrant des technologies provenant du web (html, css).
"Facile" en web ? Je dirait moins difficile à la rigueur
Le truc c'est qu'en général tu va trouver un designer qui peut te pondre un html/css.
Ensuite l'intégration n'est pas forcément complexe.
De là à trouver un designer qui va me faire mon interface en QT, c'est quand même plus complexe. Et souvent l'étape de transposition vers le code est plus longue.
Je suis plutôt d'accord avec la conclusion, de manière globale. D'ailleurs cette conclusion est finalement de dire que les deux ont leurs avantages et inconvénients, et que pour un même service les deux clients (web et natif) sont complémentaires. Et non l'un qui soit meilleur que l'autre, l'un est juste meilleur que l'autre dans un scope, et inversement.
Ha ben désolé, un journal posté par trolleurpro à -32 je suis pas allé le voir…
une application est par définition est plus agréable à faire en natif pour le dev et plus agréable à utiliser pour le user. Étant dev web puis dev natif je parle de mon expérience personnelle.
Ha tiens, j'ai un peu l'inverse en tête. J'ai commencé par tu natif, et surtout de la migration d'applis C++ natives en applis web. Et je préfère dans pas mal de cas faire du js, de l'html, du css que faire du C++ (par contre tu marques un très bon point pour QT, c'est quand même un des meilleurs framework existant…), du C# ou du java.
des apps qui font des pets…
Mais qui rapportent vraiment pas mal (pour connaître le dev d'une des plus "connues" sur iphone ;-) )
Sur les apps natives, il ne faut pas oublier deux choses : le js débarque petit à petit, et pas qu'un peu, côté applications natives (scripting) ou serveur V8, nodejs, etc. Le gap entre ça et du dev client web devient de plus en plus limité.
Nombreuses technologies natives proviennent aussi du web, css notamment. C'est loin d'être négligeable.
Actuellement oui, sur iphone et android on a pas mal de natif. Mais je pense que ça va un peu s'estomper, car gérer n applications, toutes avec des langages différents c'est difficilement tenable. Alors que modifier un template ou un css pour passer d'un navigateur desktop vers un mobile c'est pas si compliqué. Et avec du "reponsive design" finalement c'est identique.
Et dans ce cas, côté dev c'est bien mieux.
Oui et on revient à des arguments qui ont déjà été cités que tu vas galérer pour faire une app web complexe alors qu'en natif ca sera plus simple à faire et avec plus de features pour le user et une meilleur intégration.
Et on va te répondre exactement l'inverse car il y a bien des cas où faire une application web est plus simple, plus ergonomique, plus agréable pour l'utilisateur.
Et on en revient aussi à dire qu'il faudrait arréter de penser web monolithique
Sauf que cette critique n'a rien à voir avec web/natif. C'est exactement la même critique pour nombre d'applications avec un client natif pour lesquelles il est impossible d'attaquer proprement le serveur pour en faire une version smartphone ou web.
Le truc c'est que la plupart des arguments avancés pour le natif sont de fausses raisons.
Les arguments intéressant à débattre sont plutôt de l'ordre du multiplateforme vs multinavigateur, de la facilité de faire des interfaces sympa natif vs html, des problématiques déploiement vs application en ligne. Mais aussi la capacité d'intégrer un designer qui va te faire ton interface, facile en web, plus complexe en natif. etc. Mais c'est justement les points sur lesquelles ça ne tourne pas en rond, ça ne débat même pas en fait…
Moi je n'ai rien à prouver on est pas dans un tribunal […] Tu es libre de penser le contraire, je m'en fou total
Ha ben si tu préfère on peut aussi arrêter de discuter. Moi qui pensais que ça pouvais être une discussion intéressante. Enfin si on sort un peu du "moi je pense" sans argumenter.
Mais bon…
Et ca confirme que le natif permet un "peu" 3 tonnes de feature que ne pourra jamais faire le web car il n'est juste pas fait pour.
mouai…
Prenons un autre cas alors.
Si je colle toutes mes données sur des services d'hébergement. Et que j'unifie ces services. Je peux alors avoir des interfaces de consultation, modification, etc de mes données. Elles deviennent synchronisée de fait (ce que ne peux faire dropbox) et je ne fait que les représenter et non accéder directement à la donnée brut (qui n'a que très peu d'intérêt dans la plupart des cas).
Dans ce cas, je n'ai juste absolument pas besoin d'une application native.
Je pourrait en avoir une, mais ce serait ridicule et lourd. Toutes les machines d'aujourd'hui on un navigateur, je n'ai besoin de rien d'autre que me connecter à mon service de données.
Si c'est du natif, faut que je télécharge et installe mon client lourd. Et là c'est le drame. Je ne peux plus le faire chez un pote, au taff, c'est lourd sur mes multiples ordis, etc.
Donc non, au final ça ne confirme que le fait que dans certains usages c'est mieux, et dans d'autres c'est moins bien.
Donc ce n'est pas dans le sens du journal qui tente de faire croire que le web say rien que de la merde et que ça sert à rien.
Justement on reste complètement dans le sujet qui dit que le natif est ce qu'il y a de mieux pour l'utilisateur et même pour le dev.
Heu non, enfin si. Tu le dis mais ne prouve absolument rien. Ni pour l'utilisateur, ni pour le dev.
A service identique, dropbox et spotify ont éclaté leurs concurrents full web et qui étaient avant eux….
Sauf que tu n'as pas montré en quoi c'est leurs clients natifs qui le permettent (enfin pour spotify, il est évident et normal que dropbox a besoin d'un client natif, un dropbox sans client natif ce n'est pas le même service)
Google maps utilise ses voitures pour le mapping ? Certain ?
Si tu as des infos, liens je serais bien intéressé. Pour moi ils achetaient la donnée plus qu'autre chose (bien que maintenant ils permettent également de modifier la donnée)
Donc au final natif ou non ça ne change rien si tu parles de service.
Si ce que tu vends est un service (un service de mail, un service de musique, un service fichiers, etc) que ton client soit natif ou non ne change donc strictement rien, y compris pour la partie monétisation puisque ce que tu vends c'est ton service.
Ce qui était au final l'objet du message (oué j'ai l'impression qu'on s'en est un peu échappé, moi y compris)
CSS et JS sont des langages normés (ever heard of ECMA, les mecs ?)
Mouai…
EcmaScript est normé, oui. Javascript non. Javascript, jscript, actionscript, etc sont des implémentations d'ecmascript qui lui est normé. Pour faire un parallèle, ça voudrait dire qu'il n'y a pas de différence entre GCC et le compilo de MS car C++ est normé.
Donc mon avis sur le web n'a aucun intérêt. OK.
Essai d'argumenter un peu quand même, et un peu plus calmement, car là…
Oui et ?
Ce ne changera donc rien sur ton thunderbird, lui tu l'aura
Encore une fois, j'ai l'impression qu'il y a confusion.
Lorsqu'on coupe ton abonnement à gmail on te supprime deux choses :
le service de mail
l'usage du client mail gmail
Mais c'est deux choses distinctes bien quelles soient packagées ensemble (et encore, tu n'es pas obligé d'activer l'imap)
Oui mais non.
Si on me coupe mon abonnement à GMail (imaginons) alors je n'ai plus accès au logiciel webmail gmail.
Mais ça tu peux plus difficilement le faire avec du natif.
Après, que le logiciel soit diffusé ou non (donc que tu y accède par navigateur ou non) c'est un autre problème que service vs application
Ce qui revient à la même chose que d'aller chercher un crack, ça marche pour tout un tas d'applications natives. (et parfois on peut même se partager un compte, utiliser un proxy ou filtrer les requêtes au serveur d'authentification).
Non, car là tu ne parle pas d'un logiciel mais d'un service.
Ce que tu paye ce n'est pas la licence d'utilisation de dropbox natif, c'est le service dropbox hébergé.
Et que ton client soit natif ou non ne change en effet rien, car ce n'est pas lui que tu paye.
Google, profitant de sa situation de quasi-monopole et aussi d'une explosion du trafic, a logiquement annoncé une augmentation de ses tarifs et a durci ses conditions d'utilisation du service. Désormais, il y a une restriction à 25.000 chargements par jour. Au-delà, il faut payer 4 dollars par lot de 1.000 requêtes, ou encore louer une licence Maps API Premier, dont le prix démarre à 10.000 dollars par an.
Quelques petits points tout de même.
Google Maps API était déjà payante entre autre si :
c'est pour une entreprise
l'accès est payant
l'accès n'est pas possible pour tout le monde (par exemple sur invitation, communauté fermée, etc)
l'accès n'est pas ouvert sur le net (ok ça va avec le précédent, mais par exemple une appli intranet est sous le coup d'une licence)
La texte fait croire que désormais c'est payant alors qu'avant ça ne l'était pas, en réalité c'était déjà payant dans la majorité des cas. Les conditions évolues, ok.
Pour le coup, la licence Premier a une conversion en € qui est correcte (
Il ne faut pas oublier non plus que derrière les licences de Google Maps il y a bien d'autres choses que juste la consultation des cartes.
Entre autre, l'affichage des statics maps (dont les conditions ont étés pour le coup améliorées, notamment sur l'utilisation en dehors d'un navigateur).
Dans les autres points, le géocodage, très très utilisé pour les applications basées sur Google Maps. Une licence premier de base permet de géocoder de l'ordre de 100 000 points par jour (je ne sais plus pour la version gratuite par contre). On est donc loin de la fourniture d'un petit service quand même.
Note : je suis très content de l'essor pris par OSM, mais il faut par contre essayer d'être honnête dans la comparaison, le contraire ne peut que desservir.
D'ailleurs, nombre de services sur le net permettant d'avoir des fonds de plan Google Maps ne respectent absolument pas les conditions, accès direct aux tuiles, usage interdit des données, sans licence, etc.
Perdre du temps à re-développer des widgets graphique qui existe depuis des années lumières dans n'importe quel bibliothèque graphique de n'importe quel OS…
Trois choses :
si tu as des bons widgets / une bonne lib, tu ne les recode pas tout le temps
mimer un style purement natif dans un browser c'est totalement idiot et ne prend pas en compte le fait qu'on peut avoir des ergos différentes et pour certaines plus agréable que ce que nous propose souvent les applis natives malheureusement (non que ce ne soit pas possible)
le style natif est souvent moche en comparaison à la créativité sur le web et c'est dommage de vouloir faire pareil sur le web
Voir que mon client en Javascript sera toujours plus lent que mon appli native.
Vu certains mastodontes c'est pas toujours le cas. Quand on voit que le moindre soft qui ne fait rien prend 50 ou 100Mo et se traine comme une loutre mal léchée on se dit que le js c'est performant
Voir que c'est pas forcément plus compliqué de faire une application native.
Faut voir, ça dépend beaucoup du langage utilisé. Et le javascript est plutôt agréable lorsqu'on le connait (ha mince, comme quasiment tous les langages en fait…) 1 partout
Voir que Google admet que Javascript ça tient pas la route pour les applications complexes. La preuve ils développent Dart
Quelle preuve ? Ce qu'ils prouvent c'est que, par design, javascript ne peut pas être optimisé comme ils le voudraient alors qu'un langage proche mais dont l'objectif est d'être plus rapide est réalisable.
pourquoi d'ailleurs réinventer un nième langage de programmation ?
Comme si c'était pas exactement la même chose du côté natif… D, Scala, vala, Go, rust, etc Tout le monde crée toujours un nouveau langage, c'est comme les standards finalement…
De voir que je n'ai plus de limite imposée par un navigateur pour développer une appli.
De voir que je n'ai plus de limite imposée par les problématiques multiplateformes et de déploiement pour développer une appli
Voir que le développement web mobile (ou pas) est encore plus fragmenté que le marché des devices Android, bonjour les tests et le support client.
Oui, c'est vrai, avec du windows XP, vista, 7, bientôt 8, mac 10.6, 10.7, je ne sais pas combien de linux différents avec des versions totalement diverses (si on prend une debian stable, une redhat supportée, une ou plusieurs ubuntu, arch, …). Bonjour les tests et le support client.
Voir que c'est plus simple de monétiser mon appli native que mon appli web.
Voir que c'est plus simple de pirater mon appli native et donc de ne rien toucher dessus plutôt que mon appli web avec abonnement
Voir que les gens n'hésitent pas à acheter une appli native sur un AppStore.
Voir que les gens n'hésitent pas à payer un abonnement à un site
Bon, sous cette critique je pense simplement que les deux mondes sont intéressant, pas toujours pour les mêmes besoins. On est arrivé à un stade où on veut tout faire en web, puis finalement non (les applis natives sur mobile par exemple). Il faut surtout trouver un bon équilibre, mais aucun des deux mondes n'est meilleur que l'autre. C'est juste différent.
Mais surtout, il ne faut pas chercher de fausses raisons pour développer l'un ou l'autre.
(et en passant j'aimerais bien que ce soit dispo sous les autres OS, tout comme le client twitter pour mac)
D'ailleurs, de plus en plus j'utilise http://www.sourcetreeapp.com/ (oui je sais, pas libre pour un sous, pas multiplateforme pour un sous) pour accéder à mes dépots git et hg lorsque je suis sur un mac. Et c'est plutôt agréable.
Donc oui, github ou autre en natif ça peut être pertinent.
Ben j'ai l'impression que c'est le cas ici alors. Va falloir reprendre des cours. Le problème c'est qu'un troll argumenté, ben c'est pas un troll. Forcément si tu parais trop sérieux tu aura des réponses sérieuses. En même temps, samwang il parait, malheureusement, sérieux, donc parfois ça marche.
La prochaine fois, rajoute une couche de tom pouce et ça partira en troll sans problème ;-)
Oué c'est vrai ça, il faudrait l'appeler yaoubdfe : Yet An Other Ubuntu Based Distribution For Education.
Au moins ça ne passerait pas pour un nom provenant de marketeux cocaïnomanes, juste pour un énième nom provenant de nerds sous amphétamine.
Sauf qu'étrangement beaucoup de freebox rament/déconnent depuis ce problème (pourquoi, aucune idée je vois pas trop le lien, même si de nombreuses personnes s'en plaignent)
Et oui, le fait de merder tous les enregistrements n'est pas négligeable non plus (et c'est le réelle problème, l'heure comme tu dis, on s'en fout, l'enregistrement c'est pas tout à fait pareil)
Mais surtout, comme d'habitude, au delà du problème d'heure c'est surtout que, comme d'habitude, free réalise ses produits avec un niveau d'exigence même pas digne d'un amateur, pas foutu de communiquer et qui, au final, prend tout comme les autres ses clients pour des pigeons.
M'enfin je suis d'accord, pas de quoi en faire un fromage c'est pas nouveau.
Bon ceci dit, si le patch a été envoyé en novembre dernier, ce couac est plus excusable. On peut imaginer que quand on a quelques millions de box dans la nature, le cycle de patch/revalidation/déploiement soit assez long…
En quoi c'est excusable ? On est quand même à 4 - 5 mois là…
Et faut pas avoir une freebox pour parler de revalidation/déploiement…
En général ils sont bien capables de balancer des mises à jour n'importe quand, surtout plusieurs fois pas mois dans certains cas, donc il n'y a pas vraiment d'excuse.
Et le silence de free est comme d'hab, ils savent qu'ils ont merdé (que ce soit de leur faute directe ou de µclibc finalement c'est leur problème, pas celui de l'utilisateur) donc ils se taisent. On les entends beaucoup plus quand il s'agit de descendre Orange/Bouygues/sfr…
Et puis, j'aime tout ce qui consiste à réinventer les outils « historiques ».
Tu sais, ça se soigne.
Mais sinon, tu fais quoi mercredi soir ? Si tu es dispo, j'aimerais bien t'inviter à un dîner, où tu pourra partager ta passion pour ce sujet.
;-)
[^] # Re: hum...
Posté par CrEv (site web personnel) . En réponse au journal Bref, j'arrête de développer pour le web. Évalué à 2.
Ce qui est bien dans tes commentaires c'est que tu crois vraiment tout savoir et que l'autre en face de toute façon n'est pas compétent pour répondre. Finalement je comprends que sufflope soit parti en couille.
D'ailleurs, si je lis la suite :
Faut croire aussi que t'as une approche très légère du dev web finalement.
Mais je vois surtout que t'as rien compris à des problématiques de design ou d'ergo finalement.
Ha oué, pas besoin d'un designer ? Et be, on va pas aller bien loin.
Ce qui n'est pas toujours souhaitable si tu veux une ergo ou un design différent, mais bon vu qu'un designer ne sert à rien…
Ha oué, c'est vrai, architecturer, imaginer ce qui n'existe pas encore, tout ça ça n'existe que dans le monde natif. Pauvre de nous qui s'évertuons à réimplémenter encore et encore les mêmes outils sans jamais les architecturer ni imaginer.
Tu te rends compte à quel point la critique est ridicule ? Et en plus du parle de mauvaise fois ?
Histoire dans remettre un bonne couche sur le design, je te dis qu'il est plus complexe d'intégrer un designe en Qt que d'avoir un designer qui bosse avec de l'html par exemple. Réponse : de toute façon ça sert à rien on a Qt designer. Genre, dis moi ce dont tu as besoin je te dirai comment t'en passer. Supaïr !
Ben ça ferait pas de mal plutôt que de rejeter tout ce qui n'est pas natif pour des raisons à la con, finalement juste parce que tu as décrété que le web say de la merde. Mais bon…
[^] # Re: Changement de license
Posté par CrEv (site web personnel) . En réponse à la dépêche OPA sur OpenStreetMap. Évalué à 4.
Le simple fait de balancer une voiture ne va pas fournir immédiatement la bonne donnée. Comment tu gère les parties administratives, les numéros de rue, type de voie, etc ? Comment tu gère un tunnel un poil complexe ? Comment tu gère l'information d'itinéraire (vitesse à utiliser par exemple) ?
Et ça c'est pas juste un boulot d'ingénieur, il y a des métiers pour ça (des personnes qui font du SIG)
Et pourquoi ça m'étonnes ? Parce que ça m'étonnerais très franchement qu'ils aient balancé leurs voitures sur toutes les voies présentées dans Google Maps. Et d'ailleurs dans ce cas, pourquoi n'y a-t-il pas du street view partout ?
Quel investissement ? Celui de balancer une personne dans chaque rue du monde ? (ok pas le monde entier mais bon)
Ca c'est bien probable.
[^] # Re: Changement de license
Posté par CrEv (site web personnel) . En réponse à la dépêche OPA sur OpenStreetMap. Évalué à 3.
heu… http://maps.google.fr/ ?
http://maps.google.fr/?ll=46.509735,2.845459&spn=1.969618,4.196777&t=m&z=8
En fait, ça dépend, aussi, du zoom
Mais franchement, ça m'étonnerais beaucoup qu'ils aient tout recartographié, à la rigueur qu'ils aient pu racheter des droits sur de la donnée, mais autrement ce serait plutôt étrange.
[^] # Re: hum...
Posté par CrEv (site web personnel) . En réponse au journal Bref, j'arrête de développer pour le web. Évalué à 5.
Oué enfin pour du natif aussi, plus tu rajoutes de fonctionnalités plus c'est complexe.
Pour illustrer, lorsque je parle d'applications complexes en JS je parle quand même d'applications de 30 ou 40 000 lignes de code (lib non comprises). Et d'applications métiers d'ailleurs.
Hum, si je fais un client natif pour un service distant, faudra bien que j'upload aussi.
En html on peut aussi uploader des répertoires et faire du drag and drop maintenant. Donc l'écart se comble de plus en plus.
Non, pas forcément.
Qui a encore des clés usb ? Ca doit faire un an que j'en ai pas touché une. Les gens ont du dropbox maintenant (par exemple et pour le principe) du picasa, du facebook, etc.
De mon expérience, c'est quand même plus lourd de debugger du C++ sur différents linux et windows que du css dans plusieurs navigateurs. Après, en effet, ça dépend beaucoup des applications.
Si on ne parle pas de 3D (peu représenté dans les interfaces) les applications natives sont en général pas du tout agréables visuellement. Ca change petit à petit, d'ailleurs ça change en général en intégrant des technologies provenant du web (html, css).
Le truc c'est qu'en général tu va trouver un designer qui peut te pondre un html/css.
Ensuite l'intégration n'est pas forcément complexe.
De là à trouver un designer qui va me faire mon interface en QT, c'est quand même plus complexe. Et souvent l'étape de transposition vers le code est plus longue.
Je suis plutôt d'accord avec la conclusion, de manière globale. D'ailleurs cette conclusion est finalement de dire que les deux ont leurs avantages et inconvénients, et que pour un même service les deux clients (web et natif) sont complémentaires. Et non l'un qui soit meilleur que l'autre, l'un est juste meilleur que l'autre dans un scope, et inversement.
[^] # Re: Changement de license
Posté par CrEv (site web personnel) . En réponse à la dépêche OPA sur OpenStreetMap. Évalué à 2.
MapMaker est dispo pour la France par exemple… Par contre je suis sur © Google Télé Atlas
Donc non, on peut modifier même là où il y a un copyright autre que Google.
https://plus.google.com/106901486880272202822/posts/QD7N3nUDmoa
[^] # Re: hum...
Posté par CrEv (site web personnel) . En réponse au journal Bref, j'arrête de développer pour le web. Évalué à 3.
Ha ben désolé, un journal posté par trolleurpro à -32 je suis pas allé le voir…
Ha tiens, j'ai un peu l'inverse en tête. J'ai commencé par tu natif, et surtout de la migration d'applis C++ natives en applis web. Et je préfère dans pas mal de cas faire du js, de l'html, du css que faire du C++ (par contre tu marques un très bon point pour QT, c'est quand même un des meilleurs framework existant…), du C# ou du java.
Mais qui rapportent vraiment pas mal (pour connaître le dev d'une des plus "connues" sur iphone ;-) )
Sur les apps natives, il ne faut pas oublier deux choses : le js débarque petit à petit, et pas qu'un peu, côté applications natives (scripting) ou serveur V8, nodejs, etc. Le gap entre ça et du dev client web devient de plus en plus limité.
Nombreuses technologies natives proviennent aussi du web, css notamment. C'est loin d'être négligeable.
Actuellement oui, sur iphone et android on a pas mal de natif. Mais je pense que ça va un peu s'estomper, car gérer n applications, toutes avec des langages différents c'est difficilement tenable. Alors que modifier un template ou un css pour passer d'un navigateur desktop vers un mobile c'est pas si compliqué. Et avec du "reponsive design" finalement c'est identique.
Et dans ce cas, côté dev c'est bien mieux.
[^] # Re: hum...
Posté par CrEv (site web personnel) . En réponse au journal Bref, j'arrête de développer pour le web. Évalué à 4.
Et on va te répondre exactement l'inverse car il y a bien des cas où faire une application web est plus simple, plus ergonomique, plus agréable pour l'utilisateur.
Sauf que cette critique n'a rien à voir avec web/natif. C'est exactement la même critique pour nombre d'applications avec un client natif pour lesquelles il est impossible d'attaquer proprement le serveur pour en faire une version smartphone ou web.
Le truc c'est que la plupart des arguments avancés pour le natif sont de fausses raisons.
Les arguments intéressant à débattre sont plutôt de l'ordre du multiplateforme vs multinavigateur, de la facilité de faire des interfaces sympa natif vs html, des problématiques déploiement vs application en ligne. Mais aussi la capacité d'intégrer un designer qui va te faire ton interface, facile en web, plus complexe en natif. etc. Mais c'est justement les points sur lesquelles ça ne tourne pas en rond, ça ne débat même pas en fait…
[^] # Re: hum...
Posté par CrEv (site web personnel) . En réponse au journal Bref, j'arrête de développer pour le web. Évalué à 3.
Ha ben si tu préfère on peut aussi arrêter de discuter. Moi qui pensais que ça pouvais être une discussion intéressante. Enfin si on sort un peu du "moi je pense" sans argumenter.
Mais bon…
mouai…
Prenons un autre cas alors.
Si je colle toutes mes données sur des services d'hébergement. Et que j'unifie ces services. Je peux alors avoir des interfaces de consultation, modification, etc de mes données. Elles deviennent synchronisée de fait (ce que ne peux faire dropbox) et je ne fait que les représenter et non accéder directement à la donnée brut (qui n'a que très peu d'intérêt dans la plupart des cas).
Dans ce cas, je n'ai juste absolument pas besoin d'une application native.
Je pourrait en avoir une, mais ce serait ridicule et lourd. Toutes les machines d'aujourd'hui on un navigateur, je n'ai besoin de rien d'autre que me connecter à mon service de données.
Si c'est du natif, faut que je télécharge et installe mon client lourd. Et là c'est le drame. Je ne peux plus le faire chez un pote, au taff, c'est lourd sur mes multiples ordis, etc.
Donc non, au final ça ne confirme que le fait que dans certains usages c'est mieux, et dans d'autres c'est moins bien.
Donc ce n'est pas dans le sens du journal qui tente de faire croire que le web say rien que de la merde et que ça sert à rien.
[^] # Re: hum...
Posté par CrEv (site web personnel) . En réponse au journal Bref, j'arrête de développer pour le web. Évalué à 2.
Heu non, enfin si. Tu le dis mais ne prouve absolument rien. Ni pour l'utilisateur, ni pour le dev.
Sauf que tu n'as pas montré en quoi c'est leurs clients natifs qui le permettent (enfin pour spotify, il est évident et normal que dropbox a besoin d'un client natif, un dropbox sans client natif ce n'est pas le même service)
[^] # Re: Changement de license
Posté par CrEv (site web personnel) . En réponse à la dépêche OPA sur OpenStreetMap. Évalué à 2.
Google maps utilise ses voitures pour le mapping ? Certain ?
Si tu as des infos, liens je serais bien intéressé. Pour moi ils achetaient la donnée plus qu'autre chose (bien que maintenant ils permettent également de modifier la donnée)
[^] # Re: hum...
Posté par CrEv (site web personnel) . En réponse au journal Bref, j'arrête de développer pour le web. Évalué à 2.
Donc au final natif ou non ça ne change rien si tu parles de service.
Si ce que tu vends est un service (un service de mail, un service de musique, un service fichiers, etc) que ton client soit natif ou non ne change donc strictement rien, y compris pour la partie monétisation puisque ce que tu vends c'est ton service.
Ce qui était au final l'objet du message (oué j'ai l'impression qu'on s'en est un peu échappé, moi y compris)
[^] # Re: Monsieur, Bravo, je fais donc appel à vos conseil
Posté par CrEv (site web personnel) . En réponse au journal Bref, j'arrête de développer pour le web. Évalué à 3.
Dites, ça vous irait de vous calmer un peu là ?
Mouai…
EcmaScript est normé, oui. Javascript non. Javascript, jscript, actionscript, etc sont des implémentations d'ecmascript qui lui est normé. Pour faire un parallèle, ça voudrait dire qu'il n'y a pas de différence entre GCC et le compilo de MS car C++ est normé.
Essai d'argumenter un peu quand même, et un peu plus calmement, car là…
[^] # Re: hum...
Posté par CrEv (site web personnel) . En réponse au journal Bref, j'arrête de développer pour le web. Évalué à 2.
Oui et ?
Ce ne changera donc rien sur ton thunderbird, lui tu l'aura
Encore une fois, j'ai l'impression qu'il y a confusion.
Lorsqu'on coupe ton abonnement à gmail on te supprime deux choses :
Mais c'est deux choses distinctes bien quelles soient packagées ensemble (et encore, tu n'es pas obligé d'activer l'imap)
[^] # Re: hum...
Posté par CrEv (site web personnel) . En réponse au journal Bref, j'arrête de développer pour le web. Évalué à 1.
Oui mais non.
Si on me coupe mon abonnement à GMail (imaginons) alors je n'ai plus accès au logiciel webmail gmail.
Mais ça tu peux plus difficilement le faire avec du natif.
Après, que le logiciel soit diffusé ou non (donc que tu y accède par navigateur ou non) c'est un autre problème que service vs application
[^] # Re: hum...
Posté par CrEv (site web personnel) . En réponse au journal Bref, j'arrête de développer pour le web. Évalué à 0.
Ce qui revient à la même chose que d'aller chercher un crack, ça marche pour tout un tas d'applications natives. (et parfois on peut même se partager un compte, utiliser un proxy ou filtrer les requêtes au serveur d'authentification).
[^] # Re: hum...
Posté par CrEv (site web personnel) . En réponse au journal Bref, j'arrête de développer pour le web. Évalué à 3.
Non, car là tu ne parle pas d'un logiciel mais d'un service.
Ce que tu paye ce n'est pas la licence d'utilisation de dropbox natif, c'est le service dropbox hébergé.
Et que ton client soit natif ou non ne change en effet rien, car ce n'est pas lui que tu paye.
# .
Posté par CrEv (site web personnel) . En réponse à la dépêche OPA sur OpenStreetMap. Évalué à 8.
Quelques petits points tout de même.
Google Maps API était déjà payante entre autre si :
La texte fait croire que désormais c'est payant alors qu'avant ça ne l'était pas, en réalité c'était déjà payant dans la majorité des cas. Les conditions évolues, ok.
Pour le coup, la licence Premier a une conversion en € qui est correcte (
Il ne faut pas oublier non plus que derrière les licences de Google Maps il y a bien d'autres choses que juste la consultation des cartes.
Entre autre, l'affichage des statics maps (dont les conditions ont étés pour le coup améliorées, notamment sur l'utilisation en dehors d'un navigateur).
Dans les autres points, le géocodage, très très utilisé pour les applications basées sur Google Maps. Une licence premier de base permet de géocoder de l'ordre de 100 000 points par jour (je ne sais plus pour la version gratuite par contre). On est donc loin de la fourniture d'un petit service quand même.
Note : je suis très content de l'essor pris par OSM, mais il faut par contre essayer d'être honnête dans la comparaison, le contraire ne peut que desservir.
D'ailleurs, nombre de services sur le net permettant d'avoir des fonds de plan Google Maps ne respectent absolument pas les conditions, accès direct aux tuiles, usage interdit des données, sans licence, etc.
# hum...
Posté par CrEv (site web personnel) . En réponse au journal Bref, j'arrête de développer pour le web. Évalué à 10.
Trois choses :
Vu certains mastodontes c'est pas toujours le cas. Quand on voit que le moindre soft qui ne fait rien prend 50 ou 100Mo et se traine comme une loutre mal léchée on se dit que le js c'est performant
Faut voir, ça dépend beaucoup du langage utilisé. Et le javascript est plutôt agréable lorsqu'on le connait (ha mince, comme quasiment tous les langages en fait…) 1 partout
Quelle preuve ? Ce qu'ils prouvent c'est que, par design, javascript ne peut pas être optimisé comme ils le voudraient alors qu'un langage proche mais dont l'objectif est d'être plus rapide est réalisable.
Comme si c'était pas exactement la même chose du côté natif… D, Scala, vala, Go, rust, etc Tout le monde crée toujours un nouveau langage, c'est comme les standards finalement…
De voir que je n'ai plus de limite imposée par les problématiques multiplateformes et de déploiement pour développer une appli
Oui, c'est vrai, avec du windows XP, vista, 7, bientôt 8, mac 10.6, 10.7, je ne sais pas combien de linux différents avec des versions totalement diverses (si on prend une debian stable, une redhat supportée, une ou plusieurs ubuntu, arch, …). Bonjour les tests et le support client.
Voir que c'est plus simple de pirater mon appli native et donc de ne rien toucher dessus plutôt que mon appli web avec abonnement
Voir que les gens n'hésitent pas à payer un abonnement à un site
Bon, sous cette critique je pense simplement que les deux mondes sont intéressant, pas toujours pour les mêmes besoins. On est arrivé à un stade où on veut tout faire en web, puis finalement non (les applis natives sur mobile par exemple). Il faut surtout trouver un bon équilibre, mais aucun des deux mondes n'est meilleur que l'autre. C'est juste différent.
Mais surtout, il ne faut pas chercher de fausses raisons pour développer l'un ou l'autre.
[^] # Re: Et pour les outils collaboratifs ?
Posté par CrEv (site web personnel) . En réponse au journal Bref, j'arrête de développer pour le web. Évalué à 7.
Ha ok, genre http://mac.github.com/
Ha mince, c'est natif.
(et en passant j'aimerais bien que ce soit dispo sous les autres OS, tout comme le client twitter pour mac)
D'ailleurs, de plus en plus j'utilise http://www.sourcetreeapp.com/ (oui je sais, pas libre pour un sous, pas multiplateforme pour un sous) pour accéder à mes dépots git et hg lorsque je suis sur un mac. Et c'est plutôt agréable.
Donc oui, github ou autre en natif ça peut être pertinent.
[^] # Re: Une main de fer dans un gant d'acier
Posté par CrEv (site web personnel) . En réponse au journal La glibc s'ouvre à la communauté. Évalué à 3.
Ben j'ai l'impression que c'est le cas ici alors. Va falloir reprendre des cours. Le problème c'est qu'un troll argumenté, ben c'est pas un troll. Forcément si tu parais trop sérieux tu aura des réponses sérieuses. En même temps, samwang il parait, malheureusement, sérieux, donc parfois ça marche.
La prochaine fois, rajoute une couche de tom pouce et ça partira en troll sans problème ;-)
[^] # Re: Une main de fer dans un gant d'acier
Posté par CrEv (site web personnel) . En réponse au journal La glibc s'ouvre à la communauté. Évalué à 1.
Mouai…
Ha oui, donc désormais le choix de licence a un impact sur le niveau de programmation. Supaÿr ta définition. T'es sur qu'il y a un pas un problème ?
Ok, et donc ça change quoi qu'il soit ou non en phase avec certaines réalités ?
Qu'est ce que cette participation change à son niveau ? Car là on est pas loin du procès d'intention finalement.
Bon, et côté proprio il n'y a pas de bons programmeurs ? Ou plutôt tu n'en sais rien car les codes sont… proprios ?
[^] # Re: KISS
Posté par CrEv (site web personnel) . En réponse à la dépêche frenchKISS est arrivé avec le printemps. Évalué à 9.
Oué c'est vrai ça, il faudrait l'appeler yaoubdfe : Yet An Other Ubuntu Based Distribution For Education.
Au moins ça ne passerait pas pour un nom provenant de marketeux cocaïnomanes, juste pour un énième nom provenant de nerds sous amphétamine.
[^] # Re: Non mais osef quoi !
Posté par CrEv (site web personnel) . En réponse au journal Un bug de uClibc bloque le passage à l’heure d’été des box ADSL de Free et Orange. Évalué à 1.
Sauf qu'étrangement beaucoup de freebox rament/déconnent depuis ce problème (pourquoi, aucune idée je vois pas trop le lien, même si de nombreuses personnes s'en plaignent)
Et oui, le fait de merder tous les enregistrements n'est pas négligeable non plus (et c'est le réelle problème, l'heure comme tu dis, on s'en fout, l'enregistrement c'est pas tout à fait pareil)
Mais surtout, comme d'habitude, au delà du problème d'heure c'est surtout que, comme d'habitude, free réalise ses produits avec un niveau d'exigence même pas digne d'un amateur, pas foutu de communiquer et qui, au final, prend tout comme les autres ses clients pour des pigeons.
M'enfin je suis d'accord, pas de quoi en faire un fromage c'est pas nouveau.
[^] # Re: Étrange
Posté par CrEv (site web personnel) . En réponse au journal Un bug de uClibc bloque le passage à l’heure d’été des box ADSL de Free et Orange. Évalué à 9.
En quoi c'est excusable ? On est quand même à 4 - 5 mois là…
Et faut pas avoir une freebox pour parler de revalidation/déploiement…
En général ils sont bien capables de balancer des mises à jour n'importe quand, surtout plusieurs fois pas mois dans certains cas, donc il n'y a pas vraiment d'excuse.
Et le silence de free est comme d'hab, ils savent qu'ils ont merdé (que ce soit de leur faute directe ou de µclibc finalement c'est leur problème, pas celui de l'utilisateur) donc ils se taisent. On les entends beaucoup plus quand il s'agit de descendre Orange/Bouygues/sfr…
# .
Posté par CrEv (site web personnel) . En réponse au journal Dotsies : remplacer l'alphabet !. Évalué à 10.
Tu sais, ça se soigne.
Mais sinon, tu fais quoi mercredi soir ? Si tu es dispo, j'aimerais bien t'inviter à un dîner, où tu pourra partager ta passion pour ce sujet.
;-)
(bon, plus sérieusement, les dyslexiques ils en pensent quoi ? Récemment j'ai vu http://www.youtube.com/watch?v=VLtYFcHx7ec qui me semble particulièrement intéressant)