When your code is nearly old enough to vote

1,307 views

Published on

As time marches on, more and more FLOSS projects are reaching ages that qualify them as 'venerable'. On the one hand, that rich history of constant improvement provides a robust framework upon which to build. On the other hand, that can lead to sections of the code marked "here be dragons" that haven't been touched in this millennium, and the ever-accelerating speed of technology's march can leave you with a balance-sheet of technical debt that would make anyone quail.

This talk is a case study of Dreamwidth Studios, forked in 2008 from LiveJournal.com, a project that began in 1999. With a quarter-million lines of legacy Perl, it's been hard to decide what to modernize and what to leave alone. Come hear our successes, our failures, and a few horror stories of disasters we've stumbled into along the way.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,307
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

When your code is nearly old enough to vote

  1. 1. WhenYour Codebase Is Nearly Old Enough ToVote Denise Paolucci Dreamwidth Studios - www.dreamwidth.org Slides: www.slideshare.net/dreamwidth Friday, January 16, 15
  2. 2. At time of fork: • Perl 5.6 • Apache 1.3 (yes, in 2008!) • BML (custom template language from 1996) • Various Perl modules (usually outdated) Friday, January 16, 15
  3. 3. hic sunt dracones Friday, January 16, 15
  4. 4. 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; } Friday, January 16, 15
  5. 5. 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.) Friday, January 16, 15
  6. 6. 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) Friday, January 16, 15
  7. 7. 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) Friday, January 16, 15
  8. 8. 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; Friday, January 16, 15
  9. 9. 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) Friday, January 16, 15
  10. 10. 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?"); } Friday, January 16, 15
  11. 11. 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 Friday, January 16, 15
  12. 12. 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} ); } Friday, January 16, 15
  13. 13. And more... Friday, January 16, 15
  14. 14. And more... • Outdated modules Friday, January 16, 15
  15. 15. And more... • Outdated modules • Ancient JavaScript Friday, January 16, 15
  16. 16. And more... • Outdated modules • Ancient JavaScript • Massive duplication Friday, January 16, 15
  17. 17. And more... • Outdated modules • Ancient JavaScript • Massive duplication • Bugs that had turned into features Friday, January 16, 15
  18. 18. Should you rewrite? Friday, January 16, 15
  19. 19. 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 Friday, January 16, 15
  20. 20. 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 done Friday, January 16, 15
  21. 21. The pros: will you... Friday, January 16, 15
  22. 22. The pros: will you... • become more compatible with standards/ best practices? Friday, January 16, 15
  23. 23. The pros: will you... • become more compatible with standards/ best practices? • make your code easier to install? Friday, January 16, 15
  24. 24. The pros: will you... • become more compatible with standards/ best practices? • make your code easier to install? • eliminate project-specific systems? Friday, January 16, 15
  25. 25. 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? Friday, January 16, 15
  26. 26. 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? • benefit your users or your team? Friday, January 16, 15
  27. 27. The cons: will you... Friday, January 16, 15
  28. 28. The cons: will you... • lose a history of bugfixes or security fixes? Friday, January 16, 15
  29. 29. The cons: will you... • lose a history of bugfixes or security fixes? • tie up too many of your people, or involve too much retraining? Friday, January 16, 15
  30. 30. 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? Friday, January 16, 15
  31. 31. 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? Friday, January 16, 15
  32. 32. 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? • not benefit your users or your team? Friday, January 16, 15
  33. 33. The number one question: Friday, January 16, 15
  34. 34. Will you finish it? Friday, January 16, 15
  35. 35. Future-proofing Friday, January 16, 15
  36. 36. Future-proofing • Comment everything, in the code itself Friday, January 16, 15
  37. 37. Future-proofing • Comment everything, in the code itself • Be grep friendly Friday, January 16, 15
  38. 38. Future-proofing • Comment everything, in the code itself • Be grep friendly • Write task lists for your future self Friday, January 16, 15
  39. 39. Future-proofing • Comment everything, in the code itself • Be grep friendly • Write task lists for your future self • Regularly install/compile from scratch Friday, January 16, 15
  40. 40. Thank you! Denise Paolucci Dreamwidth Studios - www.dreamwidth.org Slides: www.slideshare.net/dreamwidth Friday, January 16, 15

×