When making a strategic cloud decision, organizations can follow either one of two ideologies: open or closed.

In the past, major software technologies have been widely accepted because an emerging market leader simplified the initial adoption.  After a technology comes of age, the industry spawns open alternatives that provide choice and flexibility, and the result is an open alternative that quickly gains traction and most often outstrips the capabilities of its proprietary predecessor.

After an organization invests significantly in a technology, the complexity and effort required steering a given workload onto a new system or platform is, in most cases, significant. Switching outlays, shifting to updated or new software/hardware platforms, and the accompanying risks may lead to the ubiquitousness of large, monolithic and complex ERP systems – reason not being that they offer the best value for an organization, but rather because shifting to anything else is simply – unthinkable.

There’s no denying that these are critical considerations today since a substantial number of organizations are making their first jump into the cloud and making preparations for the upsetting shift in how IT is delivered to both internal and external clientele. Early adopters are aware of the fact that the innovation brought about by open technologies can bring dramatic change, and hence are realizing how crucial it is to be able to chart their own destiny.

The world of technology moves faster than the speed of light it seems. Devices are updated and software upgraded annually and sometimes more frequent than that.  Society wants to be able to function and be as productive as they can be as well as be entertained “now”.

Software companies must be ready to meet the demands of their loyal customers while increasing their market share among new customers. These companies are always looking to the ingenuity and creativity of their colleagues to keep them in the consumer’s focus. But, who are these “colleagues”? Are they required to be young, twenty-somethings that are fresh out of college with a host of ideas and energy about software and hardware that the consumer may enjoy? Or can they be more mature with a little more experience in the working world and may know a bit more about the consumer’s needs and some knowledge of today’s devices?

Older candidates for IT positions face many challenges when competing with their younger counterparts. The primary challenge that most will face is the ability to prove their knowledge of current hardware and the development and application of software used by consumers. Candidates will have to prove that although they may be older, their knowledge and experience is very current. They will have to make more of an effort to show that they are on pace with the younger candidates.

Another challenge will be marketing what should be considered prized assets; maturity and work experience. More mature candidates bring along a history of work experience and a level of maturity that can be utilized as a resource for most companies. They are more experienced with time management, organization and communication skills as well as balancing home and work. They can quickly become role models for younger colleagues within the company.

Unfortunately, some mature candidates can be seen as a threat to existing leadership, especially if that leadership is younger. Younger members of a leadership team may be concerned that the older candidate may be able to move them out of their position. If the candidate has a considerably robust technological background this will be a special concern and could cause the candidate to lose the opportunity.

Demonstrating that their knowledge or training is current, marketing their experience and maturity, and not being seen as a threat to existing leadership make job hunting an even more daunting task for the mature candidate. There are often times that they are overlooked for positions for these very reasons. But, software companies who know what they need and how to utilize talent will not pass up the opportunity to hire these jewels.

 Related:

H-1B Visas, the Dance Between Large Corporations and the Local IT Professional

Is a period of free consulting an effective way to acquire new business with a potential client?

Let’s face it, fad or not, companies are starting to ask themselves how they could possibly use machine learning and AI technologies in their organization. Many are being lured by the promise of profits by discovering winning patterns with algorithms that will enable solid predictions… The reality is that most technology and business professionals do not have sufficient understanding of how machine learning works and where it can be applied.  For a lot of firms, the focus still tends to be on small-scale changes instead of focusing on what really matters…tackling their approach to machine learning.

In the recent Wall Street Journal article, Machine Learning at Scale Remains Elusive for Many Firms, Steven Norton captures interesting comments from the industry’s data science experts. In the article, he quotes panelists from the MIT Digital Economy Conference in NYC, on businesses current practices with AI and machine learning. All agree on the fact that, for all the talk of Machine Learning and AI’s potential in the enterprise, many firms aren’t yet equipped to take advantage of it fully.

Panelist,  Michael Chui, partner at McKinsey Global Institute states that “If a company just mechanically says OK, I’ll automate this little activity here and this little activity there, rather than re-thinking the entire process and how it can be enabled by technology, they usually get very little value out of it. “Few companies have deployed these technologies in a core business process or at scale.”

Panelist, Hilary Mason, general manager at Cloudera Inc., had this to say, “With very few exceptions, every company we work with wants to start with a cost-savings application of automation.” “Most organizations are not set up to do this well.”

Python and Ruby, each with roots going back into the 1990s, are two of the most popular interpreted programming languages today. Ruby is most widely known as the language in which the ubiquitous Ruby on Rails web application framework is written, but it also has legions of fans that use it for things that have nothing to do with the web. Python is a big hit in the numerical and scientific computing communities at the present time, rapidly displacing such longtime stalwarts as R when it comes to these applications. It too, however, is also put to a myriad of other uses, and the two languages probably vie for the title when it comes to how flexible their users find them.

A Matter of Personality...

That isn't to say that there aren't some major, immediately noticeable, differences between the two programming tongues. Ruby is famous for its flexibility and eagerness to please; it is seen by many as a cleaned-up continuation of Perl's "Do What I Mean" philosophy, whereby the interpreter does its best to figure out the meaning of evening non-canonical syntactic constructs. In fact, the language's creator, Yukihiro Matsumoto, chose his brainchild's name in homage to that earlier language's gemstone-inspired moniker.

Python, on the other hand, takes a very different tact. In a famous Python Enhancement Proposal called "The Zen of Python," longtime Pythonista Tim Peters declared it to be preferable that there should only be a single obvious way to do anything. Python enthusiasts and programmers, then, generally prize unanimity of style over syntactic flexibility compared to those who choose Ruby, and this shows in the code they create. Even Python's whitespace-sensitive parsing has a feel of lending clarity through syntactical enforcement that is very much at odds with the much fuzzier style of typical Ruby code.

For example, Python's much-admired list comprehension feature serves as the most obvious way to build up certain kinds of lists according to initial conditions:

a = [x**3 for x in range(10,20)]
b = [y for y in a if y % 2 == 0]

first builds up a list of the cubes of all of the numbers between 10 and 19 (yes, 19), assigning the result to 'a'. A second list of those elements in 'a' which are even is then stored in 'b'. One natural way to do this in Ruby is probably:

a = (10..19).map {|x| x ** 3}
b = a.select {|y| y.even?}

but there are a number of obvious alternatives, such as:

a = (10..19).collect do |x|
x ** 3
end

b = a.find_all do |y|
y % 2 == 0
end

It tends to be a little easier to come up with equally viable, but syntactically distinct, solutions in Ruby compared to Python, even for relatively simple tasks like the above. That is not to say that Ruby is a messy language, either; it is merely that it is somewhat freer and more forgiving than Python is, and many consider Python's relative purity in this regard a real advantage when it comes to writing clear, easily understandable code.

And Somewhat One of Performance