I will soon be completing my first year working as a software engineer. An year ago, I was an eager college student and was dabbling in open source stuff heavily to make up of the extra time that I had spent in college. I had the prerequisite knowledge to be a developer even before college, but in India, you are worthless if you do not have anything on paper, but are deemed to be knowledgeable if having degrees and certifications.
To start off with, I consider myself lucky to be in my present job, last year during my fifth semester, a trip to various local companies to 'test the waters' proved out to be an opportunity in disguise. I was interviewed and then selected without much fanfare. During the first day as an intern(my last semester involved industrial training) I jumped headfirst into connection pooling using spring, which was required here and there was no looking back (In direct contrast to people working in multinationals, who with much fanfare start their training - but later migrate to management as growth as a developer is restricted).
Among other things, I was having a java and ruby background and was started as a java developer. One of the perks of being in a product company is you have time and opportunity to try out, learn and explore new stuff all while doing your job.
After working considerably in the RnD over product development, I was put to test in scaling web scraping applications, porting of our product in .net platform and creating a keyboard/mouse capture application for assembling a test management mashup during the course of the previous year. Although I miss web applications a wee bit, the middleware and logic is what keeps me busy. On a parallel basis, I am into lot of books involving me to be a better developer. The Clean Coder, The passionate programmer,
With regards to updating my blog with the new stuff once every month, I learnt and made some interesting excercises during my free time, but paucity of time as well as my frequent forays in dzone and other knowledge portals led to cancellation of various blog posts. I am thinking of reverting to small posts providing a high level overview of technology practices that I consider important in current scenario instead of writing tutorial like posts.
Am having quite a few of these items in my mind, and will post them as the time allows.
Tuesday, January 10, 2012
Tuesday, November 29, 2011
Aplying Domain Driven Design
One of the common mistakes in constructing software that is sub-par with requirements is the lack of understanding of the domain in which it is to be operated. This fallout or mis-communication is perpetrated evidently by usage of different types of languages between the developers and domain experts (abstracted for the sake of simplicity) Evaluation of failures have enabled us to realize that underestimation of domain can lead into perils in project understanding. One of popular example occurs when you try to apply simple CRUD generators into, say something like medical instrumentation. Your productivity falls and you end up hitting a wall. This is evident as the technology is just the enabler, and not the end to means. I have learnt this the hard way in one of my recent project where over engineering and legacy code forced us to create entity framework configuration files via a self-created generator instead of the inbuilt edmx designer - an example of relying on reverse engineering over traditional process.
However, many software solutions which are designed with their domain in mind are essentially an object-oriented model expressed in terms of their domain, at its core. The domain, rather than data-oriented entities constitute this and it compasses the domain wisdom (logic, data, rules, terminology) expressed in simple and utilizable manner. One of the tangible benefits of utilizing this approach is that this increases the longevity of code as domain outlives its implementation. Moreover, this can be modularized into reusable components and mashed-up as the needs arise.
But to start off with, in existing applications, we can use metadata such as annotations or attributes to 'beautify' our code through using the domain logic without undergoing any unnecessary plumbing in the existing application architecture/stack. Another benefit from using them is that in java or c# multiple inheritance is not possible, but this can exist in the domain.
One thing that most domain-oriented tools tend to do is interface their data/stack through xml, which might be fine for domain experts, but is pain to maintain (think of all the xml documents for business rules and instances).
Thus domain annotations provide a starting point of integrating domain knowledge into our code, making it more reasonable. Other approaches include use of full fledged frameworks like naked objects that are geared for these tasks and like rails, play or asp.net mvc frameworks, can quickly generate abstract applications quickly.
However, many software solutions which are designed with their domain in mind are essentially an object-oriented model expressed in terms of their domain, at its core. The domain, rather than data-oriented entities constitute this and it compasses the domain wisdom (logic, data, rules, terminology) expressed in simple and utilizable manner. One of the tangible benefits of utilizing this approach is that this increases the longevity of code as domain outlives its implementation. Moreover, this can be modularized into reusable components and mashed-up as the needs arise.
But to start off with, in existing applications, we can use metadata such as annotations or attributes to 'beautify' our code through using the domain logic without undergoing any unnecessary plumbing in the existing application architecture/stack. Another benefit from using them is that in java or c# multiple inheritance is not possible, but this can exist in the domain.
One thing that most domain-oriented tools tend to do is interface their data/stack through xml, which might be fine for domain experts, but is pain to maintain (think of all the xml documents for business rules and instances).
Thus domain annotations provide a starting point of integrating domain knowledge into our code, making it more reasonable. Other approaches include use of full fledged frameworks like naked objects that are geared for these tasks and like rails, play or asp.net mvc frameworks, can quickly generate abstract applications quickly.
Tuesday, September 20, 2011
Play Framework Cookbook :book review
Play Framework Cookbook
Author : Alexander Reelsen
Play framework is an upcoming framework that comes in the growing breed of rapid application development, using convention over configuration based web application development.
The thing that sets apart this framework apart from others is the customizability of the framework in the jvm, while taking advantage of either java or scala as desired. However, owing to the late arrival of play, there has been a lack of tutorials and documentation in order to solve real world problems with this framework.
This book, being a cookbook covers the topics, head-on and gives practical insight into building web application while covering loads of practical topics, from installation to deployment.
The book has been divided into 7 chapters and a small appendix. The first chapter covers the basics and is good for those coming without rails experience. However, the chapter also presents recepies for customizing all parts of the framework- pretty much everything that other technology cookbooks pack into themselves from cover to cover. The middle chapters dig deeper into the framework and integration with external services. One thing that is special in this cookbook is it devotes 3 chapters to modules as extensibility via modules is one of the main differentiating factor that play framework offers. In line with practicality, the book devotes its last chapter totally on deployment and release functions. This does omits the cloud vendors that provide paas for play framework directly, but as a lot of cloud offerings for play are unfinalized, they do not find any mention. The appendix is a disappointment as there are no pointers for carrying out further. As with any upcoming technology, it is imperative to look out for more resources in order to update and correct ourselves with its ecosystem. This is especially important as play 2.0 would be out on beta by the end of this year and a reader always expects pragmatism from a hands-on cookbook. Also, due to the flexibility of this framework, various PAAS vendors are providing, or planning to provide play support, which deserves at least a listing of these services. The author clearly states his intention behind leaving scala based applications in play, and this hopefully might make its way in future editions.
Overall, this is a book that lives well up to its expectations on providing us with something apart from the documented portions and the stock examples supplied with the play distribution while providing insights into the activities covered and making them flexible enough to be used practically.
For anyone learning play framework and looking to go beyond the examples for making interesting and practical applications, I’d heartily recommend this book.
Wednesday, August 24, 2011
Up Next : Book review on Play framework
Today I received a copy of the book, 'Play Framework Cookbook' by Alexander Reelsen, courtesy its publisher, Packt Publications.
As the name suggests, it covers various recipes regarding the play framework, which is a promising rapid application development framework in java/scala platform.
This is the first instance of any good documentation of this upcoming framework for professionals and looks promising. I will be going over this book for the next few days and would be posting my views about it, stay tuned!
This is the first instance of any good documentation of this upcoming framework for professionals and looks promising. I will be going over this book for the next few days and would be posting my views about it, stay tuned!
Friday, August 5, 2011
Need Concurrency ? LMAX to rescue!
In praise of LMAX.
Recently, on the martin fowler's blog, I came across an interesting architecture, LMAX which was used by in a financial application to run over 6 Million transaction simultaneously, over a single thread of execution only!
Even if this architecture is limited to finance domain, it makes up for an excellent solution for dealing with concurrency. With its single point of handling of the business logic processing there might seem a potential bottleneck, but is negated via alternative mechanisms to recreate this controller - Event Sourcing.
The concept of in-memory solution for performance is not new, but having concurrency without the taxing side effects of transactions is indeed interesting.
I'll be doing some more study through it during this weekend, and update here if necessary.
Links :
- Found reference from Martin Fowler's blog : http://martinfowler.com/articles/lmax.html
- One implementation of LMAX (Disruptor): http://code.google.com/p/disruptor/
- Disruptor's technical paper that gives an excellent overview : http://disruptor.googlecode.com/files/Disruptor-1.0.pdf
Subscribe to:
Posts (Atom)