Ghetto. Zed may be on to something…


I've been slowly considering the use of RubyAMF in a couple of new Rails projects. By "slowly" I mean that there have been some more pressing projects that have prevented me from really "diving in" and experimenting with RubyAMF; only leaving enough time to read some docs and follow the Google Group.
Consider my previously stated credentials when I say that RubyAMF looks great. Given the following recent events it appears that the project has a lot of momentum:
The latest RubyAMF blog posting, RubyAMF State of the Union (doubly posted on the Google Group) is basically a well-structured "rally the troops" announcement to the community. The project founder, Aaron, is moving on to some new projects leaving it to the community to keep up the momentum. I'm happy for him. I can't imagine how time consuming the almost-sole development of RubyAMF has been. This is the real test. How will the project fair on the shoulders of the community?
(Remember: I'm not in the know on the project, I'm seeking your thoughts and opinions, and for good times I'll pull out the good ole' "Jump To Conclusions Mat.")
It's too early to tell for sure, but from my point of view I'm a little disappointed (imagine me hypocritically pointing) with the lack of any community responses to either the blog post or the Google Group post. I say, "my point of view" because I'm hoping that there have been responses and things working that I'm unaware of.
One week ago RubyAMF had good momentum with a promising future. Is that still true today? Is it a bad time to start using RubyAMF?


I'm not against acronyms, but recently I stumbled upon the Java Community Process (JCP) Wikipedia article, while looking up what exactly JSR (Java Specification Request) stands for. The JCP article lists all (or at least some - I don't know) of the JSRs that exist; including their number and technology...
RTSJ, JMX, JAXP, JDO, JCA, EJB, CLDC, JAXB, JSIP, CDC, MIDP, JMI, NIO, JSTL, JSP, JDBC, JNLP, JDM, JAXR, JDOM, WSDL4J, WMA, JSF, MMAPI, SLP, SDP, JCR, SATSA, SIP, JTWI, NIO2, JBI, JAX-WS, XQJ, SDO, JDM, MTA, IMS, JTA
Oh oh... looks like I forgot one... JBS
This is in response to Michael Urban's posting, "And The Fastest Growing Web Framework Is..." (which is also kind of a commentary/response to a Rick Hightower blog posting) which awards the honors to JSF based on job posting trends from February 3, 2005 to June 27, 2007.
I won't argue that the job trends chart clearly shows that JSF has had a significant number more job postings for the last two and a half years. You might argue the means the data was gathered but that's already been done extensively in the article's comments.
I will offer an alternative (I'll admit a bit ridiculous) interpretation that states the reason there are so many more JSF job postings is because JSF is the least productive web framework listed; requiring more developers to complete a project. I know it's another poor conclusion drawn from the chart, but I would venture to say that the average JSF project's development team is larger than other development teams using the other listed web frameworks.
FlexFM is an open source project created by the folks at Soliant Consulting as an alternative to Flex4Filemaker. This is great news! It's not that I wish Flex4Filemaker to die, but it wasn't setup for success from the start. Flex4Filemaker was created by my lonesome self as a favor with zero (afaik) production usage. I had hoped that someone/s would join in the project, but that never happened.
I am officially discontinuing development of Flex4Filemaker. I will not remove the project from google code, as I think at the very least it could be used for reference.
FlexFM is setup for success with big plans for continued development. I would highly recommend anyone interested in Flex4Filemaker to take a good look at FlexFM.
I thought this was worth sharing...
Pay $14.99 at O'Reilly or get it FREE at Ajaxian as PDF
You choose.
...and aloha Google (kind of).
"Mahalo is the world's first human-powered search engine" and I'm making the switch. Using Mahalo is easy, but switching from Google (is the link even necessary?) is not. It's not that Mahalo's search results are sub-par... they're actually better... when there is a hand-written result page. Even when there isn't a Mahalo authored result page, the site returns Google's results. It's really a win-win for the user. The hard part, is breaking the habit of typing "www.google.com" when I need to find something. Oh... and when I do remember to go straight to the Mahalo home page... I kind of miss the simplicity of classic Google.
To combat my Google habit, I've created a nice little, simple, ugly, but functional Greasemonkey script called google2mahalo. The script forwards search requests from Google.com on to Mahalo to ensure a Google habit doesn't prevent getting the best search results available.
Go on... TRY IT... there's nothing to lose...
It's time for software developers to quit doing what we're told and start thinking. We're not robots. We're intelligent individuals who can consider context and produce results beyond the handicapped communication of a formal requirement.
It's the software developer's responsibility to ask questions, listen to the answers, and do whatever it takes to understand the problem and it's symptoms; ultimately capturing the Spirit of the Requirement. The Spirit of the Requirement can be likened to the Spirit of the Law, where the focus is placed on intent; not literal definition.
For example, it's a terrible idea to spend hours styling an Adobe Flex application to match an HTML mock-up. Everyone, including the developer will be disappointed. If the customer wanted HTML, they obviously could have done it themselves. Think. Interpret. Provide value.
This problem is more common than you might think. In fact, if you haven't witnessed similar situations, then chances are that you've unknowingly participated in them. Consider an experience where you had done exactly what was asked of you, yet it wasn't good enough?
It's time we open our eyes, lift our hands from our keyboards, and be more than requirements transcriptionists.
I know... I'm very late on all of this. Greasemonkey isn't new and neither is using Google Translate as a proxy/tunnel. Heck, there's probably already a Greasemonkey script that combines the two! Nonetheless, Greasemonkey is new to me and I decided to write this for fun even though I'm not sitting behind a corporate proxy myself.
Google Proxy will add two "User Script Commands" to your FireFox Tools->Greasemonkey->User Script Commands... menu:
It's important to note that when Google Translate navigates to a URL, it also automatically converts all of the links on the translated page.
Special thanks to Jim Wilson for sparking my interest in Greasemonkey and sharing his Yoda ways with JavaScript.