Saturday, January 2, 2010
Happy New Year
8:12 pm | link
Happy New Year, friends!
Here we are in January, so named after the ancient Roman diety, Janus. It turns
out that Ronin Technologies has a lot in common with that ancient fellow. Read on and I'll tell you why.
Janus was not just the god of doorways and bridges in their concrete forms, but in their abstract concepts. He represented
transition, bridging past and future, bringing together one vision to another. If we look at him in a modern light,
Janus was the god of integration and middleware.
Everything we do at Ronin Technologies is about working smarter
by standing on the shoulders of giants and helping our customers build bridges across their data and applications. This
is true with the open standards we participate in (such as RETS and MISMO), the technology partners whose tools we use to
integrate data (Talend) and the languages and frameworks we use to develop applications faster and cheaper (Groovy and Grails) while
leveraging existing legacy code.
Like Janus, we have a clear view of the past. In our case, this past represents
the lessons learned over 2 decades' work in enterprise application development. It encompasses the tomes of the
masters, i.e., "Code Complete", "Rapid Development", "Head First Design", and of course, "The
Pragmatic Programmer: From Journeyman To Master".
Janus also sees far into the future. Ronin Technologies' works
with the leading edge and tracks the bleeding edge. The majority of our current implementations use Groovy and Grails.
We are advocates of the SaaS philosophy. We have been following developments in the semantic web and cloud computing.
I won't go stretch the Janus analogy as far as to claim that Ronin Technologies represents the middleground between
civilization and chaos, but I will say we've often found ourselves thrust into the position of hammering out a
workable compromise between extremes.
Ronin Technologies: cross the threshhold this January.
sit annus novus.
Monday, October 12, 2009
VOTE FOR ME FOR RESO BOD
5:15 pm | link
I am Paula O'Brien, and I have been involved with RETS since 1999, developing early adopter technology around the 0.9
version at the largest broker in NE Ohio. Beginning in 2002, I was contracted by Dale Stinton (then CIO) to assist NAR in
RETS adoption through the creation of tools such as reference implementations for RETS servers and clients. In 2003, Bruce
Toback and I created the RETS compliance testing program. I have served RETS as chairperson of compliance from that time through
As a thought leader in the RETS community, I have advocated decoupling transport from payload,
extending RETS to support uses beyond bulk listing downloads, and to outreach to other real estate standards bodies. Much
of my outreach and research is reflected in the concepts expressed in the 2006 RETS2 specification, which I co-authored.
As a long-time developer of both client and server-side RETS, I have unique insights into the strengths and weaknesses
of the standard. I have a history of getting things done, and I am a team player who has served on workgroups and participated
in projects with many members of the RETS community and current BOD.
If elected, I will continue my commitment
towards developing a tactical and strategic roadmap for RETS, and ensuring that this roadmap is followed and progress is reported
to the community. Our biggest technical challenge is future-proofing our current standard, so we have a solid core RETS that
can be extended without breaking backward-compatibility each time it is versioned. It is time to jumpstart our standard and
get things moving again - the standard has sat idle for nearly 3 years and Web 2.0 has passed us by. What else are we missing
out on if we continue to stand by?
It is an honor to be nominated. Please vote for me - help me help you make
RETS a standard we are all proud of, where all your voices matter.
Wednesday, September 2, 2009
Bravo, RETS Compliance Workgroup!
I want to take this opportunity to extend a round of applause and thanks to the members of the RETS Compliance Workgroup.
These folks have donated countless hours of volunteer time to review requirements, run tests, and resolve issues to help get
the new compliance tool into production.
5:15 pm | link
This has been one of the longer running, concentrated efforts
of volunteer time in my history of involvement with RETS. This group has met regularly for the past year and shown tremendous
dedication, patience and perserverance. They are a credit to their companies and to the RETS community. And I,
in particular, think they deserve a standing ovation.
Thursday, August 20, 2009
RETS - Looking Forward and A Little Help From the Past
4:59 pm | link
Matt Cohen has posted another article in his series on "Completing RETS".
It contains some very interesting responses to his recent survey, and, as always, maintains a positive and
So, how do we move forward in RETS? I have a few ideas for getting unstuck. First
we focus on the BUSINESS side of things.
- Stand on the shoulders of the past. Let's dust off those things
that we've put in the metaphorical glove compartment: the RESO governance document and the old RETS Roadmaps.
Enforce the governance document so we can operate effectively as a standards organization. Review the roadmaps to find
out our previous destinations and why we were headed there.
- Gather requirements. Matt's survey indicates
some major areas of concern/interest. Start with these and flesh out use cases. Include, where appropriate, items from
- Prioritize the requirements.
- Use requirements to create strategic goals, and from those
strategic goals, define tactical ones.
This becomes the RETS Business Roadmap. This roadmap is then presented
to the general assembly FOR A VOTE.
Once the general assembly ratifies the business roadmap, we involve technical
folks to discuss how RETS gets from where we are to where we want to be. This requires an architecture group. It's
what the Standards Committee was supposed to be, as opposed to a group that validates the format of RCPs. The architecture
group devises a plan to adapt the RETS standard to meet the requirements of the business roadmap.
This plan becomes
the RETS Technical Roadmap. This roadmap is then presented to the general assembly FOR A VOTE.
Then the workgroups are re-evaluated and chartered with specific goals to move the standard along the technical and business
roadmaps. These workgroups create RCPs based on their charters (which are based on the roadmaps) and everything runs
according to the governance document.
Along the way, NAR will have to loosen its purse strings and fund some
of these activities. NAR should do this by providing the RESO BOD with a budget (again, see the governance document).
The RESO BOD then would create RFPs, put them out publicly for bids, review responses, and designate who receives funding
to do the work. Everything open and transparent, the original intent of the governance committee.
the first technical chair of RETS from 1999 through to his untimely death in 2005, was a good friend of mine, and a visionary.
He moved mountains to make RETS a reality. I don't want to let him down by letting RETS remain stuck in neutral,
or, worse, slide backwards.
Thursday, August 13, 2009
Compliance - Report from The Front
9:14 pm | link
Anyone remember "The Charge of the Light Brigade"?
Well, if you've been involved in the compliance workgroup for the past year, you can relate to it.
are finally at the release candidate stage for the new compliance tool...if final QA testing goes well, this
means we are just scant weeks away from flipping the switch for MLS Associations to come in and test their RETS servers.
this is behind us, I would love to begin discussing issues such as usability and interoperability, especially as they relate
to the new transactions and schemas that are in progress. We need to make sure the things going into the RETS spec are
in line with modern toolkits and business requirements. Something that's testable but not usable or interoperable
is just much ado about nothing.