SublimeText and EditorConfig and eclint

Following some of all the cool developers on twitter, GitHub, blogs etc. I fell over EditorConfig. The homepage of the project boldly stated:

EditorConfig helps developers define and maintain consistent coding styles between different editors and IDEs. The EditorConfig project consists of a file format for defining coding styles and a collection of text editor plugins that enable editors to read the file format and adhere to defined styles. EditorConfig files are easily readable and they work nicely with version control systems.

I primarily use perltidy for my Perl projects and I have used other pretty printers in the past, so I understood what it wanted to do, but it seemed so general it did not really bring any value, not being able to replace perltidy or similar, so I disregarded it as a fad.

Anyway EditorConfig kept popping up in the projects I was looking at so I decided to give it a second chance. I am not doing a lot of projects with a lot of different languages involved, but all projects does contain some source code, possibly some Markdown and some other files in common formats etc.

The formatting capabilities of EditorConfig are pretty basic, since it does not go into deep formatting details for all the languages out there, which would also be incredibly ambitious, but basic formatting like indentation size and format, encoding, EOL and EOF style. This seemed pretty useful for the files where I could not control format using perltidy, so it would be a welcome extension to my toolbox.

Luckily a prolific Github contributor Sindre Sorhus had implemented a plugin for SublimeText (my current editor of choice). So I installed the plugin and got it configured for some of my projects and started using it.

Apart from the editor part you simply place a configuration file in your project named: .editorconfig, configure it to handle the languages contained in you project and you are good to go.

The problem, well not really a problem, but common misunderstanding is that it reformats ALL your code. It does NOT. It only works on newly added lines. At first you might be disappointed, but just opening your editor with an active plugin should not mean that all your code has to be recommitted with extensive diffs confusing everybody (and yourself) – so this is actually a reasonable constraint.

Anyway at some point, you might want to reformat everything, to get a common baseline. Here eclint can help you, eclint is available on Github. eclint can both work as a linter, meaning it checks your adherence to the configuration (editorconfig) specified, but it can also apply it.


$ eclint check yourfile


$ eclint fix yourfile

EditorConfig can help you keep you own formatting consistent for some of the more esoteric file formats and when contributing to other peoples projects, you do not have to go back and forth over formatting issues, well you might, but the EditorConfig controllable parts will be aligned. Check the website and read up on integration with your editor of choice.

eclint can help you establish a formatting baseline for your own projects, but do read the documentation and do not mix it up with your regular development or yak-shaving, since you could face large diffs.

Happy formatting,


SublimeText and EditorConfig and eclint

GOTO Copenhagen 2017

The Copenhagen edition of the GOTO conference have come to an end. I was able to attend 2 of the 3 days scheduled. I decided beforehand not to sign up for any tutorials since I new it would be difficult to take so much time away from work assignments. As anticipated I ended up having to skip the Tuesday sessions due to work priorities and constraints. I am glad that the conference is in Copenhagen, but perhaps going abroad would mean less interference, then again I would probably be caught in some hotel room doing Skype sessions.

When it it comes to conference attending and the like and taking time off to go to these things, network and reflect and learn. I find this incredibly important and I used to do it a lot more. At the same time I find it important to hold a balance between obtaining these stimuli and possibly executing on them, by applying newly learned techniques, tools and practices to your daily work. On the other hand often daily work seems to follow into certain almost static routines and die hard practices, if not scrutinised and challenged. In addition it would be awesome if you could set aside time to experiment with all the stuff you cannot squeeze into your daily work routine.

Now on to the actual content I will try to give a brief overview of my observations from the conference based on the notes I jotted down. I will not attempt to give a complete account, but some of the more interesting things will be mentioned. I encourage you to checkout the GOTO Play app if you want to watch the videos of the actual talks and most of them will probably make it to Youtube at some point in the future.

First talk I attended was entitled “SCRUM vs. SAFE”, an interesting talk based in yet another method SAFE, which attempts to address some of the short comings in SCRUM adaptation. Such as running siloed SCRUM in agile teams in a waterfall organisation etc. Tomas Eilsø the presenter gave an entertaining presentation with some good examples, so even though it was a method talk, it was not textbook excerpts, but based on Tomas experiences as a fighter pilot. The talk drew parallels to military decentralisation. The presentation also touched topics like, building a environment of trust, using cross-checks to stay safe and sharing of mental models. Indeed a great talks with lots of good points even if you are not into SCRUM or SAFE.

One of the really interesting take aways was the OODA loop, invented by John Boyd –  Observation-Orientation-Decision-Action loop or cycle. Which might be interesting in a agile setup for software development and business.

Mark Seeman (@ploeh) gave an excellent talk with the weird title “Pits of Success”. I have been following Mark for some time and even though he works in areas quite different from mine, meaning functional programming and F#, his presentation was awesome, entertaining and insightful. The presentation contained some very nice animations related to the title, be sure to watch the talk if you are intrigued.

The last presentation of that day was on a product named HoverFly and the importance of being able to test an API-driven architecture. HoverFly is a sort of trainable proxy, which can emulate APIs after training. The concept is pretty basic and has been seen before, but it still interested me, since we use a similar pattern in our system, but without the training part, meaning that emulating e.g. 3rd. party APIs is hard work. I plan to spend some more time evaluating HoverFly, to assert whether it could leverage our work in this area.

As mentioned earlier I had to skip the second day, so I have no notes on the talks from Monday.

The last day started out with Adrian Cockroft from Amazon, he is the Chief Cloud Strategist and holds an incredible string resume. He talked about cloud trends of course well founded in AWS, but still with good reflections on the role of cloud, the issues of going into the cloud, primarily the benefits, but also mentioning some of the classical computer problem, which seem to resurface, when new paradigmes, technologies and trends emerge. One could argue that Adrians talk was somewhat a sales pitch, like the HoverFly presentation, but well I did not mind, since the presenters all reflected and provided general insight in their respective topics.

Vijay Reddy from Google gave a presentation on Google Cloud and TensorFlow, much in the same ballgame as the other talks I just mentioned, but again also with a lot of good information and a live demonstration.

A completely different kind of talk was, it was much more theoretical and for me hard to follow, but it was nice with a sort of counter weight to the more concrete, pragmatic presentation. This talk quite philosophical and for me quite hard to follow. But some of the key points even sank in, in my thick skull.

The talks will all make it to Youtube at some point so keep an eye on the GOTO Youtube channel.

As always GOTO was inspiring, provocative, educational and a complete information overload. Now I will try to see how much of the accumulated information I will be able to convert into something actionable, there most certainly was a lot to reflect on.

GOTO Copenhagen 2017

CPANday 2017

CPANday 2017 is over.

This year I remembered CPANday, after a tweet from @neilbowers pointing to a blog post on CPANday 2017, I even jotted it into my calendar all in due time and promised myself I would contribute something.

As CPANday came closer I still had no plans on what to contribute or what to work on. At the same time my workload at work was immense, having CPANday clashing with a sprint ending and a project deadline.

After a whole day of refactoring a test suite for a service/application, I came home late and was about to give up on the idea of contributing anything at all. I had some candidates, but I was too tired to take on something big or overly complex (or so I thought). I considered what could be low hanging fruit and decided to take a look at my Github issues, to see if anything stood out.

An issue with one of the dependencies I use looked interesting, but still perhaps, not something I could do anything about – I guess my weariness, got the better of me and I just dug in.

The issue was related to my CPAN distribution Date::Holidays and problems building Date::Holidays::CN. Date::Holidays::CN depends on DateTime::Astro, which seemed to be the culprit, I took a look at the issue list for DateTime::Astro and located two RTs:


The first one seemed quite easy and as pretty low hanging fruit, so after consulting the documentation of Module::Install, I got the build script improved and sent my first PR.

Completely fired up by this quick fix I decided to take a look at the remaining issue.

This required some more debugging, but luckily the issue reporter had given a good hint on how to demonstrate the error using Time::Fake.

$ env PERL5OPT=-MTime::Fake=$(date --date="2016-08-31 12:00:00" +%s) \
prove -b t/006_solar_longitude.t

I had some problems with the date command running on MacOS and I was too tired to get my head around the man page. In order to mimic the example from the issue report.

So I made my own example, calculating the number of days until the end of the month (15 on CPANday).

$ env PERL5OPT=-MTime::Fake=+15d prove --lib -b \ 

When I was able to reproduce the error, I did some debugging and found out that the construction of a DateTime object failed, due to the fact that the date parameters were illegal (well the error output actually stated this).

After some thinking and useless experimentation it struck me that the construction was sequential, so I reordered the parameters so the day would be before the month, so we would not be altering the default object (based on the current day) so it could be a invalid date. This resulted in my second PR.

All in all a good CPAN day, short, but effective. My PRs got accepted and a new release of DateTime::Astro is now available on CPAN.

I never thought I would be able to contribute anything, so I was quite impressed with myself and my accomplishments. I even picked up a few new tricks, like Time::Fake.

I still have no idea why DateTime::Astro is needed, but it does not really matter, since the issues were a SMOP.

Now I am just looking forward to CPANday 2018.

jonasbn, Copenhagen

CPANday 2017

Test::Timer Release 2.00

Received some feedback on release 1.00 of Test::Timer, this has resulted in further improvements and release 2.00.

The diagnostics of failing tests using Test::Timer, now also presents the actual execution time observed.

Next goal of the next feature release, is to handle higher resolution than seconds. In the mean time a release with improved documentation is planned to go out.

Until next Timer – release, take care


Test::Timer Release 2.00

Date::Holidays 1.06 Release

I have uploaded a maintenance release of Date::Holidays to CPAN.

I am planning a lot of activities in relation to Date::Holidays (more on this is an upcoming blog post).

For now I have added a lot of tests of some of all the modules that Date::Holidays has adapters for and some which have not been evaluated completely yet. I am trying to get an overview of the actual status of Date::Holidays and related modules in order to plan further progress.

A part of the larger plan, is the introduction of a proper homepage. So just as for Test::Timer, Date:.Holidays now has a more appropriate representation on the web build using Github pages (also described in a blog post).

So more activity will follow in relation to Date::Holidays – I just need to flesh out the details and the plan.

Take care,


Date::Holidays 1.06 Release

Test::Timer Release 1.00

Yesterday while sitting at the computer working on a release Workflow I received a Github issue.

Test::Timer is a Perl test module that can assist in specifying timing thresholds for code execution. You can then specify that your test suite should break if the code takes too little or too much time.

The concept requested was simple, in the diagnostic messages emitted from the module, the thresholds specified should be mentioned. The implementation did not take long to implement.

However since the diagnostic messages was changed and somebody might be relying on these I decided to make it a major release to indicate this somewhat breaking change.

Thanks to Nigel Horne for the issue report I hope the implementation meets your needs and expectations.

Test::Timer 1.00 has been uploaded to CPAN, feedback most welcome.

Have a nice weekend,


Test::Timer Release 1.00