Tuesday, July 26, 2011

link_to data-method delete not working in IE9?

I was testing a Ruby on Rails 3 application with devise authentication library and to my surprise, link_to with data-method was not working in Internet Explorer 9 (IE9). In that case, the method was set to delete. It works perfectly in Chrome, though.

There are some bugs reported on that, but the solution I found was
  1. Make my application depend on jquery
    • Edit your Gemfile and add:
      • gem 'jquery-rails', '>= 1.0.12'
  2. Run rails generate to install jquery and get rid of other .js files (like prototype.js)
    • rails generate jquery:install
  3. Run application
I did not see these instructions anywhere, just decided to follow what I had done in another project to test Ajax support for Ruby and it just worked. I hope it works for you.

By the way, I've seen several mentions of this, but since my Rails 3 already had it, I did not bother much. In your case, also make sure that your application.html.erb has these tags in your :

<%= javascript_include_tag :defaults %>
<%= csrf_meta_tag %>

Saturday, July 23, 2011

Thoughts on "growing as a developer"

I just read the following blog post written by Robert Bowen:

These are the highlights:
  • We should always be moving forward, reaching for the next plateau
  • Find a way to grow, actively pursing opportunities of growth
  • Make sure:
    • Your schedule allows for that
    • You don't think you mastered the field
    • You think outside of your day-to-day job world that may have become stagnant and monotonous
  • Ways to grow:
    • Step outside of our comfort zones to try something new and experiment to guarantee to learn something new and push our skills to new heights
    • Study the work of those you admire
    • Keep up with the field and how it is evolving
    • Reach out to others for feedback
    • Collaborate on projects with others that will push you to challenge yourself
    • Be active in the community, like running a blog, contributing to blogs and discussions
This is a great post and reflects my motto of always keep getting better and pushing myself. I believe that, by getting better, you will grow in your field and, no matter what the current circumstances are, over time that will pay off.

Is it worthwhile?
I've started challenging myself in this regard by asking: is my motto actually something worth living by?  This pay-off will definitely be worth in terms of personal satisfaction. Like one that has hobbies and personal projects, oftentimes these are for personal satisfaction more than for some special reward in the future.

Provided value
Other than personal projects, when you are  an employee or a freelancer, or even an entrepreneur, this growth pays off to the extent that it provides value to those paying for your time, service, or product. And that is very important to realize sooner than later.

Multiplying effect
Even getting better technically, typically you hit a ceiling at some point, because no matter how much you can accomplish, you can accomplish only so much as an individual contributor. Unless you have a multiplying effect in the organization. Not that multiplying effect is something easy to define, and can be subject to politics and subjectivity, but the general idea is that on can make the entire organization better. Only doing that you can grown as an individual contributor, otherwise you will not grow beyond a certain point in your career.

Is getting better valued?
Besides that, another very important point is how much getting better is actually valued by the organization you are part of. If you are surrounded by people that do not see value in getting better - they may think that the current level is good enough, or just don't value improvement as long as things get done - you will grow frustrated as your growth will not be recognized and you may not even be potentially be rewarded at all by it. In some cases, you can be even penalized by that. This all can lead to potential stagnation and will require a major effort for one to keep sanity in such an environment. Notice that, if you are dealing with customers (as a freelancer or entrepreneur), it can be the same.

Address actual needs
The key is how you can leverage your getting better to provide more value - and find or create the environment that nurtures that mindset. You can make your program/code/design more efficient, more resilient, more secure, etc, and that is where your growth will manifest itself. In reality, the trick is to find the right set of people that really want more efficient, more resilient, more secure, etc, as oftentimes they think the current state of affairs is good enough. It just could be that the challenges faced by the company cannot be fixed or substantially improved by your skills, in which case the relationship can grow sour over time.

Being ahead of the curve
Eventually, if one keeps getting better, it becomes increasingly more difficult to find the right opportunities to leverage this knowledge, and this can be incredibly frustrating for the individual. The personal satisfaction is still there, but as we say that some people are much ahead of their times, some people are just ahead of the curve and must find how to apply their knowledge. Taken to the extreme, only a few places and few people in world may actually value these people, and spending their days doing the "wrong" thing or in the "wrong" place may prove to be a complete waste of time.

More than technical skills
As part of growing as developer, everybody should work on their interpersonal skills if these can be their weaknesses. I don't think that weaknesses must be necessarily completely fixed. One should build on their strengths with the following rule: don't let the weaknesses get in the way. In our field in particular, these weaknesses are typically related to soft skills, and bright people often can work on them. By doing that, nobody will dismiss great ideas or contributions on the basis of soft skills. As part of finding the right environment and right set of people to work with, improving on soft skills can be quite beneficial.

Steps to install MySQL2 GEM (Ruby on Rails) on Windows 7 (64 bit)

I ran into many issues trying to get it compiled and installed on Windows 7 64-bit and wished I had an "apt-get" that would have fixed all these issues.

The trick here is: you need MySQL 32-bit to have Ruby on Rails MySQL2 gem compiling on Windows 7 64-bit. In short, this is what I had to do:

  1. Install Ruby Development Kit in order to be able to compile C-bindings for Ruby
    • Error: The 'mysql2' native gem requires installed build tools.
  2. Install MySQL Server 64-bit
  3. Download MySQL Server 32-bit .zip file
  4. Add MySQL 32-bit lib directory to PATH (or copy libmysql.dll to %RUBY_HOME%\bin)
  5. Install MySQL2 2.0.6 GEM specifying --with-mysql-lib and --with-mysql-include options pointing to the 32-bit lib and include directories
    • gem install mysql2 -- '--with-mysql-lib="c:\Development\MySQL Server 5.5\lib\opt" --with-mysql-include="c:\Development\MySQL\MySQL Server 5.5\include"'
  6. Install Rake 0.9.2
    • Error: uninitialized constant Rake::DSL

Friday, July 22, 2011

Why use regular expression?

I never posted code I've come across, but reading a random code today, I started wondering why one couldn't use regular expressions below to accomplish the same result - maybe I am just missing some good reason for that, but I thought it might be amusing to share:

string[] stringArray = str.Replace("Jan, ", "Jan ").Replace("Feb, ", "Feb ").Replace("Mar, ", "Mar ").Replace("Apr, ", "Apr ").Replace("May, ", "May ").Replace("Jun, ", "Jun ").Replace("Jul, ", "Jul ").Replace("Aug, ", "Aug ").Replace("Sep, ", "Sep ").Replace("Oct, ", "Oct ").Replace("Nov, ", "Nov ").Replace("Dec, ", "Dec ").Split(new[] { ',' });

Monday, July 18, 2011

The top 9+7 things every programmer or architect should know

Great list of things programmer and architects should know:

About learning to estimate, I recommend the following book:

These are three top things for me:
1. The Boy Scout Rule - Robert C. Martin (Uncle Bob)"You don’t have to make every module perfect before you check it in. You simply have to make it a little bit better than when you checked it out."

To be honest this is not something I have followed throughout my career, and although I certainly try improve code where I can, I never did it per check-in. I do however feel that it is an awesome principle and should be something that is actually part of a code review process. It is all to easy to just say:
"It was like that already"
"that nasty code was there for years, I am not going to touch it."
"It never had any tests"

I work in a corporate environment were applications often last for 4-10 years. If part of the process is always to just make something a little better, everything from deleting unused code to writing a single extra unit test, year after year... it will end up with saving a lot of people a lot of time and money.

This seems obvious, but not always we make it better when checking in. It takes a lot of diligence to do that - and agreement in a team environment on what better actually means.

4. Continuous Learning - Clint ShankThis is a very important topic, we are in a industry that is constantly growing, changing, shifting and as a programmer you need to be learning and improving yourself wherever you can. It's very easy to get into a comfort zone and just rest on your laurels, I did that for a couple years, and I do regret it now.
Things I am trying to do to keep up and would recommend:

  1. Get a Kindle... then buy & read books.
  2. Use Google Reader add the popular blogs and website RSS feeds for your specific field as well as a couple outside your field that interest you.
  3. Start a blog, by putting my code and thoughts out there, I put in more effort knowing that it's going to visible than if I just wrote the code/article for myself. I also force myself to do 1 - 2 posts a week, ensuring that I must always find new content to learn about.
  4. Join an open source community, we generally don't get to do enough "technical" development in our corporate environments.
Related to the first one: keep getting better - nothing will stop you. Build on your strengths, but don't let your weaknesses get in the way.

5. Record your rationale - Timothy HighThis is something that I feel is often neglected. Quite recently a project that I had been involved in for a long time hit the spotlight for all the wrong reasons: customer, user and management dissatisfaction. The first thing to be questioned was not the analysis, requirements, testing, management or expectations, but rather the architecture. Documentation discussing all the decisions, options looked at and reason for options taken would have been valuable. When things go fine, no one will even know about the document, but when things turn bad as they sometimes do having justification and documentation for all the major decisions will be a lifesaver.

That happened a lot in my experience. People will disagree, or some people will not have been involved in some discussions, and then you need to be able to articulate why some decisions were made. Most of the times new arguments and ideas were considered, but without recording your rationale, you may not be able to discuss them, especially in public forums like large meetings. I'd say that one should write the rationale and make sure it's in your head when the subject comes up - and obviously this assumes that you communicate effectively.

Saturday, July 16, 2011

Publishing to Blogger from Microsoft OneNote

I was trying to post something today and was wondering how it can be still so complicated to post and format something to a blog nowadays. One of the integration that I wanted is from OneNote, where I've been keeping many of my notes for quite sometime, to Blogger. And looking it up on the web, I found that it's already a reality and works very well - you may need to go over the formatting to remove some additional spaces, but it reduces the work substantially compared to a regular copy and paste.

For more info, this is the link:

Design Principles and Design Patterns


Object Oriented Class Design

  • Open-Closed Principle (OCP)
    • We should write our modules so that they can be extended, without requiring them to be modified.
    • Techniques:
      • Dynamic polymorphism
      • Static polymorphism (templates or generics)
  • Liskov Substitution Principle (LSP)
    • Derived classes should be substitutable for their base classes.
    • Derives from concept of Design by Contract
    • In terms of contracts, a derived class is substitutable for its base class if:
      • Its preconditions are not stronger than the base class method.
      • Its postconditions are no weaker than the base class method.
      • (In other words, derived methods should expect no more and provide no less)
    • There are subtleties: canonical example is the Circle/Ellipse dilemma
  • Dependency Inversion Principle (DIP)
    • Strategy of depending upon interfaces or abstract functions and classes, rather than upon concrete functions and classes.
    • Motivation behind DIP is to prevent you from depending upon volatile modules. The DIP makes the assumption that anything concrete is volatile.
    • Object creation: abstract factory
  • Interface Segregation Principle (ISP)
    • Many client specific interfaces are better than one general purpose interface
Package Architecture
  • Release Reuse Equivalency Principle (REP)
    • One criterion for grouping classes into packages is reuse
  • Common Closure Principle (CCP)
    • Group together classes that we think will change together
  • Common Reuse Principle (CRP)
    • Classes that aren't reused together should not be grouped together
    • "Changes to a class that I don't care about will still force a new release of the package, and still cause me to go through the effort of upgrading and revalidating."
  • Acyclic Dependencies Principle (ADP)
    • The dependencies between packages must not form cycles.
    • Breaking cycles
      • Creating a new package
      • Make use of DIP and ISP
  • Stable Dependencies Principle (SDP)
    • Depend in the direction of stability
    • Stability is related to the amount of work required to make a change
    • Should all software be stable? We greatly desire that portions of our software be instable. We want certain modules to be easy to change so that when requirements drift, the design can respond with ease.
  • Stable Abstractions Principle (SAP)
    • Stable packages should be abstract packages
    • The more packages that are hard to change, the less flexible our overall design will be. Highly stable packages at the bottom of the dependency network may be very difficult to change, but according to the OCP they do not have to be difficult to extend!
    • SAP is just a restatement of the DIP - it states the packages that are the most depended upon (i.e. stable) should also be the most abstract