New blog

I have a new blog. It is ready. It will be deployed over the coming days. You should see it at this address pretty soon. If you can’t wait, you can head to http://lionelmontrieux.com, where it is already available.

If you use the RSS, you may have to update it. The Atom feed should hopefully still work properly.

See you soon!

Edit: the blog is being deployed on http://lionelmontrieux.com at the moment, so errors and issues are likely for a while. That’s why I deployed on a little-used domain first.

BiFlux-mode: an Emacs major mode for BiFlux

I have recently been playing around with BiFlux, a language to express bidirectional transformations of XML documents developed at NII, Japan. The language is great, because it is a much simpler alternative to GRoundTram, also from NII. But what are bidirectional transformations, I hear you ask?

Well, conveniently, there is a Wikipedia page on the subject on bidirectional transformations. Granted, it isn’t the most detailed page on Wikipedia, but contributions are, I suppose, more than welcome. And it still gives a pretty good idea of what a bidirectional transformation is. In particular, the following paragraph about lens languages is key to understanding what BiFlux does:

More general is a lens language, in which there is a distinguished forward direction (“get”) that takes a concrete input to an abstract output, discarding some information in the process: the concrete state includes all the information that is in the abstract state, and usually some more. The backward direction (“put”) takes a concrete state and an abstract state and computes a new concrete state. Lenses are required to obey certain conditions to ensure sensible behaviour.

[Wikipedia]

So, in short, BiFlux allows you to write “put” in a language that looks a lot like SQL, and to have “get” generated for free. This means that, under certain circumstances, one can easily generate a bidirectional transformation between two XML DTDs.

It happens that my favourite text editor is Emacs (what else, really?). As there was no support for BiFlux in Emacs, I decided to create a major mode for it, to help myself and others when writing code for BiFlux. I like Emacs a lot, but I have never written a major mode – or anything really – in Emacs Lisp before. I am a complete Emacs Lisp rookie, and I’m learning as I go.

Currently, the mode supports some level of syntax highlighting, which already makes my life easier, and that’s about it. In the near future, I’d like to complete the syntax highlighting, and to add commands for compiling the bidirectional transformations.

The code for biflux-mode is available on github, under the Apache 2 license. Any help is more than welcome, as I am nowhere near an Emacs Lisp expert. I will probably post more about biflux-mode as it gets new features.

New SSL certificate

For a while now, I have been using an SSL certificate signed by CAcert.org for this blog. CAcert.org is a community-owned certificate authority, that can issue free certificates to the public. However, its root certificate is not included in the most common browsers, which makes CAcert.org -signed certificate significantly less useful. Furthermore, my certificate had long expired, but I had been too busy (or too lazy?) to take the time to renew it…

Until now. I took the opportunity to switch to a certificate authority whose root certificate is bundled with major browsers, so hopefully, readers will not see any scary warnings anymore when reading this blog over https. And since that issue was solved, I have also switched the entire website to https for everyone. If you encounter issues, please do let me know!

One day, I might even update the photos in the header, and replace them by some that I took myself. But that’s something else entirely.

Google Announces Project Zero

From Google’s online security blog:

Security is a top priority for Google. […] We’re hiring the best practically-minded security researchers and contributing 100% of their time toward improving security across the Internet.

[…]

Every bug we discover will be filed in an external database. We will only report bugs to the software’s vendor—and no third parties. Once the bug report becomes public (typically once a patch is available), you’ll be able to monitor vendor time-to-fix performance, see any discussion about exploitability, and view historical exploits and crash traces. We also commit to sending bug reports to vendors in as close to real-time as possible, and to working with them to get fixes to users in a reasonable time.

This is good news. However, what will be Project Zero’s policy in case a vendor decides to simply ignore bug reports, and refuses to patch their software? Will the vulnerability be published after a certain amount of time has lapsed?

Anyway, as the database of (presumably fixed) bugs grows, it will undoubtedly offer opportunities for security researchers to better understand and improve methods and processes for dealing with vulnerabilities.

Back from Code Generation 2014

Last Friday evening, I came home after three days in sunny Cambridge, where I had the pleasure to give a talk at Code Generation 2014. This is a very quick summary of my impressions.

Code Generation is a three-days, industry-focused conference about all things related to Model-Driven Engineering (MDE). I attended Code Generation for the first time two (or was it three?) years ago, and last week’s edition was my second visit. I enjoyed it much more than the first edition I attended, but this may have to do with the fact that, this time, I was staying in Cambridge instead of commuting, and therefore got to attend the social events – a very important part of any conference.

I went to Code Generation with the objective of finding out what the software industry is working on in relation with MDE, and to find out what the current hot topics, as well as the current issues, are. It was quite interesting to compare my findings to the previous edition I attended. This year, I had the impression that DSLs were less of a hot topic than they were a couple of years ago. Although they still are a key part of the discussions, they aren’t discussed so comprehensively anymore – perhaps because progress in that area means that they are better understood and very much taken for granted, but perhaps also because of the (very much noticed) absence of Xtext developers.

Punting on the river Cam

Punting on the river Cam

Some new topics have emerged: the cloud, and the concept of “citizen developers”. MDE and the cloud has been extensively discussed, in keynotes as well as in regular sessions, and from a variety of perspectives: online DSL editors, code generation as a service, etc. Citizen developers, on the other hand, is a term that came out quite a lot. I never heard of it before, so it came as a bit of a surprise for me. Gartner defines it as follows:

citizen developer is a user who creates new business applications for consumption by others using development and runtime environments sanctioned by corporate IT.

Much of the discussions, both during the talks and around coffee, food and beer, focused on how to design DSLs and, more generally, environments that allow citizen developers to write software within a somewhat constrained environment – some of the discussions were also mentioning cloud computing. But there were also discussions about whether it is indeed a good thing or not. Arguments in favour of citizen developers mainly cite the shortage of “qualified” software engineers, and the (actual or perceived) slow reaction time of IT departments. Those in favour argue that allowing citizen developers to write their own applications speeds up development time and reduces the workload of the IT department, which can presumably redirect its resources to critical systems – and the infrastructures to support the citizen developers’ environment. On the other hand, those opposed to citizen developers put forward their lack of training, resulting in suboptimal, poorly tested and potentially harmful software. They also worry about the difficulty to centralise or communicate knowledge, as well as the maintenance nightmare that may result from a variety of applications with uncontrolled dependencies. Historically, “citizen developers” would be developing macros in MS Excel or small applications in MS Access. Nowadays, cloud platforms propose to replace those tools, allowing users to create and share their own apps, but hopefully with more control over dependencies, versioning and security from an IT department.

CG2014 dinner in a Japanese restaurant

CG2014 dinner in a Japanese restaurant

Most of the talks I attended were very interesting. Setting aside the one or two sessions that, in my opinion, felt a bit too much like sales pitches, the rest was of very high quality. Some of them were filmed, and hopefully the videos will be available in the near future. My own talk was about rbacDSL, how it works, and what sort of research we have done and carry on doing using it. I posted my slides online for everyone to see, and I still welcome questions, comments, suggestions and other enquiries.

The conference closed on a panel session lead by Andrew Watson from OMG, asking the four panelists the following question (from memory): “Model-Driven Engineering: for the masses, or for the elite?”. Discussions were of course connected to the citizen developers’ issue, but another point of discussion was how to convince software engineers that MDE, when done correctly, is a good thing. Agile was mentioned, sometimes to point out that, contrary to popular belief, it isn’t necessarily incompatible with MDE, just like using MDE does not necessarily mean following the waterfall development model. I may eventually write a more detailed summary of the panel discussion, which in my opinion was one of the highlights of the conference.

Between two talks

Between two talks

Last but not least, I should add that perhaps the most important part of the conference happened over lunch, dinner and coffee breaks. Discussing with people from various places, backgrounds and interests is incredibly motivating, and hopefully gave me a better understanding of the current issues and challenges of MDE in practice.

rbacDSL at CodeGeneration 2014

This Wednesday, I will be talking about rbacDSL at Code Generation 2014, in Cambridge (UK, not MA). I will give an overview of rbacDSL’s features as well as an interactive demo, where the audience may be asked to… participate. Scary, I know. But I won’t bite.

In a nutshell, rbacDSL is a Domain-Specific Language for writing RBAC policies, and ensuring that they conform to some authorisation requirements. It produces XACML policies that conform to the RBAC profile for XACML, which you can then use with the XACML evaluation engine of your choice.

If time allows, I may also discuss future research directions that may be of interest to the audience, revolving around ‘dynamic access control’.

I would be very happy to talk to anyone willing to give rbacDSL a try or evaluate it in any way – and of course, bug reports and feature suggestions are more than welcome – as well as contributions!

As I write these lines, it seems that registration is still open for CG2014, so it isn’t too late to join!

XACDL, a DSL for XACML

Last week, I found myself having to write a lot of XACML policies and XACML requests at work, for a new project I am working on. I quickly found out that writing XACML by hand is dull, boring, and error-prone. This is hardly surprising, given that XACML policies and requests are XML documents.

I had a very quick look around, and while I found some XACML policy editors, such as the one included in WSO2 Identity Server, I couldn’t find anything that would make my life easier when writing XACML requests. Well, I could always use an existing PEP implementation and somehow capture the generated requests, but it’s a bit overkill for what I need to do.

So I decided to create my own DSL. I started Xtext, and quickly put together a simple language for XACML requests that will compile into (hopefully) correct XML. Nothing fancy for now – it really only does what I need it to do, does not support the complete XACML specification, and makes strong assumptions – at the moment, all attributes are Strings, for example.

Still, it is quite useful, at least to me, so I created a repository on Github to host it. I released it under GPLv3, and all contributions as well as suggestions are more than welcome. There is also a website for XACDL hosted on Github, that may or may not eventually contain more information about the language (website contributions are welcome too).

Before the first release (0.1, I guess) I’d like to add support for attribute types, and have an initial support for writing policies as well as requests. I’ll post updates on this blog as I keep improving the language.