Talks (was: Re: [YLUG] A basic question)

[Alex Howells]

On 28/12/2007, Steve Kemp <steve at steve.org.uk> wrote:
>   I've run into two distinct problems which have the same cause,
>  validating "normal" fields is hard.  There are people who'll just
>  abuse the mail format.
>
>   Specifically I tried to:
>
>    1.  Validate the 'Date' header on mails, if present.

Yeah, this should be an obvious one since spammers often set the date
to something way in the past/future as an attempt to make your mail
client display it at the top - did you have any success filtering mail
if it was +/- a few days out?

>    2.  Attempt to deny "foreign" messages based upon an examination
>       of the character set used.  (I'll save the charset rants for
>       another time...)

I've noticed Google is capable of showing you only search results in a
chosen language, and do think that'd be rather cool for e-mail as
well; provided it doesn't try to intepret an attached binary as
language, of course.

Frankly 100% of the e-mail I care about arrives in English, I don't
speak any other languages barring a passing familiarity with Welsh and
perhaps French.  Being able to say "Not English? GET IN THE
QUARANTINE!" would rock.

> >       Is there an individual quarantine per user/domain, perhaps
> >       accessible through a web interface?
>
>   Ahem.

I know I've seen your system ;)  Was curious about other stuff out there too!

> >   *  Scalable web hosting  -  deploying WWW services behind load balancers
> >       and utilizing technologies like caching on dynamic content.
> >       Would be particularly interested in hearing from someone who's
> >       deployed a Ruby on Rails application in such a manner, given that
> >       it appears such a c*nt to deploy in any sane fashion :-)
>
>   I've no experience of large-scale hosting, but I do highly recommend
>  fragment caching via Danga's memcached or similar software.

Amazing isn't it?  There *must* be some big sites hosted at work but
we rarely see anything "below" the O/S ;)

>   My Debian site uses it extensively and I'd be happy to show you the
>  cache hit/miss rates if you're curious.  In short when you have per-user
>  pages being generated on the fly caching them doesn't work out as well
>  as it could - because too many parts (potentially) change.
>   Caching the computationally intensive sections is a significant
>  win.  (Probably pretty obvious..?)

Is memcached something that'll apply to any dynamic content, so stuff
generated by mod_perl, PHP, Ruby and all that?  What're the drawbacks
to the technology?  Does it require much modification to site code to
define what's cached?

>   The only thing that I'd say here, with a nod to Joel On Software, is
>  that your "product" (be it a commercial program, another piece of
>  software, or a release of a complete distribution) should be released
>  via a single tool.
>
>   If you can type 'make release', '/home/$foo/release-me.sh
>   --version=2.0.1' then you've got it made.
>
>   If you cannot then you're at the mercy of the people who can do
>  the magic.  I've watched large projects switch to this model of
>  allowing easy release of:
>
>     * Final builds
>     * PDF documentation.
>     * Release notes.
>     * Source Control tagging / etc.

That "seems" ridiculous but I can think of at least 15-20 projects
which do it this way. So a large percentage. Would you care to comment
on why they don't adopt a 'single tool' approach, given its clearly
superior?

Sounds like you'd be a good candidate for giving one of these proposed
talks! :-P