Vivek M. Chawla

ERD "Crow's Foot" Relationship Symbols [Quick Reference]

2013-04-07T22:23:47-07:00

For some reason, every time I sit down with an Entity Relationship Diagram, the first thing I have to do is try to remember what the relationship symbols mean. Doesn't matter if I cranked out 5 ERDs last week. The meanings of the various chicken-scratches...err, crow's feet...just never stick in my brain.

To help myself out, I've created this single page, printable PDF and tacked to my bulletin board. Nice to know it's there waiting to help the next time I forget this stuff.

Download the PDF here: ERD Relationship Symbols Quick Reference.pdf

How To Set Up URL Forwarding in AWS Using Only Route 53 (Amazon DNS) and S3

2013-01-11T16:28:13-08:00

Objective

Using only the tools available in Amazon S3 and Amazon Route 53, create a URL Redirect that automatically forwards http://url-redirect-example.vivekmchawla.com to the AWS Console sign-in page aliased to "MyAccount", located at https://myaccount.signin.aws.amazon.com/console/ .

This guide will teach you set up URL forwarding to any URL, not just ones from Amazon. You will learn how to set up forwarding to specific folders (like "/console" in my example), and how to change the protocol of the redirect from HTTP to HTTPS (or vice versa).

Step One: Create Your S3 Bucket

Open the S3 management console and click "Create Bucket".

Step Two: Name Your S3 Bucket

Choose a Bucket Name. This step is really important! You must name the bucket EXACTLY the same as the URL you want to set up for forwarding. For this guide, I'll use the name "url-redirect-example.vivekmchawla.com".
Select whatever region works best for you. If you don't know, keep the default.
Don't worry about setting up logging. Just click the "Create" button when you're ready.

Step 3: Enable Static Website Hosting and Specify Routing Rules

In the properties window, open the settings for "Static Website Hosting".
Select the option to "Enable website hosting".
Enter a value for the "Index Document". This object (document) will never be served by S3, and you never have to upload it. Just use any name you want.
Open the settings for "Edit Redirection Rules".
Paste the following XML snippet in it's entirety.


  
    
      https
      myaccount.signin.aws.amazon.com
      console/
      301

If you're curious about what the above XML is doing, visit the AWM Documentation on "Syntax for Specifying Routing Rules". A bonus technique (not covered here) is forwarding to specific pages at the destination host, for example "https://redirect-destination.com/console/special-page.html". Read about the element if you need this functionality.

Step 4: Make Note of Your Redirect Bucket's "Endpoint"

Make note of the Static Website Hosting "endpoint" that Amazon automatically created for this bucket. You'll need this for later, so highlight the entire URL, then copy and paste it to notepad.

CAUTION! At this point you can actually click this link to check to see if your Redirection Rules were entered correctly, but be careful! Here's why...

Let's say you entered the wrong value inside the tags in your Redirection Rules. Maybe you accidentally typed "myaccount.amazon.com", instead of "myaccount.signin.aws.amazon.com". If you click the link to test the Endpoint URL, AWS will happily redirect your browser to the wrong address!

After noticing your mistake, you will probably edit the in your Redirection Rules to fix the error. Unfortunately, when you try to click the link again, you'll most likely end up being redirected back to the wrong address! Even though you fixed the entry, your browser is caching the previous (incorrect!) entry. This happens because we're using an HTTP 301 (permanent) redirect, which browsers like Chrome and Firefox will cache by default.

If you copy and paste the Endpoint URL to a different browser (or clear the cache in your current one), you'll get another chance to see if your updated entry is finally the correct one.

To be safe, if you want to test your Endpoint URL and Redirect Rules, you should open a private browsing session, like "Incognito Mode" in Chrome. Copy, paste, and test the Endpoint URL in Incognito Mode and anything cached will go away once you close the session.

Step 5: Open the Route53 Management Console and Go To the Record Sets for Your Hosted Zone (Domain Name)

Select the Hosted Zone (domain name) that you used when you created your bucket. Since I named my bucket "url-redirect-example.vivekmchawla.com", I'm going to select the vivekmchawla.com Hosted Zone.
Click on the "Go to Record Sets" button.

Step 6: Click the "Create Record Set" Button

Clicking "Create Record Set" will open up the Create Record Set window on the right side of the Route53 Management Console.

Step 7: Create a CNAME Record Set

In the Name field, enter the hostname portion of the URL that you used when naming your S3 bucket. The "hostname portion" of the URL is everything to the LEFT of your Hosted Zone's name. I named my S3 bucket "url-redirect-example.vivekmchawla.com", and my Hosted Zone is "vivekmchawla.com", so the hostname portion I need to enter is "url-redirect-example".
Select "CNAME - Canonical name" for the Type of this Record Set.
For the Value, paste in the Endpoint URL of the S3 bucket we created back in Step 3.
Click the "Create Record Set" button. Assuming there are no errors, you'll now be able to see a new CNAME record in your Hosted Zone's list of Record Sets.

Step 8: Test Your New URL Redirect

Open up a new browser tab and type in the URL that we just set up. For me, that's http://url-redirect-example.vivekmchawla.com. If everything worked right, you should be sent directly to the sign-in page of your AWS console!

Because we used the "myaccount.signin.aws.amazon.com" alias as our redirect's destination URL, Amazon knows exactly which account we're trying to access, and takes us directly there. This can be very handy if you want to give a short, clean, branded AWS login link to employees or contractors.

Conclusions

I personally love the various AWS services, but if you've decided to migrate DNS management to Amazon Route 53, the lack of easy URL forwarding can be frustrating. I hope this guide helped make setting up URL forwarding for your Hosted Zones a bit easier.

If you'd like to learn more, please take a look at the following pages from the AWS Documentation site.

Vivek M. Chawla
Vivek.M.Chawla@gmail.com
January 11, 2013

Page-Level Permissions Now Available for Google Sites

2011-08-21T12:09:14-07:00

I fired up Google Reader this morning and came upon the most wonderful news. Normally, I'd simply share the item with a quick note, then move on to the next shiny bit of news.

But not today. Not for this. This is too awesome.

The most glaring limitation of Google Sites, a key part of the Google Apps suite of cloud-based productivity and collaboration applications, has finally been addressed.

Google Sites now supports page-level permissions!

Anyone who has built or maintained an effective Google Apps installation has made the difficult choice between creating several redundant "private" Sites with limited users, or one big free-for-all Site where everybody sees everything.

For example, if you wanted a corporate intranet, you were forced to make one Site where each department could see the content for every other department. This is fine for companies whose corporate culture is somewhere between "Kumbaya" and "We Are the World".

If you work someplace like this, please email me directions to where your leprechauns keep their gold.

Back in the real world, you probably found yourself doing something like this: You'd create several departmental sites, linked awkwardly from one to the next, and tie them all to one large "Master Site". Need to change something that effects the "whole" intranet? Well, cancel your weekend plans because you've got a ton of manual changes ahead of you. Fun times, eh?

Thankfully, that's all in the past now that Google has debuted page-level permissions for Sites. Thank god!

Enabling Page-Level Permissions for Google Sites

According to the Google Docs Blog, only site owners can enable page-level permissions, which are turned off by default. Once enabled, page-level permissions make some pages private for certain users, while allowing other pages to be viewed by a wider audience.

The new permissions work much as you'd expect. Pages can inherit current site-level permissions, and you can elect to include, or ignore, any future site-level changes. For more information, check out Google's getting started guide.

What's Next (Hopefully) For Google Sites?

Truly, this is a HUGE upgrade. Page-level permissions open up a world of new possibilities for any organization using Google Apps. Make no mistake, though. There is a LONG way to go to truly perfecting Sites.

For starters, Google must extend the permissions scheme to include comments. This would allow site viewers to participate in discussions without requiring them to be site editors. After all, just because I want you to read and comment on my blog, doesn't mean I want you editing my posts.

The editor for Sites could also use an update. Table editing, in particular, needs some love. For that matter, Google Docs needs a better table editor, too. Come on, Google...Two birds are sitting here waiting for you to pick up this stone!

It would also be very useful to save page drafts. Perfect for when you're working on something that you don't want to share with everybody just yet. This functionality already exists when adding posts to pages created with the "Announcements" template. I hope that Google can find a smart way to incorporate this functionality more broadly within Sites.

Finally, I'd also like to see a way for custom URLs to be used for non-public Sites. This is a tough nut to crack given Goolge's distributed infrastructure, so I won't hold my breath for it. Besides, I'll have my hands full consolidating all those departmental Sites into single, secure, one-stop-shop Intranets.

Sweet!

Google Apps Gets Serious About Business

2011-04-28T23:12:27-07:00

It had to happen eventually, but part of me never really believed that this day would come.

Google is changing the billing options for Google Apps, reducing the number of free users you can create under the standard Apps account from 50 to 10.

That's right...TEN.

An 80% decrease in the number of accounts you can set up before having to upgrade to Google's premium "Google Apps for Business" service is a dizzying change to people (like me) who have been allowed to use the best email and collaboration platform in the world for FREE over the past 5 or so years.

For small businesses (and the people who support them), Google has long provided an irresistible platform on which to build a basic, solid, IT infrastructure. Running 50 users for free on Google Apps almost felt like stealing. It was so good, so solid, so compelling, and so cheap (FREE!), that to do anything other than run your small business on Google Apps seemed like a complete mistake.

Despite my indulgent, reactionary whining about the change, this change is not all bad. Google is also introducing a "flexible billing" option which charges only $5 per user, per month. This is a bit more on an annual basis than the $50 per user, per year that Google currently has, but it does allow for more flexibility for those who only need services over a very short term. Seasonal businesses could really benefit from this new model, saving a significant amount of cash over the old, annual-only plan.

Google's still going to honor the 50 user limit for everyone who signed up before May 10, 2011. And May 10 just so happens to be the opening day of Google IO. I wonder what new and exciting features will be released to coincide with this new pricing?

As for me, I'll be across the Pacific in Malaysia that week, instead of at Moscone West. I'll keep an eye on the Twitter streams of my San Francisco bound peers to get the first read on whatever it is Google's going to do next with its more evolved, more "flexible", Google Apps platform.

Is Google Losing Its Mojo?

2010-12-09T14:41:04-08:00

Marc Benioff stunned a room of 15,000 DreamForce 2010 attendees yesterday during his keynote address about the future of the Salesforce.com platform and application clouds.

No, it wasn't Database.com, Chatter Free, RemedyForce, or the super-cool debut of SiteForce. Don't get me wrong, those are great stories with game-changing potential for Cloud developers (again, SiteForce...Wow!). They just weren't heavy duty jaw droppers.

This one was.

Salesforce.com is acquiring Heroku for $239 Million.

What is Heroku, and what does this have to do with Google's mojo?

Heroku is a multi-tenant platform and hosting environment for Ruby on Rails. Using Git, an application developer pushes code to a repository on Heroku. This code is automatically compiled into a self-contained, read-only application, ready to run on the Heroku grid. They manage all the infrastructure and software layers, actively curating everything to ensure stability and scalability. It's an example of a Cloud Technology concept called Platform as a Service ("PaaS"), and it's part of the most important evolution of IT in over a decade.

Google's been in the PaaS game for almost two years with Google App Engine. First previewed in spring 2008, App Engine promised something amazing: Give developers access to the same building blocks that Google uses for their own applications, then run and scale them reliably...even under heavy loads with large amounts of data. As someone who loves application development as much as I loathe system administration, App Engine was the most exciting thing I had seen in a long time.

Since it's launch, Google added a Java runtime to App Engine and worked very hard to extend application quotas and increase reliability (not always successfully). But what's been happening lately with App Engine?

Aside from last week's release of the 1.4.0 SDK, Google's been pretty quiet about App Engine the past few months. Check out the App Engine Blog and you'll see an alarming decline in posts since August 2010. Normally, I wouldn't think too much of this, but after Google suddenly pulled the plug on Google Wave earlier this year, anyone working with a "Beta" Google product should ask themselves the following: "What has Google done lately to demonstrate that this technology is going to be around next year?"

Meanwhile, in roughly the same time frame, Heroku has delivered a beloved service to a large, active development community. They seem to have taken the promise of App Engine, and simply kicked Google's ass at execution. Now Salesforce.com sweeps in and scoops them up, betting $212M cash (and another $27M in stock) that PaaS for the masses has legs. With that kind of commitment, I think it's safe to say that Heroku will still be here when Dreamforce 2011 rolls around.

What does this have to do with Google's mojo?

As an IT professional, I've believed for years that Google is the platform of the future. Stop me at a cocktail party and I would talk your ear off about how Going Google will change your life. Google's services weren't always perfect, but they were innovative. Sure, they lacked features sometimes, but improvement came incrementally and consistently. And best of all, the price point (free) was impossible to argue with. Betting on the Cloud was easy because the Consumer's biggest barrier to entry (price) was eliminated.

I think that Heroku's success indicates that a profound change has occurred. Moving to the Cloud is not just about "free" anymore. Moving to the Cloud is about being FAST. The argument is no longer how much money you can save, but how quickly your business can pivot when it needs to.

I still love Google, even as I worry about App Engine's future.

Full disclosure: I absolutely love Google. I'm proud to be called a Google Fanboy, especially when photographic evidence exists to support the claim.

My enthusiasm for all things Google has survived the death of Wave, the birth of Buzz, and the completely useless introduction of Instant Search. But watching Heroku mature this year (not to mention Salseforce.com's multi-million dollar endorsement yesterday), has made me realize that Google is not always going to be as innovative as I want to give them credit for.

In the end, that's why I feel like Google is losing its mojo.

When an unashamed fanboy like me pulls himself out of the Google-juice long enough to ask "why is Google dropping the ball so much lately?", maybe an alarm bell should be ringing somewhere in Mountain View.

George Hu Demonstrates Siteforce at Dreamforce 2010

2010-12-08T19:29:12-08:00

This is unbelievably cool!

If Siteforce works even HALF as well as it appeared to in this demo (and if Salesforce.com sets pricing low enough to appeal to non-enterprise customers), then this is going to change small business IT forever.

I hope Salesforce is looking harder at lowering prices for small customers. Chatter Free is a nice first step towards finding a middle ground between Google's low cost suite of (very cool) apps and services, and Salesforce.com's expensive (and also very cool) apps and services.

Let's see if SFDC will continue the trend as things with Siteforce shake out over the coming months.

Dancing With Hare Krishnas in Firenze (Florence) Italy

2010-11-10T12:53:17-08:00

This video was taken in Firenze (Florence) Italy in July, 2010. I was waiting in a shady spot for my travel companions to exit a shoe shop. This was Italy, after all.

Suddenly, a parade of Krishna devotees came around the corner and streamed right past me. After a few minutes of shooting video, I shut off the camera and joined in on the fun. Quite the unique travel experience. :-)

Brant Cooper Opens the UCSD Entrepreneur Challenge Fall Lecture Series With Customer Development Principles and Practices

2010-11-08T21:30:37-08:00

Keeping with the "Lean Startup" theme from the Fall 2010 kickoff event, the UCSD Entrepreneur Challenge lecture series opens Wednesday evening with Brant Cooper talking about Customer Development Principles and Practices at the Robinson Auditorium.

Mr. Cooper organizes the San Diego Tech Founders: Lean Startup Meetup, and is the founder of Market by the Numbers, a local high-tech marketing and customer development firm. Brant really seems to know his stuff, and I'm looking forward to an interesting and insightful evening.

RSVP here if you plan on attending (Wednesday, November 10, 6pm). Things begin with dinner at 6pm, so come early to nosh and network!

For anyone interested in more events like this, be sure to become a fan of the UCSD Entrepreneur Challenge Facebook page.

See you there!

Google Giving Away 10,000 Google TVs to App Developers

2010-11-01T11:49:16-07:00

Attention app developers! Google is giving away 10,000 Logitech Revue with Google TV set-top devices at the end of the year in an effort to get you interested in building apps or customizing your existing web site for Google TV.

I liked the promise of Google TV (despite the presentation snafu) when I saw it debut at the day two Keynote address at Google IO 2010. Note that this link just gets you the preamble to the Google TV demo. Hehe...Yeah, there is no way Google wants THAT nightmare immortalized on YouTube.

I've got to say that the Logitech Revue looks pretty damn cool, and I've already signed up for the giveaway contest. If you're an app or web site developer you should, too. Check out the original post from the Google Code blog here

http://googlecode.blogspot.com/2010/10/were-giving-away-10000-google-tv.html

Or, if you want to go directly to the contest entry form, here it is.

https://services.google.com/fb/forms/googletvgiveaway/

Good...err...Goog Luck!

"Lean Startup" Guru Eric Ries Helps Kickoff the 2010-11 UCSD Entrepreneur Challenge

2010-10-29T21:13:38-07:00

Calling all entrepreneurs! The fifth annual UC San Diego Entrepreneur Challenge kicked-off last night with a special event at the Price Center East Ballroom on the UCSD campus. A few hundred local entrepreneurs, business leaders, and students were treated to a fantastic keynote address by Eric Ries, a guru / evangelist of the Lean Startup movement.

Eric is a passionate and engaging speaker with a hell of a story to tell. He begins with the assertion that, as entrepreneurs, we need to Stop Wasting People's Time. He argues that our traditional approach to running startup companies needs an overhaul. Taking lessons from his five year, birth to death experience with a massively funded (and spectacularly failed) Silicon Valley startup, Eric helped build and grow a company that focused on short, iterative release cycles, and (most importantly) continual involvement of the customer to validate product development.

If you can spare 15 minutes, you MUST take a look at Eric's 2010 Web 2.0 Expo address, "The Lean Startup: Innovation Through Experimentation". It's a condensed version of his presentation last night, and it's awesome.

Following Eric's keynote was a panel of local business leaders including the CTO of Qualcomm, the CSO of Life Technologies, and the CEO of Genomatica. Moderating the panel was local venture capitalist Leo Spiegel, a Managing Partner with Mission Ventures. It was great to listen to such a luminous panel of business and technology leaders, but the night really belonged to Eric and Lean Startup.

Fortunately, members of the San Diego Tech Founders: Lean Startup Group got to enjoy a special Q&A event with Eric later that night at Rock Bottom. Many thanks to Brant Cooper for scoring such a great inaugural guest speaker. I'm definitely looking forward to the next Meetup!

And what about the Entrepreneur Challenge? Round one, The Fall 2010 Elevator Pitch, opens today! You must be a student of UCSD to participate, but anyone can (and should!) subscribe to the Entrepreneur Challenge mailing list. There are about a dozen different events held over the year where you can learn and be energized by the dynamic and diverse community of San Diego technology entrepreneurs.

(*Note: If the events are not listed yet, they should show up at that link sometime soon)

Finally, I suggest bookmarking the UCSD Entrepreneur Challenge resource page. You'll find some incredible material there, all available to the public. Stuff like this makes me proud to be a product of UCSD. :-)

Good luck, entrepreneurs!