[Idée à approfondir] Serveur privé Nabaztag (Mon-Nabaztag.fr)

cyril_92 a écrit:

malheureusement on ne coupera pas à une migration du code tous les 3-4 ans ... avec du taf pour les développeurs ..

Ça laisse quand même pas mal de temps devant nous... même si je suis du même avis sur le choix du .NET

.NET
Migration du code tous les 4 ans ? Je ne vois pas pourquoi.
Si on commence en .NET 4, rien n'oblige la migration vers les versions 5, 6 et ultérieures. J'ai, par exemple, encore des applications que j'ai développé en .NET 2.0 (2004 !) qui fonctionnent parfaitement bien (et que je supporte).
Qui plus est, si jamais migraiton il devait y avoir, elle serait automatique ! Et changer de version du Framework (du 2 vers 3.5) ne pose pas de soucis, les versions étant rétro-compatibles (combein de fois ai-je fais évoluer mes apps en 2.0 vers 4.0, tout ça pour les beaux yeux de LinQ )


Finances :
Beaucoup de jeunes n'ont pas de CB. J'accédais à certains services uniquement par Allopass lorsque je n'avais pas encore le précieux sésame bleu.
De toute façon, pour utiliser les services de paiement par CB en ligne, il faut souscrire à un contrat avec un banque (négociable), mais qui s'élève à plusieurs dizaines d'euros par mois. Le but est de payer les serveurs, pas les frais de paiement.

Aussi, certains préfèrent utiliser Paypal plutôt que d'entrer encore et encore et encore leur numéro de CB sur un site. Certains trouvent ça plus sécurisé.
On peut aussi "alimenter" un compte Paypal sans CB, en reçevant des paiements d'autres personnes.


Windows Server :
OK pour Windows Server 2008 R2, c'est le minimum.
Choisir une version US parce qu'il y a moins d'un jour de décalage entre la mise à disposition des patchs, c'est quand même gros... La faille ne viendra généralement pas de l'OS mais plus du code produit pas l'équipe de développement. Sans compter les soucis de localisation.
Pour Windows Update, c'est la bête noire... Un redémarrage automatique est très ennuyeux en pleine journée, moins en pleine nuit.
La SGBD, c'est déjà réglé : SQL Server 2008. Et le partenariat Microsoft, je pense m'y atteler l'année prochaine, durant ma scolarité, avec le support de mon école.


Au final, évidemment qu'il y aura une doc. Travailler à plusieurs sur un projet sans doc, c'est un peu comme sauter sans parachute
Tous ces points sont de toute façon discutables, mais j'estime que ce n'est pas encore le moment de plonger dans les détails insignifiants. Concentrons-nous d'abord sur le développement du serveur, est dès lors que nous aurons quelque chose d'opérationnel, on pourra diversifier les actions.

Quand on travaille en technos Microsoft (et je le fais depuis plus de 12 ans) il faut savoir que :

- les failles viennent autant de l'OS que de l'applicatif au dessus,

- il faut être attentif aux dates de fin de support, car en cas de souci (bug ou sécurité) on ne sera pas maintenu. ceci même si l'applicatif fonctionne, ou même si le développeur est là et se souvient du code qu'il a écrit il y a 2 ans.

- la rétrocompatibilité n'est que partielle (on le voit bien en entreprise ça )

- ce n'est pas parce que c'est automatique (ex. : outils de migration) que l'on ne doit pas regarder et adapter le résultat.

- ne pas appliquer les patchs de sécurité microsoft c'est avoir un serveur cracké, squatté ou dans un bot-net à coup sûr en moins d'un an.
C'est un peu le même débat que de dire que l'antivirus et le firewall ça ralentit le surf, et donc on les enlève .... mdr ...
Et quelques mois après "comprend pas, il est tout lent ... "


Sur les points de détail technique :
- le reboot auto après patch est paramétrable,
- utiliser SQL Server 2008 n'est pas incompatible avec un vrai développement N-tier, donc sans traitements en base,



Ce n'est pas parce que l'on a des idées que ce sont les bonnes, et sur les forums il y a aussi des gens bac +5, dont c'est le métier, en entreprise, pour des applicatifs sensibles.



@++

Tout ce que tu annonces ici, je le sais bien. Je suis moi-même étudiant en école supérieure d'informatique et j'entre dans ma 5ème année. Ce serait bête pour moi de ne pas avoir reçu les bases

Je ne me lance pas dans ce projet à corps perdu. Je suis un maniaque de la sécurité, j'ai des compétences en développement et je ne fais pas ce serveur en .NET pour kikouloler autour d'un buzz "libération des sources" et me révolter contre OpenJabNab.
C'est un projet sérieux, que j'aimerai faire passer comme projet de fin d'études (l'année prochaine donc). Il est viable à long terme quant aux technologies choisies (fin de support WS2K8R2 en 2017, SQL Server 2008 R2 en 2018).

Cependant, j'aimerai beaucoup en savoir plus sur les soucis de rétro-compatibilité que tu as pu rencontrer. Les seules migrations que j'ai faites (.NET 2.0 > 3.5 ou 4.0) ont été un succès : rétro-compatibilité totale.
La seule chose que je vois c'est une migration de VB6 vers VB.NET, mais c'est totalement autre chose.
N'hésite pas à m'en dire plus par MP, c'est un sujet qui m'intéresse.

Je pense que ces soucis de compatibilité ont leur place dans ce sujet, qui parle de technos microsoft.. et bien que je préfère rester sur la solution openJabNab, les réponses à ces questions m’intéressent beaucoup.

Ce ne sont pas des soucis de compatibilité, mais des futures migrations vers une version plus récente du Framework ou des applicatifs.
C'est du long terme (7 ans), et tout peut évoluer entre temps. A court terme, il n'y a pas de problème.

C'est le même problème pour tout... Le jour à PHP5 ne sera plus, il faudra passer au suivant, et faire les migrations qui seraient nécessaires.
Je ne vois pas en quoi c'est un problème, c'est la continuation logique d'un développement.