Fri, 10 Jan 2014

Page loading twice … but why?

— SjG @ 11:15 am

Oh, what a journey of discovery, and what a diet of red herring.

I’m developing some pages in Yii, and noticed that — in Firefox — pages containing CGridViews were actually loading twice. The pages seemed to flicker on load, and in my server logs, I’d see two requests. I went down a lot of dark and twisty alleys trying to figure out what was wrong with my Ajax calls, to no avail. Turning off Javascript did solve the problem, so, of course, I was focused on finding a Javascript bug.

When searching for others experiencing the same problem, I found this posting. “Curious,” thought I.

I tried re-arranging the HTML layout, and damn me twice if putting the character encoding declaration earlier in the file doesn’t fix the problem.

The CGridView red herring comes from more Javascript includes being injected in the header on pages that use CGridViews. So that makes sense.

I’m still puzzled why disabling Javascript in the browser makes any difference. It does not change the location of the character encoding declaration in the file. Maybe it’s a Firefox- or Firebug- specific “feature.”

I have to admit being surprised that the spec dictates the encoding be declared in the first 1024 bytes (or 512 bytes before the 2011 version of the HTML 5 spec). I’m even more surprised that a browser would actually re-submit the request to load the page in the case where the page was out of spec. Redraw? Sure! Reload? That’s just crazy.

Wed, 18 Dec 2013

Angular.js and IE8 Problem

— SjG @ 10:00 pm

I was just finishing up a Angular.js application. It was then time to test it under Internet Explorer 8 — not for purely masochistic reasons, mind you, but because it’s still the standard browser for some people, including the people for whom this particular app was written.

I’d already tested under Chrome, Firefox, Safari, and IE10, so I wasn’t expecting any problems. There you go. I’ve put it in writing. I’m an idiot.

So IE8 didn’t render the app at all. No error messages. I switched to IE9 to test, and it worked there, unless I put it into “IE8 Standards Mode” when it would silently fail again.

Now, this may not be news to some people, but IE8 really is pretty crappy. I spent several hours tracing through things, which is not easy with Angular.js due to the asynchronous way that most apps are built. This app has services that create Ajax promises and controllers that rely on services. Figuring out what’s supposed to be happening when can be challenging.

To make a long story short, this turned out to be a case of IE8’s non-crappiness. One of the views that was being included had a spurious close div in it. All of the other browsers happily rendered things the way I expected and didn’t even bother to warn me that the HTML was malformed. Only IE8 stuck to the standard and refused to participate in the charade. Yes, you read that right. IE8 was being a stickler for standards. I just don’t even know how to process that fact.

For what it’s worth, it can be hard to find this kind of error. When you have partial views that get included dynamically, and/or they’re ng-templates, it’s hard to see your completed HTML document, much less validate it. I even tried things like the Web Developer plugin’s “View Generated Source” and then submitting it to the W3C Validator to no avail. The way I ended up diagnosing it was the “fire the canon and see what dies” approach of commenting out different chunks of the code until I could isolate the section. From there, it was manual analysis. Yuck.

Fri, 6 Dec 2013

Another SELinux Lesson

— SjG @ 6:17 pm

So there’s this project that requires a ridiculously complicated communication protocol involving lots of byte-wrangling and formatting and weird transports. For the sake of brevity, I’ll only mention one of the endpoints, which requires decoding an email attachment.

Of course, this means a procmail script sending the email to PHP for processing and much ceremonious mucking about. On first go, it was failing. In debug mode, procmail was telling me that permission was denied. But it wasn’t user permissions: the file was owned by the same user as receiving the email and running the procmail script.

Naturally, when faced with cryptic permission failures, the first thing I did was look at /var/log/audit/audit.log and /var/log/messages for SELinux denials. There I found nothing at all. No errors, no warnings, no ugly “avc: denied” splatters.

Finally, this page here explained it to me. Rebuilding the policies with semodule -DB quickly revealed that my problem was, in fact, SELinux (as it all so often is). Once I could see the policies that were marked “dontaudit,” it was just an hour of building more and more complicated policies for procmail before stuff started working.

Once everything was good, happy, and shiny, a simple semodule -B returned the SELinux logging to the previous state, and I could once again spend my time fighting the convoluted bit-twiddling of the communication protocol.

Sat, 23 Nov 2013

Tic-Toc Bird

— SjG @ 2:38 pm

With no further commentary, I hereby offer you a Tic-Toc Bird of my own discoverytictoc-bird.

Sun, 10 Nov 2013

Diffraction Test

— SjG @ 8:28 pm

Reading different articles on macro photography, I see different opinions expressed on what the minimum aperture is that you can safely shoot at before you start losing out to diffraction. In many cases you’d like to shoot at the smallest possible aperture so as to eke out another few microns of field depth. The popular wisdom is that these two requirements meet somewhere between f/11 and f/22 (depending on who you’re reading).

For this crude test, I bolted the D90 to the desk, stuck on the Nikkor 105mm f/2.8 macro lens, put a ruler and a circuit board a short way away, focused manually, set up strobes (commanded via Nikon TTL) to light it, and then went through various apertures.

The Depth of Field range turned out as follows:

Full scene, f/4

Full scene, f/4

Full scene, f/45

Full scene, f/45

Nikon computes the effective aperture for the lens, so even though I had the lens wide open (and at f/2.8 according to the lens), the camera reports the corrected f/4.

So how about detail? Below are a collection of details at 100% crop from the same scene.

Just for kicks, I did a similar test with an image that was sort of kind of close to parallel to the focal plane.

My conclusions:
1. Pixel-peeping at 100% shows me that my focus isn’t great at any aperture.
2. While there’s a definite degradation at f/45, f/32 is barely worse than f/22. For absolute sharpest, it looks like f/11 is indeed the best.
3. Wide open, there are other aberrations at work.
4. Color and contrast shifts continue beyond the wide-open, although it gets more subtle.