subscribe via RSS
My last posts haven't been quite technical, and they haven't been quite recent too- I'm sorry, yet I just don't have time. As a brief follow-up: it has been overwhelming in San Francisco ( except for the 300$-dentist bill ), and I'm so looking forward to coming back.
And, tada, I've been spending the last few weeks just entering Rails ( a Ghetto? maybe ) a bit more than I did before. As always, there are cool things to tell. And not so cool things, too. Start with the good ones.
Rails has proven to work extremely well in pre-production mode. No framework-sourced flaws, bugs, whatever. Just nice, and with some caching-salt, speed hasn't been an issue, in contrast, it has been amazing.
That's the good part of it. The bad part is that Rails claims to be capable of working in a distributed environment, providing services ( they don't call them Web Services anymore ) addressable via REST ( buzzzz ) over HTTP, of course. Well, that's not quite true. If you stick with the example given in the docs, and are in fact happy with a remote object capable of experiencing an unauthenticated change of some first name, this is nothing but true. But when it comes to some other features, e.g. associations or caching, one question came up: are they serious?
Let's do some demos. In case you want to include objects of a has-many relationship, the way of choice is ( according to the ActiveRecord::Serialization docs ) either to call to_xml with really ugly parameters ( such as @ship.to_xml :include=>[:passengers, :sailors ] ) in a non-dry manner or to override to_xml, both not being exactly Rails-like, ugly, hard to maintain and only loosely coupled with real-world requirements.
The other part, the consuming part where ActiveResource is indeed responsible for handling everything, has been consequently kept free of useful stuff. This could on the one hand be a pro for people hating Rails' magic, but it's just quite far away from being usable. And it has nothing in common with the way ActiveRecord behaves. Any options? Sure.
At the moment, I'm sticking with HyperactiveResource, the funniest named plugin ever. It extends ActiveResource to play a bit more nice, yet it's not the ultimate answer, but a great extension, still. If you're into some serious Rails stuff with some distributed thingies, you should give it a try.
So what's missing? The feeling to work with something that has been designed by someone who actually uses it doing more than changing first names. I'm really disappointed by having to deal with the framework, something I wasn't used to with Rails before in that intensity. And while Java EE may be a pain, for distributed stuff, it's still a very good way if you need reliable and consistent, proven-to-work solutions.
In my next post, I'll talk about my android experiences so far. Love it :-)
Let's start with the wonderful things: everything at I/O was extremely well organized and planned. Not only the catering was excellent, also the possibility to meet with people everywhere at the site was greatly supported by the seating and the overall arrangement, not to mention the helping manner in which all google staff acted. It's a highly recommendable experience, even if you are interested in cooking more than in tech, I guess.
So for the handset: Someone gave me a clue before the conference started, I didn't believe him, he was right, I am still thrilled. The device, the HTC Magic with some custom Google-Branding, works. And mostly, even well. It's nice to see how a good operating system featuring a cool SDK can lead to a mass of apps being available. That's the most noticeable thing I guess. From a perfomance point of view, there are still some improvements possible, especially the touch-interaction doesn't seem to be as responsive as iPhone's, yet the overall impression is impressive. The 360°-StreetView is a killer, btw.
And what's next? A custom keyboard. I'm working on it, maybe this night a bit, maybe tomorrow or over the weekend. I see a big potential in _new_ input methods, as the old qwerty-style thingy hasn't changed for some hundred years...
Hey! I'm currently located in session room 09 and learning on how to code thee for android. Back to the headline.
After being opened by Eric Schmidt, the whole Keynote thingy mainly concentrated on HTML5 features. These features are really impressive, be it a video-tag, the canvas element ( max :-) ), background-worker processes and other related stuff that is quite handy and really capable of improving every developers live. It's also nice to see that every major browser vendor, excluding Microsoft, seem to be well-prepared for the upcoming changes.
The clear development towards web-based everything not being distinguishable form "normal" locally-ran applications is also supported by new caching mechanisms and subsequent possibility of using e.g. gmail even with no connection, a highly useful feature certainly leading to a broader acceptance of web-based applications.
Another thing remarkable is google's view on android and it's wide market adoption. In contrast to popular tech opinion, they seem to be quite satisfied, and predicting a strong year for android to come. An indicator may be that this session room I'm sitting in is overcrowded. Another is the wide range of apps presented, including gmote, a remote control application working on all platforms providing a simple to use remote control feature for your desktop, including touchscreen-to-mouse translation, remote media control and even the possibility to watch movies and pictures ( in fact, everything renderable ) stored on your computer on your handset. Nice.
I'm looking forward to the rest of this day, especially, tada, for my free htc magic. Stay tuned.
hey! it's now about 5 hours until take-off, I've finished packing my stuff and now kind of lost in not knowing what to do. In fact, Im thinking about where to post videos if it's not youtube and where to easily put pictures online. Twitpic seems to be a good choice for I/O liveblogging, yet I'm trying to do some other stuff ( visiting twitter, maybe, hope they agree ) as well. As I'm a poor student not able to rent a car or something, I hope my fellow student Jay will pick me and my friend up for a ride to silicon valley. I've definitely got some ideas to drop of there.
- Tell Google to put some up-to-date Java Reference on top of the search results. At the moment the first hit is 1.3.1.
That's just one, of course. I hope the weather in SF isn't that bad, warm, cold, foggy, whatever. And I'm looking forward to meeting lots of talented, enthusiastic, open and friendly guys to talk about everything technical, and anything else.
Just a bit excited: momo.
Our beloved model-view-controller pattern seems to act as an excuse for every damn web-framework out there. Yet there is one problem. From my point of view, no framework to date has ever managed to slice a web application in a useful way. Really. Why?
First of all, it should be clear that patterns just like MVC can't be adapted without major changes from desktop environments to the web. Why? Well, desktops are a safe harbor compared to every browser. The Operating System provides resources, screen estate, some kind of event handling and the promise that once you build your app around a certain system, it will work there. Of course this is the major drawback of desktop applications.
Web Applications are not built for just one system, they are mostly built with the target of total platform-independence. Including that nothing can be taken for granted, just like screen estate, resolution, browser software etc.
And then there is this huge limiting factor called HTTP. HTTP is a simple, beautiful protocol that does a great job for what it was designed. That is, delivering web pages, stateless, happiness. Which introduces just a new detail that clearly seperates desktop from the web, the web just doesn't know anything about state. Once a server delivered a page to you, he just doesn't care. Really. We introduced sessions and stuff, yet, there is this design-based limitation, and for the time being, we're just working around this limitation, whereas desktop applications are stateful: ever heard of RAM?
So the problem we are actually facing is that all the well-engineered patterns of the desktop world just can't be adapted. Sorry. There maybe certain areas where the impression of adaptability may occur, yet these impressions vanished as AJAX appeared.
Why? The traditional web-application, let's call it Web 1.0, was based on that well-known request-response-leavemyalone cycle. Maybe some session sugar enabled a stateful behaviour, whatever. And we had a way to adapt MVC: put everything that is persistent or part of the "business logic" in a Model-Class ( aka bean ). Go ahead and search for your embedded html. Try to put in a seperate file, and tell all your geek-friends that it's the view. And finally, the glue was the controller. And yes, it worked out really well. That was then.
Since the unfortunate launch of GMail everything has changed. There is no longer anything like "impossible", since someone clearly demonstrated that virtually no restrictions in terms of usability and functionality exist.
Again, from my point of view, Google just didn't reinvent the wheel, they just used available techniques in a new way.
So, with all this "new" technology, web application creators were forced to adapt, which led to a wide variety of 1) AJAX-Frameworks like Prototype and JQuery 2) Smart helper functions for server-side components to hide away the fact that none of them is able to encapsulate that new technology beyond some well-designed layer of abstraction.
Welcome to my world. I'm doing web stuff daily. Someone even pays me for doing it. But I'm really, really frustrated. There is simply no single well-designed framework, enabling me to really focus on what I want to do, not on how.
Today, business logic isn't the problem. There are some very good approaches making it a breeze to brew out even complex logic.
But there is still too much code here ( in my repositories, maybe I'm just doing wrong ) that's just dealing with requests. But the amount wouldn't be a big deal, since the average linecount already dropped massively over the years. The problem is that there is absolutely no beauty. Nada. No language can hide, not even Ruby, that it's ugly to deal with requests on a per-request level.
I don't have a solution, though I'm thinking about it a looottt. And that's just my opinion, expressed in some kind of english. And I'd really appreciate any single comment.