7 days with my Ice Cream Samsung

Last week I flashed my Samsung Galaxy S II with the official Android 4 firmware from Samsung. Here’s some information and semi-random thoughts about the upgrade and my Ice Cream Sandwich on Samsung-experience so far.

  1. About the upgrade:
  2. What Ice Cream Samsung is like:
    • Battery life actually seems a bit better than with the Gingerbread-based firmware.
    • Ice Cream Sandwich seems slightly faster as well, more responsive.
    • ICS isn’t all that different, from a user interface point of view. Some small tweaks and usability improvements, but nothing major.
    • Face unlock (having Android unlock your phone after recognizing your face) is a nice gadget, but it’s of little use if you value security.
    • More interesting, from a security point of view, are “encrypt device” and “encrypt SD card”. Should give that a try.
    • The data usage app is really great, allowing you to monitor and manage data usage for the entire device and on a per-app basis. “Data Usage” is, as far as I’m concerned, one of the hidden treasures in ICS!
  3. Tailoring ICS to my liking:
    • I’m not a fan of Samsung’s TouchWiz, which also features in their ICS implementation, so I don’t use it.
    • At first I installed Nova, an ICS-only launcher, but I wasn’t blown away, so I reverted to good old ADW.
    • I rooted the phone with CF-root to be able to install SetCPU.
    • SetCPU, which I had previously used on my HTC, seemed to work all right at first, but it sometimes put my phone into a deep sleep during phone calls or when idle, with nothing but a forced reboot to wake it up. I uninstalled SetCPU (and am still looking for a similar tool to save battery mainly).
    • I also installed AdFree Android, which adds known ad-domains to your hosts-file, having them point to localhost. Only for rooted phones, but it works like a charm. More privacy and better battery-life will be yours!

So I’m good, for now. But I’m sure I’ll be very tempted when Cyanogenmod 9 for the Galaxy SII comes out. Go TeamHacksung!

As found on the web (April 25th)

youtube (feed #51)
generic (feed #49)
generic (feed #49)
generic (feed #49)
generic (feed #49)
generic (feed #50)

Bug and feedback driven development

I’m not a developer, I’m just a random guy who was lucky enough to be around when the web started to happen, back in the nineties. And over the years I might have learned a bit about web development, but still I’m not a real developer. And yet, there I am with two WordPress plugins, fiddling with PHP and JavaScript. I’ll let you in on what’s not really a secret; I’ve made some ridiculous mistakes while coding those plugins. Trial and error, you know. Testing, fixing, releasing and getting feedback. Especially getting feedback!

Real users telling me it doesn’t work, asking for extra features or making proposals to make it better overall, that what I thrive on. The latest example; JavaScript namespaces. Not being a developer means that I know as much about coding patterns as I know about cows. I just hit the keyboard real hard and hope the browser understands what I throw at it. Until a good friend told me to use JavaScript namespaces, to avoid conflicts with other people’s JavaScript. And a week later someone wrote my software just didn’t work any more and I had to start digging and found a JavaScript conflict that was introduced with a new version of AddThis

And those are the moments one grows, as a developer; you start searching for information about scope, anonymous functions and namespaces. You try, it doesn’t work and you dig some deeper, until you stumble on a great question and answer on Stack Overflow with a link to a very detailed article about JavaScript coding patterns. So you go back into ‘vi’ and start changing the code once again and than all of a sudden you have a working version, which your Polish user confirms fixes the problem and you learned a lot while bugfixing.
So kudo’s to all you guys & girls for the great feedback, you rock! Here’s WP YouTube Lyte version 1.1.3 to thank you.

As found on the web (April 18th)

generic (feed #49)
blog (feed #46)
youtube (feed #51)
generic (feed #49)
generic (feed #49)
generic (feed #49)
generic (feed #49)
blog (feed #46)

WP DoNotTrack 0.6.0 and beyond

I finally found some time to continue to work my other WordPress plugin. WP DoNotTrack checks for elements being added to the DOM by JavaScript to stop 3rd party tracking by some of the major plugins or themes.

Version 0.6.0, which I released last week, features a new “forced” option. This mode aims to provide better compatibility with JavaScript-optimizing plugins such as Autoptimize and W3 Total Cache by adding the relevant code only after those optimizers have done their job, using the output buffer. There will probably be a 0.6.1 today or tomorrow, to solve a small problem with mixed HTTP/HTTPS requests on the admin-page while in HTTPS. The output buffer sure is a powerful thing and for version 0.7.0, I’ll build on that to optionally filter the full HTML (with PHP Simple HTML DOM Parser) to stop unwanted requests for images, scripts or iFrames in there.

Do contact me if you found a bug, if you have questions or if you’d like specific feature to be added, I tend to rely heavily on user feedback to improve my plugins! And if you’re happy with how it works, drop by on the WP DoNotTrack-page on wordpress.org to rate it and/ or to confirm it works with your version of WordPress!

As found on the web (April 4th)

blog (feed #46)
generic (feed #49)
generic (feed #49)
generic (feed #49)
blog (feed #46)

Speed matters: re-evaluating WP YouTube Lyte’s performance

So stupid me made a (smallish) mistake when working on 1.1.0, which caused WP YouTube Lyte (rapidly approaching 80.000 downloads, thanks guys & girls) to load immediately instead of waiting for the “document loaded” event (lazy loading). That got fixed in 1.1.2 (which also loads the CSS differently, resulting in 1 file less to request), but the mistake did get me to re-investigate performance.
Exactly how fast is WP YouTube Lyte nowadays? I fired up some webpagetest.org IE9-instances in the Amsterdam node to compare this WP YouTube Lyte powered post on my test-blog with an identical blogpost with default YouTube embedded video. These are the jury’s results for the fastest of 10 runs in both cases (click on the image to actually see the details):

The main figures to compare (normal YouTube embed vs WP YouTube Lyte):

  • time till document complete: 1.612s vs 1.047s
  • time till fully loaded: 4.358s vs 1.385s
  • total number of requests: 13 vs 9
  • combined size of requests: 446 KB vs 77 KB

So using WP YouTube Lyte instead of normal YouTube embeds results in less files to download, less data to transport, the page being ready for interaction quicker and having everything loaded a whole lot faster. These figures are for a single YouTube on a page, but the impact is all the more important if you have multiple video’s on one page (e.g. a category or tag-page for “music” or “videos”) off course.
The full comparison based on 10 tests on both pages:

YouTube embed (full results)Lite YouTube Embed (full results)
doc completefully loadeddoc completefully loaded
min:1612380810471385
median:1918463111911524
max:3221511020782881

So there you go. When in doubt, check these stats and then go install WP YouTube Lyte, because after all speed matters!