clone remote git to github

I've just made my first remote git repository at github. It's a clone of Matt Trout's Iron-Munger code. Looking back through my zsh history for git commands, this roughly what I did. Comments inline in my awesome 'pre' block.

Repository: http://github.com/spazm/Iron-Munger/tree/master

#setup get information from my new github repository
% git remote add origin git@github.com:spazm/Iron-Munger.git
% git config --global user.name "Your Name"
% git config --global user.name "Andrew Grangaard"
% git config --global user.email granny-github@XXXXXXX

#generated my ssh key, and added it via the github web interface.
% less ~/.ssh/github_dsa.pub

#added this key to my keyring.  This way I don't type my passphrase everytime, yet someone doesn't get access just by grabbing my key.*
% ssh-keygen -t dsa -f ~/.ssh/github_dsa
% ssh-add ~/.ssh/github_dsa

# get my area ready:
% git init
% git add README
#commit first commit locally.
% git commit -m "first commit"

#setup my remote repository, and push to it: (I wonder which of these worked)
% git remote add origin git@github.com:spazm/Iron-Munger.git
% git push origin master
% git remote add origin git@github:spazm/Iron-Munger.git
% git push origin master

#pull in the repository I want to clone:
% git remote add upstream http://hercule.scsys.co.uk/~matthewt/iron-munger/.git/
% git fetch upstream
% git push origin master

# pull in the repository
% git pull upstream master

# push it to my copy at github.
% git push origin master

#start making local changes
% git status
% git add IronMunger/Calculate.pm IronMunger/PlaggerLoader.pm
% git status
% git diff plagger_loader.t
% git add t/plagger_loader.t
% git status
% git add t/stats_saver.t

# commit locally
% git commit

# push to github
% git push origin master

#pull down any changes from the original master
% git pull upstream master

Iron Man Perl, redux.

Badges? We ain't got no badges. We don't need no badges! I don't have to show you any stinkin' badges!

Matt Trout writes in his blog about almost being done with the Iron Man Perl Judging software. He wrote his beautiful modern perl code to pass a suite of tests. But when he put it all together, the system didn't work. So he put out an open call to find out what's up.

This seemed like a good opportunity to do something useful for the community. Also, a chance to read some modern, moose-y perl, and do my first git checkout. Oh, and do some debugging.

I spent much of Saturday afternoon hitting "Y/Ret" in cpan to get my 5.10 debian install up-to-date with the moose core. Once I got my system up-to-date, I started running his tests. Sure enough, most of them passed. One of them didn't clean-up well so failed on subsequent runs. But that was minor.

I started by digging into the heart of the matter. The test calculate.t that verified the date calculation routines. Why did the tests pass and not with the demo data later via plagger_loader.t? I squirelled through the rest of the code, squinting at all the new funny moose bits and got a overall view of the plan.

By now it was late Saturday night, and I was having trouble sleeping. My mother-in-law was visiting, so we'd given her the bed and I was on the couch in the living room. By Santa Monica standards it was super hot (maybe 80F). Since I couldn't sleep, I pulled the laptop back out and jumped back to check one more hunch: "what is the difference between the data for calculate.t and plagger_loader.t?"

AHA! The age-old problem of real world data not being nearly as pretty as test data. All of the post data created in calculate.t was neatly sorted by increasing age. The csv data, plucked from real logs, was a hodgepodge of sorting. Maybe it was alphabetical, but it sure wasn't reverse chronological.

A quick change was called for: Sort the data by reverse date. Where to slip this into the API? 1) Sort the post order when reading the CSV in plaggerloader? 2) sort the post array in Calculate.pm, either in check_both or check. Which change matches the intentions of the API designer? I don't know, that's up to you, Senor Trout.

This experience gave me my first interaction with git. See the next post for my blog entry on cloning remote read-only git to github.

These changes are now up on github.
http://github.com/spazm/Iron-Munger/tree/master

In the mean-time, here's the ghetto-diff version:

PlaggerLoader.pm
Synopsis: add sort { $b->at <=> $a->at }

method _expand_posts_from_file(IO::All::File $file) {
    return [
      sort { $b->at <=> $a->at }
      map $self->_expand_post($_),
        @{$self->_expand_postspecs_from_file($file)},
    ];
  }

Calculate.pm
Synopsis: add my @sorted_posts = sort {$b->at <=> $a->at} @posts; and call check on @sorted_posts instead of @posts.

sub check_both ($check, @posts) {
  my @sorted_posts = sort {$b->at <=> $a->at} @posts;
  return min(
    $check->(1, 10, @sorted_posts), # 10 days between posts
    $check->(4, 32, @sorted_posts), # 4 posts within any given 32 days
  );
}

There is something very satisfying about spending a day or more debugging in a process that eventually ends with adding five lines to the primary code base. It's a feeling of having cut through the accidental complexity to the heart of the matter. Finesse vs Force. Good thing I don't get paid by the KLOC.

Hope this helps! Now when do we get our badges?

perler

Perler, I must say I've never heard this term before the most recent Mongers, when it was brought up as some sort of perlish epithet. Tommy and I had some fun tossing it back and forth afterwards. Along with our plans to release "blah module TWO", as in "oh yeah, I already have that fixed in <legitmate module><TWO>." Ok, maybe you had to be there. So you should come, next time around. Fourth Thursday in August.

I haven't been able to stop thinking about it. perler perler perler. Not having a backstory, I think it's cute. Maybe it's time I "took it back!" ?

(yeah, it's been 10 days... oops)

Slack by Tom DeMarco

I checked out Tom DeMarco's a new book from our company library and started reading last night. I'm about half way through, and I've already had to put it down a couple of times to either nod in affirmation, "Amen, Brother!" or to vent when reminded of workplace ineffectiveness.

Slack : getting past burnout, busywork and the myth of total efficiency is aimed at busy people meant to be "read[able] cover-to-cover on a flight from NY to Chicago." Don't let the slenderness of this 200 page paperback fool you, there is substance contained within. This mirrors the message of smarter work, and avoiding busyness for busyness's sake.

What is Slack? In the prelude, Tom defines for us, "Slack: The unfortunate tradeoff between efficiency and flexibility." Later we expand to "time slack" and "control slack", available looseness in the time or control model that enables the knowledge worker to improve their work, prepare for coming work and generally be more effective and responsive. We can get more efficient in the near term by squeezing out slack but we lose the ability to react and change. In essence helping the bottom-line this year by killing our ability to meet the bottom-line next year.

Squeezing out slack in the name of efficiency is another in line of short-term optimizations that improve short term efficiency but don't improve effectiveness. The thesis here is that if we over-optimize in the short term, we lose the ability to think, plan and prepare.

So far, we've already seen: why overtime is bad for the employee and for the company, why a "hurry up, be busier" mantra can lead people to work slower, the operational cost of turnover, how to recognize and avoid a culture of fear, the costs associated with made-up/over-aggressive schedules, and the myth of the fungible resource. And that's just in the first hundred pages!

More coming once I finish part II, and move on to parts III and IV.

Overview:
Part I: Slack
Part II: Lost, but making good time
  (The effect of stress on organizations)
Part III: Change and Growth
  (The difference between companies that can learn and those that can't)
Part IV: Risk and Risk Management
  (Why running away from risk is a no-win strategy)

new url -- www.LowLevelManager.com

We have a new domain: www.LowLevelManager.com!

This is a little easier than remembering the .blogspot.com address, and will allow me to someday move this off of proprietary google blogging software to an open source perl solution. One of these days.

Update your bookmarks! (the old address will still work)

New Catalyst Book

There's a new catalyst book out, The Definitive Guide to Catalyst: Writing Extensible, Scalable and Maintainable Perl–Based Web Applications.

Update: Buy through This Link and the referral money will go to the Enlightened Perl Organisation.

I'm looking forward to going to my local bookstore and flipping through it. It looks pretty good from the Table of Contents. The authors are Kieren Diment and Matt Trout. I've heard of Trout and the good work he does over at Shadowcat. I hope it's awesome so I can buy a copy.

I definitely feel like I've blundered through Authentication and Authorization before with a variety of frameworks, that's the sort of think where I want to plug in an obvious system for Authentication, and then build appropriate Authorization rules without shooting myself in the foot. Let's hope this can help walk me through that part.

Page 28 in chapter 2 starts a section on "Object Oriented programming with Moose," so that sounds pretty cool.

Table of Contents

1. Introducing the Catalyst Web Application Framework
2. Catalyst Setup and Background Knowledge
3. Your First Catalyst Application
4. Extending LolCatalyst-lite
5. Deployment
6. Database Models
7. The Catalyst Dispatcher
8. Authentication and Authorization
9. Interacting with Web Services in your Applications
10. Extending Catalyst
11. Catalyst Cookbook
12. The Reaction Component UI Framework
13. Compiling your own Perl
14. Making your own CPAN Mirror with CPAN::Mini or minicpan.sh

July Los Angeles Perl Mongers Meeting -- Thu Jul 16

Hello Los Angeles!

What: Los Angeles Perl Mongers Meeting
When: 7-9pm
Date: Thu, July 16, 2009.
Where: The Rubicon Project HQ - 1925 S. Bundy, 90025
Theme: Perl!
Food: Pizza and BEvERages provided.
RSVP: Responses always appreciated.

Presentations:

1. Mojo and Mojolicious -- A next generation web framework for the Perl programming language. Presentation and examples. (Xantus).
2. Either:
   • Interviewing perl programmers -- How to find the best: what to look for, what to ask, what to say: a Q&A. (Mon-Chaio Lo)
   • Continuous Integration and testing. (Mon-Chaio Lo)

About our speakers:

David W Davis is a software engineer who specializes in rich front-end applications and scalable back-end servers. He has a special interest in Comet, WebSockets and various other emerging technologies. He is currently rewriting his cometdesktop project using the mojo web framework.

Mon-Chaio Lo is a Software Engineer and Team Lead at the Rubicon Project. He is a fan of TDD and agile methodologies. He was previously at CarDomain.com leading a Ruby team.

About your host:

• Andrew Grangaard is a Senior Software Engineer at the Rubicon Project, and long time Perl Monk(ey).
• The Rubicon Project (http://www.rubiconproject.com)
  The Rubicon Project is an Advertising Technology Company headquartered in Los Angeles. Their mission is to automate the selling and buying of online advertising.

See you at 7 on Thursday the 16th.

View Rubicon Project in a larger map

Perl Monks and Mongers

Tired of being a "Level 1: Initiate" at perl monks, I spent a few hours yesterday answering incoming questions. Answering other people's code questions can be super fun, especially when I'm laying in bed waiting to get over a cold.

I'm really happy with how my Hash walker with closures turned out.

When I left to drive up to the Thousand Oaks Perl Mongers meeting, I was at 18 points. When I checked afterward, I'd been bumped up to 20 points -- the threshold for Level 2: Novice. Now I get two votes to mod up&down other posts. FEEL THE POWER!(my perl monks profile).

The TO perl mongers meeting was fun. Aran Deltac talked about his experience at YAPC and then Shawn Faison talked about Genetic Programming, evolving programs through iterated competition with mutation and crossover. I liked that he was talking about something he's doing on his own time for fun because he finds it interesting. Fascinating stuff.

Shawn also mentioned a desire to have a perl 6 / rakudo hackathon at one of the PM meetings. He got a response on his blog from Patrick Michaud (PM), the Pumpking of Rakudo! So now we totally have to do it!

pretty printing perl with enscript

I've been using enscript for years to format source code for printing. In particular the -2Gr flags for two-up, landscape prints with "Fancy header".

I recently found there are some colorization flags, -E for syntax highlighting and --color for colored syntax highlighting. -E can take an optional lang flag, perl in our case.

So now my pretty printer uses 'enscript -2Gr --color -Eperl' to create the postscript file and then ps2pdf to dump to pdf.

My perl wrapper and self-referential pdf output. Script requires enscript to be installed.

This is the shell code that the wrapper ends up evaluating: enscript -MLetter -Gr2 --color -Eperl 'code_to_pdf.pl' -p - | ps2pdf - "$HOME/public_html/pdf/code_to_pdf.pdf"

% enscript --help-highlight |egrep '^Hi|^Name|^Desc|^$'

Highlighting is supported for the following languages and file formats:



Name: ada

Description: Ada95 programming language.



Name: asm

Description: Assembler listings.

Name: awk

Description: AWK programming language.


Name: bash
Description: Bourne-Again shell programming language.

Name: c
Description: C programming language.

Name: changelog
Description: ChangeLog files.

Name: cpp
Description: C++ programming language.

Name: csh
Description: C-Shell script language

Name: delphi
Description: Delphi programming language.

Name: diff
Description: normal diffs

Name: diffs
Description: side diff

Name: diffu
Description: unified diffs

Name: dylan
Description: Dylan Programming Language template for Enscript.

Name: eiffel
Description: Eiffel programming language.

Name: elisp
Description: Emacs LISP.

Name: forth
Description: Forth Programming Language.

Name: fortran
Description: Fortran77 programming language.

Name: fortran_pp
Description: Fortran77 programming language with cpp-statements

Name: haskell
Description: Haskell programming language.

Name: html
Description: Hypertext markup language HTML.

Name: icon
Description: Icon Programming Language.

Name: idl
Description: IDL (CORBA Interface Definition Language)

Name: inf
Description: GUI INF Script language

Name: java
Description: Java programming language.

Name: javascript
Description: JavaScript language.

Name: ksh
Description: Korn shell programming language.

Name: lua
Description: Lua Programming Language template for Enscript.

Name: m4
Description: macro processor

Name: mail
Description: Mail and news articles.

Name: makefile
Description: Make program's definition files.

Name: matlab
Description: Matlab programming language.

Name: nroff
Description: Manual pages formatted with the nroff program.

Name: oberon2
Description: Oberon 2 Programming Language.

Name: objc
Description: Objective-C programming language.

Name: outline
Description: Outline text.

Name: oz
Description: Mozart/Oz Programming Language.

Name: pascal
Description: Pascal programming language

Name: perl
Description: Perl programming language.

Name: postscript
Description: PostScript programming language.

Name: pyrex
Description: Pyrex - a Language for Writing Python Extension Modules

Name: python
Description: Python programming language.

Name: rfc
Description: RFC and Internet Draft reformatter.

Name: ruby
Description: Ruby programming language.

Name: scheme
Description: Scheme programming language.

Name: sh
Description: Bourne shell programming language.

Name: skill
Description: Cadence Design Systems lispy language.

Name: Smalltalk
Description: Smalltalk Programming Language.

Name: sml
Description: Standard ML Programming Language.

Name: sql
Description: Sybase 11 SQL.

Name: states
Description: States program's definition files.

Name: synopsys
Description: Synopsys dc shell scripting language

Name: tcl
Description: Tcl programming language.

Name: tcsh
Description: TC-Shell script language

Name: tex
Description: TeX/LaTeX command, comment and math highlighting.

Name: vba
Description: Visual Basic (for Applications)

Name: verilog
Description: Verilog hardware description language

Name: vhdl
Description: VHSIC Hardware Description Language (VHDL)

Name: vrml
Description: Virtual Reality Modeling Language (VRML97)

Name: wmlscript
Description: WMLScript language.

Name: zsh
Description: Z-shell programming language.

returning apache 204

"Can you return an HTTP 204 (no content) response from vanilla apache, from within the conf file? For any request that matches a regex?" asked my coworker. It seemed simple enough.

A quick search showed people building little cgi scripts to fork off. That seemed like wasteful overhead, especially since this was basically to be used as a kill switch to lessen a potential data flood.

Ask Apache has a nice list of all available HTTP response codes and had a link to mod_alias redirect, which is right next to the docs for RedirectMatch

Other status codes can be returned by giving the numeric status code as the value of status. If the status is between 300 and 399, the URL argument must be present, otherwise it must be omitted. Note that the status must be known to the Apache code (see the function send_error_response in http_protocol.c).

Putting together the Redirect documentation with the RedirectMatch documentation, we see that yes, we can send a custom 204 back. Here is a quick example that responds with 204 to any request matching foo with any characters after it. #RedirectMatch example using mod_alias RedirectMatch 204 foo(.*)$

His next question was more difficult, "If we're using rewrite rules and redirect match, which one 'wins' if they both match the same url? We're using [L] in rewrite rules to force matches". That one I'm still wondering about.

Redirect directives do take precedence over other mod_alias directives, like Alias and ScriptAlias:

Note: Redirect directives take precedence over Alias and ScriptAlias directives, irrespective of their ordering in the configuration file.