Archive for August, 2006
Penguins and Cats
An “automatic” screenshot taker is something that I’ve always wanted, but the commercial offerings leave much to be desired and the only other option seems to be the “manual” approach. I am of course talking about screenshots from video files rather than screenshots of your desktop, that sort of thing is well covered.
One of the problems with making your own is that the options are fairly limited on just how you go about opening video files and pulling out the candy frame goodness. For Windows users, the option is to use DirectShow which I can only describe as The Crystal Maze for it’s Byzantine ways of operating are beyond mortal ken. The other option is to use a pre-built library such as ffmpeg or similar. This was out as well as not only was it a whole new way of working for me (Windows development files were few and far between) it was a whole new set of a programming challenges which made the learning curve more of a learning cliff.
So I turned forlornly to existing media-players in the slim hope that one of them would have the abilities required for scripting a makeshift screenshotter. Media Player Classic has limited command line support, VLC is more geared towards client/server setup and I couldn’t even figure out whether that route would lead to any semblance of success, BSPlayer… The list goes on as to the number of players which don’t supply a full body of command line options.
The silver lining, the angel of hope was MPlayer. If you’re prepared to wade through a bit of fudge to get there, MPlayer provides everything you need to script a screenshotter:
- jump to any part of the file from the command line
- output into different (static) formats such as PNG and JPEG
- can output file information (length, dimensions etc.)
With these three functions MPlayer is almost all you need. Almost.
(more…)
Over the limits
I’m not some kind of self-help guru or big social engineer but I have phoned customer support. A lot. So in case I have some sort of brain-fart in the future and decide that this is the last call I’ll ever make to customer support and it will all go well, here are some general nuggets of advice I’ve collated over time. As a prologue to this, I am in no way extroverted or comfortable on the phone, I despise indirect forms of communication and I count the phone as one of the worst so phoning customer support is not one of my favourite things; I don’t go baiting telecoms operators or Russian-roulette which company I’ll phone and berate today. I have also never worked in a call centre, so this is purely from a consumer point of view.
- First and foremost is to form the reason why you’re phoning customer support. In no way are you phoning for social reasons (or if you are, seek professional help); whether the call is just for information, to get something delivered, make a decision etc. Keep this reason in mind because whatever else the person/people on the other end say, they are putting obstacles in the way of you getting towards this goal.
- Think out the ways in which your goal is going to be achieved. If it’s about getting something delivered, start thinking about Post Office delivery times, meeting couriers; if it’s about a faulty item think about replacement, refunds. The big “trick” is to recognise when customer support is bullshitting and when they’re actually helping.
- Have a written list of everything you know. Keeping a paper trail is absolutely critical. This includes customer reference number(s), what the problem is, things that have or haven’t happened, past calls you’ve made. Everything. Keep this open on screen in front of you or on a piece paper with a pen handy, this is where you’re going to write notes on how customer support is going to make your goal happen, who said it and when.
- Have a mental list of everything they’re likely to ask and decent answers to questions. This is above and beyond what’s written on your list in point 3; it’s answers like where you’re going to be tomorrow for delivery or what phone number you have at work. I used to have little monologues of vitriol that I would form before I called and while therapeutic, they’re not conducive to getting things done and you will more than likely never, ever get a chance to use them.
Everything outside of these points is really common sense and mental acuity. Keeping calm is paramount, you want to be forceful and get your point across without sounding like a raving lunatic. Start calm as if everything is fine and this mishap (whatever it may be that caused you to be routed to a call-centre) is just par for the course; this tests the waters and lets you gauge just how helpful people are going to be to your particular problem.
Never, under any circumstances allow yourself to be railroaded into them saying “We’ll call you back.” It is the death-knell for your customer support experience and will probably mean you calling back angry half an hour later and having to explain the entire situation to a different company representative. If they need to call another department to verify, get them to put you on hold, while you are on hold they cannot receive any other customer calls so you are the priority.
If it all boils down to them phoning you back, get a number that you can call which will bring you directly through to them or to their department. Don’t settle for going through the “You are in a queue” nonsense again. Give them a time-limit on when they should phone back: “By 2pm” or “In the next half hour”. This means you can come from the phone call and go do something and know precisely when you need to phone them back instead of sitting on your hands and waiting. Before they put the phone down or if they are going to send you any information (e-mail, phone, post) make sure they have the right information. Ask them to confirm what they have and offer corrections if and when they are needed. This eliminates the possibility that you’re sitting and waiting for a call which won’t come because of bad information.
It’s worth reiterating that anything that customer support say that isn’t helping you get to your goal, be they defensive apologies or reasons why things aren’t moving, is an obstacle and should be treated as such. This is customer support so you are always right even when you’re wrong, this is about what they are doing or going to do for you. This is different from being unreasonable though, recognising when something is genuinely out of their control (strikes, floods, shortages etc.) is different from when they’re trying to cover up their inadequecies (which is what you’re trying to overcome).
At the end of the phone call before the representative has done their “Thank you for your call”, restate exactly what you have taken away from the call, what is going to happen, pertinent information etc. This crystalises the information in your head and gives the representative one last time to make any amends. It goes without saying that you should get names and times of all calls you make, this goes back to the idea of making paper trail.
Probably the hardest point to achieve is: do not put the phone down until you get closer to your goal. That is getting confirmation that you are in a better position as a customer and a consumer than you were when you started, beyond the obvious being ten minutes older and slightly more annoyed.
Fundamentally, all of this sort of “advice” boils down to common sense. Some things are worth stating simply because they’re applied common sense, the kind you only get through tormented and wearying phone-calls that make you wish you’d said something just a little more vitriolic.
On a par with reading with my eyes closed
I’ve spoken briefly before about the “Modified Pre-order Tree Traversal Algorithm” which in a nutshell, is a way of storing heirarchical data in a flat-file database without resulting to constant “parent” links (meaning you either have as many database queries as levels or you select everything and sort it programmatically). The two main articles many people point to on the subject are by Sitepoint and Evolt. But having dealt with them in a number of projects (my gallery being the only publically accessible one) really those articles fall short of providing you with the meat of what the algorithm can, and most importantly, can’t do and how to do it.
(more…)
Chasing the tail of smoke and reason
I Read this morning a couple of articles on “optimising” PHP code to execute more swiftly. This seems to have become a past-time of a lot of self-made PHP coders who use their script execution time much like a locker room dick-measuring contest. The self perpetuating myth that PHP is some kind of lumbering behemoth, striking down servers left and right with it’s uncompiled bytecode is a complete fallacy. Just like “PHP Security” is an oxymoron, slow code and inadequete security come from inexperienced or uninformed programmers.
The first article recommends the programs and and practises that will save you the most execution time. PHP/Zend extensions like APC or (the eternally under construction) Turck mmCache are fire-and-forget additions that will help execution time no end. The always jubilant templating systems will have designers breathing a sigh of relief but the majority of them come with their own caching solutions. At their simplest they can reduce the number of database hits and overall execution time if you’re willing to start integrating caching calls into your code.
And that’s it. Those two extensions are the money-makers, the ones which look good on graphs and spreadsheets and cost analysis tables. Everything else you’re pushing into the realm of either enterprise solutions or esoteric coding practises which shave rather than carve your execution time away.
The third item on the first article’s list is a “Distributed Object Caching” system which truly is as exciting as it sounds. While a very nice idea and evidently one which works wonders, the majority of people who are using PHP will not need it, especially with the potential of additional coding within PHP to make full use of it. It’s telling that it was created for the behemoth AngstJournal; on the project homepage it speaks of 2GB - 64GB memory configurations, this is not something for the mom-and-pop servers for when you need 64GB of RAM, memcached should really be just one of a whole host of bandwidth spreading and load balancing measures you have in place.
Now let the dick measuring commence.
The “language specific tips and tricks” also known as “anal coding practise”. Raw code that you write free and fresh will never be as elegant or as stalwart as when you go back and start turning the screws; but there is a definite line when optimisation turns into pointless obfuscation, all for the sake of a few CPU cycles. The cries of “it all mounts” up not withstanding: when optimisation starts affecting the readability and maintainability of your code, you’ve gone too far. Most “language specific tips and tricks” rely on certain versions of interpretters and compilers which means that the “tricks” you used yesterday for version x, might not work or even hinder you in today’s version y.
So perhaps something like doing a pre-increment (++$i) instead of a post-increment ($i++) seems like a handy time-saving trick that cascades into shaving whole minutes off your execution time; when really you’re going against common, accepted programming practises which could lead to all kinds of havoc if you start doing it unwillingly and in the wrong situations. Yes you may have a slight overhead when calling “strlen($string) < 5” instead of “isset($string{5})” but at a glance, which is the most straightforward to understand? Or using regular expressions and ctype functions for checking whether something is a number? I’d better stop using the Byzantine “is_numeric()” function then, my CPU will thank me.
The of course there’s the “no shit?” optimisation tricks. Putting indexes on database fields? Whoever heard of such heresey! You mean error-logging can slow things down in a production environment and not speed things up? Most of the time, these aren’t even worth mentioning, they’re footnotes at worst and entries on your to-do list at best. The proliferation of PHP and free database systems has opened up a can of worms with regards to database design, I’m not about to be elitist and say we should all earn our stripes on Oracle, but there’s something to be said for an academic background on the where, why and how of database design.
Skies of hellfire
Originally when I started using PHP templates I used the first one I could find a tutorial on which as far as I can tell has been absorbed into PEAR and is now an entirely different beast. It used a very quick and dirty syntax that essentially built the output as you progressed through your script; early 2.0 versions of phpBB used a similar method (though I believe it may now be optimised, as they say, “up the wazoo”). Of course changing from the block, as-you-go templating to the seminal Smarty caused all kind of trauma. No longer is your code tied to how the page is laid out, you simply hand-off what data you want to expose to the templates and let them deal with things.
A lot of the really nice features of Smarty I shunned or outright ignored in those formative forays simply because I was of the opinion that PHP was some kind of resource hog and that templates were a trade off between processing time and sanity. In reality, Smarty has very little overhead on your stock PHP code and makes your programming so much nicer.
One of the features I have taken a shine to is custom output functions. It’s the ability to put simple things into your templates and for them to do (sometimes complex) tasks:
{fckeditor}
The beauty of this is that you can start to apply the same object-orientated kind of methodology to your templates that you (should) do with your application code. The custom functions I use on a day-to-day, page-to-page basis are specific to the project I’m working on and perform tasks like constructing a table of data and associated actions based upon the array of objects passed to it; or creating a set of pagination links (next, previous etc.) for paging data (of the aforementioned table). Some of the other ones I use however, are a bit more free-form and easily packaged.
(more…)
