Morpheus - ultimate configuration engine

As I promised, here are the slides from my talk this morning at Saint Perl-2 in Saint-Petersburg, Russia.

I believe Morpheus can be very useful for the community and hope that it'll become widely adopted.
There are still a lot of things which can be added, but conceptually we are on the right track.

These slides probably suck (I wrote them in the last moment and didn't put enough details in some places), but putting code out in the wild and getting feedback is more important by now.

One more thing, if you're going to check out PODs in next few days, see them on github instead of CPAN. There are much more of them added in 0.36 release, which is not uploaded to CPAN yet.

UPD: Just found out that 0.36 release docs can be viewed here: http://search.cpan.org/~mmcleric/Morpheus-0.36/
Morpheus::Key, Morpheus::Bootstrap and Morpheus::Plugin::Content PODs are worth to be looking at, if you are interested in implementation detals.

9 Comments

Nice, but please distribute this under the Config namespace. Creating unnecessary top-level namespaces is almost as annoying as ruby-like "cutesy" names.

Yes, they are, especially "Moose" and "Starman," which are cute without conveying any information. I don't care about using up our "precious and non-renewable top-level namespace resources," but a cute name makes your module harder to find, and makes it harder to line up all the various reinventions of the configuration wheel.

For what it's worth, the top level name thing doesn't bother me at all. CPAN namespacing is a pretty loose taxonomy and it probably doesn't really help with organization or finding things so much.

I'm more concerned that when I saw this pop up on CPAN when I glanced through the docs and synopsis example, as compared to the presentation linked above, I had a very different understanding of the project. Maybe you shouldn't promote the symbol importer so heavily, since glancing threw it that's all I saw and all I thought it was.

john

I usually giggle at unintuitively-named modules and then ignore them, like I first did with Moose. When they become popular, I take a second look. But if enough people behave the same, you lose potential momentum. Any traditionally-name module, however, I take seriously and look at the docs, as well as look at the list of other modules the author has written. Unless the project is well-known, the module name should be self-documenting, i.e. it should fall under a namespace. I don't want to have to explain to my coworkers why I'm using some new module named Remulak or Thong or Neptune, etc.

For what it's worth - I named WebNano WebNano - so that it can be googled for, but Google improved much since last time I checked - and for example Web::Simple is first result when searching for it.

Leave a comment

About Vyacheslav Matyukhin

user-pic I wrote Ubic. I worked at Yandex for many years, and now i'm building my own startup questhub.io (formerly PlayPerl). I'm also working on Flux, streaming data processing framework. CPAN ID: MMCLERIC.