Altabel Group's Blog

Archive for October 2013

After Apple slammed Microsoft for gouging customers and designing tablets that nobody wants, Microsoft has fired back, saying that you can’t get real work done with iPads or its anemic iWorks productivity suite, and that iPads are little more than toys. Who’s right in the increasingly nasty war of words?

At Apple’s iPad launch, CEO Tim Cook and others zinged Microsoft for charging $99 a year for Office, charging $199 for people to upgrade to Windows 8, and for having a confused tablet strategy. CEO Tim Cook said about Microsoft:

“They’re confused. They chased after netbooks. Now they’re trying to make PCs into tablets and tablets into PCs. Who knows what they’ll do next? I can’t answer that question, but I can tell you that we’re focused.”

Microsoft is striking back, and striking back hard, esssentially claiming that you can’t get serious work done on an iPad, and that the only reason Apple is now giving away its iWorks suite is that no one wants to buy it. On the Official Microsoft Blog, Frank Shaw, Corporate Vice President of Communications at Microsoft noted the criticisms that Apple had aimed at Microsoft, and shot back:

“Seems like the RDF (Reality Distortion Field) typically generated by an Apple event has extended beyond Cupertino.”

And then he took off the kid gloves, criticizing Apple’s new iPads as overpriced, iWork as a pointless piece of software, and saying they don’t stack up against Surface tablets when it comes to productivity. He wrote:

“Surface and Surface 2 both include Office, the world’s most popular, most powerful productivity software for free and are priced below both the iPad 2 and iPad Air respectively. Making Apple’s decision to build the price of their less popular and less powerful iWork into their tablets not a very big (or very good) deal.”

He said iPads were not suitable for getting real work done, and that the reason Apple is giving away iWork for free is that no one wants them, as shown by their $10 price for iOS, or $20 for Mac OS X. He wrote:

“…it’s not surprising that we see other folks now talking about how much ‘work’ you can get done on their devices. Adding watered down productivity apps. Bolting on aftermarket input devices. All in an effort to convince people that their entertainment devices are really work machines.

“In that spirit, Apple announced yesterday that they were dropping their fees on their ‘iWork’ suite of apps. Now, since iWork has never gotten much traction, and was already priced like an afterthought, it’s hardly that surprising or significant a move. And it doesn’t change the fact that it’s much harder to get work done on a device that lacks precision input and a desktop for true side-by-side multitasking.”

And he concluded that when it comes to getting real work done, Apple is far behind Microsoft:

“So, when I see Apple drop the price of their struggling, lightweight productivity apps, I don’t see a shot across our bow, I see an attempt to play catch up.”

Who’s right here? When it comes to the productivity argument, Microsoft is. There’s absolutely no doubt that a Surface Pro 2 tablet equipped with a Touch Type 2 keyboard and a free version of Office is a far more effective tool for getting serious work done than an iPad with iWork. In essence, the Surface Pro with the Touch Type 2 keyboard is an ultrabook. An iPad with iWork is…well, an iPad with iWork. In other words, fine for light work. Not well-suited for serious work.

But when it comes to the tablet market and to sales, Apple is right. For now, tablet buyers don’t care about doing heavy-duty work on them. Checking email, browsing the Web, running apps, and light memo writing, are all well-suited for tablets. And that’s all many people need to do for their work.

So in the tablet battle, Microsoft’s Surface may be on top for productivity. But when it comes to the bottom line and sales, Apple is still cleaning up.
 

Kristina Kozlova

Marketing Manager

 

altabel

Altabel Group

Professional Software Development

E-mail: contact@altabel.com
www.altabel.com

The pundits would have you believe there is a popular debate and a difficult decision among IT architects – whether to go with a private cloud deployment, public cloud deployment, or a hybrid combination. They say the decision comes down to factors that are individual to each organization. But the truth is, there really is no debate at all (at least there shouldn’t be).

Private cloud is inefficient. It is built on a model that encourages bad overprovisioning. In fact in order to get maximum benefit from private cloud – true elasticity – you have to overprovision. The public cloud, on the other hand, is the most widely applicable and delivers the most value to a majority of businesses.

Here is why the public cloud should be your only consideration:

#1 The need for regulatory compliance. Security or privacy regulations and audits are often years behind the industry, but their rules can be challenged. We’ve seen customers exceeding auditors’ expectations, make a case for their architecture, and win the day, providing them with all the benefits of a public cloud architecture with all the security needed by common regulatory requirements, even HIPAA, SOX, or DOD standards. This is hard to replicate with private clouds, because with internal data protection you are going to have internal SLAs and internal compliance checklists, which require frequent upkeep, higher costs and a more complicated infrastructure.

#2 Start-up companies need the public cloud. These companies are often involved in development with uncertain requirements. They don’t know what they might need day-to-day. And many can be on a very tight timeline to get their products to market. These situations mandate a public cloud deployment, like AWS, where more or less resources can be configured and absorbed in a matter of minutes. While they might maintain a small infrastructure onsite, the majority of their infrastructure simply has to be in the public cloud.

#3 Security needs to be a primary concern for any cloud-based deployment. Web and cloud security can change very quickly; and some perceive a public cloud infrastructure to be more vulnerable than a private cloud, but that’s actually a misconception. A private cloud allows IT to control the perimeter; but it’s also responsible for staying on top of a rapidly shifting security landscape and making all required fixes, updates, and upgrades. Public clouds take care of all that. Data is protected by both managed security on a software and physical level, since large-scale data centers like those used by public cloud providers have state-of-the-art security. For example, more than half of the U.S. Government has moved to the public cloud; and surprisingly the banking industry holds the most activity (64 percent) in the public cloud – over social media, online gaming, photo applications, and file sharing. [IT Consultants’ Insight on Business Technology, NSK Inc., “7 Statistics You Didn’t Know About Cloud Computing.”]

#4 The need for redundancy and disaster recovery. To truly make a private cloud redundant, you need to host virtual mirrors of the entire infrastructure across multiple hosted providers, which can be public clouds themselves. To keep it completely private, organizations need to run those data centers itself – a vastly expensive proposition. There really isn’t a better choice for this scenario than a well architected cloud deployment. Taking AWS as an example, this cloud can be incredibly redundant if you take advantage of its lesser known features. Region-to-region redundancy, for instance, means the infrastructure is backed up not just in different data centers in the same general region (like the US Northeast, for example), but also in a second, removed region (such as the Pacific Northwest). Many AWS customers don’t even consider this and feel that multiple zones in the same region are enough. That’s possible, but opting for region-to-region puts data and virtual infrastructure in two very different locations, and should anything happen to one, the odds are very small that anything happened to the other. AWS can get very granular with such deployments, too, offering around the world redundancy and even ensuring that certain data centers are located on different seismic plates. This can be mirrored with a private cloud deployment, but the cost is colossal.

#5 Which brings us to the issue of cost. Budget is, of course, a huge factor in this decision and becomes a highly individual consideration with multiple factors that can affect a decision. Companies with large amounts of infrastructure already installed might find it cheaper to implement a private cloud, since in many cases they already have not only the hardware but also the operating systems and management tools required to build a private cloud. But the flip side is that hardware infrastructure, and the demands made on it by software, especially operating systems, changes about every 3-5 years.

Public cloud deployments are entirely virtual, which means the hardware hosting those virtual machines is irrelevant because it’s on the provider to keep that infrastructure current. That represents significant cost savings long term. Smaller companies that need to stretch their investment as far as it can go will see those benefits right away. These organizations will be very attracted to not only the infrastructure services offered by the public cloud, but also the application-level services offered by partners and other customers of providers like AWS. In this case, an organizations is not only deploying servers in the cloud, it’s feeding end-user applications on a subscription basis, bypassing the cost of software licensing, deployment, and updating. That’s very attractive to companies that want to be agile, regardless of the size of the company, with limited IT resources, and even companies who analyze their annual expenditures and find a public cloud deployment compares favorably to that cost.

Most IT professionals and market researchers contend that while the majority of businesses today are eyeing a hybrid deployment, that’s really because they’re being conservative. Yet we know that data centers are a single point of failure. So can we really afford to be conservative? How many private cloud deployments are fully redundant across multiple physical buildings on separate flood plains and earthquake zones? For the small group that has implemented full redundancy at the data center level – try asking for their hypervisor license bill and their maintenance and support labor costs.

Private vs. public is a hot debate among technical circles, but in most cases, taking a long, careful look at the public cloud will show it to be the best-case answer. Is successful private cloud deployment possible? Of course. Is it efficient? No.

Lina Deveikyte

Lina Deveikyte
Lina.Deveikyte@altabel.com
Skype ID: lina_deveikyte
Marketing Manager (LI page)
Altabel Group – Professional Software Development

Almost everyone involved in web development knows jQuery or at least heard of it. Being simple and concise, it makes web developers’ life much simpler. But could it be a solution to every problem? Unfortunately not.  Once you decided to create more complex web apps, you are to face a problem, as there is no easy way to make your UI and data communicate with each other dynamically. And you need a library which will provide you with a more sophisticated way of communication between your UI and the underlying data model. And here is where Knockout (KO) could help.

What is Knockout?
Knockout is a JavaScript library which helps to create rich, desktop-like web UIs. It was developed and is maintained by Steve Sanderson, a Microsoft employee. KO simplifies user interactions and makes interfaces fully responsive to any data source changes. It provides a simple two-way binding mechanism to link a data model to an UI, thus making synchronization between them very easy.

 Pros:

–     Dependency Tracking
 The right parts of your UI are automatically updated whenever your data model changes. This is achieved by the two way bindings and a special type of variables called observables. You don’t have to worry about adding event handlers and listeners for dependency tracking.

–     Declarative Bindings
 This allows you to bind the elements of UI to the data model in a simple and convenient way. When you use JavaScript to manipulate DOM, this may cause broken code if you later change the DOM hierarchy or element IDs. But with declarative bindings even if you change the DOM – then all bound elements stay connected. You can bind data to a DOM by simply including a data-bind attribute to any DOM element.

–     Templating
 This becomes useful when your application becomes more complex and you need a way to display a rich structure of view model data, thus keeping your code simple. Knockout can use alternative template engines for its template binding. It has a native, built-in template engine which can be used right away.

–     Compatibility and Extensibility
 Knockout is compatible with any back-end technology and on the front-end it does as much or as little as you decide. It leaves many decisions to you to make, thus letting pick the best tool to meet your specific needs. Knockout doesn’t care about how you communicate with the server or how you choose to do routing, but there are several third party libraries that do a fine job of these things (like sammy.js for routing and upshot.js for data-access). It goes without mentioning that it works fine next to jQuery. Knockout is also easily extensible. To modify or extend the default functionality, it offers features like custom bindings, and custom functions. There are also several plugins already written for KO.

–     Ease of Learning and Use
 The documentation for knockout is probably the best have ever been seen. It has an amazing interactive tutorial system, live examples, and the documentation is extremely comprehensive and easy to understand. For most developers already familiar with JavaScript it should not take more than a few days to pick it up and start using.

Some additional benefits are the following:
•          KO is a pure JavaScript library – so it works with any server or client-side technology
•          It can be added on top of your existing web application without requiring major architectural changes
•          It’s compact – around 13kb after gzipping
•          It works on any mainstream browser (IE 6+, Firefox 2+, Chrome, Safari, others)
•          Comprehensive suite of specifications (developed BDD-style) means its correct functioning can easily be verified on new browsers and platforms

Cons
 –              All JavaScript variables and arrays are functions (also known as KO observables) as opposed to Angular. This can be a little confusing at first for some people. But it should be noted that all native JavaScript array functions like splice(), indexOf(), push() etc. are implemented by Knockout and may be used on KO observables.
–              HTML views can get messy as declarative bindings increase. This can be weakened to some extent through the use of custom bindings, computed observables and by attaching events to the DOM using jQuery instead of using the data-bind attribute.
–              Additional functionality like data-access and url-routing are not included. If you are looking for an end to end solution that offers a complete toolbox of common web-app functionality, you should probably check out such frameworks as Angular or Ember.

Knockout VS jQuery

Knockout.js is not a replacement of jQuery (as well as of Prototype, or MooTools). It doesn’t attempt to provide animation, generic event handling, or AJAX functionality (however, Knockout.js can parse the data received from an AJAX call). Knockout.js is focused only on designing scalable and data-driven UI.

Moreover Knockout.js is compatible with any other client-side and server-side technology. It also acts as a supplement to the other web technologies like jQuery and MooTools.

Although you will need to use Knockout with jQuery at the same time, in some cases like animated transitions, Knockout itself doesn’t depend on it. Another thing you need to understand is that Knockout doesn’t compete with jQuery – they both do excellent job; each one in its own direction. And if you want to get the most benefits you should use them together.

Knockout is the simplest of all the frameworks as well as one of the smallest. It does not claim to be able to solve all your problems, but it does claim to do a few useful things and do it better than the alternatives. In the words of Knockout creator Steve Sanderson, it is “low risk” because its uses are focused and it is compatible with any other technologies you are using and you can use it in a very small part of your application or your entire application. For someone who wants to take their project to the next level without too much risk, knockout is a great choice.

Hope you found the information in this article useful. Your valuable feedback, question, or comments about this article are always welcome! 🙂

Yuliya Tolkach

Yuliya Tolkach
Yulia.Tolkach@altabel.com
Skype ID: yuliya_tolkach
Business Development Manager (LI page)
Altabel Group – Professional Software Development


%d bloggers like this: