When your code is nearly old enough to vote

When Your Codebase Is Nearly Old Enough

To Vote

Denise PaolucciDreamwidth Studios - www.dreamwidth.org

Slides: www.slideshare.net/dreamwidth

Friday, January 16, 15

At time of fork:

• Perl 5.6

• Apache 1.3 (yes, in 2008!)

• BML (custom template language from 1996)

• Various Perl modules (usually outdated)


hic sunt dracones


Comments that don’t help my $out_straight = sub {

# Hacky: forces text flush. see:

# http://zilla.livejournal.org/906

if ($need_flush) {

$cleaner->parse("");

$need_flush = 0;

}


Comments that don’t help my $out_straight = sub {

# Hacky: forces text flush. see:

# http://zilla.livejournal.org/906

if ($need_flush) {

$cleaner->parse("");

$need_flush = 0;

}

(Six bug trackers and four owners ago.)


Workarounds for outdated browsers

// let me explain this. Opera 8 does XMLHttpRequest, but not setRequestHeader.

// no problem, we thought: we'll test for setRequestHeader and if it's not present

// then fall back to the old behavior (treat it as not working). BUT --- IE6 won't

// let you even test for setRequestHeader without throwing an exception (you need

// to call .open on the .xtr first or something)


Workarounds for outdated browsers

// let me explain this. Opera 8 does XMLHttpRequest, but not setRequestHeader.

// no problem, we thought: we'll test for setRequestHeader and if it's not present

// then fall back to the old behavior (treat it as not working). BUT --- IE6 won't

// let you even test for setRequestHeader without throwing an exception (you need

// to call .open on the .xtr first or something)

Current Opera: 26.0.1656.60 (Opera 8 released 2005)Current IE: 11.0.12 (IE 6 released 2001)


Really old HTML $ret .= "<FORM METHOD=POST>"; $ret .= LJ::form_auth(); $ret .= "<TABLE WIDTH=400><TR VALIGN=BOTTOM>"; $ret .= "<TD><IMG SRC=\"$LJ::IMGPREFIX/nerd_small.jpg\" WIDTH=167 HEIGHT=169 HSPACE=2 VSPACE=2></TD>"; $ret .= "<TD><B><TT>command console.</TT></B>"; $ret .= "<P>welcome to the livejournal console. from here administrators can do administrative type things. you will forget the commands, so there is a <A HREF=\"reference.bml\">reference</A>.</TD>"; $ret .= "</TR>"; $ret .= "<TR><TD COLSPAN=2>"; $ret .= "<P><tt>enter commands:</tt><BR>"; $ret .= "<TEXTAREA NAME=commands ROWS=10 COLS=60 WRAP=OFF></TEXTAREA></TD></TR>\n"; $ret .= "<TR><TD COLSPAN=2 ALIGN=RIGHT><INPUT TYPE=SUBMIT VALUE=\"execute\"></P></TD></TR></TABLE></FORM>\n"; return $ret;


Really old HTML $ret .= "<FORM METHOD=POST>"; $ret .= LJ::form_auth(); $ret .= "<TABLE WIDTH=400><TR VALIGN=BOTTOM>"; $ret .= "<TD><IMG SRC=\"$LJ::IMGPREFIX/nerd_small.jpg\" WIDTH=167 HEIGHT=169 HSPACE=2 VSPACE=2></TD>"; $ret .= "<TD><B><TT>command console.</TT></B>"; $ret .= "<P>welcome to the livejournal console. from here administrators can do administrative type things. you will forget the commands, so there is a <A HREF=\"reference.bml\">reference</A>.</TD>"; $ret .= "</TR>"; $ret .= "<TR><TD COLSPAN=2>"; $ret .= "<P><tt>enter commands:</tt><BR>"; $ret .= "<TEXTAREA NAME=commands ROWS=10 COLS=60 WRAP=OFF></TEXTAREA></TD></TR>\n"; $ret .= "<TR><TD COLSPAN=2 ALIGN=RIGHT><INPUT TYPE=SUBMIT VALUE=\"execute\"></P></TD></TR></TABLE></FORM>\n"; return $ret;

(1999 called; they want their tables back)


Out of date special-casing

# Catch misspellings of hotmail.com if ($domain =~ /^(otmail|hotmial|hotmil|hotamail|hotmaul|hoatmail|hatmail|htomail)\.(cm|co|com|cmo|om)$/ or $domain =~ /^hotmail\.(cm|co|om|cmo)$/) { return $reject->("bad_hotmail_spelling", "You gave $email as your email address. Are you sure you didn't mean hotmail.com?"); }

# Catch misspellings of aol.com elsif ($domain =~ /^(ol|aoll)\.(cm|co|com|cmo|om)$/ or $domain =~ /^aol\.(cm|co|om|cmo)$/) { return $reject->("bad_aol_spelling", "You gave $email as your email address. Are you sure you didn't mean aol.com?"); }


Out of date special-casing

# Catch misspellings of hotmail.com if ($domain =~ /^(otmail|hotmial|hotmil|hotamail|hotmaul|hoatmail|hatmail|htomail)\.(cm|co|com|cmo|om)$/ or $domain =~ /^hotmail\.(cm|co|om|cmo)$/) { return $reject->("bad_hotmail_spelling", "You gave $email as your email address. Are you sure you didn't mean hotmail.com?"); }

# Catch misspellings of aol.com elsif ($domain =~ /^(ol|aoll)\.(cm|co|com|cmo|om)$/ or $domain =~ /^aol\.(cm|co|om|cmo)$/) { return $reject->("bad_aol_spelling", "You gave $email as your email address. Are you sure you didn't mean aol.com?"); }

80-90% of our new signups are from @gmail.com


Old bad decisions (that were right at the time)

# remove the SvUTF8 flag. it's still UTF-8, but

# we don't want perl knowing that and messing stuff up

# for us behind our back in random places all over

# http://zilla.livejournal.org/show_bug.cgi?id=1037

foreach my $attr (qw(id subject text link author)) {

next unless exists $it->{$attr} && defined $it->{$attr};

$it->{$attr} = LJ::no_utf8_flag ( $it->{$attr} );

}


And more...


And more...

• Outdated modules


And more...


• Ancient JavaScript


And more...



• Massive duplication


And more...



• Massive duplication

• Bugs that had turned into features


Should you rewrite?


Upgrading Apache

BENEFIT COST

• Moving away from software at EOL

• So much time. (circa 6 months to working

prototype)

• Security fixes • New and exciting bugs

• Not having to downgrade new installs

• But really, a no-brainer

• Easier to explain

• No longer horribly ashamed of ourselves


Switch to Foundation

BENEFIT COST

• Modern framework • So many pages

• Responsive design (better mobile)

• Changes to look/feel (our users are picky)

• Better cross-browser • New and exciting bugs

• Easier to make accessible

• Less individual

• Well documented • No, seriously, SO MUCH WORK

• Kill lurking old HTML • We’re still not doneFriday, January 16, 15

The pros: will you...



• become more compatible with standards/best practices?




• make your code easier to install?





• eliminate project-specific systems?






• reduce reliance on institutional memory?






• reduce reliance on institutional memory?

• benefit your users or your team?


The cons: will you...



• lose a history of bugfixes or security fixes?




• tie up too many of your people, or involve too much retraining?





• be tied to something that might not last?






• need to fork/adapt a standard/module?






• need to fork/adapt a standard/module?

• not benefit your users or your team?


The number one question:


Will you finish it?


Future-proofing


Future-proofing

• Comment everything, in the code itself


Future-proofing


• Be grep friendly


Future-proofing



• Write task lists for your future self


Future-proofing



• Write task lists for your future self

• Regularly install/compile from scratch


Thank you!Denise Paolucci

Dreamwidth Studios - www.dreamwidth.orgSlides: www.slideshare.net/dreamwidth

When your code is nearly old enough to vote

Technology