I attended the TCO 2006 finals as a spectator, because TopCoder does attract some really great talent and therefore makes for good recruiting and good entertainment. The talent pool does skew toward non-US and early 20s developers, because as you say, people who already have good programming jobs don't have the time or the real need to put in the hours of practice required to compete at these levels.
But TopCoder is still a lot of fun. I gave it a shot - if you just look at it as a fun way to compete in a field in which you have skill, and not as some reflection on your overall talent level - you can have a good time.
Even being a spectator in the finals - being able to watch the top competitors attack some hard problems in real-time - was an exciting experience.
The SDK is the same SDK used by the official AIM clients, so there are no different rules, and you get access to all the features.
Regarding 3rd party clients - we think that we can build a competitive client. If people don't want to use our client, we don't think it makes sense to force them to do so.
Regarding how this is a good move for AOL - there are a number of IM networks to choose from, and we think increased creativity and client choice is a way to position our network ahead of the rest. Also, ads aren't the only way to make money. If 3rd party clients feature our VoIP service (which is built into the SDK), we make money off that regardless of what client is being used.
Sure. You can speak the straight OSCAR protocol if you want. It's a lot harder than using the SDK - especially if you want to get p2p stuff like file transfer and voice working - but we understand that one size does not fit all.
So any client that properly identifies itself (i.e. does not claim to be an official AIM client and uses an Open AIM key), and conforms to the AIM Developer EULA, will be allowed to use the AIM network, regardless of whether or not they use our SDK.
Of course, I recommend using our SDK. It's robust and fast, and is way ahead of libgaim and other libs in terms of functionality.
We're not joking. The rules have changed. We want people to build on top of the AIM platform. That is why this is a big deal.
Any client that properly identifies itself (i.e. does not claim to be an official AIM client and uses an Open AIM key), and conforms to the AIM Developer EULA, will be allowed to use the AIM network, regardless of whether or not they use our SDK.
Yes. The rules have changed. That is why this is a big deal.
Any client that properly identifies itself (i.e. does not claim to be an official AIM client and uses an Open AIM key), and conforms to the AIM Developer EULA, will be allowed to use the AIM network, regardless of whether or not they use our SDK.
Now, the SDK provides A LOT of functionality, including full support for file transfer, image sharing, voice, video, security - things that would take a long time to get working right if you are starting from the base protocol - so I recommend that you use the SDK.
I think the open IMAP access is not be switched on yet. But as far as I know, that is the plan... from the eWeek article: "AOL already is planning additional features for the full launch of AIM Mail. The service will support the IMAP (Internet Message Access Protocol) standard so that users can access their AIM Mail accounts from other e-mail clients, Ben-Yoseph said."
Seriously. I mean, at least try the product first.
The AOL spam filters have gotten quite good over the past couple years, better than Yahoo/Hotmail and way better than that of your typical cable operator. The web interface is really nice (Mailblocks). There's free IMAP access. And if you use AIM, there's good integration between AIM and AIM Mail. Clearly I'm biased, but I think it's a great product.
Speaking as an individual who happens to be the chief architect for AIM...
* The TOS is confusing, but was meant to apply to AIM Forum posts, not IMs. I agree that we should amend it to clarify this. * The AIM network has hundreds of gigabytes of IMs flowing through it per day. Recording this would be extremely costly (especially for a free service). We don't do it. * If you don't trust us, we have Direct IM and Secure IM in all recent AIM clients that let you send your messages peer-to-peer and/or with industry standard S/MIME, SSL, and AES encryption. There are no backdoors. I know since I designed these features.
Man oh man, I hear you. I've been in charge of the design of the AIM plugin framework, and while I think we are going to have some real good stuff there, I'm also really trying to get us to dial back on the bundled crap - I think it really turns off developers to install something that drops lots of other stuff on your machine.
But we're going to have a nice platform, with web services, SIP gateways, client plug-ins, and a client SDK; there's different levels of intergration depending on what you're trying to do. I just hope that the clever developers out there look at this as an opportunity to build something that millions of people could be using, and aren't put off by prejudice against AIM/AOL.
Anyway - if you want us to "do it right", I'd appreciate it if you would let us know what you would like to see! Email me at juberti [aol.com], or post to my [new] blog on this topic. http://journals.aol.com/juberti/runningman
Slashdot Mirror
I attended the TCO 2006 finals as a spectator, because TopCoder does attract some really great talent and therefore makes for good recruiting and good entertainment. The talent pool does skew toward non-US and early 20s developers, because as you say, people who already have good programming jobs don't have the time or the real need to put in the hours of practice required to compete at these levels.
4 129668120/
But TopCoder is still a lot of fun. I gave it a shot - if you just look at it as a fun way to compete in a field in which you have skill, and not as some reflection on your overall talent level - you can have a good time.
Even being a spectator in the finals - being able to watch the top competitors attack some hard problems in real-time - was an exciting experience.
More thoughts on TCO 2006: http://journals.aol.com/juberti/runningman/
Photos from the TCO 2006 finals: http://www.flickr.com/photos/juberti/sets/7205759
Full security services are built into the SDK. You can use our SSL and/or S/MIME encryption, or implement your own.
The SDK is the same SDK used by the official AIM clients, so there are no different rules, and you get access to all the features.
Regarding 3rd party clients - we think that we can build a competitive client. If people don't want to use our client, we don't think it makes sense to force them to do so.
Regarding how this is a good move for AOL - there are a number of IM networks to choose from, and we think increased creativity and client choice is a way to position our network ahead of the rest. Also, ads aren't the only way to make money. If 3rd party clients feature our VoIP service (which is built into the SDK), we make money off that regardless of what client is being used.
Actually, if you build your own client you don't have to display any AOL ads at all. You are in total control of the UI.
Sure. You can speak the straight OSCAR protocol if you want. It's a lot harder than using the SDK - especially if you want to get p2p stuff like file transfer and voice working - but we understand that one size does not fit all.
So any client that properly identifies itself (i.e. does not claim to be an official AIM client and uses an Open AIM key), and conforms to the AIM Developer EULA, will be allowed to use the AIM network, regardless of whether or not they use our SDK.
Of course, I recommend using our SDK. It's robust and fast, and is way ahead of libgaim and other libs in terms of functionality.
More info: http://journals.aol.com/juberti/runningman
You only need to register your binary if you want higher usage limits and protection against someone else (mis)using your key.
We're not joking. The rules have changed. We want people to build on top of the AIM platform. That is why this is a big deal.
Any client that properly identifies itself (i.e. does not claim to be an official AIM client and uses an Open AIM key), and conforms to the AIM Developer EULA, will be allowed to use the AIM network, regardless of whether or not they use our SDK.
More info: http://journals.aol.com/juberti/runningman
Yes. The rules have changed. That is why this is a big deal.
Any client that properly identifies itself (i.e. does not claim to be an official AIM client and uses an Open AIM key), and conforms to the AIM Developer EULA, will be allowed to use the AIM network, regardless of whether or not they use our SDK.
Now, the SDK provides A LOT of functionality, including full support for file transfer, image sharing, voice, video, security - things that would take a long time to get working right if you are starting from the base protocol - so I recommend that you use the SDK.
More info: http://journals.aol.com/juberti/runningman
Justin
I think the open IMAP access is not be switched on yet. But as far as I know, that is the plan... from the eWeek article:
"AOL already is planning additional features for the full launch of AIM Mail. The service will support the IMAP (Internet Message Access Protocol) standard so that users can access their AIM Mail accounts from other e-mail clients, Ben-Yoseph said."
I will update my blog when I have more info.
Seriously. I mean, at least try the product first.
n itRegistration.psp.
The AOL spam filters have gotten quite good over the past couple years, better than Yahoo/Hotmail and way better than that of your typical cable operator. The web interface is really nice (Mailblocks). There's free IMAP access. And if you use AIM, there's good integration between AIM and AIM Mail. Clearly I'm biased, but I think it's a great product.
If you have an AIM account, you can try it out at http://mail.aol.com/ . If not, you can create an AIM account at https://my.screenname.aol.com/_cqr/registration/i
Some more info at my blog: http://journals.aol.com/juberti/runningman
Speaking as an individual who happens to be the chief architect for AIM...
* The TOS is confusing, but was meant to apply to AIM Forum posts, not IMs. I agree that we should amend it to clarify this.
* The AIM network has hundreds of gigabytes of IMs flowing through it per day. Recording this would be extremely costly (especially for a free service). We don't do it.
* If you don't trust us, we have Direct IM and Secure IM in all recent AIM clients that let you send your messages peer-to-peer and/or with industry standard S/MIME, SSL, and AES encryption. There are no backdoors. I know since I designed these features.
More info: http://journals.aol.com/juberti/runningman
Man oh man, I hear you. I've been in charge of the design of the AIM plugin framework, and while I think we are going to have some real good stuff there, I'm also really trying to get us to dial back on the bundled crap - I think it really turns off developers to install something that drops lots of other stuff on your machine.
But we're going to have a nice platform, with web services, SIP gateways, client plug-ins, and a client SDK; there's different levels of intergration depending on what you're trying to do. I just hope that the clever developers out there look at this as an opportunity to build something that millions of people could be using, and aren't put off by prejudice against AIM/AOL.
Anyway - if you want us to "do it right", I'd appreciate it if you would let us know what you would like to see! Email me at juberti [aol.com], or post to my [new] blog on this topic. http://journals.aol.com/juberti/runningman