And now for something completely different.
Often we hear people talk about making your programming more "data-driven". When you can convert procedural code to a data structure (generally with a small procedural driver), instead of replicating procedural code, you just add another entry to your data structure. This is great with dispatch tables, repetitive chunks of code and state machines. However, there is a hidden benefit of it which will not only make you a better programmer, but it will make later maintenance programmers fail to notice a common flaw that your code lacks. They'll curse you if you have the flaw, but if you don't have it, they'll find that data-driven sections of your code are so easy to work with that they won't even think about it.
My current contract is lovely. I'm having a lot of fun and the environment is awesome. However, it's a short contract. I took it, in part, because it was a problem space I wanted to do more work in. Because it's a short contract I'm already working on negotiating my next contract (a perpetual hobby for freelancers), but I thought I'd experiment with a different approach: asking you to reach out to me. If you think I can help your company and you're not in a position to hire me directly, go to those who are and talk to them. If you want to hire me or one of the talented developers who works with me, drop me a line (I can't guarantee that I'm available, but you never know). If this approach works, I can do more work on open source or Veure instead of spending all of my "between" time negotiating contracts.
That being said, I don't always get contracts I negotiate for and sometimes I turn them down. However, if you're an individual considering freelancing, I thought it worth discussing some of the obstacles I've faced.
On my personal blog I wrote about Veure, an MMORPG that I'm writing in Perl. I followed that up with a post about the roadmap to an invite-only alpha. It's a lot of work, but my company has now decided to commit to it and figure out how to finance the work. This browser game is huge in intended scope, but fortunately, Perl has given me the power to get much of it done quickly. In fact, according to my private Veure github repo, I now have 17% of the ALPHA tasks done. That's up from 0% when I posted the roadmap a little over a week ago. In short, progress is fast.
Currently I'm working on character combat and that's where custom DBIx::Class resultsets have made my life easier.
Some of you may remember me talking quite a bit about Veure a few years ago when I was living in Amsterdam. I never discussed on the Web what it was about.
Now it's time to fess up, but I've posted the story of Veure to my personal blog instead of blogs.perl.org because it's not really about Perl (and blogs.perl.org kinda struggles with images). Veure was/is a Perl-based MMORPG. It's not done, but I included a few screenshots.
Search this blog
- Perl-Operated Boy
- The Hidden Benefit of Data-Driven Programming
- Why Companies Turn Me Down For Contracts
- Custom DBIx::Class ResultSets
- Veure - The Game That Isn't
- Perl::QA Hackathon in Lyon - Summary
- Perl::QA Hackathon in Lyon - Day 4
- Perl::QA Hackathon in Lyon - Day 3
- A Simple dist.ini for Dist::Zilla
- Perl::QA Hackathon in Lyon - Day 2