I suspect that many of you are familiar with the term "hard coding a value" whereby the age of an individual or their location is written into the condition (or action) of a business rule (in this case) as shown below:

if customer.age > 21 and customer.city == 'denver'

then ...

Such coding practices are perfectly expectable provided that the conditional values, age and city, never change. They become entirely unacceptable if a need for different values could be anticipated. A classic example of where this practice occurred that caused considerable heartache in the IT industry was the Y2K issue where dates were updated using only the last 2 digits of a four digit number because the first 2 digits were hard-coded to 19 i.e. 1998, 1999. All was well provided that the date did not advance to a time beyond the 1900’s since no one could be certain of what would happen when the millennia arrived (2000). A considerably amount of work (albeit boring) and money, approximately $200 billion, went into revising systems by way of software rewrites and computer chip replacements in order to thwart any detrimental outcomes. It is obvious how a simple change or an assumption can have sweeping consequences.

You may wonder what Y2K has to do with Business Rule Management Systems (BRMS). Well, what if we considered rules themselves to be hard-coded. If we were to write 100s of rules in Java, .NET or whatever language that only worked for a given scenario or assumption, would that not constitute hard-coded logic? By hard-coded, we obviously mean compiled. For example, if a credit card company has a variety of bonus campaigns, each with their own unique list of rules that may change within a week’s time, what would be the most effective way of writing software to deal with these responsibilities?

Below are two pdf's which discuss and outline the Java Message Service, JMS, tutorial.

One Hour Java Messaging Service Tutorial
Advanced One Hour Java Messaging Service Tutorial

 

Studying a functional programming language is a good way to discover new approaches to problems and different ways of thinking. Although functional programming has much in common with logic and imperative programming, it uses unique abstractions and a different toolset for solving problems. Likewise, many current mainstream languages are beginning to pick up and integrate various techniques and features from functional programming.

Many authorities feel that Haskell is a great introductory language for learning functional programming. However, there are various other possibilities, including Scheme, F#, Scala, Clojure, Erlang and others.

Haskell is widely recognized as a beautiful, concise and high-performing programming language. It is statically typed and supports various cool features that augment language expressivity, including currying and pattern matching. In addition to monads, the language support a type-class system based on methods; this enables higher encapsulation and abstraction. Advanced Haskell will require learning about combinators, lambda calculus and category theory. Haskell allows programmers to create extremely elegant solutions.

Scheme is another good learning language -- it has an extensive history in academia and a vast body of instructional documents. Based on the oldest functional language -- Lisp -- Scheme is actually very small and elegant. Studying Scheme will allow the programmer to master iteration and recursion, lambda functions and first-class functions, closures, and bottom-up design.

Supported by Microsoft and growing in popularity, F# is a multi-paradigm, functional-first programming language that derives from ML and incorporates features from numerous languages, including OCaml, Scala, Haskell and Erlang. F# is described as a functional language that also supports object-oriented and imperative techniques. It is a .NET family member. F# allows the programmer to create succinct, type-safe, expressive and efficient solutions. It excels at parallel I/O and parallel CPU programming, data-oriented programming, and algorithmic development.

Scala is a general-purpose programming and scripting language that is both functional and object-oriented. It has strong static types and supports numerous functional language techniques such as pattern matching, lazy evaluation, currying, algebraic types, immutability and tail recursion. Scala -- from "scalable language" -- enables coders to write extremely concise source code. The code is compiled into Java bytecode and executes on the ubiquitous JVM (Java virtual machine).

Like Scala, Clojure also runs on the Java virtual machine. Because it is based on Lisp, it treats code like data and supports macros. Clojure's immutability features and time-progression constructs enable the creation of robust multithreaded programs.

Erlang is a highly concurrent language and runtime. Initially created by Ericsson to enable real-time, fault-tolerant, distributed applications, Erlang code can be altered without halting the system. The language has a functional subset with single assignment, dynamic typing, and eager evaluation. Erlang has powerful explicit support for concurrent processes.

Computer Programming as a Career?

What little habits make you a better software engineer?

It’s the eternal conundrum of a hiring manager – you have to hire for every single position in the company without any first-hand experience. How to do it? If you can have a trusted programmer sit in on the interview, that’s ideal, of course. But what if you’re hiring your first programmer? Or what if you’re hiring a freelancer? Or what if company policy dictates that you’re the only person allowed to do the interviewing? Well, in that case, you need some helpful advice and your innate bullshit detector. We questioned programmers and hiring managers and compiled a list of dos and don’ts. Here are some things to ask when interviewing programmers:

Past Experience

Ask the programmer about the biggest disaster of his career so far, and how he handled it. Did he come in at midnight to fix the code? Was he unaware of the problem until someone brought it up? Did someone else handle it?  According to our programmer sources, “Anyone worth their salt has caused a major meltdown. If they say they haven’t, they’re lying. Or very, very green.” Pushing a code with bugs in it isn’t necessarily bad. Not handling it well is bad.

As usual, your biggest asset is not knowing the field, it is knowing people. Asking about career disasters can be uncomfortable, but if the interviewee is experienced and honest then she won’t have a problem telling you about it, and you will get an idea of how she handles mishaps. Even if you don’t understand what the disaster was or how it was fixed, you should be able to tell how honest she’s being and how she handles being put on the spot.