MS Office trouble

Problem
-------------

Users having:
- Office 2003 (sp3) with Office 2007 compatibility pack (sp1).
- Office 2007 (sp1)

work on the same document on a smb share.

From on point in time, the user using Office 2003 gets:

"Filename.ppt is currently in use. PowerPoint can't modify it at this time."

when he tries to save it (even if no modifications done).

Cause
---------
The user with Office 2003 has inserted some excel tables as embeded (instead of graphic). This article appears to apply: http://support.microsoft.com/kb/285517


Solution
-------------
Using Office 2003 , copy/paste all slides to a new powerpoint and save it as Office 2003. Then replace the pptx with this one and instruct the users to use this ppt instead (and save it as ppt no matter if they use 2007/2010).

The perfect laptop backpack...

... has not been created yet.

The "almost perfect" laptop backpack was my last Targus. But somehow they decided to discontinue it and trash its features instead of just adding some new ones on.

This is a list of features I would love to have at my laptop backpack and cannot find them all at any on the market, so far. Backpack manufacturers, erm... take notes?

• Secret pocket. My old Targus had one hiden in the lower back padding. Super super feature! Even I needed few month to find it :)
• Cell/Mobile pocket on one of the brackets. You need to visually check you mobile to decide if you answer/call back/etc, right? Then why putting the mobile somewhere inside, where you cannot reach it it unless you take off the backpack? Old Targus had it.
• Side pocket keychain. It's super to be able to reach the keys without taking off the backpack. Targus had it but I needed some practice to be able to reach and get the keys off the chain; still I managed to do it.
• Outside bottom made of special fabric / plastic / lether / rubber. Targus had it made of a kind of plastic fabric and I didn't care if I put it down in muddy or wet areas because it was easy to wipe afterwards and completely water proof.
• Laptop compartment access from the side. I would prefer to be able to take out/in the laptop without opening the round upper part zipper of the backpack. It would be much easier to be able to extract it through a side linear zipper (only the laptop not the charger, etc). This is the only feature missing from my old Targus but at the time I bought it was not "invented". Now I can see some models on the market having this nice feature.
• Some obvious and very common features: External side pocket for bottles (even one on each side). Padded back, straps, and laptop compartment. Diveded interiors with various mesh/non mesh pockets and zippers. Most of the backpacks have these anyway.

This is a message in a bottle. If you bump into this post and I am still alive, I would appreciate if you could send me the link to the backpack model that meets all of the above requirements.

God bless your back(pack)!

Modern Perl and the lack of "great" programmers

I'd like to collect some opinions about the following things. I am referring to some of the recent posts on linked-in, about recruitment and the lack of "great programmers".

A bit of history in my (possible distorted) view:
When OO appeared there were debates on the fact that has certain disadvantages over procedural like speed and being more verbose (over the advantages of allowing abstraction and allegedly being better for organizing huge code).
Then, in Perl's world, there were voices saying that one should not bother to learn OO perl because it is not a real OO, it is more a set of cumbersome conventions than a proper OO implementation.
Finally Moose appeared and practically defined a sub-language, a lot of "sugar" to overcome the base language OO limitations.

Now everybody jumped happily in Moose's boat and no-one talks about procedural Perl and, more important, they don't accept anymore procedural at interviews.
Like OO Perl is more than just another way to structure Perl code.

I call "There Is More Than One Way To Do It" in my support. True, I read somewhere: "Because TIMTOWTDI, don't assume that you can do it any way you want" but I tend to disagree for most of the situations.
In my opinion, the main purpose of any application is to meet the specs and also to be done in the allocated time. If you think of the application as a black box, and you managed to make it work as expected and tested it thoroughly from any angle, I really don't understand why would anyone would care *how* it is inside the black box. Is like, you can hit a nail with a hammer or with a pair of pliers and to a certain extent the outcome will be the same, depending of the wood's resistance.

Of course, when it is about interacting in a team and if there is a defined programming style, the applicant should converge to it, to respect the house rules. Still, it doesn't mean that procedural Perl should be a reason to reject a candidate at technical interview time.

It seems that only few companies are still willing to allow time for learning and they all ask for guys that can "hit the ground running" (again, mind you, we talk about a style not about core programming skills). But no one can know everything needed at the new job already. If (s)he knows everything, there is a chance (s)he might be tempted to look somewhere else for a challenge.

I think that's why a lot of recruiters/companies complain about the fact there are not many "great" programmers on the market. (BTW: Define "great". How? By compiling a list of technical questions that all "great" programmers should know? This might be a wrong approach. See http://it-quirks.blogspot.com/2012/10/modern-perl-recruitment-contd.html).
I bet there are lots of good Perl programmers but they get rejected (and possibly going to other languages) because they were considered as not fitting the target company's programming style. The companies are incredible picky these days about the style, and the middle layer (agents) is escalating this much more by not knowing what's really about.

And then the advertised job stays on the market for 6 months or more and the agents and companies, at unison, lament about the fact that "great" perl guys are a scarce resource. Maybe giving a chance to any Perl programmer that can do the application no matter the style, would be more beneficial for the company. Put in balance the 6 month fishing for the "great" programmer versus few month a "regular" guy can learn the new environment's specifics, style, etc.

Maybe it is time to admit that we're not so many out there,  therefore you need to be more flexible. Otherwise, wait.

I'm not trying to diminish the importance and role of OO Perl or Moose. I would just love that the recruitment wouldn't be so exclusive about it nowadays, because things can be still done very well and fast, the procedural way. Besides I don't think that it'd take more than few weeks for someone to adjust from procedural to OO style of the company. Not to mention that OO design sometime is a separate job in many companies, and in the end the programmer ends up writing code inside the same class, not needing to know the big OO picture.

So, how hard you think it is for an "regular" perl programmer to switch from procedural programming to Moose?

Modern Perl recruitment - cont'd

This is in response to some recent posts on linked-in, some of them leading to http://www.modernperlbooks.com/mt/2011/01/how-to-identify-a-good-perl-programmer.html

I think compiling a list of questions for the recruiters to ask for when filtering candidates is wrong and irrelevant for few reasons:

First of all, the weight of each question in the list should be judged in the context of the particular job requirements. No-one knows everything about Perl (maybe with few exceptions, see below the "top N").

Then, the weights of two questions could appear comparable to the recruiter and the candidate could get rejected based on wrong assumptions. Take these 2 examples from the list:

"What's the difference between == and eq?"

-- versus --

"Where do tests go in a standard CPAN distribution?"

One one side, if a programmer doesn't know the difference between == and eq, then we might have a problem (still debatable if the guy is coming from lots of years experience in PHP for example).
On the other side even an experienced programmer might have never been in the situation to care about the tests in the cpan distributions: if everything installs correctly and never created a CPAN module, why should one bother?
You can find more pairs of "extremes" in the list to prove this point.

The list also proved its limitations as a lot of people on linked-in already started to ask for clarifications. Assuming that someone really fixes the list's "bugs" as feedback is received, discussed and changes agreed on, probably endless iterations will be needed.

As for the relevance of asking somebody these questions, as the present list's answers can be found in only one book (Modern Perl), if anyone really wants to fool the examiner can do it by just reading this quite small book. Even easier, any perl wannabe can find now the list on the internet and can prepare the answers for potential future interviews.

Finally, knowing everything about perl is quite impossible: everyone has strong areas and weak areas and the capacity (or lack of) to improve in the weak ones if the job requires it.
Not everybody is Larry, Damian or Randal (and the list might continue to a top N). On the other hand not every company would need (or afford) any names from this shortlist. Bothering one of the top N programmers to write scripts for a company that sells ladies bras, briefs and stocks would seem a bit out of proportion, much like using a hammer to kill a mosquito.

Modern Perl recruitment

I am currently looking for a job using good old Perl and things seem more annoying than ever before. The frustration came back gradually, and most of it comes from the middle layer: the recruitment agents.

Let me start by clearly stating that not all the agents are the same and not all of them are "bad". However, unfortunately, many fit the description below.

This special breed of people, the perfect salesmen (in their views), is interposing between me and my "happiness" in annoying ways. Here are some things they, and only they, know how to do best:

• They understand 50% (if...) of what you can really do, but they have the audacity to decide your professional life by not putting you forward to the decision maker, the one that would really understand (as he needs and asked for you skills).
  Sometimes you don't check a skill and, even they don't know what's the real relevance of it or how easy it is to learn it; they just feel that skill sounds impressive. If you don't have it, you're a looser.
  Some other times they don't like you, you'll never know why.
• They publish their own, "cloaked" version of a job that's already published directly by the hiring company. They leave the same keywords inside 'cause they're unable to reformulate the skill set.
• They publish non-existent jobs, probably just to motivate their existence to their bosses by pretending they have activity. Moreover, they fish for leads by asking you to provide info about any other interviews you had, motivating that they don't wanna overlap with other agents on the same positions.
  I am sure (!) they don't contact an employer if they know that some other agent is already there :) They do have an exaggerated common sense.
• They treat us as like... cattle by adding quantities to the job titles, like: "50 perl developers for a big company[...]", "Calling for all perl developers [...]".
  We should just moo-in by sending all resumes to them. It's kinda depersonalizing, you know? What about having a regular posting for the job and selecting how many people you needed, afterward?
• All the companies they're recruiting for are presented as they are the latest shit on the market, next to Oracle or Microsoft or whatever you consider it's a big shit these days (pun intended :)
  Buzzwords include: "thriving environment",  "exciting", "world leading", "voted as number one expanding", "global footprint", etc.
  Have you thought that I just might prefer a regular sized company that would have obviously many advantages over the corporate, impersonal ones?
  
• You need to be psychologically abnormally addicted to work to please them. I mean, why would anyone choose to "dream in LAMP", "eat and breathe Perl", have an "Unquenchable thirst to automate mundane tasks" or be a "Perl junkie" instead of being a regular work-life balanced individual?

Unfortunately there are so many companies that act the same through their HR department.

I have a real example, one that is these days on the jobs.perl.org: Heart Internet, UK. They think is ok to cut all communication with me, *after* I spent few good hours on their programming test. I don't care if my solution was dumb or not to their liking, I just consider I am entitled to an answer, at least as a sign of courtesy after wasting my time.
This job based in Nottingham is present on jobsite.co.uk also cloaked by an agent: Simon Harris, Applause IT (see above about cloaking).
Same communication skills from this guy too. I sent them together about 10 emails until now asking for feedback, no reply.

Say, what about a database with agent names and star rating/feedback? Something similar to yelp.com but focused on recruitment agents/companies.
Also, it could be extended for any job recruitment agent, not only for Perl.Anyone?