During a recent manipulation to delete elements of WxPython's ListControl object, the application gave the following strange error as a pop up:
Could not retrieve information about list control item #Number
The number was always the last element of the list control.
The list control wiki also does not explains this issue.
This question was discussed before, but was wrongly asked.
The error is actually in finding the last element of the list control; asthe self.logwin.GetItemCount() results in an error. The last correct element is actually at self.logwin.GetItemCount()-1
Hopefully this solves the problems of others who stumble upon here.
Tuesday, January 31, 2012
Monday, January 30, 2012
Introduction towards using Ruby enVironment Manager
As I have been using RVM for quite a while during recent times, I felt it was necessary to give a quick introduction of it.
Similar to bundler, the dependency management tool, this sort of has become the de-facto method of setting up development environment in the ruby community.
Basically , this is a bundler for the entire ruby platform, or the ruby application stack. By using this, at a given project, we can specify the version of ruby that application runs upon (yes, even its different ports like jruby and ironruby) and its different gems.
To install, it is recommended that you install from the default location as mentioned from the website itself as the bleeding edge projects tend to migrate and change their locations quite often.
After a single step installation and setup, you can perform different steps, some of which are :
Installation of platforms
rvm install
for eg : rvm install ruby-1.9.3
This will install the given version of ruby platform by fetching its source tarball into your .rvm/archives folder at home location and build that ruby from source
Testing of all platforms managed by rvm
rvm do ruby [filename.rb]
This will run the ruby command on all installed
Selection of an installed platform
rvm use
for eg : rvm use 1.8.7
This searches for an appropriate version of ruby and specifies steps for installation of that version if it is not present in the rvm.
Gemsets
In line with the compartmentalization introduced at platform level, rvm also provides the same at gem level. We can create different 'schemes' containing specified gems of specific version.
The gemsets are namespaces having different combinations of gems. This solves a lot of headache from developers as newer versions can be tried without compromising on stability of existing systems.
Creating gemsets
rvm gemset create
This creates different gemsets which are used in the following manner :
rvm @[gemsetname]
This sets our current gemset and now we can install any gems that we like using the gem install -v version gemname here.
The version@gemset name is unique and will have these configurations saved.
Using gemsets
After the creation you can load a gemset configuration through:
rvm use version@gemset
rvm use gemset
There are host of other options that we may use, but these are enough to get started (as in git, where the necessary commands are a breeze once we understand its intent). Since I am currently working on only hobby projects based on ruby, I have not used rvm's advanced topics yet. I would update here as I come across other exciting facets of this technology.
Similar to bundler, the dependency management tool, this sort of has become the de-facto method of setting up development environment in the ruby community.
Basically , this is a bundler for the entire ruby platform, or the ruby application stack. By using this, at a given project, we can specify the version of ruby that application runs upon (yes, even its different ports like jruby and ironruby) and its different gems.
To install, it is recommended that you install from the default location as mentioned from the website itself as the bleeding edge projects tend to migrate and change their locations quite often.
After a single step installation and setup, you can perform different steps, some of which are :
Installation of platforms
rvm install
for eg : rvm install ruby-1.9.3
This will install the given version of ruby platform by fetching its source tarball into your .rvm/archives folder at home location and build that ruby from source
Testing of all platforms managed by rvm
rvm do ruby [filename.rb]
This will run the ruby command on all installed
Selection of an installed platform
rvm use
for eg : rvm use 1.8.7
This searches for an appropriate version of ruby and specifies steps for installation of that version if it is not present in the rvm.
Gemsets
In line with the compartmentalization introduced at platform level, rvm also provides the same at gem level. We can create different 'schemes' containing specified gems of specific version.
The gemsets are namespaces having different combinations of gems. This solves a lot of headache from developers as newer versions can be tried without compromising on stability of existing systems.
Creating gemsets
rvm gemset create
This creates different gemsets which are used in the following manner :
rvm @[gemsetname]
This sets our current gemset and now we can install any gems that we like using the gem install -v version gemname here.
The version@gemset name is unique and will have these configurations saved.
Using gemsets
After the creation you can load a gemset configuration through:
rvm use version@gemset
rvm use gemset
There are host of other options that we may use, but these are enough to get started (as in git, where the necessary commands are a breeze once we understand its intent). Since I am currently working on only hobby projects based on ruby, I have not used rvm's advanced topics yet. I would update here as I come across other exciting facets of this technology.
Tuesday, January 10, 2012
Experiences as a software engineer
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.
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, 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.
Subscribe to:
Posts (Atom)