Jekyll2025-02-07T05:57:35+00:00https://ramblings.saager.in/feed.xmlRamblings of a wandererJust my GitHub pages blogSaager MhatreHow touching!2011-02-18T00:00:00+00:002011-02-18T00:00:00+00:00https://ramblings.saager.in/2011/02/18/how-touchingTo Standard Chartered,

Continuing on my previous rant, while I appreciate the very heartfelt birthday wishes via SMS followed by a mail notification of the same, I think I'll settle for better service.



Sincerely,
A disgruntled customer
]]>Saager MhatreFishworks @ Joyent2011-01-20T00:00:00+00:002011-01-20T00:00:00+00:00https://ramblings.saager.in/2011/01/20/fishworks-at-joyentJoyent's Cloud Analytics talk titled Solving Big Problems with Real-time Visibility into Cloud Performance. Of course, I was interrupted by The Real News' panel discussion on WikiLeaks after which I couldn't watch either stream to its conclusion, but it was a fun morning! :)

Back to Joyent- now that almost the entire DTrace team from Sun's Fishworks group has moved to Joyent, it was inevitable that they would retarget the real-time analysis technology they were building for Sun's storage line to Joyent's cloud offerings.

While the talk went on to describe the various statistics provided and how we could utilize them, most of the first half was a bunch of fun anecdotes from the Fishworks effort. It was nice to have Bryan himself tell us about the origins and need for DTrace and (more importantly) the serendipity that lead to Brendan's famous Shouting in the Data Center video!

Bryan Cantrill and Brenden Gregg have been busy modifying the Fishworks DTrace consumers to monitor SmartNodes and SmartMachines instead of disks in JBODs. It seems Joyent will soon be making these monitoring services available to all cloud users to allow fine-grained analysis of their production deployments in real-time.

The statistics seem to be presented primarily as a heat map of no. of ops at a given latency over time. The tool also provided for drilling down into specific programs/calls to refine the trends. The two of them also pointed out a number of commonly found patterns in such analysis and how they interpret them. It was a lot of fun to see these two ex-Sun h@k0rs bounce off each other as they presented their latest offering.

Here's wishing Joyent luck on their new venture and many more!]]>Saager Mhatre… beyond Programming (and Development)2010-12-13T00:00:00+00:002010-12-13T00:00:00+00:00https://ramblings.saager.in/2010/12/13/beyond-programming-and-developmentdifference between Coding and Programming. That idea has been long over due for update, so here goes.
Coding is about how you should write,
Programming is about how you shouldn't;
Development is about bringing it all together,
Solving is about putting it out there!
Coding as about the Language and Syntax,
Programming is about the Paradigm, the Thought Process;
Development is about Dependencies and Integration,
Solving is about Understanding and Reacting.
Coding is represented by the 'Writing' metaphor,
Programming is epitomized by the 'Construction' metaphor;
Development is idealized by the 'Evolution' metaphor,
Solving aims to bring 'Satisfaction' all over!
Coding defines the Solution,
Programming defines the Problem too;
Development defines who will solve it,
Solving actually does it!
Coding creates the Implementation,
Programming creates the Interface;
Development creates the Framework,
Solving creates the Application.
Coding is about "Getting it in place",
Programming is about "Getting to know it!";
Developing is about "Getting it across",
Solving is about "Getting it done!"
Coding gets you Paid,
Programming makes you Employed;
Development makes you Engaged,
Solving makes you Satisfied.
Coding is what we HAVE to do,
Programming is what we SHOULD be doing;
Development is what we LIKE to do,
Solving is what we MUST do!
]]>Saager MhatreCustomer Care2010-12-13T00:00:00+00:002010-12-13T00:00:00+00:00https://ramblings.saager.in/2010/12/13/customer-care
How big boutique shops get away with crappy products that their primary customers don't use anyway!
Let's just get it out of the way, Standard Chartered Bank sucks! Leave aside the fact that they have a next to useless netbanking experience that starts off by making you set a password you'll probably NEVER remember because they have the most non-standard password requirements. Then, if you forget your password, you're only respite is to have a temporary password SMS'd to you once you've given them your ATM/Debit card number and... (wait for it) PIN! But it's not over yet, 'cause the temporary password just let's you create a new login. Yup, you read that right, not reset your password, but create an entirely NEW login; new username and password!


Oh, and did I mention that once you do manage to get in, you can only see transactions upto 3 months ago. Yes, your transactions... transactions you effected through your account beyond 90 days are only available to you on requesting a statement from a branch; and even they're not authorized to pull statements beyond 6 months! (insert face-slap here)

But that's just the online experience. On the ground it gets even better. Did you know that StanChart has less than 6 ATMs in all of Pune? To top it off, almost all are in reasonably remote areas; and the cherry is that you can never find parking spaces near any of them! Even though 3 of them are in branch offices. I'm not kidding, the last time I went to the ATM in Kalyani Nagar, I was instructed by security to park in front of the adjacent building! Following which I had to sign in at security and (surprise, surprise) walk up the drive-in on ramp that led to their office, where lay an ATM so that I could change the PIN on my ATM card. Thank you StanChart for turning a 5 minute activity into a 15 minute ordeal, we feel so blessed to be banking with you.

But here's where it gets really interesting. Because I ran up quite a bit of a balance in my account, they bumped me up to Preferred Customer. What that basically meant was that they assigned me a nanny to nag me every other day about 'investing' all that balance. And when I calmly informed her that I was looking at investing through other avenues, she actually got mad at me!

So, here's the question, how is it possible that big banks (at least in India) can get away with really bad basic services? My guess is that because we're not really their target group. We're just the sideshow they run to absorb spare capacity. The people they're really looking for a large corporate accounts and big ticket investors who want babysitters at their beckon call to run the bank errands for them. Let's face it, that's where they're probably making most of their money.

But then, that's just my opinion... who cares? I don't! I get much better service from my IDBI account; even if their netbanking site has horrible UX, at least you can do stuff on it!]]>Saager MhatreGettin’ Groovy at the IndicThreads Conference On Java2010-12-13T00:00:00+00:002010-12-13T00:00:00+00:00https://ramblings.saager.in/2010/12/13/gettin-groovy-at-the-indicthreads-conference-on-java5th IndicThreads Conference On Java here in Pune. This would be the second time I attended this conference and the first time I presented at it. I was pleasantly surprised that it turned out to be a whole lot more informative and entertaining than I expected.

Harshad Oak kicked off with the keynote on recent changes in the Java ecosystem. It touched on topics such as Oracle's purchase of Sun, new language features, other languages on the JVM and potential avenues for the growth of Java (viz, cloud computing and mobile development). He concluded with the interesting viewpoint that Java devs would do well to wait, watch and ride the change.

Having landed the first slot of the very first day of the conference, I was pretty nervous about setting the pace right for the event with my DSLs in Groovy talk. I think I did pretty well , especially considering I hadn't gotten any time to practice the deck... at all!

The presentation spun up quite a few interesting discussions such as:
A bunch of people asked me if there were any real world examples of Grails apps; I think the Testimonials page on grails.org should answer that sufficiently.


It was also nice to be followed by another presentation relating to Groovy. Aniket Shaligram of Talentica demonstrated the benefits and caveats of the flex-scaffold Grails plugin by quickly building an app from scratch within a matter of minutes. And I must say, I was very impressed by the Flex view scaffolding, much as I always have been by the HTML scaffolding in Grails. The one concern that I did raise was around this technique landing the team with two MVC apps that need to keep their models in sync; while Aniket assured me that they faced no major hurdles there, experience forces me to maintain a healthy dose of skepticism.

Another talk that was met with particular enthusiasm was Shekhar Gulati's demonstration of Spring Roo. Shekhar also live-coded a Spring MVC app with various bells and whistles (persistence, relationships, security, deployment to GAE, et al). The productivity accelerating qualities of Roo were intriguing, but I've always been a little reserved about it and about Spring MVC in general. I'll leave that argument to a whole other post. :)

The Unconference hour in the middle of day 2 was another highlight of the event. The group discussed various interesting issues such as:
  • technology conferences should present more code and less kool-aid
  • potential Spring Roo addons
  • application profiling tools (JProfiler, VisualVM, IBM Health Center) and their shortcomings
  • with Spring gaining traction, would enterprises look to Java EE6?
  • should enterprises look at tools/frameworks beyond Spring MVC and Java EE?
In contrast to the rest of the event, the two presentations from event sponsor IBM were mostly J9 pitches- thoroughly passable.

The Sun (ok, ok Oracle) presentation on new features in Java EE6 was a welcome refresher. Considering I've been out of touch with that community for quite some time, it served to reintroduce me to a lot of tech as well as bring me up to speed with what's hot there. CDI's cute use of annotation based qualified DI caught my eye in particular.

The networking and open spaces weren't bad either. I got to catch up with a few old acquaintances, make some new introductions, add a few twitter followers and earn some cool hashcred! In hindsight, I actually regretted not getting business cards printed, but the second slide in my presentation pretty much made up for that.

The ThoughtWorks brand carried me well throughout the event even though I did absolutely nothing to indicate I was a ThoughtWorker (big shout out to good ole' TW!) A lot of people wanted to know how ThoughtWorks operates, why I left and what I'm doing now, why others have left and what they end up doing after ThoughtWorks- a somewhat muted (from my end) set of discussions, but very interesting all the same. People were usually pretty surprised when I told that that I actually quit ThoughtWorks to figure out what I want to do next and that I was currently voluntarily unemployed! :)

Well, since this is a fairly contrarian blog, here's what I wish would have gone better:
  • better gender distribution; we ended up with just 1 girl in the audience on day 2 :(
  • the turnout was pretty low at under 50; is Java as a technology really over the bump?
  • demo'ing CRUD apps and then engaging in RDBMS-bashing in a NoSQL plug
  • Enterprise still looking at dynamic languages with skepticism
  • Harshad calling Scala a scripting language :P
All in all, it was a weekend well spent. Kudos to Harshad, Sangeeta and the rest of the Rightrix team for another well organized event in the city. And thanks for keeping it eco-friendly!

Oh, and before I forget IndicThread Java celebrated it's 5th consecutive year this time, so we got to have cake!

]]>Saager MhatreFragments of a wanderer- Part II2008-11-14T00:00:00+00:002008-11-14T00:00:00+00:00https://ramblings.saager.in/2008/11/14/fragments-of-a-wanderer-part-2
Ever wonder why we hear birds chirping at 2:30 n the morning? Have we messed up their biological clocks with all the artificial lighting?!?]]>Saager MhatreTaking the stack for granted2008-09-23T00:00:00+00:002008-09-23T00:00:00+00:00https://ramblings.saager.in/2008/09/23/taking-the-stack-for-granted
It amazed me no end how much of the software on my computer .NET 3.0 and ASP.NET 2.0 simply assumed or installed without even checking too see if I really wanted to be tied in to it.

For instance, ASP.NET automatically assumed that all my apps would be floated on IIS 5.0. Interestingly enough, Visual Studio.NET 2008 also made the same assumption and required me to have a well configured instance of IIS up and running every time I OPEN my project! So now, I just leave my IIS instance up and running all the time; in fact, just like almost every other ASP dev would have to, I have the IIS service set up to start automatically on boot. :(

And when it came to security, every one just assumed that we were using Windows Domain User Authentication. ASP.NET even has its own sweet little group of users that run the sites and impersonate as users on them. You just grant them access and shazam! you're good to go.
Except now you're stuck with that group and any fine grained access control is going to entail some serious Active Directory management... that I'm not at all keen on!

What all this points at is how Microsoft seems to want to lock us into their stack. Given that there aren't really any other viable platforms to host .NET apps, we don't really have much of a choice in the components; but even when the options do come in, these assumed dependencies will raise the barrier to entry for those options to unsurmountable levels. So we're going to be stuck with M$, for ever!

I guess some people are just never going to get it.]]>Saager MhatrePutting REST to rest2008-07-28T00:00:00+00:002008-07-28T00:00:00+00:00https://ramblings.saager.in/2008/07/28/putting-rest-to-rest
Representational state transfer (REST) is a style of software architecture for distributed hypermedia systems such as the World Wide Web.
- from Wikipedia

The term REST along with the principles it implies (or 'should' imply!) were put down in a doctoral disseration by Roy Fielding.

Actually IMHO, REST is just SOA and WS wrapped in a layer of OOP with just a generic Resource entity at the application layer. Even then, you kinda get to roll your own with everything- serialization, interaction, responses, validation...

Well... OK, I may have over-genericised that. But, the funny thing is, that's the funny thing about REST! It is very generic.

Even the primary 'Resource' definition is vague; the interface is almost completely implied-
  • POSTing to a URL creates a new resource (POSTing what?!)
  • I GET a resource referenceable at a given URL provided an id, otherwise... I get all resources at that URL (?); unless, of course, it is a singleton resource, in which case I get the singleton instance. :S
  • PUTting causes edits, although POSTs may behave in the same manner
  • HEADs can be used to detect the presence of a resource, while DELETEs... delete![1]
  • And I'm not even sure if OPTION and TRACE are relevant
And that's just REST over HTTP! Wait!! Is there any other REST?!? Well actually REST is a meta-architecture, it's protocol-agnostic. It's supposed to work for all hypermedia- so we should be able to do it over HTTP, FTP, SMTP, SNMP(?)...

What is hypermedia? Media hopped up on too much sugar?!? Well, the Oxford Dictionary defines it as
an extension to hypertext providing multimedia facilities, such as sound and video.
I don't know about you, but my brains just about ready to explode.

But wait, it gets better. Some people liked the REST over HTTP idea so much that they forked their own flavour. So Fielding has Vanilla, while (these guys) have Extra Fudge! (all puns intended) It's called Web-Friendly services- services that behave reeeeally well with HTTP. Basically services that behave like web pages. Whoa! I'm getting asmx flashbacks!!! So I'm gonna shut up about that now.

Then there's the Hypermedia As The Engine Of State Transfer people[2]. These guys really love the URL. To them the body is whatever it's gonna be! Now it's an XML document, now it could be a HTML FORM, then it could be a JSON object or, maybe, a hCard. I'm sorry, but I can't comprehend this comically 'uniform' interface where your interaction modes are implied, reference end-points are overloaded and results are undefined, or implied, or... did you say they're documented somewhere?

The question I arrive at, then, is- why do we want to be RESTful or Web-Friendly? The loudest argument I hear is that the infrastructure has has already been laid; web servers and proxies with caching, DNS servers, IP routers with path optimization algorithms, the whole kahuna! Think of all the automatic performance gains arising from all that caching! All the more reason to stick more stuff into the URL and fill up those HTTP parameters you never thought to use until now! You just ride the wave!

Hmm... it would seem that REST intends to counter the end-to-end principle by allowing for intelligence (optimizations) at the nodes, but that's a little too debatable; so <sidestep />.

But stepping back a bit, lem'me get this right. We're trying to fit an application protocol directly over a document delivery infrastructure? You've gotta be kiddin' me! I'm not saying this can't be done, just not without a cost- TANSTAFL. Just think about all the time you're going to spend on deciding and negotiating a wire format, and corresponding responses. And that's just one wire format. REST talks of 'representations', a resource could have more than one wire format! I don't know about you, but I've had trouble getting people to understand one wire format right, and now you're telling me they're gonna want to send 'resources' in XML, JSON, YAML, HTML, delimited strings, multi-fixed and EBCIDIC? Over my dead body!!!

Plus, the wireformats are completely arbitrary. Every resource implementer gets to pich their own. So you end up having to 'understand' the specific wire format of every resource you interact with. And by 'understand' they mean RTFM. So much for convention over configuration. Just too much Knowledge in head vs Knowledge in world.

Actually, the wire format is where it gets really funny. XML just had the attribute-element dilemma, REST elevates it to the payload-parameter dilemma! Most Web-Friendly service makers get away without a body to the requests, they just stick a bunch of 'required' HTTP parameters on to the resource URL. So much for 'representation' of 'state', we're back to representation of output. Why does this remind me so much of WS?

I think REST could find application in internal applications where the domain model is well defined, where resources and their interactions are well defined. But I'd still be skeptical because I tried that once at work and we kinda crashed and burned. The biggest brick wall we hit was latency. Given the 'resource' unicycle that REST provided and the specific verbs HTTP provided made our resource interactions multi-stage, especially since REST is stateless. When updating a resource, I wanted to GET a representation of the current state of the resource, modify it and PUT the modified state representation back into its place. But others on the team felt that adhering to those principles added unnecessary communication overheads and chose to add interaction verbs, which was conveniently provided for by ActiveResource. Oh, and that's just when we were not arguing about the wore formats.

Honestly, if you ask me, the only reason REST wont go down the tube like Hailstorm is because it's community driven, not governed and controlled by a megalomaniac. Everyone gets to roll their own and even fork while still calling it RESTful. But even if it does last, I think it's only going to be a buzzword that we'll all have a good laugh about in a few years-

Raj: Hey Saager, we're building this new service for so-and-so and it's accessible via, get this... RESTful resources! :D
Me : Wait, are you sure they're not Web-UNfriendly?!? =D

1 the DELETE's about the most logical thing I got so far! :P
2 sorry Dave, your post is the only one I could directly reference to HATEOS]]>Saager MhatreHere’s a thought… ActiveRecord in PL/SQL2007-11-27T00:00:00+00:002007-11-27T00:00:00+00:00https://ramblings.saager.in/2007/11/27/activerecord-in-pl-sqlWith all the talk about putting logic in the DB and hiding SQL behind stored procedures, wouldn't it be really intuitive if Oracle simply provided a default ActiveRecord implementation for every table in the DB? So, instead of returning a vanilla record type, FOO%ROWTYPE would return an Oracle-generated Object type that had accessors/mutators (getters/setters) for all the columns in table FOO and methods to UpdateRecord and DeleteRecord along with a static method to AddRecord. If you want to avoid any collisions with existing syntax, we could simply have a new attribute- something like FOO%OBJECTTYPE.

My experience shows that most reluctance to encapsulate SQL behind PL/SQL programs stems from the fact that people actually have to write (and subsequently maintain!) that wrapper code. People just don't want to do the donkey work (write the same boilerplate code over-and-over agian for each Table). And personally, I don't think a code generator is very good in this case either. The generated code simply breaks down under maintenance (add/modify/drop column from table).

But, what if all that was done by the database?– CREATE the Object Type when a Table is CREATEd and propagate changes whenever the table is ALTERed; plus maintain the accessors (which could very well enforce the integrity constraints declared on the Table)!

It'd be a great way for the Oracle community to show some benevolence towards (lowly! :P) application developers who can't write PL/SQL even if their life depended on it, let alone SQL!

Also, if you left the <Table>%OBJECTTYPE as NOT FINAL, those who can write PL/SQL could extend it to add even more (business) logic in the database! Whopee and horaay!!!]]>Saager MhatreEasy ain’t Good!2007-10-12T00:00:00+00:002007-10-12T00:00:00+00:00https://ramblings.saager.in/2007/10/12/easy-aint-goodDonald A Norman's Design of Everyday Things (DOET)- a fascinating read about the little frustrations of everyday life inflicted on us by impatient capitalists and disconnected designers (or any combination thereof!). However, as I was reading the last chapter, the case study entitled How Writing Method affects Style got me thinking about how we tend to ignore the flip side to advances in technology in favour of immediate benefits.

A little background- Donald Norman's case study describes an accelerated timeline of writing techniques from the quill-and-ink up to voice-recognition. He observes that with advances in technology making it easy to...
  • write almost as fast as you think; and
  • correct mistakes
... our writing has become more colloquial and unstructured. [However, he does go on to say that newer tools such as voice-based word processors help maintain structure; but the colloquial nature still remains]

To study a more concrete subset, parallel observations can be drawn from the advances in written communication, as opposed to just writing techniques.

We have come a long way from traditional letter writing to recent voice-based solutions. The pen-and-paper letters were well structured. They would be drafted and then... re-drafted! Sentences would be rephrased and reworded to present the most content using the least amount of text. A lot of thought went into such communication, because you knew this wasn't a dialogue and you wouldn't have a chance to explain any misunderstandings, atleast not very soon.

Then, somewhere along the way, we invented the Memo. In our effort to be short & pithy we (mostly) ended up vague & ambiguous. Soon, computers brought us email, letters in binary; and it was good for some time. That is, till IRC invaded the web. Slowly email turned into a sort of e-Memo and chat took communication by storm. Now people consider it normal to be bombarded with a string of 'electronic communique's. The fact that the line between chat and email is growing thin is proven by people who choose to carry on lengthy one-line-conversation chains over email.


To consider similar progression in an alternative technology, how about publishing and retrieval of online content? Online search and indexing services such as Yahoo and Google proved to be a boon. They helped us sift through the glut of information dumped onto the web as a result of years of indiscriminate publishing by people who finally found a medium to vent their 'creative' outbursts! Somehow, I always thought that search engines were invented out of the necessity to find signal in existing noise. However, they ended up becoming invitations to generate EVEN MORE noise. Armed with the knowledge that some web crawler will eventually index their site/blog/micro-app, the Web 2.0 community got busy building more-and-more 'information' into the web in the form of opinions, reviews, cross-blogs and flame wars!

As if that wasn't enough, Google gave us GMail! A direct invitation to actually CREATE a greater waste of resources. Just think of the volume of useless email still sitting around in your GMail account, just because Google gives you 2 GB of storage space. In this day and age of environmental preservation, I shudder as the sheer waste of resources- mail storage space, connected storage media, CPU cycles, electrical power, heat emanated by these devices, energy wasted on resulting cooling... and Google itself isn't far behind in the waste with it's ultimate redundancy matrix!

The following line pretty much sums it up.
Ease can also lead to callousness.
Harmanjit Singh @ Remains of the day

Seems like every day we're making it easier to waste some more.

Update 24-October-2007: Great! Another invitation to create greater waste!

]]>Saager Mhatre