Changes and CPAN, CPAN::Changes and my Changes

Following up on the comments to my blog post on CPAN::Changes and CPAN::Changes::Spec, I created a fork of the distribution on Github and implemented a first shot for the author to evaluate. I sent the pull request yesterday, so now it will be interesting see whether it will be found useful at all.

I did a lot of thinking before starting the actual coding and I was not quite satisfied with the vocabulary I was using to describe the concept. Originally I referred to the concept as impact pointer, but it is simply misleading and not particularly descriptive. So when it occurred to me that the concept was actually hints on how the reader should view the changes and release described it came to me that the obvious name should be “update hint”.

Hints are everywhere and is the term is highly popular these days. Hints are less intrusive and in this case a much better description.

Here is an example lifted from the POD.

0.03 2010−08−01 − update recommended

− Fixed serious bug in bar method

0.02 2009−07−17 − update not required

− Added more foo() tests

0.01 2009−07−16

− Initial release

I decided for two values of the hint:

        - update recommended
        - update not required

The first for for releases, which address serious issues/bugs like security fixes, memory leaks etc. the second for releases which are housekeeping releases, updates to tests, documentation, build scripts etc.

As you can see there is no hint for the initial release. I do not want to impose my proposal on the existing specification as such and I well let it be up to the maintainer to decide whether it should be optional and what the actual values should be, my proposal works, but it just a proof of concept and in my opinion it is a nice concept I hope will be adopted.

Please feel free to evaluate my proposal for update hints in the CPAN::Changes::Spec and let me know what you think.

jonasbn, Copenhagen/Denmark

Changes and CPAN, CPAN::Changes and my Changes

Sublime Text and Perl

I have been using the Sublime Text 2 editor for some time now. Editors are a funny thing and over the years I have used quite a few different ones: pico, vi, vim, jEdit, BBEdit, TextMate, Komodo IDE and now Sublime Text. I like to have an armory of editors in my toolbox for different kinds of things. An editor for basic fast (right now) text editing, one for longer coding sessions and one for project development with several files of different types.

For a long time I was using a combination of Vim, BBEdit/TextMate and Komodo IDE for the different coding assignments under the circumstances I mentioned above. I later exchanged BBEdit for TextMate at some point and when I got CLI integration running for TextMate I slowly stopped using Vim. I still use the Komodo IDE, since the graphical debugger is a magnificent tool, one I simply cannot live without, but Komodo has longer startup time and is not well suited for short tasks unfortunately.

Hearing all the (b|f)uzz about Sublime Text intrigued me and made me want to check it out. I have read quite a few blog posts and I have watched several video tutorials – and they all say that when you start with Sublime Text you will not want to go back – yeah right!

I must however admit that I am impressed, the editor is flexible, easy to use, incredibly fast and responsive and it is really, really, really easy to customize.

Editors are the primary tool of most developers. Often we spend more time in editors editing code, than we actually do compiling or translating the actual source code. There are many opinions on editors, most developers have a favorite and in addition an opinion on the other developers favorite. Some are quite religious about their editor and mocking or talking about the other editors is not uncommon and most of you already know the funny diagram depicting learning curves for the most “popular” editors.

pastedgraphic-2014-03-1-13-18.png
Ref: http://unix.stackexchange.com/questions/986/what-are-the-pros-and-cons-of-vim-and-emacs

The depiction is funny, but as it is with most satiric fun, it comes with a grain of truth. I am not going to dig more into the above visualization since I will not attempt to visualize the learning curve of Sublime Text and because my opinion would be subjective and not as funny as the above examples, which I guess are all created with great love/hate to the editors mentioned. I think I can take liberty of writing love/hate since it is with most things you love you really hate when they let you down.

Getting back to Sublime Text I can only say that the editor is growing on me and I do not love it as such and it was not love at first sight since I actually just thought that it was just another editor, but Sublime Text continues to impress me and I feel like it gets better the more I use it and really feels like the editor for me. I do spend time coding, not as much as I would like to, since I am also using the Microsoft Word (editor) for a large part of my work, but luckily I get to do some coding and if not at work then at least when I am not at work.

When watching some Youtube tutorials I fell over the concept of Zen Coding, this was the idea of being able to write code with as few key stroke as possible (not like Perl golf), but getting productivity and speed up utilizing and maximizing you and your editors coding/typing capabilities. The demo for Sublime Text for HTML markup was really impressive and it got me thinking.

Sublime Text has a nice Perl integration, syntax highlighting, it builtin auto-completion can get you a long way and you can install plugins for integration with Perltidy and the plugin SublimeCodeIntel will extend this even further.

Inspired by the Zen Coding demonstration I thought CPAN has a log of APIs, so what would be the most useful ones to play around with for creating cool snippets for speeding up my Perl coding and then it occurred to me, that the modules and APIs I actually use the most are for implementing unit tests using Test::More and Test::Class, I do this across all my distributions and projects and both at home and at work.

So here is my first shot at snippets for Test::More and Test::Class available on Github for you to use with Sublime Text or fork you can fork them to suit your own needs. I am working on getting them made available via SublimeTexts Package control, which requires a pull request to a central repository of metadata, where I am still waiting for approval.

If you are in a situation where you feel like trying out a new editor, checkout Sublime Text, I have only tried version 2 and there is a version 3 on the way, I will not say that “it will not make you want to go back”, since my history of editors is long and proves the opposite and I expect it will continue to evolve, but I can promise you that it will be both fun and inspiring as you discover the nifty features and niceties which gives the sublime in Sublime Text.

Happy coding,

jonasbn, Copenhagen/Denmark

Sublime Text and Perl