Friday, July 05, 2019

A Low End Camera Shootout

We've got some travel with our nieces and nephew coming up, so it was time to dust off my collection of makePads and insure everything was ready for the kids to start creating.

The BLU Advance 4.0 has been working well as the makePad's hardware platform. The device is compact, cheap and functional. At $40 each, I can comfortably hand the phone to a kid and not worry how rough they'll play with it. One nagging limitation, however, is the quality of the camera. At 5 megapixels, the photos are fine at small sizes, but any degree of enlargement reveals how sub-par the pics are. I've wrestled with this pretty extensively: do the photos really need to be high quality? Could the lower quality be considered a creative constraint? How big a jump in megapixels would I need before I saw a notable difference?

Thankfully, Shira stepped in with a suggestion: swap the thought experiment with actual tests. That is, buy a bunch of BLU phones and do a photo shootout. And that's what I did.

The photos below are from a BLU Advance 4.0, BLU Advance 5.2 and a BLU R2 Plus. These have 5, 8 and 13 megapixel cameras respectively:

I found the results of this test to be insightful. At low resolutions, for example the thumbnails above, all the cameras look about the same. When enlarged, it's obvious at the A5 is better quality than the A4 and the R2 is leaps ahead of the A5. However, the jump from the 5 megapixel A4 to 8 megapixel A5 isn't as dramatic as I'd hoped. It's only when you hit 13 megapixels that you start to see some real improvement. So trading up to A5 from the A4 to gain 3 megapixels isn't worth it.

This is perhaps the best advertisement I've ever seen for a point and shoot digital camera. I'm tempted to try out this $40, 20 megapixel camera to see if it can deliver high quality pictures at a budget price tag. Though, a stand alone camera loses out to even the A4 in terms of versatility, so I'm not sure what that test would ultimately teach me.

Bottom line: unless I want to splurge on the $100/device, I'm just going to have to accept the cruddy image quality of the BLU A4.

Wednesday, July 03, 2019

One Wicked Bug: Fixing a PHP Upload Error #3

A few weeks back one of my customers started seeing a new issue with a recently updated Ionic app: uploading files resulted in a PHP Upload error #3, UPLOAD_ERR_PARTIAL. I'd come across the usual PHP upload errors before: needing to increase post_max_size, upload_max_filesize and max_execution_time. But these settings had never caused an UPLOAD_ERR_PARTIAL before.

One of the problems with the UPLOAD_ERR_PARTIAL error is how little information you're given. Apache and PHP report no errors, and there's no way to see the underlying web request that caused the problem. Using mod_security and mitmproxy gave me some interesting data, but nothing conclusive. mod_security reported a 408 Timeout and using mitmproxy actually corrected the problem altogether.

What had changed was replacing the standard Angular HTTP Client with a Cordova specific plugin. I'd found some evidence that iOS had timeout issues due to Keep-Alives, and thought that may be in play. Turning off Keep-Alive didn't help. I then swapped out the Ionic plugin, first for the FileTranser plugin, then for the native HTTP plugin. The problem persisted.

I then switched back to the Angular HTTP Client, and to my surprise, the issue showed up there as well.

I was just about to swap out Apache for Nginx, when it occurred to me that I hadn't investigated the issue from the Apache side of things. Attacking the problem from this angle yielded this hit on Google: Can't upload larger files to server. This individual ran into a similar issue and for once I got a new answer:

Found the problem. The Apache had a RequestReadTimeout header=20-40,MinRate=500 body=20-40,MinRate=500 setting which means the request's forced to timeout after max 40 sec... Another thing to watch out for.

I quick Google search of Apache RequestReadTimeout turned up a module I had no idea even existed, let alone one that was turned on by default. The mod_reqtimeout does what you think it does: if it takes too long to read a request, the Apache truncates the request. I enabled the logging the module suggested (LogLevel reqtimeout:info) and had my customer try again. Sure enough, the module reported that the request timed out.

Suddenly, the whole scenario made sense. My customer's slow connection was causing his uploads to be timed-out and truncated. From PHP's perspective the file was indeed a partial upload. Putting mitmproxy in between my client and Apache 'fixed' the problem because mitmproxy read the entire request slowly, reported it to me, and then delivered it all at once to Apache, which made Apache quite happy.

Not only am I pleased that I've fixed this bug, but I'm happy to have uncovered yet another critical Apache setting. Heck, just being reminded that you can turn up Apache's logging by setting LogLevel was an invaluable take away from all of this.

And here was I blaming Ionic, Cordova and iOS when the issue was fully due to my Apache ignorance.

Tuesday, July 02, 2019

More Columbia Pike Adjacent Fishing

Given the fishing success I had at Holmes Run, I was curious if a creek-like section of Four Mile Run would have similar results. So last night I made my way back down Columbia Pike and took advantage of the free parking at Arlington Mill Community Center.

I took the stairway down to the run and walked North. The water level was low, but I remained undeterred. Within 50 yards of entering the run I found what appeared to be a pool that was a couple of feet deep. I tossed in a small orange grubby plastic thing and bam! a sunfish snatched it up. I had my answer: there were definitely fish here!

For the next hour I made my way up the run, finding pools and pulling in sunfish. Obviously, they weren't huge, but for the size of the run they were actually pretty chubby.

At one point I came across a point where faster water was flowing between two rocks. I could see some larger fish--perhaps trout--hanging out in this section. I tried variety of baits, but they weren't biting. Still, this tells me that there's definitely interesting fish to be had in this section of the run.

Like Holmes Run, I was impressed at the solitude and nature factor. It was easy to forget that I was just a few hundred feet from homes and buildings. It was a relaxing time, with only the occasional runner, walker or biker passing by to break the illusion that I was fishing in a pristine wilderness.

If you're looking for an easy fishing option, look no further than Four Mile Run near the Arlington Mill Community Center. What you'll give up in terms of stalking monster fish, you'll make back in convenience and simplicity. And I'm so going back with more gear to try to land me some trout.

Monday, July 01, 2019

A Very DC Ultra Run

A few years back I enjoyed this read: I Walked 64 Miles Around the Beltway. What the Hell Was I Thinking? It's the tale of two friends tracing a path, as close as possible, to the DC beltway. The TL;DR version is this: they got way more than they bargained for. What seemed like a novel idea turned into a death march. An entertaining to read death march, but a death march none the less.

I enjoyed the story because it's a wonderful reminder that adventure doesn't require hopping a plane to a far off land. There are challenges and discoveries to be had in our own backyard. It's also a humble reminder that miles always seem small on paper. How gruelling can a 64 mile hike be? Turns out, very.

Why mention this story now? Over the weekend, Shira shared this tweet with me:

That's right, fellow Aringtonian Michael Wardian *ran* around the beltway. In one day. And he didn't cover 64 miles; his route took him almost 90. Even Mother-Nature didn't want to cooperate, and made the weather extra hot for his run.

You can read more details of Michael's run here and here. You can see the route he took here.

In short, what a superhuman effort.


Related Posts with Thumbnails