The Nikon pwnage continues with a camera that has built in WiFi and can upload directly to Flickr or a blog.
Nikon’s Flickr/Blogger Cam
Leave a reply
Monthly Archives: August 2007
Revamped OneLight Workshop site
Yes, I shot the Eclipse tonight
The Erlang community
Matt Croydon Didn’t agree with my commentary on the Erlang community, and he’s partially right. I shouldn’t have said “we need a community” because there is an Erlang community, and I knew that. I have never been a fan of Java, and I don’t want to be stuck using the moral equivalent of Java when the multicore/concurrency thing shakes out. So if I want to be able to use Erlang (and I’ve not totally made that decision), then it needs to have a bigger, more diverse, and easier to find community.
Greg Stein mugged
Kevin Burton reports that Greg Stein, who is a friend and has done a lot to help open source in a variety of ways, was mugged last Friday. In addition to the things that Kevin listed, Greg has been very involved in getting Google to fund students to work on open source projects via the Google Summer of Code program. If you want to do something nice for Greg, Kevin’s post has the details.
Opening up to distributed version control
Stefano has written a great introspective post on his inner reactions to a Linus video on Git. It’s good to see people being more open minded about this. I’ve never understood the resistance to distributed version control, especially open source software development is itself an example of the success decentralization. Even the “social” argument that distributed version control would somehow destroy communities seems odd to me. This year at the OSCON Art of Community panel, Karl Fogel said that a tenet of the Subversion team is to avoid using technology to solve social problems. Yet insisting on a centralized version control system seems to me to be doing exactly that. I think its noteworthy that the Subversion team itself has a “hybrid distributed/centralized VC model” as a long term goal.
Centralization in open source projects is a “community smell” (think code smell). It’s best avoided.
Another victory for full feeds
During the bar conversation after the Saturday Seattle Strobist Seminar, a bunch of including James Duncan Davidson and Eric Soroos were talking to David Hobby about full feeds on the Strobist site. In particular, we pointed him to John Gruber’s experiment with full feeds on Daring Fireball (preliminary report on John’s experience). So I was very happy to read that David has decided to try a full feed for Strobist as well.
Since David wanted some more power user full feed info, here’s my take on David’s situation.
The argument for full feeds is that it allows a reader to be more efficient because they can digest more information per unit time. At least that is true for me. The other big benefit is that it allows people who want / need to read offline to do so. The question is, “Doesn’t reader efficiency come at the expense of the publisher”? My answer is, no, not if your content is good. In fact, if your content is good, reader efficiency works in your favor. If your content is good, then you as the publisher doen’t want me to have to break my workflow (by switching to a browser, browser tab, or NetNewsWire tab) to determine that the content is good. If I have to break the flow, there’s much less chance that I will do command-shift-P (in NetNewsWire) to pop the your post into Ecto where I can quote it as part of my post (which ought to generate some additional traffic for you). There’s less chance that I will hit command-1 to pop your post’s title and permalink into Twitterific, where it can get pumped into the realtime information junkie network. And there’s less chance that I will hit command-control-‘ to pop your post’s permalink into Pukka where I can quickly tag it and stick it into del.icio.us, where it can be immortalized as important, seen by my del.icio.us network, and pumped into my blog and tumblog. In other words, you make it hard for people like me to help you. Now you might not care about that, and that’s a completely rational choice. But since just about everything in the blogosphere (after your good original content) is about getting flow (which doesn’t just mean inbound clicks) from other people, it seems like a short sighted thing to make it hard for flow to happen.
There are a few other dynamics which I think are relevant to Strobist, which don’t apply to all blogs.
1. Strobist is not just a blog, it is a source of reference materials. If you metered my accesses to the Strobist site, you would see that I access the site much more as a reference site than as a daily blog. I read the daily blogs, but since I am learning something that requires practice, trial and error, and so forth, I am always pulling up old posts (and those Lighting 101 and 102 pulldown menus) are a godsend for that. Which you have to go the site for. Dropping the 1 click that you would have gotten by forcing me to follow from the partial feed is just noise compared to the other volume
2. The advertisers on Strobist aren’t getting the value from the ads. If you make me go to Strobist in Firefox, Adblock pwns you. I never even see your ads. If you want to get value from Strobist, do something that works with what David is doing. Nonetheless, I’ve ordered several times from the Midwest Photo Exchange, not because they advertise on the site, but because they are doing something that works with what David is doing – so well that David actually writes about it. You might think you need an ad, but what you really need is to do something that will get David to write about you. Strobist is becoming a community, and the advertisers / sponsors of the site will get the most value by being a part of the community (see yesterday’s post on Nikon for tips). And that means more than just doing ads.
3. I was less vehement about full feeds that night (and I do love my full feeds) because I don’t think that David’s audience is an RSS enabled audience. The small sample size at the bar bore that out. So full vs partial doesn’t make that much difference, really. I’ve been reading the blogs of some wedding photographers because I think that maybe someday I might like to take a crack at that. But one thing I’ve noticed is that the word on Strobist is out. I see the techniques being mentioned. People see off camera flash pictures and want to know how to do that. And the answer that invariably comes back is Strobist (or occasionally, the OneLight). You can be sure that this is happening in real life, maybe even more so than on line. So the flow net for Strobist has expanded beyond the RSS savvy crowd and into the real world. No amount of full vs partial RSS feed is gonna change that.
But just in case, click here to convince David of the value of a full RSS feed. 🙂
Scalability != concurrency
Sam Ruby is writing about Russell Beattie writing about Java and Erlang.
Russell thinks Java needs an overhaul. I think that Java has reached the point where technical, community, and business forces well exert pressure on the language to evolve in a uniformly bad manner.
Russell wrote:
The reason people are looking at Erlang is not because its beautiful syntax, great documentation, or up-to-date libraries. Trust me. It’s because the Erlang VM can run for long periods of time, scaling linearly across cores or processors filling the same niche that Java does right now on the server.
Actually, I am looking at Erlang as a solution for anywhere, (including the client) where concurrency will be an issue. By the way, it is not VM’s that scale linearly, but computational problems. And there are some problems which just can’t scale linearly, no matter what VM we put them on.
Sam goes on to make the point which is the title of this post.
Next, to dispel a few myths. Slashdot is written in Perl, seems to handle the load, and also seems to stay up. While there are a number of BitTorrent implementations, the original and (to the best of my knowledge) the most pervasive version is written in Python. Yahoo is a mix, but a good portion of it is written in PHP, with critical functions written in C. Twitter is written in Ruby, had early scalability issues, but seems to be past them. These are all examples of massively scalable applications.
Scalability is not the same thing as concurrency. It is certainly possible to scale a program written in any language – that’s a given. Especially when scaling = throwing more hardware at it. But there’s got to be a better way of doing it. Question is whether the better way is worth the price of admission.
But as far as Erlang vs Java, the real kicker is here:
Unlike the CLR which was designed to be multi-language, and unlike the JVM which is in the process of being repurposed to be multi-language also, Erlang’s VM is designed from the ground up assuming that objects typically are immutable and serializable.
Which is what makes the situation with Java so bad. Not only is the language bad, the VM is fatally flawed when it comes to actor style concurrency (which is why for all its niceties, Scala will suffer the same problems as Java). There’s a real problem here — ask yourself why there is a market for these things, if all that is needed is to throw even more boxes at the problem.
In the comments, Sam wrote;
The biggest problem I have with Erlang is clearly an addressable one: the documentation of the libraries, and the lack of good samples that can be quickly found by Google/MSN-Live/Yahoo!/Ask searches. And many of the libraries appear to be abandoned at 0.n versions.
This is actually 2 problems. There’s the issue with the libraries, and there’s the issue with the community that did/didn’t produce the libraries. We don’t just need a technology, we need a community. Hmm, Erlang lab, anyone?
Yet another reason why Nikon’s star seems to be rising
Nikon has done a great job of featuring the work of Flickr users in their Nikon Stunning campaign, and the Nikon Stunning Gallery tag on Flickr. Now they’ve taken it up another notch by introducing the Nikon Digital Learning Center group. It’s a great idea, marred only by a very unpleasant copyright license policy for pictures in the pool. That doesn’t seem to extend to the discussions, so you could still post pictures there in order to gain educational value from the group. That flaw aside, this Nikon seems to be pounding Canon into the ground as far as their use of Flickr. Oh, and their ability to produce an ISO 25,600 DSLR.
Some simple thoughts on Erlang
Our reading group on Bainbridge Island has been working its way through Programming Erlang. Actually we’re technically not done yet, but since I spent a fair amount of time on the ferry recently, I went ahead and finished it off. There’s been quite a bit of writing about Erlang recently, and I wanted to at least have finished the book before jumping in. Looking at Joe Armstrong’s PhD thesis is probably soonish on my list too.
Basics
Erlang is a functional language which incorporates a concurrency model based on very lightweight processes communicating via messages. I’ll cover the concurrency model a bit more below. Since many people have not really been exposed to functional programming, there are things in Erlang which seem odd when compared to more mainstream languages. In addition, Erlang relies heavily on pattern matching as a flow of control construct, and it takes some time to get used to it. Some people liken the pattern matching aspects of Erlang to Prolog, but this is not entirely accurate because Prolog uses unification, which works in “both directions” and not pattern matching, which only works in “one direction”. I can’t say that I care for the syntax of Erlang, but after using Python, there are very few syntaxes that I really like. Erlang supports higher order functions, so closure based control flow structures are included. There is a fairly usual set of basic data types which are provided. Probably the biggest problem with the basics of Erlang is the way that strings are handled. In reality there are no strings in Erlang, and strings are just lists of integers. More on that below.
Concurrency
Much of the current interest in Erlang is due to its concurrent programming capabilities. The foundations of these capabilities are the availability of processes at the language level. Erlang allows a programmer to create and destroy processes quickly and cheaply (in terms of resources). Processes can only communicate with each other by sending each other unidirectional messages. Every process has a mailbox, which is where messages for it are delivered. The messages are queued there until the process explicitly “receives” them.
The code that implements a process typically consists of a tail recursive loop which explicitly “receives” messages and uses pattern matching to examine the messages and dispatch to the correct behavior. Replying to the sender of a message must be handled by the programmer, but it is easy to code up simple rpc style message passing. Two (or more) processes can be linked to each other so that when one process dies, the other is sent a signal. The preferred mode of handling errors in processes is to kill them and restart them. This signaling forms the basis of the supervision tree concept in OTP. The basic concurrency model of Erlang is a version of the Actor model developed by Carl Hewitt at MIT. I took Hewitt’s class while I was an undergraduate, so the concepts were familiar to me. Erlang is relatively blind to where a process might be running – in the same VM, in a different hardware thread on the same VM, or on a VM on different computer altogether. This makes it easy to write programs that can grow easily when you want to add hardware, whether that is processors or computers.
OTP/Mnesia/ETS/DETS
The folks at Ericsson have also provided a bunch of libraries to raise the level of abstraction for concurrent programming in Erlang. There are 3 major libraries. OTP (Open Telecom Platform) helps a programmer to write scalable, fault-tolerant code. It takes advantage of Erlang’s hot code update facilities to allow processes to be upgraded in place. The basic abstractions to do this are very simple to work with. OTP includes the notion of supervision trees, which is an abstraction for managing networks of processes.
Mnesia is a (potentially) distributed database written in Erlang. It provides an easy mechanism for storing Erlang terms. While it is not an RDBMS, it does provide a query mechanism based on list comprehensions. It also supports transactional behavior and has the ability to duplicate Erlang tables on other machines
Runtime
One thing that isn’t discussed enough are the features of the Erlang runtime/VM. The runtime is very efficient at managing processes, much more so that languages like Python, Ruby, or Java. Erlang programs have been deployed in telephone switching products for years, with extremely long uptimes – due in part to Erlang’s hot code swapping capabilities. Java’s hot code replacement or Python’s reload are substantially weaker than Erlang’s hot code swapping. So while libraries that provide an actor like model can help people learn a good programming model for concurrency, it’s less clear to me that the languages (and the implementations of those languages) hosting the libraries will be as good as Erlang when it comes to highly concurrent applications. Of course, if an application isn’t that concurrent it might not matter.
Conclusion
Semantically, there is a lot to like about Erlang – the actor based concurrency model, hot code swapping, higher order functions, and (once one gets used to it) pattern matching. The OTP libraries have been refined by many years of production usage in demanding, commercial applications.
At the same time, there are number of issues which I think are real barriers to Erlang adoption. The syntax will prove difficult for many people, which is a big issue. I’ve already mentioned the problems with string handling, and really that generalizes to a lack of libraries for performing 21st century / web computing tasks. The nice thing about telephone switches is that you don’t really have to talk to the world. But if Erlang is to be viable as a solution for mainstream programming as it moves to more concurrency, Erlang programs must be able talk to the environments around them.
I am aware of several projects where Erlang is being used to do the heavy server lifting and then data is being passed off to programs written in more familiar languages like Python, Ruby, or Java. Certainly this is one way that people could begin to exploit the benefits of Erlang without converting wholesale. It would also give the Erlang community some time to improve Erlang to the point where it could be adopted by a larger audience.