Marty Pitt, one of the developers on dpHibernate has been busy. And he has written 3 new blogs covering some of the new features he is working on in dpHibernate

Check them out here:

overview: http://martypitt.wordpress.com/2010/01/18/dphibernate-an-overview/

paged collections http://martypitt.wordpress.com/2010/01/18/implementing-paged-collections-in-dphibernate/

entity persistence http://martypitt.wordpress.com/2010/01/18/entity-persistence-with-dphibernate-overview/

Recently, we released version 1.2 of nomee, a social media desktop app written in Adobe AIR. When I look back, I realize it's been more then a year since we started down the path to build nomee. As I prepare for my presentation at Adobe MAX this week, I thought it would be a good idea to share why we chose Adobe AIR as our development platform and why it makes so much sense – both for our customers and for our business.

Originally, nomee was going to be a native Windows application. However, we quickly realized that it would take too long to build a Windows version and then a separate Mac version. Not to mention the problem of keeping two different applications in sync as we add new features – think of the duplicate code we'd have to write. For a consumer product like this, it has to run on both operating systems, or run as a Web application, from the beginning. That decision is what started us on the Adobe AIR path. But it didn't end with cross-OS support. When we started looking at the benefits of AIR for nomee, we found a few reasons that made it a better solution than creating just another Web application.

1. Offline – For nomee to become a full relationship and information management tool, you need to be able to use it anywhere (on a plane after a conference, for example). We have basic offline support now in nomee – login offline, open cards, get contact information, and so on. And we have even more plans on the roadmap, such as editing and sending cards while offline.

2. Customer Experience – There are a lot of things we can do in a desktop application, which we can't do on the web, to give the user a better experience. We aren't limited by browser sand boxes. We can access local resources to build better caching layers and local data stores, as well as to add native drag-n-drop support. In a web application, every time you login in you need to pull the data back from the server that you saw the last time you used the application – plus anything that has happened since. With an AIR application, you can keep the data you've already pulled cached locally and only pull new data, requiring less bandwidth for the clients and server while decreasing the round-trip to the server.

3. Always Working – By creating a desktop application, we are able to give users a tool that is always monitoring their friends' and families' sites for updates and alerting them as things change. If nomee was a web application, users would need to remember to open a browser and login to see updates. And if they didn't login, they would never know something has happened with someone they care about.

4. Security – For some reason, we live in a world where people don't mind giving out usernames and passwords to random web sites and letting them impersonate you as they login and pull in your data. We don't like that. We don't believe that our db should have copies of every user's login name and password. However, in an application like nomee where we do need to pull in users' data from across the web - at times we do need to ask for a username and password. Because nomee is a desktop application, when we do need to get your credentials, we don't save it on the server. Instead, we save it in an Encrypted File Store that only lives on your computer.

5. Infrastructure Costs – AIR saves us money! And as a start-up, that's important. Let me explain. With an AIR application, you are able to push a lot of the work for each client back to the client. Work like pulling feeds, parsing feeds, etc. Remember a browser is nothing more then a dumb terminal. Granted there is a lot you can do with one, but it is limited in certain ways. If we were to have started out as a web application, we would need to build server farms of dozens – if not hundreds – of servers to do all of the social web parsing that our nomee clients do.

As we dig in to our next nomee build (an engineer's work is never done), I'd love to hear what you think. What makes a desktop application right for you? I'd also encourage you to take nomee for a spin and send us your feedback.

You may of already seen the Adobe cards I created for some of the different adobe products.

Now I've created a nomee card for all things MAX.. This card runs inside the nomee AIR application and monitors all of the sites on the card for updates. So when there is a new tweet, facebook post, blog post, etc.. You'll get an alert. So you know when something you care about has happened. And you can see it all merged together in the Newstream on the card. If your going to MAX you need this.

Direct Link

This was just pointed out to my by Andrew Powell. dpHibernate is used as an example in the spring-flex docs for "Providing Custom Service Adapters"

http://static.springframework.org/spring-flex/docs/1.0.x/reference/html/ch02s09.html

to the guys who figured out how to get dpHibernate working with the spring-flex project, thank you!

The other day I told you about nomee and how nomee was primarily a tool to follow people not sites. However, nomee can be used to do more. So I created some public cards for the different adobe technologies. What can I say, I'm a geek and I follow technology as close as I do friends and family.

These cards monitor all of the key pages and rss feeds on adobe.com that I could find for Air, Flex, CF, LCDS, and FMS. Including the main phone numbers, product pages, support feeds, developer center articles, team blogs, and mxna feeds. All on your desktop.

These are the first cards for our technology section of public cards, watch this page for more public cards. And if you have any suggestions for other public cards let me know or email us at support@nomee.com.

Some of you already know this, but I've been waiting to post the news until I had something to show. With the new year ahead of me, I decided it was time to get out of consulting and back into product development; this time with a company called nomee. What can I say, I like product development.

What is nomee you ask? What is that thing on the side of my blog? First let me say, Nomee is not another social website. It's a tool, built with Adobe AIR, to organize and monitor them all.

If you think about it, if you put all of the websites you've signed up, and everything you've posted about yourself together -- you've created a virtual brand for yourself. Wouldn't it be cool if there was a way to control what part of that online brand people see? facebook for friends, linked-in for co-workers, etc.. Add in the annoying problem of trying to stay on top of all of these sites and all of your friends. How many hours a day/week do you spend going to different sites to see if anything has changed; or have you given up?

These are the problems we are solving with Nomee. With nomee:

• You can control what things about yourself that you want to share with others.
• You can follow your friends. Nomee can monitor over 100 different websites. When your friends do things online you are alerted, then you can decide if you care and want to open the item or if you want to ignore it.
• You can stay in touch. Nomee keeps your contact information synchronized with your friends and families. When they need to know your new phone number - they look in nomee. When they need your new address - they look in nomee.
• You can publish yourself. like I have on this blog, or my facebook page. On the right you'll see my public nomee card (they can be public or private).

As we are starting our public beta and getting ready for web 2.0, check out our beta, you can download it now. Go to nomee.com, or even better, click the follow me link on the bottom of my nomee card (on the right of my blog) and add me to your nomee desktop.

If you've ever used IntelliJ for java development, are frustrated with eclipse, or you wish Flex Builder could do more (and you never use design view). This might interest you.

JetBrains has added Flex development support to IntelliJ 8. Which was just release (nov 6th). Note, they have only added code support with no plans for a UI designer.

http://www.jetbrains.com/idea/

Some of my favorite features

1. CODE FORMATTING!!
cntrl-shit-L and boom the as/mxml file is formatted to my liking.

2. Flaging common errors without running the compiler.

3. Navigating between classes and around a class.
you can jump from an interface to the as classes that implemented a given menu.

4. CNTRL-Q help
Put your cursor on a method or class and hit cntrl-q, intelliJ will dynamically pull the comments out of the code for that class/method and show it to you as help

5. Code generation
It's easy to auto generate get/set method for properties, constructors, implemented methods, override methods

6. Find Usages
A quick search of all the code that uses a given variable to method.

I just posted about a post written about RIA Debugging by Simeon Simeonov, in this post: http://blog.mikenimer.com/index.cfm/2008/10/13/RIA-Debugging-and-ColdFusion-forgotten-feature

In Sim's post he talks about the need for a common place to see all of the debug data from the server and the client.

So my question to everyone. What would this look like?

Let's imagine that there was a way to send all of the client (flex, ajax, silverlight, etc.) logging data and all of the server logging data(ColdFusion debug data, etc..) to a common UI..

What features does that common UI need to have? What would it look like? What are some of the must do features?

Some of you might remember Simeon Simeonov from the early days of ColdFusion. He was one of the original engineers and the architect of ColdFusion at Allaire. Needless to say, he is responsible for many of your favorite features in ColdFusion.

Sim, has recently posted a great blog post about the problems debugging RIA applications. And a possible solution. Definitely worth a read.

http://simeons.wordpress.com/2008/09/16/debugging-ria-ajax-flex-services/

However, there is one more way to do debugging missing from his post (unless it's been updated). One of the last things I added to ColdFusion 7.0.2 before I left Adobe was to make sure all of the ColdFusion debug data is sent with every Flash Remoting request.

This is one of the more common forgotten features in ColdFusion. If you are using ColdFusion with Flex, you can still get all of the information you are used to seeing at the bottom of a regualar .cfm. To turn this on, just turn on debugging in the cfadmin. And then in your result event, you can look at the result event header to see all of this information; sql, execution times, variables, etc..

Way back when, on mikenimer.com I posted a flex dump component that does know how to format this debug data. However, to be honest. I haven't opened the component in the latest versions of flex so the component might need to be tweak to work in flex 3.

But that's no excuse not to monitor this data. With RIA apps it's more important than ever to monitor your requests. It's too easy to write a bad query and not know it, since you can't easily see this debug data. But it's worth a little extra work.

One of the biggest problems with working with data in a RIA/Flex application is that it's all or nothing. You either need to get all of the data or write a lot of code to return the data in multiple requests. The problem is that good design means that we want to design our data object to match the data, not the UI. For instance a User might have an array of Orders which each have an array of Items. Seems simple enough, right. The problem is that this is a large complex objects which could require a query that joins multiple tables when returning data to your application. No big deal if you want to display all of the data. But if you are just trying to output the users name and email in a search result screen then this is a huge performance hit.

Luckily there is a solution, It is called lazy loading. JSP developers, which use the java hibernate framework, have been able to use lazy loading for years. But until now this did not work with remote client applications like Flex. For those of you who have tried, I'm sure your familiar with the dreaded LazyLoadingException. Frustrating huh. Lazy loading let's your define a complete object model, such as a User with an array of Orders. But only return the data you are actually using in your presentation layer (Flex). Avoiding that all or nothing data problem that is so common.

I'm happy to announce a new Digital Primates open source project. dpHibernate, add support to BlazeDS for Hibernate lazy loading. You can find both the java and the ActionScript parts of the project here: http://code.google.com/p/dphibernate

If you're not familiar with hibernate, check out http://www.hibernate.org. At a real high level, Hibernate is a java ORM tool, which lets you map java beans to a relation database. Hibernate does all of the sql work for you.

So how do dpHibernate work? dpHibernate is actually a combination of two code bases. First, there is a custom java adapter for the BlazeDS server. This HibernateAdapter understands the hibernate proxy objects and knows how to convert them into a special dpHibernate proxy which the AMF serializer will ignore and not try to initialize. This is how the proxy objects are able to go back to the client without getting the LazyLoadingException.

The second part of dpHibernate is an ActionScript library which gives your application the code it needs to understand these dpHibernate proxy objects. This AS library has the code to manage your ActionScript beans and knows how to call back to the server to load a proxy once that object has been touched, usually with a binding expression.

In case your wondering, how does dpHibernate differ from the hibernate support in LiveCycle Data Services ES? For one dpHibernate doesn't require LCDS it works with the open source BlazeDS server. The other big difference is that hibernate support in LCDS requires you to duplicate the lazy associations in the services-config.xml and you need to use an Assembler class to get the hibernate objects. dpHibernate let's you call any java method and return any hibernate object.

So check it out, if you can use it I'd love to hear about it. If it doesn't work for you I want to know about that too. And as with all open source projects this one can use as many eyes as possible on it too. If you find any hibernate configurations that don't work let me know. Or better yet, send me a test case with the right hibernate mapping files to recreate the issue.

Thanks, ---mike nimer mikenimer at yahoo.com