Catalyst Credentialing

I really like the Catalyst web framework. It handles all of the boring, repetitive details while leaving me the juicy, fun pieces of coding. For the most recent web application, I added authentication. I pieced together the functionality by reading module documentation. Here's what I learned - all in one place.

Catalyst has a plugin for authentication - Catalyst::Plugin::Authentication. It performs authentication in two steps: look up and password check. Catalyst calls these store and credential respectively. The store accesses your list of users (look up). The credential then compares the password.

Okay, let's walk through this. Henry comes to your web site. You greet him with a normal looking login screen. Henry types in his user name and password. Then he hits theLogin button. Your backend code passes off the user name and password to Catalyst::Plugin::Authentication. The plugin searches the store for the user name. At this point, all we know is that this user is on our list of valid users.

Next, the plugin compares the password Henry typed to the password in his user record. If they match, Catalyst::Plugin::Authentication authenticates Henry and he logs in successfully. Now we know that Henry is who he claims.

The User List

To use Catalyst::Plugin::Authentication, you first configure a store. Remember, the store is where you keep your list of users. Search CPAN for Catalyst::Authentication::Store. There's a whole bunch of them. Shoot, they even have one for when you don't need a store

The store populates a user object with the user's information. The exact fields depend on what your store holds. That's good news. Catalyst::Plugin::Authentication provides standard ways of checking the user without limiting the information you keep.

I used Catalyst::Plugin::Authentication::Store::DBIx::Class. The application keeps a list of valid users in an SQL database. The examples had everything to get it up and running.

Check the Password

99% of the time, you can use the simple Catalyst::Authentication::Credential::Password. It compares the password Henry typed with the password in his user record. Catalyst::Authentication::Credential::Password fully supports encrypted passwords. This part was dead simple to setup.

Unfortunately, my application required a little more. Work uses Active Directory as a single sign-on system. My Linux server accesses it through LDAP. To validate a password, I actually have to log into LDAP with that user name and password. If the query returns a record, then the password is valid. My code never sees a password from the LDAP server. And anonymous queries fails.

I couldn't find an existing Catalyst credential for this type of password check. So I wrote one. Turns out much easier than I thought. Catalyst::Plugin::Authentication calls the authentication method in the credential. Then the credential code calls down into the store for loading the user.

My custom module loads the user from the database with Catalyst::Plugin::Authentication::Store::DBIx::Class. If that succeeds, it then queries the LDAP server with the login and password typed by the user. This is not the normal way that you authenticate with LDAP. Our setup at work is, well, odd.

I created the custom credential module specifically for our setup. Server name, dn, and all of the LDAP settings are hard coded into the module. On the up side, it makes adding single sign-on a piece of cake.

4.01 != 5

Ran into an interesting problem at work this week. And when I say "interesting", I mean "crazy annoying". See, I developed this small Catalyst web application on my Linux laptop. Added cool gradients, box shadows, and round corners using CSS. Everything looked GREAT!

I moved the application onto our test web server. The app should work exactly the same, right? Yeah, I didn't buy it either. Type the URL into Chrome and pow - there's no background on the links. These links perform actions. So I styled them like buttons. All of the styling disappeared.

Long story short, the style sheet set the --webkit-appearance property for those links. I thought that it made the links all the same width. Turns out it does more, and that more messed up their appearance under Windows. Remove --webkit-appearance and the links looks like buttons again.

Now how do I make them the same width? The correct property is display: block. Poof - we're back and running!

Pull up the same page under Firefox. Everything looks great. Links still look like buttons. I'm making good progress here.

Internet Explorer 8 comes last. Ugh! This page is all wonky. Worse - the standard elements I copied from the main web site look all wrong. That's impossible. That exact same HTML appears just fine on our main page. Why not for my page?

I'll spare you all of the dead ends inherent in debugging. In the end, the problem came down to the <!DOCTYPE> declaration in the HTML. Dumb me, I copied it from an older project. So this current document declared the 4.01 DTD. And the HTML content blithely contained HTML5 tags. Oddly, Chrome and Firefox both ignored this contradiction. IE ignored the HTML 5 tags - making the page look downright nasty.

Knowledge in the World
This little experience reminded me about The Design of Everyday Things by Donald Norman. The book talks about the distinction between knowledge in the head and knowledge in the world. See, my problem and its solution with <!DOCTYPE> completely dealt with knowledge in the head. That in and of itself is another problem.

Nothing in Chrome, Firefox, or IE told me the problem. Yet all three clearly saw the contradiction.

Error messages are very difficult to do right. Users really don't care about the technical details. Shoot, I'm a programmer and I don't care about the technical details. I want to know how to fix the problem! Error messages should put knowledge in the world. When I went looking for the error, a message about  tags not matching the DTD would have gone a long way. It would have taken knowledge the browser had and placed it in the world - so I could see it.

That brings up another good point - know you audience. Error messages for developers leave hints. Point a good developer in the right direction and they'll find the solution. Users, however, may require more hand holding. I would never expect a browser to show users messages about DTD's and HTML versions. Communication means understanding.

Litterbugs and Dirty Houses

Three things happened this last week that all struck a chord. For better or worse, my mind drew a connection between these events. Let's see where this leads...

The first event happened on Saturday. The missus went shopping for pre-school clothes. No, not her pre-school - Vania's (our 4 year old). My wife went shopping with the van. The van has Vania's one and only car seat. I expected to visit the library and park, taking the girls with me in the van.

So there we are standing in an empty garage, Dad, Deanna, Lucy, and Vania. I spent the next hour distracting Vania - who expected to go to the park. Why? Because my wife is uncomfortable driving the car. She can drive it. She has driven it. She doesn't want to drive it.

The second event occurred at church. I was standing around outside. A girl and boy walked along the street. I watched the boy unwrap an ice cream cone. Without even missing a beat, the boy dropped the wrapper right in the grass. Never even looked back or down.

The third event happened on the way to work. I drove by a business owner walking by the highway picking up trash. People had hurled fast food bags, cups, and wrappers from their car onto his property. Bags and wrappers attract bugs. They look ugly.

These three things reminded me of the book Leadership and Self Deception: Getting Out of the Box by the Abinger Institute. The book discusses how we view people as objects. In this state, we hold a fundamental disrespect of other people. Those three events display that fundamental disrespect.

Take the boy with the ice cream wrapper. He had a problem - how to get rid of the useless wrapper. Did the boy solve the problem? Well, no. He imposed his problem onto someone else. Now someone at the church will pick up the wrapper and they must find a way to dispose of it. See how the problem still remains - getting rid of the useless wrapper. Just the responsibility shifted.

The missus did the same thing. Driving the car presents an inconvenience. Taking the van imposed inconvenience on the rest of the family. It didn't overcome anything. It shifted the responsibility. That shifting - the imposition - shows a fundamental disrespect for the person on the receiving end.

I read another Slashdot discussion vilifying the user interfaces for GNOME 3 and Unity. Personally, the new interface is growing on me. Since I just finished the book Psychology of Everyday Things, I wondered how it applies. So with five minutes contemplation, I came up with visibility and gulf of evaluation.

Principle of Visibility
A person has to know what they can do. Visibility tells the designer to make possible options visible. You won't know what you can't see.

Okay, Unity starts up with a large empty area, a gray bar at the top, and some pictures on the left side. What now? All of the geeks immediately said push the icons. And there lies the problem. Notice that our imaginary geek called them icons. He knows that they are and what they do. To him, the next action is visible.

Our imaginary geek has knowledge in the head - he knows what those pictures are and what actions they afford. Other people do not have this knowledge. The innate actions are not visible.

Okay, for the Slashdot crowd, this is a pretty poor example. Anyone discussing user interfaces on Slashdot knows about icons. Do they know that right clicking brings up a menu? Or that you can create your own menus, effectively making drawers? Where do you go to look at everything installed? Finding these answers means fumbling around the interface. I'm not getting work done while I'm fumbling.

Unity relies on knowledge in the head. You have to know certain things for Unity to be useful. That violates the principle of visibility. A menu puts knowledge in the world. You see all of the choices right in front of you without any extra knowledge. Knowledge in the world is easier to learn.

The Unity and GNOME developers are right, though - knowledge in the head is faster. Once I know the tricks, Unity is more efficient than the old menu structure. The problem is how to move people from knowledge in the world to knowledge in the head. Doing that by fiat leads to revolt.

Big Icons
Unity's icons are way too large. No, I am not being hypocritical. For one single icon, bigger is more visible. When I'm exploring 200 for something that looks interesting, I want more options. Bigger icons leave less room. Now I have to scroll or page through the options. To compare options, I have to remember information about what I saw two screens ago. Unity make me memorize things.

See - the interface makes me do more work. That's terrible. A computer is supposed to help. Adding tedious memorization does not help. The interface steals my time and energy.

Gulf of Evaluation
This is pretty easy to explain - Unity is SLOW. It has a noticeable time lag between pressing the Dash key and being to type into the search box. Shoot, randomly, the search box doesn't have focus. I hit the Dash key, start typing the program name, and pow - nothing. I expected to see the icon for my program. Instead, Unity lost my typing and I have to start over again.

As we perform actions, people check the results. Did this action move me closer to the ultimate goal? That is evaluation. The time between performing an action and seeing the results is the gulf of evaluation. We call larger gulfs interruptions. It's rude to interrupt, even for a computer.

With the user interface, we want to keep this gulf very, very small. Your action should have an immediate, verifiable consequence. Unity fails when it takes too long displaying the Dash.

Thoughts?
Judging user interfaces is like judging art. Everyone has different tastes. I memorize commands easier than symbols (icons). For me, GNOME Do was perfection. That most definitely affects my perception of Unity. We'll have to see where Unity goes next...

Working in Your Strengths

I'm sorry this started out on such a negative note. The guy I work with - Nik - once quoted this idiom: worry is like praying for what you don't want to happen. Why in the world would I invite the stuff we don't want? That's crazy! Instead, we're going to stop looking at negative things and instead focus on the positive. Let's work on the good things - I want more of those.

And so you don't think that I'm completely insane, Philippians 4:8 says Finally, brothers and sisters, whatever is true, whatever is noble, whatever is right, whatever is pure, whatever is lovely, whatever is admirable—if anything is excellent or praiseworthy—think about such things. You go where you look. If that's true, why do we spend so much time looking at our weaknesses?

This is how the book First Break All the Rules (by Marcus Buckingham and Curt Coffman) begins. People waste a lot of time trying to fix weaknesses. I look, examine, and analyze my weakness. What happens when I eat, sleep, and live that weakness? I'm miserable. I do things that I can't do well. I never really make a lot of progress. I feel like a complete failure. And that's helpful how?

Instead, why not spend time and energy strengthening things that I'm already good at? Proverbs 22:29 says Do you see someone skilled in their work? They will serve before kings; they will not serve before officials of low rank. Take a strength and make it something exceptional. Now that's cool!

Talents and Skills
At this point, it is important to understand the difference between strength and skill. Ever heard the phrase work to your strengths? First Break All the Rules calls them talents. God created you in a unique way. He made you so that some things come easily and others don't.

Imagine these as roads inside of your brain. Talents run like interstates - four lanes, wide open, and a high speed limit. Add more lanes, smooth out the ride, then you go from point A to point B a lot faster. Like the road system, you have different levels of talents. Interstates represent your strengths. Other talents are simply highways, county roads, dirt lanes, or even underbrush.

As you may imagine, interstates get you more places faster. Underbrush goes nowhere. Some things feel easy. You enjoy them, lose track of time, and feel great when you're done. That's driving down the interstate.

Highways run a close second. You make good time. Traffic flows freely. These talents have a lot of promise too.

County roads are okay. You can get things done. Though you'd avoid them if you can. Improving them doesn't really get you anywhere sooner.

Let's just skip right to underbrush. Face it, in some things I have no talent. And that's okay. I won't waste my time on them. Now remember, the talents aren't a waste of time. Me working on them is a waste of time. I could spend years taking voice lessons and never be better than mediocre. Why? I'd rather spend those years working on my strengths. They'll become exceptional. Mediocre or exceptional - not much of a decision is it?

I'm using a lot of generalities. Talents are like that - general. You cannot learn talents. You're born with them. Skills, on the other hand, you learn. Skills are things that you do. They're physical manifestations of your talents. My best skills are those that correspond with my strongest talents. That is working in your strengths.

So What?
You used to make a joke of putting domestic engineer as an occupation. Take it seriously instead. I'm the employer. This is your job. The great thing about this job - you have the power to make it whatever you want! Don't change who you are. Let's change the job so that it fits you.

We begin with some career discovery questions. These questions come from First Break All the Rules. Their purpose is identifying talents:

• How would you describe success in your current role? Can you measure it?
• What do you actually do that makes you as good as you are? What does this tell you about your skills, knowledge, and talents?
• Which part of your current role do you enjoy the most? Why?
• Which part of your current role are you struggling with? What does this tell you about your skills, knowledge, and talent? What can we do to manage around this?
• What would be the perfect role for you? Imagine that you are in that role. It's 3pm on a Thursday. What are you doing? Why would you like it so much?

We'll go on from there.

What's In a Name?

Do you listen to the speeches about the economy? It grates every time when a politician says millionaire in one sentence and high income earner in the next. Seriously, pay close attention to the next speech - Republican or Democrat. Occupy Wall Street protested against highly paid bankers while citing the statistic that 50% of the wealth belongs to 1% of the population. Even the talk radio host I listen to on the way home does it daily. And I like (aka learn from) what he says. Yet I continue hearing this lie. Say a lie often enough and people think that it's the truth.

Gut Reaction: Lie? Wait a minute, what lie?

Yes - it's a lie. Millionaire and high income do not mean the same thing. Millionaire refers to a person with $1 million or more net worth. Net worth has nothing to do with your income.

Gut Reaction: Potato, potato. Does the difference really matter?

Yes. Okay, let's imagine for a minute that the politicians are right. It really takes a huge, six figure salary plus obscene bonuses to become a millionaire. Getting that kind of gig means you know somebody. You, hard working middle class person, will never become a millionaire by yourself. To get more, you need help. So who's going to help little old you?

And in steps the politicians. Give them your submission and they will give you the money. You need them. You cannot do this on your own.

Now imagine the opposite - there is a difference. You become a millionaire by saving money. You sock away a little bit every month over 30 years letting it grow and grow. This scenario requires no special knowledge. It depends on your character, not a politician.

So yes, the difference does matter. It all starts with whether you have hope or despair. Hope comes from power. With hope, I know that I can change the world. I will become a millionaire. The goal is in my power. Net worth grows with hard work, discipline (saving), and divine blessing. Who I am shapes the world around me.

With despair, I can never reach such a lofty goal. If I can't, then those people who do must have some special power. And it must be evil, because I'm good and I can't. They don't deserve good fortune. Dumb luck.

I read a great book called Leadership and Self Deception: Getting Out of the Box. This book posits that we choose first and justify second. (That's a very shallow summary. Read the whole book. It's worth your time.) That is what I'm saying. I choose hope or despair. Then my economic view becomes what justifies my choice.

Now our conversation shifts from money to character. Hope (or despair) rises from our character - who we are at our core. All of the arguing over money hides the real issue - who am I? And do I really want to know?

So I spent a couple of hours digging around in Visual BASIC code today. We're moving this code from one server to another. The .NET version changed. And the database delete functionality stopped working. Insert and update work fine. Only the delete part broke. It's frustrating.

The code uses something called a Business Facade with LINQ for database access. I personally find it very confusing. LINQ abstracts away the database access. In my mind, LINQ just adds another translation layer between me and the goal. My coworker probably feels the same way about Catalyst with DBIC. So honestly, what's the difference?

Abstraction vs. Simplicity

We use abstractions all of the time in real life. Calendars abstract the march of time so that we can see the interactions. We write checks instead of mailing cash. You look at a gas gauge instead of the fluid level right in the tank. Abstractions make our lives simpler. They stand in for messy details.

Catalyst does that. It hides the mundane intricacies of web connections. No matter how many web applications you write, parsing the URL happens the same way every time. There is only one right way of parsing CGI. And every application does it the same way. Why rewrite that code over and over and over? Catalyst does it once.

DBIC works in similar fashion for database queries...

• Make the connection
• Generate the SQL
• Join related tables
• And convert it all into Perl data structures

Abstractions help you write working code faster. My Catalyst applications are more documentation than code. And that's a good thing. So what happens when the abstraction breaks? This is the situation we find at work - the abstraction broke. My co-worker finally figured out that the web class calls into Business Facade which calls down into another class that executes a stored procedure that runs a DELETE statement. Yeah - all of that work for something as simple as deleting a record.

An abstraction should simplify details, not hide them. When the abstraction breaks, you can figure out what's happening.

Good Managers Delegate

Delegation happens every day. Your boss's boss asks your boss for something. Your boss then gives you responsibility for getting it done. You do a spectacular job, hand the result to your boss, who then gives it their boss. This occurs across your entire team. So when the manager delegates work to 8 people, that means he received the work for 8 people. What would you do if someone dropped the work of 8 people in your lap? One person doesn't accomplish the same as 8.

Delegation lies at the heart of automation. We delegate work to machines. Machines handle repetitive tasks with aplomb. Humans find them boring. Seriously, I would go bonkers typing in all of our data by hand. The computer doesn't blink an eye when it loads that same data. I delegated my work to the computer and accomplished more by doing so.

Web frameworks are about delegation - not abstraction. A good framework delegates the mundane, repetitive details using a library of proven code. Catalyst delegates the URL parsing to some block of code I have never seen - and don't need to. DBIC delegates table joins to some block of code I have never seen - and don't need to.

Catalyst and DBIC don't hide the details. They tie directly with the lower level details, if you need those capabilities. Both frameworks handle the details by default - helping you the programmer - like a good assistant. Does your framework help?