How to handle completely clueless users?

I admit I'm sort of a email traffic controller.

It irks me to the point of a pet peeve, when I spatter the contact page of my project with notes that say, "DO NOT CONTACT ME FOR SUPPORT UNLESS YOU WANT TO BUCK UP SOME MONEY", and I get tons of support emails, wanting free support.

Sigh.

What I don't want to do, is take the time and go,

"Look. We have forums. We have mailing lists. Use those. Thanks." And then not answer they're question.

What I do is exactly that.

I don't want to do this, because I know how much of a pain it is for the person to now, *rewrite* what they just ask me. It also is a pretty weird introduction to what should be a really valuable exchange - someone actually wants to talk to *me* about *my* thingy.

The curious thing is, I don't want to be hired to fix some stupid bug - I have better things to do. I'd rather help fix the bug for *free* - and its beneficial - users let me know it's there, I (or them - ha!) open up a bug report, it gets fixed (probably by me) and *there's a thread of, "something just happened"* that lives far away from my inbox and takes on a life of its own. I don't have to write the same thing twice and with a little work by the user (or if they dare help themselves) they can find it themselves, and keep a thread going. When I say, "thread" - I mean, anything - a forum post about a problem, with a reply of a confirmation that it's a bug, with a link posted to a bug report, that may then give you a patch in a day or so - which then gets referred in another forum post - etc. But, a trail is there.


The thing is, there's better ways to ask the questions.

What's the better way to point them to the right way?



For a while, I just had a auto responder that said,

"Hey, if this is a support question - go here, and here and here and read this and that and then post to this thing or that thing and away you go! America!"



"...but, if this isn't a support question, well, disregard all that, and I'll get back to you, soon"

That seemed a little foolish.


Right now, I'm trying something different - I'm just making up a mail template that first, welcomes the new person emailing me to the *community* and then gives a very brief list of resources that say, "Here's what to read", "Here's where to ask questions"

Then,

well, then if I can, I'll answer they're question - I haven't yet said, "And next time, POST HERE", cause again, that makes me think I'm reprimanding someone for something they may have just missed. Or something. Anyways - let's think positive and we're all humans here, and we probably all have a strong sense to belong.

But, what I want to do is get people active in the program and community. It's pretty hard, since, well, usually my audience is general users and they just have Work They Need To Do, and aren't nerdy enough to get excited about some program. Understandably.

Perhaps, by simply giving a welcome, some encouragement, some links to check out and a head-start on solving the problem, they'll feel as if they're welcome in a community, instead of just a bother to me.

As far as I'm concerned, community in anything is everything. If you're not building a community, you have almost nothing, no matter how great you are, you have nothing without people.

Anyways, I'll let you know how it goes, but I'd be interested in hearing other ideas you yourself may have,

Problem with Email::Valid and newlines

Found a strange problem in Email::Valid:

 
#!perl
use strict;

use Test::More tests => 4;

BEGIN {
 use_ok('Email::Valid');
}
my $email;

$email = 'withnewline@example.com' . "\r";
ok(Email::Valid->address(-address => $email) eq undef, 'addresses with "\r" at the end return undefined');
diag(Email::Valid->address(-address => $email));

$email = 'withnewline@example.com' . "\r\n";
ok(Email::Valid->address(-address => $email) eq undef, 'addresses with "\r\n" at the end return undefined');
diag(Email::Valid->address(-address => $email));

$email = 'withnewline@example.com' . "\n";
ok(Email::Valid->address(-address => $email) eq undef, 'addresses with "\n" at the end return undefined');
diag ("'" . Email::Valid->address(-address => $email) ."'");

From what I expect, that last test should pass. Email::Valid's docs do say that if address can munge the address, it'll return the munged address, instead of undef - but I have munging (or "fudging, in this module" *off* - as it is off by default). Carriage returns aren't munged, so why newlines?

Perhaps it's the last line in the module:

 
# Regular expression built using Jeffrey Friedl's example in
# _Mastering Regular Expressions_ (http://www.ora.com/catalog/regexp/).

$RFC822PAT = <<'EOF';
# Possibly the most insane regex... possible
EOF

$RFC822PAT =~ s/\n//g;

The test for validity changes the actual string being validated. Drrrrr.


And that kind of brings up another point: Why is a module called, Email::Valid and its validating method (address) also doing double-duty with wanting to munge the string I give it so it may possibly be validated? Sounds like you just need to methods there, validate() and, gimme_back_an_address_if_at_all_possible(),

or,

whatever.

Perl Semaphores 'n stuff

This is a pretty good and gentle introduction into file locking and using semaphores in Perl:

http://interglacial.com/~sburke/tpj/as_html/tpj23.html

I was having the exact problems being described:

Unfortunately, this means trouble for our flock-using code. Notably, there can still be a problem with instances being out of phase — since we can’t lock a file without already having opened it, things can still happen in that brief moment between opening the file and locking it. Consider when one instance is updating counter.dat just as another new instance is about to read it:

Instance 1                         Instance 2
-----------------                   -----------------
open COUNTER, ">counter.dat"
or die "Can't write-open: $!";
                                  open COUNTER, "<counter.dat"
                                   or die "Can't read-open: $!";
                                  flock COUNTER, LOCK_EX;
                                  my $hits = <COUNTER>;
                                  close(COUNTER);

flock COUNTER, LOCK_EX;

There, the OS dutifully kept two instances at once from having an exclusive lock on the file. But the locking is too late, because instance 1, just by opening the file, has already overwritten counter.dat with a zero-length file, just as instance 2 was about to read it. So we’re back to the same problem that existed before we had any flock calls at all: two processes accessing a file that we wish only one process at a time could access.

In a very very complex part of my app, that has to do with basically managing a queueing system - something that really really really should be written using a transaction capable SQL backend. If only I knew how to do that.

I combined the semaphore file with the, Highlander, THERE CAN BE ONLY ONE! Idea:

http://perlmonks.org/?node_id=14260

http://www.stonehenge.com/merlyn/WebTechniques/col54.html

So if I can't get a lock, I can wait a little longer. I thought, "Hey, sounds like a good idea". It also sorta kinda puts a queueing system to the resources that a lot of different thingies want to hit, and hopefully, stop the programming from giving back errors like, all the fucking time. We'll see.

All the tests pass (you do write tests, right?), but using the app doesn't really... um, work. It's timing out. Most likely from the Highlander idea. More whackin' to do...

Nerd!

I've decided what computer programming is to me at the moment:

It's a hobby. It's a hobby that currently pays my bills, but to call it a job or a company that I have is not what's going on. I know this, because I explicitly attempt not to do what companies attempt to do really really well. One of these things is to try to sell you the product.

The product I make is free, so there goes that baby/bathwater.

I also write a book about the thing.

The book is just a bunch of HTML I create from a simple doc format. It's akin to me selling you plans on how to make your own land mower from the back of Popular Mechanics, or something.

Another thingy that companys are good at, especially in computer-stuff is automation. I do provide services to install the program. But I do it manually. There's no installer. And, that's stupid.

But if this is just a hobby - one that takes a lot of my time, I don't have a job. And art isn't making any money.


This is all going to come to a head, soon enough. But at least it allows me to identify myself as a, "hacker" rather than a software engineer, which I couldn't possibly be.

It also gives me something to put on my artsy résumé: Computer Hacker. That sounds almost hip. Would you like a painter that has a hobby of collecting pogs, or a painter that also has a hobby of hacking computers?

yeah, you're right, pogs win again.

LWP is Simple.

While I'm on the nerd tip, this is the simplest example I can get to grab the contents of a URL, with a optional username/password and/or proxy:

 
#!/usr/bin/perl 
 
my $proxy = undef; 
my $user  = undef; 
my $pass  = undef; 
my $url   = 'http://localhost'; 

 # Create a user agent object
 require LWP::UserAgent;
 my $ua = LWP::UserAgent->new;

 if($proxy){ 
  $ua->proxy(
   ['http', 'ftp'], 
   $proxy
  ); 
 }
 
 # Create a request
 my $req = HTTP::Request->new(
    GET => $url
   );
 # Pass request to the user agent and get a response back
 my $res = $ua->request($req);
 if(
   defined($user) && 
   defined($pass)
 ){ 
    $res->authorization_basic(
   $user, 
   $pass
  );
 }
 # Check the outcome of the response
 if ($res->is_success) {
     return $res->content;
 }
 else {
     warn $res->status_line;
  return undef; 
 }
}

Wishing LWP::Simple would do this, but. Nope.

MIME Trickery with MIME::Parser and friends

You can attach attachments to a multipart/related email message entity (say, a email message created from a website, with the images attached to the message itself) by creating a new multipart/mixed entity, and having the first part be that multipart/related entity and the rest being your new attachments. For example:

 
#!/usr/bin/perl 
use strict; 

use :MyMIMELiteHTML; 
use MIME::Parser; 
use MIME::Entity; 

my $HTMLurl = 'http://localhost'; 
my $jpg_path = '/Users/justin/Desktop/4.jpg';


my $mailHTML = new MyMIMELiteHTML(
 'IncludeType' => 'cid', 
); 
                 
my $MIMELiteObj = $mailHTML->parse($HTMLurl)  ;

 
my $msg_as_string =  $MIMELiteObj->as_string; 


my $parser = new MIME::Parser;

my $entity = $parser->parse_data($msg_as_string);


# Attach stuff to it:


my $cont_entity = MIME::Entity->build(Type        => "multipart/mixed");
   $cont_entity->add_part($entity); 
   $cont_entity->attach(
    Path     => $jpg_path,
                Type          => "image/jpg",
                Encoding      => "base64",
    Disposition   => "attachment",
    );

print $cont_entity->stringify;

MyMIMELiteHTML is just my version of MIME::Lite::HTML, with a few bug fixes and changes to fit in my program better.

http://search.cpan.org/~alian/MIME-Lite-HTML-1.22/HTML.pm

I've tried also just added the attachments to the multipart/related entity, but the new attachments never can be found - at least in Mail.app (Gmail? Yes?), unless you put in a bogus Content-ID header for the attachement - which actually could come in handy in some rare cases, but I digress...

First Post. It's about Perl. Perl Perl Perl.

So.

There was a recent flurry of postings in the Perl Community dealing with how Perl isn't very sexy any more and lots of, "oh my God, no one uses Perl anymore" and sky falling down and all that.

They also mentioned that the number of teh blogs dealing with Perl, when compared to other languages was a bit lackluster. Perhaps this is because most of the big-shot Perl programmers you see lurking around on teh Perl mailing lists and are creating the majority of quality CPAN modules are on http://use.perl.org? - I dunno.

Anyways, I thoughts to myself, Self, you're eccentric. You're a sexy little beast.

And you program in Perl.

So here's my hat thrown into the ring for teh Blogs about teh Perl.

The other thing I do - I would say my main passion is Art: drawing and painting. It's not Perl. Perl helps pay the bills I guess.

I'm sort of realizing, as I get older, that playing with Perl and being so SO into art is a rarity, and as a nod to the Paul Graham article, "Hackers and Painters (http://paulgraham.com/hp.html)", I give you the Perl Hacker Painter.

Hacking is probably the best way to describe to you how I program. I barely understand the concepts I play around with. I didn't go to school for this. I am not math-inclined.

But, I've flourished, in my own little way, in writing Perl (mostly).

If you're more traditional in your skill-acquiring, I may say/do/write things that makes no sense. And, that's OK. Because, when I ask for help? I get a lot of answers from people that don't make much sense to me. And then, I just hack about.


I'll probably use this thing (I loathe the word, blog) to write examples of code for whatever, problems I solved with Perl and hopefully, artwork Perl helped me with, since, there's a lot of that in my portfolio

So, if you're zooming around on Techorati or something and you've come across, *gasp* a blog about Perl, well, hello to you too.