Yet another jQuery validation post: make it work with bootstrap

I recently needed to enforce rules on a form that I laid out with bootstrap. The form looked great but required a selection of values or it wouldn’t yield correct results. If designed well, a form won’t need a lengthy explanation how to make it work. I opted to use jQuery validation so I could focus on the user experience first and code details second. The jQuery validation library adds value in this scenario because it is well tested so I don’t have to spend time re-inventing code to do this work.  If the required fields are obvious when someone uses the form then there is less frustration.

Here is the html:

<form id="form_to_validate" novalidate="novalidate" method="post">
  <div class="col-sm-12">
    <div class="form-group" id="divisionlist">
      <select id="divisions" name="divisions" class="form-control" required="required" multiple="" size="5">
        <option value="1">01 - Division 1</option>
        <option value="2">02 - Division 2</option>
        <option value="3">03 - Division 3</option>
        <option value="4">04 - Division 4</option>
        <option value="5">05 - Division 5</option>
      </select>
    </div>
  </div>
</form>
<br/>
<button id="Validate">Validate!</button>
<span id="valid_result"></span>

Here is the Javascript:

$(function() {
  // override jquery validate plugin defaults to work with twitter bootstrap
  $.validator.setDefaults({
    highlight: function(element) {
      $(element).closest('.form-group').addClass('has-error');
    },
    unhighlight: function(element) {
      $(element).closest('.form-group').removeClass('has-error');
    },
    errorElement: 'span',
    errorClass: 'help-block',
    errorPlacement: function(error, element) {
      if (element.parent('.input-group').length) {
        error.insertAfter(element.parent());
      } else {
        error.insertAfter(element);
      }
    }
  });

  //set up the validation rules
  $('#form_to_validate').validate({
    rules: {
      divisions: 'required',
    },
    errorElement: 'div',
  });

  //this bit uses button to tests that the validation is working
  //it's not part of the published solution.
  $('#Validate').click(function() {
    var valid_form = $('#form_to_validate').valid();
    if (valid_form) {
      $("#valid_result").text("valid!");
    } else {
      $("#valid_result").text("NOT valid!");
    }
    return false;
  });
});

Here is the end result when not valid:

form_not_validHere is the end result when valid:

form_is_validIt’s important to not that I had to include 4 libraries on this page to get this to work. These libraries are what do all the difficult work. I’m just using them to get easy validation with a good looking result.

Bootstrap 3.3.6 css

Bootstrap 3.3.6 js min

jQuery Validate 1.14.0

jQuery 2.2.2 js min

So let’s work through what’s going on here. In the code I pasted above there are two parts that do all the magic. First, this snippet shows the jQuery validation library how to work with bootstraps css rules. Specifically, it tells the library which elements in a form-group should be decorated with the ‘has-error’ css rule that turns elements red when a rule is violated.

$(function() {
  // override jquery validate plugin defaults to work with twitter bootstrap
  $.validator.setDefaults({
    highlight: function(element) {
      $(element).closest('.form-group').addClass('has-error');
    },
    unhighlight: function(element) {
      $(element).closest('.form-group').removeClass('has-error');
    },
    errorElement: 'span',
    errorClass: 'help-block',
    errorPlacement: function(error, element) {
      if (element.parent('.input-group').length) {
        error.insertAfter(element.parent());
      } else {
        error.insertAfter(element);
      }
    }
  });

Second, this bit tells the jQuery validate framework which fields to perform it’s validation.

  //set up the validation rules
  $('#form_to_validate').validate({
    rules: {
      divisions: 'required',
    },
    errorElement: 'div',
  });

With around 25 very short lines of JavaScript you can enable good looking validation on a nicely laid out form.

A link to JSFiddle with a complete working solution.

Happy coding.

Posted in General

It’s not about you

A basic truth about your software career: It’s not about you

A simple truth about opportunity in the world of software is that most of the paying work lies in the fulfillment of other people’s desires. This means that staying busy (read: gainfully employed) will consist of working on projects that start in someone else’s head. Stated bluntly, the majority of your professional career will be centered around bringing other people’s ideas into reality.

Let’s face it. If everyone had the time and ability to learn how to program there wouldn’t be a need for software professionals. Luckily for us, most people don’t want to learn how to talk to machines. This creates great opportunities because lots of people want to leverage the power of computers but they need someone to help them do it. This is where we have the ability to shine. With our help, our users and clients can achieve the leverage they desire. We serve as the key to a world where their information needs are met with our assistance.

The basic idea behind this strategy of helping clients get their information in order is service. If you want to earn a living then you must learn to be of useful service to your clients. Personally, I find a great satisfaction in serving the needs of others so this arrangement suits me. I also like technology so it’s like getting paid to fiddle with trinkets and ideas that I already have a desire to learn. The fact that I get to earn a living helping people achieve goals inside my area of expertise is icing on the cake. All you need to be successful is to keep learning while cultivating your desire to help others.

If you’ve been in the field for awhile you’ve likely had to face deadlines or constantly shifting requirements. It can be difficult to retain an attitude of humble service when users are breathing down your neck while your trying to concentrate on fixing an issue that’s holding up production. Maybe your boss has changed his or her mind about a critical piece of functionality for the sixth time in so many weeks and drops the change on you with the attitude that “it’s no big deal”. If your goal is to become a true professional in this field then you must learn to take these nutty developments in stride. Above all you have to retain an attitude of humble servitude toward your users and clients. Without them you’d be out of a job!

The moral here is: If you can remain focused on humble service to others when conditions around you are constantly changing then you’re well on your way to success.

 

Posted in General

How to be a successful software developer

Be of service.

This is simple to talk about, but difficult to practice. The key is to adopt service focused approach to your profession. This technique is powerful because most developers spend all of their time thinking in a “nerd technical” way as opposed to a “how to serve people” way. To put it another way, if you want to become successful, you need to start solving a different set of problems. You need to use what you know about software to solve other people’s problems.

Thinking of service first, and the task at hand second is a time tested approach for success for almost any type of profession. Good professionals are “of service”. They begin with service and end with service. Their clients (users, bosses, other developers, other departments) all depend what they produce. So your first and last task is to make yourself of maximum use to your users. A developer can raise the quality of their output by focusing on “being of service” to their clients. Simple right? No, not really. In real life this is really hard. But if you do it well, the service oriented approach will make you indispensable to your clients or employer.

Being of service requires listening skills. This is something that developers usually struggle with. We’re just not trained to focus on the end users experience. We usually focus on details of implementation. I mean, it’s hard enough getting the program to work like the specification states, when are we going to find time to get all ‘touchy-feely’ with users? This is where the rubber meets the road. Your task is to train your technical brain to see things the way your users see them. If you can accomplish this superhuman feat you’ll know exactly where to laser focus your efforts on your product. To look at it another way, you are making sure than not a single moment of your precious time is wasted on details that will never matter in the real world. At some point in our careers most of us worked really hard on the ‘must have’ feature that was promptly discarded on launch day.

Software nerds like to think of their brains as powerful equipment capable of solving complex problems. We rarely take to time to think about how our efforts directly impact the people we serve. In reality, we’re usually so busy solving problems that we rarely get to see our work in action. If we were to spend more time thinking about how our contributions affect users we would have more insight into how to make more meaningful contributions

If you’ve been a developer for very long you’ve certainly experienced a user saying something like “Wow, this makes this my day so much easier!” When you hear this you feel proud of your accomplishment and might think to yourself, “glad it worked out, it wasn’t much effort, I just added a simple function.” But don’t discount your efforts so quickly. When the recipient of your effort expresses gratitude then you’ve just accomplished one of the most basic and difficult to master tasks of human endeavor, which is to “be of service”.

By focusing on the service aspect your profession you’re leveraging a part of your brain that developers aren’t really trained to use. You’re focusing on the client first and the task second. Doing this will lead to success because you’ll always be focused on meaningful work. This means starting with the simple idea “how can I directly serve another person” and ending with the implementation of what service means to the client. This is a simple equation but it’s difficulty lies in the discipline of getting out of bed everyday and asking yourself “how can I be of service today”. If you can do this consistently you’ll never be out of work and you’ll receive plenty of gratitude for all your hard work.

Posted in General

A plan for requirements gathering

When creating software program how do you get from an idea to a detailed list of things that need to be accomplished? This question is not easily answered. There is a road to get there, others have traveled this road and mapped the pitfalls. The following is a brief description of the basic parts of the process.

Understand the problem you’re tasked with solving:

This may be the hardest part. If you’re successful here chances for successful delivery of a working and useful program increase greatly. The first step is to create an honest and thorough description of the problem.

This looks like:

  1. Build a list of stakeholders – these are the people who’s input, if left out, would likely result in a program that fails to launch. Obvious members of this group are users and management, but there are likely others who have valuable input. Seek them out and include their opinions. Divide the stakeholders into groups. Each group of stakeholders will need to elect a representative leader who can speak for the group in periods where consensus cannot be achieved by the group itself.
  2. Meet with each group of stakeholders individually. Record what must be accomplished and what would be nice if accomplished. Build a definitive list of needs and desires.  Next, call a meeting with the group leaders to go over the needs and desires. The leaders have final say in what’s in or out of the product. You’ll gain much clarity at this point in the process.
  3. Meet with your team (if you have one) to discuss the product must-haves and the technical requirements necessary to make the product must-haves possible. If you don’t have a team you still need to work through this step. The user functionality requirements will drive the technical requirements and you need to map out the technical requirements.
  4. Set a schedule based on your estimates of fulfilling the required features, both functional and technical. Notify everyone who sees the schedule that it’s not set in stone, that’s it’s likely to change over time. Having a schedule, and honestly attempting to meet it, will force accountability to create positive progress. But you get to modify the schedule if something gets added to the product or if the stakeholders decide to make a significant change to the requirements.
  5. Using your schedule begin with phase 1 by building a rough prototype of the first part of your project. This can be on paper or using a mock-up tool. Show it to the stakeholder group that will be using this when it’s finished. Tell them that it’s just a mock-up, it’s not supposed to be perfect, but it should be functionally complete with representative buttons, text fields, display areas, lists, etc… Pencil in any additional features until everyone agrees it’s functionally complete.
  6. Build and maintain a list of risks that the project faces as it evolves. Show this list to the group leaders so they understand what might cause the project to fail. Risk can include anything from “not enough testing” to “the developer environment is too noisy”. If the stakeholders are serious about you finishing the project they will help you address the challenges you’re facing.

At this point you have something tangible that describes with great detail the challenge you must overcome.

Happy building!

Posted in General

Don’t ask for permission, just get busy

You don’t need permission (read: degree, certificate, etc…) to become a software developer. In many ways, degrees and certificates can be a waste of time, money, and effort. I can already hear the howls from folks who paid good money for degrees or certificates. The truth is that anyone can learn to make meaningful contributions without sitting through lectures or taking standardized tests. If you want to get paid to work with code and create value for your employer or client then what you do need more than anything else is a disciplined approach to learning and practicing. Learning to produce valuable output in the form of code is a skill that can be gained through practice.

Please allow me to unpack the above paragraph a little. In many ways the field of software development is still in it’s Wild West phase. There are no formal rules or codes like exist in the construction industry, developers don’t have a hippocratic oath, if it compiles it is fair game. This is the way it should be if we want maximum creativity from the profession. There are pitfalls to avoid if your approach is like throwing spaghetti at the wall. There is a core body of knowledge that doesn’t change much. It outlines a set of best practices that are trend agnostic. These ideas will make sure you’re not on one of the many here to today, gone tomorrow, development ideas that are a routine feature of this field. This is what you need to know to thrive. It’s what should be considered “the basics”. It’s a true shame that almost no formal schooling programs teach it. If you read, learn, and practice the core body of knowledge you’ll be able to make significant contributions and stay employed.

The vacuum of proper educational opportunities for people wanting to enter the field creates a casino like environment for employers. There aren’t any truly good techniques for figuring out who is good and who isn’t. Everyone is flying blind when it comes to new hires. No HR manager wants to admit this to their senior management, to do so would be career suicide. The methodology in use across the board is hire and pray. This leaves the developers with proven track records in a field virtually free of competition. This has an upside and a downside. The upside is that they get to pick and choose their assignments and demand high salaries. The downside is that they’re constantly overworked.

To be a long term successful software developer you need a voracious desire to learn, the liberty to make mistakes, an ability to laugh at your mistakes, and the humility to appreciate that you’ll never know everything. Writing software is an act of creation. All acts of creation are an endeavor of the spirit tied to an evocation of human will. The developer brings an idea to a blank screen, then time and effort yield useful functionality. As you begin to work and struggle, you will fill gaps in your knowledge and ability with grit and frustration. The grit and frustration is the learning process doing its job. This applies to almost any creative process, be it painting, writing, musical composition, etc… In time, if you stay focused and disciplined you will improve. If you’re just starting out, good for you! If you’re already moving then sustained, disciplined effort is your best friend. Some days will be better than others, occasionally it will be abysmal. There is no degree program, support group, workshop, blog, or certificate that can offer this. You are the arbiter of your success.

 

 

Posted in General