La meilleure perle de code...

Bonjour à tous, ca faisait longtemps. Hier, je suis tombé sur un bout de code que je ne peux pas m'empêcher de partager avec vous :

public IEnumerator<T> GetEnumerator()
        {
            var pos = 0;
            while (pos < _data.Count())
            {
                yield return _data.ElementAt(pos++);
            }   
        }

jnode : jquery et nodejs

 

une api nodejs avec la simplicité de jquery.

jnode utilise le fichier jquery-core à cette adresse https://github.com/jquery/jquery/blob/master/src/core.js.

jnode a pour but d’être utilisé avec un serveur http. Vous pouvez faire sans, mais vous vous retrouverez avec des fonctionnalités inutiles.

Ce qu’apporte jnode :

• Une configuration simple d’un serveur http
• un serveur de fichiers statiques
• un serveur d’api (avecla possibilité d’encapsuler automatiquement le résultat en fonction du type de contenu attendu par le client)
• la fonction $ de jquery : vous pouvez charger un module avec la fonction $ ou l’utiliser pour exporter un handler
• les isFunction, isArray, ... de jquery sont bien sûr de la partie.
• vous trouverez aussi les inmanquables extend, each, inArray, merge, grep, map, function de jquery

La façon de construire des UI évolue

Depuis quelques temps, je travaille sur un framework d’UI en .NET. Ce framework est potentiellement capable de générer une UI en n’importe quoi. Pour l’instant un rendu WPF et HTML sont implémentés. Ce dont je me suis aperçu en faisant de framework c’est que nos besoins d’UI ont évolués.

Les contrôles d’UI que nous voulons ne sont plus des contrôles bas niveau tels qu’un bouton ou un TextBox, mais des contrôles haut niveau : un contrôle Master-Detail, une toolbar. Je ne vais certainement pas m’attirer les bonnes grâces des designers et autres infographistes en disant cela, mais le design importe peu au final. Ce qui compte, c’est d’avoir un rendu fonctionnel.

Une application se décrit de manière fonctionnelle : un menu, une vue maître/détail, une fonction d’export de la vue maître… Le fait que le bouton se situe au-dessus de la grille ou dans un onglet contextuel d’un ruban, qui s’en soucie ? Ce qui importe, c’est d’avoir un comportement cohérent au sein d’une application, et si ce comportement peut être généralisé à toutes les applications existantes sur un OS, c’est encore mieux. C’est ce que commence à propose Microsoft avec son API WinRT. Une UI commune pour toutes les applications Metro.

Ce qu’il manque à .NET, c’est une uniformisation des interfaces. Avec le XAML, on tend effectivement vers cette uniformisation, mais le soucis, c’est qu’il ne s’agit pas d’une bibliothèque de contrôles identiques : Silverlight a la sienne, WPF aussi, WinRT, qui arrive, aussi. C’est là où intervient mon framework en cours de développement : 1 langage, des cibles différentes. J’ai tenté de pousser le concept à son maximum en proposant de n’avoir qu’une dll contenant l’UI, et c’est ensuite le projet que vous faites qui doit spécifier qu’il s’agit d’une application Web, Win, … Et voilà. Bien sûr, il ne s’agit là que d’une humble contribution, pleine de bugs à souhaits, manquant cruellement de fonctionnalité. Le but est principalement de démontrer le concept.

A mon avis, le développement d’application va prendre un nouveau tournant après la sortie de Windows 8, et je pense que la tendance sera à 1 langage => n plateformes, 1 plateforme => 1 UI uniforme. La seconde tendance a déjà émergé avec iOS ou WindowsPhone. Dans les best practices de développement d’UI (web principalement), on nous recommande toujours tester les fonctionnalités plutôt que de tester le moteur de rendu. N’est-ce pas une première étape vers un langage universel de création d’UI ? Est-il possible d’uniformiser toutes les UI sous un seul et même langage universel ?

Evaluant est Happly

Depuis le premier juillet 2011, Evaluant devient Happly. A partir de là, nous pouvons nous poser la question suivante : Qu’est ce que cela change ? La réponse pourrait se résumer à plein de choses et pas grand chose. Alors, un complément de précision est nécessaire :

• Ce qui change : un nouveau nom, de nouvelles ambitions et plus de moyens.
• Ce qui ne change pas : les mêmes équipes, les mêmes valeurs d’entreprise. En résumé, Happly restera le même acteur régional.

Repris de l’article de Philippe.

Marshalling en .NET, quelle galère !

Bonjour à tous,

Je n’ai pas consacré beaucoup de temps ces temps-ci au mon blog. Cela ne m’a pas empêché de travailler sur un projet perso. J’en avais déjà parlé à quelques collègues, mon but est de me faire un media center basé sur VLC en WPF. J’avais 3 idées en têtes :

• Intégrer sans WindowsFormsControlHost la vidéo de VLC pour pouvoir avec la puissance de WPF au niveau des transformations
• Avoir une interface Metro
• Avoir une interface Web/REST me permettant de contrôler mon Media Center (de la même façon que l’API sur la FreeboxHD)

C’est maintenant chose faite pour deux de ces trois tâches : une interface métro est assez simple à réaliser en WPF. Par contre, l’intégration de VLC l’est beaucoup moins. Avec l’aide d’un collègue qui a pas mal navigué dans le monde de la 3D, j’ai pu décortiquer le module direct3D de VLC et le reproduire en C#. VLC étant codé en C, il a fallu créer des délégués. J’ai voulu utiliser un wrapper tout fait comme vlcdotnet. Mais là encore, le wrapper bas niveau n’était encore pas réalisé comme il le fallait. Mais il m’a fallu vraiment beaucoup de temps avant de comprendre que mon problème venait du marshalling de .NET. un int* ne peut pas être marshallé en int[] parce que la taille n’est pas connue. Du coup j’avais un tableau de taille 1 alors que c’était un tableau de taille 5 sur VLC. Bref, cumuler des erreurs de marshalling sur 3 callbacks différents, ca fait beaucoup d’erreurs pour comprendre pourquoi ca marche pas…

EUSS en asynchrone !

Euss avance ! Désormais, les requêtes en asynchrones sont réalisable. En tout cas le moteur le plus basique d’euss (le moteur mémoire) les gère. C’est bientôt la fin de DataService

Comment activer l’intellisense sur les fichiers javascript

Salut à tous,

Je viens juste de lire un post que j’ai pensé qu’il serait intéressant de partager. Vous avez tous certainement déjà entendu parler de jquery et du fait qu’avec la version 1.3, il y avait un fichier vsdoc que vous pouviez télécharger pour avoir l’intellisense lors de l’écriture de javascript avec jquery. Maintenant, un patch a été publié pour visual studio qui active le support des fichiers vsdoc. Pas seulement pour jQuery, mais pour n’importe quel fichier javascript.

Voici le lien vers le post original : http://blogs.msdn.com/webdevtools/archive/2008/11/07/hotfix-to-enable-vsdoc-js-intellisense-doc-files-is-now-available.aspx

Voici le lien vers le site de jquery où vous pouvez télécharger le fichier vsdoc : jQuery web-site (Cherchez “Documentation: Visual Studio”)

Bien-sur, il ne faut pas déployer le fichier vsdoc. Celui-ci est présent simplement pour une aide au développement…