Logo

Who is talking?

Archive

mongodb with Rails 3

almost 7 years ago | Gourav Tiwari: easy_software = Agile.find(ruby_on_rails)

Few days back, I did introspection and thought, as a developer:How many languages I know?How many databases I have worked with?Which frameworks I am comfortable working with?Do I know the latest technologies in my field?I then realized that working on PHP 4, PHP 5, Ruby 1.8.6 doesn't mean that I know the latest cutting edge technologies. I should try learning may be Ruby 1.9.2, or may be a new language. I have worked with MySQL, Oracle, but what's new? I should try working with some other database, may be Mongodb. I did work on Drupal 4.7.x, 5.7.x and also on Rails 2.0.x to 2.3.x, but may be I should try Rails 3.Then I downloaded Ruby 1.9.2, with pik, so I can continue work on the project work(ruby 1.8.6), as well as try out rails 3. Needless to say Rails 3.x is far better than it's predecessor Rails 2.x. bundler  is just awesome! But I was so used to use ActiveRecord (with mysql and oracle), I was not able to think how would I work without it on a Rails project. I first tried mongodb online (Try it out section) and felt it different, but complete. Whatever basic operations you can perform in mysql/oracle, you can do it in that tutorial.I installed Rails 3.0.3 without ActiveRecord and installed mongodb to give it a try. It is really different and it amazes you by the fact that how easy to use it with rails. ActiveRecord syntax will not work, but mongo mapper has it's own syntax. In two-three hours I had my basic application with Rails 3 and mongodb on windows7 machine up and running (including learning curve and thanks to mongodb and mongo mapper asciicast and Ryan Bates for nifty_generators)Once I was done with my rails3-mongodb test application, I realized that MySQL and Oracle are not end of the world. There are better and different things that I should learn. It is much faster to install and configure Ruby 1.9.2 + mongodb + rails 3 and get the application up and running as compared to Ruby 1.9.2 + MySQL/OracleXE (10g) + rails 3 from scratch.I would love to hear comments/similar experiences :)

mongodb with Rails 3

almost 7 years ago | Gourav Tiwari: easy_software = Agile.find(ruby_on_rails)

Few days back, I did introspection and thought, as a developer:How many languages I know?How many databases I have worked with?Which frameworks I am comfortable working with?Do I know the latest technologies in my field?I then realized that working on PHP 4, PHP 5, Ruby 1.8.6 doesn't mean that I know the latest cutting edge technologies. I should try learning may be Ruby 1.9.2, or may be a new language. I have worked with MySQL, Oracle, but what's new? I should try working with some other database, may be Mongodb. I did work on Drupal 4.7.x, 5.7.x and also on Rails 2.0.x to 2.3.x, but may be I should try Rails 3.Then I downloaded Ruby 1.9.2, with pik, so I can continue work on the project work(ruby 1.8.6), as well as try out rails 3. Needless to say Rails 3.x is far better than it's predecessor Rails 2.x. bundler  is just awesome! But I was so used to use ActiveRecord (with mysql and oracle), I was not able to think how would I work without it on a Rails project. I first tried mongodb online (Try it out section) and felt it different, but complete. Whatever basic operations you can perform in mysql/oracle, you can do it in that tutorial.I installed Rails 3.0.3 without ActiveRecord and installed mongodb to give it a try. It is really different and it amazes you by the fact that how easy to use it with rails. ActiveRecord syntax will not work, but mongo mapper has it's own syntax. In two-three hours I had my basic application with Rails 3 and mongodb on windows7 machine up and running (including learning curve and thanks to mongodb and mongo mapper asciicast and Ryan Bates for nifty_generators)Once I was done with my rails3-mongodb test application, I realized that MySQL and Oracle are not end of the world. There are better and different things that I should learn. It is much faster to install and configure Ruby 1.9.2 + mongodb + rails 3 and get the application up and running as compared to Ruby 1.9.2 + MySQL/OracleXE (10g) + rails 3 from scratch.I would love to hear comments/similar experiences :)

The Client Questionaire

almost 7 years ago | Joe Pettersson: JoePettersson.com

Getting the most out of that first client meeting is incredibly important. Finding and isolating the core issues quickly can mean a final product that meets and exceeds all of a clients expectations. In this post, I have included a … Continue reading →

CAPTCHAs and the Fake Security

almost 7 years ago | Eduard Moldovan: eduardmoldovan.com - tech

We all use CAPTCHAs all the time, almost every day. For an average user, even its name is scaring, not to mention its functionality. Even I, as developer and a heavy internet user, did not register on many sites, because they used bad CAPTCHAs. In this article, I shall talk a bit about CAPTCHAs, their fake security and alternatives.

EPL Fantasy Football: Best overall, home and away teams

almost 7 years ago | Prasoon Sharma: Enterprise Software Doesn't Have to Suck

I've refined the R code to pick the best fantasy soccer team by using more granular player performance data (available publicly). Here are the best overall, home and away teams.  The constraints used are:  1) Number of goalkeepers = 12) Number of defenders = 43) Number of mid fielders = 34) Number of strikers = 35) Total team cost = 50 GBP6) Maximum number of players from a team = 2 (most fantasy soccer sites use this)

Dynamically added fields using ajax do not get posted on form submission (FORM inside TABLE)

almost 7 years ago | Sanjeev Mishra: Sanjeev Mishra's Blog

This is a problem which is actually not a problem if we are following right semantics of HTML. Problem: I faced this problem where in after a page is loaded I have to add certain input html elements in the form (which I had inside a table) using ajax. Only the elements that were loaded […]

Building High Performance Team

almost 7 years ago | Gourav Tiwari: easy_software = Agile.find(ruby_on_rails)

‘High Performance Team’, a phrase that one always dreams to be a part of some day.  A team that inspires other teams to achieve what they would generally consider way above their potential. A team, where there is no place for finger pointing, rut and panic(even in crucial times). I am working in a team which is high performing and I would like to uncover the challenges we faced and how we overcome those as a team.We never thought that one day we will be a successful and high performing team nor did it happen overnight. We faced the moments of finger pointing, failures, boredom and heated discussions during the initial phase. We slowly made use of continuous ‘retrospection’ from ‘Scrum’, which helped a lot. We found that retrospection never hurts, even if you don’t have any failure since last retrospection, you may find better ways of doing the same thing. We saw that rhythm is important, as repetition reduces complexity. So, we tried continuous improvement in everything, be it very small discussion, a big deployment or regular review meeting with product owners and sponsors. Soon, we found our key mantra, ‘rhythm’ and we stick to it.Challenges:I believe most of the teams face these challenges, but since our team was very small(one developer, one hands-on architect and one product owner) and our sprints were small (one week), these became crucial for various reasons:    * Begin meetings on schedule: Since we have meetings with different groups and most of the times they are back to back, it became crucial to join meeting on time.    * Meetings, never end on time: This costs a lot if you have small development cycle, if meetings go beyond their scheduled time, you have to back fill the development hours, may be sometimes by staying late and sometimes working over the weekend to avoid delayed deliveries.    * Distractions from the agenda: This one is real killer and one of the real cause of the previous challenge. It happened very often in our team, until we found solution for this.    * No more boring stories (tasks): How would you feel if you are given to write automated functional test cases for more than 50 combinative scenarios in a sprint?    * New Ideas/innovation: Every team feels that it should innovate something or implement new ideas, that no one around have thought about (which in turn brings confidence and enthusiasm)    * Effective retrospection: Every Scrum project team does the retrospection, but how can we do it in a better way was a big challenge, as we did not want to do it as a ritual which will die in few days.    * Avoid panicking in crucial times: I admit, no one can avoid panicking in a production failure, but we all know it will not help either. The challenge was to learn how to avoid panic in crucial moments and keep the calm hat on, so that team can find right solution in instead of a quick and dirty solution.    * Why failures in QA instead of development environment?: No matter how much we test some issues come-up in QA instead of development, which is a big challenge for any team.    * Demanding stakeholders do not agree for automation testing: It was always challenging to convince sponsors for automated unit/functional/integration testing. Their question was dead straight, “Why would I spend my money on something which is not a must have feature in my product?”Approach to solve these challenges:It all started with retrospection and I love saying that retrospection is the best process Scrum has come-up with. It is a forum to brainstorm, rather than asking questions like, why you have done that crap, why you did not build the right code? Who love such questions? I don’t and I don’t think anybody would love it. There are better ways to do the retrospection and I think our team came-up with the right approach.    * Effective retrospection:      We all do the retrospection in Scrum projects, sometimes every sprint, sometimes on ad-hoc basis. We were doing retrospection, but in three to four weeks, it became boring, we were not getting benefit of the retrospection. Then we tried new approach, we started maintaining ‘retrospection-backlog’. We took ownership of say two items per person per sprint. Until the team agree, that we have worked on those items, we do not close (or mark as done) those items in the backlog. Also, we made those items appear in the stand-up, as whether we have acted on those items or not. Now, we are not addressing them at the end of the sprint, but we were addressing them daily. Result? We close many items in the backlog and suddenly it is working for us. There are many of the retrospection items I have listed in this paper, one I liked most, “Cutting corners never help in a big picture. Shortcuts work for few days, but you have to pay it’s cost in a longer run”.    * Begin meetings on schedule:      A big challenge, I feel it is very easy to say, that we begin on time, but difficult to follow. We spoke in our retrospective and decided to maintain a backlog on our own, and whoever is late (more than two minutes) three times should give a treat to the team or bring snacks items (we maintain a snacks corner in our team room) or bring small logical game (we have a game zone too!). It really worked!    * Meetings, never end on time:      Another challenge and another retrospective was waiting for it. One of us volunteered to do time checks in meeting, so that participants talk precisely what is important and it helped to finish meetings on time.    * Distractions from the meeting:      This one was one of the root cause of previous challenge and we came up with parking lot idea. It is really helpful, if you see someone is distracting the discussion and one of us would raise a hand, which means: ‘Focus!’.    * No more boring stories (tasks):      This happened with me, when I was asked to write automated functional test cases for more than 50 combinatorial scenarios in a sprint. It is boring to the death at the same time you have to keep reminding yourself that you are not missing any crucial scenario, otherwise needless to say your efforts are waste. I discussed with my product owner and we came-up with a mutually exclusive and collectively exhaustive(MECE) list of scenarios on ‘matrix based problem solving’ approach. It was new for me and in less than one hour we discussed only important scenarios and implemented them, which kept the problem interesting at the same time it helped us to achieve the goal.    * New Ideas/innovation:      We as a team would like to try out different things, but the pressure of development work never let us do ideas, which we wanted to try-out (for example unit testing of javascript code). We made a retrospective item that as a team we will spend some time to try-out new things, sync-up with the new technologies/we trends. The ‘so what’ for our product owner was, better solution will come upfront when the team, a) learn new things and b) share the ideas/innovations with broader groups. Since we added this as a retrospection item and even product owner voted on that, we found no excuses and started implementing new ideas. Another idea we came-up with was to have backlog for ‘Most Teamish Room goal’ and the acceptance criteria was, if anyone stop by, ‘wow!’ should be the first expression/reaction.    * Books are best friends, how can they help my team?:      Building a team with collaboration and learning, Do it yourself, workaholics is killer, good enough is fine, pick a fight and how to say you’re sorry, are few of the principles I have learnt from few books I have read. Books not only guide you, but more importantly they keep hammering the concepts, so that you are bound to find a better way of doing the same thing.    * Avoid panicking in crucial times:      It happened when ‘we’ as a team tasted failure first time. Again, retrospection came to rescue us. Once we got over the failure, we did the retrospection from a distance (after a week) and found that instead of panicking, it was our cool mind, which helped us. We were very tempted to go with quick and dirty solution, but we waited and thought, ‘Is this the right solution for the long term?’. It helped and this approach became our habit. The key is to, ‘never lose the calmness, never in a crucial situation’.    * Why failures in QA instead of development environment?:      We happened to see failures in QA, even when developers do their part of testing in development environment. In our retrospection we brought this and came-up with, ‘Team testing time with freinds’. So, we called few friends who were neither part of development team nor part of sponsors’ group. This strategy worked and we started catching issue in development environment.    * Demanding sponsors do not agree for automation testing      We find it difficult to convince sponsors for tech debt or automated testing stories. One of the retrospection item was to present a Scrum factoid at the end of the sprint review meeting, to help sponsors understand the Scrum more. It worked like a charm. More we involved sponsors (though they hesitated initially), more it became easier to convince to them what development team wanted to try to improve the code quality(and obviously to improve the product).Benefits:With the challenges we faced, we uncovered a lot many solutions for variety of problems. Be it technical problem or a process issue, we decided not to be caught up in a rut of work. The benefits were many folded.Joy of work and flow of energy: Most importantly team was enjoying the work. No task or deadline pushed us to do something, everything was in flow.Confidence of stakeholders: We won the confidence of the sponsors and product owners.Software Craftsmanship: We implemented our own ideas (software craftsmanship), which boosted morale and confidence of the team.No more ‘staying late’ nightmaresRetrospect everything: Retrospectives made life much easy. Nothing fell of the cracks, as we were doing retrospection every week.Celebrations: Team had a lot to celebrate; their innovation, problem solving approach and knowledge sharing with other teams. Best practices became part of the team activities.In all it became a win-win situation for everyone.I feel that every team can become a ‘High Performing Team’. It only takes small efforts every sprint, but in a longer run, you will find yourself out of those nightmares of teams with lack of energy, lack of vision and above all lack of self confidence. Retrospection is the best tool Scrum has given and each team will get benefit, if it is used. Finally, if you have the idea implement it, because, world needs execution of ideas (I think I read it in some book, ‘no one likes the idea guy!’).I would like to thank my team members, with whom I lived this experience. Also to thank my colleagues and my seniors to inspire me to learn and achieve, they are not directly involved in project activities directly, but always helped with their continuous feedback.References:   1. Rework - http://37signals.com/rework/   2. Beautiful Teams -Inspiring and Cautionary Tales from Veteran Team Leaders http://oreilly.com/catalog/9780596518028

Building High Performance Team

almost 7 years ago | Gourav Tiwari: easy_software = Agile.find(ruby_on_rails)

‘High Performance Team’, a phrase that one always dreams to be a part of some day.  A team that inspires other teams to achieve what they would generally consider way above their potential. A team, where there is no place for finger pointing, rut and panic(even in crucial times). I am working in a team which is high performing and I would like to uncover the challenges we faced and how we overcome those as a team.We never thought that one day we will be a successful and high performing team nor did it happen overnight. We faced the moments of finger pointing, failures, boredom and heated discussions during the initial phase. We slowly made use of continuous ‘retrospection’ from ‘Scrum’, which helped a lot. We found that retrospection never hurts, even if you don’t have any failure since last retrospection, you may find better ways of doing the same thing. We saw that rhythm is important, as repetition reduces complexity. So, we tried continuous improvement in everything, be it very small discussion, a big deployment or regular review meeting with product owners and sponsors. Soon, we found our key mantra, ‘rhythm’ and we stick to it.Challenges:I believe most of the teams face these challenges, but since our team was very small(one developer, one hands-on architect and one product owner) and our sprints were small (one week), these became crucial for various reasons:    * Begin meetings on schedule: Since we have meetings with different groups and most of the times they are back to back, it became crucial to join meeting on time.    * Meetings, never end on time: This costs a lot if you have small development cycle, if meetings go beyond their scheduled time, you have to back fill the development hours, may be sometimes by staying late and sometimes working over the weekend to avoid delayed deliveries.    * Distractions from the agenda: This one is real killer and one of the real cause of the previous challenge. It happened very often in our team, until we found solution for this.    * No more boring stories (tasks): How would you feel if you are given to write automated functional test cases for more than 50 combinative scenarios in a sprint?    * New Ideas/innovation: Every team feels that it should innovate something or implement new ideas, that no one around have thought about (which in turn brings confidence and enthusiasm)    * Effective retrospection: Every Scrum project team does the retrospection, but how can we do it in a better way was a big challenge, as we did not want to do it as a ritual which will die in few days.    * Avoid panicking in crucial times: I admit, no one can avoid panicking in a production failure, but we all know it will not help either. The challenge was to learn how to avoid panic in crucial moments and keep the calm hat on, so that team can find right solution in instead of a quick and dirty solution.    * Why failures in QA instead of development environment?: No matter how much we test some issues come-up in QA instead of development, which is a big challenge for any team.    * Demanding stakeholders do not agree for automation testing: It was always challenging to convince sponsors for automated unit/functional/integration testing. Their question was dead straight, “Why would I spend my money on something which is not a must have feature in my product?”Approach to solve these challenges:It all started with retrospection and I love saying that retrospection is the best process Scrum has come-up with. It is a forum to brainstorm, rather than asking questions like, why you have done that crap, why you did not build the right code? Who love such questions? I don’t and I don’t think anybody would love it. There are better ways to do the retrospection and I think our team came-up with the right approach.    * Effective retrospection:      We all do the retrospection in Scrum projects, sometimes every sprint, sometimes on ad-hoc basis. We were doing retrospection, but in three to four weeks, it became boring, we were not getting benefit of the retrospection. Then we tried new approach, we started maintaining ‘retrospection-backlog’. We took ownership of say two items per person per sprint. Until the team agree, that we have worked on those items, we do not close (or mark as done) those items in the backlog. Also, we made those items appear in the stand-up, as whether we have acted on those items or not. Now, we are not addressing them at the end of the sprint, but we were addressing them daily. Result? We close many items in the backlog and suddenly it is working for us. There are many of the retrospection items I have listed in this paper, one I liked most, “Cutting corners never help in a big picture. Shortcuts work for few days, but you have to pay it’s cost in a longer run”.    * Begin meetings on schedule:      A big challenge, I feel it is very easy to say, that we begin on time, but difficult to follow. We spoke in our retrospective and decided to maintain a backlog on our own, and whoever is late (more than two minutes) three times should give a treat to the team or bring snacks items (we maintain a snacks corner in our team room) or bring small logical game (we have a game zone too!). It really worked!    * Meetings, never end on time:      Another challenge and another retrospective was waiting for it. One of us volunteered to do time checks in meeting, so that participants talk precisely what is important and it helped to finish meetings on time.    * Distractions from the meeting:      This one was one of the root cause of previous challenge and we came up with parking lot idea. It is really helpful, if you see someone is distracting the discussion and one of us would raise a hand, which means: ‘Focus!’.    * No more boring stories (tasks):      This happened with me, when I was asked to write automated functional test cases for more than 50 combinatorial scenarios in a sprint. It is boring to the death at the same time you have to keep reminding yourself that you are not missing any crucial scenario, otherwise needless to say your efforts are waste. I discussed with my product owner and we came-up with a mutually exclusive and collectively exhaustive(MECE) list of scenarios on ‘matrix based problem solving’ approach. It was new for me and in less than one hour we discussed only important scenarios and implemented them, which kept the problem interesting at the same time it helped us to achieve the goal.    * New Ideas/innovation:      We as a team would like to try out different things, but the pressure of development work never let us do ideas, which we wanted to try-out (for example unit testing of javascript code). We made a retrospective item that as a team we will spend some time to try-out new things, sync-up with the new technologies/we trends. The ‘so what’ for our product owner was, better solution will come upfront when the team, a) learn new things and b) share the ideas/innovations with broader groups. Since we added this as a retrospection item and even product owner voted on that, we found no excuses and started implementing new ideas. Another idea we came-up with was to have backlog for ‘Most Teamish Room goal’ and the acceptance criteria was, if anyone stop by, ‘wow!’ should be the first expression/reaction.    * Books are best friends, how can they help my team?:      Building a team with collaboration and learning, Do it yourself, workaholics is killer, good enough is fine, pick a fight and how to say you’re sorry, are few of the principles I have learnt from few books I have read. Books not only guide you, but more importantly they keep hammering the concepts, so that you are bound to find a better way of doing the same thing.    * Avoid panicking in crucial times:      It happened when ‘we’ as a team tasted failure first time. Again, retrospection came to rescue us. Once we got over the failure, we did the retrospection from a distance (after a week) and found that instead of panicking, it was our cool mind, which helped us. We were very tempted to go with quick and dirty solution, but we waited and thought, ‘Is this the right solution for the long term?’. It helped and this approach became our habit. The key is to, ‘never lose the calmness, never in a crucial situation’.    * Why failures in QA instead of development environment?:      We happened to see failures in QA, even when developers do their part of testing in development environment. In our retrospection we brought this and came-up with, ‘Team testing time with freinds’. So, we called few friends who were neither part of development team nor part of sponsors’ group. This strategy worked and we started catching issue in development environment.    * Demanding sponsors do not agree for automation testing      We find it difficult to convince sponsors for tech debt or automated testing stories. One of the retrospection item was to present a Scrum factoid at the end of the sprint review meeting, to help sponsors understand the Scrum more. It worked like a charm. More we involved sponsors (though they hesitated initially), more it became easier to convince to them what development team wanted to try to improve the code quality(and obviously to improve the product).Benefits:With the challenges we faced, we uncovered a lot many solutions for variety of problems. Be it technical problem or a process issue, we decided not to be caught up in a rut of work. The benefits were many folded.Joy of work and flow of energy: Most importantly team was enjoying the work. No task or deadline pushed us to do something, everything was in flow.Confidence of stakeholders: We won the confidence of the sponsors and product owners.Software Craftsmanship: We implemented our own ideas (software craftsmanship), which boosted morale and confidence of the team.No more ‘staying late’ nightmaresRetrospect everything: Retrospectives made life much easy. Nothing fell of the cracks, as we were doing retrospection every week.Celebrations: Team had a lot to celebrate; their innovation, problem solving approach and knowledge sharing with other teams. Best practices became part of the team activities.In all it became a win-win situation for everyone.I feel that every team can become a ‘High Performing Team’. It only takes small efforts every sprint, but in a longer run, you will find yourself out of those nightmares of teams with lack of energy, lack of vision and above all lack of self confidence. Retrospection is the best tool Scrum has given and each team will get benefit, if it is used. Finally, if you have the idea implement it, because, world needs execution of ideas (I think I read it in some book, ‘no one likes the idea guy!’).I would like to thank my team members, with whom I lived this experience. Also to thank my colleagues and my seniors to inspire me to learn and achieve, they are not directly involved in project activities directly, but always helped with their continuous feedback.References:   1. Rework - http://37signals.com/rework/   2. Beautiful Teams -Inspiring and Cautionary Tales from Veteran Team Leaders http://oreilly.com/catalog/9780596518028

My first practical assignment on User Experience :-)

almost 7 years ago | Lalita Chandel: My View

I am very excited to share updates about my first project assignment on UX, that I have been working for last 1.5 month. It is a platform for me to apply my usability concepts and knowledge that I have gained so far from online UX tutorials, blogs, Technical forums etc. I am working on a Ruby and Rails tutorial with my friends in India (Abhishek Nalwaya and Akshat Paul). Our objective is to improve the overall experience of this site. The initial versions of this tutorial were deployed in Heroku with the sole intention of learning some new technologies. But now, we want to completely focus on re-designing this site for improving the usage. It is a small effort from our side to contribute to the ROR community.So we started with analyzing the site usage results in Google Analytics Dashboard, where we observed a very high bounce rate. Moreover, the Google pagerank and visual appeal of the tutorial was not very good, which definitely implied that there is a huge scope of improvement. We came up with these initial thoughts to start our work :-Improve the whole information architecture by revising the content with the latest version material, as that is the main deciding factor to retain visitors on any tutorial. Also, adding two sitemap's i.e. one for site visitors and the other for googlebot would be helpful to provide an organized view of the site to its visitors.Navigation mechanism can be structured better by shifting the navigation links to the top , so that we have more space on the content page. The social media icons and twitter feeds are not prominent currently and they can made more visible. We pushed our first release on 18 Dec with following improvement stories:- 1. XML sitemap implemented and registered in Google Webmaster Tools to improve the content accessibility to the crawler.2. Favicon added to have a unique brand image to the tutorial.3. Revision of the About Us page with pictures to make the developers more approachable for suggestions and feedback's.We are currently working on the content revision and application of search optimization techniques. I would keep you guys updated about my learning experience with this system. In case you have any suggestions or feedback, please feel free to reach out to me.