Ugly truth about SimpleJdbcCall! Learnt the Hard way!

When I first picked up Spring framework, it felt like Magic. It does things which Struts does in ugly way! It made things look neat, and made an good impression for a first timer. Well it was like that and stayed for quite some time. But not all is fairytale, and we find it in hardest way possible!

When our company decided to stick with Stored Procedures even after explaining them about benefits in going with dynamic query, we had no choice but embrace the jdbcTemplate. Poor man’s ORM!! Picked up SimpleJdbcCall, added ParameterSource and execute, bam! it works. And we were all happy, we left it there and feel like done and dusted. But months after it’s over, the performance testing started. We use Oracle and they have nice and detailed report on what makes the application so slow! It wasn’t that slow, but for the kind of load we gave, it was slow. We tested with just over 100 concurrent users and run loop forever in JMeter, things started going south. Execution time, no of times, elapsed time all indicate one thing. A query is running in the background too often, which we can’t find anywhere in our code and SPs. Then after digging up SOF, we find that SimpleJdbcCall was the culprit.

Yes, SimpleJdbcCall like to query the metadata of the column details very often, so it sneaks past us and do it’s thing. So as mentioned everywhere, we had to add withoutProcedureColumnMetaDataAccess() for all SimpleJdbcCall objects. Pretty easy, right! Nope, not if you didn’t used declareParameters()! To save time, we skipped it at the initial phase of development, but it came back to haunt us. What irritated us most was, declareParameters expects the order to be same as we declare in Stored Procedures. Man, that is really fucked up. No shit! So we had to change them all to make it work and make the application perform better. After doing this up, the number of time the meta data query executes becomes less around 50%! But why does it expect the argument list to match?

So people, if you want to use SimpleJdbcCall, keep it in mind to do these things, so that you won’t regret using it later. Well, at least I didn’t have to change all the code and I pity the poor guy who did that! so beware of this ugly truth and act carefully.

Noob friendly Nodejs Hosting!! Heroku vs Open-Shift

Hosting an application which we developed in a new framework is as much exciting as well as challenge than using the framework. And what better way than giving a noob the easiest way to deploy the app? So, created the app, now it’s time for me to deploy. So I went ahead, typed “Free hosting for Nodejs” and as usual trusted Google gives me a lot, but less useful. Either some links/sites have changed, and rest point me to a couple of providers. Heroku and Openshift!

So my scale to measure the best one is simple, how hard it is for me to deploy my app! Took Heroku as a challenge and man, I must say they put a lot of restrictions for a small app, and deploying is a nightmare(at-least for me!). Digged through documentation, did exactly as they say and bam!!! It looks like there were no gears assigned to the app to scale. So as usual, digged some more and do as they say, bam! Not working. And getting MySQL is not easy as I thought.

After waiting patiently for a day, I dropped the idea and turned to Openshift. Installed rhc, cloned repo, made changes and committed. The moment I push I can see the logs on one hand and deployment process on the other. Errors were clear, Connecting to MySQL was pretty easy and I got my app up and running under 30 minutes. Well, that was quick! That’s what I thought! And what’s more surprising is, PHPMyAdmin installation is just easy too!

So what about them? To be clear, There was no pre-conceived notions about Heroku, but things could have been a lot simpler like how Openshift had! If they claim it is dev friendly, then it should be noob-dev friendly too! Let them add Gears, commit the app and bam! No missing dynos gimmick, and don’t expect developer to pay heed to such things. And for gods sake, don’t make installing Relational DBs a chore. It took me a while to figure out Heroku is not for me!

So I request Heroku to make the setting the instance a bit easier like OShift! This will go a long way!

Noob vs Nodejs ORMs(Caminte/Sequelize/node-orm2)

Well, as they say, once you use DB in your app, you will look for ORM! And it happened to me obviously. So what’s so special or different in this post? Well, nothing really. It’s just my perspective, a Java Dev’s perspective, on the ORM eco-system of Node.js. We, Java Guys, rely too much on ORMs. Be it Spring, Play or any framework for that matter, will come bundled with ORM! But not in Node.js. This was a big blow. When I chose Expressjs, I thought I don’t have to write plain DAO like codes anymore, but how wrong am I?

It’s not that writing plain SQL is harder, but it feels too much painful. Too painful, that I have to open a connection, execute statement, close it! Eew, Seriously? People still do that? Anyways, my search started. So like all, I got sucked up into Sequelize with their shiny new home page and all those jargon’s! It all went smooth. It was so smooth, I felt like I can relax now because at this rate I’ll finish the app much before I thought. But boy, Sequelize said NO!

See the thing is, I don’t want to dig SOF or any forums to know simple thing. It should be in the documentation. And when I try to insert inside another insert and it failed with no error, this is a big RED symbol. I debugged, and cried a lot, but no help. So there I am, sitting and crying at 1 AM! So with heavy heart, I decided to go with Caminte, after looking at another shiny page! Same old, Same old. So I thought why not open a Issue! Well, it wasn’t what I expected. No one replied. Well, with last release couple of months ago, and lot of open issues with no response, I decided to knock it off from list.

The bad thing is, Caminte looked like a serious contender in the ORM race. It had all I need, but not support. So while at work, I glanced upon node-orm2. No shiny page, just simple github template. But still I thought, why not? And to my surprise, it did the trick. With such minimal documentation, it just explained things clearly. No hiccups anywhere and debugging was a lot easier compared to those 2 guys! So what was this all about? Me, bitching about famous Nodejs ORM FW for fun? Nope. There are reasons why I am writing this at 2 am. If it ain’t work, then go for the once which work. And that’s what I did. I tried hard to use them, but either due to my sheer negligence or my noob-ishness might have cause some errors, but logs are supposed to be there to give exact error. It is how we fix them and move on. This got me thinking, how come such big popular ORM’s left out such major part? Or am I missing something? Whatever it is, I did the same with all 3 and node-orm2 performed to my expectation. Which means. this guy gets it!

  1. ORM frameworks ecosystem is matured, but not to the point where we can take them to any project as I do with likes of Hibernate!!
  2. Logging is the key! Don’t overdo the documentation. If logging is perfect to the sense, every single activity is logged, it will be lot easier to debug without any help. Rather than look up SOF for everything I prefer to do it this way.

These 2 points, I feel is rather very important. I mean, whats the use of giving OBD port, when I can’t get error codes to debug? So I suggest them to improve their logging mechanism, which is a boon rather than giving a whole lot of FAQs and tutorials and putting out answers in SOF! This isn’t healthy.

Well, I maybe wrong. Maybe JS Guys like it this way, but I don’t. And if something works for me out of the box,  nothing matters. Not even support. I stayed with JDK 6 until a year ago. Yes, that’s cold, but that’s how it works. So I wish, Caminte and Sequelize step up their game and bring some new features along with proper way to debug.

NOTE : This was my short term observation. Opinions may change, once I get hold of these FWs and this is not intended to berate anyone or any Entity(Pun intended!). This post gives you a brief of how noob friendly these FWs are! And for me, if a noob can do it in a short time, it tends to be a better one(Not applicable to all things!).

Why I chose Node.js for my hobby project?

If you know me, you can easily say I’m Java addict. I prefer to use Java wherever possible. But things change. JS MVC frameworks becomes hipster framework and I’ve already took a deep dive in AngularJS. After worked in AngularJS for past 5 months, I’m completely impressed with what they can do. Leaving all the bad things aside, it is a perfect RAD framework. If not for AngularJS, we wouldn’t have finished our project on time!

So it all started like that! So one day, my long term project, which is supposed to be my personal pet project, was started with Spring MVC + MySQL! It was left as it is because of me, not having enough time to spend it, and I’m incredibly lazy to write all those boilerplate codes! Anyways, fast forward to Feb, I decided to dust it off and start again. Since I’ve been studying/practicing Nodejs for more than a year, I thought I can give it a try. Well, whats wrong gonna happen and there is nothing to lose! So, meh!

It was nothing but simple yeoman like code generator for AngularJS!!(Don’t ask me why I want to do when it’s already there! It’s secret.) So I chose to go with Expressjs for it’s sheer simplicity in setting up and huge community support, better documentation. It was not more than a week and I’m almost at 50%! And I’m not even spending more than a hour a day! It was little tough at beginning, but once dice started rolling, things went smooth! I liked how the Nodejs community matured within such short time and npm is such a bad-ass! I’m not an pro in Nodejs and calling it THE BEST at this point will be over-doing it, but for now, it seems to best bet for all my pet projects, freelancing ones too! So the moment I put Angularjs with Nodejs, things never was this simpler.

But not all is well. Where it sucks is, when it comes to hosting the app.With PHP/Java, I will setup the server and get app running within an hour, but that’s not the case with Nodejs. It is just not noob-friendly. But once you understand the nuances and terminology, it just hits you right in the face.

So you might ask, what is this post about? It is about, things I liked/dis-liked in one the most touted buzz-word framework Node.js. So here for you!

Likes

  1. Ease of use and setup! Server configuration in local, just 2 secs! Yes, that easy.
  2. Huge community support. I mean huge. And Node.js have LTS now, which is a big relief when devs going in for critical applications where support is crucials.
  3. NPM! Enuff said. Nothing can beat this, not even close.
  4. Awesome plugins. Almost anything, you can find. Never have I felt so relaxed in my 7 years of developer life. Before doing something, I just check npm to see if a plugin already exists and so far it is the case!
  5. Simple, modular code structure.
  6. Very very very very less, learning curve.

Dis-likes

  1. Few plugins I want to use, is either not maintained properly or author simply left it there hanging. I can see many such one, with lot of PRs hanging around. I mean, I’m little concerned about using it. What if something breaks after some time, who I’m gonna ask for help?
  2. Infrastructure is big PITA! This thing is harder than setting up J2EE Server! This coming from Java guy. I mean, yes, heroku is great, but not as great as I thought. If a noob cant configure it, then it is indeed not great. It needs proper, setup guide for noob like us.
  3. Callback! Yeah I know it sounds dumb, because I know there was callback, but this is serious. For first few weeks, it’s fine. No, it’s great. But when code base is expanding, things get real ugly. But there are ways but still, I wish Node.js could have come up with some slick one instead of fat one!(Don’t tell me promise!)

So, it’s not bad at all as people claim. If planned and written properly, with some research on whether it suits you, this can be the best RAD framework, be it your pet project or anything.

 

Things I learned from IE9!(Still learning!)

What motivated me to write this post? Simple, huge amount of time I spent sitting in front of the PC and stare at screen and think “Why it isn’t working in IE9!“. And after lot of fiddling/wrestling with tags, I feel like “You kidding! Is this even fix? WTF!!!!!“. So, this is what made me do this.

So as I said, this post is all about Things I learned while making some site(s) work in IE9(Don’t ask me why IE9, it’s not like I love to, it is more like I had to. Duh!)

1. It isn’t just a browser. It is much more than that! I used to be so distracted, short-tempered and anger issues. But IE9 has made me a calm, zen like person. Yes, one minute you think you fixed everything. And once you add a tiny plugin in to your page, all hell break loose and you need to think like a child to fix it. Yes, remove from here, add here, remove this and add that! Oof! It’s working. But you must put an Note in your code to warn other devs not to add a plugin or anything of sort, else you are again going into medication.

2. It is strict. I mean real strict! More than your mom or your girlfriend. In fact, much stricter than strictest of the girlfriend! You make slightest of mistake in JS, other browsers just ignore it like your best friend, but not IE9! You missed a dot here, you missed something here. No excuses. If it had to be done, it has to be. It teaches you how to follow protocols and follow industry standards!

3. It is more of 90s kid, who yell at new kids on how they are ruined with the gadgets. In fact the founder of the gadgets(Ajax! Remember?) is none other than very own IE9! It sometimes struggles to understand what you are trying to send over Ajax! Are you trying to send a object with number, you convert it as string before sending it! When I see this, all I can imagine is, they forget to keep the Ajax documentation, so after a while, someone else wrote the documentation, which is not exactly what it is supposed to be. Weird! It teaches you to back up your documentation before you release your product.

4. It isn’t very fond of CSS. Oh! You meant rough edge, let’s give you nice clean edge! While other guys merrily decipher newer plugins, IE9, who is not much educated struggled to do things like their Yale/Harvard(I know, don’t ask!) competitors! So you have to tell exact steps and some time, you have to feed it in mouth so that it’ll understand! Which teaches us to always write your own, handmade CSS exclusively for IE9, and test them. If not, then don’t get shocked when your site got scrmbled in IE9 when you give demo to the client. Which taught me the valuable lesson of keeping seperate files for the task, even if it’s not the norm.

5. Even the most experienced can look like jack-ass while debugging in IE9. Because most of the time, debugging sucks and gives inappropriate messages like a most shitty stalker send filthy messages to a girl. Or the best, most of the time, it just hangs or won’t work! Which gives us the valuable lesson of always be content and polite, even if you are experienced. Because one bug in IE9, you are his bitch!

And a lot more are there, but seriously I don’t wanna give all the spoilers and rob the fun for you. Enjoy your time with IE9.

ie9-internet

Is AngularJS(1.x) ready for Enterprise Application Development?

Before I start, I know that we have tons and tons of posts on this topic, but this was based purely on my experience.

It all started with our new project kick start phase, where AngularJS was suggested out of blue to speed up the development due to the tight deadlines. I’m a J2EE guy, and I’m a not a big fan of JS Framework, but ever since words like Backbone.js, Node.js got around the web, it always fascinated me. Whenever a new one comes in the market, I will be start exploring the tech and get excited for couple of months, before the mainstream development get me involved! But this move, looked like I finally get a chance to use cutting edge, buzz word technology in a project at my workplace. Yay! This should be fun.

So the first few weeks has been excited, and I’m very eager to get the prototype up and running to showcase the team, that AngularJS is the right candidate for this project. The base code which we created for the project was so smooth, we felt that we can REALLY speed up the development, because it was so easy, where we spend 100s of lines of code, AngularJS did it in much fewer and simple way! But that excitement didn’t stay long with me.

Before I get any further, this is not another AngularJS Bashing post, but rather a post to clear the mythical air that surround the front-end JS MVC framework. Let me get into the topic.

  1. Documentation : Most part of the development time was spent trying to understand how certain things worked. Because when I try to find them in official documentation, it isn’t there. For a guy like me, who read official documentation for all my doubts in a framework, this was a big blow. The documentation to getting started with was good, but once you are past that honeymoon period, it will be a tough time to find and understand certain aspects. I strongly feel official documentation should be the main place to dig anything and find solution, or learn a framework. Not in some forums. Infact, SFO helped me a lot with AngularJS than the official documentation!
  2. Learning Curve : One funny thing I noticed about AngularJS was, as much easier as it is to learn the basic, it will get tougher when you get going. I’ve done some learning curve graph for easy understanding.ang-learn-curveIt was exactly what happened. Initial excitement levels gave confidence that we can achieve anything but as we are into middle of the project, things get tough and it becomes a swirl-wind about to destroy the city! But after a lot of digging, it get’s down but after certain point of time, it feels like a landmine hidden somewhere safe, but we don’t know where it is. It is mainly attributed to my first point about Documentation. If it was any easier, it could have saved us a lot of time!
  3. Performance : Hey, I am not complaining, but it isn’t what we believed. Since it is an JS framework, things get uglier if we can’t look under the hood(code!). It’s a like a kid left unnoticed with dangerous toys! Hello world can be snappy but when the code base gets big, headache gets bigger! Of course, it is a developer’s responsibility to make sure to tune up the performance, but kind of added more work for us. As a J2EE guy, we were more into server side tweaking and even after bringing skinny data to client side, it took ages to render them! Why, because bloody watchers infested all over the page. Then it hit us, that now we are not only going to tweak server, but the front end tools too! It took us a while to figure out, but in the end we figured out stuff and moved on.
  4. Browser Rendering Engine : Before this, all we cared about was not how our app will perform in different browsers, because all the stuff will happen at back-end. But now, we need to be cautious about this. It adds one more layer of work. In fact, plain Vanilla AngularJS performed just fine, but with all added plugins and modules, it is pretty tough to make it work across all browsers. It is mainly attributed to the fact that we are newbie at JS framework, but still we never thought of this, because we never had this issue before. Although this might sound silly for many, but when it comes to Enterprise Development, things aren’t as glamorous as it’s with other industry. Client browser restrictions, extreme pressure, unnatural deadlines were just a recipe for stress, and this will put more pressure to already squeezed developers!

Conclusion :

All the points I’ve mentioned are just a few to go with, but in the end, instead of speeding up the development, it did slowed us done after the initial surge. Th main reasons were

  1. Lack of proper R&D. If it’s new and shiny, just pick it up mentality was the big mistake. It would’ve saved us hell a lot of time.
  2. Poor documentation should’ve have been taken into consideration.
  3. People’s general belief. If it’s front-end JS framework, work should be done fast. This is what made some guys go with this new techs, but in the end, without proper understanding about the underlying technology, it is quite opposite.

And there are lot more to say, but I feel you get what I am about to say. If you want to use something, take your sweet time to understand the in and out of the framework before you start churning 100s of lines of code. And if you are seriously tight on deadline, please don’t go with this new shiny thing. Because it can backfire you, if you don’t have the skill and the person.

Finally, after looking at AngularJS 2.0, I am quite confident that it can solve a lot of issues of v1 and the documentation looks a lot better. It sounds quite exciting(see, again I fell for this!) and I hope it will help a lot in enterprise application development.

Thanks for reading!

 

What is Grails. Why should a Spring developer use it?

When I first heard about Grails, I thought Rails finally visit Java. I like Groovy, as it is quite easy for me to pick up and an framework based on it will be fun. That’s what I thought. Does things look good? Will it worth your time to shift? Let’s see.

I never really had a chance to use Grails up until last year, for my pet project. Which I longingly desired to change it from very old Spring version to something new. It was done around 2008, without any annotations.

First thing you easily notice is, when you start with Grails, you get excited. Yes, configuration is none. Which as a Spring developer, I find a good one. Next, scaffolding. I had few CRUD part which I don’t need to do with Grails, which is again good thing, All I have to do is, create domain class, create controller, map them and slap them. Bam! CRUD page is ready! And gsp is sight for sore eyes, if you have only worked with JSP till today(which I heavily doubt apart from people who always stay in maintenance work). As I stopped working in JSP long ago, gsp never impressed me. But still much better than JSP, and it looks much similar to some template engines available for Node.js. And most important thing is, it sure reduced lot of boilerplate code. Even if I don’t use scaffolding, LoC is greatly reduced compared to Spring counterpart. That is something to be considered.

After initial phase of Wow, and Oooh is over, you have to face the fact. I wanted to use JPA as I wanna give it a try and see if it really get along with Grails,. Boy, it wasn’t as easy as I thought it would be. I had to do a lot of hoopla and dropped the idea, as it was taking much more time than I expected. Not worth the time, as it is for my pet project. GORM is decent enough, well, at least for me.

Now, for worst part, speed is awful. I know, but for dev, productivity is important and every time I make changes in Java, it hot-reloads and at same time, system started slowing down. At certain point, it feels like slideshow. So I had to kill few processes to get it back to life.

Plugins : Yes, there are plugins. Lots of plugins!! You want to do X, chances are you already have X plugin. Certain things were made real easy, which makes me cry in joy! But by looking at source/issues you can see, even most popular one’s are discarded by it’s author. Yeah, it is open source and we can do whatever we want, but honestly, that’s not something we want. As much as I love to work in OSS, making it work for our requirement is again an development hurdle in my opinion.

So, what the hell am I thinking? If it matters for you, I pretty much like Grails, and as a Spring developer, it is quite an interesting journey. But do I consider using it in my existing project? I don’t know. It is not worth it. May be if something new and small comes in my way, I might give it a try. Next time, I use it for some real small project and blog here, on how it went?