Posted by Tom Moertel
Thu, 09 Oct 2008 01:04:00 GMT
The 2008 Pittsburgh Perl Workshop is this
weekend! I can’t wait. (BTW, there are still seats available. If you
can somehow get yourself to Pittsburgh this weekend, by
all means, grab a PPW
ticket now.)
I’m on the organizing committee, so I get an advance look at the
talks, and I’m continually impressed by the quantity and sheer
interestingness of the things that the Perl community has to say.
When leading members of a community volunteer their time to talk to
you about something they’re passionate about, that something is
usually fascinating.
This year is no exception. There are tons of talks I want to see. Check out the schedule for
Saturday and
Sunday,
and you’ll see what I mean. (You’ll note that there are even
talks on programming GPUs and adorable BUG embedded hardware.)
In addition to technical talks, there are three courses being
offered this year. Daniel Klein is once again leading his From Zero
To Perl introductory course, which was widely praised at last year’s
PPW. Author and Perl trainer Peter Scott is offering Maintaining
Code While Staying Sane, which is all about maintaining legacy code,
something most programmers must do for a (surprisingly) large chunk of
their careers. Finally, the ever-knowledgeable brian d foy is
offering his Mastering Perl course for coders interested in learning
how to reliably write professional, enterprise-quality Perl programs.
(I think there are openings for some of the classes, too. If you’re interested,
click one of the links above and try to grab a spot.)
This year we’re expanding on the Hackathons, too. We actually have
allocated a dedicated “Hackathon Room” – and we’ve arranged for
freshly ground, freshly brewed coffee all day long to fuel the
hacking. :-)
All in all, it’s shaping up to be another fun-filled, festive PPW.
I hope to see you there!
Posted in perl
Tags perl, ppw, ppw08
no comments
no trackbacks
Posted by Tom Moertel
Fri, 19 Sep 2008 15:06:00 GMT
Via Dare Obasanjo’s blog, I learned
that the much-publicized cracking of Sarah Palin’s Yahoo! email accounts was
accomplished by exploiting the weakness of “security questions”. In short, all the attacker needed to do to convince Yahoo’s computers that he was Palin was answer three questions as if he were Palin:
- What’s your birthday?
- What’s your Zip code?
- Where did you meet your spouse?
The attacker says he obtained the answers to these questions in less
than an hour. Everything he needed was already public knowledge, and
Google and Wikipedia made that knowledge easy to find.
And that’s why when I sign up for web sites that ask me to provide baseline answers for those annoying security
questions, I claim that I met my spouse
in CWmKryWzuxCSAnMDuIg. What? You’ve never been there? Well, that’s not surprising. It’s not a real
place: it’s a password, randomly generated, and remembered for me by
password-management software on my computer.
That’s right. Every time I’m asked to establish my “secret” answer to a
security question, I generate a random string and use that. Here’s a
script I use:
#!/usr/bin/perl
use MIME::Base64;
open my $random, "/dev/urandom"
or die "can't open /dev/urandom";
my $bytes;
read $random, $bytes, 16;
close $random;
my $pw = encode_base64($bytes);
$pw =~ tr/A-Za-z0-9//cd;
print "$pw$/";
Then I store the string in my password-management software, just in
case the web site asks me for it later. Which should only happen if I
forget my primary password for that site. Which should only happen if
I can’t get into my password-management software. Which should only happen if I’m totally screwed, anyway, so what are the security questions buying me again?
In sum, if you care about your security, you’re probably picking good passwords already. In that case, security questions can’t help you, but they can harm you by making it easier for an attacker bypass your passwords. That’s how the Palin-email cracker did it. So treat your answers to security questions as if they were passwords – in effect, that’s what they are.
Posted in security
Tags passwords, security
9 comments
no trackbacks
Posted by Tom Moertel
Mon, 25 Aug 2008 02:56:00 GMT
I finally got around to releasing PXSL Tools on Hackage. The package contains pxslcc, a preprocessor that converts Parsimonious XML Shorthand Language into XML, and supporting documentation.
If you want to hack on the Haskell sources, I’ve put the project on GitHub, too. See the pxsl-tools project page to browse the code, or just clone the repo and hack away:
$ git clone git://github.com/tmoertel/pxsl-tools.git
Tags git, haskell, pxsl
no comments
no trackbacks
Posted by Tom Moertel
Thu, 21 Aug 2008 01:50:00 GMT
Although at work I code mostly in Python – a language from which
lambda and map were nearly removed – I still find that functional-programming experience
has its benefits. One of the
“functional-programming dividends” I notice most often is insight
gained from considering problems from an algebraic perspective.
Recently, for example, I had a small parsing problem. I had to
write code that, given a simple grammar specification as input, emits
a regular expression that matches the language generated by the
grammar.
Here’s a simplified version of the problem. A grammar specification
is limited to a series of one or more atoms. For example, “a b c”
represents the atom “a”, followed by the atom “b”, followed by the
atom “c”. To generate the grammar, the series of atoms is interpreted
such that each atom (except the last) generates a production rule of
the following form:
atom_rule ::=
<the literal atom> (SPACE <the next rule> | NOTHING)
(SPACE represents literal white space and NOTHING represents an
empty string.) The grammar as a whole is rooted in the first atom’s
rule.
Thus the specification “a b c” represents the following grammar:
grammar ::= a_rule
a_rule ::= "a" (SPACE b_rule | NOTHING)
b_rule ::= "b" (SPACE c_rule | NOTHING)
c_rule ::= "c"
Note that the final atom’s production matches only the literal atom
itself: it has no following rule on which to chain.
The grammar, in turn, generates the following language:
a
a b
a b c
Thus, given the grammar specification “a b c”, my code had to produce
a regular expression that would match “a”, “a b”, or “a b c”.
At this point, please stop for a moment and think about this little
programming exercise. Do any solutions leap to mind? How would you
approach the problem? Form your opinions now, because I’m going to
ask you about them later. (If you’re feeling especially caffeinated, try
coding a solution before reading on.)
Read more...
Posted in functional programming
Tags folds, fp, haskell, python
19 comments
no trackbacks
Posted by Tom Moertel
Sun, 10 Aug 2008 18:12:00 GMT
As an update to my previous post on the 2008 convention of the Historical Construction Equipment Association, I have posted an action-packed video of a Type-B Erie steam-powered shovel! Wait until you see this old beast belch steam and smoke and you hear it chug, clank, and huff and puff – it’s like stepping back in time. And it’s definately fun stuff!
I took this footage on 8 August 2008 in Brownsville, Pennsylvania. (I also have footage of other equipment – dozers, draglines, trucks, shovels, and more. Let me know if you’re interested, and I’ll upload those, too.)
Update: I have uploaded the rest of my footage to flickr:
- Thew “O” steam shovel
- Dragline
- CAT 955 bulldozer
- CAT D8 bulldozer
- Vintage Army dump truck
See them all in
my HCEA 2008 photostream.
Posted in fun stuff
Tags fun_stuff, hcea, hcea2008, steam_shovel, video
2 comments
no trackbacks
Posted by Tom Moertel
Sun, 10 Aug 2008 00:23:00 GMT
Today, my dad and I went to the 2008 annual convention of the Historical Construction Equipment Association. We were impressed with the quantity and quality of the machinery on active display: steam shovels, dozers, graders, crawlers, scrapers, cranes, steamrollers, and a bunch of other old but well-maintained construction equipment. I’m talking dozens of massive machines – not just sitting there, but working!
This year’s convention is in Brownsville, Pennsylvania and runs through August 10, 2008. If you are within driving distance and think smoke-belching, earth-shaking construction equipment is fun stuff, don’t miss it. There’s still time to go.
If you can’t make it, I took some photos for you. Not quite the real thing, but better than nothing.
Posted in fun stuff
Tags fun_stuff, hcea, hcea2008
1 comment
no trackbacks
Posted by Tom Moertel
Mon, 05 May 2008 13:58:00 GMT
There’s a great way to explain delimited continuations in the notes of Oleg’s Continuation Fest talk on using delimited continuations for CGI programming. Just so it doesn’t get overlooked, here it is:
I’m obsessed in pointing out that every programmer already knows
and understands the delimited continuations; they might not know that
word though. Everyone knows that when a process executes a system
call like read, it gets suspended. When the disk
delivers the data, the process is resumed. That suspension of a
process is its continuation. It is delimited: it is not the
check-point of the whole OS, it is the check-point of a process only,
from the invocation of main() up to the point
main() returns. Normally these suspensions are resumed
only once, but can be zero times (exit) or twice
(fork).
I especially like the final part about exit and
fork, which drives home the notion that something more
subtle than returning from a typical function call is going on. If
anybody is confused over what suspended means, that last part
ought to clear things up.
The next time I need to explain delimited continuations, I know how
I’m going to do it.
Posted in functional programming
Tags continuations, fp, oleg
no comments
no trackbacks
Posted by Tom Moertel
Fri, 11 Apr 2008 15:58:00 GMT
Via Chris:
$ history | awk '{print $2}' | sort | uniq -c | sort -rn | head
196 git
110 l
102 cd
70 make
34 darcs
30 pushd
23 ssh
23 m
23 ls
20 rm
The l and m commands are aliases:
Posted in interesting stuff
Tags life, memes, programming
1 comment
no trackbacks
Posted by Tom Moertel
Thu, 20 Mar 2008 02:34:00 GMT
At work recently I was writing some tests with Python’s out-of-the-box
unit-testing framework
unittest. I’m new
to Python and accustomed to Perl and Haskell’s testing frameworks,
which are lightweight and let you write tests without much
hoop-jumping. In particular,
QuickCheck and
LectroTest make it easy
to test at the property level instead of the test-case level.
With unittest, I was having to write a lot of code
to get the same level of abstraction.
By “property level,” here’s what I mean. Say I’m testing this thing,
let’s call it a subscriber pool. It has two fundamental properties:
- Subscribe. For all initial states of the pool, if you call subscribe(user), then, assuming there have been no other operations on the pool, user must be in the pool.
- Unsubscribe. For all initial states of the pool, if you call unsubscribe(user), then, assuming there have been no other operations on the pool, user must not be in the pool.
That’s it. If my implementation satisfies both properties, it’s
correct. (This is a simplified version of my real testing problem,
which required additional property checks.)
To test whether my implementation satisfies each property, I must
write individual test cases that together “cover” the property. For
example, to test whether the Subscribe property holds, I might write
four test cases:
class SubscribeProperty(unittest.TestCase):
def setUp(self):
initialize_pool()
def tearDown(self):
destroy_pool()
def testEmpty(self):
load_pool_with_members([])
subscribe("1")
self.assert_("1" in pool_members())
def testOtherGuyAlreadyInPool(self):
load_pool_with_members(["2"])
subscribe("1")
self.assert_("1" in pool_members())
def testSubscriberAlreadyInPool(self):
load_pool_with_members(["1"])
subscribe("1")
self.assert_("1" in pool_members())
def testSubscriberAndOtherGuyAlreadyInPool(self):
load_pool_with_members(["1", "2"])
subscribe("1")
self.assert_("1" in pool_members())
Every one of the test cases has the same form. The repetition
makes me want to refactor the whole thing.
Okay, let’s do it:
Read more...
Posted in testing
Tags nose, properties, python, testing, unittest
1 comment
no trackbacks
Posted by Tom Moertel
Tue, 18 Dec 2007 03:33:00 GMT
XML is fine for representing document-like things, but when it’s
twisted to represent build recipes, configuration files, and little
programming languages, it opens the gates to XML Hell. Once the
gates are opened, the demons of cargo-cult thinking are loosed upon
the world, where they are free to trick innocent programmers into
working with grotesquely twisted XML documents – something no human
mind was designed to comprehend. Ensnared, these programmers are
slowly drawn into the depths of XML Hell, from which their
lamentations echo across the
universe.
When the demons of cargo-cult thinking come for you, don’t be
ensnared! Instead, be prepared – with PXSL – the Parsimonious XML
Shorthand Language
(pronounced “pixel”).
What’s PXSL? It’s a luxurious, thermonuclear smoking jacket that you
can slip on using a convenient preprocessor. Use it whenever you see
grotesque XML on the horizon. Within PXSL’s plush (and stylish)
protection, you can create all the nasty, twisted XML that may be
demanded of you, but you need not descend into XML Hell to do it.
Instead, you can work from the comfort of a well-stocked lounge, where
clarity and conciseness are always on tap.
For example, here’s a snippet from an XSLT stylesheet, in the
original XML:
<xsl:template match="/">
<xsl:for-each select="//*/@src|//*/@href">
<xsl:value-of select="."/>
<xsl:text> </xsl:text>
</xsl:for-each>
</xsl:template>
And here’s the same snippet, written in PXSL:
template /
for-each //*/@src|//*/@href
value-of .
text << >>
Isn’t that refreshing?
Why PXSL?
There are lots of XML shorthands available. (The PXSL FAQ lists about ten of them.) So why choose
PXSL? Here’s why:
Also, PXSL is battle tested. It was first released in 2003 and has
been saving people from XML Hell since. People who try it seem to like it:
- I think PXSL could do wonders for soothing my irrational hatred for all things XML. —kowey
- Impressive… I converted some of my files from XML to PXSL and the readability was much improved. —chris
- Quite aside from the fact that XSLT is finally somewhat readable, the fact that you’ve added a serious macro system means that some serious scripting of XML can occur. I’m very impressed. —invisible
The next time you’re headed for XML Hell, why not give the venerable PXSL a try? You might just find that you like it, too.
This public service announcement was brought to you in celebration of
the 1.0 release of the pxsl-tools package. The PXSL-to-XML compiler
pxslcc is written in Haskell and uses the
cross-platform Haskell Cabal
build/package system to let you use PXSL just about anywhere.
Posted in programming
Tags haskell, pxsl, xml, xslt
8 comments
no trackbacks
readers
