i have a Motorola Droid and a first generation iPhone which I use on WiFi only. But I really can't get myself to use either of them for task management.
Nothing beats the feel of my Palm Tungsten C keyboard. And nothing really beats the simplicity of the Palm ToDo List. Well, not really nothing, but you know what I mean.
I was surprised and happy to notice active development still taking place on p5-Palm. Today, I decided to resurrect an old project I had started to create a Palm Sync daemon on my home server.
First, I confirmed that pilot-link was up and running on my server. Next, I refreshed my memory on the commands used to run a WiFi sync.The first step is to make sure the user of the Tungsten C and the user of pilot-link are one and the same. This overwrites the user on the device, so proceed with caution.
If you are the author of this module, use it, or otherwise have an interest in its health, please let me know. I don't use it at all, but I know how to make broken distros work again. There are still lots of problems, but I only did the minimum to get the tests to pass.
The drive Wednesday up to St. Paul went well, no major meltdowns or fussing.
Had dinner at the Blue Door Pub. I had the Jiffy burger and a bunch of good beer. A bit too much peanut butter for my taste. The Purvis at XXX seems to have a better balance of peanut butter to burger.
Thursday was mostly focused on getting to Punch for lunch. We then had Taste of Thai for dinner.
Friday was awesome. I took brian d foy's Effective Perl Programming class. Nothing like beta testing (more like alpha since brian did mention this was the first time teaching it) a class. Since I've taking his Mastering Perl class a couple years ago at OSCON I would say half the content was familiar from that and general Perl stuff I've done/read about. The rest was golden (mostly Unicode stuff). I'm looking forward to the second edition of the book that the class is based on.
I often find that test reports I get from smokers are not terribly useful for failures. Sometimes it's obvious. Other times it's not. One thing which helps a bit is this bit in your t/load.t test:
so I was asked this question regarding our users and our products
and such. wanting a quantitative numerical result,
- I quickly (less than 5 minutes) wrote up a map-reduce (+ reduce) job,
- submitted it to our array of servers,
- and in less than 10 seconds, I had the answer.
There is empirical evidence that Perl is an inherently maintainable language. The Software Productivity Research group have published 2 comprehensive surveys of programmer productivity across different languages and problem domains. One was published in 1996, the other in 2006. The results in both are consistent - for overall perl productivity scores & when perl is compared against other popular languages.
Function points were used as the data collection method and the survey covered the whole dev lifecycle. The actual figures are not too important - suffice it to say that both surveys found that perl is far more productive than C & generally significantly more productive than Java.
SQL scores even higher, btw, albeit in its specialist field of relational data manipulation.
Productivity != Maintainability though?
True - but to be productive throughout the lifecycle the maintainability must be at-worst acceptable w.r.t to design,implement,test.
Naturally questions can asked of the method & the results. SPR themselves spell out the limitations, so take with appropriate seasoning. That said the consistency of the results might induce speculation on:
For a while I have had two itches to scratch. Firstly, I wanted a simple set of libraries to interface to the Amazon Web Services. Secondly, by having those, I could do my own remote storage of various important files.
Almost 2 years ago I wrote the start of Project AwsSum in Perl. They are simple but they work and also come with some small command line tools which do as you want.
The itch for those interfaces has mostly gone. I do need to add some latest updates to the interfaces but they're ok in all honesty and those who want those new features would only take a few mins to add them :)
Remote Backup
The 2nd itch has been bugging me for a long time though. In the example folder of the repo there is a command line tool called s3bak and for ages I have been using it to store my files. However it has one major disadvantage, the pushing and pulling is manual.
One month to go and work is progressing well on the transformation to CPAN Testers 2.0. Over the last month many changes to the websites have been visible, but just as many changes have been happening behind the scenes. The Metabase is a key part of the transformation, and although work has been going well, it is reaching the point where it'll need some serious testing prior to switch over on 1st march 2010. If you have the time, please join the cpan-testers-discuss mailing list or contact David Golden to let him know what you can help with. See David's CPAN Testers 2.0 mid-January update blog post for a more detailed status update.
On Tuesday, February 23rd, Jeff Thalhammer will speak on why you should create CPAN distros, even for proprietary code. He has worked on worked on several projects where all the private code was organized into CPAN-style distros, and then injected into a local copy of CPAN. They then used the CPAN tool chain to manage the entire build, test, and release process.
Jeff Thalhammer's CPAN page:
http://search.cpan.org/~thaljef/
Announcement posted via App::PM::Announce
RSVP at Meetup -
http://www.meetup.com/San-Francisco-Perl-Mongers/calendar/12509158/
Some older articles from a (failed) attempt to compete in the Ironman Blogging Challenge. I’ll try to move them over here, although converting from Blogspot’s HTML (or even cleaning up said HTML) to Markdown is a hassle.
Nagios is probably the most famous and used monitoring program on the market. It's free, GPL and has nice features such as object representation of data, inheritance, plugin systems, passive testing, built-in Perl interpreter, result caching, pipe interface, alert delegations and so on and so on.
I was looking over my old notes recently - I have a file where I keep ideas for projects among other things. These notes are really of any kind: implementation details, user requirements that should be met, project naming ideas. Among the potential projects for some later day is a Twitter client, for which I kept some naming notes. The thought process behind them was to somehow combine “Twitter” with “Perl” (not necessarily in an obvious fashion). I had even arrived at a conclusion.
With the benefit of retrospect, I have no idea what I was thinking.
I had decided that the right name would be “Twipple”.
I completely agree, design is the first thing people notice about a project. If you do not put effort into the look of your projects web page then whether you like it or not it will have an affect on the perception of your project (and indirectly on Perl).
If someone (my list of projects is way too large at the moment unfortunately) has time I think there are two projects which would make a massive difference.
Provide a Creative Commons licensed design(s) that anyone can use for a Perl project. Lots of us are not designers, so even if we'd like to make our projects look better we don't know how!
See if it is possible to get CPAN redesigned, this is already the home to thousands of Perl projects, so improving this will have a massive impact.
Many of the Apple applications websites have a similar feeling (simple and clean), this is because they all use iWeb. Good design does not mean lots of design. It just means a clean page, and separating content under headings (rather than having a single page with everything just listed).
Though 1: Test::Class::Most fails on Perl 5.010001 -- but only on Linux. Not on FreeBSD, OS X or Solaris. I've already emailed the testers and hopefully someone can track down what's going on. I don't want to say "bug in Perl", but this is not platform-specific code, so it looks suspicious.
Thought 2: Can anyone please explain to me why anyone would want to buy a whyPad?
Thought 3: What does the following print and why? Results are the same for 5.10.1 and 5.8.9, in case you're wondering. Try and figure out the output before you run the code. I now know why it does this, but I was confused by the behavior.
For a long while now I've been wondering about some observations I've made of Perl, Ruby, Python and PHP in marketing terms. I'm going to discuss them here in detail, and I hope it will gain us some insight into better marketing understanding or at least not bore anyone.
I've understood through the years that projects with beautiful websites have a better chance of getting picked up by users (even when the project itself is purely command-line) and definitely gives much more credit to the encompassing layer (like the programming language itself).
I've also noticed that a rather large portion of Ruby-related projects have very beautiful websites. You might have noticed this yourself as well. I tried to understand how this situation occurred and had a few discussions at $work with people whose opinion I appreciate, one being a Python and PHP programmer (or, as I like to see him, a programmer who knows PHP) and the other being a Ruby, RoR and overall Javascript whiz.
Over the past year or so, I've been working on a project called Cil. It's a distributed issue tracker and if you don't know what that means, let me explain.
Cil is currently a command line tool. It saves it's issues, comments and attachments as plain text files inside your project in an issues/ directory. Some settings are read from .cil and also you may set some personal preferences in ~/.cilrc.
Due to the fact that all data associated with issues (bugs, feature requests, tasks) are saved as text files, it's really easy to check them in to Git and, if required, fix conflicts.
Aha, conflicts, that's gotta be painful. Well, it's not and here's why.
This subject really requires a whole series of posts, but for the moment I'd just like to lay out the basics of what's needed to integrate your Perl development process and Hudson.
First and foremost, you must be using some source control system. Doesn't matter if it's CVS, Subversion, Git, Mercurial, or Bazaar (Hudson supports all these), but you need to have this set up so that Hudson can both consistently check out your software and so that it can notice when to do another build.
Second, you need a test suite. It doesn't have to be perfect, or have 100% test coverage, but you need something that Hudson can run to verify your builds.
After uploading Test::Class::Most, I kept thinking and thinking about the fact that you automatically get strict and warnings with it. I started to think about my annoyance with test suites in general and am now thinking about doing this with Test::Most. I proposed this to Perl-QA and received three positive responses (two offlist) and no negative. It won't import "features" of 5.10, but instead of this:
use strict;
use warnings;
use Test::Most tests => 34;
I like dispatch tables. Which means I use this kind of thing quite a bit:
$dispatch{$pieces_of_state}->(@args)
if exists $dispatch{$pieces_of_state};
Does that sub-routine call look ugly? I suspect it does. It would look nicer in javascript for sure:
dispatch[pieces_of_state](args) vs $dispatch{$pieces_of_state}->(@args)
But how much difference does the syntax really make? I understand the impulse to make perl look more like Haskell but I doubt very much that the extra noise from the sigils makes a lasting difference to the readability/maintainability of the code.
Which is not to say that notation is not important - it is - but it can only get you so far. You still have to understand the concepts behind the notation. I could use source filters and come up this something like:
dispatch :
pieces_of_state
args
Free of sigils and arrows but - well - so what? I still have to mentally reconstruct the text into "table", "condition", and "inputs" clauses.
What is more important in this case is why I'd use a dispatch table in the first place. I can
ruthlessly weed out:
