<Glazblog/>

ES6 introduced a change in Gecko that remained under my radar for a looong time. Testing BlueGriffon 2.0 features, I discovered a feature that was completely borked and I was unable to explain it... Everything in my code looked fine. After some debugging, I nailed it into a codepen. Gecko and Chrome show the behaviour I dislike (window.bar is undefined if bar is a constant) while Safari does not.

I find this, mandatory per ES6 spec, completely ridiculous. It's not understandable from a JS author's perspective and apparently broke "a ton of stuff". This is clearly the kind of things where gurus and purists should have thought of users (JS authors) and did not.

Please TC39, change that. It's ugly and painful.

Mes ennuis avec le RSI (Régime Social des Indépendants), organisme très défavorablement connu de tous les non-salariés de France et de Navarre, vient de me donner un nouvel épisode, et je l'ai gagné par K.O. J'envisage très sérieusement désormais de porter plainte contre le RSI. Voici les faits, bruts de fonderie :

1. je démarre ma SARL en octobre 2003. Étant gérant majoritaire, je ne peux être salarié et me retrouve direct affilié au RSI
2. pendant 7 ans, le RSI est le seul organisme collecteur qui pose problème : documents non reçus, documents en versions multiples et différentes, amendes indues, j'en passe et des meilleures
3. en mars 2010, je transforme mon entreprise en SAS. Tout est fait dans les règles via la Chambre de Commerce de Versailles qui transmet correctement tous les bordereaux. La transformation est finalisée pour le 1er avril 2010, je suis donc automatiquement désaffilié du RSI au 31 mars 2010 au soir pour rejoindre - enfin - le régime général.
4. URSSAF, impôts, prévoyance, tout est notifié en temps et heure et toutes actions sont menées pour mettre mon statut à jour dans ces organismes SAUF AU RSI qui continue à m'abreuver chaque trimestre d'appel de fonds.
5. malgré tous mes courriers, en AR, le RSI continue de me poursuivre de ses assiduités et m'envoie en plus des pénalités de retard, des commandements à payer. Évidemment, je ne paye pas puisque je n'ai plus à payer !
6. le RSI finit par me signifier par voie d'huissier une contrainte, à laquelle je m'oppose immédiatement
7. le 22 mai 2013, audience est tenue au Tribunal des Affaires de Sécurité Sociale des Yvelines, à Versailles. Sur 10 audiences, 9 sont clairement des requêtes infondées du RSI. Le Président du tribunal se marre doucement à chaque exposé, et se marre franchement quand le type devant moi demande réparation du préjudice causé par le RSI à hauteur de 7 jours à son taux horaire de consulting... Pour ma part, je demande la condamnation du RSI à 1€ pour le préjudice causé.
8. le 25 septembre 2013, le RSI est débouté de l'intégralité de ses demandes me concernant, condamné à 1€ à me payer au titre des dommages et intérêts, et doit assumer seul les frais de la contrainte et des tentatives de recouvrement
9. entre le 25 septembre 2013 et hier, aucun signe de vie du RSI ou de son huissier...
10. hier midi, je reçois un recommandé de ma banque Boursorama me notifiant une tentative de saisie-attribution sur le compte joint que je détiens avec ma compagne. J'appelle Boursorama immédiatement qui m'annonce que cette saisie est faite par tel huissier sur demande du RSI... Urgggh !
11. je me rends immédiatement chez l'huissier et découvre plusieurs choses effarantes :
    1. la contrainte est la même qu'en 2013
    2. le RSI tente de récupérer les pénalités de retard sur les cotisations indues de trimestres plus récents que ma désaffiliation, encore une fois !
    3. l'adresse qu'a utilisée l'huissier n'est pas la bonne, ce qui explique que je n'ai jamais reçu la moindre notification de reprise d'une procédure
    4. la tentative de saisie a été effectuée sur un compte joint que ma compagne alimente majoritairement. La contrainte aurait donc du lui être signifiée, ce qui n'a pas été le cas. L'huissier n'a effectué aucune vérification en se sens.
12. après récupération du jugement de 2013, je retourne chez l'huissier mettre fin à tout ça. L'huissier me confirme alors en blémissant n'avoir jamais eu communication par son client de ses élements. Or la contrainte a été en 2011 signifiée par le même huissier qui était au courant de l'opposition et du passage au Tribunal. J'exige évidemment la main-levée immédiate de la contrainte sous peine de poursuites.

Le RSI, avec ses méthodes habituelles, le trou noir qui lui sert d'archives et les sommes délirantes qu'il dépense en pure perte en poursuites au lieu de se préoccuper des services fournis à ses clients. Le RSI n'a pas appliqué la décision de justice, n'a pas versé la condamnation d'1€, a relancé sans droit la procédure, l'huissier a été négligent dans ses courriers à mon endroit et dans sa tentative de saisie. Je compte saisir la Chambre Nationale des Huissiers de Justice et porter plainte contre le RSI. Je suis en train de chercher un conseil (avocat) en ce sens. L'impunité du RSI dans ses poursuites infondées doit être stoppée, nous avons tous, entrepreneurs, eu affaire aux méthodes honteuses du RSI. Souhaitez-moi bonne chance, et si vous êtes avocat et que l'affaire vous intéresse, contactez-moi au plus vite. Merci !

Totalement épuisé, je viens de faire une petite sieste réparatrice. Fait rare, je me souviens de mon rêve. Fait exceptionnel, j'ai rêvé que je cuisinais... Dans mon rêve, j'appelais ça le Veau-Soleil. Je n'ai aucune idée si c'est faisable, si ce serait bon ou même mangeable. Je vous livre verbatim :

1. découper une lanière fine d'environ cinq centimètres de long dans la peau d'une aubergine
2. demander à votre boucher de vous découper une escalope de veau la plus rectangulaire possible, fine d'un des côtés longs et un peu plus épaisse de l'autre
3. avec un bon couteau non denté et surtout bien aiguisé et en partant du côté fin, découper des rayons sur la largeur de l'escalope tous les demi-centimètres en s'arrêtant à un centimètre du bord opposé
4. solidariser les deux extrémités du côté épais avec la lanière de peau de courgette après avoir percé deux petits trous dans l'escalope
5. préparez un mélange à 50% de chapelure fine et 50% de parmesan râpé
6. clarifiez un œuf
7. au pinceau, badigeonnez votre escalope - d'un seul côté - au blanc d’œuf
8. saupoudrez immédiatement toutes les zones badigeonnés de votre mélange
9. mettez de côté à température ambiante
10. découpez des tranches (sans peau) de carotte et aubergine de 0.3 cm chacune
11. passez les 3 minutes à la cocotte-minute en prenant soin que le niveau d'eau ne touche pas les tranches
12. découpez les tranches en petits dés de 0.3 cm ; préparez également des dés de citron doux, type citron de Menton ou de Ligurie, que vous conserverez à part au frais
13. réservez au chaud
14. faites fondre un peu de beurre dans une poêle à moyenne puissance
15. placez votre escalope du côté pané dans votre poêle et laissez dorer
16. lorsque le côté pané est doré à votre goût, retournez votre escalope pour dorer également le côté non pané
17. réservez à votre guise, en laissant les jus de cuisson dans la poêle
18. déglacez les jus de cuisson avec une cuillère à soupe d'eau et passez vos dés de légumes à la poêle pour les assouplir
19. sortez vos dés de légumes de la poêle, mélangez-les avec vos dés de citron
20. placez vos dés en demi-sphère au centre de votre escalope-soleil
21. servez

Oui, je sais, j'ai besoin de vacances...

I'm currently playing with Swift, outside of Xcode (but of course, you need to have Xcode installed to have swiftc installed...), when I have a few spare cycles and building more than just a few files was getting so painful I started working on a minimal build structure. Since it's working pretty well and it was not always easy to figure out what to do, I've decided to share it.

First, clone the following git and copy the swiftbuild directory you'll find inside to your project's top directory: git clone https://github.com/therealglazou/swift-makefiles.git

Then tweak the swift/config.mk according to your wishes (in the repository, it's for a macosx x86_64 target).

Finally, add a Makefile file to each directory inside your project. Each file should look as following:

# TOPSRCDIR is a relative path to the top directory of your project
# for instance:
TOPSRCDIR = ../../..

# if you have subdirs to build, list them in DIRS. They will be built
# before the files directly in your directory
# for instance:
DIRS = public src

# if you're building a module from the swift files in this directory
# name your module in MODULE_NAME
# for instance:
MODULE_NAME = MyProjectCore

# if your directory contains your main.swift (mandatory for a
# standalone executable), give your app's name in APP_NAME
# for instance:
APP_NAME=MyProject

# now, always include $(TOPSRCDIR)/swiftbuild/config.mk
include $(TOPSRCDIR)/swiftbuild/config.mk

# your swift sources should go into SOURCES
# for instance:
SOURCES = foo.swift bar.swift

# if you need to import modules outside of your project
# use IMPORTS to list the paths, of course prepended by -I
# for instance:
IMPORTS =-I /Users/myname/trees/myotherproject/modules/

# if you need some dylibs to build your module or your app,
# then use LD_FLAGS (always +=) and LIBS; for instance:
LDFLAGS += -L/Users/myname/trees/myotherproject/lib
LIBS = -lfooCore

# and finally always include $(TOPSRCDIR)/swiftbuild/rules.mk
include $(TOPSRCDIR)/swiftbuild/rules.mk

And that's it, you're now good to make build, make clean and make clobber. The first one will build everything, your dylibs and app being in $(OBJDIR) at the end of the build while your modules are in $(OBJDIR)/modules. The second one will delete all dylibs, *.o and build remains from your directories but will preserve $(OBJDIR). The last one performs a clean and deletes $(OBJDIR) too.

Let me know if it's useful please. And I'm of course accepting pull requests. Next steps: static linking and build of a complete foo.app OS X application...

“There’s class warfare, all right, but it’s my class, the native class, that’s making war, and we’re winning.” -- Android and iOS, blatantly stolen from Warren Buffet

Firefox OS tried to bring Web apps to the mobile world and it failed. It has been brain dead - for phones - for three days and the tubes preserving its life will be turned off in May 2016. I don't believe at all myself in the IoT space being a savior for Mozilla. There are better and older competitors in that space, companies or projects that bring smaller, faster, cleaner software architectures to IoT where footprint and performance are an even more important issue than in the mobile space. Yes, this is a very fragmented market; no, I'm not sure FirefoxOS can address it and reach the critical mass. In short, I don't believe in it at all.

Maybe it's time to discuss a little bit a curse word here: strategy. What would be a strategy for the near- and long-term future for Mozilla? Of course, what's below remains entirely my own view and I'm sure some readers will find it pure delirium. I don't really mind.

To do that, let's look a little bit at what Mozilla has in hands, and let's confront that and the conclusion drawn from the previous lines: native apps have won, at least for the time being.

• Brains! So many hyper-talented brains at Mozilla!
• Both desktop and mobile knowledge
• An excellent, but officially unmaintained, runtime
• Extremely high expertise on Web Standards and implementation of Web Standards
• Extremely high expertise on JS
• asm.js
• Gaia, that implements a partial GUI stack from html but limited to mobile

We also need to take a look at Mozilla's past. This is not an easy nor pleasant inventory to make but I think it must be done here and to do it, we need to go back as far in time as the Netscape era.

(I hope I did not make too many mistakes in the table above. At least, that's my personal recollection of the events. If you think I made a mistake, please let me know and I'll update the article.)

Let's be clear then: Mozilla really succeeded only three times. First, with Firefox on the desktop. Second, enabling the Add-ons ecosystem for Firefox. Third, with its deals with large search engine providers. Most of the other projects and products were eventually ditched for lack of interest, misunderstanding, time-to-market and many other reasons. Mozilla is desperately looking for a fourth major opportunity, and that opportunity can only extend the success of the first one or be entirely different.

The market constraints I see are the following:

• Native apps have won
• Mozilla's reputation as an embedded solution's provider among manufacturers will probably suffer a bit from Firefox OS for phones' death. BTW, it probably suffers a bit among some employees too...

Given the assets and the skills, I see then only two strategic axes for Moz:

1. Apple must accept third-party rendering engines even if it's necessary to sue Apple.
2. If native apps have won, Web technologies remain the most widely adopted technologies by developers of all kinds and guess what, that's exactly Mozilla's core knowledge! Let's make native apps from Web technos then.

I won't discuss item 1. I'm not a US lawyer and I'm not even a lawyer. But for item 2, here's my idea:

1. If asm.js "provides a model closer to C/C++" (quote from asmjs.org's FAQ), it's still not possible to compile asm.js-based JavaScript into native. I suggest to define a subset of ES2015/2016 that can be compiled to native, for instance through c++, C#, obj-C and Java. I suggest to build the corresponding multi-target compiler. Before telling me it's impossible, please look at Haxe.
2. I suggest to extend the html "dialect" Gaia implements to cross-platform native UI and submit it immediately to Standard bodies. Think Qt's ubiquity. The idea is not to show native-like (or even native) UI inside a browser window... The idea is to directly generate browser-less native UI from a html-based UI language, CSS and JS that can deal with all platform's UI elements. System menus, dock, icons, windows, popups, notifications, drawers, trees, buttons, whatever. Even if compiled, the UI should be DOM-modifyable just like XUL is today.
3. WebComponents are ugly, and Google-centric. So many people think that and so few dare saying it... Implementing them in Gecko acknowledges the power of Gmail and other Google tools but WebComponents remain ugly and make Mozilla a follower. I understand why Firefox needs it. But for my purpose, a simpler and certainly cleaner way to componentize and compile (see item 1) the behaviours of these components to native would be better.
4. Build a cross-platform cross-device html+CSS+JS-based compiler to native apps from the above. Should be dead simple to install and use. A newbie should be able to get a native "Hello World!" native app in minutes from a trivial html document. When a browser's included in the UI, make Gecko (or Servo) the default choice.
5. Have a build farm where such html+CSS+JS are built for all platforms. Sell that service. Mozilla already knows pretty well how to do build farms.

That plan addresses:

• Runtime requests
• Embedding would become almost trivial, and far easier than Chromium Embedded Framework anyway... That will be a huge market opener.
• XUL-less future for Firefox on Desktop and possibly even Thunderbird
• XUL-less future for add-ons
• unique source for web-based app and native app, whatever the platform and the device
• far greater performance on mobile
• A more powerful basis for Gaia's future
• JavaScript is currently always readable through a few tools, from the Console to the JS debugger and app authors don't want that.
• a very powerful basis for Gaming, from html and script
• More market share for Gecko and/or Servo
• New revenue stream.

There are no real competitors here. All other players in that field use a runtime that does not completely compile script to native, or are not based on Web Standards, or they're not really ubiquitous.

I wish the next-generation native source editor, the next-gen native Skype app, the next-gen native text processor, the next-gen native online and offline twitter client, the next native Faecbook app, the next native video or 3D scene editor, etc. could be written in html+CSS+ECMAScript and compiled to native and if they embed a browser, let be it a Mozilla browser if that's allowed by the platform.

As I wrote at the top of this post, you may find the above unfeasible, dead stupid, crazy, arrogant, expensive, whatever. Fine by me. Yes, as a strategy document, that's rather light w/o figures, market studies, cost studies, and so on. Absolutely, totally agreed. Only allow me to think out loud, and please do the same. I do because I care.

Updates:

• E4X added
• update on Jetpack, based on feedback from Laurent Jouanneau
• update on Versioning and ESR, based on feedback from Fabrice Desré (see comments below)
• XULrunner has died...

Clarification: I'm not proposing to do semi-"compilation" of html à la Apache Cordova. I suggest to turn a well chosen subset of ES2015 into really native app and that's entirely different.

Several painful things happened to bluegriffon.org yesterday... In chronological order:

1. during my morning, two users reported that their browser did not let them reach the downloads section of bluegriffon.org without a security warning. I could not see it myself from here, whatever the browser or the platform.
2. during the evening, I could see the warning using Chrome on OS X
3. apparently, and if I believe the "Search Console", Google thought two files in my web repository of releases are infected. I launched a complete verification of the whole web site and ran all the software releases through three anti-virus systems (Sophos, Avast and AVG) and an anti-adware system. Nothing at all to report. No infection, no malware, no adware, nothing.
4. since this was my only option, I deleted the two reported files from my server. Just for the record, the timestamps were unchanged, and I even verified the files were precisely the ones I uploaded in january and april 2012. Yes, 2012... Yesterday, without being touched/modified in any manner during the last four years, they were erroneously reported infected.
5. this morning, Firefox also reports a security warning on most large sections of BlueGriffon.org and its Downloads section. I guess Firefox is also using the Google blacklist. Just for the record, both Spamhaus and CBL have nothing to say about bluegriffon.org...
6. the Google Search Console now reports my site is ok but Firefox still reports it unsecure, ahem.

I need to draw a few conclusions here:

• Google does not tell you how the reported files are unsecure, which is really lame. The online tool they provide to "analyze" a web site did not help at all.
• Since all my antivir/antiadware declared all files in my repo clean, I had absolutely no option but to delete the files that are now missing from my repo
• two reported files in bluegriffon.org/freshmeat/1.4/ and bluegriffon.org/freshmeat/1.5.1/ led to blacklisting of all of bluegriffon.org/freshmeat and that's hundreds of files... Hey guys, we are and you are programmers, right? Sure you can do better than that?
• during more than one day, customers fled from bluegriffon.org because of these security warnings, security warnings I consider as fake reports. Since no public antimalware app could find anything to say about my files, I am suspecting a fake report of human origin. How such a report can reach the blacklist when files are reported safe by four up-to-date antimalware apps and w/o infection information reported to the webmaster is far beyond my understanding.
• blacklists are a tool that can be harmful to businesses if they're not well managed.

Update: oh I and forgot one thing: during the evening, Earthlink.net blacklisted one of the Mail Transport Agents of Dreamhost. Not, my email address, that whole SMTP gateway at Dreamhost... So all my emails to one of my customers bounced and I can't even let her know some crucial information. I suppose thousands at Dreamhost are impacted. I reported the issue to both Earthlink and DH, of course.

Non, rassurez-vous, je n'ai pas l'intention d'en discuter. Perdre du temps à causer d'une telle stupidité, d'une telle preuve non seulement d'incompétence crasse mais également d'arrogance lamentable (par défaut d'interrogation des spécialistes) de nos politiques ne serait même pas drôle. Quelle honte.

Ce qui est hilarant par contre, c'est cette issue sur github. Une vraie perle Faites-vous du bien en ce lundi matin, et faites mieux qu'une pause café, faites une pause lecture. Rire garanti

Let's suppose you have a rather long document, for instance a book chapter, and you want to render it in your browser à la iBooks/Kindle. That's rather easy with just a dash of CSS:

body {
height: calc(100vh - 24px);
column-width: 45vw;
overflow: hidden;
margin-left: calc(-50vw * attr(currentpage integer));
}

Yes, yes, I know that no browser implements that attr()extended syntax. So put an inline style on your body for margin-left: calc(-50vw * <n>) where <n> is the page number you want minus 1.

Then add the fixed positioned controls you need to let user change page, plus gesture detection. Add a transition on margin-left to make it nicer. Done. Works perfectly in Firefox, Safari, Chrome and Opera. I don't have a Windows box handy so I can't test on Edge.

Alors que l'opacité des tarifs des envois de colis à La Poste a fait l'objet de plusieurs brèves récemment, le consommateur non-attentif, qu'il soit particulier ou professionnel, vient de se faire entuber à sec par La Poste en guise de vœux de bonne année pour 2016...

Le tarif « entre 20 et 50g » pour les lettres vertes, lettre prioritaires et ecoplis à été supprimé :

Bref, une lettre verte de 21 grammes qui coûtait 1,15€ à affranchir passe à 1,40€. Soit 21,8% d'augmentation, excusez du peu. Pour la lettre prioritaire de même poids, on est à 28% pile d'augmentation ! Mais le plus fort, c'est l'ECOpli de 21 grammes qui prend tout bonnement 29,5% d'augmentation.

Là où c'est encore plus vicelard, c'est que les entreprises ne sont pas soumises à ces mêmes règles. Mais La Poste étant ce qu'elle est, c'est-à-dire gérée par des énarques qui oublient non pas le service du public mais le Service Public, pas toutes les entreprises : le tarif de 20 à 50 grammes est maintenu pour les entreprises qui louent une machine à affranchir, les autres utilisant des timbres tombant dans le régime général. Bref, petites entreprises à peu de courrier, baisées comptez-vous.

Je trouve tout cela scandaleux. L'augmentation tout d'abord est lamentable vu ses taux. La distortion entre entreprises et particuliers ensuite. La distortion entre entreprises disposant de machines à affranchir d'une part et celles qui n'en ont pas d'autre part. Je m'interroge fortement sur la légalité de ce dispositif, et me demande comment nos politiques ont pu autoriser une telle augmentation des tarifs.

Bonne année 2016, signé La Poste, qui ne fournit pas le lubrifiant avec.