Best practices? there is no such thing.

There's one thing everyone knows about Perl: There's more than one way to do the same.
And that, that same single thing, is viewed as a good thing for pro-perl people, and as a bad thing for anti-perl people.
There are obviously good ways to do something, and bad ways. There can be better ways. But there's no way a single way should be the best.
Perhaps, and only perhaps, there could be a best known way to do something. Perhaps Bresenham's algorithm was the best one to draw a line, until a better one came. Which is the best one nowadays? Well, it depends on the lenght of the line. And on the slope. And on the machine executing it.
I'm sick of hearing people preach of best practices to do something or the other where using these best practices means a much larger code to write, bloat, inefficient code, etc, while providing absolutely nothing better than a different way to do it. They sure are better in some cases, but not always. And when something is not always better, even if there is a single case of not being better, it's of course not the best.
Anyway, having a best something would, by definition, kill all innovation and improvements, because... how could someone even imagine doing something better than the best?

Managing complexity

Is never easy, and that's why so many people fail to do so correctly.
I've been somewhat forced to develop an application using a framework. I really hate this framework. Any little change, any tiny modification, anything which could be done in half an hour takes us days to acomplish. Why? because this framework is the wrong tool for our problem.
The framework was developed internally to solve one problem, and I hope it's right for that. But now a completely different team must use it for a completely different problem. And nothing works. Of course.
We don't know it, we have never used or even seen it before. We don't have documentation (because there isn't any, of course).
Most of our work is via trial and error. We also do some reverse engineering, and study the sources we have, and studying the sources is what makes me ill.
I can see how much work has been put there. How great attention to small details has been put there... for very concrete, special, narrow cases...
The moment where you try to do something slightly different than that which was expected... everything fails.
You want to filter your data? it's easy, you place that filter there and everything works automatically.
Ok. Now how do I put this other filter there?
what? which other filter?... well,  that was not thought of, it's not possible.

So, after spending days to try to know how something worked, when I want a slightly different solution... it's simply not possible. The only way? study the sources and replicate everything with the small changes required for the new specific case.

Hiding complexity for a specific case will never work. When will many of these high qualifications, high rank, high pay "software architects" realize they are doing it wrong?

adjusting your webApp to iPhone screen size still giving problems.

Well, the workaround I published here some time ago works perfectly on my test app.
Obviously, only when starting a real webApp do the problems present themselves.
The "real" webApp (so simple it even souldn't be called real) didn't have any header or footer. And neither any "content" as defined on my previous example. All content were some absolute positioned divs, and a background-image scaled to 100% of both width and height (that means that at least in one orientation it was distorted, but it was so by design).
Any of the hacks which worked for my test app produces unsuccessful results, but as I didn't want to place any empty placeholder divs, was short on time, and the webApp was designed to be added to the home screen and using all screen space, I left it as is, without hiding the navigation bar when in browser mode.
Some day I'll try to find some more answers about successfull iPhone screen size detection...