Saturday, December 09, 2006

More on Jumpcut

Yesterday, I wrote about Jumpcut. This morning, I tried to see how easy it is to create and publish one of these videos on my own web site. Here is the results of about 15 minutes of work in my pajamas this morning...

Of course the real time is taken in one of these apps when you go to improve it slightly: you can triple the time if you go for perfection...

Friday, December 08, 2006

Jumpcut - Make Amazing Movies Online

Jumpcut - Make Amazing Movies Online

A while back, I wrote the following message to friends: Hello Television Networks...? The gist of that article is that soon we will have the tools to pull together clips from all sorts of sources into compilations which approximate shows.

Well, it took about 1.5 months for me to come across several tools that are headed in that direction. Jumpcut is a tool that allows you to create such a compilation online out of media you have on your PC. I say "media" because you can upload video, music and still images to and put the clips together with titles and transitions to produce a pretty sophisticated flash movie.

This is like having iMovie in your browser: and jumpcut does the hosting! No download of your results yet, but they have got to be thinking about how to do that. Even if they charged me a couple of bucks to download the video I created with their tools, I would gladly pay: it is certainly a lot easier than installing the tools and hosting the video myself (and I am usually against such approaches, preferring to do everything myself). Jumpcut is so easy to use, video compilations should start jumping out at us -- either from Jumpcut or any of several others in this space.

Monday, December 04, 2006

Digital Picture Frames

Digital Picture Frames

The web site above is a very nice survey article about digital picture frames.

For quite some time, we have had a iMac in our kitchen which we use for both a computer, but also as a digital picture frame. By using the excellent Macintosh screen saver, we get a wonderful slide slow which runs when we are not using the computer. I point the screen saver at the pictures I have taken from our latest trip.

Inspired by our kitchen display, a friend and his son built a digital picture frame out of a flat panel display and an old PC running Linux. He mounted the picture frame on the outside wall of a closet and put the computer in the closet. Unfortunately, the computer is not connected to the network and so he has to load new pictures to his frame using a CD.

A while back, when I was trying to use gadgets to keep in contact with my aging mother, I bought a Cevia frame which was pretty cool. You subscribed to their rather expensive service and the picture frame would dial up the service each night and download pictures that you could leave for it using a web interface.

It worked quite well, but the telephone hookup was a little annoying to rely on and the web interface was a little too difficult to use very often.

Inspired by all of this, I have come back to the idea of building a large digital picture frame based on an inexpensive HDTV as the computer monitor and a small wireless PC which could be connected to via the web (or via FTP) for downloading photos or photo shows to be displayed. The parts and the software exist to build a 20x30" flat panel display which could show a continuous presentation of digital photos -- or any other type of presentation you could show on your computer monitor.

All that I need to do is to take the time to build it. More on this later...

Sunday, December 03, 2006

What's the difference between PHP and Javascript?

PHP: Hypertext Preprocessor

For the past 10 years, I have concentrated my programming activities in JavaScript, a scripting language in which programs run inside a client browser. Since I have been focusing primarily on what the user sees on the web, this has served me well. But there were always limitations.

Recently, I have gotten interested in Wikis, which is a particular style of web that allows for both reading and writing. To support writing, it must have a content management system -- a system to hold the contents of a web page and which allows updating that content. I choose to focus on pmWiki because it seems to be a Wiki system which encouraged extensions -- which has turned out to be extremely useful in getting a basic mechanism to do what I want it to do. pmWiki is written in PHP, another scripting language. Unlike JavaScript, PHP scripts run on a server and can produce results (html code) that is shown in a browser.

So, why two scripting languages? Why isn't there a JavaScript that can run on a server? Why isn't there a PHP that can run on a client? For a long time, I couldn't figure out the answers to these questions. Finally, I think I have figured this out.

The differences have to do with the original purpose of the two scripting languages, and the major influences on each of them. In reality, there really isn't any difference between them -- or for that matter between them and Perl, Python and a bunch of others (see Scripting Language). The difference is due to the focus of JavaScript on running in the user's browser -- on the client side, rather than in the service provider's server -- on the server side.

If a script runs on the client side, then it must be prevented from violating the security of the user's computer: with client-side scripts, the script is downloaded from some other source -- whose motives are unknown. To prevent harm from being done, JavaScript has all sorts of restrictions placed on what can be done. One big one is, no interactions with the client computer's file system. This has such a big influence on the language that almost no one thinks of running JavaScript on the server side because it has no way to change the state of anything other than the bounded environment in which it runs. This is not because it couldn't be, but because the developers of JavaScript spent all of their creative energies working in an environment where they were just focused on activities they could perform in a web browser.

The developers of PHP focused their energies on all of the functionality you must have to be a general purpose programming language which can access all of the resources of an Internet connected computer system: they did not spend any time thinking about how to restrict PHP so that it could run client side.

And that is the difference.

I must admit that I am still somewhat surprised that someone hasn't made a bigger effort to develop a version of JavaScript that is fully competitive with PHP, Perl and the host of other server side scripting languages. There are some implementations of JavaScript that run on the server side, but they don't seem to be very popular -- PHP and Perl dominate server side scripting.