Archive for the 'development' Category

Update: Amazon Refunded my AWS Developer Bootcamp Fee

Amazon has agreed to refund the $175 fee I paid to attend its Amazon Web Services Developer Bootcamp in December.  I didn’t feel the bootcamp quite lived up to what it promised.  A marketing manager for Amazon AWS says the organization has received some “valuable feedback” and that they “will be making changes to improve the training and provide additional levels of training.”

More in-depth training that goes under the hood of an actual application would be great.  And if anyone attends an AWS bootcamp in the meantime, I’d love to hear how it went.

Why I Can’t Recommend the Amazon AWS Developer Bootcamp

I’m attending the Amazon AWS Developer Bootcamp today in Silicon Valley, to learn how to use Amazon’s “cloud computing” services like Elastic Cloud Computing (EC2), and Simple Storage Service (S3), for lowering Web hosting and infrastucture costs.  Unfortunately, we’re off to a slow start.

Nearly three hours into the class, we’re still on introductory slides and there’s confusion among attendees about how Elastic Block Storage works.  Also, the network here has slowed to a crawl so even the presenter’s online examples are being impacted.  Usually, at conferences, I forgive the inevitable network issues that arise when a roomful of developers go online at once.  But when you charge for a class focused on Web-based technologies, I think it’s a requirement to be prepared to handle the traffic.

Still, I’m hoping things pick up after lunch and that we actually into the examples.  The goal is to get under the hood of a video sharing application that runs off EC2, S3, and other Amazon Web services. Fingers crossed.

Update: We got a little further after lunch, and finally got a little more hands-on with some of the tools available for administering EC2 and S3.  So we practiced launching Linux and Windows server instances, transferred files to S3 buckets, and mounted EBS volumes.

But we were clearly short on time and had to skip most of the code examples.  In particular, we never got to the video sharing application — which was the entire reason I signed up.  While administering AWS is a necessary step in developing and deploying applications on Amazon’s infrastructure, it’s hard to justify spending $175 and the related costs of an entire day away from the office only to come back with no real insight into the architecture of an AWS application.  The session was touted as a “Developer Bootcamp” after all.

What could the presenters have done differently?  Four things:

  1. Skip the 45-minute-long “team building” exercise at the beginning of the day.  For a one-day session during which there is no other group work, there’s no need to “team build.”  If you want to encourage people to meet others, a 10-minute round-robin of people introducing themselves and saying why they are attending would suffice.
  2. Don’t switch the software requirements once attendees arrive (as our presenter did.)  We wasted valuable time as everyone tried to download the new code samples and consequently brought the entire network to a halt.  People should arrive at the session with all the necessary software installed and ready to go.   If people need help with configuring the software, maybe ask them to arrive early during the breakfast portion of the day?
  3. Ensure that the network can handle the traffic.
  4. Don’t spend so much session time answering tangential questions.  The goal of the day is to provide a developer-level look at how one can build an application on AWS.  Attendees who have specific questions about AWS or need clarification on things that aren’t core to the session should be encouraged to re-ask their questions at lunch.

Hopefully the presenters will improve in subsequent bootcamps.  Based on the peformance at this one, however, I can’t recommend it to other developers.

Update 2: Amazon has refunded the $175 I paid to attend the class.

why security by obscurity only works for a little while

When my local swim center set up their P.A. system, they decided to make it accessible via phone.  That way, staff members wouldn’t have to walk back to the office to make an announcement over the loudspeaker — they could just pick up any phone at the center, dial the P.A. system’s phone number, and start speaking.

I guess they figured the system wouldn’t be abused because only the staff members would know the phone number.  What they didn’t plan for, however, was telemarketers accidentally stumbling across the system as their auto-dialers try every possible phone number.

So imagine my surprise — and everyone else’s there at the pool the other day — when in the middle of the usual lap swim time a pitch for carpet cleaning services suddenly blasted out from the speakers.

Moral of the story? Just beause you think you’ve hidden some technical feature where no one will find it doesn’t mean they won’t.  If it’s important to you to hide something, use real security measures like a password.

Creating Smarter Interfaces with jQuery (and Drupal): Presentation Slides

Building Smarter User Interfaces with jQuery: My Talk at this Weekend’s BADCamp

Want to learn how jQuery can help you build smarter, more dynamic user interfaces — in particular, within Drupal?  I’m presenting an intro session at this weekend’s Bay Area Drupal Camp (BADCamp) gathering in Berkeley.

The session is on Saturday at 11am.  Drop by and check it out if you’re attending.  For those who can’t make it or didn’t register before alll the spots were gone, I’ll post my notes here.

Facebook Apps Access Dropping In and Out

Looks like a DNS problem this time.  Both apps.new.facebook.com and apps.facebook.com, the domains from which applications are initially accessed, have gone offline several times today — at least for Comcast customers — according to reports in the forums.  (I can confirm this too, and I’m on Comcast.)

It’s unclear if it’s a Comcast problem, a Facebook problem, or something else.  But Facebook does plan to get rid of the .new. subdomain now that the new profiles are rolled out, which would require some DNS modifications. And given the company’s track record, I’m not entirely ready to give Facebook the benefit of the doubt.

Lessons from the Palin Email Hack: How to Provide More Secure Password Recovery than Yahoo

The only really shocking things to come out of the hacking of Sarah Palin’s Yahoo-based email account are the revelations that:

  1. The Governor of Alaska uses the free Yahoo email service for work-related emails; and that
  2. Yahoo uses really bad security practices for its password recovery system.

Indeed, it’s the latter point that makes the former all the worse.

If the so-called hacker who accessed Palin’s emails is to be believed, Yahoo allowed the intruder to reset the password on Palin’s account simply by answering some security questions.  And sure enough, that’s exactly how Yahoo’s password recovery system works: You answer some simple questions like “Where did you meet your spouse?” and Yahoo checks to make sure your responses match up with the answers you provided when you first created your account.  In other words, these questions serve as a secondary, “backup password.”

Password recovery security questions for Yahoo Mail

The problem with security questions like these is that they’re all too easy for almost anyone to answer.  This is especially true if you have information about your life published on the Web (as Palin found out) — or, more likely, if you publish that information yourself on blogs, social networks, profile pages, and so on.

So what should Yahoo have done instead?  Or, more importantly, if you’re developing a Web site that needs a password recovery feature, what should you do?

Read more »

facebook rolls out incomplete upgrade, makes apps hard to find

While rolling out new new profile pages to users today, Facebook also released a modified Apps toolbar — which no longer shows recently used applications.  Developers are not happy about this (myself included) as it makes it difficult for users to get back to applications they’ve used but haven’t yet formally bookmarked.  It’s a good bet that a lot of apps will show a dip in return visits beginning today.

Screenshot of temporary Facebook Apps toolbar

To make matters worse, there seems to have been no advance warning of the change.  And as of this morning, the Facebook Beta site that is supposed to act as a preview sandbox for developers didn’t show the change either.

Facebook’s response?  A company rep posted this in the forums after developers complained: “We’re sorry about the confusion — we’re in the midst of finalizing the feature and what you see here is definitely not final!”  No word on what the final version will look like nor when it’ll show up.

As I was just saying, Facebook’s seemingly haphazard release process is harming its relationship with the developer community.  The more the company ignores the needs of developers who, in many cases, are building their businesses and livelihoods on Facebook’s platform, the less chance it has of sustaining the budding market its created.

Update: Facebook finally posted a note about the upcoming changes to the application menu on their Developer Blog at the end of the day.  I logged back into my Facebook account and noticed the menu in the lower left corner of my window, as the blog post notes.  However, I’m not sure I would’ve found it there without having read the post.  Hopefully they find a way to notify users of this change.

Drupal for Firebug: The Smarter Way to Debug Drupal

At last night’s San Francisco Drupal Users’ Group meetng, Matt Cheney of Chapter Three gave a demonstration of Drupal for Firebug — a combo Firefox extension and Drupal modle that lets you send Drupal debugging and status messages to Firebug.

“A smarter var_dump()” is one way to think of it.  But it also does several other handy things, like let you see how and where forms are altered by various modules, gives you access to the user object for inspection, and lets you execute PHP from Firefox.

Definitely something to check out if you’re developing modules or themes for Drupal.

Facebook CSS Problems are Messing Up Apps

Some Facebook apps are currently messed up due to what looks like Facebook not parsing app stylesheets and missing its own master stylesheets.  It’s unclear how many people and how many apps this affects, but it’s a major screwup.

Clearly, managing a site that serves tens of millions of people on a regular basis is no easy task.  But it’s not the first mistake that has made the site or the apps inaccessible.

If Facebook wants its ecosystem of third-party apps to thrive — and expects developers to build businesses on the Facebook app platform — it has to start treating the platform like a true business-level service.  And that means getting a grasp on Facebook’s QA and deployment processess so that bugs like these don’t keep knocking apps offline.

Facebook App With Missing CSS

Next Page »