Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


 
 
Posted by Sandeep Chanda on December 12, 2014

ECMAScript 6, the latest version of ECMAScript standard, has a host of new features added for JavaScript. Many of the new features are influenced towards making JavaScript syntactically similar to C# and CoffeeScript. Features such as function shorthand are introduced in the form of Arrows =>.

 iterateItemsInCollection() {
    this.coll.forEach(f =>
     //operate on item f;
  } 

Another noticeable feature is the class construct. Classes are based on the prototype-based object oriented pattern and support inheritance methods (static and instance) and constructors.

The most interesting new feature, however, is the introduction of Object.observe(). Note that Object.observe() is going to be available only with ES7.

Object.observe() is touted to be the future of data binding. A new upgrade to the JavaScript API, Object.observe() lets you asynchronously observe changes (adds, updates, deletes) to a JavaScript object. That means you can implement two-way data binding using Object.observe() without using any frameworks (KO, Angular…). Does this mean Object.observe() is set to obliterate frameworks such as Knockout, Angular, Ember? Not really, If it's just data binding, you can obviously use Object.observe(), but most frameworks today provide more than just data binding (e.g., routing, templates, etc.) and may be inevitable for bigger complex projects.

Object.observe() brings great performance boost over traditional dirty-checking used while implementing data binding. Testimony to this fact is that Angular team has decided to rewrite data binding implementation in Angular 2.0 using Object.observe(). As an API with great promise, Object.observe() is surely going to change a lot in the way we build client apps. You can read more here.


Posted by Sandeep Chanda on December 4, 2014

The web has come a long way from its standards being largely controlled by two major browser makers — Netscape & Microsoft, who largely dictated web standards based off of what those two browsers supported with every new release. New players (Firefox, Chrome, Opera) entered the web battleground and helped move the web towards standardization. The tipping point was reached when the web stack got a major upgrade in the form of HTML5, CSS3 and additions to JavaScript API. The future looks bright for web development with amazing new features being added to the web platform. Here are some of the prominent features that will be available to web developers to use in the not so distant future:

Web Components — Web Components is a set of cutting edge standards that allows us to build widgets for the web will full encapsulation. The encapsulation inherent in the web components solves the fundamental problem with widgets built out of HTML & JavaScript as the widget isn't isolated from the rest of the page and global styles. The main parts comprising Web Components are:

  1. HTML Templates — Reusable templates/html fragments. Read more.
  2. Shadow DOM — This is what enables encapsulation for a section of an html page/widget by introducing a new element (known as 'shadow root') in the DOM tree. Read more.
  3. Custom Elements — Custom elements are probably the best new thing available out of the box for web developers as they allow us to define new HTML elements without the need for an external library (if you've used angularjs, think custom directives). With custom elements you can have something like below in your html
    <contoso-timeline></contoso-timeline>

    Assuming contoso is the namespace under with your timeline control goes. That one line encapsulates the complete functionality of the timeline control. Neat! Read about custom elements in more detail.

Google has released an amazing library called Polymer that is worth a look. It's essentially a polyfill for web components.

Not all browsers support Web Components today. The latest builds of Chrome & Opera do have the support for web components. What features are supported by which browsers can be checked at caniuse.com.

To get a sense of what is coming in the future releases of each browser, you can check the respective bleeding edge versions —  Chrome Canary, Firefox Nightly, Opera Next and IE.


Posted by Sandeep Chanda on November 28, 2014

Earlier this month Google released its material design specifications. Material design talks about a synergy from principles of good design and applying modern techniques in science to create a specification that provides seamless experience to users across devices. The Material Design specification is a living document and continues to get updated on a regular basis. The inspiration behind the design elements are real life cues like surfaces, and first class input methods like touch, voice, and type. The material design specification provides a unified guidance on animation aspects like responsive interaction, style elements like colors and typography, and layout principals. It also provides guidelines on UI components like Text Fields, Buttons, Grids, etc.

Material UI is a Less based CSS framework created based on the Google's Material Design specifications. It is available as a Node package. Material UI provides the mark-up for various UI components and also less variables for the color palette and classes for typography. You can use the NPM console to install the node module and then use the React library to start building your UI. In addition, you can use Browserify to perform the JSX transformation.

Here is the command to install Material UI:

npm install material-ui

Now that you have installed the Material UI in your application, you can start coding your UI using the components.

First step is to dependency inject the Material UI instance:

var react = require('react'),
  materialUI = require('material-ui'),
  LeftMenu = materialUI.Menu; 

Next you create a react class to render the Material UI component:

var navigationMenu = react.createClass({
  render: function() {
    return (
        <Menu menuItems={this.props.items} />
    );
  }
});

Finally you can render the UI component using the React.render function.

React.render(<LeftMenu items={ labelMenuItems } />, mountNode); 

You are all set to create some great UI elements using the Material Design specifications and Material UI!


Posted by Jason Bloomberg on November 25, 2014

Perhaps you have noticed that my Twitter handle is @theebizwizard. You may have even noticed that my Skype handle is as well. It occurred to me that I’ve never told the story about that handle. I’d say it’s about time.

Ebusiness, as we gray-haired geezers are happy to relate, is a hype term from the dot.com crazy period of the late 1990s. The e prefix stands for electronic, as in e-mail. Well, if we can electronic-ify our mail into email, and we can electronic-ify our commerce into ecommerce, let’s take the next step and do the same thing with our entire business!

The core idea made perfect sense. Even as long ago as the 20th century, many businesses became increasingly dependent on their IT, and in some cases, we could even say that their business was IT. Take banking, for example. Money was no longer cash in a drawer, it was bits on a wire. Everything a bank does touches its technology.

But then two things happened to this essentially good idea. First, the pundits and vendors took the term and hype-ified it, essentially turning ebusiness into dot.com insanity, the enterprise version. Ebusiness rode the wave up to the top and predictably crashed along with the rest of the dot.com nonsense.

The second thing that happened to ebusiness, however, is more important. We finally realized that even ebusinesses aren’t made up entirely of technology. In reality, businesses are made up of people, just as they have been since the dawn of commerce back in the stone ages. Technology only gives us tools – increasingly powerful tools, but tools nevertheless.

What about Wizard?

There’s more to the theebizwizard story, however – the word wizard. This story begins in 1996, when my first wife and I were thinking about buying a mansion in Pittsburgh and turning it into a bed and breakfast. We never ended up buying the mansion, but I did buy the domain name rhodes.com, as a fellow named Rhodes originally owned the mansion.

It may be hard to believe now, but in those days it was bad form to own domain names you weren’t using, so I turned rhodes.com into my personal web site. For my email address I concocted wizard@rhodes.com – to indicate I could have selected any email address, not to indicate any kind of magical ability on my part.

For the next eleven years my personal email was wizard@rhodes.com and my personal web site was at www.rhodes.com, where I hosted my JavaScript and Java games. People would periodically ask to buy the domain or flame me for owning it, but I resisted, setting what I thought was an outrageously high price.

But to my surprise, in 2006 someone agreed to my price -- $50,000. For a domain name! It seemed the dot.com craziness hadn’t entirely gone away after all. (The buyer put up a tourist site promoting Rhodes, Greece, until they went out of business. To this day www.rhodes.com is still on the market.)

So, to make a long story, well, even longer, when it came time to create a Twitter handle, I put together ebusiness and wizard – not to indicate I was a wizard at ebusiness (although thank you for thinking that!) but rather as a reminder of the two sides of hype. Yes, ebusiness as a term came and went, but the fact I was able to sell a domain name for more than I made in two years as a high school teacher shows the true power of hype if you know how to use it (or if you just get lucky).

Now It’s Digital

In the 2000s, I successfully rode the SOA hype term up and then down. Today I’m doing the same thing with digital transformation. I’m the first to admit this new term – especially the word digital – has its flaws, but it represents a set of very powerful and important ideas nevertheless.

In fact, we’ve come full circle with this story, as digital business more or less means the same thing as ebusiness. Admittedly, today digital technologies include mobile and social media, where ebusiness focused primarily on the web, so the technology story today is noisier and more confusing. But the fundamental principles still remain: in particular, the fact that digital is about people.

Today, the fundamental driving force behind digital transformation is the shifting preferences and behaviors of users – either consumers or employees, who after all, are also consumers. Consumers demand multiple technology touchpoints, and it is for that reason (and only that reason) that digital is about technology at all.

Nevertheless, people are missing this fundamental point, just as they did with ebusiness back in the day. It seems that every day I spot yet another digital consultant or digital analyst hanging out their shingle, promising to help companies with their digital strategies. And what do those strategies consist of? Mobile strategies. Twitter strategies. Even web strategies. The list goes on and on. In other words, technology strategies.

What about customer strategies? Not sexy enough. Businesses have needed customers since the dawn of time, after all. What’s new or exciting about that? Today, people are confused about mobile and social media and don’t even get me started about the Internet of Things. Those are the hot topics! And hot topics are where the money is!

Well, yes and no. Yes, there’s money in hype – that’s the lesson wizard@rhodes.com taught me, after all. But never forget that people are – and will always be – at the center of business. Even ebusiness, or now, digital business.

Avoid Shiny Things

The reason it’s so easy to miss this fundamental principle is due to what I like to call the shiny things problem. People like shiny things, after all. Why? Because they’re shiny. The shinier the better. And if something is really shiny, you’ll forget all about what problem you’re trying to solve.

Techies frequently fall for shiny things. It seems that every new programming language or open source product is the next shiny thing. Ooh, Haskell! We gotta program in Haskell! Docker! We gotta use Docker! Etc. Etc. Believe it or not, SOA was a shiny thing in its day. I spent half a day in my SOA class trying to convince a roomful of architects that if something ain’t broke, don’t fix it. Don’t do SOA because it’s shiny!

Now digital transformation is the next shiny thing. People want it because, well, because it’s shiny! My advice: don’t fall for the shininess trap. Sometimes you do really need shiny things, and then by all means, go for it. But start with the problem you’re trying to solve. In the case of digital transformation, that starting point always centers on the customer, not the technology.


Posted by Jason Bloomberg on November 19, 2014

I’ve started using the phrase digital professional, in particular in my recent article dinging Amazon’s cloud division Amazon Web Services (AWS) for not having a clear digital strategy. However, I haven’t been very clear on what I mean, so it’s time to put a finer point on this terminology.

The role of digital professional begins back in the 1990s with the rise of the web professional: people who worked on web sites in some capacity. Some of them were technical, able to sling HTML or JavaScript or perhaps Perl back in the day.

Others were designated as creatives, including graphic designers and the like. A third subset of the web professional community were the marketing people: hammering out web strategies, focusing on key performance indicators like conversions and churn, and figuring out how to communicate to users using this newfangled World Wide Web of ours.

And finally, there were the information architects, designing page flows and form interactions, making sure site maps made sense and navigation worked as expected.

On Beyond the Web

Cut to 2014, and the digital professional sports all these roles and more. Today digital is much more than the web, as it also comprises mobile, social media, and a burgeoning class of newer technology touchpoints that are currently undergoing a phase of rapid, disruptive innovation – everything from iBeacons to thermostats and other consumer-facing parts of the Internet of Things (IoT). We might classify anybody who works in any of these areas as a digital professional.

However, in spite of its technology-centric label, digital is not really about the technology per se. What’s important about digital today is the fact that customer preferences and behavior are driving organizations’ technology choices – most notably in the B2C world, but also in B2B as well.

Digital transformation, therefore, includes more than technology change. The real transformation is organizational, as customers are driving enterprises to change the way they do business in fundamental ways.

Transforming the Role of Marketing

This transformative nature of digital predictably impacts the roles of digital professionals. While the first-generation web was first and foremost a marketing channel, digital goes well beyond marketing – or from another perspective, marketing itself is undergoing a digital transformation.

If we define marketing broadly as the part of an organization responsible for communicating with current and prospective customers, then digital is shifting and expanding the roles of marketing to include data scientists, engineers, and architects of many varieties, as well as operational personnel, both on the business side as well as within IT.

As a result, digital teams tend to be cross-organizational. For innovative enterprises, these teams should be self-organizing and only loosely connected to the management hierarchy of the rest of the organization. Most importantly, digital teams should not contain only techies. They should have a mix of different skillsets from different parts of the organization, where ideally the team self-selects and self-organizes to tackle the task at hand.

Will Everyone Be a Digital Professional?

My definition of the digital professional is necessarily quite inclusive. However, while it might sound like everyone in the organization falls into this category, such an eventuality is unlikely and often undesirable. Certainly, as enterprises ramp up their digital transformation efforts, most of the organization will have a much broader variety of roles and goals than the members of the digital teams.

Even as digital transformation takes hold, I would expect only some organizations to end up essentially becoming all-digital. True, it’s possible some web-scale companies may fall into this extreme case (Netflix and Spotify come to mind as possibilities), but it’s unreasonable to expect every bank or manufacturer or government agency to transform into the next Netflix.

Nevertheless, even for traditional enterprises, digital transformation will spread horizontally across the organization, recasting and re-purposing people as they shift from their traditional roles to becoming digital professionals. You don’t need to be a techie in IT, and you don’t need to be a web guru to qualify. But you do need to focus on the shifting needs and preferences of your customer.


Posted by Sandeep Chanda on November 17, 2014

With the recent release of Visual Studio 2015 Preview, the on premise Release Management feature is now introduced in Visual Studio Online. Release management allows you to create a release pipeline and orchestrate the release of your application to different environments. Using the Visual Studio Online edition for release management allows you to scale your release operations on demand and realize the benefits of using a cloud based service.

The Visual Studio Release Management client is what you will still use to configure releases in your Visual Studio Online account.

Specify your Visual Studio Online URL to connect and start configuring the release template. There are four stages to configuring release management in Visual Studio Online.

  1. First you need to configure the environment. This would include among other steps, configuring the different stage types to represent the steps to production.
  2. Next you need to configure the environment and server paths.
  3. Once you are done with the first two steps, you can then create a release template. If you are using any tools you can add them. You can also add your actions to augment the built-in release management actions.
  4. Start managing the release.

You could potentially define your stages as testing (/ QA), pre-production (/ UAT), and then finally production. Configure these under the stage types as shown below. The goal is to configure them in the line up to production which is the ultimate release you will manage.

In addition, you can also optionally specify the technology types to determine what is supported by each environment.

Next step, you should configure your environment for release. If this is a Microsoft Azure environment, then you can directly retrieve the details from your subscription as illustrated below.

If you have PowerShell scripts from an existing application to deploy to an environment, you can use them directly without using an agent. Alternatively you can also use an agent to deploy.

Next step you can define custom actions that you will use during the release management process. Predefined release management actions for some common activities are already available with the client and are supported in Visual Studio Online as the following figure shows:

You are now all set to create the release template components and then use them to build an automated or approval based release process.

The release template provides a workflow style interface to allow you configure different stages in the release pipeline. You can also use tagging to allow reusing stages across environments.

Visual Studio 2015 is bringing a host of new additions including significant ones around developer productivity. Watch out for a future post on them!


Posted by Jason Bloomberg on November 13, 2014

OK all you techies, time to go back to English class. The word “data” is the plural of “datum.” If you use either word improperly, I’ll hit your knuckles with a ruler, so pay attention.

Wrong: This data is important.

Right: These data are important.

Wrong: Big data is useful when we use it properly.

Right: Big data are useful when we use them properly.

Wrong: Which piece of data am I looking at?

Right: Which datum am I looking at?

And so on. Now, before you freak out and realize your entire existence has been meaningless up to this point because you never saw a datum in your life, relax. Most language experts admit that correctness follows common usage, and since people commonly use the word “data” as though it were singular, that means it’s OK to do so. So carry on, you wretched English destroyers, you.

Common usage or not, treating “data” as plural is still correct. It’s up to you whether you wish your language to be correct, and presumably, as long as people understand you then it doesn’t matter in many situations. But in other situations, it’s important to be correct – or at least to know what is correct, so that if you break the rules, you do so intentionally.

In my writing, I predictably use the word “data” quite frequently, and I endeavor to use it properly every time. And while correctness is important to me, I’m willing to break rules when I feel like it. After all, the previous sentence began with “and,” now didn’t it? In the case of “data,” however, I stick to the rule book for a particular reason.

Data, you see, are inherently plural. When we have a data set, we have a set of many things, not just one thing. In many cases those data are varied and diverse. Especially in today’s big data world, our data are likely to be quite heterogeneous. Referring to them in the plural, therefore, emphasizes both the diversity and the discreteness of our data.

“Information,” however, is a collective noun. We cannot count our information the way we can count our data. We never say “informations” – and for good reason. Information is fluid. It’s difficult to quantify, unless we break it down into data first. And most importantly, information depends upon the recipient: data only become information if there is at least potentially a person on the receiving end that can understand it. Otherwise they’re just noise.

Each datum can be thought of as made up of individual bits or bytes, concrete units that we can count, move, and calculate with. Information, in contrast, must inform – an essential abstraction of the data that brings humans into the loop. Emphasizing this distinction is why I always treat “data” as plural. Break this rule if you wish, but remember, I still have my ruler.


Posted by Jason Bloomberg on November 6, 2014

I attended a Business Architecture/Enterprise Architecture power panel yesterday at the Building Business Capability conference in Miami. Since I knew two of the panelists personally, I expected a lively conversation—and in that respect I wasn't disappointed.

However, there was one word that nobody mentioned the entire session, neither panelists nor audience members: agility.

From my perspective, agility is—or at least, should be—the primary driver for Enterprise Architecture (EA), as well as Business Architecture, for that matter. But no one seemed to be on the same page.

True, there was a discussion of change, and John Zachman did state that the primary reason to do EA is to help organizations change. But no one suggested that EA should help organizations become better at dealing with change. And therein lies the critical distinction.

EA (as well as Business Architecture) have long clung to the "final state" myth. If we can define a final state and help the organization get there, then we can consider ourselves successful. By then, of course, the desired state will have changed, so we pick up our skirts and rush to the new destination, bouncing from one purported final state to another, as though we were trying to pounce on some kind of enterprise leprechaun moving his pot of gold.

It's time to stop the madness! Jumping from one illusory goal to another doesn't serve our organizations well. Instead, let's raise our game. Focus on embracing change. Live it. Breathe it. That's what business agility is all about.

And for what it's worth, nobody mentioned the word innovation, either. Why am I not surprised?


Posted by Sandeep Chanda on November 3, 2014

Web Components are redefining the way you build for the web! They are touted to be the future of web development and are definitely showing a lot of promise. Web Components allow you to build widgets that can be used reliably and will be resilient to changes in the future—as opposed to the current approach of building them using HTML and JavaScript.

The real issue in the current approach with HTML and JavaScript is that the widgets that are build using them are not truly encapsulated in the DOM from one another, leading to cross references and ultimately errors in the rendered layout. You cannot easily isolate content from the widget presentation, making it difficult to build widgets that can be reused in a reliable fashion.

Web Components expose some powerful features like Shadow DOM and Templates that are built for DOM encapsulation and reuse in the form of widget templates allowing you to separate content from the infrastructure. Note that Web Components are designed around HTML and JavaScript, so there is no new skill you need to learn to start leveraging them right away.

Shadow DOM is comprised of a feature called shadow root to support the DOM encapsulation process. Browsers supporting Web Components (e.g. Chrome 35+) recognize a JavaScript method called createShadowRooton HTML elements that allows the element to update its content by overriding the predefined content from the static mark-up. This is used in conjunction with new supported tags like template and content to create reusable widgets. Here is an example in code:

<template id="detailsTagTemplate">
<style>
…
</style>
<div class="details">
<content></content>
</div>
</template>

The JavaScript code will look like:

document.querySelector('#detailsTag').textContent = [your message goes here]; 

This can create magic by dynamically allowing you to project different content inside the details DIV tag. The template element is never rendered and the content tag replaces the text content with your message. This combination opens up a plethora of opportunities, letting you create reusable widgets and use them in your applications without having to worry about cross references.


Posted by Jason Bloomberg on October 30, 2014

The latest cyberattack to hit the news is POODLE (Padding Oracle on Downgraded Legacy Encryption). While POODLE wins points for both the cutest title and including Oracle in its name, I’m cheering it on for a different reason.

POODLE compromises the obsolete protocol SSL 3.0. That alone wouldn’t be a big deal, but it’s sneakier than that, since it tricks browsers and other applications that use more recent, more secure transport-layer security protocols to downgrade to SSL 3.0, thus becoming vulnerable to attack.

The best way to protect yourself from POODLE is to disable SSL 3.0 across your entire IT environment – servers, browsers, the lot.

And that’s why I’m cheering. You see, the bane of many an IT manager’s and web developer’s existence is Internet Explorer Version 6. This browser version has been obsolete for years, but numerous enterprises still insist on remaining standardized on it. It doesn’t support HTML 5, which is one of the many reasons web developers hate it. But that deficiency alone hasn’t forced shops to switch browsers.

The good news, however, is that IE 6 doesn’t support any transport-layer security protocol newer than SSL 3.0. So not only can POODLE drive a big truck through IE 6’s security defenses, but now every IT shop must disable all SSL 3.0 support to protect the rest of its applications. And that means finally getting rid of IE 6 once and for all.

Hallelujah!


Sitemap