Book Review: Ace on the River

I just finished (Aug 28th listening to Ace on the River, by Barry Greenstein. Read by the author.

This is a very interesting look into the life of a professional poker player. It is more a memoir than an "Advanced Poker Guide". It does include a lot of information on playing the larger game -- building a life while playing poker.

Thinks I liked:

• Talking about the difference between tourney and cash game styles. Especially about how the cash game people look down on the tourney players, yet are jealous of the "respectability" afforded the tourney players.
• The last section walks you throw several real tourney hands, and he walks you through how he played them, and what the optimal plays were. On the audio version, there are pauses to force you to think about the situation and make your own answer before he tells you his thoughts.
• While tourney payouts are top heavy, so it's best to win. it is important to guard your chips more than a cash game, since there is no rebuy. This doesn't always mean cautious, tight play. Really it means evaluating where your stack is relative to the big blind -- and in a tourney the blinds are always moving up so they are a big chunk of the stacks. It may well be that you take a big chance when you're below 8 big blinds, because you've got to take it to stay alive.
• Winning early hands gives chip power. Use your big stack "as a bludgeon" on your opponents
• Conversly, realize the power of the short stack (more useful in a cash game). Easier to get odds to double you up. In a tourney, it's still nicer to have the big stack!
• The emphasis on maintaining a life outside of the game.

With a forward to Doyle, how could you not be interested?

Business Motivation

An important message and a beautiful example of design.
Enlarge the image to see the full message.

Intrinsic > Extrinsic

Found this on Dan Pink's blog.

LA PM tonight.

I'm Looking forward to seeing you tonight at 7.
1925 S. Bundy, LA, CA, 90025.

I'll be your speaker tonight, as our originally planned speaker has an injury and can't make it. I've put together a presentation and a Q&A discussion.

Presentation:
* Accessing the JIRA SOAP api using JIRA::Client.
JIRA::Client is a thin wrapper around SOAP::Lite that provides a few additional convenience methods. I'll compare and contrast a perl and ruby implementation of a simple script to query bug counts.

Discussion:
* Care and feeding of third party Perl modules at work -- how do you do it?
I've asked a few of you this question, and heard a variety of answers. I think it'll be interesting to discuss the various strategies that are out there. How is this not a solved problem that everyone knows? (Or am I just out of the loop?)

I have blog posts on both of these, if you'd care to comment before the meeting: access-jira-api-from-perl-with
care-and-feeding-of-third-party-modules

Info, directions and parking map: losangeles.pm.org

cryptic git status: "failed to push some refs"

A first stumble with git: error: failed to push some refs to 'git@github.com:/spazm/examples.git'.

And here's how I fixed it.

[agrangaard@willamette]% git fetch                               129 ~/examples
[agrangaard@willamette]% git push                                  0 ~/examples
To git@github.com:/spazm/examples.git
 ! [rejected]        master -> master (non-fast forward)
error: failed to push some refs to 'git@github.com:/spazm/examples.git'

In my case, this meant I had a merge conflict. git status showed no changes and a git fetch wasn't listing an action nor listing any changes.

Once I realized I needed to do a git pull, more specifically a git pull origin master, the merged code was pulled in.

[agrangaard@willamette]% git pull origin master                    0 ~/examples
From git@github.com:/spazm/examples
 * branch            master     -> FETCH_HEAD
Auto-merged jira.conf
CONFLICT (content): Merge conflict in jira.conf
Automatic merge failed; fix conflicts and then commit the result.
[agrangaard@willamette]% git status                                1 ~/examples
jira.conf: needs merge
# On branch master
# Changed but not updated:
#   (use "git add ..." to update what will be committed)
#
#       unmerged:   jira.conf
#
no changes added to commit (use "git add" and/or "git commit -a")
[agrangaard@willamette]% vi jira.conf                              1 ~/examples

Since there was a manual merge needed, I opened jira.conf and cleared out the diff. Then I committed it locally and in the master repository:

 [agrangaard@willamette]% git add jira.conf                         1 ~/examples
[agrangaard@willamette]% git status                                0 ~/examples
# On branch master
# Changes to be committed:
#   (use "git reset HEAD ..." to unstage)
#
#       modified:   jira.conf
#
[agrangaard@willamette]% git commit                                0 ~/examples
Created commit e69f257: Update jira.conf
[agrangaard@willamette]% git status                                0 ~/examples
# On branch master
nothing to commit (working directory clean)
[agrangaard@willamette]% git push                                  1 ~/examples
Counting objects: 13, done.
Compressing objects: 100% (9/9), done.
Writing objects: 100% (9/9), 1.71 KiB, done.

And now my local check-out is in sync with my remote repository at github. Woo!

Care and feeding of third party perl modules at work -- how do you do it?

How do you install and maintain third party perl module dependencies in your work perl code base? How about your own perl modules?

I'll be hosting an open discussion on this tomorrow at the Los Angeles Perl Mongers meeting tomorrow. (Wed 2009-09-23). Let's see what we can dig up.

I've been at a few perl companies now, and they all seem to have taken different approaches. Yes, TIMTOWTDI, but TIMTOWTDIWrong aka TIMTOWTFIU. This seem like it should already be a "solved problem," so what are the best practices in this arena?

Popular memes in this space:

• System Perl
  • Install to system perl via cpan. Upgrade whenever.
  • Install to system perl via package manager, deb or rpm. Manually roll unpackaged cpan modules through a tool like cpanflute.
  • Sub part 1: install those rpms/dpkgs manually
  • Sub part 2: run a local yum/apt-get/dag repository internally to pull "trusted" internally packaged cpan modules
  • Install via system tools (puppet, etc) live on each box from a configuration file of needed modules.
• (shared) Application Perl, compile your own single perl version for internal applications
  • Install into the application perl via cpan
  • check into local source control source for third party modules, install during application install.
  • check into local source control binary version of third party modules.
• Install into local library, using Local::Lib with either application or system perl.
• Install from a "mini cpan", maintained internally and populated with vetted, approved third party modules.

How do you do it?

If you're just installing a handful of modules, the ad-hoc approach may be sufficient. Right now I'm writing some new apps with Moose, and installing that module dependency chain seems crazy without figuring out a plan. With Moose and the MooseX namespace there are probably 20+ modules I want to install, and many of them are improving and releasing rapidly. Edit: Sorry Dave, you're right, not hundreds of modules. I didn't mean to spread Moose FUD, I love the Moose

Plan: flesh out this page with links to the current wisdom on these matters, from fellow iron mongers, perl monks, etc. I know I've ready half a dozen recent articles on this, time to find and organize them.

Access the JIRA API from Perl with JIRA::Client

Quick problem: I want to know the bug count for the upcoming release, which encompasses two jira projects. I'd like to know the count of open, closed and resolved bugs for each of the two projects and combined. I have created several stored filters that show me the bugs/issues/tickets in each category, and a count.

Because the issues are in multiple projects, combining them in one search and filtering by closed status is daunting directly in Jira.

A quick CPAN search later and I had JIRA::Client installed on my workstation. After jumping through a few hoops I got the JIRA admin to enable SOAP API access. API access is installed but disabled by default.

The hardest parts was finding the correct API docs for our version of JIRA. I didn't think 3.11 to 3.13 would be a big difference, but it was.

Tonight a threw together a quick script to grab the bug counts across each of my 6 saved searches and return the bug count. It started out looking like this: Eventually I prettied it all up with flags, config files and documentation and pushed it to my github repository named "examples": jira.pl

Is there a way to embed a file from my github the same way as I can for gists from gist.github.com?

Pair Programming with gnu screen

Good ole' screen, nothing beats screen
-- bart simpson (almost)

Setting up a screen session for sharing

1. screen needs to be setuid root for multiuser sessions to work
2. set the multiuser flag to on
3. use acladd or aclchg to add acl rights for other users. This must be done after enabling multiuser.

make screen setuid:
ls -l $(which screen)
sudo chmod +s $(which screen)

Note in zsh this could be simplified by using = to replace the $(which ) block.
ls -l =screen;
sudo chmod +s =screen

Update: On recent ubuntu installations (9.04 and newer), /usr/bin/screen is a wrapper around /usr/bin/screen.real. /usr/bin/screen.real is the file that needs to be made setuid.

sudo chmod +s /usr/bin/screen.real

Note: I'll use "^A" to represent the screen key.

^A:multiuser on
^A:acladd usertwo
Now usertwo can see the screen session of userone with the following command (The trailing slash is important!)
  screen -ls userone/

And connect with either of:

• screen -x userone/
• screen -x userone/name-of-session

In the latter case, name-of-session is used as a search string within the available named screen sessions.

If you used acladd, then usertwo comes in with full capabilities -- write and execute. It is possible to restrict users to write bit (allows sending chars to the screen, assuming no one else has write-lock) and execute bit ( allows screen commands to be run ). These commands can be granted on a per-screen and per-user basis.

Check out more on the screen man page.

Now, you and your remote pair can get back to work. One of you coding, one of you watching. Both of you creating.

Hints:

• try and get this set up and running while userone and usertwo are both local so it is easier to debug.
• you'll need to own your own pty. This is not normally a problem, unless you are using su or sudo to change users, which you may want to do while testing.
• don't forget to set multiuser to on *before* trying to set the acl commands, I think that was important.
• Use an out-of-band method for communicating. I like a VOIP connection or even a ytalk or irc back channel. ( I'm still waiting for a jabber based tool that will do all of this for me, all while integrating into vim. )
• give your screen session a useful name with the -S flag, like screen -S shared or screen -S bug_1234
• I have vim on one screen, open with my perl module and my .t test (vim -o foo.pm t/foo.t), and a second screen primed for running the test file. If test output is short, I just run it in the vim session with :make , but for long, slow, verbose tests, I run them in a second window. This lets my screen partner run tests at his/her leisure while I'm typing code.
• set your shell to auto-update the screen title for a given screen when a command is run.
• use double-quote ^A" to get a named list of screen windows, choose the window to switch to by number, j/k or arrows. These two make it easier to follow what is going on.

Welcome Aboard: Others Online

The Rubicon Project announced the acquisition of Others Online today. Welcome to the team guys! It's nice to finally be able to talk about my new coworkers.

Official announcement

With today’s acquisition of Others Online, Rubicon Project aims to provide its publisher customers a way to find the best data on audience segments from among all those data providers. Others Online, which apparently started out several years ago as a social network play, offers several audience data-related services—in particular an “affinity scoring” service that determines how strongly a person is interested in particular brands, products or topics.
-- Businessweek

Motivation -- Autonomy, Mastery and Purpose

"Autonomy, Mastery and Purpose. It's not Utopian, I have proof."
--Dan Pink.

This TED talk from Dan Pink on the economics of motivation. This is an awesome presentation with good information and a compelling speaker. The thesis: Knowledge work doesn't improve with higher incentive rewards, in fact it may be hindered. Why is there a mismatch between what Science KNOWS and what Business DOES?

This has been replicated over and over and over again for nearly fourty years. These contingent motivators, "if you do this, then you get that," work in some circumstances but for a lot of tasks they don't work or often they do harm. This is one of the most robust findings in Social Science and also one of the most ignored.

The talk dovetails nicely into the book I'm reading Predictably Irrational by D. Ariely, which I would suggest for further reading. As well as Management Rewired, which is next on my reading list.

Two quotes from Ariely used in this talk:

"As long as the task involved only *mechanical* skill, bonuses worked as they would be expected: the higher the pay, the better the performance."

"But once the task called for "even *rudimentary cognitive skill*," a larger reward "led to *poorer performance*."

What would Peter Drucker say? I think he'd approve. Drucker "maintains that people motivate themselves. You can't motivate them; you can only thwart their motivation.To be an effective leader you must recognize that the business you're you're in is the obstacle identification and removal business. "source.

September LA Perl Mongers Meeting

See you all in a week-and-a-half! Please let me know if you are interested in presenting!

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

Our website has been updated with the current info as well as titles of past talks.

I haven’t recovered enough from the previous meeting to write up a recap, but it was definitely off-the-hook. We ranged from co-routines to Moose to Jaeger shots, with the last guests stumbling off at 1:30am after the poker game.

Thanks,
Andrew

Remembrance.

Mallory Portillo wrote:

In honor of the fallen (friends of the Rubicon family):
Todd Beamer
Scott Weingard
John Murray

It is often said that out of great hardship comes strength. Instead of letting the tragic day tear us apart as a country, we came together as a nation and mourned together, helped each other, and shared memories of the event and of the fallen. It is our saddest day but likely our proudest moment. We showed, as a united country, that freedom is a strength not a weakness and in the face of great tragedy we stop at nothing to come together and hatred cannot tear us apart.

Eight years later, we will all likely remember the exact moment when we saw the first plane hit the World Trade Center but more importantly this day will always be a time for us to reflect on what is so great about this nation and its people. Today in the LA office, we are having a pot luck to share food amongst friends and also raise money for a local non-profit. In the spirit of 9/11, please take a moment wherever you are to share with others (even if it’s just a smile on the street or an email to an friend).

To those who knew Todd, Scott and John, my condolences on the tragedy of your loss.

Thank you for sharing this act of Remembrance. None of us are alone in our grief, for we are all united. Let us hope that the legacy of this day will be of a united, strengthened people and a lasting day of Service.

This is my third anniversary back in California and it has felt so strange for this to be a "normal day" for so many people. A day of Remembering puts into stark relief the pettiness of our regular days and reminds me how lucky I am to be loved and living a wonderful life. Mallory, thank you for reminding us why the Rubicon Project is such a special place.

peace and love,
Andrew

"On a day when others sought to sap our confidence, let us renew our common purpose, let us remember how we came together as one nation, as one people, as Americans united, Such sense of purpose need not be a fleeting moment."
— President Obama, September 11, 2009.

Perl 6 hackathon

Update: Rakudu Release #22 has been named after us!
blog | official announcment

Our (TO.pm) Perl 6 Hackathon was last Saturday. I had a blast, waking up early and spending Saturday morning tackling a new challenge. Aran & ValueClick were wonderful hosts! Thank you! In theory, our plan was to make a simple DB back aggregation website to test the state of the art in perl6 land. My goal was to show up and hack away, and see what there was to see.

We set up ourselves on a communal account on a shared host. I set up a common screen session which made it easy and fun to follow each others work. There may be new tools for communal editing (subethaedit and the like), but screen has a certain beauty and simplicity that is perfect for this "four laptops in a room" coding style. I also made a local git repository to snapshot our process. The local repo is complete, but I had problems pushing it to github. I'll get that working soon and push it up.

Before the meet-up, Todd had made gains getting sqlite3 to work with perl6 + rakudu. (Honestly I was mostly lost by his birdseed code but it is definitely neat). I spent much of Saturday providing pairing with him to provide assistance getting his stuff working in our shared environment. Frustrating that updates to rakudu knocked out his working code, but he has since moved on to get it working another way.

As you know, Mitch and I were working on the cyanide system. Well, earlier today it ate itself. But, these little set-backs are just what we need to take a giant step forward. Right, Kent? Needless to say, I was a little despondent about the melt down, but then, in the midst of my preparations for hari kiri, it came to me. It is possible to synthesize excited bromide in an argon matrix. Yes, it's an excimer frozen in its excited state.
--Real Genius

I didn't actually write anything in perl6 during the hackathon. I did get to read and edit some PIR (parrot code). I read the scripts that Aran and Shawn put together. I think Aran's "game" is even still live on http://sponge-six.thousand-oaks-perl.org. Notice the empty button on the cave page, that's the result of the body of a for loop getting executed, even though the array is empty. Bug? Feature? Confusion?

I had a great time. I enjoyed hacking together a working environment and smoothing rough edges, that plays well to my skills. I hope to do something similar in the future, "social coding" is fun! Give it a try. Get involved! Your Language and Your World are what you make them!