Peanut Butter Thoughts

“Use one IDE and use it well.” - Pragmatic Programmer

So Silverlight 2 has just been released. The web is aflutter with talk of this and I don’t really need to add to that buzz. What I AM going to talk about for a moment is the budding ability to develop Silverlight applications in Eclipse via the Eclipse4SL project.

I know the big excitement about this is the ability to hack SL apps on a Mac. Seems we’re not there yet. And those Mac users actually interested in the platform are understandably upset. But it’s supposed to be coming soon. In the meantime all that we can do is SL in Eclipse on Windows. But who cares right? We’ve got Visual Studio on Windows. SL can even be developed using the FREE version of VS. And VS is better than Eclipse right?

Well, maybe. Maybe not. I’m definitely not here to discuss the merits of one IDE over another. But I’ve had plenty of people tell me that it’s rocktastic and who am I to argue. But I don’t want to learn it. Am I lazy? Well, yea. I suppose I am. But don’t lazy people make the best programmers? I’ve spent YEARS in eclipse learning the ins and outs; How to use the tools. Starting with FDT doing my AS2 development a long time ago I’ve become comfortable with Eclipse and I don’t want to leave.

Part of my hesitation of learning Silverlight has been the fact that I would have to get used to another IDE. I just didn’t want to do that. But now I don’t have to. I can stay in the comfort of home and invite my MS buddy over for lunch. I suspect that I’m not the only Flash/Flex dev out there who is going to be willing to give SL a test drive now. I’ve seen MS do a lot of stuff right with this Silverlight thing. I’m definitely a Flash platform fan-boy but I’m really glad to see Silverlight pushing it along.

Tell me if this has happened to you: Your client wants a simple change to your awesome Flex application. You rock it out and deliver a new .swf with the piece of cake change. But nothing is different for them! The problem is still there! You spend the next four hours trying to figure out why the fix works for you and not for them. Only to find out that the file was put on the wrong server. Or that their .swf was still cached. Or any number of reasons as to why the newest build isn’t seen. Wouldn’t it be great to know that the .swf they’re seeing is the .swf they’re supposed to see? Maybe some number in there that shows what revision their .swf is?

There are some great tools that handle that stuff for us. CruiseControll is a great example. But usually I don’t need a tool as powerful as all that. And besides, most of that stuff is written for those Java people. I already use Ant to package up my builds for delivery. And I always keep all of my projects in some SVN repo or another. Wouldn’t it be great if I could just stick the SVN revision number somewhere in the application code automatically?

Well I can. And I do. And it’s incredibly handy. My friend and colleague Adam Knauff did a great job of figuring out the details of this procedure. This is how it works. (BTW my work environment is Windows, but you should be able to do all of this on Linux/Mac as well)
(continue reading…)

A recent post on the Facebook Developer’s Blog tells us:

…as part of our ongoing efforts to improve Platform through policy and technology changes, applications are prohibited from dead-ending users at an invite-friends page, and must never again prompt for invites after the user has declined. … please be aware of the reach of your application to those who haven’t sought it out. While we embrace the diversity of tastes expressed by apps, content sent through Facebook’s API communication channels may be encountered by people who don’t share your application’s sensibilities or are otherwise unsuited to it.

I have to tell you I am excited. I’m a Facebook developer, but before that I’m a Facebook user. I’m a pretty “bare bones” user too. I use only a handful of applications, mostly those created by the Facebook staff, and that’s about it. I’ll try some of the other ones if many of my friends are but ONLY if I think that it’s going to somehow make my life better.
(continue reading…)

It seems that the mindset of most modern technical companies (at least those that I have worked for) has been that of production. The idea is that they produce something and the less money they can put into the building of the product the more money can be made in return.

Management, in fact, has been structured to deliver exactly that. Knowledge workers (I do like that term) are usually treated with the same top-down hierarchy that was born of the industrial revolution. Their superiors have orders to wring the most productivity possible out of a worker; time is ALWAYS running short and a worker must be pressed to reach his quota before the time period has ended. “Quotas” of bugs filled and features implemented are treated very much the same as hems sewn or parts welded. But what a lot of companies (and managers) fail to realize is that bugs and features and programmatic problems that must be solved are much less like factory line items and much more like a hand carved doorknob.

One of the reasons why I like the term “knowledge worker” so much is that it is so similar to another hobby of mine; woodworking. The genius craftsman Sam Maloof has often been called an artist but makes it known that he prefers to be known simply as a “woodworker”. Likewise those of us plying the knowledge craft are not artists; though often what we do can be very artistic and pleasing to the eyes. We are knowledge workers. We work 0’s and 1’s putting them in order in a manner that is pleasing to ourselves and for those that have requested our talent. We learn over the years and grow comfortable with our tools; our skill growing by practice.
(continue reading…)

For the past couple of weeks the Facebook team has been rolling out a JavaScript API. This is the first client-side API to be officially released by Facebook. They’ve had something they call “FBJS” for a while now, and it’s a great tool when you’re working on embedded pages using FBML (which can be an awesome time saver and styling tool). But if you know me well enough you know that JavaScript sucks! Ok, it’s better than not having JavaScript but one of the reasons I left the browser arena is because of the frustrations of that language. I can’t deny its popularity and I don’t think that Facebook is doing a bad thing by introducing the API, but I want the same thing in MY language.

I’ve been working on my FB AS3 API for a while now. It’s getting pretty close to being done, but there is still one thing that I think will keep it from being taken seriously. The security of the API (as well as every other client side FB AS3 API) is pretty lax. I don’t want to give any secrets away (pun intended) but Flash apps that use the API aren’t very hard to hack. The JavaScript API, however, uses the idea of session only authentication and doesn’t rely on using the secret the way a server-based API (such as Java or PHP) does. Instead it relies on the callback settings for the application to keep things secure. This article on the Facebook Wiki gives better details about the authentication model for the JavaScript API.

So hopefully, as the work on the API winds to a close, I’ll be able to implement some of the logic of the JS API to make ActionScript secure as well. If you’ve got any ideas on how to proceed then please leave a comment or drop me a line.

-Jason Crist