Nate Beck

This user hasn't shared any biographical information

Homepage: http://blog.natebeck.net


Posts by Nate Beck

Tip of the Day – Deploying a scalable widget

Jan 6th

Posted by Nate Beck in Tip of the day

1 comment

Believe it or not, widgets do go viral.

An excellent example of this was back when I worked at Snapvine. We setup our signup flow, and launched our widget on MySpace. Our initial user base of 20 users sky-rocketed, and within one week, we had 400,000 users signed up.

I’m not saying results like this are typical, but they do happen. And like Snapvine, they kind of sneak up on you without any warning. The problem that most viral widget developers run into is very similar to the Slashdot effect.

Let’s take a look at the Snapvine widget example. After week one, 400,000 users have installed the widget. Let’s say that an average person’s profile page is visited twice a day. Once by them, and once by one of their friends. You’re looking at 800,000 requests hitting your servers, daily!

So here you have a really cool widget that users just love. Word of mouth is spreading. Users are posting on their friends message boards (omg, u hve GOT 2 chk out my Napolean Dynamite boblehed. w00t). Before you know it, your server can’t keep up with all of the requests, or your hosting provider’s bandwidth allotment has been reached, and down goes your widget.

Nothing makes a person pull a widget off their profile page faster than it not working.

But alas my friend, there is hope.

The best solution that I have found thus far is to use Amazon S3 to host your creation.

Amazon S3 is a completely scalable service which also allows you two very important ideals. Pay only for what you use, and pay after you use it.

Paying only for what you use is a huge deal when you’re deploying a Flash widget. I’ve talked to many people who fell into a very common pitfall. They invested large amounts on money into into either a dedicated hosting solution, or leasing some rack space and providing their own server hardware. However, when their widget didn’t go viral like they were hoping, they were still stuck having to pay for their infrastructure that wasn’t being used.

Amazon S3′s monthly billing setup is also a major benefit for us Flash widget developers. You can host a widget, get paid for showing advertisements, and your Amazon S3 bill doesn’t show up until the end of the month.

If you want to play around with estimated Amazon S3 (US) costs, check out my bandwidth calculator. Also you can use the Amazon Services calculator if you wanted to price out additional Amazon services.

:: UPDATE ::

ComputerWorld released an article this morning about Amazon’s new S3 payment options.

This is really cool! Imagine a setup where you can offload bandwidth costs to the people advertising within your widgets. That way you’re not having to pay it out yourself, and advertisers only have to pay bandwidth actually used. This can make for an enticing advertising package setup.

,

Tip of the Day – Why Widgets?

Jan 5th

Posted by Nate Beck in Tip of the day

No comments

So why widgets?

That’s an excellent question! Here’s an excellent answer.

I’ve seen time and time again, companies and individuals trying to create the next MySpace. Frankly, chances are you are going to fail, and fail miserably. An Epic Fail if you will.

And here’s why. Let’s take a look at your typical social network junkie.

Name – Ashley Smith
Age – 18
Gender – Female
Network of choice – MySpace
Logs on – Multiple times a day (morning, lunch break, evening, before sleepy time)
Favorite Bands – Coldplay, Paramore, Jonas Brothers
Favorite Books – Twilight (omg, the movie was sooo amazing, I’ve seen it, like, a 100 times)

Having sat in on more than my fair share of focus groups, the majority of social network users spend the majority of their online time on said social networks. Especially with widgets and the splendor of OpenSocial and the Facebook Developer Platform, users are spending less and less time visiting other websites.

[sidenote]
You might be asking yourself. Why build a widget instead of a third party application for social networks? I’ll address this in more depth in a later tip, but the quick answer is, there are pros and cons to both. One of the biggest pros for widgets is cross network support. However, there are absolutely times when developing a third-party application over a widget is the best choice, but more on that in a later tip.
[sidenote]

Trying to create your own social network is a fruitless endeavor. Think of who you’re trying to compete with.. MySpace, Facebook, Bebo, Orkut, Hoverspot, MS Live, VampireFreaks, etc… Even if you were to get venture capital backing, it’s an extremely tough market to break into now-a-days.

So back to the question at hand… Why Widgets?

Social network users love widgets

Nothing says how cool I am more than a Napolean Dynamite bobblehead on my profile.

Widgets allow you to take your content to the masses

Driving traffic to your website can be done, but it’s never going to be anywhere near the same amount of traffic that the social networks already have. It’s much easier to cast a net into a raging river, than it is to divert the river.

Widgets are portable

They are not just limited to Social Networks. Take the YouTube.com external video player for example. Their embeddable video player shows up on blogs, webpages and pretty much anything that will render HTML (exception: the iPhone, Apple allow Flash on the iPhone already, gosh).

Widgets are a fairly inexpensive way to get your name and brand out there.

Build something really cool, and allow social network users to run with it. Next thing you know, people have heard of your company. Especially helpful if your target demographic is 16-28 year olds.

Widgets can make you money

Widget advertising is a new market, there hasn’t been a lot done with it yet. Personally, I think there is a huge revenue stream there that is waiting to be tapped. Just be careful when advertising inside widgets. Some social networks will shut you down if you’re trying to make money on their network without their consent. A wise MySpace employee once told me that sharing some of your advertising revenue with MySpace is better than not getting any revenue through MySpace.

So that’s it for our first Tip of the Day, thoughts?

,

Happy New Year! Tip of the day!

Jan 5th

Posted by Nate Beck in Tip of the day

1 comment

One of my a new years resolutions I made this year is to post more to this blog.

While writing my last blog post dealing with widget development, I accrued a large list of tips and tricks that I’ve learned over the years. There are way too many to put them in a single post.

So in honor of Senocular, who probably doesn’t know it, but has taught me a lot about Actionscript and Flash development in general, I’m going to start posting a Tip of the Day. The first few tips will be dealing with widget development.

I’m going to post a different tip everyday for the next 30 days.

You can also take a look at the original AS3 Tip of the Day, which is still an extremely valuable resource.

,
A simple application only using a combo box is still 56 KB

Widget development on the Flash Platform

Jan 2nd

Posted by Nate Beck in Flex

6 comments

An interesting conversation has been happening for a while over on flexcoders. The conversation started with a simple question… Whether or not using the Flex framework is a good idea when developing widgets.

First a little background about me.

A little while back, I worked for a small startup named Snapvine. Snapvine currently has many widget offerings, one of which still gets loaded millions of times each week. These widgets are deployed across hundreds of social networks (who knew there were so many). As the lone flash developer in the company, it was my job was to create and maintain all of these widgets.

The great thing about Snapvine was that I was surrounded by brilliant people, we discussed the Flex framework in extraordinary detail, weighing the pros and cons of using such a framework in our widgets.

So that brings me to the whole point of this blog post… pros and cons for building widgets for the Adobe Flash Platform using Flex.

[Sidenote]

My experience in widget development was mostly focused on development for social networks, so I might say some things that may not apply to other types of widget development.

[/Sidenote]

– Pros –

Flex does a lot of the work for you

Flex does so much of the heavy lifting for us. If you’re ever bored, skim through the Flex documentation. It’s not uncommon for me to find things within the framework I didn’t know existed.

Also, If you haven’t already done so, I highly recommend picking up the O’Reilly Flex 3 Cookbook, or thumbing through it at your local bookstore. I’ve found some really great things in there that I didn’t know about the Flex Framework.

Flex allows quicker development time because there is less code YOU have to write.

Once again, Thanks Adobe… for doing my work for me.

RSLs decrease frequent loading time

The use of Adobe’s Runtime Shared Library significantly reduces multiple loads of your widget. This is because parts of the Flex Framework become cached inside the Flash Player itself. One of the big benefits of the framework RSLs is that not only your widget benefit from them. The framework is cached the first time ANY Flex content, on any site, using framework RSLs is loaded.

One caveat to Runtime Shared Libraries is that you have to configure your widget to utilize them during compilation. They don’t just get used magically. This also means that when you deploy the widget on your web server, you need to also upload and distribute the RSLs.

So if a user visits Picnik, which uses the Flex framework RSLs. Then the user visits a myspace profile page with your widget on it, they wouldn’t download the framework RSLs again (if you and picnik.com are using the same version of the SDK).

Myspace wants users to use Flash Player 9 and above

A while back Adobe and MySpace scratched each other’s back a little bit. Adobe added support for MySpace to disallow navigation events from flash widgets (allowNetworking=”internal”), and MySpace in turn highly recommend users to upgrade to Flash Player 9 (I’m pretty sure they also did this for the video support in Flash Player 9). Myspace did this by prompting users to update their Flash Player if they detected version 8 and below.

That’s a BIG pro for us widget developers, because that means the majority of our widget market is using a player with loads of the features we know and love. At the time of this writing, I’m unsure if MySpace is pushing Flash Player 10, I haven’t noticed it yet.

[Rant]

I’m currently writing this post aboard an airplane at 33,000 feet. Would the person who keeps passing gas, please knock it off, this is an enclosed air system for heaven’s sake.

[/Rant]

– Cons –

Flex is huge, comparatively

300 KB is still too big for dial-up. Many people argue that if people are using MySpace on dial-up, that they’re used to slow loading times. It’s not uncommon for a MySpace profile to be littered with hundreds of 100 KB photos, music, etc… However, that brings me to one of my main points.

By keeping your widget small, It’s more than likely going to load prior to other things on the profile. This is key for getting your brand out there. In Snapvine’s case, this meant that before pictures of friends, before the music players, before the slideshows… Snapvine’s logo was spinning on the page.

Bandwidth is expensive

If your goal if for your widget to go viral, bandwidth is something you should consider. It is bandwidth which drives how much money you are going to spend.

This calculator estimates how much it would cost if you were hosting your widget on Amazon S3 (US).

If you want a direct link… Widget Bandwidth Calculator
If you are curious, you can view the source.

Why is this a con? Using the Flex framework bloats a swf’s file size, and ultimately costs you more money, even if you are using Runtime Shared Libraries.

A simple application only using a combo box is still 56 KB

A simple application which is JUST a combo box, is still 56 KB, even when using Runtime Shared Libraries.

Flex was built primarily for Enterprise Development

This means that lots of the components within the framework, are pretty much useless within widgets. For example, using a datagrid to show massive amounts of data… not really a good use for a widget.

Remember, we’re talking about widgets, not about widgapplications (my spellcheck doesn’t like that word). Most widgets are fairly simple apps. Examples – a music player, slideshow, awesome video slideshow, small game, etc…

Keep your widget fairly simple, if it begins to become too complex, you should probably ask yourself, “Should I be building a 3rd party application (OpenSocial or FBML) instead of a widget?”

It’s hard to selectively use pieces of Flex

I’m not going to say that it is impossible, but loads of classes in the Flex framework are dependent upon each other. Which means that if you’re going to use one Flex class within your widget, it will import ALL of it’s dependencies, whether you use them or not.

– Nate’s opinion –

If I’m building a widget whose soul purpose is to go viral and be loaded millions of times a day, I’m going to write it in straight ActionScript.

Sure, it will take a bit more time, but in the end I’ll save money, have more granular control over my widget, and feel good about myself.

, , , ,

Why YOU should contribute to Flex.

Dec 14th

Posted by Nate Beck in Flex

5 comments

So I’ve been developing Flex since the 1.5 days, and before that using <cfform format="flash">, aka flex-lite. Yet, until recently I haven’t really been too involved with the community… well unless I needed something. I guess I’ve pretty much been self-absorbed and in my own little world.

I’ve now realized that the only reason I’ve ever found what I needed was because someone was willing to share. I know, I know… you knew that already… sometimes I’m one taco short of a combination plate.

So here are the reasons why YOU should get involved with the Flex (and flash) open source world.

The Adobe Team

I had the opportunity to meet some of the Flex team. And let me tell you, these guys (and girls… ahmmm.. Deepa) really care about this project. I’ve never seen a group so devoted to what they do. If you’ve had the chance to read through the specs that the team is putting online. You will see how well thought out the SDK is.

It’s also not uncommon to see the Adobe team participating within the community. If you’re subscribed to FlexCoders, you’ll frequently see members of the Flex SDK team answering questions and making comments. They also answer questions on the Adobe forums. I’m pretty sure the team at Adobe already has a full plate. Yet, they still contribute to the community. They go above and beyond the call of duty. For example, as I’m writing this post at 10pm PST on a Sunday night, I’m watching Alex Harui answering questions on the FlexCoders mailing list. Thanks Alex.

They’re asking for help!

Most people don’t realize how easy it is to get involved with open source Adobe products. Everyone can (and should) sign up for the Bug and Issue Management System. It’s quick and easy to get setup.

If you’re a developer, become a contributor and submit patches. It’s actually much more painless than I thought it would be. I faxed over my Contributor Agreement and was approved within 20 minutes.

Take matters into your own hands

One thing that I have been guilty of in the past is complaining that the Flex framework, or Flash in general, is missing what I consider no brainers. I found myself saying, “Self, why on earth would the person writing the Date class not think that someone, somewhere would want to change the timezone offset”, or other types of complaints. I soon realized that, Nate you dummy, this is an open source project. Fix it yourself! (again… sometimes I’m slow). It hit me like a ton of bricks: If you build it, they will come… errr…. include it into the framework.

It’s more likely that a feature will be put into the framework if it’s already written for them. Heck, in my previous post I was amazed by how quickly my fix was committed to the code repository. Adobe wants us to help! Which is a great place to move on to my next point.

YOU have a say

YOU have a say! It’s our framework. Sure, maybe Adobe has the final say on most of these things. And sure, Adobe may mark your feature request as deferred. But you know what, since it is open source with a public issue system, you do have a say.

Every user within the Bug and Issue Management System has the option to vote on bugs and features. This isn’t a dictatorship. Adobe has given us to right to vote on issues, and if an issue is getting lots of attention from the community, they will look at it and likely fix it.

You don’t even have to be a programmer (or an expert programmer)

I know there are some of you out there who don’t write code, or people who simply think, “I’m not a good enough programmer to contribute to the SDK”. Well good news, you can be part of the revolution too! You have the ability to contribute quality to the Flex Framework and Flash Platform. Here are few ideas: Submit bugs, submit feature requests, correct spelling mistakes in documentation. Get involved!

In regards to bugs and feature requests, I cannot stress this enough. Before you submit a bug, please… PLEASE… verify that the bug (or feature) doesn’t already exist, do some research before you just willy nilly submit feature requests and bugs. It ends up being counter productive. Other people doing the research you’ve should have done now have to spend time cleaning up the issue system because of duplicates and other issues. Having said that, another thing that helps the community is to browse through the issue tracker looking for duplicates, or general cleanup of the issue tracker. If you find something that needs to be cleaned up you can report it to Adobe and they will take care of it.

Anything that reduces the time others have to spend wading through issues is a good thing. It means that the people who are writing fixes to the issues spend less time in the bug system, and more time fixing the issues themselves.

FlexCoders Mailing List

Now I should mention, that FlexCoders is not a mailing list that is controlled by Adobe. It was started by a group of developers within the community. I’ve been following the list for a very long time, and frankly it’s kind of annoying. I’ll be in the middle of typing out a response to a question, when gmail pops up to tell me the conversation has been updated. Maybe it’s just bad timing, but it always seems that someone else beats me to the punch.

Another great thing about FlexCoders is the people that post there regularly. I usually end up laughing over some debate or a nerdy joke that someone included in their response.

Flash isn’t going anywhere

Let’s be honest here, against Silverlight… and whatever Sun, Google, Apple and everyone else is cooking up, The Flash platform is here to stay. With a ~90% client install base, and a large development following. I don’t foresee Adobe taking their ball and going home.

So what does that mean for us developers? We have a stable, time tested platform to develop on. We don’t need to worry about the Adobe going under.

Conclusion

The last point that I want to make… I’m proud to be a Flash developer. Looking at code that I submitted now being part of the Flex SDK just makes a person feel good. I’m beginning to understand why the Adobe Team puts so much dedication into this platform. And I have to admit, that dedication and devotion is contagious.

, , , ,

Flex, DateTimes, .NET….. Why can’t we all just get along?

Dec 6th

Posted by Nate Beck in Flex

3 comments

Recently I’ve been working on a project that has a very interesting architecture. It’s a scheduling application that has a Flex front end, C# .NET Middle tier, nHibernate DAL and Oracle database.  We’re using SOAP to transfer data back and forth to the Flex client…..

[Rant]

I’m well aware of the other options that this client could have used to pass data back and forth. Frankly, I would have been much happier with anything other than SOAP.  But alas, this is the decision the client made before I was on the project. 

<3 AMF

[/Rant] 

….. so there I was, writing a dashboard which polls to see if the data has been updated. The idea is to request data from the server, store the servers timestamp on the client, and then check for updates by sending the timestamp back to the server.

Using C#, the web method is very simple:

[WebMethod]
public StatusResponse IsUpdated(DateTime timestamp)
{
	StatusResponse response;
 
	// Query or do what you gotta to give a valid response based on timestamp
 
	response = new StatusResponse(DateTime.Now, false);
	return response;
}

In Flex I set up a test application which allows me to send requests to the server. I should mention, the client and the server are running on the same machine, which is why I am comparing local client time to server time. This is my result handler

protected function onStatusResponse(event:ResultEvent):void
{
	_lastTimestamp = event.result.Timestamp as Date;
	var now:Date = new Date();
	var diff:int = now.time - _lastTimestamp.time;
	trace("ClientTime: "+now);
	trace("ServerTime: "+event.result.Timestamp);
	trace('Difference (ms): '+diff);
}

As I’m watching my data being outputted, I was a little disturbed with the results.

– Requesting Server Time –
ClientTime: Sat Dec 6 09:09:05 GMT-0800 2008
ServerTime: Sat Dec 6 09:23:32 GMT-0800 2008
Difference (ms): -866850
– Requesting Server Time –
ClientTime: Sat Dec 6 09:09:25 GMT-0800 2008
ServerTime: Sat Dec 6 09:32:00 GMT-0800 2008
Difference (ms): -1355072
– Requesting Server Time –
ClientTime: Sat Dec 6 09:09:25 GMT-0800 2008
ServerTime: Sat Dec 6 09:10:02 GMT-0800 2008
Difference (ms): -37070

You’ll notice that the ServerTime is getting pushed forward by some random amount of time. This is a big problem! If I am polling for updates every 30 seconds, and the last timestamp I received was 10 minutes in the future, the query will always return a status of false.

So what’s going on here? Why does Flex think that my Date is actually in the future when it’s retrieved from the web services?

Naturally, I started by looking at the web service response:

 
2008-12-06T08:49:02.2292832-08:00
false

A status of false simply means that the data has not been updated. Let’s look closely at the timestamp.

2008-12-06T08:49:02.2292832-08:00

According to the w3.org xml schema, everything looks good with that string. But one thing catches my eye: ‘.’ s+ (if present) represents the fractional seconds.

With a bit of research, I quickly learned there is a big difference between milliseconds (0-999) and fractional seconds. The schema doesn’t dictate what precision the milliseconds need to be in. So the C# webservice is using a precision of up to 7 digits. This seemed highly suspect to me, but the string is technically correct.

So now I needed to dive into Flex, and figure out where the data was being corrupted.

** fast forward a week **

After quite a bit of investigating, I figured it out.

frameworks/projects/rpc/src/mx/rpc/xml/SchemaMarshaller.as

Within the SchemaMarshaller, the milliseconds are being treated as just that… milliseconds. So when C# returned fractional seconds with a precision of 7 places (2292832), the marshaller was simply just appending 2,292,832 milliseconds to my date.

I submitted a patch which solved the issue, and while I was writing this post, I noticed that the fix has already been committed into the the Flex 4 repository.

Thanks Adobe, you guys rock!

, , , , ,
« First...«89101112