Discussion :

[Bousk]

Unity n'existe pas depuis des années

Bon ça commence bien, mais vu le personnage faut s'y attendre!
La 1° release de Unity date de 2005. Et je parle de la version 1.0, pas de la première version béta disponible.
Les mecs de Unity ils sont une centaine de programmeurs sur le moteur uniquement.

, et puis, de toute évidence, comme toute les nouvelles technologie, ça ne laisse aucune liberté sur les librairies que l'ont souhaite utiliser, ni sur le code source, donc si il y a un bug ou qu'on a besoin de rajouter un fonctionnalité par la suite, on est contraint de faire avec.

Tu peux acheter une version de Unity avec le code source.
Mais dès que tu vas le modifier, tu auras du mal à intégrer leurs mises à jour par la suite, puisqu'il te faudra merger leurs modifs aux tiennes, ou l'inverse. Du coup c'est plus une fausse bonne idée amha.

Donc oui ce genre de technologie c'est un gain de temps dans un premier temps mais c'est trompeur car ça peut t'en faire perde énormément par la suite..., rien ne me dis que unity gère des techniques tel que le weighted blended OIT ou encore des volumes englobant sur des games objects par exemple.

C'est tes nouveaux mot-clés sur lesquels tu fais des recherches ?
Unity gère à peu près toutes les techniques classiques et plus ou moins avancées.
Et Unity gère aussi très bien un système d'add-on, ce qui permet de trouver à peu près tout le nécessaire pour pousser la bête https://github.com/nobnak/BlendedOIT

Un autre exemple est lorsque j'étais dans une boîte et que l'on souhaitait modifier un programme fait avec visual basic 2005, impossible de retrouver cette version, maintenant on est déjà à visual studio 2015

oui la plupart des boites ne comprennent pas que l'informatique évolue
Mais pour le cas de VB2005, j'ose espérer que vous saviez utiliser Google tout de même.. http://lmgtfy.com/?q=visual+basic+2005 parce que le 1° résultat est le lien direct pour le télécharger depuis le site de Microsoft http://download.microsoft.com/downlo...NU/vbsetup.exe
Le plus dur étant souvent la compatibilité avec le matériel/système récent

-Lourd (un jour pour l'installer, très lent à s'ouvrir)

Euh.. t'es sérieux ?! Tu l'as installé sur calculatrice ?

-La galère pour lier les dépendances.
-Du code qui compile parfaitement avec cmake et gcc sous linux mais le compilateur de windows ne le prend pas. (Je parle de code c++ bien sûr par les langages récent qui demandent de maîtriser un tas de concept et me font perde un temps fou à lire des tas de bouquin.)

Change de métier ?

Non sincèrement avec les nouvelles technologie ont peut aussi bien perdre sont temps même plus de temps que de recoder une bibliothèque toute simple tel que la mienne.

Ca faisait longtemps que tu avais pas sorti un truc pareil ça m'avait manqué
Mais les technos en question ont
- une doc souvent correcte
- des communautés d'entraide
- des moyens
- des équipes pour les faire évoluer
- simples à utiliser
- simples à personnaliser (add-on, code source disponible)

[DonQuiche]

Si tu veux vraiment comprendre comment fonctionne un moteur de voiture, c'est pas en roulant et en étant uniquement conducteur que tu y arriveras vraiment.

Si tu veux apprendre, fais un moteur.
Si tu veux faire un moteur, fais un moteur.
Si tu veux faire un jeu, utilise un moteur tout fait.


Mais faire ton propre moteur ne sera jamais un gain de temps - pas en 2015.

[SurferIX]

C'est à mon sens une des raisons pour lesquelles nous avons perdus ce "pouvoir" : le risque d'abus.

La balance était peut être trop déséquilibrée dans un sens.
Maintenant, la balance est trop déséquilibrée dans l'autre...
Enfin, de mon expérience, c'est ce qu'on essaie de nous faire croire...

Mais sans développeur, pas de programme, point à la ligne. Sans commercial, pas de vente non plus. Il faut trouver un juste équilibre, et à mon sens, la France est allée beaucoup trop dans l'autre sens, avec les commerciaux qui se montent le choux entre eux et méprisent de plus en plus les développeurs. Quand j'étais expert Web à B&D, il m'est arrivé de monter dans un ascenseur avec 3 de mes collègues développeurs. Et un commercial. J'ai le nez fin, et tout sentait bon. Pourquoi je dis cela ? Parce que le commercial nous regardait avec un mépris, j'ai réellement cru qu'on sentait la merde (véridique). Evidemment, ce type a une pièce pour lui tout seul alors que nous, on travaillait en "open-source", vous comprenez, on peut parquer les développeurs comme du bétail, par contre, les commerciaux, oulah faut pas toucher, attention, c'est la crème de la crème, il leur faut leur pièce bien à eux seuls pour passer leurs coups de fils, et il leur faut leur propre salle de réunion, qui n'était pas la même que pour la basse populasse sur laquelle on chie allègrement, hein... oui je sais je suis vulgaire, mais le défaut que je déteste le plus chez l'être humain, par dessus tout, c'est la prétention, avec ces gens qui se croient "naturellement supérieurs" aux autres. Bref je m'éloigne du sujet. Mais ce genre de type qui ne sait que passer des coups de fils et discuter toute la journée, avec des réunions dans lesquelles il ne sait même pas de quoi il parle, ne mérite qu'une seule chose : devenir serveur ou autre métier qui lui apprendrait à devenir humble, servir les autres et être poli, afin qu'il puisse manger.

Si tu veux apprendre, fais un moteur.
Si tu veux faire un moteur, fais un moteur.
Si tu veux faire un jeu, utilise un moteur tout fait.
Mais faire ton propre moteur ne sera jamais un gain de temps - pas en 2015.

Qui a parlé de gain de temps ? Le sujet est "l'ère des logiciels ratés".
Et la discussion semble tourner sur le fait que s'ils sont ratés, c'est entre autre, par manque de compétence car, justement, beaucoup de personnes ne veulent plus mettre les mains dans le cambouis.
Cela dit je suis un fan inconditionnel de Unity, qui me permet de contourner le Web pour lequel, même si je gagne ma vie avec actuellement, je n'en peux plus

J'ai même fait un gros serveur multi joueurs en tour par tour, pour lequel j'ai dérivé les classes pour faire une bataille navale, et là, j'ai essayé de tout faire en jQuery : ça fonctionnait mais c'était très laid.
Alors j'ai essayé 4 frameworks de jeu en JavaScript je me suis cassé le nez sur le fait qu'ils étaient tous des usines à gaz : ils étaient partis d'une bonne idée, tout le monde avait rajouté son grain de sel et au final : que des usines à gaz = se baser sur le travail des autres = logiciels ratés.
J'ai alors essayé d'écrire un truc sur Canvas, et là d'un jour à l'autre, Chrome, avec une mise à jour, ne fonctionnait plus pareillement, c'était un truc de dingue = se baser sur le travail des autres = logiciels ratés.
Donc après un mois complet de développement toutes les nuits, en plus de mon boulot, j'ai laissé tomber et je suis passé à Unity. Là j'ai découvert ce qui pour moi est l'avenir : tout a fonctionné du premier coup. Android. Windows. Linux
Sauf que... il faut en permanence le suivre, faire les mises à jour, changer son code qui évolue, discuter énormément sur les forums, sans parler du Unity 5 qui a encore quelques soucis de résolution des calculs des tensions et frictions : voir ici. Bref, ici aussi, se reposer sur Unity n'est pas la solution ultime, et on perd pas mal de temps sur des problèmes... qui sont différents de ceux qu'on aurait si on avait développé le moteur à la main, mais qu'on soit bien clairs : il y a tout autant de problèmes, il ne sont juste pas aux mêmes endroits.

C'est comme moi avec Django/Python : depuis que j'ai laissé tomber tous les frameworks Php (et Dieu sait si j'en ai fait des paquets), y compris le mien , je ne perds plus de temps que sur une chose : le Web. Et là, même chose, l'ère des logiciels ratés : le Web est toujours du "work-in-progress". C'est impossible de développer une application propre, qui fonctionnera parfaitement sur les dix prochaines années. Impossible. Tiens, regarde rien que jQuery qui essaient de sortir la v3 en alpha et qu'il expliquent qu'ils ont essayé de simplifier le code de hide() et show() mais qu'il y a tellement de mauvais boulot sur les navigateurs (= ère des logiciels ratés) qu'ils doivent laisser du code pour hacker le tout....

Bref j'arrête là, autant faire du constructif aujourd'hui

A+

[Artemus24]

Salut SuferIX.

Plus je te lis, plus je t'aime !!!
On a dû fréquenter les mêmes entreprises, car ton constat est le même que le mien.

On donne trop d'importance aux commerciaux dans les SSII.
Mais quand un développeur fait une connerie, il est sanctionné. Tandis qu'un commercial sera excusé de sa bévue.
C'est le triste sort des improductifs vis-à-vis de ceux qui rapporte.

Que serait les commerciaux sans les développeurs ? Juste des chômeurs en perspective.

@+

[Mat.M]

it une connerie, il est sanctionné. Tandis qu'un commercial sera excusé de sa bévue.
C'est le triste sort des improductifs vis-à-vis de ceux qui rapporte.
Que serait les commerciaux sans les développeurs ? Juste des chômeurs en perspective.

exact mais de toute façon un commercial ne comettra jamais de bévue sauf s'il fait une rature sur le contrat avec un gros client.
Ensuite les commerciaux se fichent totalement des développeurs, la seule chose qui compte pour eux c'est de démarcher les clients, faire des propositions commerciales et signer les contrats.
Donc ce qui suit après, peu importe pour eux...

C'est un paradoxe du monde informatique. La technique a toujours été mal considéré par nos patrons et je n'ai jamais compris pourquoi.

La technique a toujours été mal considérée par nos patrons , je vais expliquer pourquoi..
le problème numéro un des entreprises françaises c'est que la finalité n'a jamais été le business voilà pourquoi ça tient en quelques mots.
Si tu crées une entreprise et que ta finalité c'est de faire du business , gagner de l'argent,avoir une mentalité orientée produit eh bien pour satisfaire tes clients tu vas te décarcasser pour innover et vendre des produits ( logiciels entre autres ) que les clients veulent acheter.
C'est pour cela que les entreprises américaines et anglo-saxonnes me semblent largement meilleures que les entreprises françaises, parce que le mot d'ordre c'est l'innovation et faire avancer le schmilblick...
si tu innoves et que les utilisateurs sont contents de ton produit eh bien ton entreprise gagne de l'argent après ça se ressent sur la paie des programmeurs...c'est un cercle vertueux.

Moi ça ne me dérange pas de dépenser 1000euros pour un excellent logiciel, l'éditeur il gagne de l'argent moi je suis content parce que le logiciel est un excellent produit et qu'il est productif.
Et les programmeurs du logiciel sont bien payés..

si la finalité d'une entreprise n'est pas d'innover , de faire avancer les choses alors avec la concurrence l'entreprise va patiner voire couler..

pour ce qui est des entreprises en France au vu de mon expérience pro ( j'ai fait une dizaine d'entreprise éditeurs comme SSII j'ai même travaillé aux USA et au Canada ) je suis extrêmement sceptique,les maux des entreprises françaises c'est
pas de finalité business et économique du moins de manière claire à mes yeux.
manque de méthodes, manque de qualité finale sur les projets
bureaucratie et empilement de la hiérarchie.
vouloir flatter les egos des directions des services informatiques, faire de la communication inutile..

Donc après un mois complet de développement toutes les nuits, en plus de mon boulot, j'ai laissé tomber et je suis passé à Unity. Là j'ai découvert ce qui pour moi est l'avenir : tout a fonctionné du premier coup. Android. Windows. Linux
Sauf que... il faut en permanence le suivre, faire les mises à jour, changer son code qui évolue, discuter énormément sur les forums, sans parler du Unity 5 qui a encore quelques soucis de résolution des calculs des tensions et frictions : voir ici. Bref, ici aussi, se reposer sur Unity n'est pas la solution ultime, et on perd pas mal de temps sur des problèmes... qui sont différents de ceux qu'on aurait si on avait développé le moteur à la main, mais qu'on soit bien clairs : il y a tout autant de problèmes, il ne sont juste pas aux mêmes endroits.

c'est pour ça que théoriquement il faudrait bannir les middlewares et frameworks intermédiaires...et être plus dans l'abstraction logicielle.
Un projet logiciel quii est vraiment bien fait c'est celuii qui comporte le plus de couches d'abstractions totales indépendantes des langages et technos.
Malheureusement à l'heure actuellle c'est de plus en plus difficile à faire on finit par être verrouillé et dépendant des technos existantes.

In computer science
Main article: Abstraction (computer science)

Computer scientists use abstraction to make models that can be used and re-used without having to re-write all the program code for each new application on every different type of computer. They communicate their solutions with the computer by writing source code in some particular computer language which can be translated into machine code for different types of computer to execute. Abstraction allows program designers to separate categories and concepts related to computing problems from specific instances of implementation. This means that the program code can be written so that it does not depend on the specific details of supporting applications, operating system software or hardware, but on an abstract concept of the solution to the problem that can then be integrated with the system with minimal additional work.

[Jitou]

Contrairement a des avis déjà exprimés ici, je ne crois pas que la logique "financière" (coûts et délais) des entreprises soit la cause des dérives de qualité des projets développés à notre époque. Il y a bien d'autres domaines où l'on parvient à des niveau de qualité très élevé malgré ces contraintes externes. Pour moi une partie de la cause est dans la technologie qui est encore trop hésitante, qui se renouvelle trop vite et donc pas encore mature aujourd'hui. Je regrette par exemple d'avoir à développer des IHM Web en utilisant encore la logique request/response, la plupart des API dites modernes reposent encore largement sur ce principe d'un autre age. Le résultat est l'apport d'une complexité phénoménale dans le développement et la maintenance des applicatifs alors qu'une API orientée composant classique comme dans les années 90 alors à la mode du client/serveur donnerait des résultats bien plus rapide et autrement plus fiable. Patience, attendons encore 50 ans et on ne se posera plus cette question ...

[Luckyluke34]

Je regrette par exemple d'avoir à développer des IHM Web en utilisant encore la logique request/response, la plupart des API dites modernes reposent encore largement sur ce principe d'un autre age. Le résultat est l'apport d'une complexité phénoménale dans le développement et la maintenance des applicatifs alors qu'une API orientée composant classique comme dans les années 90 alors à la mode du client/serveur donnerait des résultats bien plus rapide et autrement plus fiable.

Le modèle request/response est donc d'un autre âge et à bannir alors que le client/serveur est une bonne vieille recette simple et fiable ? J'avoue que j'ai du mal à comprendre là

[Mat.M]

il y a certainement du sens et de la vérité mais j'ai du mal à comprendre également...

[Jitou]

Je parlais de manipuler des composants UI en faisant abstraction de la technologie "bas niveau" HTTP en dessous, aujourd'hui les machines clientes regorgent de puissance, on pourrai donc aussi largement déporter la partie serveur sur le client. Je sais qu'il existe des frameworks qui tendent vers cela mais qui manquent cruellement de maturité pour arriver à égaler la richesse des composants que l'on manipulait il y a 15 ans pour construire des application dites "client/server". Pour l'instant on bricole comme on peut en glanant à droite et à gauche des composants tout fait en javascript et en s'amusant avec xhr

[SurferIX]

Je parlais de manipuler des composants UI en faisant abstraction de la technologie "bas niveau" HTTP en dessous, aujourd'hui les machines clientes regorgent de puissance, on pourrai donc aussi largement déporter la partie serveur sur le client. Je sais qu'il existe des frameworks qui tendent vers cela mais qui manquent cruellement de maturité pour arriver à égaler la richesse des composants que l'on manipulait il y a 15 ans pour construire des application dites "client/server". Pour l'instant on bricole comme on peut en glanant à droite et à gauche des composants tout fait en javascript et en s'amusant avec xhr

C'est rien de le dire... et tous les nouveaux qui arrivent à l'école n'ont jamais connu ça et essaient tant bien que mal de faire du Web en recollant des bouts d'ici, des bouts de là. Un exécutable sous Windows = la fenêtre s'affichera absolument toujours de la même taille si tu le lui demande. Le bouton aura toujours l'offset X et Y, peu importe la version de Windows, et même chose pour les exécutables Linux.
Le temps qu'on perd à refaire ce qui n'aurais jamais dû avoir besoin être refait est juste inimaginable, mais seul les "old-school" le savent et passent pour des ronchons quand ils ne supportent pas de perdre trois jours à faire un site qui s'affiche de la même manière sur Safari, Chrome, et Firefox, pour ne pas parler de IE....

[Bousk]

aujourd'hui les machines clientes regorgent de puissance, on pourrai donc aussi largement déporter la partie serveur sur le client.

Sauf qu'il y a autre chose à prendre en compte : ton serveur aura toujours raison. Il ne sera pas modifié par l'utilisateur pour avoir la réponse qu'il souhaite. Donc garder un check côté serveur est (parfois) indispensable.
Et la vitesse des réseaux a aussi augmenté. Ce n'est pas vrai partout, mais si tu fais une application entièrement connectée, il n'est pas rare de voir des recommandations de vitesse de ligne également en plus de la puissance de la machine à posséder.

[Luckyluke34]

manquent cruellement de maturité pour arriver à égaler la richesse des composants que l'on manipulait il y a 15 ans pour construire des application dites "client/server".

Tu penses à quels composants exactement ?