Profile cover photo
Profile photo
David Haley

Hey, +Google , Google+ is a little frustrating for photo management. It has amazing editing and viewing, but the actual management is painful, especially when trying to collaborate.

+Sara Antunovich and I started with one album to pare down -- problem #1, we can't actually edit the album together. So Sara had to +1 photos she liked. (On Drive, I can share with edit rights, but Drive is not great for photos for other reasons.)

In order to see just the nice photos, I tried to add those photos to album highlights.

Problem #2: you can't (afaict) search for photos with activity. Really, I have to manually go through 800+ photos finding & clicking them one at a time?

Problem #3: I can only pick so many photos as highlights. So, we decided to move the selected ones to another album.

After selecting our photos and moving them to an album, problem #4: Google+ removed all the +1's and more annoyingly, all the comments we had about which photos needed which edits. 
Add a comment...

Is there a way to disable hangout notifications in Google+? I already get them from gmail/inbox, I really don't need to see them popping up again when I'm trying to manage an album.
Add a comment...

You know you're making it big when transferring your production database to your local machine actually takes enough time that you do something else while waiting.
Add a comment...

A programmer's peripeties in nomenclature:

I need to represent a queue of things to be synchronized. I need a model name for such a thing: ThingToBeSynchronized. Well, that's awkward...

If only English had the present passive infinitive: such paucity! Much lack of conjugations!

If we accept "synchronizare" as the Latin infinitive of "to synchronize", then we could say:


which captures, in a single word, "to be synchronized". 

This pleases me, and is relevant to my interests.
(Yeah, I guess six years of Latin messes you up a little.)
Add a comment...

Post has shared content
Nothing to hide, Citizen?
Since Orwellianism seems to be the theme of the day, (it's the theme of every day, Citizen!) I present to you this rather disturbing little game, "Nothing to Hide." It's very simple: you have to get from one end of each level to the other, and stay in sight of the cameras at all times. Because the cameras are your friend, and they ensure that you are safe. You want to be safe, don't you, Citizen? 

You can play a demo at -- and it's quite playable. In a disturbing sort of way.

Something between credit and blame to +Peter Norvig for pointing me at this.
Add a comment...

Perhaps this will help you: when sending JSON to an APEX REST service, invalid values come back as parser errors. E.g., if you send 2,147,483,648 for an integer field, you'll get something like:

[{"message":"For input string: \"2147483648\" at [line:1, column:48]","errorCode":"JSON_PARSER_ERROR"}]

of course, 2,147,483,648 is an invalid integer; sending 2,147,483,647 works fine.

It wasn't obvious to me that the culprit was a too large number, and I was trying to find a syntax error in the JSON. So, now I know that the parser will fail if the values can't be deserialized into the field even if the JSON itself is valid. #salesforce #salesforcedevs
Add a comment...

Post has attachment
Useful info: if you're working with SFDC OAuth, don't follow the documentation for getting an authorization token back! :-)

The docs ( say to use the standard login URL:

But you should be using your instance e.g.

Thanks +Jeff Douglas for the pointer!
Add a comment...

Do you use a #CRM ? If you wish you could measure lead/contact engagement with your content, and use that to manage your pipeline, I'd love to hear your thoughts!
Add a comment...


I was doing something like so:

  t1.field1, t2.field2, t3.field3
  t1 join t2 join t3 <under various conditions>

It so happens that t3.field3 == t2.field4 (although the database does not know this with foreign key constraints, etc.)

Running the original query took 500ms.
Replacing t3.field3 with t2.field4 brought it down to 15ms. That's 3% of the original time.
Interestingly, t3 is far, far smaller than t2.

This is interesting to me because it shows the massive complexity underlying systems that we usually take for granted. There is SO MUCH happening to answer the query, most of which is "magic" as far as we are usually concerned.
[*] I have several theories for why changing the table from which you grab the field could have such a dramatic effect; most of them have to do with how the data is represented on disk, and therefore, one requires far more I/O than another. It's interesting to me that the much bigger table gives better performance than the much smaller table. Perhaps the query planner is misjudging what it should do? Perhaps the on-disk representations are just that different?

And this isn't an indexing issue, either, because the fields in question are either already indexed or don't appear in join/where conditions.

So, again: Databases: HOW DO THEY WORK. It's pretty damn amazing that they do, though.
Add a comment...

Post has attachment
Add a comment...
Wait while more posts are being loaded