Lightweight Languages Blog

Automator: More Than Meets the Eye

kcarlson — 2007-07-02T10:19:35-05:00

Mike Reilly's recent conversation with Sal Soghoian, product manager for automated technologies at Apple, really is an eye-opener if, like me, you've underestimated Apple's Automator Technology. Automator is a technology for building workflows out of actions by visually wiring together a sequence of those actions. As such, it's an end-user app, a visual programming tool for novices. But one of the common misconceptions about Automator, even among developers, is that actions are just wrappers for Applescript. Not so. As it turns out, you can build Automator actions from just about any language, which gives them enormous flexibility and untility for developers.

Bray Talks Tech

kcarlson — 2007-06-04T12:21:07-05:00

Tim Bray is truly one of the guys that just keeps the Internet humming along. He's the co-author of the XML 1.0 spec, and co-chairs the IETF AtomPub Working Group. His main job these days, however, is to evangelize developer technologies inside Sun, and to get the word out to developers about technologies being developed by Sun. He describes himself as a "two-way evangelist." John Dorsey had a talk with him at RailsConf2007.

Picking an AJAX Framework

kcarlson — 2007-05-07T12:27:08-05:00

The AJAX framework space is really starting to look like a robust place to do development these days. The number of choices is proliferating, and the level of maturity and polish in these frameworks is remarkable, and improving by the day. But not all frameworks are created equal, of course. How to choose? You need to consider how well the framework fits the style and structure of your development team. Critically, you need to see how well the widgets in the framework map to the desired feature set in your app. And then you need to know how easy those widgets are to customize. Andrew Turner and Chao Wang make it all a bit easier for you by revealing their decision-making process when choosing a framework for their latest project in "AJAX: Selecting the Framework that Fits."

Getting Started in LSL

kcarlson — 2007-04-09T12:30:44-05:00

This week, we continue our focus on the Second Life virtual environment. As a programmer, what do you need to know? First, and possibly most important, is that nearly everything you see and touch in SL was created not by Linden Labs, Second Life's creator, but by user-programmers within the virtual world. With the Linden Scripting Language, and Second Life's built-in IDE, you can create fabulous objects and (potentially) get paid for them. Here's how.

Scripting a Brave New World?

kcarlson — 2007-03-12T13:33:06-05:00

Unless your cave is particularly dark and deep, you've no doubt heard about Second Life, the virtual world where players own land, gather together with like-minded avatars, and run businesses (sometimes even successfully, though that's not the norm yet). Is it a bright, shiny, brand-new world with huge potential, or a flash in the pan? At Dr. Dobb's, we're betting on the former, which is why we've just announced our Dr. Dobb's Life 2.0 project. This is a world where code creates value, so it's a natural place for good programmers to shine. To help you do this, we're committed to bringing you the tools you need to be successful in this virtual universe. For starters, check out "Using the Linden Scripting Language."

Future-Proof Mapping

kcarlson — 2007-02-12T14:00:01-05:00

Maps are on everyone's web site these days. Google, Yahoo and Microsoft have made it pretty easy. But can you count on these services working as you expect well into the future? If you need to switch from one map provider to another, how easy will that be? Lionel Laské creates an API that insulates you from changes like these, making it an easy matter to switch from one provider to another without extensive code changes. Read all about it in "MyMap: A Portable API for Maps."

Delivering the Goods

kcarlson — 2007-01-16T14:18:43-05:00

AJAX and other Web 2.0 technologies continue to have explosive growth. Increasingly, the pressure is on to deliver fast, lightweight and secure apps with the new technology. But developers face a number of hurdles. As so often happens in the software world, this is a case of an initial technology being used for something it was never designed for. HTTP was never meant to do what we're now asking of it. So there are performance issues. There are also security risks. In "The AJAX Application Delivery Challenge," Lori MacVittie lays out the problems facing Web 2.0.

Trust Me

kcarlson — 2006-12-18T13:52:50-05:00

One of the reasons I love small, lightweight scripting languages is the way they often are used: as the glue to hold together a loose confederation of cooperating (or occasionally competing) technologies. I've always found it strangely comforting—sort of an algorithmic "can't we all just get along" plea. So it's also fitting that many of these languages have been instrumental in creating the latest crop of Web endeavors, which themselves are highly dependent on trusted interactions, not only between software components, but between people. In his article "Web 2.0 and the Engineering of Trust," Michael Swaine explores the issue of trust, one crucial component of Web 2.0 businesses.

A Common Framework

kcarlson — 2006-11-17T14:39:17-05:00

The Rich Internet Application (RIA) world these days is a soup of technologies looking for a common ingredient. Consider all the varied and often overlapping technologies for creating web app functionality: JavaScript, AJAX, Java, XML, HTML, and Flash all either compete or cooperate in building today's crop of web apps. Will we someday have a uniform, well-defined way of building components for this new platform? Jim Grandy of Laszlo Systems thinks so.

Revenge of the Rubyist

jwoehr — 2006-10-22T05:16:55-05:00

Zed Shaw (author of the well-know Ruby tools Mongrel, liteweight web server and the Rfuzz fuzzifying HTTP client used in Web testing): One thing I'm currently working on is called Utu. It's not a Ruby project. It's a networking protocol.

Railing against Rails

jwoehr — 2006-10-22T04:45:10-05:00

Ben Bleything (Portland, Oregon): This is my first RubyConf. I've been a Ruby programmer for about a year and a half.

Yukihiro "matz" Matsumoto

jwoehr — 2006-10-21T02:27:35-05:00

Matz invented Ruby. The name came first, as Masayoshi Takahashi told us this morning. "Has to be a gem," an associated advised Matz. "Why?" "Because of 'Perl'," was the answer. I hadn't been able to help noticing the pride Mr. Takahashi had expressed in the fact that Ruby is the first significant and widely accepted programming language to arise in Japan.

Who Attends the RubyConf?

jwoehr — 2006-10-21T01:31:10-05:00

Mike Howard is a veteran of programming, weighing in at 40 years in the trade, still active, still questing. I asked Mike what brought him to RubyConf 2006?

Mike Howard: I've been looking for 8-10 years for a way to build web applications that is efficient. The first thing I tried was a bunch of m4 macros and C macros that translated stuff. Every time I see a web framework I try it. That got me into Ruby. I've become really interested.

For these past ten years, I've been a consultant, doing a broad range of things, device drivers, applications, system administration ...

I'm trying to narrow my focus to something I can manage a little bit better, to stay the lone wolf, to keep from going insane. The breadth of what you have to know and the speed at which you have to learn new information pretty much follows Moore's Law. It's impossible to keep up, especially if you cover too broad a spectrum.

I think of it in terms of efficiency. I started out programming in Fortran. I eventually found C and Pascal. About 5 or 6 years ago I discovered Python and started doing everything I could in Python and PHP.

Ruby is a step above that. I've come to appreciate just how efficient and concise the Ruby syntax is and how much easier it is to solve problems in Ruby than it is in other languages. Just as a guess, there are probably two orders of magnitude of ease in Ruby compared to C, in terms of the code you have to write. I haven't measured it.

Ruby is readable. I don't write in languages that aren't readable. I have code that I wrote close to 20 years ago that's still running and the people that I wrote it for still know where I am. I may have to fix it someday.

Riding the Rails to Denver: Day 1

jwoehr — 2006-10-20T14:40:56-05:00

Denver is beautiful in the fall. The sky is clear, it's 61 F., and from behind the stark and rugged Rocky Mountains the clouds bringing this weekend's projected snow are looming like bread rising out of the bowl.

RubyConf 2006 - Introducing Jack Woehr

jjainsch — 2006-10-18T20:58:59-05:00

As of this date, we're handing over the reins of our Ruby Show Blog to Jack Woehr: computer scientist, programmer (contributor to the Ant project, etc.), long-time Dr. Dobb's contributor, and general Renaissance type whose interests run the gamut from goose-keeping to arranging for the Hayden Duet-layout concertina.

Jack will be reporting from RubyConf 2006 in Denver, October 20-22.