CodeMentor Experts Reveal The Secrets To Staying Motivated

I've been featured in an article on CodeMentor.io, so thought I'd share:

CodeMentor Article: Experts Reveal The Secrets To Staying Motivated

“Build a personal low-risk project that tackles a new idea or puts a new twist on an old idea” – Andy Maleh

“Get training or regular mentoring by an expert in the language of choice or technology you aspire to master” – Andy Maleh

If you ever feel like solving a programming problem on a side project with the help of a mentor, expert, or pair-programming partner, hit me up at CodeMentor.io:

https://www.codementor.io/andymaleh

Presenting Abstract Feature Branch at Montreal.rb April 2015

I am giving a talk at this month's Montreal.rb user group, taking place next week on April 21, 2015:
http://www.montrealrb.com/2015/04/april-21th-meetup/

Abstract:

How many times do you find yourself near the software release finish line on an exciting new feature only to be pulled off by management in the last minute to sneak in some higher priority emergency fix? What do you do with the unfinished feature's code if parts of it were already functional and merged into master? Do you pluck it out and move to a remote feature branch? Do you simply comment out the code not ready for exposure to the customer? What about some of the nice software design improvements that were done as part of the feature and are being put to good use by the team today? Do you also put design improvements off till the feature is deemed by management high priority again?

These questions typically get decided on by the team on a case by case basis, and often with big compromises affecting both project delivery and code quality.

While consulting for Sears in 2009 and working at Groupon.com in 2012, I happened to work in teams that adopted a very effective and inexpensive solution to the problem called "Branch by Abstraction", a technique originally popularized by Martin Fowler, author of UML Distilled and Patterns of Enterprise Application Architecture.

In this talk, I aim to explain Branch by Abstraction and demonstrate how to apply in Ruby using a gem I wrote called Abstract Feature Branch, partly inspired by the internal team libraries used at Sears and Groupon. The gem has already had over 50,000 downloads from rubygem.org and has been utilized in several of my newer projects, including launch of EarlyShares.com and enhancements of Factor75.com.

Attendees should walk out with basic understanding of Branch by Abstraction and enough knowledge of Abstract Feature Branch to be able to explore further in their own projects after the talk.

SuperModule v1.1.0 is the New Sherif in Town!

After posting an article on AirPair.com about SuperModule v1.0.0 and getting quite a bit of feedback on it in the form of article reviews and reddit posts, I decided to make a new revision with quite a number of improvements, which was released yesterday as SuperModule v1.1.0:

What's New in v1.1.0?

• Brand new self-friendly algorithm that ensures true mixing of super module singleton methods into the including base class or module, thus always returning the actual base class or module self when invoking a super module inherited singleton method (thanks to Banister for reporting previous limitation on Reddit and providing suggestions)
• New included_super_modules inherited singleton method that provides developer with a list of all included super modules similar to the Ruby included_modules method.
• No more use for method_missing (Thanks to Marc-André Lafortune, a Ruby language contributor, for bringing up as a previous limitation in AirPair article reviews)
• New dependency on Banister's method_source library to have the self-friendly algorithm eval inherited class method sources into the including base class or module.
• Refactorings, including break-up of the original SuperModule into 3 modules in separate files
• More RSpec test coverage, including additional method definition scenarios, such as when adding dynamically via class_eval and define_method

Cheers...

Ruby SuperModule Comes To The Rescue!!

Tired of ActiveSupport::Concern and Ruby's modules not allowing you to mix in class methods easily? Well, worry no more! SuperModule comes to the rescue!



SuperModule allows defining class methods and method invocations the same way a super class does without using def included(base).

This succeeds ActiveSupport::Concern by offering lighter purely idiomatic Ruby syntax and simpler module dependency support.

1. Just include SuperModule at the top of a module definition:

module UserIdentifiable
  include SuperModule

  belongs_to :user
  validates :user_id, presence: true

  def self.most_active_user
    User.find_by_id(select('count(id) as head_count, user_id').group('user_id').order('count(id) desc').first.user_id)
  end

  def slug
    "#{self.class.name}_#{user_id}"
  end
end

2. Mix newly defined module into a class or another super module

class ClubParticipation < ActiveRecord::Base
  include UserIdentifiable
end
class CourseEnrollment < ActiveRecord::Base
  include UserIdentifiable
end
module Accountable
  include SuperModule
  include UserIdentifiable
end
class Activity < ActiveRecord::Base
  include Accountable
end

3. And start using by invoking class methods or instance methods

CourseEnrollment.most_active_user
ClubParticipation.most_active_user
Activity.last.slug
ClubParticipation.create(club_id: club.id, user_id: user.id).slug
CourseEnrollment.new(course_id: course.id).valid?

More details and examples are available over here: https://github.com/AndyObtiva/super_module

And the SuperModule RubyGem lives over here: http://rubygems.org/gems/super_module

Enjoy!!

Presenting at RailsConf 2014

Update: here are the links to the talk video and slides

My talk "Ultra Light and Maintainable Rails Wizards" has been added to the RailsConf 2014 program

Abstract:

Wizards have been common in web applications since the dawn of the Internet, with the most popular example being the Shopping Cart, yet many struggle with writing wizard code effectively, resulting in a huge untraceable rat's nest of copy/paste code. In fact, many implementations violate REST and include Fat Controllers as well as overly complicated wizard-step management, data, session, and validation code. This talk covers a better way that yields Ultra Light and Maintainable Rails Wizards!

If you have any special requests to include in the talk, please let me know in the comments.

Looking forward to connecting with Rails developers at RailsConf 2014.

You're Hired! You're Fired!

NOTE: I originally authored this article for Big Astronaut's blog, which Lance Ennen posted on my behalf. I am sharing here as well for those following my blog directly.

What is the #1 thing everyone complains about with regards to using Heroku as a Rails Web Hosting platform? 

If you guessed "price" you would not be far off from the truth. In fact, Heroku gives a lot of bang for the buck to get websites started and on the way to mega-stardom, but the inability to scale dynos up and down automatically based on web server load can be such a boon when you know the site is a ghost town at night not worth having 5 dynos fired up at $34/month each.

Enter HireFire: a dyno manager for Heroku, allowing you to autoscale your web and worker dynos, saving on server costs at nighttime and handling greater traffic during the day. It can integrate directly with NewRelic to get response times, request rates, and Apdex as data to use for scaling Heroku dynos automatically.

Testing

Very recently, I experimented with HireFire.io on a Staging web server for a Chicago healthy gourmet food site called Factor 75 (highly recommended approach to testing the waters before taking the plunge). 

The first step was to configure HireFire for Web Dynos with a minimum number of dynos set to 1 and a maximum set to 5. Additionally, it was configured to scale up when response time (obtained From NewRelic) surpassed 950ms and scale down when response time went below 700ms.

Next, I ran the following command to try and overwhelm the single dyno that was originally configured for the Heroku Staging application:

ab -v 1 -c 5 -n 1000 http://factor75-branch.herokuapp.com/menu

It caused HireFire to scale the Heroku application gradually until there were 5 dynos. After the command finished and a little bit of time passed, HireFire scaled the Heroku application back down

The result was a great success yielding both better traffic handling and better cost saving depending on the traffic situation.

Lastly, I experimented with enabling HireFire for Worker Dynos, and it scaled them up to 2 and down to 0 depending on whether the Sidekiq background processing queues got populated with jobs. The configuraiton stipulated adding an additional dyno for every 15 queued jobs waiting to be processed. Again, the result was a great success, yielding $0 cost for worker dynos the majority of the time.

Recommendation

It would be good to start with a minimum of 2 dynos to avoid Heroku's single dyno sleeping policy and support 2 concurrent users to boot. The maximum can be set to 5 dynos to support spikes of 5 concurrent users (the number may be increased further if there is higher traffic and the web application owner can afford more dynos). 

Next, it would be good to set the Upscaling Sensitivity to LV1 in order for the website to scale up and service users immediately when load is increased and the need arises. It would also be good to set the Downscaling Sensitivity to LV5 to give the server time to prove it needs to scale down before doing so, thus avoiding a jittery experience for website users.

I configured the HireFire Upscale Quantity to 2 to ensure handling sudden spikes with more fire power, yet configured the Downscale Quantity to 1 to scale it down gradually when the extra server load is gone.

With regards to timeouts between dyno scaling, 3 minutes (minimum) is good for upscaling and 12 minutes is good for downscaling.

I recommend a maximum response time threshold of 950ms as that is about the point when user experience starts to degrade. As for the minimum response time threshold, 700ms should work well leaving some room to downscale gradually.

Last but not least, time boundaries can be very useful to lower the minimum number of dynos at night (e.g. 11pm-7am) to 1, thus running the website completely FOR FREE during the night.

Pricing

With regards to pricing, HireFire costs about $10 a month. Given that it scales Heroku Web dynos from 5 down to 1 and Worker dynos from 2 to 0 at nighttime (8 hours), it would save at least 33.3% over a month on dyno cost. That can add up to roughly $70 in cost saving for a 5 web dyno / 2 worker dyno setup. Trading that for HireFire's $10 a month fee results in a $60 net saving. And, that is the pessimistic estimate. In actual use, HireFire should result in much greater savings.

Gotchas

Note that when a Heroku dyno is added, it takes about a 20 seconds to boot up according to data captured from Heroku logs.

Also, HireFire warns about hitting the Heroku API rate limit of 1200 calls an hour when enabling the "Restart Crashed Dynos" feature on a web application. It costs about 60 API calls to Heroku per hour, so with one application utilizing HireFIre under a Heroku client account, HireFire will work well with Heroku with regards to using the "Restart Crashed Dynos" feature. It is recommended for the sake of ensuring minute by minute restart of crashed dynos during emergencies, which is faster than Heroku's increasing intervals restart policy. 

HireFire makes Redis connections to check the number of jobs in Sidekiq queues. It is important to ensure Redis can handle these extra connections in addition to the workers connecting to do work. For example, with Redis To Go Medium, which supports a maxclients number of 512, HireFire has plenty of room to connect.

Conclusion

HireFire did work as advertised, scaling Heroku dynos up within a second of load surpassing the maximum response threshold. It also did work as advertised with regards to scaling Heroku dynos down once the load has let up, resulting in great savings, at least 33% if the website gets light traffic at night.

In other words, go ahead and HIRE HireFire.io so you'd finally FIRE your DevOps team!

Ultra Light and Maintainable Rails Wizards at RailsConf and EuRuKo 2014

I have submitted proposals for the following talk at RailsConf 2014 and EuRuKo 2014:

Title: Ultra Light and Maintainable Rails Wizards

Abstract:

Every developer probably struggled at one point with building a large multi-step wizard that spanned several weeks to develop, interrupted by the client multiple times to insert another step here and another step there resulting in big code rewrites or lots of quick copy/paste and code duplication. Developers might address the concern by writing custom code that violates REST, results in Fat Controllers, or includes complicated Wizard step data management code. Andy will introduce a better way!

RailsConf2014 Proposal Link:

http://rubycentral-cfp.herokuapp.com/events/railsconf-2014/proposals/2d717970a4

If I were to present, I would look forward to meeting you there.