Publicité
+ Répondre à la discussion Actualité déjà publiée
Page 5 sur 5 PremièrePremière 12345
Affichage des résultats 81 à 86 sur 86
  1. #81
    Membre émérite
    Homme Profil pro
    Analyste/ Programmeur
    Inscrit en
    juillet 2013
    Messages
    508
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Analyste/ Programmeur

    Informations forums :
    Inscription : juillet 2013
    Messages : 508
    Points : 926
    Points
    926

    Par défaut

    Personne ne semble connaître XCode pour iOS

    XCode est pénible sur certains points [surtout lorsqu'on vient du monde Windows], mais:
    1) La génération des écrans IHM, c'est du XML. Donc [quasi] impossible de le faire à le main.
    Ensuite XCode a une très bonne intégration de ces écrans [mais pas que par exemple pour ARC, CoreData et les storyboards]: donc sans XCode je ne suis jamais posé la question.

    La solution sans XML est "à l'ancienne": rajouter un à un dans le code les éléments graphiques en les configurant

    2) Dans les options, toutes les options du compilateur et du linker sont présentes. Comme Visual.
    Et à la première compilation tu dois configurer tes 2 environnements debug et production
    De plus XCode t'affiche les lignes de commandes qu'il génère/ utilise.
    Donc je ne vois pas trop le problème

    3) Il y a des trucs sympas comme le "jump to definition" pour voire tous les petits frères d'une méthode ou d'une valeur.
    XCode permet aussi de se balader dans le code rapidement (notamment avec les #pragma mark)

    4) Et je ne parle pas de la publication automatique des applications, de la gestion des url types (notamment pour Google +), des comptes/ identifiants, ...
    Surtout lorsque tu vois que pour Eclipse/ Android SDK toute la configuration du projet (mais pas que) doit se faire obligatoirement avec du XML: je préfère laisser un IDE faire cela à ma place


    Et sinon, niveau génération de code, XCode te génère un squelette minimal AppDelegate/ AppControler/ premier écran + 2-3 "trucs" en fonction de la nature du projet et il n'y quasi rien dedans
    Ce n'est pas forcément un gain de temps, mais plus une sécurité du code de base [parce qu'Apple change 2-3 choses par ci par là en fonction de l'évolution du framework]

  2. #82
    Expert Confirmé Sénior
    Avatar de Katyucha
    Profil pro
    Ingénieur systèmes Linux/Unix/SAN
    Inscrit en
    mars 2004
    Messages
    3 264
    Détails du profil
    Informations personnelles :
    Localisation : Allemagne

    Informations professionnelles :
    Activité : Ingénieur systèmes Linux/Unix/SAN

    Informations forums :
    Inscription : mars 2004
    Messages : 3 264
    Points : 4 748
    Points
    4 748

    Par défaut

    Citation Envoyé par steel-finger Voir le message
    Je trouve que cette article est du grand n'importe quoi, je pense qu'un développeur dois savoir utilisé les nouveaux outils mis a ça disposition sans pour autant qu'il oublie c'est connaissances, si ça peut le rendre plus productif au contraire, la personne qui a écrit cette article, n'a pas d'argument valable, et surtout il ne peux en aucun cas vérifier ce qu'il dit, bien sur on parle de développeur professionnel et non les gens qui débutent
    Alors là, 100% d'accord pour la partie : "Sans pour autant qu'il oublie ses connaissances"
    Malheureusement, je le vois de plus en plus en tant que sysadmin, les devs comprennent de moins en moins comment s’exécute du code. Je raconte toujours l'histoire du développeur, qui ne connait pas le principe de "FORK".
    Un developpeur n'a pas besoin d'avoir le même niveau de connaissance qu'un sysadmin mais il y a un minimum à connaitre sur l'execution de ses programmes. Aujourdh'ui avec les IDE, j'ai de plus en plus la sensation que les developpeurs s'en tapent royalement. Résultat, on se retrouve avec des programmes qui bouffent un maximum de mémoire/cpu/IO disk
    Je vais faire mon vieux con mais le developpeur C à l'ancienne, savait le prix d'un malloc.
    Ancien Rédacteur Linux && Unix / Nouveau retraité de DVP
    "En face, c'est des c**s, alors au premier regroupement, il faut qu'ils discutent avec les taupes."

    Je ne réponds ni aux messages privées, ni aux messages plein de fautes...

  3. #83
    Membre Expert
    Avatar de Mickael_Istria
    Homme Profil pro Mickael Istria
    Développeur Expert Eclipse RCP
    Inscrit en
    juillet 2008
    Messages
    675
    Détails du profil
    Informations personnelles :
    Nom : Homme Mickael Istria
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Expert Eclipse RCP
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juillet 2008
    Messages : 675
    Points : 1 156
    Points
    1 156

    Par défaut

    A propos de noir sur blanc vs. blanc sur noir: http://uxmovement.com/content/when-t...rk-background/ . En plus de cet article et de similaires, j'en avais parle a la medecine du travail, et on m'avait confirme que noir sur blanc etait plus relaxant pour les yeux. Par contre, il faut generalement baisser un peu la luminosite de l'ecran, et imperativement prendre des pauses pour se detendre les yeux (la regle des 3 * 20: toutes les 20 minutes, regarder a plus de 20 metres devant pendant 20 secondes).

    Au niveau des avantages d'un IDE, il y a certes la coloration/completion, qu'un bon editeur peut avoir, mais aussi d'autres choses plus subtiles, qui mises bout-a-bout ameliorent vraiment l'efficacite lorsqu'on code (laissant ainsi plus de temps pour reflechir ou tout simplement ne rien faire, ce qui est bon pour la sante):
    * Le debug associe avec l'editeur
    * La validation a la volee: on voit certaines erreurs des qu'on les ecrit, pas apres. Meme avec les langages dynaminques (JavaScript, Groovy, Python...), Eclipse est par exemple capable de mettre en italique ce qu'il ne resout pas statiquement. Rien que ca, ca permet d'eviter pas mal de soucis
    * Une completion plus contextuelle, en triant par exemple par type (lorsqu'il est connu), voire par "popularite" dans des bases de code connues
    * Une organisation par "tache" associee a un bug tracker: cela permet de filtrer ce qu'on veut voir ou non, selon la tache en cours, et de passer de l'une a l'autre sans trop avoir a se demander "alors c'est quel fichier que j'etais en train de bidouiller deja?"
    * Des assistants et des editeurs visuels pour generer des squelettes de code: meme si le resultat en terme de code n'est pas toujours parfait, ca permet de demarrer le developpement plus vite.
    * Les deploiements/builds/refresh automatiques: ne pas avoir a lancer les commandes de builds et de deploiement, on configure l'IDE et il fera ca pour nous des que necessaires. Du coup il suffit de faire un "Save" pour que la page web qu'on a dans Chrome soit mise-a-jour.
    * ...

    Il existe des outils separes dans tout ca, mais le bon point de l'IDE, c'est de les integrer et de faire en sorte que leur utilisation soit transparente et la plus efficace possible.
    Ca cree beaucoup de productivite, ce qui fait que pour faire la meme chose, un IDE demandera moins de travail et vous permettra de rentrer plus tot a la maison. Se remettre a utiliser des editeurs bas niveau et de la ligne de commande en permanence representerait pour beaucoup une grosse perte de temps.
    Tu fais du JEE/Web/Mobile dans Eclipse? T'as essaye JBoss Tools ?
    Read my blog about Eclipse | Follow me on twitter

  4. #84
    Membre chevronné Avatar de Simara1170
    Homme Profil pro David Champagnat
    Développeur Delphi
    Inscrit en
    avril 2014
    Messages
    286
    Détails du profil
    Informations personnelles :
    Nom : Homme David Champagnat
    Âge : 24
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur Delphi
    Secteur : Enseignement

    Informations forums :
    Inscription : avril 2014
    Messages : 286
    Points : 621
    Points
    621

    Par défaut

    Bien d'accord avec mon VDD, auquel j'offre une petite pelle US pour le déterrage

  5. #85
    Membre Expert
    Homme Profil pro
    Étudiant
    Inscrit en
    juin 2012
    Messages
    851
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : juin 2012
    Messages : 851
    Points : 1 598
    Points
    1 598

    Par défaut

    Citation Envoyé par Katyucha Voir le message
    Aujourdh'ui avec les IDE, j'ai de plus en plus la sensation que les developpeurs s'en tapent royalement. Résultat, on se retrouve avec des programmes qui bouffent un maximum de mémoire/cpu/IO disk
    Je vais faire mon vieux con mais le developpeur C à l'ancienne, savait le prix d'un malloc.
    Je ne vois absolument pas le rapport, c'est pas parce qu'on à l'auto-complétion, des outils de refactoring etc.. qu'on saura mieux ou moins bien ce qu'il se passe réellement derrière les lignes de code que l'on écrit.
    Il n'y à que pour le code auto généré où ça reste flou, mais cela ne concerne pas le code critique (le plus souvent cela se limite à l'UI).

    Citation Envoyé par Mickael_Istria Voir le message
    A propos de noir sur blanc vs. blanc sur noir: http://uxmovement.com/content/when-t...rk-background/ . En plus de cet article et de similaires, j'en avais parle a la medecine du travail, et on m'avait confirme que noir sur blanc etait plus relaxant pour les yeux. Par contre, il faut generalement baisser un peu la luminosite de l'ecran, et imperativement prendre des pauses pour se detendre les yeux (la regle des 3 * 20: toutes les 20 minutes, regarder a plus de 20 metres devant pendant 20 secondes).
    Je trouve que le blanc sur fond noir (blanc cassé sur fond gris foncé plutôt) est moins agressif pour les yeux, en particulier dans un environnement sombre (je peux pas être le seul à aimer coder dans le noir quand même ? )



    (Je suis pas médecin ni expert dans le domaine, c'est juste un ressenti.)

  6. #86
    Membre Expert
    Homme Profil pro
    Analyste-Programmeur / Intégrateur ERP
    Inscrit en
    mai 2013
    Messages
    261
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Analyste-Programmeur / Intégrateur ERP
    Secteur : Bâtiment

    Informations forums :
    Inscription : mai 2013
    Messages : 261
    Points : 1 023
    Points
    1 023

    Par défaut

    Citation Envoyé par Iradrille Voir le message
    Je trouve que le blanc sur fond noir (blanc cassé sur fond gris foncé plutôt) est moins agressif pour les yeux, en particulier dans un environnement sombre (je peux pas être le seul à aimer coder dans le noir quand même ? )
    Bah tu n'es surement pas le seul, mais c'est juste super déconseillé, au contraire, il faut être dans un environnement le mieux éclairé possible pour moins s'abimer les yeux, peu importe la couleur de fond.

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •