Posts

Agile Stand Ups

Agile Stand Ups The stand up is a great way to have daily communication between team members. There has been much written about how to do a stand-up, but there are two ways.  The most traditional way is to have each team member answer these three questions: What tasks have you worked on since we last talked? What tasks are you planning to work on next? Is anything getting in the way of finishing the work as expected? Another popular way, especially if you have team members that do not like to share, is to "walk the board." You have the board shared, whatever tool you use for tracking, and discuss the status of user stories in each swim lane.  Traditionally, you have two problems with teams and stand ups.  There is The Lottery.  In short, there is the danger of teams choosing the weakest link, and a blaming situation occurs. There can be underperformers. And teams do have to hold people accountable. But you have to treat people with respect. L...
Post a Comment
Read more

Optimistic Locking

Optimistic Locking  For Rails We had the challenge today for making forms behave well with Optimistic Locking with a rails application. Overall, this is built into the Rails eco-system, with the subtle difference in the way errors are handled. Which is to say poorly. Although this seems to be a problem at the Controller level, this is really related to the model, and the data persistence layer. Hence we chose to use a Concern to provide a method to handle the error gracefully.  We included this new concern in any model necessary, and now our apps handle this elegantly. Quick Code Glance: module OptimisticLockingNameMe   extend ActiveSupport::Concern   def update_with_opt_lock_validation(*args)     update(*args)     rescue ActiveRecord::StaleObjectError       self.lock_version = lock_version_was       errors.add :base, "This #{self.class} has modified while you were editing."       cha...
Post a Comment
Read more

Agile Communication

Agile Communication From the 12 principals of the Agile Manifesto The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. In our group, get up and talk to the developer, business person. Or pick up the phone. Skype. If you absolutely have no other recourse then tag them in a user story. Email is for documenting. Elevating to management. Of course, to elevate is to admit you cannot take responsibility to solve a problem... so be cautious http://agilemanifesto.org/principles.html Communicate in code! This has multiple facets. First, write clear code. Another way to think of this is by doing code reviews. Our team does!  https://smartbear.com/learn/code-review/agile-code-review-process/ Today in history... August 23 The World Wide Web was introduced! Talk about communicating!
Post a Comment
Read more

Rails & Agile common mistakes

Rails & Agile common mistakes Rails This is a useful link about common Rails mistakes. https://airbrake.io/blog/rails/5-common-mistakes-rails-development The most useful suggestion is to avoid fat-models. In today's rails applications, there is simply no reason not to follow solid OO design. Loose Coupling and Tight Cohesion. Here's a better explanation than the above blog. http://www.infoworld.com/article/2949579/application-architecture/design-for-change-coupling-and-cohesion-in-object-oriented-systems.html Agile There are three types of companies.  Start ups Enterprise Donkeys Not sure what you are? You're a donkey. In short, start ups will introduce new concepts and paradigms, enterprises will pick the best practices from start ups, and donkeys are everyone else.  Fifteen or even ten years ago, Agile was practiced by the start ups and then the enterprises. We are finally seeing the rest of the business world catch up. How do these old...
Post a Comment
Read more