I just took delivery of my latest new computer from my employer.  This time, instead of another run of the mill IBM compatible laptop or desktop it was a fancy new 17" MacBook Pro.  We're developing software which we're supporting in Safari using the Silverlight plugin and I needed to be able to develop and test in that native environment.

First, let me give you some background.  See, I'm an Apple geek from days of yore.  We're talking Mac II and Quadra days here.  I was raised around Apples because my father owned his own business in the desktop publishing industry.  Around 1996 or so, I started to defect to "the dark side" and use the Windows OS, and only a few short years later I started dabbling with Linux, which is my current OS of choice.

Now, I knew that OSX was BSD based, and I knew I'd like it.  I also knew that the Apple hardware was pretty stinkin' elegant.  But man…. I had no idea.  This feels all so new and exciting, but at the same time comfortable and familiar.  In the ~3hrs I've had it I've installed pretty much an entire Groovy/Grails development tool set as well as installing and configuring things I'll be using on a daily basis.

I'm discovering some things which require are requiring a bit of research, but once I find the answer it usually fits some pattern or concept that is very familiar.  I'll likely be blogging about a few of those items as I continue to "move in" to my new machine.

I've also been firing off my thoughts as I have them on Twitter, you can follow the stream below if you're interested.

[wpts terms=#mbpfirstimpressions limit=20 lang=en]

This is the second installment of my What Grooves You? series of posts, this time discussing how to modularize your Grails application. While Grails does an awesome job of enforcing MVC once your application reaches a certain size, or you have multiple applications which may have shared components, you’re going to have to start thinking about how your going to modularize the reusable parts of your code.

I encountered this pretty quickly because the application I am working on is broken out into two distinct parts, a public facing web form for submitting data (the “Front End”) and a private back office application for managing those user submissions (the “Back End”). These two parts of the application (for compliance reasons) cannot run on the same internet facing system, and the “Back End” must only be available on the internal network. Of course, both of these applications are going to work with the same database and therefore the same Domain classes. It would be dangerous and tedious to try to keep the separate domain classes in each project synchronized with one another.

What won’t work

The RESTful JSON Service

My first thought was to deploy a 3rd application which would be internet visible and act as a proxy for all the database requests. I could then query that application with REST and handle a JSON payload which would be my domain object. This actually seemed pretty elegant since I wouldn’t have to actually share any code between the Front End and Back End applications and I still got a well defined object on either end. The problem of course is that all I get is the data for my domain class, and I don’t have access to any of the functionality that GORM gives me “for free”. I’d have to duplicate search functionality, limits, grouping, sorting, and all sorts of other querying tools in my service. That seemed like an awful lot of work for functionality that is offered by GORM and works very well!

Just JAR it man

The next obvious conclusion is to just toss my domain classes into a library JAR file and reference that library in both of my other applications. This way I actually have the whole domain class and access to the dynamic find methods and all that other good stuff. But, how do you package these? Do you compile the Groovy classes then package the .class files? Will the data source information have to be set for the domain class(es) in the JAR, or will the data source of the application referencing the library be used?

Now some more seasoned Java and Hibernate developers might simply laugh at that barrage of questions, but for me it presented a serious barrier to entry. Fortunately there is a better way.

Just plug it in!

It didn’t take me long to discover that putting my reusable code into a Grails Plugin was the best and most scalable approach. For the sake of demonstration I’m going to take you through an example comment submission and administration application, kinda like blog comments.

The plugin project

First, let’s go ahead and create our plugin project.

[bash]grails create-plugin Modular-DAL[/bash]

Once you’ve got your shiny new plugin created, open it up with your favorite IDE (I use Spring Source Tool Suite) and add a new domain class that you’re going to be sharing.

[bash]grails create-domain-class com.nslms.modular.domain.Comment[/bash]

Now we specify some properties for our new shared domain class.

Comment.groovy

[groovy]
package com.nslms.modular.domain

class Comment {

static constraints = {
name(blank:false)
email(blank:false)
comment(blank:false)
}

String name
String email
String website
String comment

Boolean isApproved = false
}
[/groovy]

With our new shared domain class created, we want to package up our plugin so we can load it into the other projects which we’ll be creating in a moment.

[bash]grails package-plugin[/bash]

That’s it, you’ve just created a (very small) module of your application which contains a shared domain class. This could, of course, contain any number of domain classes, controllers, or services, views, javascript, css, etc. that would be used by other parts of your application, or by other applications.

The Front End

Now, lets create an application which will serve as the “front end” or externally facing form for collecting data.

[bash]grails create-app Modular-FrontEnd[/bash]

Then the very important part of installing the plugin we just created

[bash]grails install-plugin ../Modular-DAL/grails-modular-dal-0.1.zip[/bash]

Because you can download the project I created, I’m not going to go into excruciating detail about the controller and view(s) I setup in my front end, but sufficed to say I am accessing the “Comment” domain class that is supplied by the Modular-DAL plugin project!

CommentsController.groovy (snippet)

[groovy highlight="1,5"]
import com.nslms.modular.domain.*

class CommentsController {

def index = { [comments: Comment.findAllByisApproved(true)] }
}
[/groovy]

The result of the front end app should be a list of comments which are approved (by the backend) and a submission form to allow you to submit new comments. Kinda like this.

The Back End

Now we need to create the system which will allow you as the administrator to approve the comments submitted by the unwashed masses.

[bash]grails create-app Modular-BackEnd[/bash]

And install the plugin with the shared domain class.

[bash]grails install-plugin ../Modular-DAL/grails-modular-dal-0.1.zip[/bash]

Again because you can download the project I created, here’s just a snippet of the admin controller showing the juicy bits where we use the shared domain class

AdminController.groovy (snippet)

[groovy highlight="1,5"]
import com.nslms.modular.domain.*;

class AdminController {

def comments = { [comments: Comment.findAllByisApproved(false)] }
}
[/groovy]

The back end app should have a list of all unapproved comments, and a method to approve them. Kinda like this.

Trying it out

Now if you’ve followed along and created your own controllers and views, or downloaded my basic project, you’re going to want to try running both the front end and back end at the same time, persisting data to a common datasource so that you can see the whole thing in action. If you just use the grails run-app command, you’ll find very quickly that you can only run one or the other project, but not both at the same time. This is because they’ll both be trying to run on the common Tomcat port (8080). To overcome this, and run both apps at the same time, try the following starting from the Modular-FrontEnd directory.

[bash]
grails -Dserver.port=8081 run-app
cd ../Modular-BackEnd
grails -Dserver.port=8082 run-app
[/bash]

Now you should be able to access both applications at http://localhost:8081/FrontEnd and http://localhost:8082/BackEnd respectively.

Download The Project(s)

If you want to download the project(s) and follow along, fire up your favorite subversion client and export everything at svn://linode.nslms.com/blog/grails/Modular or download it here. A couple things to note if you’re grabbing my project, it’s currently setup to use a MySQL database named “modular” running on the same system as the application. If you don’t already have MySQL setup, give XAMPP a look to get you started quickly. Also, I didn’t include the JDBC driver, go fetch it here and drop it into the “lib” directory of both the FrontEnd and BackEnd applications. Lastly, these projects are all written with Grails 1.2.1 so you’ll have to be using 1.2.1 or newer.

* UPDATE: The example apps have a new home..

Grab the projects at

[bash]
git clone git://ec2.nslms.com/grails/blog_example_modular
[/bash]

This is my first installment in the What Grooves You? series of posts, and it deals with the first thing you’re going to need to consider if you are deploying your Grails/Groovy applications in the average corporate IT infrastructure, Single Sign On with Active Directory and NTLM. Like it or not, because all of our existing applications are based on Microsoft technologies our users have gotten used to just going to the URL for the application they intend to use and being instantly recognized and authenticated. Forcing them to sign in again, or worse still forcing them to setup a new username and password for your system would be completely unacceptable! Below, I’ll take you through the steps I took to solve this problem, including the detours that cost me time!

Throughout this post I’ll be referring to domain objects, controllers, and views which would have been created by running the Acegi LDAP tutorial. So if you want to follow along, go walk through the tutorial, then come back here to see how we tweak it. Be sure to take the “optional” step of creating the views and controllers for the auth domains, you’ll need it not only in the tutorial, but also for some customization we’ll be doing later.

[bash]grails generate-manager[/bash]

You can also download a copy of the Spring Source STS project I used for this application here.

LDAP Single Identity but not Single Sign On

As I started searching to figure out how to authenticate my users, everything seemed to point to using the Acegi Plugin for Grails, and using it with LDAP, tweaked to talk to Active Directory. So, I started down this path and followed the LDAP tutorial for the Acegi plugin. Without a lot of trouble I got this working by following the steps in the tutorial, though I did make a couple significant changes to the SecurityConfig.groovy file to make it play nice with Active Directory

SecurityConfig.groovy

[groovy highlight="14,17,18"]
security {

// see DefaultSecurityConfig.groovy for all settable/overridable properties

active = true

useLdap = false
ldapRetrieveDatabaseRoles = false
ldapRetrieveGroupRoles = true
ldapServer = ‘ldap://<your-domain-controller>’
ldapManagerDn = ‘<your-service-account-dn>’
ldapManagerPassword = ‘<your-service-account-password>’
ldapSearchBase = ‘OU=People,DC=yourdomain,DC=com’
ldapSearchFilter = ‘(sAMAccountName={0})’
ldapSearchSubtree = true
ldapGroupSearchBase = ‘CN=Users,DC=yourdomain,DC=com’
ldapGroupSearchFilter = ‘member={0}’
ldapUsePassword = false

loginUserDomainClass = "User"
authorityDomainClass = "Role"
requestMapClass = "Requestmap"
}
[/groovy]

By setting ldapSearchFilter to ‘(sAMAccountName={0})’, we’re telling the Acegi plugin to look for the field in Active Directory that stores the username, this means that users can login just like they’re used to by using their Active Directory user name and password.

The ldapGroupSearchBase and ldapGroupSearchFilter are set such that any domain user groups that a user is a member of become Acegi “Roles” which can be used to determine if a user has authority to do stuff in the application.

Setting ldapUsePassword to false is important too. What we’re telling the Acegi plugin is not to extract the users password from Active Directory. If you don’t set this to false, you’ll get a lovely exception which isn’t particularly useful, java.lang.IllegalArgumentException: Cannot pass null or empty values to constructor. What this is trying to tell you is that the users password is null, which is correct since the default setting for the Acegi plugin is to try to extract the users password from Active Directory, and we haven’t told Acegi what attribute Active Directory stores the password in. By setting ldapUsePassword to false, the plugin provides a bogus password for the user details, and we’re able to proceed without incident.

So, great! If you’ve made these changes and followed the steps in the tutorial to add a user to the application domain with the same username as your Active Directory user you can authenticate users with the username and password they’re already using to login to their computer, we have a single identity for this person. But remember, our users are used to simply going to a URL and not being prompted to login. How do we reproduce that experience?

NTLM Really Single Sign On

Having realized that using Active Directory/LDAP authentication works, but isn’t an actual single sign on solution I started looking into the other settings in the SecurityConfig.groovy file. Turns out there is an NTLM option, but no corresponding tutorial! Here’s my configuration for using NTLM.

SecurityConfig.groovy

[groovy]
security {

// see DefaultSecurityConfig.groovy for all settable/overridable properties

active = true

useNtlm = true
ntlm.stripDomain = false
ntlm.defaultDomain = "yourdomain.com"
ntlm.netbiosWINS = "<your-domain-controller-ip>"

loginUserDomainClass = "User"
authorityDomainClass = "Role"
requestMapClass = "Requestmap"
}
[/groovy]

Nothing really outstanding here, I chose to set ntlm.stripDomain to false, so that the users name is not prefixed by the domain, I.E. DOMAIN\username. Also ntlm.defaultDomain and ntlm.netbiosWINS are both required, and I found that the ntlm.netbiosWINS works better if you actually give it the IP address of your domain controller, rather than the DNS name.

With NTLM configured, our Grails app now accepts the users cached authentication from their windows session. True single sign on!

Securing the Security Controllers and BootStrapping

Now we’ve got an application which will use NTLM to authenticate the user, we restrict access using the requestmap, and we add users and their roles using the user and role controllers. The problem, of course is that if you deploy this application anyone can go right to http://yourdomain.com/sso-app/user and add themselves as a user with any roles they see fit! So we need to make sure that our security controllers are secured, and that there is an authorized user that can get in to add users and roles.

Securing the Security Controllers

The first thing we’re going to want to do is secure our authentication controllers. My preference is to do this with annotations on the controllers, so lets secure the UserController and RoleController with annotations. Shown below we annotate them to show that the “ROLE_USER_ADMINISTRATOR” role is necessary to access any of the pages for either controller.

UserController.groovy

[groovy highlight="1,3"]
import org.codehaus.groovy.grails.plugins.springsecurity.Secured;

@Secured(["ROLE_USER_ADMINISTRATOR"])
/**
* User controller.
*/
class UserController {
/* Snip */
}
[/groovy]

RoleController.groovy

[groovy highlight="1,3"]
import org.codehaus.groovy.grails.plugins.springsecurity.Secured;

@Secured(["ROLE_USER_ADMINISTRATOR"])
/**
* Authority Controller.
*/
class RoleController {
/* Snip */
}
[/groovy]

Enabling the @Secured annotation

Now if you were simply to run the application like this, you’d find that you can still freely navigate to /user and /role without having to be authenticated, that’s because we are still configured to use the Requestmap to restrict access to specific parts of our application. To configure this for use with annotations instead, we only need to make a couple of small changes to the SecurityConfig.groovy file.

SecurityConfig.groovy

[groovy highlight="14,16,17"]
security {

// see DefaultSecurityConfig.groovy for all settable/overridable properties

active = true

useNtlm = true
ntlm.stripDomain = false
ntlm.defaultDomain = "yourdomain.com"
ntlm.netbiosWINS = "<your-domain-controller-ip>"

loginUserDomainClass = "User"
authorityDomainClass = "Role"
//requestMapClass = "Requestmap"

userRequestMapDomainClass = false
useControllerAnnotations = true
}
[/groovy]

Setting useControllerAnnotations to true gives the @Secured annotations on the user and role controllers meaning. By setting userRequestMapDomainClass to false we tell the Acegi security plugin to not even query for restrictions in the database, but to use only the static configuration defined by the annotations. We also delete the requestMapClass line. I commented it here instead of deleting it so it can be highlighted as a change in the file, but we’re not quite done with the requestmap yet. Now that we’ve configured our application not to use the request map we can delete the controller, domain, and views for it. Go ahead and delete the following files.

• /grails-app/controller/RequestmapController.groovy
• /grails-app/domain/Requestmap.groovy
• /grails-app/views/requestmap/*

BootStrapping

Now that we have our app secured, and we’re using annotations to restrict access we need to make sure that some user can successfully login after we first deploy our application. Otherwise no one will be able to access the pages to add new users! So we use boot strapping to add a user administrator who can add more users and roles for the application.

BootStrap.groovy

[groovy]
class BootStrap {
def authenticateService

def init = { servletContext ->
def role = new Role(authority: ‘ROLE_USER_ADMINISTRATOR’, description:’User Administrator’)
role.save()
def user = new User(username: ‘admin’,
userRealName: ‘Administrator’,
passwd: authenticateService.encodePassword(‘foobar’),
enabled: true,
description: ”,
email: ”,
emailShow: false)
user.addToAuthorities(role)
user.save()
}
def destroy = {
}
}
[/groovy]

So there you have it, an application which allows users to connect using their cached authentication using NTLM, uses annotations to secure your controllers, and actually allows access to at least one user once it’s deployed. Now, there are still some weaknesses. Particularly the level of permissions you can assign is limited to roles, I.E. “Administrator”, “User”, “Reporting User”, “User Administrator”, etc. Also in a corporate environment, having to go through this configuration for every grails app, and adding users and assigning their roles for each app can be tedious. I’ll be looking into improving these things with Acegi ACL’s and possibly using a centralized database for users and roles in future articles so stay tuned!

In my "Day Job", we design and build our applications using Microsoft technologies. In particular, we’re using C#, Silverlight, and IIS to build and deploy our web applications. This makes good sense because the vendors we use are well versed in the Microsoft technology, and like the IT infrastructure of a lot of medium and large companies Microsoft solutions are at the forefront. It’s becoming apparent though that we’re going to have to consider our options and possibly embrace a different technology stack to properly scale and support the applications we’re building.

While I knew that Java servlets and the Spring Framework were the answers, credit goes to my boss Scott Ellis for really doing a deep dive into what technologies are on offer, and coming up with using Grails and Groovy as the best solution for us. Which brings me to the reason for this blog post. I’ve been spending some time playing around with Grails and Groovy, and familiarizing myself with the technology and what is on offer. I intend to do a series of posts here about my discovery process, what problems I encounter, and how I resolve them.

From the searching I’ve had to do in order to get answers or better understanding about the challenges I’ve faced, I think I have a chance to be a real resource to others who are just starting out with Grails and Groovy. What’s more I’m writing from the perspective of a relative newbie to the Java world. Stay tuned as you follow my journey into Grails and Groovy. *Spoiler alert* – I like it, a LOT!

I am something of a Google Zealot, I was using the search engine back before many people knew what it was and haven’t strayed since. I’ve been using GMail for the better part of two years, and it handles ALL of my incoming mail, I even forward all of the emails from my self hosted domains to it. I use Google Docs for everything, including writing and storing invoices for my consulting work and any of my other “office” needs. And I use Google Voice daily for business phone calls. We used Google Maps to find and track rental homes, and it helped us find the place we’re living in now. Google Analytics keeps a finger on the pulse of the (itty bitty) traffic on this site. Google Reader is my RSS reader of choice, which I use almost strictly through a gadget on my iGoogle homepage along with tgadget for Twitter. I sync my iPhone with Google Calendar, and wouldn’t know what I’m doing any particular day without it. You get the idea.

So you can imagine that when I heard about Google Wave, I instantly signed up to receive an early invite. And as you can probably also imagine, I was super disappointed when the first set of invites went out to the public, and I didn’t get mine! I watched as many of the people I follow on Twitter announced that they’d received their invite, and were happily getting started with Google Wave. Of course, many of them were reporting serious usability issues and disappointments but I was never-the-less anxious to get my peek at it. After a few short weeks I managed to trade a Google Voice invite for a Google Wave invite.

Now getting the wave invite was… Interesting.. Evidently when a user is granted some discretionary invitations they aren’t sent out immediately when used. Instead a user “nominates” a person to receive a Google Wave account. Apparently there is some waiting involved, and I suspect some manual human intervention on the part of Google in order to actually send the concrete invitation. After waiting four days (two of which were the weekend) I actually received the email that my invitation had arrived!

My initial interaction with Wave was reasonably short. I watched a couple of the introduction videos, make a few setting changes to my profile, added a couple of people who I knew were on Wave, and logged out. My first real Wave was from an acquaintance of mine from Twitter who had also recently gotten Wave. We both admitted that we were excited to have the new tool, but really had very little idea of what it was really intended for!

After having a couple interactions with a few others later that day, I started to get a feel for the interface and the power of the tool. See, I’m currently working on a software project which is reasonably large in scope. The nature of the company I work for means that we didn’t have the time, money, or expertise to hire a big enough development team to accomplish the software solution we’re trying to build. So, we’re managing with myself as the lead architect, a business analyst who knows what this thing is supposed to do, and a project manager on our side. Then we’re having all of the development work done by an offshore team.

Very quickly it struck me that Wave lends itself VERY well to this sort of thing, and in fact I think real-time collaboration for creative/design purposes is exactly what this tool is designed for. In many of the sessions of collaboration that we’ve had over the phone, having a parallel wave would be invaluable! Imagine an integration with Google Docs, I can create a wordpressing doc, a presentation, or a spreadsheet and simply attach it to the wave. Or I can take a screenshot and toss it in there where it is appropriate. Everyone has visibility to the results. This thing is DESIGNED for agile, if you ask me.

That said, this is still a very early version. In all of the “buzz” about Wave it was claimed that it will contact you in any way that is appropriate. If you’re at your computer, and logged into Wave, you’d get the real-time view. Not logged in? That’s okay we’ll nag you by email. Not at a computer? Easy you’ll get an SMS message. None of that functionality seems to be there yet though, as there is no place to supply my email address (you’re supplied with an @googlewave.com address which you can’t access), or my phone number (should already know my Google Voice number). And there is the matter of stability. It certainly has some kinks to be worked out.

So, now that I’ve caught the Wave, I’m looking forward to really starting to use it to my advantage and riding along to see how the tool evolves. Isn’t it fun being an early adopter?

So you likely know that I recently dropped and broke my Nikon SB600 flash. Disappointed as I was about this, I was already thinking of how I’d replace it. My searches for Nikon compatible flashes had always included these apparently super affordable Phoenix flashes. Now, of course, I was always very suspicious of these for a couple of reasons. First, in all the auctions and other sites selling these I never saw information indicating if this had ANY manual control, and there was never a picture of the rear panel of the unit! Second, there weren’t really any reviews of it online. I found a few, but usually it was on something like Amazon where it was fairly apparent that those reviewing were (at best) uninformed users who wouldn’t know the difference between a “good” flash and a bad one.

In spite of those facts though, I convinced myself that spending $80 to find out if the thing is any good couldn’t hurt, right? Wrong! The thing got shipped reasonably quickly to me from the eBay seller, and upon opening it up it seemed like it had some potential. Yes, it was kinda cheapy plastic and felt light, but that is what I expected for something so inexpensive. The real dissappoinment came when I put it on my camera, and snapped a few shots. You can see the results here. Needless to say this thing, even when doing full power pops, can’t provide enough light to expose a shot properly. This, in spite of the fact that it’s a big, imposing looking flash. They did a lot to try to make it look like an SB800, hinting that it might actually have some decent performance.

So now, to answer some questions I had about it. This is strictly intended for use with iTTL. The back panel just contains a couple switches, one to turn it on, and one to switch “modes, and a guide for ISO/zoom/distance that this flash supposedly covers. The switch to change between “BL” and “STD” has absolutely no influence on the poor performance. Using a Cactus v2s to pop it seems to do only a very low power pop and the flash does not seem to recharge afterward.

The zoom is manual which is to be expected, and goes from 28mm to 85mm. When I zoomed it in to 85mm, and fired it I noticed some artifacts from the lens/diffuser which were distracting see here.

My plan was to use it along with a Nikon SC-28 iTTL cable to simulate the way I was using my Nikon SB600 when shooting butterflies on the fateful day that I broke it. I figured that I would lose some convenience having to go with a cable, and zoom the flash manually. I didn’t anticipate that the thing wouldn’t have enough power to expose a frame properly! So if you’re wondering if this thing is any good, and maybe thinking you’re willing to give up a little performance and convenience for a STEAL of a flash, think again. You do, sadly, get what you pay for.

For what I did actually do to replace my Nikon SB600, stay tuned. I went on a bit of an ill advised shopping spree, and have some exciting stuff headed my way!

If you’re reading this, it means that the DNS records have replicated and Random Musings is now fully hosted on my shiny Linode VPS!

I’ve been steadily growing out of my previous hosting solution over on Host My Site. All things being equal they’ve served me very well, but running WordPress started to demand more memory than they’d allocate for a shared hosting customer. Then there’s the limited functionality of the PHP stack which I was starting to run up against quite regularly.

I have to say I’m SUPER pleased with Linode so far. I signed up for it on the 21st, and by today I’ve got it completely setup hosting web and email for three domains, with another on the way. I was worried that it would cost me money, but when I account for the other hosting accounts I’ll be able to close I wind up money ahead. Sweet!

Hopefully this change will be seamless to ya’ll, might notice an increase in speed. Let me know if you see anything “odd”.

I just received an email today from one of my contacts on LinkedIn. It was an invitation to join this new UNYK Address Book application which is apparently in beta.

I think I’ve made it clear that I’m a big fan of anything which centralizes my information and allows me to access it through a web browser from anywhere, so I checked it out.

Overall, it looks quite promising. It will harvest your existing contacts from several different locations (Yahoo!, Google, LinkedIn, Microsoft Outlook, MSN, etc.) and consolidate them. When you sign up you provide your personal and professional contact information, and this in turn keeps your contact record up to date for anyone who has you in their address book. Their premise is that everyone will eventually use them to manage their contact information, and therefore your address book will always be “automatically” up to date, because all of your contacts will have updated their information with UNYK.

My first, and perhaps biggest problem with the service is that they don’t provide an https:// option. So as I’m entering all of this personal and professional data, as well as supplying my login credentials for these other services it’s all going across the wire in plain text!

My second problem is that I’m already using GooSync to store my contacts, and then synchronize them with my HTC phone, which is my life line as far as contact information is concerned.

There is also some considerable controversy regarding the fact that it will effectively “spam” the contacts that you do import inviting them to join UNYK as well. This is no doubt how the email was sent to me. I’m less concerned about this than the previous two points however.

So in order for me to fully embrace this new UNYK solution, it’ll have to get a “secure” presence, and either integrate (which they seem to already do quite well with several other services) with GooSync, or provide the same functionality (syncing with my HTC).

Seems like a cool idea, but it’s not quite mature enough for me to dive in head first. I’ll keep an eye out though!

EDIT:
Since I was more than a little bit surprised that there was no secure access to login and supply my credential for other services, I did a little further digging. UNYK insists in their privacy policy that they encrypt any “sensitive data” that goes across the wire. Here it is directly from their site.

How Secure Are Your Web Servers? [ ^ ]
The security of your personal information is important to us. When you enter sensitive information (such as credit card number) on our registration or order forms, we encrypt that information using secure socket layer technology (SSL).
To learn more about SSL, follow this link http://www.verisign.com/products-services/security-services/ssl/index.html.

We follow generally accepted industry standards to protect the personal information submitted to us, both during transmission and once we receive it. No method of transmission over the Internet, or method of electronic storage, is 100% secure, however. Therefore, while we strive to use commercially acceptable means to protect your personal information, we cannot guarantee its absolute security.

If you have any questions about security on our Web site, you can contact us.

So, since it looked like they used a lot of Web 2.0 technologies I thought possibly they were doing some javascript magic to encrypt the stuff going across the wire, I did a little test with Wireshark to see what got sent. I bit the bullet and imported my gmail contacts, and this was the result, with the password obscured by me, of course.

POST /Scripts/dotNET/ContactFinderProxy/Services.asmx/ImportWebContacts HTTP/1.1
Host: www.unyk.com
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.17) Gecko/20081021 Firefox/2.0.0.17
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
X-Requested-With: XMLHttpRequest
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Referer: http://www.unyk.com/Diffusion/main.asp?nub=5EDC7952-7D0D-445F-B49A-0E068F4CA09E
Content-Length: 76
Cookie: BIGipServerwebUnyk=185207306.12310.0000; s_cc=true; s_campaign=en-US-0064; s_cp_persist=en-US-0064; s_sq=%5B%5BB%5D%5D; s_vi=[CS]v1|49503BB000004A0E-A02085E000051AD[CE]; InfosCompleted=3; nub=5EDC7952%2D7D0D%2D445F%2DB49A%2D0E068F4CA09E; __qca=1224815862-86415704-76514833; __qcb=1181521546; UNYK=LoginPassword=&LoginUsername=&RememberOption=0
Pragma: no-cache
Cache-Control: no-cache
provider=Gmail&username=qwikrex%40gmail.com&password=*********&useOctazen=true

Clearly not secure. I do have to admit however that I seem to have been wrong about the mobile sync, they do provide this, though I’ll have no idea how well it works until they fix the security problem.

Since I became a dad, and bought a dSLR I’ve been trying to figure out the best way to store and share my pictures of my son, and other interesting stuff I shoot. As far as securely storing it locally, I have a sizable RAID setup that handles redundantly storing my pictures on two drives, but it’s the sharing part that I’ve had some trouble with.

Initially, I was using my own web host and the rather nice PHP based SPGM photo gallery software. The problem though, is that it’s fairly tedious to resize and upload the images (I wrote a whole blog post about it here), and I have “only” 20GB of storage and 500GB monthly throughput. When shooting at 10 megapixels I could fill that space up quickly. Beyond that I knew that some of the web based sharing sites out there had some really cool features for sharing and organizing your photos.

So, the search begins. I had some (I thought) fairly simple requirements. I was hoping to have these requirements met by a free solution, but I was willing to pay a nominal subscription fee if I got everything I was after. Here’s the run-down of what was important to me.

• Ability to upload original sized images. Some services have a limit to the size of each image
• Unlimited storage/uploads
• Sophisticated organization features. This means unlimited “albums” and the ability to have an “album” hierarchy and probably some other stuff that the service would surprise me with
• Ability to use my images on my website, blog, forum posts, etc.
• Ability to have a gallery on my site which displays all of the public images from the photo sharing site

That’s a fairly short list, and seems as though it should be fairly easy to match but surprisingly it isn’t.

So let’s break down the services I tried and how they stack up. First, let me say that I did not try every service out there, I ruled some out just based on their feature set, some due to their obscurity etc. Listed here are just the ones that I either discovered myself, or were directly suggested to me. If you want to do your own search and want to see all of the services available, here are a couple links that I found useful during my search.

Top Ten Reviews
CNET Reviews

Picasa

This was a fairly natural choice for me since I’m a pretty heavy user of Google services. I use Gmail, Google Reader, Google Analytics, Google Calendar, Blogger (switched from blogger to wordpress), Google Docs, and YouTube. Additionally, Picasa has a great desktop tool for uploading photos that acts as a great photo management tool on your local system as well.

Unfortunately, Picasa only allows you to organize your photos into albums with no hierarchy. Also, while you can upload a photo in it’s original size, the number of photos you can store is limited by your storage space. You’re given 1GB of space for free, and you can buy additional space on a yearly basis. But again, shooting at 10 megapixels means I’m going to need a whole lot of storage space, and I suspect that even their 400GB plan for $500 a year would become insufficient sooner or later.

Facebook

To be honest, Facebook is actually what warmed me up to the idea of using a photo sharing service on the web. So while it’s technically not a photo sharing service I thought I’d talk about what I did and didn’t like about the photo storage and sharing options it had.

First, I loved how easy it was to upload pictures and tag the subjects in the photo. Facebook also had no limit to the number of photos I could upload. Of course, those photos were downsized to a much more reasonable 604x404px, and their album hierarchy was also flat. And perhaps the most annoying thing was that I couldn’t share my pictures on my own web site and the galleries I made public I had to link directly. For instance I can send you to my public album of artistic shots but I can’t send you to a page that shows all of my public albums on Facebook. If you had a Facebook account, and were added as one of my friends you could see them all, but that’s cumbersome.

Snapfish

Frankly, I didn’t get very far in evaluating this service. There wasn’t much public information about the services offered, and it had a requirement of buying some product from them at some specified interval in order to keep your account active. As such, I never even signed up or tried it.

And the winner is….

Flickr

As it turns out, this had all of the features I wanted, plus some ones I didn’t realize I wanted until I used them.

First, the negatives. With a free account your only allowed to upload 100MB of files each month, and you’re limited to 3 “sets” (Flickr’s version of an album). Also, you can’t technically have a multi-level hierarchy of sets but there are ways to overcome that (more on this later). Of course, those limitations are removed as soon as you buy a “Pro” account which is a paltry $25 per year. Needless to say I went with that.

Now the good stuff! While you can only have a flat hierarchy of sets, you can create “collections” which contain sets or other collections. These can be nested up to 5 deep. This more than handles my organization needs. For instance, I’d like to categorize all of my pictures of my son, then break it down into particular types of events, then the specific event. Something like “Baby Pictures -> Firsts -> Crawling, Walking, Solid Food, Etc.”.

And if that organization is not enough, you can also tag a photo with keywords that are search able by the community, and act as a sort of metadata for organization.

Built right in is the ability to use your photo in a variety of sizes on your blog, forums, website, or whatever you like. Even more exciting is that there are plenty of options for sharing your pictures on other sites, as well as a public landing page for you. They even offer an open API which I’m sure I’ll find useful eventually!

So there it is. After a fair amount of time spent searching I found the solution that works best for me. Hopefully my comparison can help you if you’re searching for a photo sharing service.