AirPort Updates fixes AirPort Extreme VPN Problems · 44 words posted 58 days ago

You might miss it in the Time Machine hubbub, but Apple has quietly fixed its VPN issues in the latest “Time Machine and AirPort Update.”

I can now connect to my VPN even over the Airport Extreme. Run Software Update to get the fix.

Comment

* * *

How to connect OLPC XO to WPA Airport Extreme · 85 words posted 142 days ago

As others have noted, the XO doesn’t support WPA out of the box. A kind soul has posted a shell script to connect to a WPA Wifi network.

Connecting to an Airport Extreme base station is simple: make sure your wireless is set to 802.11n (802.11b/g compatible) with “Wireless Security” set to WPA/WPA2 Personal.

When you run the shell script, the SSID is the same as your wireless “Network Name.” The Pass phrase is your “Wireless Password.” And WPA Version is 1.

Happy surfing.

Comment

* * *

Quick and Dirty MySQL Diagrams on OSX with EOModeler · 510 words posted 343 days ago

Whenever I take on a new project with an existing database the first thing I like to do is generate an entity diagram of all the tables. On OSX you can buy or download any number of third party packages to model tables, but here’s how to do it with software you already own: WebObjects and EOModeler.

The executive version:

Create a MySQL database with Foreign Key relationships; then install the proper JDBC driver for MySQL; finally point EOModeler to your database to generate the diagram.

Although these steps are covered in various places on the web, here’s the whole thing step by step in detail. I assume you have MySQL 5 and OSX 10.4.9.

cd ~/Desktop/mysql-connector-java-5.0.6 sudo cp mysql-connector-java-5.0.6-bin.jar /Library/Java/Extension [Enter your password when prompted] jdbc:mysql://localhost/yourdatabasenamehere

Schweet! You can save the generated diagram and reopen it in Xcode. You should end up with a diagram that looks something like the image below, foreign keys and all. Tip: if you end up with am archipelago of unconnected tables, you’re probably working with MyISAM tables instead of InnoDB.

Questions? Post them in the comments here. Just don’t expect any replies Sunday night. I’ll be respecting the Bing.

Comment

* * *

ColdFusion 8 hosting on HostMySite · 56 words posted 352 days ago

HostMySite is offering free ColdFusion 8 beta hosting for as long as the beta lasts. Amazingly, the plan even includes a 600MB SQL Server database. Plenty of room to kick the tires on someone else’s machine—although HostMySite and Adobe must both have real confidence in the stability of CF8 to offer a deal like this.

(via fullasagoog)

Comment

* * *

Interview: Dave Hoff and Anthony Webb of IMified · 571 words posted 443 days ago

Dave Hoff and Anthony Webb recently launched IMified, “an instant messenger buddy that works across all major IM networks and offers access to a growing number of web applications.” While I’ve worked with the ColdFusion Event Gateway to build automated bots in the past, I’ve never seen the Event Gateway used so well for such broad purposes under a heavy load: IMified provides a single chat interface to Basecamp, Remember the Milk, Google Calendar, and more. I asked Dave and Anthony to talk about their service. And if you haven’t checked out IMified yet, it’s worth your time.

since1968: IMified is one of those great ideas that seem obvious only in hindsight: an IM content aggregator. How did you come up with the idea?

IMified: The idea for IMified came about when I was looking for an easier way to post todo’s to my Basecamp account. I found myself neglecting to add stuff to my projects because the process to do so was too cumbersome. Basecamp is a service I use a lot but doesn’t really warrant me leaving it open in my browser all day. I use IM throughout the day for staying in touch with colleagues and family. It’s always open and available, yet unobtrusive and was a logical interface to “fire and forget” simple data entry tasks.

since1968: Rails gets most of the “Web 2.0” attention. How did you decide to use ColdFusion?

IMified: Choosing anything other than CF as platform wasn’t really an option. Anthony and I are CF developers. When the concept for IMified was finally laid out, ColdFusion became the logical option due in most part to the excellent Event Gateways that are offered out of the box in the enterprise edition. The event gateways allow us to tightly integrate with the IM networks we connect to.

since1968: You say on your blog that your initial growth was almost accidental. For all we know you guys may be running a higher load on the CF Event Gateway than anyone else. What is your load?

IMified: Before launching IMified we did some research and tried to find others out there making use of CF’s Event Gateways under a heavy load. We didn’t find much information to go off of and were really surprised to see that the event gateways were so under utilized. We are handling a very heavy load and CF has handled this load like a champ! Our down time to date has been due to problems with some of the IM networks we run on and one out of control log file that grew to 30gb. In just 3 weeks of operation, our users have completed over 60,000 tasks through IMified!

since1968: What pitfalls did you encounter with the Event Gateways?

IMified: Honestly, none. There haven’t been any surprises as of yet and we don’t expect to see any soon. We’re really impressed with their performance, stability, and ease of use.

since1968: Do you have plans to monetize IMified?

IMified: Yes, we most certainly do. Someones got to pay for all this bandwidth! In the next few weeks we’ll be launching the next phase of IMified that we feel will really change the way people think of IM. We want IMified to be your go-to buddy when you need to get something done at your desk or on your mobile. Somewhere in there will be a business model. Hint hint… API.

since1968: Thanks for your time.

Comment [5]

* * *

The Newest Garrett · 27 words posted 456 days ago

Our first child, a boy, arrived five hours ago in Washington, DC. I’ll be offline for a few days whilst studying the intricacies of burping and napping.

Comment [3]

* * *

Mark Hamburg Interview: Adobe Photoshop Lightroom Part 2 of 2 · 1691 words posted 456 days ago

Last month I spoke to Mark Hamburg, Adobe Fellow, former Photoshop architect, and founder of the Adobe Photoshop Lightroom project. In the first half of our interview we discussed Lightroom’s lengthy gestation and innovative UI. Here’s the second part of our talk.

since1968: Lightroom’s first beta was Mac only. Thanks for the Mac love—but why did you choose Mac first?

Mark Hamburg: I’m primarily a Mac user, and as it happens a lot of people on the initial team were primarily Mac people. We’ve now got some hardcore Windows users on the team for balance. We started out doing what was much more a research project, though, and it seemed sensible to only focus on doing one platform first.

We actually spent a while at one point starting to get things running cross-platform and that managed to sidetrack most of the project. The lesson there was that when you are still figuring out what to build, you don’t want to let yourself be distracted with coming up with cross-platform architectures too early. You want to keep cross-platform in the back of your mind, but the most wonderful cross-platform strategy without a product to build on it doesn’t really get one anywhere.

Another thing that influenced us in this regard is that Photoshop started its current code base in the early 90s. Though it has evolved over time there are certain assumptions built in very deeply that reflect the state of the art at that time and the Photoshop team is having to do a lot of work to move beyond them. When we started what would become the Lightroom project we wanted to focus on building for “modern” operating systems. Mac OS X by that point had been out for a while and was more or less settled. On the other hand Microsoft was busy still just talking about Longhorn, so Mac OS X was in a better position for us to start on when looking for a modern OS.

The irony here is that Lightroom 1.0 ended up being built for XP rather than Vista, and we’ve already felt some development pain from that.

Finally, we knew that in reaching photographers it was really important to get to the influencer market and that market was largely a Mac market. If you go through and look at how the market breaks down among photographers, the influencers tend to be heavily Mac—not entirely, but heavily. The mainstream working photographers frequently are on Windows. In the “prosumer” market Windows still dominates but there’s a mixture. Knowing that we wanted to start with the influencers, we needed to be on the platform they were going to be on.

since1968: Lightroom is 40% Lua. How did you select Lua? Which parts of the program are handled by Lua?

MH: I foisted Lua on the rest of the team which actually at that point was very small. But I had discovered it just in reading some of the mailing lists I was on—I think it was actually a garbage collection mailing list that led me to it.

I wanted to build an app that was heavily scriptable and was looking for a good scripting language to build in and got the pointer to Lua. I’d actually read one of the first papers on Lua several years earlier but hadn’t pursued it because it hadn’t been relevant to what I was doing. At that point Lua was also much more primitive than it was when we picked it up.

Lua has an appealing balance of simplicity and power. It’s small, fast, and easy to embed. It also has a very straightforward license associated with it. It’s very much like Scheme language I like—but without a syntax likely to make people go running for the hills. So there were a lot of things.

I looked at some other things. I looked at JavaScript: Adobe had an internal implementation of JavaScript but it wasn’t as easy to do drop-ins and all the things we wanted to do in the Lightroom project. I looked at Python, I looked at Ruby. Some things were going to be bigger, slower, and had licenses that were harder to figure out. Lua just happened to fit really well.

So what we do with Lua is essentially all of the application logic from running the UI to managing what we actually do in the database. Pretty much every piece of code in the app that could be described as making decisions or implementing features is in Lua until you get down to the raw processing, which is in C++. The database engine is in C; the interface to the OS is in C++ and Objective C as appropriate to platform. But most of the actually interesting material in the app beyond the core database code (which is SQLite) and the raw processing code (which is essentially Adobe Camera Raw) is all in Lua.

since1968: What development environment do you use to write Lua? LuaEclipse?

MH: We have our own development environment. On the Mac side we have a fairly sophisticated IDE that was developed internally as one engineer’s first project when he started on the team. We have a Windows IDE as well. It isn’t as sophisticated as the Mac IDE. I think the people who are doing their primary development on Windows are generally either using the Windows IDE or they’re editing the source code in Visual Studio.

since1968: Whoa—Adobe is known for building or acquiring some famous IDEs: HomeSite, Flex Builder, Dreamweaver. Did you look at your stable before building your own? Any change the Mac IDE will evolve into a future public project?

MH: Tim Gogolin, the engineer who built the IDE, gave a demo at the Lua Workshop in 2005 and had lots of people drooling. We’ve contemplated on occasion whether there was a good way to release it to the public, but it’s pretty tightly coupled to the rest of the Lightroom implementation. It will, however, definitely be included when we do a serious SDK for Lightroom.

since1968: Lua’s not such a common scripting language. Apart from a legion of World of Warcraft modders, do you have to grow your own Lua talent?

MH: Yes, we have to teach people Lua. The benefit is that it’s fairly easy to learn. One of the people who joined the team was an avid scripter anyway, but his comment coming in was that Lua was easier to learn than JavaScript.

since1968: On the Mac, did you use LuaObjCBridge or write your own bridge to Cocoa?

MH: We wrote our own bridge.

since1968: Let’s talk about extensibility. Adobe will release an SDK sometime after 1.0. Data from C is directly accessible in Lua’s userdata type, so presumably Adobe could really open up Lightroom to be extended as far as a developer can take it. Will developers be able to write extensions in Lua?

MH: [Laughing] Developers will have to write their extensions in Lua. At one point—and it probably complicates the app a little—there was probably some notion that we’d provide ways to let people write things in purely native code as well. But I think at this point you will have to write at least part of your logic in Lua for knitting into the rest of the system.

When people ask “What do I do for Lightroom development?” I tell them “Go out and learn Lua. Hack World of Warcraft until we’ve released an SDK.”

Any APIs we publish we’d like to commit to supporting long term. In getting a 1.0 out as we’re sorting through some of the feature set there’s a fair amount of churn on the APIs that we have. Putting out an SDK means we need to start freezing those a lot more, so that’s essentially the delaying factor. After version 1 we get to go through and sort through and say “Yes we can commit to this. We can publish it and put it in the SDK.”

since1968: What’s the coolest Lightroom feature that people haven’t noticed or hasn’t been mentioned in the blogs?

MH: One of the things people haven’t entirely gotten is some of Phil Clevenger’s working from the “inside out” behavior. It takes time to really grasp how to tune your workspace, but once you do, you can get a lot of stuff out of the way.

One of the really surprising features for me in Lightroom came out of the Print module. It starts with doing the basic grid work, but combining extreme grids with the “zoom to fill” options start to push you toward discovering new way of looking at your images and new layouts that wouldn’t have been expected on our part. The grid goes in as “OK we’re dealing with contact sheets and so forth” but what comes out of it is that it actually becomes a viable creative tool as well. That’s somewhat reflected in the 4 Wide templates, but I don’t know that people have really picked up on the fact that if you start pushing the settings in the Print module you can get fairly creative effects out of what otherwise people might have thought of as a contact sheet generator.

The Split Toning controls in Develop actually are fun to use on color images as well as gray scale. They were created for creating duotone-like effects but they actually can be used in interesting ways to enhance color images as well. They’re not particularly good for correcting images. I’ve had people try to push them to correct color casts in the shadows and they’re not really built for that. If you want to put a color cast into your shadow they’re a great tool for that. Not so good if you want to take one out.

Finally, something that applies only to 1.0 and not Beta 4. I’ve been doing more dust spotting work on my images lately, I have to point people to the benefits of zooming to 1:1 (or higher), starting at the top left corner, and then just repeatedly pressing page down. Watch what happens when you get to the bottom of the column.

since1968: Mark, thanks for your time.

MH: You’re welcome.

Comment [3]

* * *

Wall Street Journal finds social bookmarking sites follow a power law curve · 129 words posted 457 days ago

The Wall Street Journal reports on the Wizards of buzz behind social sites like Digg and Reddit and finds that a few influential users generate a hugely disproportionate share of the content (via).

Although the words power law distribution don’t appear in the article, that’s precisely what the WSJ has uncovered: a small number of highly linked tastemakers are the hubs at the center of a scale-free network. Blogs are a classic example of the power law distribution at work: for every Gruber and kottke there’s hundreds of, uh, me.

See:

Comment

* * *

Parsel: a Mint Plug-in for detecting language, now updated · 29 words posted 471 days ago

Parsel is a plug-in for Mint, designed to detect your visitors’ browser settings. It’s updated it to work with Mint 1.29 and higher.

You can download it on google code.

Comment

* * *

Mark Hamburg Interview: Adobe Photoshop Lightroom Part 1 of 2 · 1855 words posted 479 days ago

Adobe Photoshop Lightroom, currently in beta, is Adobe’s newest tool for importing, managing, developing, and printing digital images. On January 19 I spoke with Mark Hamburg, Adobe Fellow, former Photoshop architect, and founder of the Lightroom project. Mark has been working on digital imaging at Adobe Systems Incorporated since 1990 and is currently driving the development of Adobe Photoshop Lightroom.

since1968: You started work on Lightroom partly based on your frustration at working with several gigs of images—but the project has had almost a five year gestation.

Mark Hamburg: Well, Lightroom as a multi-image editor probably hasn’t been going for five years. I left the Photoshop team in spring of 2002, so I’ve been looking at post-PS stuff for about five years. The general direction and focus on how you deal with lots and lots of images in photography workflow grew probably a year plus after that.

I started out worrying about alternative paradigms for image editing, but then my manager at the time, Greg Gilley, who was an avid photographer, started to push toward: “Well, we just have all this stuff, and how do we deal with lots of images and what can we get out of pushing ACR further.” Actually the way he got me to deal with that was he pushed me to go get a camera and start shooting more. I very rapidly determined that as interesting as it was to do image editing there was clearly just a general problem that comes from shooting far more than the tools are really built to deal with. At this stage it’s focused on “I’m shooting gigs of images and I need a tool to deal with that.”

The volume problem really hit home in fall of 2003 when I did my first shoot of nearly 500 images in one day. The things we’d been experimenting with like light table simulations just fell apart in the face of that sort of volume.

Even after that, we kept resisting getting into hard core image management for quite a while because it would pretty obviously eat up everything else we wanted to do and we felt that Adobe had already explored image management with Photoshop Album. We capitulated eventually and it did indeed consume vast amounts of attention and resources and probably could have taken even more if they’d been available.

So that’s my partial defense for why it’s taken so long.

since1968: Is it fair to say that but for Aperture, Lightroom might never have been released? In the podcast it sounded as if LR might not see the light of day. Is that a fair assessment?

MH: Certainly there were a lot of doubts. Adobe has been very successful with Photoshop. From Adobe’s perspective and market surveys every photographer out there has Photoshop. Working through that mindset, it’s sort of a classic thing that happens when you have a product that’s strongly successful: seeing the things that are different from the product is difficult for people whose job it is to spend most of their time thinking about Photoshop. And so we would go through discussions internally about “Well how many people are there like this? How big is this market? Maybe what we want to do is just add something on to Photoshop.” A variety of things like that.

And as we’ve seen in the public beta program, this isn’t just an internal issue. Photographers generally get the program and understand the problems it is trying to solve. People more focused on Photoshop, however, have a harder time seeing where Lightroom fits in.

The benefit for us of Aperture is that it clarified the market for people who had doubts that you could actually launch a product into that space. It certainly raised the pressure to ship Lightroom. As long as there were people with doubts about the existence of the market we could spend lots of time internally just trying to clarify what the market was and how big it was. Aperture’s entry showed that there is a market and we should be pursuing it. It’s pretty obvious that it does match up almost identically with the market we had identified though Apple’s approach to that market is also pretty different from ours when you drop down from the high-level overview.

since1968: One of my favorite Lightroom features is the way the Print module options are integrated directly into panels, instead of opening a new dialog box. Who thought of that?

MH: The notion about doing more without going into external dialogs goes back to an idea that was introduced early on in the project—before we were working with lots of images—taking ideas that had started to evolve in Photoshop with things like Liquify and “Save for Web”: a number of these things were getting to be mini-applications in a dialog. We had these giant plug-ins (we refer to them as “mondo plug-ins”) and the notion got to be “What if you could build an application where everything was essentially these modules that sat on top of the core, and instead of going into a monster dialog and going back—what if you just went from one environment to the next and never went back to a core?”

So the diagram that I would draw for this: Photoshop with a big circle in the middle, and you go out to various things; you go out and come back, you go out and come back. The model for Lightroom was to say “We still have a core but the user never actually goes into it. The user just goes and bounces around the things that are on the outside of the circle.”

So the Print module then becomes a full peer to all of the other tasks. The idea is to take what you would put into an elaborate print dialog and instead bring it up as a user interface for the print environment. And what actually happens inside that environment is the result of lots and lots of iterations. As I joke, the print environment works as well as it does in Lightroom because we made Kevin Tieskoetter iterate on it until his eyes bled.

since1968: In one of your recent podcasts, Phil Clevenger says he demos Lightroom from the “inside out,” with most of the interface hidden. It took me a long time to discover just how image-centric Lightroom’s interface can be. Why not install Lightroom with its panels hidden? Most programs I explore by adding pieces to the interface, but with Lightroom I explore by taking pieces away.

MH: Ideally we would ship it in the ideal configuration to work in; of course that will vary from person to person. If you have all the panels open, unless you’re on a really large screen and it’s far off to the sides—mostly in your peripheral vision—it gets to be a lot of stuff and that’s not ideal.

The notion was to have an interface where we could make things go away. The problem is from the standpoint of users discovering things: if we were to ship it with the panels hidden off to the side users would have to learn “Oh, if I move over and I click this thing on the side and then I pop this panel open it has a bunch of settings that I want.” It seems easier to have them see the settings and then have them learn that they can make things go away and can adapt this in a way that’s ideal for whatever my workflow is. Certainly it does have the downside that it means that the initial launch experience is not reflective of how good the app can be if you allow the interface to get out of the way.

There are people who will run with the top module picker bar hidden. If you ran with that hidden—if that’s how we came up initially—people would have a hard time knowing “oh I can go to these other modules.” They could discover it in the menus but the menus have lots of stuff in them and you have to find and dig through and find stuff.

I think we’re also seeing that web pages have been to some extent undermining the value of the menu bar. People see more things in browsers; the menu bar in the browser is pretty much completely useless in terms of what it contains. People don’t go looking in the menu bar by default as much.

since1968: I’m one of those people who run with the module picker hidden.

MH: Yeah. That’s just it. Ideally Lightroom is designed to run in full screen mode with the menu bar hidden. That was one of our focuses throughout the evolution of the product. Heavy Photoshop users frequently ran in full screen mode and we wanted to build a UI that was really optimized for full screen. At the same time it would be considered pretty rude if when we first launched Lightroom the first thing it does is blanks out everything else on your screen.

since1968: I understand that you want to differentiate Lightroom from Photoshop and the older version of Camera RAW, but sometimes I’ve found the language changes confusing. “Smooth” seems to work like Camera RAW’s “Luminance Smoothing.”

MH: Yes, it does. The noise reduction is same as Camera RAW’s; we’ve had a few terminology differences but those are now getting sorted out with the next version of Camera RAW. The issue for Lightroom was because of the user interface design we tend to favor shorter labels.

If you look at Camera RAW, it stacks the name on top of the slider and so has a fair amount of horizontal space. Because we were trying to make more of the controls available at once, stacking them up vertically, we ended up putting the label off the the left-hand side of the slider. That then means you don’t want to spend a lot of space on the label. So there was a certain amount of “well can we pick a shorter name than this?”

since1968: But at some point Adobe will map the names for various functions and algorithms across its various image management tools? If I perform an action in Camera RAW will it render the same result as Lightroom?

MH: Yes, there will eventually be a version of Camera RAW which will be synched up with Lightroom because we’re building off identical code. This also means all of those cool new development features in Lightroom are making their way into Camera RAW. Not all of the UI functionality is coming over, but all of the processing is showing up in Camera RAW.

since1968: The Sydney Morning Herald has reported that Lightroom will be released on February 28.

MH: That would not be accurate, nor is CNet’s report of January 29 accurate as a release date. The release date is not announced at this time.

since1968: And we shouldn’t expect any more beta point releases?

MH: That is correct. There will not be a beta 5, nor beta 4.2

In Part 2 of the interview to be posted later this week, Mark discusses Lua’s place in Lightroom.

Comment [8]

* * *