The idea of storing data online is sexy. It means easy sharing of files, pseudo-backup and access-everywhere all rolled into one. I’ve been using Box.net for a year now, with mostly good experiences. It’s got a well-designed dynamic interface, it makes sharing extremely easy and the service is very stable. I do have a few complaints though:
- The space you get is small. 5 GB for $5/month is not a lot. They have a bigger plan at 15 GB at $15/month (== $180/year), which hardly seems like a bargain.
- The interface looks great, but is sometimes a little tricky for complex file operations such as moving lots of files around. It’s got a great search function though.
- Most importantly: Uploading can sometimes be painful, requiring the use of either a popup applet or a built-in Flash tool. Navigating the file structure from these tools seems like it’s harder than it should be, with slow GUI response times.
Essentially, I’ve been wanting a file browser-like interface for uploading, with immediate folder navigation. Box.net has promised for a long time that they would release an uploading app that works outside the web browser, but has not delivered so far. I like their service and I’m not looking to switch, but I just wish it’d be easier to use…
To the rescue: Fire Uploader, a Firefox extension that supports FTP-style uploading to Box.net, Flickr, Picasa and YouTube. Browsing my Box.net account, creating a new folder and uploading a bunch of images was a snap. It supports downloading as well, but unfortunately not moving files.
It remains to be seen how stable Fire Uploader is in dealing with huge files and broken uploads, but so far it’s looking really good. Upcoming versions might add site-specific functions such as setting permissions, as well as new services to upload to. If it supported moving files it could almost be a complete Box.net GUI replacement.
For Flickr uploading, Fireflix is useful, but a little clunky. For FTP transfers, I like FireFTP, another great Firefox extension. It allowed me to finally do away with clunky FTP software, and do it all inside the browser. I love that that the browser becomes an environment for getting things done.
08:16 | July 9th, 2007 | marius watz | +del.icio.us | +digg | trackback
As mentioned previously, I’ve been working on developing a visual piece for a Nokia phone. After trying Mobile Processing, I came to the conclusion I’d be better off going the old school way: Pure J2ME development in Eclipse. It makes me appreciate just how easy developing in Processing really is compared to going back to the bare bones.
Seeing as my target is a Nokia phone, I figured using Nokia’s own Carbide.j tool for J2ME development. Now it looks like that was a mistake. Nokia has just announced that they’re discontinuing development of Carbide.j. Instead, they suggest two Open Source alternatives, Eclipse with the EclipseME plugin or NetBeans IDE with the NetBeans Mobility Pack.
I found out about the announcement while trying to repair my apparently broken install of Carbide.j, so I’ve now made the jump to EclipseME and dumped Carbide.j altogether. EclipseME feels much better integrated with the IDE, running a MIDLet in a given emulator is as easy as running a regular app. Carbide.j forced you to use a series of clumsy steps just to get the emulator up and running.
Right now everything’s running flawlessly except when I try to use Nokia’s S60 3rd Edition (FP 1) emulator. It barfs at the step of creating the JAR file for some reason. I guess I’ll just stick to Sun's WT5 2.5 emulator and forget about using any fancy Nokia-specific stuff like transparency. The upside is that my final app will theoretically run on any MIDP 2.0 phone.
Update: When trying to install my MIDP application generated with EclipseME on the Nokia phone I kept getting “Invalid JAR” errors. According to a post on eclipseme-users, this is due to EclipseME not including a vital piece of information in the JAD file. To fix it, simply open the generated JAD file with a text editor and add the following:
MIDlet-1: Classname,,packagename.Classname
“Classname” should be the name of your MIDlet class, “packagename” should be the name of the package it’s in. After I added this line to the JAD it installed just fine.
05:45 | July 6th, 2007 | marius watz | +del.icio.us | +digg | trackback
I’ve just learned some handy tricks about packaging Processing-based applications with OpenGL for deployment on Mac OS X. As it turns out, it’s remarkably easy to do on a PC if you use Processing’s own application export as a template. My thanks to Ben Fry for the tip (and also for all the other hard work he’s put into Processing…)
Create a sketch called “Dummy” in the Processing GUI. If your final application will use OpenGL, make sure that “Dummy” does as well. Export using “Export as application”. This produces several folders, of which only “application.macosx” is of interest. This has a “Dummy.app” subfolder which is the actual MacOS application. It’s not a single file, but rather a folder structure that on a Mac shows up as a clickable application. Change the name of “Dummy.app” to whatever name you want, keeping the magic “.app” extension.
In “Contents” you will find a file called “Info.plist”. This contains various parameters controlling your Java application, bundled as pairs of <key> and <string>. Make sure that “MainClass” string is the full name of your main class (including package name if any). Change all instances of “Dummy” to the name of your application. You can also tweak a bunch of other options at will.
If you have JAR files that you need to add, place them in the subfolder “Contents\Resources\Java”. It should already contain core.jar as well as the OpenGL-related JARs and jnilib libraries if you exported Dummy with OpenGL imported. You will need to include the new JARs in the “ClassPath” string found in “Info.plist”.
If all changes have been done correctly, you should now have a runnable application. Copy it to a Mac for testing.
For some icing on the cake (and as an alternative to present mode), you can hide the dock and menu bar on application start. Add the following lines to the <dict> section of “Info.plist”:
LSUIPresentationMode
4
Thanks to Vitaflo for his post on the Processing Forums for this tip.
If you compile your code including the Processing source in an IDE like Eclipse, you can simply replace core.jar with your own as long as it contains all the usual Processing class files. I've made a few small changes to the PApplet class, so I prefer this option to the standard JAR file.
This is particularly pertinent if you want your OpenGL apps to be anti-aliased on Mac OS, since smooth() does not always turn it on. The solution is to make an alteration to PGraphicsOpenGL using the GLCapabilities class. Read Mike Creighton's post on the Processing forums for the details.
21:03 | April 7th, 2007 | marius watz | +del.icio.us | +digg | trackback
I’m currently writing a monster application doing indexing of feeds from blogs, del.icio.us, Flickr, Digg etc. It’s been a bit of a learning curve, but using the excellent and comprehensive Rome library has made it a great deal easier than it might otherwise have been. Rome handles Atom feeds as well as the various confusing RSS variants.
Making sense of feeds is often tricky, as different publishers can use various tags in different ways, or even add their own by introducing custom namespaces. The use of namespaces (which Rome supports through a plugin system) is a promising way of adding custom information, but not without its problems.
Having completed indexing of Flickr, del.icio.us and plain vanilla feeds, I turned to Digg feeds. Imagine my surprise to find out that not only is their advertised namespace (http://digg.com/docs/diggrss/) in fact offline, but they don’t even use it properly in their main RSS feeds.
http://digg.com/rss/containerscience.xml correctly specifies xmlns:digg=”http://digg.com/docs/diggrss/”, but http://digg.com/rss/index.xml specifies xmlns:digg=”docs/diggrss/”. And that just happens to be their main RSS feed. I know it seems niggling to complain, but it messes with the Module I’ve written to handle their tags and seems a tad careless. Oh well, guess I’ll just skip that feed.
More information about Rome, Digg etc:
16:42 | November 4th, 2006 | marius watz | +del.icio.us | +digg | trackback
Creating PDFs in Processing and post-processing them in Adobe Illustrator, I frequently find myself wanting to do things like adjust global transparency levels, colors etc. So far that’s been frustrated by the rather poor color adjustment options built into Illustrator, but today I finally got impatient enough to look into a scripting solution.
Illustrator has had Javascript support since CS 1, exposing the document object model to anyone with a bit of scripting savvy. Adobe is good about publishing technical documents, perhaps a holdover from the days when they relied on PostScript to build their empire. So anyone can go to the online scripting documentation and download a complete PDF with a description of the Illustrator API.
As might be expected, coding Javascript is not without its troubles, and I found myself having dotcom flashbacks to the days when I would do client-side scripting. In particular, debugging is always been a pain with Javascript, especially when one is not intimate with the DOM and API. Fortunately, the ExtendScript Toolkit provided by Adobe functions both as a IDE and a debugger. Still, I find myself wanting a few nice details, like the possibility of displaying a progress bar when a script is executing.
To give you an idea of the oddities of coding for Illustrator, I am posting a script that allows the user to input a multiplier, which is then used to adjust the opacity of all path items in the active document. This covers for the lack of such a function in Illustrator proper. To be honest I was surprised at the speed with which I was able to accomplish my goal. I would seriously consider this as a way to do brute-force post-processing of vector files.
That said, I doubt it will ever be as fun and quirky as Scriptographer…
Source code – OpacityAdj.js
Read the rest of this entry »
21:15 | October 22nd, 2006 | marius watz | +del.icio.us | +digg | trackback
Adobe has released a public preview of ActionScript 3.0, which will be part of Flash 9. This follows the release of Flash Player 9, which will support AS3 features. At a glance this release seems to reinforce the evolution of Flash and ActionScript into a serious application development. Runtime types, non-dynamic classes and runtime exceptions brings AS3 in line with regular programming languages and hopefully simplifying the process of debugging Flash. In the past, grown programmers have been known to break down and cry at the thought of figuring out what is wrong with a complex Flash app. Perhaps now they will only sigh deeply.
The real reason for these changes is that run-time types and non-dynamic classes give a major performance boost. Flash Player 9 contains a new ActionScript virtual machine, the AVM2. This VM is expected to boost Flash performance up to 10-fold, to a point where the VM can run complex applications at reasonable speeds.
And guess what: Flash now has a revolutionary new primitive type: The “int”. The fact that this was missing in the first place is mind-boggling. My apologies if this sounds snide, but I remember wondering why Macromedia didn’t “professionalize” ActionScript over 4 years ago. Ok, so AS2 had OOP but it felt like a kludge and the willy-nilly handling of pointers made you cringe.
More good news: There are indications (see overview, search for “DisplayList”) that AS3 will ditch the MovieClip class in favor of more logical DisplayList and Shape classes, as well as doing away with the hopelessly outdated layer system for deciding depth of objects.
The recent developments are good, but my suspicion is that they will still fall short of making Flash a real application environment without relying on obscure tricks and guru knowledge. I understand the desire to keep Flash accessible to non-hardcore coders, but surely it would be possible to make the language scaleable without sacrificing consistency.
Don’t get me wrong, Flash is invaluable as a platform for rich media content that can actually be seen by the majority of Internet users. And this new version is inching towards a better Flash world. But if Adobe allows Flash to continue the “fix a kludge with a kludge” tradition that has always plagued Director, they’ll eventually have to scrap the whole platform and build something new from scratch. Let’s hope that doesn’t happen.
Links:
(Via Create Digital Motion)
12:09 | June 29th, 2006 | marius watz | +del.icio.us | +digg | trackback
Some exciting news about VVVV, the “multipurpose toolkit” from the best boys at Meso. They’ve launched a redesigned and much improved VVVV site, combining Wiki and blog functionality into one user-friendly setup. VVVV has never been the most well-documented tool and the previous site suffered slightly from geek tendencies, but this time they got it right. The documentation page should now have something even for those with no visual programming experience, and if not they can just head over to the Fan Club to look for answers.
And for anyone who is unaware of the powers of VVVV, have a look at David Dessen’s new blog, Sanch TV. David has been producing some amazing results using VVVV’s built-in support for vertex shaders. Shaders run directly on the GPU of your graphics card, and so get a major performance boost compared with CPU-based methods. That feature alone should be reason enough to start experimenting with the VVVV toolkit (Windows only.)
Note: I blogged David Dessen’s work in more detail over on Generator.x.
09:44 | June 26th, 2006 | marius watz | +del.icio.us | +digg | trackback
I just posted an entry about NodeBox over on Generator.x. NodeBox is a Python-based coding environment that specializes in producing vector graphics, with very high quality results. Like Processing’s use of Java, NodeBox uses a simplified syntax but has access to the full power of Python for advanced programmers. It also has some interesting libraries, like the Pixie handwriting library or the PhotoBot image processing library.
Unfortunately, NodeBox is only for Mac OS, but the source is available under a MIT license. It looks like a fun alternative to Processing with a slightly different bias on what kind of work it is useful for. Have a look at the Gallery for some examples.
12:19 | June 6th, 2006 | marius watz | +del.icio.us | +digg | trackback
Today is the last day of the workshop. Zach spoke about the role of the question mark in art. Don’t just ask “how”, but also “why”. I spoke about code-related blog resources, and presented VVVV and visual programming as an alternative to text-based programming environments.
VVVV is a tool created by the German media design group Meso, and is an excellent tool for VJ’ing and other visually oriented tasks. Because it is a patching system, it lends itself to spontaneous hacking, and even live coding (see Toplap).
Finally we had demos of what people have been working on over the course of the workshop. Some very nice projects were presented, hopefully we will be able to publish some results of the workshop online.
16:30 | May 12th, 2006 | marius watz | +del.icio.us | +digg | trackback
