Tuesday, June 23, 2009

10 skills developers need in next five years

I got this this morning from ZDNetAsia , worth reading .....

"With the recent changes in the economy, a lot of developers are focused on their short-term job prospects.
At the same time, it's important to make sure that you get the most bang for your buck when it comes to taking the time and energy to learn new skills. Hence, here is our list of 10 skills you should be learning right now to make sure that your resume is relevant for the next five years.
The list is hardly exhaustive, and there are huge swaths of the industry it won't cover (mainframe developers, for example). Nonetheless, for average mainstream development, you can't go wrong learning at least seven of these skills--not only to the point where you can talk convincingly about them at a job interview, but actually use them on the job.
1: One of the "Big Three" (.NET, Java, PHP)
Unless there is a radical shift in the development world (akin to an asteroid hitting Redmond), most developers will need to know at least one of the Big Three development systems--.NET (VB.NET or C#), Java, or PHP--for the near future.
It's not enough to know the core languages, either. As projects encompass more and more disparate functionality, you'll need to know the associated frameworks and libraries more deeply.
2: Rich Internet Applications (RIAs)
Love it or hate it, in the last few years, Flash is suddenly being used for more than just animations of politicians singing goofy songs. Flash has also sprouted additional functionality in the form or Flex and AIR.
Flash's competitors, such as JavaFx and Silverlight, are also upping the ante on features and performance. To make things even more complicated, HTML 5 is incorporating all sorts of RIA functionality, including database connectivity, and putting the formal W3C stamp on AJAX. In the near future, being an RIA pro will be a key resume differentiator.
3: Web development
Web development is not going away anytime soon. Many developers have been content to lay back and ignore the Web or to just stick to "the basics" their framework provides them with.
But companies have been demanding more and more who really know how to work with the underlying technology at a "hand code" level. So bone up on JavaScript, CSS, and HTML to succeed over the next five years.
4: Web services
REST or SOAP? JSON or XML? While the choices and the answers depend on the project, it's getting increasingly difficult to be a developer (even one not writing Web applications) without consuming or creating a Web service.
Even areas that used to be ODBC, COM, or RPC domains are now being transitioned to Web services of some variety. Developers who can't work with Web services will find themselves relegated to legacy and maintenance roles.
5: Soft skills
One trend that has been going for quite some time is the increasing visibility of IT within and outside the enterprise. Developers are being brought into more and more non-development meetings and processes to provide feedback. For example, the CFO can't change the accounting rules without working with IT to update the systems. And an operations manager can't change a call center process without IT updating the CRM workflow.
Likewise, customers often need to work directly with the development teams to make sure that their needs are met. Will every developer need to go to Toastmasters or study How to Win Friends and Influence People? No. But the developers who do will be much more valuable to their employers--and highly sought after in the job market.
6: One dynamic and/or functional programming language
Languages like Ruby, Python, F#, and Groovy still aren't quite mainstream--but the ideas in them are. For example, the LINQ system in Microsoft's .NET is a direct descendent of functional programming techniques.
Both Ruby and Python are becoming hot in some sectors, thanks to the Rails framework and Silverlight, respectively. Learning one of these languages won't just improve your resume, though; it will expand your horizons. Every top-flight developer I've met recommends learning at least one dynamic or functional programming language to learn new ways of thinking, and from personal experience, I can tell you that it works.
7: Agile methodologies
When Agile first hit mainstream awareness, I was a skeptic, along with many other folks I know. It seemed to be some sort of knee-jerk reaction to tradition, throwing away the controls and standards in favor of anarchy. But as time went on, the ideas behind Agile became both better defined and better expressed.
Many shops are either adopting Agile or running proof-of-concept experiments with Agile. While Agile is not the ultimate panacea for project failure, it does indeed have a place on many projects. Developers with a proven track record of understanding and succeeding in Agile environments will be in increasingly high demand over the next few years.
8: Domain knowledge
Hand-in-hand with Agile methodologies, development teams are increasingly being viewed as partners in the definition of projects. This means that developers who understand the problem domain are able to contribute to the project in a highly visible, valuable way. With Agile, a developer who can say, "From here, we can also add this functionality fairly easily, and it will get us a lot of value", or "Gee, that requirement really doesn't match the usage patterns our logs show" will excel.
As much as many developers resist the idea of having to know anything about the problem domain at all, it is undeniable that increasing numbers of organizations prefer (if not require) developers to at least understand the basics.
9: Development "hygiene"
A few years ago, many (if not most) shops did not have access to bug tracking systems, version control, and other such tools; it was just the developers and their IDE of choice. But thanks to the development of new, integrated stacks, like the Microsoft Visual Studio Team System, and the explosion in availability of high quality, open source environments, organizations without these tools are becoming much less common. Developers must know more than just how to check code in and out of source control or how to use the VM system to build test environments. They need to have a rigorous habit of hygiene in place to make sure that they are properly coordinating with their teams. "Code cowboys" who store everything on a personal USB drive, don't document which changes correspond to which task item, and so on, are unwelcome in more traditional shops and even more unwelcome in Agile environments, which rely on a tight coordination between team members to operate.
10: Mobile development
The late 1990s saw Web development rise to mainstream acceptance and then begin to marginalize traditional desktop applications in many areas. In 2008, mobile development left the launch pad, and over the next five years, it will become increasingly important.
There are, of course, different approaches to mobile development: Web applications designed to work on mobile devices, RIAs aimed at that market, and applications that run directly on the devices. Regardless of which of these paths you choose, adding mobile development to your skill set will ensure that you are in demand for the future."

Friday, June 12, 2009

... of beetles and intelligence ...

... thinking of changing SCARAB to a MOCKINGBIRD ... fed up with dung beetles .... cute but they stink ... mockingbirds on the other hand are cute, efficient, fast ... and necessary .... all the bru ha ha over semantics and business intelligence  doesn't seem to go anywhere, not in Malaysia anyway.
Everyone's talking about semantic searches, when most of them don't even know what that means. The same goes for Green IT ; the people who are supposed to have the $ for funding R&D in Green IT think it only has something to do with planting more environment friendly veggies .......
OK. I'm starting to rant again, but all this c**p is just p******g me off. No one seems to want to address current issues at hand; stuff like actual business intelligence such as HR skill set matching, true cash flow tracking, distributed intelligence in governance etc. wonder when everyone is going to wake up and realise that they missed out spending time with their 3 year old while wasting time talking about clearing another 100 hectare forest to plant more palm oil ... Green IT ......



Thursday, June 11, 2009

dreamline ... desperation, hope and realisation...

I was listening to an old Rush album on my way to work this morning, and I wanted share the lyrics from their song 'Dreamline' from the album 'Roll The Bones' ..... please remember these are copyrighted .... it's just to inspire entrepreneurs like me who like to dream big .... :) :


He's got a road map of Jupiter
A radar fix on the stars
All along the highway
She's got a liquid-crystal compass
A picture book of the rivers
Under the Sahara

They travel in the time of the prophets
On a desert highway straight to the heart of the sun
Like lovers and heroes, and the restless part of everyone
We're only at home when we're on the run
On the run

He's got a star map of Hollywood
A list of cheap motels
All along the freeway
She's got a sister out in Vegas
The promise of a decent job
Far away from her hometown

They travel on the road to redemption
A highway out of yesterday -- that tomorrow will bring
Like lovers and heroes, birds in the last days of spring
We're only at home when we're on the wing
On the wing

When we are young
Wandering the face of the Earth
Wondering what our dreams might be worth
Learning that we're only immortal
For a limited time

Time is a gypsy caravan
Steals away in the night
To leave you stranded in Dreamland
Distance is a long-range filter
Memory a flickering light
Left behind in the heartland

We travel in the dark of the new moon
A starry highway traced on the map of the sky
Like lovers and heroes, lonely as the eagle's cry
We're only at home when we're on the fly
On the fly

When we are young
Wandering the face of the Earth
Wondering what our dreams might be worth
Learning that we're only immortal
For a limited time

We travel on the road to adventure
On a desert highway straight to the heart of the sun
Like lovers and hereos, and the restless part of everyone
We're only at home when we're on the run
On the run...


 - geddy lee, alex lifeson, neil peart-




hmm ... imported my old blog and messed up fonts ....

I decided to import my old blog's posts and realised that my posts were in pale yellow (i had a dark background then .... ). Now, I have to change all the fonts .... sigh .... so much for lazy shortcuts .....

Thursday, June 4, 2009

why a new blog?

Believe it or not I've forgotten my email address which used to start analog ravings before. So, now, in roder to bore everyone more, I've decided to move on to another new blog. Anyway, I needed to grow out of my raving moods.
Well, scarab.semantics is supposed to be a place for me to rave (again?) about my scarab project, semantics, AI, ambient intelligence, food, RPG and other stuff most people find too boring to read. And I'm hoping no one would be reading this blog.
Well, here's to another blog from me. Let's hope it lasts longer than the previous one. At least until I forget the email I used to set this up.

Tuesday, March 31, 2009

Learn to Understand Your Own Intelligence

Three years ago I listened to a lecture on cognition that changed the way I
think about intelligence. This is the crux. There are two types of
cognition. The first is normal cognition. This is the ability to
retrieve knowledge from memory. When you are asked a question on a test
and produce an answer, that’s a display of cognitive ability. The
second type of cognition is metacognition; the ability to know whether
or not you know.

Have you ever been asked a question that you knew the answer to, but
you couldn’t find the right word? This is called the “tip of the
tongue” phenomenon and I’m sure we’ve all experienced it. You know that
you know the answer, but you fail to produce it. If someone said an
answer, you would know instantly if it was correct or not. In these
cases metacognition exists without cognition.

In short, cognition is knowing, metacognition is knowing if you know or not.
Both can exist together, but many times they don’t.

How Does this Affect Intelligence?


So what importance does this have and how is it relevant to self
improvement? The fact that there are two different kinds of cognitive
ability means that there are different types of intelligence.

In traditional education, intelligence is measured by cognitive
ability. For some people this is works well. They can easily produce
everything they know on a test. But for others it doesn’t work out so
well. The people that know something cold but can’t find the right
words on a test are awarded with poor grades and considered inferior.

But does this inability make them any less intelligent? They know
the answer. If the question came up on a task, they could refer to a
book or a quick Google search. In reality they’re just as effective as
the people that aced the test. They just can’t prove it as easily.

The Importance of Knowing what you know

Unless you’re taking a test or playing Jeopardy, metacognition is
more important to success than cognition. In real life, when you’re
faced with a question the first decision is whether you know the answer
or not. With strong metacognitive ability this is easy. If you know the
answer, but can’t come up with it, you can always do a bit of research.
If you know for sure that you don’t know, then you can start educating
yourself. Because you’re aware of your ignorance, you don’t act with
foolish confidence. The person who thinks they know something that they
really don’t makes the worst decisions.

A person with poor cognitive ability, but great metacognitive
ability is actually in great shape. They might do poorly in school, but
when faced with a challenge they understand their abilities and take
the best course of action. These people might not seem intelligent at
first glance, but because they know what they know, they make better
decisions and learn the most important things.

Clever but mediocre people

At the opposite end of the spectrum are people with great cognitive
ability but poor metacognitive ability. These people are proclaimed
geniuses at a young age for acing every test and getting great SAT
scores. Unfortunately, they’ve been ruined by poor metacognition; they
think they know everything but they really don’t. They are arrogant,
fail to learn from mistakes, and don’t understand the nuances of
personal relationships; showing disdain for persons with lower
cognitive ability.

So who is superior? In a battle of wits the higher cognitive ability
prevails, but life is not a single encounter. It is a series of
experiments in succession, each building upon the last. Learning
requires knowing what you don’t know, and taking steps to learn what
you need to. People with poor metacognitive ability never realize that
they don’t ‘get it’. They also don’t realize what’s important.

This doesn’t preclude them from material success. But, perhaps
that’s a poor measurement of intelligence as well. There are many
people who become rich and successful by their cleverness and cognitive
ability, but as human beings are quite mediocre. Is the man that makes
a million dollars, but is cruel and abusive to his employees and
family, really more intelligent than the poor man who lives a modest
and loving life? I don’t intend to demonize wealth, only to state that
it should not be the measure of virtue.

Use your metacognitive ability

So what do we know and what do we not? And how can we tell the
difference? There is so much to know in the world that the most
brilliant human minds can grasp only the tiniest fraction. For this
reason we should always be in doubt of what we know. The closed mind is
oblivious to its surroundings, while the open mind absorbs them. Like a
sponge, it soaks up observations, becoming fuller and more robust.

But we can’t live in total doubt. If we did we would never act,
paralyzed by our inadequate knowledge. We must trust our intuition. If
something makes you feel a certain way, that feeling is real and must
be respected. Act based on your own convictions, not those of others,
and keep an open ear for new ideas.

The most important mental power is the ability to know what you
don’t know. The recognition of a fault is the first step to
improvement. Don’t try to hide a lack of knowledge. People will see
through it and you’ll appear foolish and arrogant. If you admit your
ignorance, people will help you learn and respect your humility. For
intelligent people this is the toughest lesson to learn. We are used to
being right, and consider being wrong shameful. We’re afraid to lose
status by looking stupid. This vain arrogance is a great weakness and
the source of many problems. To crush it and embrace humility is the
mark of true wisdom.





Tuesday, January 27, 2009

Intutive Software?

Found this article on Tech Republic while browsing my junk mail just now, and found that this is not junk at all ..... :


Would you want your brakes installed by someone who is on their first day on the job with no training and expects fixing brakes to be intuitive? I didn’t think so. But this is essentially the expectation that we have been perpetrating in this industry for years now.

Somewhere along the way we lost track of the fact that software is often used to accomplish some very complex tasks. As a result, this expectation has turned into a curse. Users now feel entitled to sit in front of any given piece of software and instantly understand its every nook and cranny. And if they can’t, it’s the software developer’s fault for not making intuitive software. This is an unrealistic expectation, and it’s time to start reversing the trend. Below I present what I perceive to be the problems that have perpetuated the myth of intuitive software, as well some potential solutions.

The problems

The first part of the problem is the idea that users who have no experience or understanding of the field of knowledge the software addresses should be able to use the software. If I sat in the cockpit of a 747, I would not expect to be able to fly it after glancing at the controls (even if I did put in countless hours of Wing Commander), yet this is the first mistake users make when blaming the software developer. “I don’t know what it means when it asks me to enter my IP address, so this software is hard to use.” Would users prefer for the software to ask for their system administrator’s e-mail address, and then automatically e-mail that person and ask them to reply with the IP address? Or, would the user want the software to provide a short tutorial on networking? If the user does not understand what an IP address is, no application should be teaching it to them; the software should be looking for a way to get the information without the user’s help.

The next part of the problem is that even users who are knowledgeable in the problem domain are not necessarily going to “get” a piece of software if the domain is sufficiently complex. Word processors are a great example. A word processor is a piece of software designed to do hundreds of tasks — everything from writing grocery lists to legal briefs to screenplays, all of which have different workflow requirements, formatting needs, and so on. Needless to say, any piece of software designed to do not just one complex task but hundreds of complex tasks is going to be complex. Given the complexity of these pieces of software, why would we expect someone who is good at writing essays out by hand to instantly “get” a word processor right away?

ERP and CRM applications are some of the favorite punching bags in the industry. It is common knowledge that a huge number (some studies show the majority) of licenses sold for applications like SAP go unused. These projects have an astoundingly high failure rate, and when you consider their sticker price, that is really unacceptable. One of the typical causes for a project to be declared a failure is that it is “dustware.” That is, after a year-long integration and millions of dollars in consulting fees and license costs, the users fire it up, stare at the screen for five minutes, shut it down, and it sits on the shelf for eternity. Well, not to give these enterprise-class vendors a free pass, but I do not think that plopping a user in front of a complex piece of software untrained and with no documentation is a good way to get them to use it. If I expect a crane operator to be trained in that piece of equipment before using it to lift 10 tons of steel, I think it’s reasonable to think that someone should be trained before using a piece of complex software.

What is most frustrating to me is that things were not always this way (at least, that’s my recollection). WordPerfect 5.1, which is often remembered with a mixture of fondness and disdain, required you to purchase a keyboard overlay, a 100 - 200 page Quick Reference guide, and have a 500 page in-depth manual on your desk to be well-equipped to use it. But the simple fact was, you really needed to read a few hundred pages of text to get the gist of what was happening before you could sit down and do real work. That was also an era when there were local users’ groups for users to get together and help each other out. In addition, companies also sent their employees to computer training.

Now employers are looking for computer savvy and computer literate employees, which seem to mean, “I can use Google to find Gmail.” Instead of teaching true computing skills, such as how to form effective search queries, how to discern which Web sites are credible, and how to maintain security of private data, schools are letting students play on Facebook and LiveJournal, and saying, “Oh, the kids are learning how to use a computer.” Nonsense. The students are learning, at best, how to use a particular Web site that will be different by the time they graduate.

Proposed solutions

Our industry needs to do more about this issue. Sure, we occasionally throw our hands in the air and spew forth a loud “RTFM!” Which would help if “TFM” wasn’t often so useless. After all, why bother writing good documentation when the only people who care to read it are those who can figure it out on their own? It’s a catch-22. So first up is the documentation. If your application is addressing complex tasks, you can’t count on an intuitive interface.

A complex task will require either a ton of walk-through style wizards (which power users hate and even beginners eventually outgrow); or an interface like a command line; or a toolbar crammed with buttons, lots of keyboard shortcuts, or some other way of packing a lot of functionality into a small screen space. And with interfaces like that, the documentation needs to be better. Unlike a wizard-driven interface, you do not have a paragraph to explain each choice; at best, you have a tooltip to explain what function the icon represents. Users in these situations need to be able to rely upon the documentation to give them in-depth information.

A fallacy is that in order for software to be intuitive, it needs to be different from the “hard to use” products on the market. Networking devices are a good example. If I were to market a networking device, I would do my best to emulate the Cisco IOS to the most minor detail. Even though the Cisco IOS is not intuitive (in fact, it is one of the most consistently miserable pieces of software I have ever dealt with), nearly every network administrator has spent a lot of time learning the intricacies of IOS. By emulating a really obnoxious system, you are actually working with existing user knowledge. You see this a lot in the *Nix world. Because so much of *Nix counts on pipes and redirects, applications tend to implement the I/O patterns of existing applications in order to be a drop-in replacement, even if they support their own (and probably better) I/O as well. If you are trying to break into an existing market, you will want to provide a UI that looks like the current king, even if you have a better one as an alternative. If possible, try to use both, with an easy way of switching between the two.

We also need to stop counting on the community to provide support for us. A huge temptation, particularly in the current economic climate, is to put some freeware wiki or forum software on a server, link to it from the Support section of the Web site, and expect that users will train each other. I am not saying this doesn’t happen or telling you not to set up a wiki or a forum. I’m saying that even with these tools, your staff will need to spend a lot of time on the wiki or forum and provide many (if not most) of the answers — at least until you get a number of MVPs on board and editing the wiki.

Also, I would like to see more new user and experienced user modes for software, particularly in super-complex applications. It would be even better if the software could seamlessly transition on a feature-by-feature basis. For example, once a user does Task A a few times without too much help, the software stops using wizards, but the first time a user does Task B, the software still has him in training wheels mode. I think this would be a great way to combine the promises of agent-based systems with the guidance of wizards and hands-on tutorials.

Finally, let’s get honest and drop the “easy to use” bullet point in our marketing materials when possible. Instead, we need to start putting in good tutorials and have our sales reps offer free (or highly discounted) training. What do you think costs your company more money: sending a trainer on site for a week to get new users up to speed, or not having a customer renew its license because no one ever used the system and then bad-mouth your software to boot? In the long run, it makes more sense to give free (or highly discounted) on-site training to big accounts and free online training to smaller accounts than it does to lose the upgrade fees.

In conclusion, software does not need to be intuitive to users who don’t know the field; and even for users who understand the work, complex tasks are going to have complex software. But, software developers need to keep finding ways to make sure that users get up to speed and can fly on their own.

..Original article appeared on MSDN by Justin James, this is a commented and edited version by analogkid..