Author Archives: Ted Leung

Congratulations to the Strobist, Again!

Leave a reply

David Hobby, the author of the Strobist blog, is taking a leave of absence from his “professional” job in order to spend more time with his family, and try to make the most of the opportunities presented to him by the amazing uptake of Strobist. I am glad to see that he’s worked out an arrangement that lets him see if Strobist has wings. I, and many others have learned a huge amount from David, and I am sure that this will be an exciting year for him (and us, by extension).

If you aren’t following the Lighting 102 series, you really owe it to yourself to do so. In the second unit, David filled in the one area that Zack Arias’s OneLight workshop didn’t cover that well, the impact of flash to subject distance. As always, no only did David show how it worked, but he explained it way better than just regurgitating the inverse square law: “Light has depth of field.” Great explanation.

I haven’t shot the assignments yet, having been on an “off the grid” vacation for a week (and now trying to dig out after that), but I am anxious to do so. We shot a variation of the first assignment on angle, at the OneLight, so I don’t feel quite so behind. Here’s one of the OneLight angle shots:

Seattle One Light Workshop

Open source peeps and Dopplr

4 Replies

People working in open source have limited opportunities to meet each other in person. My own experience is that meeting someone in person, even if it is only once, can be a help in working with them in the virtual world. The Dopplr service is a social networking application oriented towards people who travel. I’m already using it to find out who is going to at OSCON and ApacheCon US later this year. Meeting folks from various open source communities in person has been an enriching experience for me, and I’m glad to have help at making that easier.

Let me know if you want a Dopplr invite.

Sometimes reading is useful…

2 Replies

Turns out that there is a little more technical information for us poor folks that aren’t at WWDC. So on the topics that I wanted more info on:

  • Multicore – fixes to the scheduler, including processor affinity, multithreaded networking stack, more threading in Mail.app and Spotlight, NSOperation and NSOperationQueue, and OpenMPI
  • 64 bit – 64 bit Java, MySQL and Apache.
  • DTrace / XRay – Dtrace-ified Ruby 1.8.6, Python 2.5, Java, and Perl. XRay alone would justify the $129 upgrade.

There’s also a bit of news on ZFS [via Simon Phipps].

I guess I feel better now. Now if only someone would tell me that Spotlight is no longer crawling…

WWDC keynote impressions

2 Replies

I have to say that I was pretty underwhelmed by the WWDC Stevenote today. Between the combination of last year’s keynote and the promise of super cool, top secret features, I was expecting a bit more than what actually took place. Let’s look at the ten features that were shown:

  1. New desktop – this is pretty, and I will appreciate a unified window look, but I’m doing just fine today. Unlike the rest of the world, apparently, I am using the plain old blue apple background, so a desktop that is friendly to my digital photographs just isn’t making me that excited, although in theory it should. Stacks the only thing that look like a new feature, and while they look cool, I’m not sure that I will use them that much.
  2. New finder – I’d like a new finder – so much so that I already use PathFinder on Tiger. The sidebar searches are nice — assuming that Spotlight actually has something like decent performance now. CoverFlow looks very pretty, but the only time that I can see using it is on collections of images or PDF’s. Looking at my Applications directory using CoverFlow isn’t really very exciting. The file sharing stuff would be good if I actually shared any file with people, but mostly we’ve been doing just fine using the existing, albeit clumsy networking.
  3. Quicklook – This is nice, and it’s nice that enabling quicklook support enables other things, like iChat Theater support. But I’d rather have working (i.e. performant) Spotlight.
  4. 64-bit – A genuine advance. Too bad it missed the window so that we could have 64 bit Photoshop
  5. Core Animation – I’m just not an eye candy guy. There wasn’t really any indication of how much effort is required to build something like the video wall that was demonstrated. Without a look at the code, it’s hard to know how impressed to be by this. It does look like Core Animation is an enabler for lots of what was shown.
  6. Boot Camp – I understand the rationale for Boot Camp, but continue to find the idea of rebooting into Windows a non starter. Give me VMWare or Parallels any day.
  7. Spaces – Virtual desktop management is so 1990’s.
  8. Dashboard – more specifically, a movie widget, and webclip. I can’t remember if we saw webclip last year, but it looked impressive. I am sure that people using Dashboard will find this a boon. Personally, I turned off all the Dashboard triggers because Dashboard is such a resource hog.
  9. iChat – It’s great that there is all the iChat eye candy. I might actually use the iChat theater features, but the big impediment to iChat is that I don’t run it. I run Adium because I need to talk to people not on AIM. Also, my experience has been that firewall tunneling for iChat doesn’t work very well, so it’s anybody’s guess as to whether video or audio chat will work on a given day. I’m basically using Skype for those features now. If Apple improved the firewall tunneling, then this might be interesting. I do give points for leveraging Quicklook to get things into iChat Theater
  10. Time Machine – well, okay, but we saw this last year.

Note that 64 bit support, Core Animation, Boot Camp, Dashboard, iChat, and Time Machine all appeared last year. That leaves the new desktop, finder and Quicklook as the Top Secret features that we’ve waited an additional year for. The things that I really want from Leopard are probably still buried in those NDA’ed sessions. I want my OS to stop leaking VM. I want XRay and ZFS. I want to know if the processor thread affinity problems have been fixed. I want garbage collected Objective-C – actually I want that one for the ISV’s. Perhaps most of all, I want Spotlight to actually be usable for me.

I”m not that excited about Safari for Windows. Since I do “Web 2.0 AJAX apps” for a living now, the last thing that I need is to add another browser/platform combination to the test matrix. It’s great that Safari is so fast on Windows, but that doesn’t really help me much. It kind of bothered me that when Steve talked about increasing Safari’s share, he overlaid the share that currently belongs to Firefox and “other” browsers. That did not make me warm and fuzzy. Nice that tabbed browsing is improving in Safari, but why couldn’t they do something slightly cooler like using stacks to organize the tabs?

As for the sweet SDKless iPhone development story? Well, it’s nice to know the whole Safari engine is in there. Basically what they said is: Hey you can write a dashboard widget that is deployed from the web. Ok. You can build some decent apps that way. I still think that a regular SDK is going to need to happen some day. In the meantime the problems that I have with iPhone remain, which means that I’m likely to end up with something like this. But that’s for another post, sometime in the future.

Twitter in Scala

4 Replies

David Pollak shows a simple Twitter clone written in Scala. Last night was our first Bainbridge reading group meeting on Programming Erlang, so this is timely, as Scala’s actor libraries are modeled after Erlang. Also of interest is the use of David’s lift web framework for Scala, which includes ideas lifted from Seaside, Django, Rails and Erlyweb.

Strobist Lighting 102

4 Replies

It looks like David Hobby over at Strobist is going to run a new version of last year’s summer long lighting workshop. I learned a ton of stuff from the bootcamp last year, and after the OneLight Workshop, I am highly motivated to do a bunch more lighting stuff. If you are interested in improving the quality of your pictures via off camera lighting, you owe it to yourself to participate in Lighting 102.

Silverlight and the DLR

17 Replies

Microsoft has announced that it is embedding a version of the CLR into their Silverlight RIA technology. Blogging machine Ryan Stewart had some of the initial details, and Sam Gentile has a good pile of links. The CLR enabled version of Silverlight will run inside Firefox (both on Windows and OS X) and inside Safari. This is a good step at cross platform support, but the omission of Linux, while not surprising, reduces the reach of Silverlight versus Flash or regular AJAX. Also, it appears that there are no Mac development tools for Silverlight, although presumably there is always text editors.

DLR
The most interesting part of the whole business is the Dynamic Language Runtime, which is the project that Jim Huginin has been working on since he arrived at Microsoft. The DLR currently supports JavaScript, a dynamic version of Visual Basic, IronPython, and IronRuby. John Lam’s work at Microsoft also appears to be paying off. eWeek had three good articles on DLR technology, and all three articles include conversations with Jim and John. It’s nice / interesting to see that two people could have a large impact on Microsoft. The DLR is being made available under a BSD style license. While I have to give props to Microsoft for choosing an unrestrictive license, I’d point out that a license is not a governance system, and while the DLR might technically be open source, the “Core CLR” definitely is not, and neither is the XAML portion of the Silverlight runtime — no surprise there. I wonder if we will be seeing a port of the DLR on top of Mono. I also wonder if IronRuby can run Rails, although that seems like a weird thing to want to do inside of Silverlight.

Linq
Another part which I find interesting is the inclusion of Linq as part of the Core CLR. I like Linq, and if Microsoft is going to try to define a new platform for inside the browser, I’m happy that they’re including Linq as part of the core.

Impacts
Here are some of the potential impacts of this announcement:

Since Silverlight will include the CLR, it will benefit from the CLR JIT and garbage collector, which together with Mozilla’s Tamarin, will raise the bar for JavaScript performance in the browser. It’s unclear whether regular AJAX apps running in a Silverlight enhanced browser would beneft from CLR acceleration of Javascript. I’m in favor of the browser vendors getting into a Javascript performance race with each other.

Allowing people to write browser side applications in multiple languages fragments the technology on the browser side. You could argue that the benefits of either IronPython or IronRuby are sufficiently large over Javascript that such fragmentation is ok. I’m not as sure that this is a good thing.

If there is significant uptake of IronPython or IronRuby for Silverlight development, that could have interesting impacts on the Python and Ruby communities. The Ruby community is already dealing with a proliferation of different Ruby runtimes, so there probably isn’t much new there other than a change in the mix of adoption of the various runtimes. On the Python side, its less clear, since the CPython implementation is the most heavily used.

The inclusion of facilities like Linq will boost the semantic level of the platform running in the browser. Granted, it only does that for Silverlight, but I hope that this puts some pressure on the other players to provide more leverage in the platform. If we are going to be building much richer applications inside the browser, we are going to need all the help that we can get.

So what?
In the end, though, I probably won’t be doing much with Silverlight, for the same reasons that I’ve written about before. The technology has definitely gotten stronger, but the other issues haven’t really changed much: there are no tools for the Mac or Linux, and as far as influencing the technology, you’re just standing outside the Big House, pressing your nose up against the window.

Adobe open sources Flex

24 Replies

Last week while I was in San Francisco, I sat down for an hour with David Wadhwani, the VP of product development for Flex and Ely Greenfield, one of the Flex architects. After I wrote my original post about open sourcing Flash, I got a note from David asking if I would be willing to spend some time to help him understand the issues that I raised in that post and its follow ons. This afternoon David called to tell me that Adobe was announcing that it was open sourcing Flex v3. I was especially happy when he said that my posts and our conversation had an impact on his thinking about open source and Flex. There is a press release with the announcement as well as a FAQ on the basics.

The Basics
The basics of the announcement are that Adobe will open source Flex v3, due later this year, under the Mozilla Public License (MPL), which is sensible given that they have already open sourced their Tamarin Javascript engine via Mozilla. Before that happens, Adobe will make daily builds of Flex available (the source is already available, but daily builds gives better visibility). Also, they will open their bug tracker to the public in preparation for the open source version of Flex.

Adobe is taking a slow approach on governance. Unsurprisingly, the initial set of committers will be folks from Adobe, and the governance model is underspecified. Right now, the FAQ says that the schedule and roadmap for Flex will continue to be defined by Adobe. There are stated plans to create a subproject process and subprojects could be managed by people outside Adobe, and incorporated into the Flex tree. The full governance model is not yet determined, and will be influenced by feedback and what actually happens between now and the end of 2007, which is the target for the transition to being a full open source project.

I think that there are likely to be some concerns around use of the Flex trademark. Unlike Java, where (in theory anyway) an open source Java could pass a compatibility test suite and gain access to the trademark, the open source version of Flex cannot be called Flex. It remains to be seen whether this will actually impact participation in the project.

Flex, but Not Flash
This is a good first step for Adobe, but it’s just the first step. The Flash player is not being open sourced at this time, but when I talked with David he told me that that Adobe had been telegraphing the fact that they were going to open source Flex for about 20 months, since the opening of Adobe Labs. When I asked him about the Flash player, he said that open sourcing Flex should be viewed as a telegraphing of Adobe’s intentions. Of course, there’s a big difference between intentions and actual followthrough, so we’ll have to wait and see how the Flex project ends up working out.

Bottom Line
Adobe is moving pretty quickly. When I met with David a week and a half ago, I got the impression that he and Ely had decided that they wanted to open source Flex, but hadn’t cleared it with his management chain. A week and a half later, they are making an announcement. As I’ve mentioned, this is just a first step for Adobe, and there are plenty of opportunities for things to go sideways. Nonetheless, I think that Adobe has understood the importance of openness and is taking some initial exploratory steps to do what’s necessary.

If you think that an open source Flex is important, then you should go to the new discussion forum that Adobe is setting up for open source Flex. There are a lot of things which are intentionally unspecified, and there is still lots of time to give Adobe feedback on this move. I know that I’m going to keep giving them feedback for as long as they continue to solicit it.

Update:
Scoble has a video interview that lets you hear some of what I’ve heard from David and Ely.