Instagram Digest : round two

It’s been a couple of month since I mentioned Instagram Digest plugin for WordPress.  Unfortunately, making it work wasn’t as easy as it seemed at first.  The thing is that Instagram’s Developer corner shows you four pieces of information, once you register a new Instagram API application. These four pieces are: client ID, client secret token, website URL, and redirect URL.  Just populating them with sensible values doesn’t necessarily work.

The trick here is to get a little bit of understanding of how OAuth works.  When a new API application is created, there is an authentication stage, where you, as a logged in Instagram user need to confirm access of the newly created application to your data.  For that, a redirect URL must handle the request from the Instagram, and, in case of Instagram Digest plugin, you need to save the authentication token.

Too bad the documentation for the plugin is not too clear on that.  Luckily though, after playing around with an deleting and re-creating the application a few times I managed to make it work …

… just in time for the upgrade of the site to WordPress 3.5.  What’s so special about WordPress 3.5 then? Well, if you look closer at the announcement of this version, you’ll see that the media manager has been changed heavily.  It looks very nice now when you are adding the images the old way, but it also doesn’t work too well with the Instagram Digest plugin.  The gallery is created, but it seems to have all the wrong things in it.  Manually fixing it takes just a few clicks, but is annoying enough, since the whole point of this plugin is automation.

With that, you do have my first Instagram digest post, and a possibility of a bumpy ride for the next few days until I figure it all out.  If you have any ideas on how to fix it, please let me know.  Otherwise, please be patient.  Maybe spend more time with your family during the Christmas holidays instead of browsing through silly blogs like this one.

SPL – Standard PHP Library

I’ve been looking at SPL for some time now.  On one hand, it’s a new addition to PHP core (since version 5.3), so I know how to work without it.  On the other hand, it provides standardized solutions for common problems, and that should be enough reason to start using it.  However, today I came across an interesting article that provides even more reason to use SPL.

In this post I want to investigate the memory usage of PHP arrays (and values in general) using the following script as an example, which creates 100000 unique integer array elements and measures the resulting memory usage:

$startMemory = memory_get_usage();
$array = range(1, 100000);
echo memory_get_usage() - $startMemory, ' bytes';

How much would you expect it to be? Simple, one integer is 8 bytes (on a 64 bit unix machine and using the long type) and you got 100000 integers, so you obviously will need 800000 bytes. That’s something like 0.76 MBs.

Now try and run the above code. You can do it online if you want. This gives me 14649024 bytes. Yes, you heard right, that’s 13.97 MB – eightteen times more than we estimated.

[…]

But if you do want to save memory you could consider using an SplFixedArray for large, static arrays.

Have a look a this modified script:

$startMemory = memory_get_usage();
$array = new SplFixedArray(100000);
for ($i = 0; $i < 100000; ++$i) {
    $array[$i] = $i;
}
echo memory_get_usage() - $startMemory, ' bytes';

It basically does the same thing, but if you run it, you’ll notice that it uses “only” 5600640 bytes. That’s 56 bytes per element and thus much less than the 144 bytes per element a normal array uses. This is because a fixed array doesn’t need the bucket structure: So it only requires one zval (48 bytes) and one pointer (8 bytes) for each element, giving us the observed 56 bytes.

For years I’ve been suffering from PHP’s memory hunger. I’ve had to optimize the code around smaller memory footprints, unset variables, and do all sorts of other messy things, that I normally wouldn’t have in a high-level programming language like PHP. With SPL, it seems, there is more help on the horizon.

LinkedIn “improved” profile

Today I got an email from LinkedIn, telling me that I am about to get an improved profile.

On December 11, 2012, you’ll be getting the new LinkedIn profile, which has a simplified design, provides deeper insights, and surfaces new ways to connect and build relationships. You’ll also be one of the first to preview a new way to showcase rich content on your profile — like presentations, videos, documents, and more.

But it’s not only the new functionality, some of the old functionality will be removed:

Now there are more ways than ever to tell your professional story on LinkedIn, and we’re excited for you to try them out. As we roll out these changes, we’ll also be streamlining our app offerings, so the following LinkedIn apps will no longer be supported on the homepage or profile as of December 11:

  • Blog Link
  • GitHub

Unfortunately, these are the only two applications that I am interested in.  As a blogger, I want to have my blog’s RSS feed broadcast to LinkedIn.  And as a developer, I can’t think of a better way than GitHub profile to showcase my work at LinkedIn.

I wonder what bits of new functionality will allow to compensate for this gaping hole…

Search for emails by size and more in Gmail

Search for emails by size and more in Gmail

Search is one of the two main reasons I use Gmail (awesome SPAM filtering being the other one).  It’s nice to see that Google recognizes it and works on improvements.