I have mentioned before how much I like CPANtesters! Here is another story.
Yesterday I got an email from them listing a number of failures from Galileo, my CMS. I had recently pushed some bugfix releases, but it had some new, and as yet unused code and tests for that code in it. The tests passed on all my Linux systems, so I wasn’t worried about the release. Yet the failures came in. Some on Linux, some on other platforms, but not all the tests were failures and I couldn’t figure out a pattern. CPANtesters put me on to a problem but for this I needed faster results.
I've spent the last year or so of my daily commute building a social bookmarking site that for me has now replaced my use of delicious, and I think offers more than other services such as diigo, Google Bookmarks et al.
The original site at bkmrx.com was mainly built in PHP & MySQL, however since finishing that site I've taught myself how to use Mojolicious, and did a fairly comprehensive rewrite of the website into a Mojolicious and MongoDB stack. As such it's not a full replication of the features available on bkmrx.com (see the about page for a comparison).
Now with a new job on the horizon, I want to spend less time on building out a better bookmarking service, but at the same time don't want it to stagnate.
To that end, I've released the code for bkmrx.org on Github, and uploaded a live version of the site at bkmrx.org.
This is the first time I've released a relatively big project onto Github and since I'm by no means a full time developer, go easy on me :) However I'm hoping there are others in the Perl community who might be interested in contributing to, forking or otherwise using the code.
You can read more details on my blog if you're interested.
I like writing code. I like writing tests. I don't like:
Trying to figure out where the tests are
Writing boilerplate
Finding yet another package without tests
That last one is particularly vexing when you discover that your code is failing because another package doesn't load, but it doesn't have tests. So I fixed that.
Some of what follows is a repeat of things written in previous posts, but it's important enough that it bears repeating.
Best of all, the talk itself was written in Mojolicious! As Joel was talking, he was able to edit the code and display the results, showing off various features of Mojolicious like:
Websockets
Easy testing (even of websockets)
Helper scripts
Mojo templates
There are quite a few interesting parts of Mojolicious that make it worth giving a look to, and I hope to be able to do so with some web projects that have been sitting in my queue for a while (I wrote a nice ticket tracker with AngularJS, but the backend is Python, I'd like to fix that glaring mistake).
Today I was quite busy $working. I was a bit tired, too, because a group of young and cheerful boys and girls (possible future Perl hackers?) had their small hotel party on the floor outside my room. After a short bicycle ride (numerous places of interest again) I reached the Betahaus (many current Perl hackers).
Just because I was curious I took a peek at various fellow Perler's computers displays. Quite familiarly with hacker's displays there was lots of text; not a small amount white on black.
Today however I learned that there are people using light-blue to dark-blue on black as their favourite colour scheme. Like so:
Perl projects have all manner of ways of declaring their dependencies. CPAN releases usually include a file called META.yml or META.json listing their dependencies (though Makefile.PL or Build.PL is also supposed to generate a list of dependencies when it runs; this allows the release to dynamically decide on different dependencies based on the machine it's running on). Non-CPAN projects can declare their CPAN dependencies using cpanfile too.
Once the dependencies are declared, this information is used by CPAN clients, by metacpan.org (to show the list of a release's dependencies), by http://deps.cpantesters.org/ and so on.
However, this only works where you want to declare dependencies on CPAN modules, or on a minimum version of Perl itself.
To help CPAN authors keep track of who is using their modules,
we could introduce two concepts: "follow module" and "I'm using this module".
Both would be similar to the 'following' and +1 features found
in nearly all social media services, and ++ in MetaCPAN.
Templating Modules are a bit like editors. Every web application developer has a favourite one. And every template system is someone's favorite.
Mine is Mason. But not because the Perl MVC tutorials are full of examples using Mason. Not because it's the fastest (use xSlate if you want to trade speed for flexibility). Not because it's the most popular. It's my favourite for a very plain reason: It makes me more productive and allows me to develop web GUIs using all the powerful features a programmer should biterly miss if they are taken away. That includes writing Perl code :P
I never heard of a business that went down because they didn't have fast enough CPUs, so I'm not fussy about trading a few CPU cycles for elegance, ease and speed of development.
Yesterday evening I got onto the CityNightLine and spent a most comfortable night in my small single cabin, sleeping to the soft rocking of the moving train.
After arriving in a freezing cold Berlin I rode my bike along Brandenburger Tor, Checkpoint Charly and a dozen other places of interest to the Betahaus where the Workshop takes place.
Thanks to the organisers, I immediately saw many signposts which guided me to the venue.
I love browsing and/or buying books on Amazon.com. Part of the reason is that there are no lack of ratings/reviews on the books, helping me decide on which books to choose on a certain topic. On CPAN however, despite cpanratings.perl.org having been online for more than a decade, most modules have no reviews.
I've done my share of commenting/reviewing modules, but some things could be improved.
First, whenever some other modules are mentioned in a review, it should perhaps be shown as reviews/mentions for that module. For example, just minutes ago I added four reviews each for Text::ASCIITable::TW, Text::CharWidth, Text::VisualWidth, and Text::VisualWidth::PP. Basically I just wanted to say that Text::CharWidth is my preferred way. I should've been able to enter just one review article, which mentions all 4 modules, which cpanratings could show for all those 4 modules.
Second, there should perhaps be an indexing service to index blog/web articles which mention Perl modules. Neil's articles, for example. All in all, those articles could translate to hundreds of module reviews/comments.
this is my first post here. I never thought about blogging here, because i just didn't felt to do so. But the last weeks made me to think over this.
More and more i read negative stuff about Perl coming from the people using Perl. This irritates me. On the one side, i think it's a good characteristic to be critical about what you use, what you love and the tools you use. On the other side, i don't really understand why we keep to propagate the bad things about Perl and the economy around it all the time here in public?
If we wanted to attract new programmers to do some Perl coding, they probably don't want to read about all the quirks that exist. They want to read about cool stuff thats possible with Perl, success stories and the like.
So i would love to read more entries which are written in a more positive way than always complaining about stuff that doesn't work.
This is an attempt to succinctly list all the different problems perceived with CPAN, and give them a name. No attempt at proposing solutions, or structuring a taxonomy / priority list, but data gathering.
Suppose we use books as analogies for Perl (CPAN) modules.
Do we want CPAN to be some sort of an ISBN authority, where we merely dole out namespaces and unique IDs? There should be no requirements of content or any editorial activity on the modules. We should not discourage (nor encourage?) experimental modules or implemetations, modules for personal or semi-private use, etc.
Do we want CPAN to be some sort of a publisher? There would be some editors in charge to determine which modules are worthy of publishing and which are not (yet). The question is, who? There can hardly be a consensus and "CPAN publisher" will be forked into several publishers with differing guidelines/missions. Not that forking is a bad thing.
Do we want CPAN to be some sort of a bookstore? Where we can browse for modules or do comparison shopping, see buyer's ratings, and finally check out and bring some modules home.
Do we want CPAN to be some sort of a public library?
Do we want CPAN to be some sort of a personal library? Where we display our favorite collections for others to see?
Tong Sun, a user of GraphViz2, has drawn my attention to the test database Chinook, downloadable here.
He and I have both had great difficulty getting GraphViz2 to properly display the schema of this database. He's using Strawberry Perl, and I'm using Perl under Debian.
Among the various problems are files marked as ISO-8859-1 but containing UTF8 data, and the Postgres data using the string syntax N'...'. AFAICS my Postgres V 8 (printed) manuals don't use this. Perhaps the original Chinook data was prepared by someone using Postgres V 9.
So, I've created Postgres and SQLite files to simplify installation of the Chinook data.
Download the Postgres data from here, and the SQLite data from here.
See create.pg.sh and create.sqlite.sh for the installation steps.
Note also that Postgres' psql and SQLite's sqlite3 both fail to handle UTF8 files starting with a BOM, so I've rigged the code in both cases to generate a deliberate syntax error when the reader attaches the BOM to the first non-comment token.
I am writing to solicit help from anybody who knows Perl and can read Serbo-Croation. Vera Djuraskovic kindly offered to translate the documentation to PDL's threading engine, PDL::PP. Not light material, mind you. :-)
Of course, the original docs are written in pod, and I would really like to distribute the translation with PDL itself. However, Vera has not expressed any interest in distributing these docs as pod, possibly because she (he?) would actually like to drive some viewers to his (her?) site. For my part, I am most concerned about having the translation. If the translator can derive a fringe benefit from the translation, I'm OK with that.
