I recently wrote about Veure's test suite and today I'll write a bit about how we manage our database. Sadly, this will be a long post because it's a complicated problem and there's a lot to discuss.
When I first started Veure, I used SQLite to prototype, but it's so incredibly limited that I quickly switched to Postgres. It's been a critically important decision, but I want to take a moment to explain why.
All software effectively has four "phases" which amount to:
Note that we could rewrite the above as:
- Initialization of data
- Input of data
- Calculation of data
- Output of data
Notice a pattern?
Yeah, I thought so. There are all sorts of areas where we could get things wrong in software, but the further down the stack(s) you go, the more care you need to take because the more damaging bugs can be. Data storage is often pretty low in your stack and you don't want to get this wrong. So what happens?
Over on Perlmonks I wrote that you should probably use this:
say join '', @array[2,4];
Instead of this:
local $" = '';
And my reasoning being:
Why is that better? Because nobody knows what $" is, but everyone knows what join() is. Always write your software to be as readable as possible :)
I received a couple of upset replies along the lines of "Perl devs should be allowed to write Perl!" While I generally agree with that sentiment -- I had no problem with the array slice, for example -- I think the replies came, in part, because I had answered too quickly. I clarified what I meant, but I thought I should explain it here, too, because too many people reach for those punctuation variables.
We're still hacking away on the Veure MMORPG and things are moving forward nicely, but I thought some folks would like to hear more about our development process. This post is about our test suite. I'd love to hear how it compares to yours.
Here's the full output:
$ prove -l t
t/001sanity.t ... ok
t/perlcritic.t .. ok
t/sqitch.t ...... ok
t/tcm.t ......... ok
All tests successful.
Files=4, Tests=740, 654 wallclock secs ( 1.57 usr 0.20 sys + 742.40 cusr 15.79 csys = 759.96 CPU)
Let's break that down so you can see what we've set up. You'll note that what we've built strongly follows my Zen of Application Test Suites recommendations.
I've gotten a bit of grief over the title of a TechBeacon article I recently wrote: Why Perl 6 is the "Game of Thrones" of programming languages. I wrote the article, but the editors chose that title based on a throwaway line a couple of paragraphs in:
Like A Song of Ice and Fire (Game of Thrones), which was started back in 1991 and is still being, ahem, "developed," good things come to those who--well, you know.
To be completely honest, I could have objected and the editors at TechBeacon would have changed it back. However, I didn't object because I was honestly curious what the reaction would be. The general reaction so far has been "great article, awful title." I've no idea if that clickbait title helped draw enough traffic to offset the bad impression of the title itself.
In other news, I now write semi-regularly for TechBeacon and you can check out the list of articles I've written (I'd write more often but I just don't have the time).
In fact, now that I think about it, the "wrong choice" title might be the only one I wrote.
For the curious, TechBeacon is a Hewlett Packard project to have a dev and tech site with articles written a bit more on the business side of the divide rather than just the technical side. It's a nice initiative and I hope it does well. The IT world needs more efforts in crossing the business/technical divide.
Working on a large internationalization (I18N) for one of our clients and I found myself in a curious position where I needed to build an I18N objects from users, companies, and web sites. It's tricky because there are multiple ways the object can be instantiated:
my $i18n = Our::I18N->new( domain => $domain );
my $i18n = Our::I18N->new( user => $user );
my $i18n = Our::I18N->new( company => $company );
my $i18n = Our::I18N->new( request => $c->request ); # at the Catalyst layer
Anything consuming the I18N object should be able to do things such as determine country and language, but should not be able see the user, company, or request because they should not be tightly coupled. There are tricks I could do with
BUILDARGS to make the above work, but frankly, that's a pain and often a nasty hack. That's when
bare Moose attributes and meta hacking come in handy.