Commentaires

Merci à toi, c'est toujours appréciable d'avoir un retour

Merci Patrick pour ce retour, très intéressant !

Envoyé par dourouc05

Les compilateurs Microsoft restent bloqués à C89 pour leur mode C ; pour le reste, il faut passer en mode C++ (/TP dans la ligne de commande). La justification principale est que leurs clients leur demandent très peu de C : ils implémentent de mieux en mieux C++, les évolutions de C nécessaires dans ce mode, mais pas un mode C un peu décent.

C'est tout à fait ça et c'est un peu triste. Si on veut un compilateur C conforme au standard récent il faut aller voir vers des UNIX (mais certains sont portés vers Windows). Je partage l'avis de Kolodz que cette idée de déclarations en début de bloc est devenu un anti-pattern aujourd'hui, à raison. C'est certainement pour faciliter la vie des programmeurs de compilateur que ça a été fait initialement.

Cela étant il existe une façon de contourner mais qui n'est pas bien jolie non plus:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
void log_and_do_sthg() {
  log("blablabla")
  {
     int i = bloblo();
     ...
   }
}

Dans un bouquin de C moderne (en tout cas postérieur au standard C99), je ne me rappelle plus lequel, l'auteur disait: "c'est bien de profiter de cette nouvelle possibilité, mais attention, hein, pas d'excès du genre for (int i = 0; i < BUF_SIZE; ++i) Comme quoi les habitudes ont la vie dure.

Merci pour ce billet que je découvre un peu tard!
Juste une réflexion: pour un gestionnaire de versions à la main créé il y a vingt ans, il était tout de même drôlement bien fait puisque tu as pu retrouver presque toutes les infos pertinentes en quelques dizaines de lignes de Java (d'ailleurs, pour moi qui ne suis pas un fan de ce langage, je dois tout de même tirer mon chapeau en voyant tout ce qu'on peut faire en restant dans la bibliothèque standard). Dommage tout de même que tu n'aies pas essayé de proposer un passage à Git, puisque tu n'étais plus très loin d'une conversion complète quand tu as fait ton repo perso.

Tiens, j'écoutais un reportage ce matin sur le Li-Fi.

Parait qu'on est à la pointe en France dans le domaine, avec des produits déjà fonctionnels...

Oledcom de Vélizy arrive, par exemple, à baisser l’intensité lumineuse quasiment jusqu’à zéro sans couper la transmission. Il n’est donc plus nécessaire de garder la lumière allumée.

Trop fort... du Li-Fi dans le noir.

Merci pour l'info en tout cas

Les différents problèmes de ce genre de solution, c'est premièrement la sauvegarde. Pour un non initié à l'informatique, croire que ces données sont protégés parce qu'elles se trouvent sur une carte SD est une vaste blague.

Si l'on s'auto héberge pour tout (mail, web, etc.) alors il faut une sacré redondance matériel et être absolument sur de n'avoir aucune coupure de courant ou d'internet, dans différents lieux et n'avoir aucun problème logiciel. Déjà que des boites privées ont parfois du mal alors "le péquin moyen"...
Sauf à considérer que la perte [B][U]définitive [/U][/B]de nos données n'est pas dramatique et dans ce cas pas de soucis, de ce point de vue là ce genre de solution est tout à fait adapté.

Deuxième problème et pas des moindre que les gens de la ville oublient :) le débit de la connexion internet. Parce que faire de l'upload/download de fichier avec du 100ko/s au mieux, il faut avoir du temps à perdre. Et ca malheureusement, ce n'est pas cette box qui offrira une solution.

Pour finir, come dit plus haut, si le méchant FAI décide de filtrer l'ip du vpn (à cause du gouvernement par exemple), hop plus de mail, plus de site, plus de partage de fichier. Dans le genre single point of failure, on ne fait pas mieux. Même chose, si c'est le prestataire de la box qui arrête le vpn.

En gros, [B][U]de mon point de vue[/U][/B], ce genre d'initiative est bien pour apprendre et découvrir, mais en aucun cas dans le cadre d'un usage réel.

Envoyé par helje

Euh... si le FAI filtre au niveau de la box, je ne vois pas comment la "brique" peut lutter contre ! La box est en amont de la brique !

Tout le trafique passe par un tunnel VPN (Réseau privé virtuel) entre la brique et le fournisseur d'accès associatif. Ce qui fait que le FAI ne voit qu'un seul flux de données crypté entre la brique et un autre FAI (associatif). Le FAI de base peu certes filtrer, mais seulement en tout ou rien.

Cordialement,
Patrick Kolodziejcyzk.

Euh... si le FAI filtre au niveau de la box, je ne vois pas comment la "brique" peut lutter contre ! La box est en amont de la brique !

Envoyé par Rubicon

• Où sont stockées les donnés de l'auto-hébergement (Courriels, site web etc...) ? Sur la carte SD contenue dans la brique ?

Oui, si tu va sur le lien du projet, tu peux voir dans la section "Matériel proposé"

Carte micro-SD qui sert de disque dur interne : Transcend Premium 300x Classe 10 (16 Go est suffisant)

Envoyé par Rubicon

• Si la brique est détruite par un pot de fleurs ou volée par un combrioleur, la carte SD mangée par le chat ou volée par une pie, alors toutes les données sont perdues, n'est-ce pas ? Pas de sauvegarde ni rien, vu que tout est local. Ai-je tort?

Oui, mais rien ne t'empêche de faire une sauvegarde annexe. Mais la même chose et valable pour l'hébergement en ligne. Même Microsoft, Google et Amazone ont déjà perdu des données clients. Alors que celle-ci étaient en théorie backupé...

Envoyé par Rubicon

• Hébergement web :
  
  Comment se passe l'enregistrement du nom de domaine ? À quel coût?
  Comment installe-t-on les différents composants (Base de données, scripts, fichiers...) ? À quel coût?

Pour l'enregistrement du domaine, cela dépends du domaine et non de la "brique".
De base, le projet propose une version "clé en main" :

Envoyé par Comment obtenir une Brique Internet ?

...Les associations proposent en général de vous fournir la Brique complète, entièrement montée, installée et configurée avec un accès VPN : il ne vous restera plus qu'à la déballer et la brancher chez vous pour bénéficier de votre nouvel accès à Internet propre, sans rien avoir à faire d'autre (et installer ensuite des services web auto-hébergés si le cœur vous en dit, en quelques clics sur l'interface d'administration).
...

Mais, il t'es possible de le faire toi-même !
Pour la partie installation, cela se base sur le projet/logiciel YunoHost.
Le guide d'installation se trouve ici
Le prix de la licence doit-être d'au moins une bière, parce que j'applique ma nouvelle taxe ! Plus sérieusement le projet est sous "GNU AFFERO GENERAL PUBLIC LICENSE". (voir github)

Mais, je ne suis peut-être pas le mieux placer pour répondre. Si tu veux plus de détail n'hésite pas à contacter les personnes du projets :

Liste de discussion : discussions@listes.labriqueinter.net
IRC : #labriqueinter.net sur irc.geeknode.org
Twitter : @Une_brique (peu utilisé)
GitHub : labriqueinternet

Cordialement,
Patrick Kolodziejczyk.

La Brique Internet permet deux principaux usages :
[...]
S'autohéberger :

1. Où sont stockées les donnés de l'auto-hébergement (Courriels, site web etc...) ? Sur la carte SD contenue dans la brique ?
2. Si la brique est détruite par un pot de fleurs ou volée par un combrioleur, la carte SD mangée par le chat ou volée par une pie, alors toutes les données sont perdues, n'est-ce pas ? Pas de sauvegarde ni rien, vu que tout est local. Ai-je tort?
3. Hébergement web :
   
   Comment se passe l'enregistrement du nom de domaine ? À quel coût?
   Comment installe-t-on les différents composants (Base de données, scripts, fichiers...) ? À quel coût?

Ca a l'air plutôt pratique...

Voici ce que j'en comprends :

Le FreeBooting n'est pas le plagiat puisque le plagiat est la reprise, ou devrais-je dire réinterprétation d'une oeuvre. Le plagiat est en quelques sorte une copie faite par un humain. Il arrive que le plagiat soit meilleurs que l'original. Pardon alors on parle de reprise mais c'est fondamentalement la même chose la seul différence est que dans "reprise" on a plus le côté péjoratif.

Dans le FreeBooting, il n'y a pas de modification, du moins pour le FreeBooting même s'il peut y en avoir par la suite. La copie, est réalisé par une machine elle est donc en tout point semblable. Il s'agit simplement de rendre disponible l'oeuvre autre part. Cela participe a la diffusion et il n'y a en cela rien de choquant. Ce qui serais immoral c'est d'en tirer plus de bénéfice que l'auteur original sans lui en reverser une partie.
De là je tire 2 type de freebooting
- Celui qui vise a diffusé a un plus large public (Pour contourner les DRM ou autres limitations innitiale) que je trouve pleinement justifiées.
- Celui qui vise a s'accaparer les bénéfices de l'auteur initial. C'est le principe même des "Pattent Troll". C'est immoral mais ce n'est pas nouveaux. Les géniaux inventeurs ayant terminé très pauvres sont monaie courantes.

bonjour,

je n'ai jamais été grand fan de l'architecture MVC personnellement. Et j'ai découvert ensuite un architecture orienté action. je ne connais pas du tout le Command Pattern, peut être que j'en ai fait dans les projet s'en m'en rendre compte. Mais en tous cas je m'y retrouve dans ce qui est décrit dans ce billet.

Étant grand adepte d'UML et donc des cas d'utilisation. Je trouve d'ailleurs que un application bâti avec un framework orienté action rend en effet le découpage du code très proche des diagramme UML. Et donc de la vu métier.

D'ailleurs pour aller dans ton sens j'invite à consulter ce lien https://github.com/CATCorporation/Ja...rc/module/user qui montre en effet qu'avec une architecture comme ça on vois très vite les action que peux faire un utilisateur dans l'application.

personnellement dans mes projets je divise même mes actions en 2 groupe. celles qui servent à modifier mes vues et celles qui servent à effecuter des action backoffice comme dans ce projet https://github.com/MarieLePanda/Fram...ter/src/module

Quels sont les différents moyens pour augmenter la productivité dans une équipe agile ?
De ne pas être inféodé aux préceptes d'Agile

Envoyé par Traroth2

Comme à chaque fois qu'on met en place des métriques portant sur la production de code, les équipes vont finir par "optimiser" leur fonctionnement de manière à être bien évaluées. La qualité du code va en souffrir (puisqu'on mesure la vitesse), et la granularité des "bidules" produits va diminuer, c'est à dire que des morceaux de code de plus en plus petits et de plus en simples seront considérés comme des "bidules". C'est la manière la plus simple d'augmenter la productivité, telle qu'elle est mesurée. Les gens suivent toujours le chemin de moindre résistance...

Comme dans la politique du chiffre dans la police, chercher à quantifier du qualitatif est une mauvaise idée. Je suis toujours à la recherche d'une exception à ce principe.

Le cœur du sujet n'est pas la productivité en elle-même, mais les axes d'améliorations que va ciblé une équipe en fonction du contexte. D'ailleurs, je ne comprends pas pourquoi tu pars du principe que cette discutions a nécessairement pour bût d’augmenter le nombre de "bidule" produit. C'est d'ailleurs, l'approche de la réduction du temps effectif de mise en production qui est présenté. Or d'après le second point de mon billet (cas où le temps de développement est nul) faire du "chiffre" n'est pas une valeur que peux réellement visualisé le client.

Par exemple, pour la livraison de deux fonctionnalités :

• Livraison de deux fonctionnalités au bout de deux semaines.
• Livraison de la premier fonctionnalité au bout d'une semaine, puis livraison de la seconde la semaine suivante.

La productivité effective de l'équipe n'a pas changé, cependant la productivité constaté à bien été amélioré.

Les points qui me semble intéressant et ayant une vraie valeur sont les suivants :

• La mise en production continue.

Car cela à de la valeur forte pour le métier et implique une maitrise de l'ensemble de la chaine de mise en production. Et donc implique du Dev-OP's

• La mise en exergue du travail en équipe.

En effet, l'approche proposer est de réduire la durée d'un sprint, mais aussi de réduire le nombre d’élément à traiter dans un sprint. Ce nombre d’éléments à traiter sera nécessairement inférieur au nombre de personne dans l'équipe. (Dès le début ou non.) Ce qui va à l'encontre de beaucoup de pratique actuelle qui considère que le plus productif est d'avoir une seule personne sur une tâche.

Au final, l'idée n'est pas de changer la productivité individuelle de l'équipe et donc de faire du chiffre, mais bien de changer la productivité/vitesse constaté d'un point de vue extérieur. Ceux-ci étant généralement deux choses totalement différentes.

Cordialement,
Patrick Kolodziejczyk.

Comme à chaque fois qu'on met en place des métriques portant sur la production de code, les équipes vont finir par "optimiser" leur fonctionnement de manière à être bien évaluées. La qualité du code va en souffrir (puisqu'on mesure la vitesse), et la granularité des "bidules" produits va diminuer, c'est à dire que des morceaux de code de plus en plus petits et de plus en simples seront considérés comme des "bidules". C'est la manière la plus simple d'augmenter la productivité, telle qu'elle est mesurée. Les gens suivent toujours le chemin de moindre résistance...

Comme dans la politique du chiffre dans la police, chercher à quantifier du qualitatif est une mauvaise idée. Je suis toujours à la recherche d'une exception à ce principe.

Les compilateurs Microsoft restent bloqués à C89 pour leur mode C ; pour le reste, il faut passer en mode C++ (/TP dans la ligne de commande). La justification principale est que leurs clients leur demandent très peu de C : ils implémentent de mieux en mieux C++, les évolutions de C nécessaires dans ce mode, mais pas un mode C un peu décent.

Je ne suis pas au fait du "standard" C. Du coup j'ai fait un peu de recherche dessus et je suis tombé sur cela :

Envoyé par RavuAlHemio

I have recently become a teaching assistant for a university course which primarily teaches C. The course standardized on C90, mostly due to widespread compiler support. One of the very confusing concepts to C newbies with previous Java experience is the rule that variable declarations and code may not be intermingled within a block (compound statement).

This limitation was finally lifted with C99, but I wonder: does anybody know why it was there in the first place? Does it simplify variable scope analysis? Does it allow the programmer to specify at which points of program execution the stack should grow for new variables?

I assume the language designers wouldn't have added such a limitation if it had absolutely no purpose at all.

Du coup, cela voudrait dire que le compilateur windows que j'utilise respecte le standard C90. Et que celui de mon Unix, soit ne le respecte pas, soit respecte un version C99 (ou supérieur)

Un autre source dit ceci :

[QUOTE]The biggest reason I know of is that it simplifies the language grammar and parser.

With the declarations up front, a block of code must look like

{
<declarations>
<stmts>
}

and consequently the definition of <stmts> is simplified because it doesn't have to involve declarations. This, in turn, simplifies the parser, since it need only disambiguate statements from declarations at the start of a block.

In fact, this particular definition of the code block is codified in the standard:

3.6.2 Compound statement, or block

Syntax

compound-statement:
{ declaration-list<opt> statement-list<opt> }

declaration-list:
declaration
declaration-list declaration

statement-list:
statement
statement-list statement[/CODE]

Cependant, je n'ai pas été en mesure de retrouver les normes C90 et C99 et cette section sur la déclaration en question...


source :
http://stackoverflow.com/questions/7...n-up-until-c99
http://stackoverflow.com/questions/1...s-and-code-why

Le comportement de ton compilateur Windows me semble tout à fait conforme au standard ANSI C qui spécifie que les déclarations se font en début de bloc.
C'est plutôt ton compilateur Unix qui est plus permissif que le standard.

Merci pour le lien. Cela présent relativement bien le contenu de Java 8. Cependant, c'est une approche très démonstratif et didacticiel. Ce qui est, selon moi, une approche très différentes de l'approche travaux pratique.
D'ailleurs, la section Java de developpez.com est assez pauvre du côté de Java 8 et des Streams. Il y a peut-être un manque à combler de ce côté.

Cordialement,
Patrick Kolodziejczyk.