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 IT departments continue being the hands on production support, and provide new features and new applications? It's a big mind shift. It is difficult to adopt Agile after supporting old systems that are 20, 25 or 30 years old. 

Every developer is production support. Now plan for new applications and features. Here's one way to schedule these teams. 

https://dzone.com/articles/sprint-planning-for-agile-teams-that-have-lots-of

Lincoln

And speaking of common mistakes. Abe Lincoln had justified the Civil War based on keeping the Union united. On this day in history in 1862, Lincoln made the most provocative case for the war: Abolition! Careful readers of Lincoln could not have seen any other outcome of the war, but this was the first outright case for ending slavery. The case was laid out in a letter to Horace Greenly. 

A month later he issued the Emancipation Proclamation.

Thus correcting his mistake. Not to judge Lincoln too harshly, but even 150 years later historians remember that the war justification was not originally slavery.

Comments

Post a Comment

Popular posts from this blog

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...
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!
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...
Read more