Prelude Interactive

OFI, as I recently learned, stands for Opportunity For Improvement.  A few times over the last couple weeks, my GMail account has suddenly been suspended.  The warning displayed is something like this:

If we detect abnormal usage that may indicate that your address has been compromised, we may temporarily disable access. It will take between one minute and 24 hours for access to be reinstated, depending on the behavior detected by our system.

Unusual activity includes, but is not limited to:

1. Receiving, deleting, or downloading large amounts of mail via POP or IMAP in a short period of time.
2. Sending a large number of undeliverable messages (messages that bounce back).
3. Using file-sharing or file-storage software, browser extensions, or third party software that automatically signs in to Gmail.
4. Leaving multiple instances of Gmail open.
5. Browser-related issues. Please note that if you find your browser continually reloading while attempting to access your Inbox, it’s probably a browser issue, and it may be necessary to clear your browser’s cache and cookies.

If you feel that you have been using Gmail according to the Gmail Terms of Use, please contact us.

My first reaction to this message isn’t that GMail is taking a great, proactive step to help protect others in the event my account is actually compromised.  It is actually a mix of panic (70%), rage (20%), and then a deeper, gut churning realization that absolutely everything I do for work goes through this single point of failure, and that I can’t even remember my ehren@preludeinteractive.com password, because it’s probably stored somewhere in GMail (10%).

The first few times this happened, I thought that Google was doing just about the worst job possible in handling these kinds of situations.  I didn’t have any clear information on why exactly the account was shut off, and I could no longer access the Last Account Activity, which is a critical place to look for possible issues.  I do keep GMail open in several tabs, sometimes in several browsers, sometimes on several computers.  However, there’s no gentle indication that I might be using too many resources, and I know they’re smart enough to put some code in there that causes each instance to poll for new mail less often in order to compensate.

As I looked through the forums, I realized that pretty much everyone was in the same situation:  You just have to wait, and they aren’t going to tell you why it’s happening.

There could be reasons for this opacity.  One is Google’s longstanding tradition of completely automating their customer service.  For their scale, I can completely understand this.   Another is that the more information you give to the bad guys, the more effective they will be.  If bad guys understand exactly what the limits are of exploiting GMail accounts, they can adjust to stay within them and send out more spam and compromise more accounts.  However, neither of these things completely let Google off the hook for not improving this process for their users.

Some good did come of this situation, however, and these remedies seemed to help.  I say seemed, because how would I know if they helped or not?

• I did a full virus scan of both my computers, which turned up nothing notable.  I did find that the automated scans hadn’t run for a while for some reason, so this was a good reminder to pay attention.
• I updated my GMail password, which is a process available outside of GMail, and therefore available while your account is suspended.  I used the phone code for this and it worked great.  I can’t tell if this caused my account to come back (which it did soon after).
• I checked my Last Access history, and found nothing unusual.  It’s possible that GMail cleans the violations from this so that a) bad guys get less information and b) users don’t get freaked out when Google’s computational white blood cells dispose of the problem automatically.
• I’m more careful now to limit the number of GMail tabs open.  I often need at least two – one to compose, and one to look up details or continue working.
• I need to develop a contingency plan in case GMail disappears tomorrow, forever.  However, backing up my 3.4GB of mail and 30,000 messages is one of the things that Google says causes accounts to be suspended.  Also, I just love GMail and I don’t want to learn new hotkeys.   At the very least, make sure you export your contacts so you can tell everyone your one, true address no longer works.

So, next time this happens, for no apparent reason, at least I have the solace of having blogged about it.

Now that HelpAttack has been live for just over two months, a funny pattern is emerging around our releases. To put it another way, every time we deploy new features I screw something up. Oh, there are checklists, and unit tests, and functional tests, and the team reviews the features before they go out – all that industry standard stuff. But, I still find some new, unique way to break things each time.

Bugs!

On our first major release, back in August, I wanted to work on some finishing touches on a 3 and a half hour flight from Boston to Austin.  I put in a little snippet of code that would automatically log me in, because I couldn’t access Twitter to perform the conventional OAuth steps.  It worked great and I got a lot done.  That evening the team tested the recent changes and we agreed that everything looked A.O.K.

Of course, it wasn’t – now every user who visited the site would be logged in as @ehrenfoss!  Of course, I didn’t notice as this was how the site usually behaved for me.  My fellow testers also didn’t raise any flags because they “figured it was supposed to be that way for some reason.”

How to avoid this one in the future?  At that point we hadn’t completed any functional tests, which are ways of automating what a web browser and user might to do verify that various pages load, error free, and that the right information appears on each.  These might have caught the problem…unless of course I wrote the functional tests to use my own Twitter account, which seems like something I would do.

The second major release, put out this past Friday, caused an email to go out to just about every user in the system, not just the handful who should have received it.  Oops!  I had left a “to do” comment in one of the configuration files to remove the file and merge the contents with another config file that was more heavily used.  A contractor saw this message and deleted the file, helpfully, except didn’t realize that the contents were still needed.  The email sending code which was using those settings wasn’t effectively hardened against this – it should have checked to see if the settings were missing, null, or zero and stopped right in its tracks.  This time:

• I should have paid more attention to the code repository delete message for this file, which I saw, and did nothing about.
• I should have communicated to the team that we were releasing the code, so no more changes.  Better yet, I should have branched and locked down that part of the repository.
• The email sending code, always a sensitive place for danger, should be more bullet-proof.

The moral of the story is that there will always be bugs.  They will always be there, hanging out in the folds of your shower curtain ready to scare the bejesus out of you (this is what Texas cockroaches do).  They are always caused by a confluence of several events, and almost always by human error.

We’ve had the opportunity to work with Samasource again this fall, and I wanted to follow up on an earlier post about them.  Samasource lets first world companies outsource work to refugees, women, students, and other workers who otherwise would not be as able to find this kind of work.

Leila Chirayath Janah: Ending Poverty in the Digital Age from TEDx Silicon Valley on Vimeo.

The good news is that Samasource is still able to provide incredible value.  HelpAttack! commissioned a research project into the Facebook platform and API and the delivered results are pretty much exactly what we were looking for.  It saved a lot of our time and bandwidth during a period of work when we really didn’t have any to spare.

It seems that Samasource has changed their model and is now focusing mostly on larger blocks of work that can be managed more directly and efficiently, including some relationships with very large technology firms in the US.  Between HelpAttack! and Prelude Interactive, it’s reasonable that we would generate more than 1,000 hours of work in a month, but the fraction that would be appropriate for Samasource workers is still too small for a retained services relationship to make sense.   So, we ended up working directly with a school in Pakistan, without a Samasource person in between, and it turned out fine.

The only thing I feel is missing is more background on the people we’re working with.  What’s their story?  How have they been shut out of the traditional outsourcing economy, and how did Samasource find them?  I haven’t asked the developers directly – their reasons for working with Samasource may be personal, and we usually have our hands full discussing technical details.

Oh hey, spoke too soon.  Their directory of workers has almost exactly what I was looking for.

If you have well defined technical work that needs to be done, give them a try.  It’s the kind of program that benefits all involved.

This post is just pure SEO love for a solution on the SalesForce Community forums.

http://boards.developerforce.com/t5/Visualforce-Development/Using-the-New-quot-Rich-Text-Area-quot-Data-Type-in-VisualForce/m-p/169410#M21288

I ran into a problem recently where I changed a long text field to a rich text field, but could not use it in a VisualForce page in Sites.  It worked fine viewing the page in SalesForce itself.  I tried a few different combinations of outputText, outputField, escaped = true, escaped = false…. nothin doin’.

I ended up running probably 50 searches on the forums before uncovering this particular post, but it was a life saver.

<apex:outputField value=”{!Event_Course_List__c.Description__c}”  />

I had to remove the following (and closing) tags before the error went away.  The solution

It has been quite some time since I wrote a blog post, and one of the many wonderful reasons why is HelpAttack!  It’s a startup, it’s a service, it’s a very exciting gig for me.  The idea is that you pledge to give to a nonprofit or cause for each Tweet you create.  It doesn’t matter what the Tweet is about, it doesn’t matter who you mention in it, or what tags you include, it just matters that you’ve pledged to give.

For example, you might pledge $0.25 per Tweet to the Red Cross for the month of October.  Then, a few weeks from now, when you Tweet “Eating eggs for breakfast.  They’re a little runny,” that inane fact that nobody needs to know *still* does some good. You can see what I’m pledging to now on my profile page.

Use Twitter?  Don’t be shy – go create a pledge and try it out!