SuperSatellite ||

Finally back and settled in after returning from training in Miami. Now just very busy trying to catch up, and put some of the things that I learned to use. I did manage to grab some photos around the area on CocoWalk where I was, so feel free to browse the Flickr set. I also started playing around with geotagging the photos. I have no idea how useful that will be in the future, but what the heck? I wish that I’d had more time to get out and about, but I did hit two excellent sushi places, instantly reminding me that what I pass off as sushi here is nothing but a sick and twisted joke by comparison.

First, how come no one told me that some Chinese company was making new MGs? I saw one at the condo where I was put up at. It wasn’t anything fancy as far as sport convertibles go, but it was still pretty neat in its own way. Now I want to drive one and see what they feel like.

Nearby was CocoWalk, which is where the dotMarketing headquarters are and where I spent a lot of my time. It was Cinco de Mayo the night I arrived, so it was a pretty popular site, with the shops and restaurants (though I made the mistake of passing up Hooters.  I’m not sure what I was thinking to make that mistake). However, I did take a couple hours the night I got there and saw Iron Man. Let me just say, I was absolutely not disappointed. Go see it.

On the travel side, I think I will make the effort to never fly US Airways again. Worst planes and service I’ve ever dealt with. Tiny pretzels, mean spirited, inattentive stewardesses, terribly seats, and small planes. And to top it off, I appear to be getting increasingly worse anxiety while driving long distances by myself. My nerves light up high enough on the drive to KC and back that it very nearly makes me sick. I’m not sure what to do about this yet, but it is very unsettling. Obviously drugs would probably impair my ability to drive, and if I had someone drive me, it would cost a fortune. I think I’m going to try to start flying out of Tulsa, which is a tiny bit closer, or even Joplin, assuming I can find well timed hoppers.

As for dotCMS, I feel much better equipped than I have in the past after opening my skull and letting their lead developer pour knowledge into it for a full day. I anticipate having no problems setting up my development environment soon, and upgrades from here on out should be much, much easier. I also understand better how the parts come together, and what they do when the break. I also agreed to devote some time to helping with their community site doing some writing or theme crafting. That will be a fun side project I think.

I know some people have had questions about setting up dotCMS to run in an Eclipse development environment. If you were like me, you might have been having problems because you were reading the wrong setup documentation. Turns out there is a new one that was misfiled that is much better and up to date. Also, if you are running a dotCMS site on MSSQL, don’t run ant buildsql when you update. It breaks things, because it’s meant for the Oracle and Postgres camps. You’ll want to use ant buildmXsql.  Learn from my mistakes, heh.

If you have been following my tweets lately, you might have noticed that I’ve been fighting over which service I would prefer to use: Flickr or Picasa. This has resulted in far more headache than I would have initially thought, and I still don’t feel any closer to coming up with an answer. I thought by sharing my opinions, maybe you could toss some feedback my way that might help the decision making process. You may also ridicule and taunt me, as it pleases you.

I am not a photographer. I enjoy taking pictures, and I believe that I take relatively good ones, given my amateurish state. But I admit that it’s just a small hobby. Until now, I have used a Coppermine powered gallery that I kept on my personal server for managing and sharing my pictures. This works relatively well. To be perfectly honest, the only real reason I even care to switch is because I’d like to connect to more social tools through my photos. My own hidden little gallery site doesn’t do that. I also don’t have a lot of interest in keeping the software maintained, so I end up with older software that is a pain in the butt to update. But, I’m also not looking for 100,000 people to drool over my pictures. Mostly it’ll be stuff from plays I work on, or trips I take, things none of you care about (even though you try to act interested).

And here’s the matchup. Flickr is clearly a more socially driven web site. It’s purpose is more closely linked with my goal, I think. But, they lack a good desktop app for organizing pictures like Picasa does. They have an uploader application, which seems to work well enough, but I’d like my offline archive to basically mirror what I have online (at the moment, my photos folder is a pretty big mess, I admit it). Flickr is also pretty crippled if you don’t spend $24.95 a year on a pro account. Without it, you only get to use three sets (albums), which is, frankly, useless to me. You also only get to upload 100MB of photos a month, which if you are trying to migrate to their service, is also pretty useless. I said I’m not a photographer, but I still have a solid 2GB+ of photo (not that I need to share them all, but if I can, I probably will share most). However, with pro, you get unlimited everything for the most part. Storage, bandwidth, sets, collections, even video (if you care. I don’t).

Picasa has a slightly different purpose. It is geared more towards what Coppermine did for me; simply provide online gallery/album functionality. It’s desktop app is nice for organizing offline, and it integrates right into web albums. You get unlimited albums out of the gates, and a full gig of storage with no upload limits per month. But, extra storage (10GB) starts at $20/yr. Cheaper than Flickr Pro, but Flickr Pro gives you unlimited storage for five bucks more. Alternatively, you can do more for free through Picasa, just at a loss to some of the social networking features Flickr has. If you need more than 10GB, the price starts hurting.

My problem is basically that I can’t easily decide what kind of user I am, or what my goal is. I fall right in the middle of one big gray area, like Nick-at-Nite TVLand poop. Ideally, the systems should just merge into one super warehouse, like my crappy Photoshopped graphic above intimates. $25 a year isn’t much, but a lot of what I’d pay for I could have through Picasa for free. And using Flickr leaves me stuck managing stuff offline through something else. I could use Picasa as a purely offline file manager, but that’s like using it and wasting half the purpose of it. Half a dozen of one, six of another. I sure as hell don’t want to do both, I’d like one solution that answers my needs.

You could solve this problem for me, of course. Just sponsor a Flickr Pro account for me, and that will make up my mind for me. It’s not that I’m cheap, it’s just that I’m cheap.

Update: I almost forgot to mention; Brad Ward has a nice blog writeup on Flickr over at SquaredPeg on Flickr, and using it to manage your photos.  I read it the other day and it was really what got me thinking that Flickr might be the way to go.

By now, you might have heard of the new Adobe Integrated Runtime, otherwise known as AIR. AIR is aimed at allowing developers to create rich internet applications that are capable of running on a user’s desktop, regardless of operating system. Think Java, but geared more towards self contained web applications. It also results in comparatively superior looking applications. I mean come on, anyone else think Java is generally ugly?

The Adobe® AIR™ runtime enables you to have your favorite web applications with you all the time. Since applications built for Adobe AIR run on your desktop computer without a web browser, they provide all the convenience of a desktop application. Companies like eBay and AOL are using Adobe AIR to create exciting new applications that allow you to use their services on your desktop. In short, Adobe AIR means applications that are easier, more powerful, and more fun to use.

With AIR, you can slap some XHTML and Flash together, and create an application on it that can run independent of a browser. It’s finding wide adoption among crowds like Twitter users. Groups that are looking for applications to plug into a web site’s API (Application Program Interface). Check out Twhirl for an example, it’s what I use to keep up on Twitter. So, this is all super neat, right? Applications install with little more than a couple clicks, and can auto-update themselves to boot. Nice in Windows, but this could be invaluable in the Linux world. Can you guess why?

I run Ubuntu 8.04b on my laptop (I love installing 20 updates every day!). My desktop dual boots XP/Ubuntu (it swings both ways). I’m slowly transitioning to the geek side. But, I fall far short of calling myself a Linux guru (you may still refer to me as Sir, though). I can do anything in Windows, but in Linux…well…I’m like a sixteen year old boy on prom night. Actually, I’m getting much better than that, but for years the largest barrier to entry for me has been installing software. It has gotten easier with RPM’s, apt-get, and Ubuntu’s Add/Remove Applications interface, but if something isn’t listed you might find yourself jumping through a number of hurdles to get things going. And let’s be honest, how many “average” users could master the art of ./configure, make, and make install? Easy for a geek, hard for Grandma Jane (don’t hit me grandma!).

That’s where this whole AIR thing caught my attention. Turns out, Adobe has got an alpha version of AIR for Linux released. Keep in mind, it’s only for testing and not fully functional (like your mom), though I’ve only noticed a little graphical quirkiness so far. First off, the install is fairly painless (though must be done through the command line):

user@system:~$ wget http://download.macromedia.com/pub/labs/air/linux/adobeair_linux_a1_033108.bin
user@system:~$ chmod +x adobeair_linux_a1_033108.bin
user@system:~$ sudo ./adobeair_linux_a1_033108.bin

The installer pretty much does it’s own thing. From there, you can now find and open up an .air file for an application that you want to try out. Sizlopedia has got a nice list of 10 good AIR applications that you can start with. That’s where the whole gap bridging takes place. It’s almost like running your basic install.exe file. The browser will ask if you want to open it with Adobe’s handler (hint: you do), and it runs and installs like a Window’s app would for the most part. Painless. Simple. Easy (hint: also like your mom). And what makes it more perfect is that the process doesn’t differ between using Windows or Linux, so if you’re transitioning, it’d be completely familiar to you.

Which is why I ask the question: could this be part of the key to really mainstreaming Linux? It has always been my opinion that application installation has been the single largest barrier to entry Linux has faced in the general market. If this concept could be passed along to general application installation (like an RPM, only better), I think things would change rapidly. Naturally, that’s just my opinion. But it does make the OS and AIR based applications immediately useful, without any guessing, and that’s really what the install.exe-bred users need to smooth a transition to a new and foreign OS.

Today was a day of days for dotCMS and me. A couple weeks ago I started working on integrating a servlet into dotCMS to handle PHP code. This in part to learn if I could, and also because I know PHP way better than Java. It would also help to keep me from needing to rewrite chunks of code that I might want to keep using or from having to maintain a second server and connect it to Tomcat using mod_jk for the purpose of running PHP. Ideally, I wanted it all wrapped up in one, nice package.

Enter the Tomcat Wiki. That’s where I started out at, specifically this entry about using PHP. It definitely got me started. The only thing that was sorta sucky was that the method did not work with PHP5+. Only PHP4. But I figured I could live with that. Better than nothing, right? After spending two days hammering away at it, I gave up. I was able to eventually get rid of all the errors, but the end result was a big goose egg on code execution. I also wasn’t sure if it’d even work with the 4.4.8 codebase I grabbed from PHP. All around, I just decided this wasn’t a worthwhile course to follow.

Enter IRC, JT, and Quercus two weeks later. Jason got to talking with Chris and I about it yesterday in the IRC channel (#dotcms on Freenode), and pointed out Quercus. Quercus is a PHP servlet designed by Caucho for their Resin Java application server. Released under the GPL, no less. Unfortunately, at this time, their site sucks, the mailing list bounces, and the forums error out when trying to make a new account. So, I started sniffing around. Rob Sinner’s blog turned out to be a great starting place, and has the bulk of the information you will need. Quercus was also picked up and integrated into the Liferay project, which was where dotCMS started. I figured if they got it working, there’s no reason I shouldn’t be able to.

Here’s how it went down. Go get the current .war file from Caucho (3.1.5 as of right now). Extract it using 7-Zip, or some equally useful unzipping program. First off, copy the three .jar file (quercus.jar, script-10.jar, and resin-util.jar) into /common/lib or /common/lib/ext in your dotCMS root directory. Then, go into /liferay/WEB-INF (dotcms/WEB-INF in version 1.6 and up) and open the web.xml file. Add to it:

That sets up the servlet to handle files that it is told to handle that end in .php. There is a sample web.xml folder in the files you extracted from the .war file that has other stuff like datasource and php.ini designations if you want to connect to a database or use custom PHP settings.

Now, shutdown the dotCMS server if you haven’t already. Do an ant clean and ant deploy. Copy a test php file (I used a basic HTML page with <?php phpinfo(); ?> in it) into /liferay/html on the server’s file structure, and start the server back up. Now, you should be able to open the page http://www.yourdomain.com/html/test.php and see the result page above. dotCMS is set to refer to the real file structure when it sees the folder /html in a URI (Uniform Resource Identifier), rather than its internal virtual file structure.

The kicker that fouled us up originally is that you can’t execute PHP pages from within the dotCMS file structure, since it is a virtual file structure and all the files actually exist in /liferay/assets rather than where they appear in dotCMS’s file browser. If you upload a PHP file to a directory in the back end, it will just come out as a 404, because when the Quercus Servlet tries to call the file by dotCMS’s file structure, it can’t find it’s equivalent in the real server file structure. Get it?

The solution is to this is more complicated than simply making it so there’s a way to run PHP code, and I’m working on it with some help and might get it in to 1.6 if we get it figured out fast enough. We’re trying to modify the CMSFilter.java file and extending the QuercusServlet.java file with code from the SpeedyAssetServlet.java file to make it so that when a PHP file within the dotCMS file structure is dropped to the Quercus servlet, it has the ability to ask dotCMS where in the assets folder it is to execute it. In the mean time, the PHP works with the above solution so long as you store the file in the right place.

Following up the completion of one of our first successful forays into using dotCMS on campus, I thought it would be time to discuss what we did and how we did it, to give you an idea of what is possible within the platform. I mentioned in past articles that dotCMS is a powerful CMS (Content Management System) framework, you just have to assemble the pieces. Think of templates, structures, containers, and content like Lego blocks. You can have tons of them, different shapes and sizes, and depending on how you assemble them, you can control what the end result is.  This is exactly how you build more complex displays in the system.

That was the case with the Gorilla Geeks’ newsletter (alternate here). This was the first advanced usage we tackled, and we did so as part of a proof of concept to show others what we’d be able to do in the new CMS to help sell it around campus. It was created to provide a web page based newsletter that would have a URI (Uniform Resource Identifier) emailed out to people when new issues were made available (based on the schedule they settle on). Note that this was not a newsletter that was embedded in an email, and we didn’t use any of dotCMS’s CRM capabilities. The email just told people to visit the page. It is very similar to a blog, in that it has articles and categories. The main difference is how we display the articles and navigate.

Step one was to plot out how to arrange the content. I needed a way to refer to articles individually, or in groups by newsletter, or groups by category. That was clearly a relationship issue for the former, and category issue for the latter. I needed two content structures to do this. One was the “Blog/news item” structure. This already existed in the system and works well as a generic post-type content handler (title, body, image, tags). The second structure was one I created called “Newsletter.” This was a very basic structure that contained a publish date and an issue number. I then created a one to many relationship between newsletters and news items. What this means is that one newsletter could be related to many news items (Newsletter 1 could have 12 articles under it, Newsletter 2 could have 8). First you go in a make a newsletter, giving it an issue number. Then you create a news item, and on the relationships tab tell it that it’s parent is the newsletter that you just created. That solved the basic content question for the project.

Next I started looking at templates and functionality to actually make the display presentation work. The template provides all the basic display information up until articles show up; that includes the headline and sections region. Initially, the template checks to see if an article or issue number is passed in the URI and uses that to see if it needs to call a specific newsletter or if it should call the newest one. It also looks to see if the user has requested a printable version and will serve a custom CSS (Cascading Style Sheets) for that. As for the newsletter call, it starts with:

This is just checking to see if the $displayIssue variable was set (which happens on page load using $request.getParameter()), which indicates a preference for a specific issue. If not, it calls the current newsletter issue, and sets $displayIssue to that. All of this leads into the relationship needed to pull in the issue’s headlines, and the newsletter body, if needed. Once the page enters the body, we move to a container for generic web content. There, a widget is loaded that builds out the article(s) based on the request:

Basically, it figures out which of three Lucene queries to execute, and runs a loop to display them.  This allows one page to serve as the display mechanism for three different views: newsletter, category, single post.  Think of it kind of like how The Loop works in Wordpress.  I could just as easily kick them into another page for different views if I wanted, but that’s the benefit of widgets, which are cleverly crafted content items allowing dynamic content display somewhere that normally would require one piece of static content.

This ended up being a fairly simple setup: one relationship, one template, and one widget does this newsletter make.  With it, they get newsletter functionality, RSS, print versions, categorizing, search (via our Google Mini), and nice archiving.  The biggest catch is just making sure to tell a news item which newsletter it needs to relate to.  From here, I’d like to refine the theme and improve the usability some, but none of that changes the basic setup.  I’ll be happy to share more of the code with anyone if you like.