How to hire Perl Hackers in 2008

By
J. Shirley
on December 20, 2008 7:24 AM | | Comments (0)
This is a post in response to "How to not get hired".

In modern times, with the wonderful business of head-hunters and body placement shops you can't rely on getting quality candidates through traditional job posting channels unless you have a lot of time on your hands.  Most of that time is spent throwing away resumes.  This is the first step to being successful: throw away bad resumes.  This is even true if you suspect it to be bad.  You may toss out some good candidates, but for the first round focus on candidates that know how to write a resume (and ideally use spell check and don't write Java Scripts).

The second step to being successful is to define testing criteria.  If you want experienced developers, not only do you have to be prepared to pay for them (in addition to creating an environment they would want to be in) but you have to know what it means.  An experienced developer or an experienced Perl developer are two different things.  React accordingly.

I'm also a proponent of sample code, but I don't believe it's all that helpful.  The people who submit terrible sample code tend to be the same people who submit terrible resumes.  If someone truly wants a job, they're going to care about the sample code they submit.  This, however, is very closely tied into the pay rate.  If you offer low pay, expect low quality -- chances are they are junior and haven't figured out the "right way" yet.

If your first round of candidates all have the same style and there aren't any clear winners, something is repeling the quality developers.  React accordingly; either adjust your qualifications or restructure what you are offering.

There is always a shortage of high quality developers, as they always know someone who is looking to hire them.  Good developers are more likely to find employment through their social network than through a job posting site.  This puts companies without being able to tap their social network for new developers at a distinct disadvantage.

This means you're bound to get spammed with a ton of poorly written resumes by people who don't want the job for more than a few weeks.  If you expect gold from these folks, you're going to get lead.

It's not their fault, it is yours.  Just as ridiculous as their sample code may be, it's ridiculous to assume skilled developers are just waiting to be picked up by some lucky company.

On a side note, expecting a Perl developer to know Moose on a $25-$30 an hour contract job with a cap of 20 hours is almost as bad as expecting a free lunch... but good luck on hiring, I know how frustrating it can be.

Now with ActionStreams (and a fix for "<mt:event> not found")

By
J. Shirley
on December 12, 2008 1:38 PM | | Comments (0) | TrackBacks (0)
I've setup ActionStreams before, and I really dig the idea.  I'm setting it up here, because of the CPAN ActionStreams plugin.  All of this centers around the work I'm doing for the Enlightened Perl Organisation (or Organization, depending upon your Atlantic Ocean perspective).

One thing that bothered me is that the tags didn't work right with the templates provided in the distribution.  Movable Type rightfully complained that some of the tags simply didn't exist.  Trying to save the widget template gave me this error:
  • <mt:authorevents> at line 9 is unrecognized.
  • <mt:eventdate> at line 23 is unrecognized.
  • <mt:event> at line 22 is unrecognized.
  • <mt:event> at line 24 is unrecognized.
  • <mt:event> at line 25 is unrecognized.
  • <mt:eventmodifieddate> at line 26 is unrecognized.
  • <mt:eventdate> at line 27 is unrecognized.
Well, that sucks!  Fortunately, the fix is a quick search and replace.  You just have to change the following:

mt:authorevents=>mt:ActionStreams
mt:eventdate=>mt:StreamActionDate
mt:event=>mt:StreamAction
mt:eventmodifieddate=>mt:StreamActionModifiedDate

That should get you going!

Update: Some other things I had to debug to get everything working that I thought I'd list here:
  1. Check your blog Activity Log for errors.  I was missing XML::Parser, so the Vox plugin was stopping everything from going and nothing was happening.
  2. Make sure both your blog author name and your display name are the same in every template bit, otherwise ActionStream can't find your stream.

Writing Catalyst Components

By
J. Shirley
on November 18, 2008 6:39 AM | | Comments (0) | TrackBacks (0)
This is a posting about a wiki node on writing Catalyst Components I just wrote up at the Catalyst wiki, that I hope gets a bit wider views.  People often times ignore wikis; less so than blogs anyway.

Writing Catalyst Components

The first step to really working with Catalyst is to venture out and write your own components. Whether it is a view or model they share the same common ancestor, which is Catalyst::Component. Catalyst::Component is an important part of Catalyst, as it sets up the model, view or controller object. Catalyst will handle instantiation (calling ->new) as well as calling a setup method called COMPONENT. While both of these methods can be overridden, it is better to override COMPONENT if you need to execute code at instantiation time.

Important Note: whatever object is returned from COMPONENT, Catalyst treats as the object for that model or view. This means that if you return a different object from an overridden COMPONENT method, that is what you will get back from calling $c->model("Foo");.

More on that further down, for now a very simple model class that has default configuration:

package MyApp::Model::Foo;

use warnings;
use strict;

# You must inherit from Catalyst::Model, which in turn inherits from Catalyst::Component
use base qw/Catalyst::Model Catalyst::Accessor::Fast/;

# Make an accessor for 'foo'.  Inheriting from Catalyst::Accessor::Fast lets us easily do that
__PACKAGE__->mk_accessors('foo');

# All Catalyst components have ->config available to them.  This is merged in with the application-level
# configuration after instantiation.
__PACKAGE__->config(
   'foo' => 'default foo value'
);

1;

That's it, that is all that is there for your model to exist. Catalyst (and friends) handle everything else. If you want to get at the 'foo' variable, you simply have to use the accessor:

$c->model("Foo")->foo; # returns 'default foo value';
$c->model("Foo")->foo('new value');

It's important to remember that while Catalyst does some abstraction of the mundane code, it is still just perl. That means that if you add a method to the Foo model above, it will be available via $c->model("Foo"), which as discussed above, is simply an instantiation of MyApp::Model::Foo.

So, to change this, override the COMPONENT method:

package MyApp::Model::Foo;

use base 'Catalyst::Model';

use External::Module;

sub COMPONENT {
    my ( $self ) = @_;
    return External::Module->new;
}

Now, all calls to $c->model("Foo") return the instant of External::Module. Use this wisely, and also sparingly. If you find yourself binding to external modules, it is highly recommended to use Catalyst::Model::Adaptor to do it, rather than writing the code yourself.


Dear Apple: Please make an external multitouch pad

By
J. Shirley
on October 22, 2008 5:05 PM | | Comments (0) | TrackBacks (0)
I don't think it is unreasonable for Apple to create a multitouch trackpad.  Something like the FingerWorks gesture pad, but without the absolutely insane price tag.

There's Apple Pricing, and then there is crazy insane pricing.  I'll pay for the former.

So, pretty please with sugar on top, give me a multitouch trackpad that works well and preferably has a larger surface than the MBP.

While I'm making demandsrequests, please hurry up and have scriptable gestures on the MBPs.  I want to be able to interact with QuickSilver and related software with gestures, as well as better support for multitouch in my apps.

Resizing and rotating photos gets old quickly.

"Federated Login" evolves to "Contextual Web"

By
J. Shirley
on October 4, 2008 9:51 AM | | Comments (0) | TrackBacks (0)
Federated Login has been closely examined by so many parties that I'm surprised there isn't a published guide on best practices.  There is still so much left to do in the arena that trying to implement a flexible and just "better" authentication and signup system gets frustrating. 

Standing on the shoulders of giants that are pontificating doesn't get you anything but a nosebleed.

I have a work (as in, the day job that pays the bills) task to improve cohesion, retention and reduce confusion.  Sounds like a job for a more robust login system to me.  When I think of a more robust login system, I immediately think of Federated Login and making use of OpenID and other methodologies to increase cohesion.

I launched Roostermatic with OpenID support, with the intention of experimenting with some ideas there on a smaller codebase and then hopefully expanding those offerings into a more robust solution for work.  The problem is that it isn't quite so analogous as I had hoped.

Work has membership ID numbers (to register for most events, you have to purchase a membership), the current legacy identity token is email which isn't so great because amongst non-tech users email changes and they continue to login with their email address.  Which isn't valid anymore, because they never told us their new email.

What inevitably happens is they simply create a new account and buy a membership, then we lose their history (which is important when dealing with things like racing licenses).

This is why I think the dialog that says, quite directly, "Do you already have a password?" helps.  Then the option of "No, help me login" makes more sense.  However, it doesn't address the point that "identity" is increasingly variable.

With OpenID and other auth solutions in the mix (Google Auth, Facebook, etc) now the identity itself becomes confusing.

At this point, I think that we're going to see a natural decentralization of web applications and the idea of Federated Login is simply a growing pain in that direction.

To clarify what I mean by natural decentralization of web applications is a tendancy to be built using RESTful principles and various APIs, which are then exposed based on context.  So, perhaps rather than decentralization think of it more in terms of "Contextual Web Applications".

Now, I do mean something subtly different in the two terms and I'll hope to clarify the distinctions.

Decentralization means that the applications themselves are decentralized.  You can see this already happening with Dashboard widgets (Google Homepage, etc) and even to a lesser extent with Facebook applications.

Applications are context-aware, but even more importantly they're beginning to have different front-ends that talk to the same backends.  It's a refinement from a foundational application that doesn't have a user-facing interface.  Instead, it has web-services interface that talks to a refinement stack that then serves the application based on context.

This is where the Contextual Web meets Decentralization.  It is perfectly feasible for an application to join several applications and splice them together based on context.  To further the point, I'll bring back my work example.

I manage the application stack for an event management and registration system.  This handles users who need to purchase a membership, manage their competition licenses, and finally register for events.  It also allows the individuals who host the races to setup the race information, scheduling, and specific items.

It obviously is a case of a singular application, right?  I'm not so sure anymore.  Why should our application care about event scheduling?  There is a great deal of code that goes into tracking the dates that is pointless.  If we stored a reference to another application that handled the scheduling, we would end up with less code and offset a lot of responsibility.  The hidden gain is that our events would be broadcasted to a larger audience.

The work would be simple, too.  Create an event object, which has a relationship to a Google Calendar entry that tracks the dates, stores the location and description.  We would have a very simple event object at this point, that only serves as a conduit from our application stack to Google Calendar.  And, the next step is tracking the individual racing groups that can be purchased.  This is where our application requires explicit trust, since we deal with money.

I have, however, reduced our application space down significantly by using a different application to store the scheduling information.

This is how I view decentralization.  To move on to Contextual Web piece, this is the front-end applications.  An application should be aware of who the user is, and through what environment the application is being used.

This means that if a user authenticates through Facebook, consider redirecting to a built-in facebook view (if possible).  Or, assume a user enters through a Google Calendar link to the site, support Google Auth and attempt to pull in authentication information from Google Auth.  All of these things will require action on the end-users part (accepting that the site wants to use OpenID, Facebook Auth, Google Auth, etc) but the experience can be mostly seamless I believe.  Especially if context is preserved.  Our events don't require our full-fledged application to be used for registration, just that we control the connection.  By this, we could have an iframe view inside of Facebook so if a user wants to register for an event a friend has registered for, they could do it without ever leaving Facebook.  Only on the users first time inside the application would we require them to associate their membership with their Facebook account, and that check would be simple because we'd just have to ask if they had a membership previously.  If they did not, we just add that into the shopping cart and they check out entirely on Facebook.

We email them the receipt, they get their purchase history available to them, and we invite them to create a password on the main site.  The membership ID number or Facebook authentication mechanism will be associated at the time of creation, or, when they provide their membership number to register for the event.  This would, of course, require a change to the registration page to allow them to input (and verify) their membership ID.

We do have a bit of an advantage over other sites because our members come to see us in person, so our fraud rates are ridiculously low.  People also can't really try anything bad, because our accounting is easily able to be audited and verified.

I'm still thinking of how to do these things on more general purpose applications, but I fully believe this is the way forward for web applications.  I hope, anyway.


Free Trials Done Wrong

By
J. Shirley
on September 15, 2008 9:55 AM | | Comments (0) | TrackBacks (0)
A fairly frequent subject of discussion that comes in blogs and news feeds is piracy.  Piracy regarding games, software and justifications, etc.

A common response in people justifying piracy is that it is often times easier and better to grab a cracked version than some ridiculously limited and crippled demo version.  In this, I wholly agree.

I grabbed a piece of software that initially prompted me to register and had a convenient "Not Now" button.  I promptly clicked that button, as I'm not going to spend $40 to see if a piece of software works.

30 minutes later, it tells me, "Oh, your 30 minutes is up so I'm going to quit now."  Application state gone, only option is to buy the product.  This is a bad experience.

These are the types of behaviors that make it easy to justify pirating software.  It's cool to nag.  It's cool to have a trial period of the full version (thank you TextMate).  The idea of exiting after 30 minutes is ridiculous.

So, instead they lost all possibility of ever getting a customer on my end and likely anything else that they do.  If they pay such little attention to user experience, it certainly isn't an app I would grow to rely on.

Please, if you are working on a desktop application and want to let users try it then do that.  Let them try it as if they own it.  Just remind them that they don't.  Intruding in their work flow is a straight trip to the garbage.


A review of Varnish

By
J. Shirley
on September 13, 2008 2:35 PM | | Comments (0) | TrackBacks (0)
After several respected peers mentioned Varnish, I decided to give it a try.  For reasons that are fairly complex, so here's the story from the top.

The way our MogileFS cluster works here (and I'm just about finished with the new front-end media management code, so stay tuned next week) is quite simple. 

To start with, when designing it, I threw out the idea that we should pregenerate any of the image sizes/formats.  Instead, we simply filter and scale to a max size (configurable, but currently set to 1280x1024) and then we throw out all the meta data (EXIF profiles, etc) that we can.  This drastically reduces the size on disk, and then to spit out resized images it doesn't take long (I haven't finished stress testing this yet, but I'll post when I do).

So, now I have files stored in the MogileFS cluster that are stripped down versions of the originals.  For the sake of simplicity, just think of those as the original (if I were running something like SmugMug, I would store it in the original size, but then extract the meta data into a separate data node).

Now, when a request comes in for a media asset, we just enforce it follows a specific convention.  In our case, the URL looks like:
http://static.cartionary.com/images/{uuid}/{mutations}.{ext}
For now, we just serve images, so that part is easy to deal with.  The UUID is the unique identifier that we use to store the image and {mutations} is any series of programmatic mutations.

If the {uuid} isn't known to the system (the test is if MogileFS knows the key), it returns 404.

If it is, the system then parses {mutations}, which can also simply be 'original' and it will return out the original copy (or rather, the raw data stored in MogileFS).  Mutations are a format that I've simply concocted to determine rotation, scaling and anything else we can come up with.  For example: "s=s" means "size=small" (other sizes are "m", "l", "xl").

Combining that upstream with as permanent of a cache as we can gives us better results, because we don't have to generate thumbnails that may never be used.  They're generated on demand, and then cached on our proxy for as long as we reasonably can keep them.

The reason why I went with Varnish, over lighttpd+mod_cache or Squid, is simply that Varnish (from the varnishcmd command) allows you to purge cached items via regular expression.  Which means that if we want to delete an image from the entire cluster we just have to delete it from MogileFS then issue:
varnishadm -T :6082 url.purge {uuid}
Done!  All requests for that UUID will end up as a 404.

That's the reason why I picked Varnish over lighttpd+mod_cache and Squid (or, rather to be more specific, picking something that doesn't rely mostly on HTTP PURGE) because we'd have to know every image ever generated (that's a lot).  This is also why I decided to do away with the idea of generating permanent thumbnail and other modified images.

Every time you need to do some operation, or make some change, you're stuck with however many user contributed images * number of generated images.  It's costly, silly, and most of those images will sit dormant except for the occasional .  CPU time is really really cheap. Disk space, too.  So make your caching huge and your media cluster fast.

The decision really comes down to the fact that I'd rather have the CPU deal with on-demand requests, and have the user have to wait an extra second or two, then have a developer have to get "creative".  The reality of it is that a user, in most cases, won't have to wait.

When an image is uploaded, have a job (or preload it in the resulting HTML displayed to the user) that asks the caching cluster for the expected image sizes (small, medium, large) and then they're saved until the cluster runs out of disk space, then the least recently used items fall off and won't be missed.

I'm happy to be building this system in a day and age where I can make that decision and expect it to work out well.  I've dealt with two other high traffic photo-centric organizations, and I experienced the pain of not doing it this way.

I'm eager to experience the pain of doing it my way now.

Using the right tool for the job

By
J. Shirley
on September 4, 2008 3:01 PM | | Comments (0) | TrackBacks (0)

If you haven't read Zed Shaw's C2I2 Hypothesis, you should really do so now.  I mean it, go read it.  I'd like you to come back here but if you don't that's ok, I'll understand.

The main gist is properly identifying just what type of person you are working with, and to a more significant degree, what type of person you are (which is variable).  I have my own thoughts on the specifics that he lists that I'll likely write up later, but for now just reading it is a good start to continue my current thoughts.

I think that it equally important to understand the tools you are using. It seems a lot of people use a specific tool because they don't really think about other tools. If a problem looks like a nail, they use a hammer.  While I hate metaphors when they're not necessary, I think using the nail/hammer metaphor does work for this case.

What ends up happening is the, "When all you have is a hammer, every problem looks like a nail." syndrome.  Conversely, if you have a vast array of tools at your disposal, you are going to over-complicate problems.  There is a very important balance that must be maintained.

If I had to pick over-engineering a problem, versus simply driving a nail in a plank of wood and calling it a deck, I'd over-engineer it every time. This is coming from years of experience, and several contracts that seemed to extend in two-week intervals where I was expecting to find another gig every two weeks.  One of those went for 2 years, adding two-weeks worth of "enhancements". It was all hammer and planks of wood. Absolutely terrible.

The reason why I'm writing this is because a discussion popped up where I expressed my confusion in people using plain vanilla mod_perl, then being frustrated with testability and other nuances. Someone pointed out that mod_perl is a perl runtime inside of Apache that gives you programmatic hooks into Apache.

Fantastic.  However, that doesn't enter into what my point was.  People use mod_perl because that is the only tool they know.  I believe this is the case with most PHP-based engineering shops.  They use PHP because that is the tool they, or the managers, know.

The problem with this mentality is that by not knowing the tools, you are doomed to work within the confines of what you know.  While the skillset and knowledge may evolve, it won't have a renaissance or giant evolutionary leap.

This is the key reason for learning other toolsets and libraries that are available.  It isn't about jumping to trendy and shiny technology, it is about defining your own capabilities in relative scope to what other technology is around.

It's very easy to spot this type of individual, which I view as a blessing.  If a person ever argues against a tool (or rather, using a tool in place of something that they know) you can count on them being very limited in their ability to accurately scope and understand a problem.  They will mutate the problem to be solved with the tools at their disposal.

In context of Zed's C2I2 hypothesis, I've been struggling to really distinguish between a collaborator and an implementer.  They were very much the same in my mind.  Thinking about the usage and understanding of tools has helped clear this up for me.

A collaborator doesn't know the details of the tools.  They follow cookbook recipes.  Contrast that to an implementer, who still follows cookbook recipes but understands the tools that are being used.

The inventor, of course, usually is the one building the tools.  If a tool doesn't fit an implementers agenda, they'll either move on or smash at it until it works.  An inventor will go in and fix the tool.  A collaborator will be that guy on the mailing list you wish would go away, and probably be the first in line to argue against other tools they've never used.

A kind word for github

By
J. Shirley
on August 31, 2008 5:01 PM | | Comments (0) | TrackBacks (0)
You know a project is successful and well built when you get people trying a product simply because some additional accessory is built around it.

Imagine buying a computer because the case was that good.

A car because the seats were so comfortable

That, precisely, is what github is. Git is fantastic software, sound engineering principles went into it and it works very well. I still use subversion+svk for nearly everything, because that is just what most places use and I'll never be able to get away from that software.

Github just makes me wish I could.  It is excellent work, astoundingly simple and put together very well.

A hesitant plug...

By
J. Shirley
on August 18, 2008 6:57 PM | | Comments (0) | TrackBacks (0)

After Rick Segal mentioned Windows Live Writer, I figured that I had nothing to lose if I gave it a try.

The problem with that thought is that I did have something to lose. And lose it I did. I lost my belief that Microsoft couldn't produce a program that is worse than any other alternative.

I don't like to unnecessarily hate on Microsoft, but I find their products to be absolutely terrible when compared with sufficiently advanced alternatives. In the case of Windows Live Writer, there is no alternative.

A few folks have pointed out Mars Edit and other offerings (on OS X, as that is my platform of choice currently) but they really aren't as good as Live Writer.  Even under Linux I couldn't find anything that is just better than Live Writer.

It still isn't perfect, but it works extremely well. Now my only hope is that Microsoft will lose something... the irritating need to bundle a staggeringly large amount of irrelevant software with Live Writer. Until they do that, I don't think I can recommend Live Writer to people who won't just blindly click "Continue" without seeing what other crap they're installing. If you do read before clicking, definitely check it out.

It seems to be working fantastically with Movable Type 4, but I still need to figure out how to manage static pages.

Archives

Recent Activity

Tuesday

  • Jay tweeted, "Damn MySQL database threw a corrupted table error and dropped the connection. Again."
  • Jay tweeted, "Good soccer game, very tired. Time for physical therapy exercises and then sleep. Maybe a beer somewhere in there... no hacking tonight."
  • Jay tweeted, "First soccer game in several weeks. Will be exhausted, but can't wait."
  • Jay tweeted, "@lisaphillips only if you tweeted that from the bathroom. Hopefully not."
  • Jay tweeted, "Dear Apple, did you forget about the new MacMini? I was waiting to buy one."

    • More...

Pages

Search

Categories

Monthly Archives