The vote for Microsoft to bring back an updated version of VB6 is now #5 (out of over 8000) on the Microsoft VisualStudio UserVoice site “Bring back Classic Visual Basic, an improved version of VB6″
Windows Phone 8.1, Windows 8 RT and Window 8.1—that is, the phone, tablet (sort of) and PC flavors of Windows—are no longer distinct operating systems that largely look alike but vary wildly under the hood. Microsoft has spent the last couple of years updating its disparate Windows versions so that they work together with the goal of letting developers write one app and deploy it—after some tweaking to the user interface—to Windows PCs, tablets and smartphones.
True, Microsoft’s operating system naming conventions are still awful. But that shouldn’t obscure the major step forward this code-base unification represents to developers, nor the benefits that will flow to users as a result.
All three flavors of Windows now run on a common software core, or “kernel,” with a common runtime (i.e., the set of tools necessary to run programs). The major remaining differences between them have mostly to do with how they handle user-interface issues across a variety of devices, input methods (think touchscreens vs. mouse and keyboard), hardware (not just CPU and memory, but graphics processors, accelerometers and other sensors) and screen sizes.
Microsoft knows that those differences still present obstacles for developers, and hopes to address many of them with an update to its integrated developer environment, Visual Studio 2013, which it announced at Build 2014 this week.
Kevin Gallo, Microsoft’s director of the Windows Development Platform, describes it in a post on the Windows blog:
Write Once, Deploy To All The Windows
The Visual Studio update allows developers to port existing apps across devices and their specific versions of Windows. For instance, if you have a Windows 8.1 app, you can use settings in Visual Studio to target smartphone-specific capabilities in Windows Phone 8.1. Visual Studio is designed to let developers use the same basic app code across different devices and Windows flavors, and allows them to emulate how an app will behave in each case.
From Microsoft’s perspective, the two most important takeaways for developers are these:
- You can build universal apps and share all the code while just making tweaks to the user interface
- Visual Studio offers a variety of diagnostics tools to optimize apps for use on different device—smartphones running Windows Phone, laptops running Windows 8.1, etc.
Essentially, Microsoft wants to make it as easy as possible for developers to build Windows apps. Given Microsoft’s minuscule share of the mobile market to date, you can hardly blame it.
In practice, this means Windows Phone developers—and you know who you are— essentially have three options. If you’ve built your apps using the Silverlight Phone 8.0 development tool, you don’t have to do anything; they’ll continue to work as is on Windows Phone 8.1.
Alternatively, you can update your apps to Silverlight Phone 8.1 to access the new features in Windows Phone 8.1, such as the Cortana personal assistant and customizable homescreens. Or you can migrate your apps to the universal Windows app platform with the new tools in Visual Studio. Of course, if you prefer, they can also just start from scratch and build a “universal” Windows app to Microsoft’s specifications, which would theoretically optimize it for the new unified Windows code base.
Buy Once For All Of Your Windows
For consumers, Microsoft aims to make the process of buying an app easier. If you buy an app for your Windows 8.1 laptop, you can automatically download it to your Windows Phone or vice versa. Microsoft insists that you won’t need to buy separate apps for separate versions of the operating system because, essentially, Windows is now all one big operating system now. The same is supposed to hold true for in-app purchases within these apps—they should migrate from laptop to tablet to smartphone as well.
Apple doesn’t do this. If you buy an app on Mac OS X for your iMac or MacBook, you will still need to download or buy the same version for your iPhone or iPad. Google doesn’t do this, either. If you buy an app or extension for Chrome OS, you will still need to buy that app for Android on Google Play.
Some individual apps for Android and iOS, of course, do let customers download versions for different devices—for instance, via a subscription service or universal login. But that’s up to the app developer. It’s not required by Apple or Google.
1. To build brand, focus on quality.
The reason that antihero Walter White’s crystal meth becomes so valuable is that it’s of much higher quality than the competition’s.
Through a tight control of his manufacturing process, White creates a product that’s almost 100 percent pure. The competitors can only manage around 60 percent pure. As a result, the meth consumers (a.k.a. “tweakers”) all want White’s product, not that of his competitors.
When you look at all the great commercial brands, you see the same thing. The brand is built on product quality and suffers when quality declines. A good example of this is GM, which has struggled for decades to return to its former reputation for quality, a struggle that its recent recall makes all the more difficult.
2. Tie quality to a visual hook (brand image).
As is frequently pointed out in the series, White’s product has a blue tinge to it and consequently acquires the brand name Blue. The consumers of the product quickly associate the blue color with the purity of the product. The color, in other words, becomes the brand image. When other people unsuccessfully attempt to imitate White’s manufacturing process, the lack of the blue color is as fatal to the knockoffs as the lack of purity.
Similarly, great commercial brands always have a visual hook—a logo or, better yet, a look and feel—that people associate with product quality. Apple is a great example of this. Every iPod, iPhone, and iPad is easily identifiable—even from a distance—compared with their frequently shoddy competition.
3. Make distribution as important as brand.
Throughout Breaking Bad, White’s main challenge (and the majority of his problems) comes from his need for a distribution network. Needless to say, some of White’s problems in this area are connected to the fact that he’s selling a product that’s illegal.
The other week I wrote a post discussing how PowerView was the future of SQL Server Reporting Services, and the killer features that made it a compelling choice. Despite the numerous positive advances that PowerView brings to Microsoft/SQL-based reporting, there are of course a number of counter arguments. I deliberately left these out in order to look at some of these reasons in a later post.
1 – Customisation
One of the major shortcomings ofPowerView’s current implementation is its lack of customisation options. Compared with vanilla SSRS, where you can tweak just about every single property of a control, the options inPowerView are extremely limited.
Take the charting component, for example. In PowerView, you have a choice between 4 types of chart: Pie, Line, Scatter or Bar/Column (I’m not going to even entertain these as different types). You can assign your axes and values, and choose a colour scheme for your view…and that’s it. No secondary axes, scale breaks, major/minor tick marks, and so on.
SSRS is extremely powerful, and all the properties in standard SSRS objects are still there in the underlying RDL file (check out Dan English’s blog for a rundown of what makes a PowerView RDLX file), they’ve just been disabled. It’s possible there might be more control in a future version of PowerView if Microsoft choose to expose more options, but for the time being, if you want customisation, you’re better off sticking with vanilla SSRS.
2 – Silverlight
But it’s much easier when you don’t have to install anything extra to view your reports.
3 – SharePoint
Ahhh, SharePoint. And not just SharePoint, but SharePoint Enterprise. It’s like Microsoft’s own, personal licence to print money. Yes, with Excel 2013 you can share Excel workbooks, but it’s a long way from being a portable, easily accessible solution.
SharePoint Enterprise is like Microsoft’s own, personal licence to print money.
Vanilla SSRS supports either SharePoint integration or a native mode Reporting Services server, which includes all the necessary components for deploying, managing, scheduling (more on that in a minute) and running reports. It’s also much cheaper than forking out for a SharePoint Enterprise licence, requiring only the free SQL Server Express Edition to run an SSRS native mode server (at least in its most basic form).
Unfortunately, it’s currently SharePoint Enterprise only for PowerView, something that is sure to be a blocker to many SME’s in adopting PowerView in any serious manner. Microsoft seem set on pushing SharePoint as an important part of their BI platform, but they really need to consider how to help people share the great things they create with the tools on offer.
4 – Automation
As I mentioned above, one of the great things about SSRS is its support for automation of report execution and delivery. A lot of businesses rely heavily on the ability to create dynamic data-driven subscriptions and deliver reports directly to client and executive inboxes at critical times.
With PowerView not currently having any means of scheduling or automatic report delivery, there’s a large gap here that quite simply requires SSRS. Even if Microsoft were looking to replace vanilla SSRS with PowerView, there’s a huge infrastructure shortfall that needs addressed. Report automation and delivery is an absolutely critical business requirement, and one that PowerView and its supporting cast is simply not equipped to handle. It’s great for the power users and self-service BI platform, but there’s still a massive need for the business support that SSRS can provide.
5 – Extensibility
Finally, one of the greatest, and most overlooked capabilities of vanilla SSRS is its sheer flexibility. Even if you’re totally stuck on a report and can’t figure out a way to achieve your goal, you can always extend it by using some custom code. Simple functions can be embedded within the report itself, while entire client libraries can be deployed directly to the report server, offering a huge array of features to even the simplest report. I’ve used custom libraries to support complex string formatting and currency conversion, customisable column naming, and many other features.
You can add JS or .NET code toSSRS…really the only limit is your imagination.
But of course, if you can add JS or .NET code to SSRS, then really the only limit is your imagination. There are so many possibilities. PowerView doesn’t support any custom code in its current state, and it’s a huge limitation of the current component.
PowerView’s first iteration and a half (It’s a stretch to call the version in Excel 2013 2.0) have delivered a solid foundation and a great tool for power users, executives and prototyping. As a self-service component, it’s simple, quick, and graphically very impressive.
But beneath all the fanfare, there’s a worrying lack of depth. SSRS is a complex, flexible and scalable platform that offers something for every business, from the home-run self-employed effort, to multi-national, blue-chip corporations. Its innate flexibility allows heavy customisation straight out the box, and the infrastructure behind it supports business processes and software.
A lot of people are worried about Microsoft’s future plans for corporate-level BI, and a lot of their focus over the past year or so has been placed in the self-service side of things. As such, there’s not been much movement on new features for the corporate crowd. While it’s great to bring BI tools to the masses, it’s important that the business users aren’t forgotten in the long run, as there’s definitely a need for multi-tiered BI in any organisation. Here’s hoping that SQL Server 2014 and beyond bring some new developments to keep both sides, and those of us who see the value in both approaches, happy.
Assume for a minute (OK, just for a second) that new Power View Data Visualization tool from Microsoft SQL Server 2012 is almost as good as Tableau Desktop 7. Now let’s compare installation, configuration and hardware involved:
- Hardware: almost any modern Windows PC/notebook (at least dual-core, 4GB RAM).
- Installation: a) one 65MB setup file, b) minimum or no skills
- Configuration: 5 minutes – follow instructions on screen during installation.
- Price – $2K.
- Hardware: you need at least 2 server-level PCs (each at least quad-core, 16GB RAM recommended). I will not recommend to use 1 production server to host both SQL Server and SharePoint; if you desperate, at least use VM(s).
- Installation: a) Each Server needs Windows 2008 R2 SP1 – 3GB DVD; b) 1st Server needs SQL Server 2012 Enterprise or BI Edition – 4GB DVD; c) 2nd Server needs SharePoint 2010 Enterprise Edition – 1GB DVD; d) A lot of skills and experience
- Configurations: Hours or days plus a lot of reading, previous knowledge etc.
- Price: $20K or if only for development it is about $5K (Visual Studio with MSDN subscription) plus cost of skilled labor.
As you can see, Power View simply cannot compete on mass market with Tableau (and Qlikview and Spotfire) and time for our assumption in the beginning of this post is expired. Instead now is time to remind that Power View is 2 generations behind Tableau, Qlikview and Spotfire. And there is no Desktop version of Power View, it is only available as a web application through web browser.
Power View is a Silverlight application packaged by Microsoft as a SQL Server 2012 Reporting Services Add-in for Microsoft SharePoint Server 2010 Enterprise Edition. Power View is (ad-hoc) report designer providing for user an interactive data exploration, visualization, and presentation web experience. Microsoft stopped developing Silverlight in favor of HTML5, but Silverlight survived (another mistake) within SQL Server team.
Previous report designers (still available from Microsoft: BIDS, Report Builder 1.0, Report Builder 3.0, Visual Studio Report Designer) are capable to produce only static reports, but Power View enables users to visually interact with data and drill-down all charts and Dashboard similar to Tableau and Qlikview.
Power View is a Data Visualization tool, integrated with Microsoft ecosystem. Here is a Demo of how the famous Hans Rosling Data Visualization can be reimplemented with Power View:
Compare with previous report builders from Microsoft, Power View allows many new features, like Multiple Views in a Single Report, Gallery preview of Chart Images, export to PowerPoint, Sorting within Charts by measures and Categories, Multiple Measures in Charts, Highlighting of selected data in reports and Charts, Synchronization of Slicers (Cross-Filtering), Measure Filters, Search in Filters (convenient for a long lists of categories), dragging data fields into Canvas (create table) or Charts (modify visualization), convert measures to categories (“Do Not Summarize”), and many other features.
As with any of 1st releases from Microsoft, you can find some bugs from Power View. For example, KPIs are not supported in Power View in SQL Server 2012, see it here: http://cathydumas.com/2012/04/03/using-or-not-using-tabular-kpis/
Power View is not the 1st attempt to be a full player in Data Visualization and BI Market. Previous attempts failed and can be counted as Strikes.
Strike 1: The ProClarity acquisition in 2006 failed, there have been no new releases since v. 6.3; remnants of ProClarity can be found embedded into SharePoint, but there is no Desktop Product anymore.
Strike 2: Performance Point Server was introduced in November, 2007, and discontinued two years later. Remnants of Performance Point can be found embedded into SharePoint as Performance Point Services.
Both failed attempts were focused on the growing Data Visualization and BI space, specifically at fast growing competitors such as Qliktech, Spotfire and Tableau. Their remnants in SharePoint functionally are very behind of Data Visualization leaders.
Path to Strike 3 started in 2010 with release of PowerPivot (very successful half-step, since it is just a backend for Visualization) and xVelocity (originally released under name VertiPaq). Power View is continuation of these efforts to add a front-end to Microsoft BI stack. I do not expect that Power View will gain as much popularity as Qlikview and Tableau and in my mind Microsoft will be a subject of 3rd strike in Data Visualization space.
One reason I described in very beginning of this post and the 2nd reason is absence of Power View on desktop. It is a mystery for me why Microsoft did not implement Power View as a new part of Office (like Visio, which is a great success) – as a new desktop application, or as a new Excel Add-In (like PowerPivot) or as a new functionality in PowerPivot or even as a new functionality in Excel itself, or as new version of their Report Builder. None of these options preventing to have a Web reincarnation of it and such reincarnation can be done as a part of (native SSRS) Reporting Services – why involve SharePoint (which is – and I said it many times on this blog – basically a virus)?
I am wondering what Donald Farmer thinking about Power View after being the part of Qliktech team for a while. From my point of view thePower View is a generous gift and true relief to Data Visualization Vendors, because they do not need to compete with Microsoft for a few more years or may be forever. Now IPO of Qliktech making even more sense for me and upcoming IPO of Tableau making much more sense for me too.
Yes, Power View means new business for consulting companies and Microsoft partners (because many client companies and their IT departments cannot handle it properly), Power View has a good functionality but it will be counted in history as a Strike 3.
When Should You Create New SQL Server Indexes?
Every time there are major software upgrades performed, the system should be reviewed and index tuning should be performed.
In my professional view, SSAS OLAP is still the “king of the hill”, and SSAS Tabular is often “not quite there yet.” But the word “yet” is a powerful word in the evolutionary history of software products. None of this should imply that I don’t have great respect for what Microsoft has done to produce an in-memory analytic database model (in SSAS Tabular).
However, the limitations and necessary workarounds in the Tabular model only serve to highlight the sheer depth of SSAS OLAP. And although some areas of SSAS Tabular are very close to what analytic developers need, other areas need considerable attention.
As a review (and many of these are listed in Table 2), here are the primary features in SSAS OLAP that either don’t exist in SSAS Tabular (or require DAX code workarounds):
- Extremely large cubes that exceed server memory
- Parallel processing for partitions
- MDX named sets and block computation of calculations
- Direct Support for more advanced relationship types (role-playing, many-to-many, self-join)
- Data mining (this is a topic that could occupy an entire article)
- Report Actions
- Advanced dimension attribute properties and aggregations
- Non-visual Totals
- Calculated Measures for ROLAP
Yes, SSAS OLAP (and MDX) have steep learning curves, but the rewards are often worth it. SSAS Tabular might initially seem to have a shorter learning curve, but once put through the paces of an actual project, a more positively realistic conclusion might be that SSAS Tabular isn’t better or easier, nor worse or tougher. It’s just different.
Yes, SSAS OLAP (and MDX) have steep learning curves, but the rewards are often worth it.
In closing, I hope you have gained a better understanding of the differences between SSAS Tabular and SSAS OLAP. It has never been my intention to harshly criticize SSAS Tabular. (Believe me, I wish some of the improved UI features in SSAS Tabular would be implemented in SSAS OLAP!). I do strongly think that some speakers and bloggers have been soft on SSAS Tabular, and I think it’s important to put both products under the proverbial microscope. A developer shouldn’t go into a project without knowing the functionality (or lack) of the product. Identifying the differences and shortcomings is a step towards improving (in this case) SSAS Tabular.
Additionally, none of this means I wouldn’t recommend using the SSAS Tabular Model for new projects. If the database can fit in server memory (because SSAS Tabular is in-memory), doesn’t require more advanced fact-dimension relationships and parallel processing, and you don’t mind implementing DAX calculations to extend any relationships, then I’d say give SSAS Tabular a try. Additionally, companies might use SSAS Tabular (or even PowerPIvot) for prototyping or proof-of-concept discovery activities-and I’m not suggesting a context of “relegation,” as the prototyping and discovery processes can be EXTREMELY valuable. But for most other projects, I recommend staying with SSAS OLAP but keep a close eye on SSAS Tabular, as one day I’m sure it will win the feature war.