Has Microsoft killed Silverlight?
Posted by Patrik Löwendahl in Uncategorized on November 23, 2011
The reports of my death are greatly exaggerated – Mark Twain
The internet is currently full of rumors and reports that Microsoft no longer will develop Silverlight after version 5 is deployed. This could not be a bigger exaggeration.
Silverlight consists of a couple of different components;
- XAML for describing UI
- C# for writing the code
- A framework with built classes and controls to speed up development
- A runtime to execute the executable
- Development tools
One of these will go away “A runtime to execute the executable” and one will be updated “A framework with … “.
A new runtime
The Silverlight runtime will go away. Microsoft doesn’t support plugins in their Windows 8 Metro-style browser and here the rumors have some validity. But what is in the runtime? There is a memory model, an execution environment, a type system, threading model and a lot of things needed to get your application to run. In Silverlight you seldom interact directly with this runtime, you interact with the libraries on top of it.
But there is a big difference between being killed and being replaced. In Windows 8 they Silverlight model has been embraced and pull down on top of the kernel itself. In Windows 8 the runtime is called the “WinRT”. It will execute your C# code and XAML but native to the platform instead of in a virtual machine.
Does this change stuff? Yes, will you have to care? Barely. If you don’t count the fact that your apps will be able to run on XBox, Devices and PC’s.
The framework
Here you as a developer will be mostly affected. A few things will change. A couple of namespaces are moved to better reflect the native model of WinRT, the type system has change a little bit and your reflection code will have to be updated (minor update, adding a method call to all typeof and gettype). For the most part, all the classes, methods and other artifacts will be the same as the ones that you use for Silverlight / WP7 development today.
The big difference here isn’t any changes to existing code, it’s that Silverlight applications now get access to so much more functionality that it was restricted from before. Silverlight becomes native.
C# and XAML
… will stay the same (with the obvious version upgrades). You will not have to create COM-objects or call any Win32 api’s. From C#; the programming model of WinRT is pretty much the same as that of the CLR / DLR.
Final words
So yes, Silverlight in its current form could probably be considered dead. But is the technology dead? I’d argue it isn’t. It is evolving into a native model, it’s going to be the engine for applications on the next version of Windows, both on desktop and other devices.
So even if the runtime dies, it’s essence and tools are still there.
More reading:
Silverlight isnt dead its the heart of WP8, Windows 8 and XBOX
Silverlight is dead, long live XAML
Cell phone operators: the next extinct species
Posted by Patrik Löwendahl in Uncategorized on September 27, 2011
I firmly believe that most cell phone operators have lost the initiative in their own market. There are more and more technology breakthroughs and events that further marginalizes their role in providing communication services.
With Microsoft buying Skype, putting their PBX replacement Lync in the cloud and pushing hard for device independence for all your information; they start to become a big competitor on the communication services market.
Consider the following scenario:
Your company decides to rent Lync from Microsoft in the cloud, by then Microsoft has connected Skype’s dialing out capabilities with Lync in Office 365 and rolled out the Lync/Skype clients for their windows phone 7 and IPhone.
Now ask yourself this:
"Will you ever have to use the voice service of the cell phone operator again?”
The answer is simply no.
Another interesting example is the phone app. A simple SMS replacement with additional value add like sending your exact location using GPS-coordinates. This without the additional cost for sending sms.
The cellphone operator are getting marginalized to merely providing the infrastructure for 1’s and 0’s.
How did this happen? They are protecting their own investments more then they think about innovation.
So in the end they only have themselves to blame, after all, they could have invented Skype, they could have created PBX’s in the cloud, they could’ve anticipated that IP packages will be the communication going forward.
Instead they choose conservatism over innovation, bad choice. Services is the high-margin business, infrastructure the low-margin.
HTML5 will chop more then Flash and Silverlight, next up: Apps
Posted by Patrik Löwendahl in Web on August 11, 2011
In response to Apple adding a 30% “Tax” on anything bought inside apps and subscriptions, Amazon has released a HTML5 version of Kindle (source).
This is an interesting turn of events and one I’ve been waiting for. The capability leap of HTML5 seems to create a little bit of sanity in this space. Much like everything was a desktop app before WWW matured, everything on a mobile device is an app today. Even company contact info it seems.
But as HTML5 matures and get’s more widely spread on mobile devices, I’m expecting more and more apps being converted to web pages. In a similar fashion that more and more desktop apps was converted to HTML4 / Javascript pages when that technology matured and evolved.
Just because everything can be an app, doesn’t mean it should. Now we have other very strong alternatives as Amazon just showed.
Microsoft buying Skype – The vision
Posted by Patrik Löwendahl in Column on May 13, 2011
So Microsoft bought Skype. Interesting. Looking at the tech that Microsoft is now owning in this space, Live Messenger, Lync and Skype you don’t have to be a rocket scientist to see where this can go.
Let’s put up a couple of stand alone facts.
- Microsoft is addressing IP-Telephones and video conferencing using Lync for the business.
- Skype is addressing IP-Telephones and video conferencing for the consumer space.
- Lync could be delivered in the cloud (parts of it is already is in Office 365).
- Skype is delivered using the cloud.
- Microsoft announced Skype clients to your Windows Phone 7
- Microsoft announced Skype clients to Microsoft XBox.
Now do you see what I see?
Bring up your phone, call your friend. He/She will be able to answer where ever he/she is. Sitting at the computer with a skype-lync client, the mobile phone or from the couch in front of the Kinect. Some of these options will be with video, some wont.
All of this options will run through the Microsoft IP-telephony network. Some of this will be paid for by the consumer, some won’t. All in all, Microsoft is becoming a carrier for chat, voice and video.
I think this is cool, thinking about the integration possibilities. On-premises Lync server with all the apps that can hook in, and the ability to call other networks.
What do you think?
In the face of frustration.
Posted by Patrik Löwendahl in Column on May 12, 2011
I love to write code. I’ve written code in one form or another for the past 25 years and I’ll probably still write code for the upcoming 25. I love the pure power of creation and freedom to let creativity flow that code gives me. But like in any love story there is times when it just frustrates the hell out of me.
I have a confession. I’m not proud of this, I know it’s morally wrong and I would never do this in any other setting; I’ve taken on a mistress.
My mistress is business value. Not that code can’t be business value, but sometimes other options can more quickly satisfy business values and in the face of frustration I’ve started to indulge in those options.
In the past I’ve easily accepted blame for throwing code at most problems and tried to deliver features at a rapid agile pace. Often and early. Sometimes code is just not as rapid as I want.
Now if just the platforms I choose to install to meet business needs quickly wasn’t so frustrating to code for…
Standard products – Can’t live without them, can’t live with them.
No Comments
The benefits of minimizing the centralization of IT
Posted by Patrik Löwendahl in Architecture, Methodology on November 10, 2010
One of the lesser known ideas and practices behind what has come to known as SOA was the physical organization of teams into service areas. The basic idea is that there shouldn’t be a centralized “IT-Department” that manages the systems they need, but every department should have their own dedicated IT that help them conduct their business as effective as possible.
At a first glimpse this seems like someone didn’t think this through. After all, why should the finance department handle it’s own IT? They should focus on finances! This is true, but digging past the first shallow glimpse there is actually really interesting benefits here, none of the technical in nature.
It’s all about understanding the core
Centralized IT-departments are often very good at performing their core-business; IT. But if IT isn’t the organizations core business there is a lot to be learned, there is a gap to be bridged and you really need dedicated IT-staff that understands exactly what your departments function is in the the whole. This often leads to IT-departments dividing into subgroups with staff specialized in servicing a separate department. The collective knowledge collected over years a group like this will often represent a full understanding of what the department actually does. This leads to shorter cycles, quicker feedback loops and more to-the-point implementations.
If you understand the finance department, it will be a lot quicker to understand new requirements. This is a first step into making IT part of the business and not only a cost of performing it. It also comes a long way to becoming more cost effective then general development departments ever can be.
It’s all about money streams
As business has evolved, a lot of organizations today can’t conduct it without IT-support. Often you hear that cost of IT is the cost of doing business. In a sense it is (though I’d say that cost of IT is an investment that will pay it’s own weight done right, but that’s another discussion).
Add to this that all head of departments have their own budget that they need to maintain and fulfill. All IT-projects with a centralized IT-department will quickly come to the same discussion, who will pay for this? If there is an investment that need to be done that the finance department will reap the benefits of, should the cost end up on the IT-departments bottom line?
A lot of organizations try to solve this by charging the departments for new projects and taking a fixed fee for maintenance. This solves part of the problem but creates new grounds for discussions.
When is the project done and when do we go into maintenance mode? Is maintenance just about bug-fixes and what if that is the case, what is a bug? Endless discussions. All based on the fact that the managers of each department have to report their budgets.
Much like some discussions between clients and consultants.
If managing the budget was entirely up to the department itself, this would not be an issue. It would be up to the department to do investments that bring their business forward. All costs associated with their IT-support would be visible in their own budgets. Manageable in their own budgets. There will never be a discussion about investing X to get benefit Y, it will all boil down to the same bottom line and ROI will be the responsibility of the same manager.
There are some IT functions that might not be feasible for this, like desktop maintenance. Maybe the BizTalk server should be maintained centralized for all departments, etc. But for the system support you need, for any customization or development you need. This is a smooth way to go.
Conclusion
Organizing your development into areas of service might not be for everyone. But there are great benefits for those who does. Shorter feedback loops for requirements, shorter decision paths and visualization of actual cost / benefits in the right place; the bottom line for the department actually using the service.
Reflections of Visual Basic 6, when the end is near
Posted by Patrik Löwendahl in Column on October 12, 2010
Very soon Visual Basic 6 will go out of commission, Microsoft will cease all support and will officially bury a language, tool and platform that has been argued to carry their success with their platform penetration through the 90’s.
In the backwater of this I can’t help but wonder. Was Visual Basic an expensive detour or did it actually help bring our industry forward? The goal with Visual Basic was simple, bring a tool that makes it easier to build LOB type of applications. Lower the threshold and make the Microsoft platform dominant on delivering software. There will be arguments for success and failure but a simple fact remains, there is a lot of Visual Basic systems out there, there where million and millions of VB6 devs working everyday with the platform before .NET.
But did it backfire? Did the rapid growth of Visual Basic developers contribute to the mistrust in the Microsoft platform for mission critical applications? The fact is, there was a lot of really poorly written VB systems deployed. Enough to create serious doubt in the Microsoft platform. Was it VB’s fault?
I would say that with Visual Basic, Microsoft got it’s wish fulfilled. With an army of devs there where apps flying onto their platform. But was it the right devs?
Maybe, no matter the tool, people who can’t write software won’t be able to write software?
Maybe, with a really bad tool, people who can’t write software will write insanely bad software?
Maybe Microsoft should be careful what they whish for?
It might not be a tooling problem that people can’t write software, it might be a people problem.
With that in mind, I look very skeptical at things like LightSwitch. I don’t see any problems in making solid developers more productive. There is one thing that VB has taught us though; not every person with a keyboard makes a solid developer, and a tool won’t change that.
The dreaded “Save(Foo bar)”
Posted by Patrik Löwendahl in Architecture, design patterns on September 24, 2010
For the last year or so my biggest antagonist has been “Save(Foo bar)”. There is usually a lot of things going wrong when that method turns up. I’m not saying that saving stuff to the persistence storage is a bad thing, but I’m arguing that the only place it should exist is in actually saving data in the persistence/data layer. Don’t put it in your services, don’t put it in your business logic, and for crying out loud; do not base entire behavior around it.
The source of the ill behavior
When developing software a user will quite often tell you that she wants a button that will save the current changes she’s done to the current work. As a good developer we implement this button and make the user happy. After all, their happiness is our salary. In a pure data-entry application this is all good, but as soon as we add just a little bit of behavior we need to start pushing the actual saving far, far away. Consider this screen:
In this setting the Save button makes perfect sense. The user changes a couple of things and then commits those changes to the system. Now start to think about more then just storing the values in a database, think about adding behavior to the changes.
Do not throw away the users intent!
When a user makes a change to any of these fields, they do so with an intention. Changing the address might mean that the receiving end of an order has changed. Changing logistics provider might mean that a new one need to be notified. With a save method, the only way for our business logic to know what to do, is to figure it out;
And even worse;
Basically what we’ve done is throwing away the users intent and capturing of the actual work the user has done. I see this happening a lot in service interfaces (WCF Service contracts with a single Save method), in “Managers” (Let’s not even go there) and in local services.
The code this will generate a couple of releases down the road will smell in so many scents it’s not even funny to joke about. But to get you started, read up on Open/Closed (A SOLID principle).
Enough with the bashing, what’s the solution?
The idea that a user can commit their work in a single push of a button is a good one. But that doesn’t mean that the save need to anything else then a button. The actual work under the covers should reflect what the user really wants to happen. Changing a service provider on an order that’s packed should probably issue a message to the old provider not to pick the package up and a message to new to actually do. This kind of behavior is best captured with commands.
Let’s revisit the order form:
In this scenario every red box here is actually a intended command form the user. Identified as;
ChangeOrderAddress
ChangeOrderLogisticServiceProvider
ChangeOrderStatus (or actually, CancelOrder, ShipOrder, etc)
Implementing this could either be using the command pattern or methods on the order class. “It all depends” on your scenario on preferences.
So what am I really suggesting?
Make sure that your code reflects the intention of the user. Not the technical details of how the data is persisted. You will save a lot of pain, grief and hard work by just identifying what the user intends, capture that in commands or something similar and execute them in order when the user hit’s save. And most importantly SAVE IS A METHOD ON THE PERSISTENCE LAYER, NOT A BUSSINESS FUNCTION.
NDC2010: Michael Feathers – The deep synergy between good design and testability
Posted by Patrik Löwendahl in NDC2010 on June 18, 2010
In this session Michael Feathers basically killed the argument based on; I don’t want tests to drive my design with a simple example base on the code smell; Iceberg class.
Private methods are really hard to test, and here we have a class with a bunch of them, It will be hard to test, but in addition to that it’s also a bad design decision. It violates the single responsibility principle.
A better design would be to break this out in smaller classes, something like;
Which honors SRP and will be much easier to test.
So why is this true?
There is basically two reasons, related to each other, that drives this synergy. To begin with you are consuming and using the api, which quickly lets you feel the pain. The second reason is based on the fact that test help you understand code. Badly designed code will be hard to test since it’s also very hard to understand what it does. In the light of this, SOLID principles makes a lot of sense. Not only does it allow you to test your code, but it makes it easier to understand.
With these facts, Michael stated a simple truth;
Solving Design Problems
Solves Test Problems
It’s not about letting a test tell you what to do, making code testable does not necessarily imply better design. But better design will make your code easier to test.
This is also why he has problems with “Groping test tools”, tools that let you test private parts. He feels they are a “Get out of jail free card”. Which removes an important force to make the design better; Pain. Pain is useful as a learning tool in that it tells you what to avoid. Sure removing test-pain will make the code easier to test, but will it make it easier to maintain or extend? Usually not.
He then concluded that testing isn’t hard, testing is easy in the presence of good design.
Reflections
This was a great talk! By examining relationship between test-pains, code smells and design principles, Michael made a clear point that there is a synergy. If you find it hard to test your code, there is usually some other problem with it.
He didn’t want to impose TDD on everyone, but he made his case that test will help you understand your code better and act as a constraint that forces you into good design. Something you should be doing anyway.
Catalogue of testing pains and relation to code smells
| State hidden within a method – you find yourself wishing you could access local Variables in a test. | Methods are typically to long and are violating Single Responsibility Principle. |
| Difficult Setup – Instantiating a class involves instantiating 12 others. | This pain says something about the design, it means that the class isn’t factored into smaller pieces. Problem: To Much coupling. |
| Incomplete shutdown – pieces of your code lose resources and you never realize it until you test. | Classes don’t take care of themselves, poor encapsulation. |
| State-leaks across tests – The state of one test affects another. | Smells of improper use of sIngletons or other forms of global mutable state. |
| Framework Frustration – Testing in the presence of a framework is hard | Insufficient Domain separation. Lacking good separation of concerns. |
| Difficult mocking – You find yourself writing mocks for objects returned by other objects | Law of Demeter Violations |
| Difficult mocking 2 – hard to mock particular classes | Insufficient abstraction and / or dependency inversion violation. |
| Hidden effects – you can’t test a class because you have no acess to the ultimate effect ot its execution | Insufficient separation of concerns and encapsulation violation |
| Hidden inputs – There is no way to instrument the setup conditions for a test through the API | Over encapsulation, insufficient separation of concerns |
| Unwieldy parameter lists – it’s too much work to call a method or instantiate a class | To many responsibilities in a class or a method. SRP violation |
| Insufficient access – you find yourself wishing you could test a private method. | To many responsibilities in a class. SRP violation |
| Test Trash – many unit tests change whenever you change your code. | Open/Closed violations |
NDC2010: Michael Feathers – Testable C#
Posted by Patrik Löwendahl in NDC2010 on June 18, 2010
This session was basically explaining a simple rule that regardless if you are using TDD; should be followed at all times:
Never hide a TUF in a TUC
What did Michael mean by that?
There are two things that can be “Tests Unfriendly”, features and constructs. The common denominator of the two is that they are hard to replace or isolate and thus impose a lot of constraints on what need to be up and running to test.
He then went on to explain exactly what TUF’s and TUC’s to look out for.
Test Unfriendly Features (TUF)
A TUF is something that has a tight coupling to a resource that’s hard to mock, fake or replace for testability. He listed a few;
- File access
- Long computations
- Network access
- Database access
- Global variable manipulation
- Use of 3rd party libraries or frameworks
The list is in no way complete but clearly shows a pattern and really follows the ideas that a unit test should be isolated from any external dependencies.
Test Unfriendly Constructs (TUC)
A TUC is a language feature that makes it hard to fake, mock or replace a piece of code. He was very clear that he didn’t say that these features where bad in any way, just that by using them we should be aware that we might introduce testability issues. Certainly in combination with TUF’s.
He listed a few C# constructs that wasn’t replaceable (or at least hard to replace without stuff like TypeMock);
- Private/static/sealed/non-virtual methods
- Object constructors
- Static constructors
- Static initialization expressions
- Sealed classes
- Static classes
- Const/read only initalization expressions
When dealing with these TUC’s, since they aren’t completely worthless, he gave a simple advice; “Do not code with the idea “why would anyone ever want to replace this” but think instead in terms of “this is really important that nobody can change or easily access”.
Reflections
This was a good talk, not in terms of new things I didn’t know. But in introducing rules and arguments for building testable code. Not everyone will write code TDD-style but by at least making them following the simple rule of “Don’t hide a TUF in a TUC” it will be easy to add tests later on if there is something you are curious about or want to validate.
This was a great take away that I see I can put into use right away.
-
You are currently browsing the archives.
-
