Programming – Page 2 – Jay R. Wren

Build MVVM Applications in F#… or C#

Last month Chris Marinos had an article in MSDN Magazine titled “Build MVVM Applications in F#”

I liked it a lot. I jotted down some notes as I read it. My learning processed amused me as I went from WTF… to Hrm… to Oh I see… in a period of about 15 minutes or so.

It went something like this:

> My first thought on skimming the first 3 pages…
>
> Ok, no offense… but… Dude! Really?!?
>
> PM> Install-Package NotifyPropertyWeaver
>
> and my "viewmodel" can be class MovieVieModelCSharp { public string Name
> {get;set;} public string Genre { get;set;} public int Rating {get;set;}
> public MovieVieModelCSharp(Movie movie) { Name=movie.Name;
> Genre=movie.Genre; if(OptionModule.IsSome(movie.Rating)
> Rating=movie.Rating.Value; else Rating=0;} }
>
> But then I realize that isn’t the point of that part of the article.
>
> Everything looks cool. I’m wondering if NotifyPropertyWeaver would work
> with the Dummy F# view model in Figure 7.
>
> Then I see in Figure 9 you use the ViewModelBase. That is cool I guess,
> but I think NPW might allow for writing WAY less code.
>
> …
> OK… i spent some time exploring these idea and realized I’m clueless.
> F# has no concept of autoproperites (WART!) and its A LOT of code to
> write a mutable property (warts!). NPW sure isn’t going to work with
> non-autoproperties (it picks up on C#/VB autoproperty naming convention
> of the compiler IIRC).
>
> So all that said… I think your article is great.
>
> It challenged me to investigate some things. It shows me that F# really
> sucks for WPF. It makes me really appreciate C# autoproperties and NPW.
> Damn that is some ugly ass code in that last "all F#" section.

Now some interesting parts to this is that NotifyPropertyWeaver apparently DOES support weaving PropertyChanged into non-autoproperties. That is pretty cool, but even with that, I think that this is a case where C# is actually more appropriate than F#.

Where Windows Is Going

I’ve been stewing for about a day.

I did not go to Build Conference.

Once I figured out that WinRT is for Metro style apps and ONLY Metro style apps, and I tried to make a call from a .NET 4.5 app into a very simple “GetUserInfo” WinRT API and it threw an Access Denied Exception, I was upset.

Then I realized something.

This is not just a new way to program on Windows.

It is also not THE new way to program on Windows.

Microsoft is segregating their application types on purpose. Metro style apps and WinRT is not about “the next windows”. What was shown with the hybrid classic desktop and the new Metro UI is NOT the future vision that MSFT has for Windows. It is a transition.

Microsoft is posing Metro style and ONLY metro style to be the next development platform of a version of Windows that will not have the classic desktop. Some future version of Windows that won’t have Win32 and won’t have .NET. It will be WinRT on top of a Windows kernel and THAT IS ALL.

This is why that line between WinRT and .NET/Win32 has to stay thick and hard. There will be no hybrid apps. That ruins the vision.

Imagine a thick wall between the light blue and green.

Microsoft knows that it has to participate in a segregated market. They won’t be selling $100 Windows Professional licenses to OEMs of $300 tablet devices. The $10 license of Windows Started Edition is more like it. (I’m guessing at OEM costs.)

The operating system has to run fast on low power hardware. Any applications which run on it have to run on all the better and faster hardware, right on up to $5000 laptops. The Metro style along side classic desktop fits this mold.

I’m a little bit sad that they wouldn’t just come right out and say this. Come right out and say: “Hey! Our phones are going to run Windows 8! There will be 7”, 8”, 9”, 10”, 11”, 12” tablets all running Windows! But its not like any Windows that you’ve ever known!”

Talk about shaking things up! What if that were the first 3 sentences of the Build keynote?

I’m less angry about not being able to call WinRT from my .NET apps. But I’m a .NET developer. I’m not a Windows developer. I’m not a Silverlight developer. I’m not a WinRT developer.

I think in what I’m most disappointed is all that awesome stuff that WinRT makes easy, and out in .NET land, talking to a webcam for photos and video is still painful. Transcoding video is still painful. (Did you see how easy it is to transcode with WinRT? That is SWEET!)

Build Windows Day 2 From Afar: WTF is WinRT

Watching the developer reaction to Metro style and WinRT has been both depressing and comical. I suppose its like watching anyone else learn something from nothing. We can get it very wrong at first. It is part of our learning process.

I know I’ve not figured what the existence of WinRT means for .NET or what I can and cannot do between WinRT and.NET4.5. I’m also not sure what the difference is between Metro style and WinRT. It sure seems like there are some cool non-UI APIs in WinRT that I might want to use from .NET. I sure hope that I can.

At first glance it feels like Metro style apps aren’t .NET. At least not really. It feels like Metro style apps run in a different CLR. They feel like Silverlight on the desktop since they have no direct access to file system and the types available for use are limited.

I’ve read that it is not a different CLR. I’ve read that it is .NET but that the verifier and other tools in the chain of building a Metro style app enforce the restrictions. I’ll have to wait and see how the pieces fit together.

Missing the APIs can be a challenge: http://winmd.tumblr.com/post/10211942442/missing-net-apis

Looks like I can do the above when I say use some WinRT from .NET4.5. Cool, because those file pickers sure are pretty. http://ermau.com/using-winrt-from-net/

Doug Seven has an excellent post detailing what is being released and how it fits: http://dougseven.com/2011/09/14/i-know-what-youre-thinking-and-youre-wrong/

Take a look at this slide from the keynote:

I’d like to speculate about a couple things related to this picture.

This is not in the scale of overall importance to all developers. It is in the scale of what is new.
All of the things in blue are still there and still supported.

Consider an alternative pitch for Metro style apps. Metro style apps, like all apps, are all launched from the new “Start Screen”. The start screen replaces the start menu. Metro style apps keep the look and feel of the start screen. It is as if you are never leaving the start screen. Metro style apps are apps that you program into the start screen. Imagine being able to program apps into the start menu. It sounds crazy. Now that your start menu is full screen and interactive, those metro tiles (they have a different name) are programmable by you. I can think of another little square in windows that is programmable: Sidebar Widgets. When was the last time you wrote a sidebar widget? (Mike Ward, you are the only one I know.)

Considered from the point of view, very few of us Line of Business app developers will be writing Metro style apps. They are not meant to replace all desktop apps. You will not see Office apps like Word, Excel or Powerpoint built as Metro style apps. They will likely get some theming that is Metro influenced, but they will still run on the traditional Windows desktop and not in the Start Screen. That said, there might be augmentations in the Metro style apps. After all, Windows on a tablet is far more usable with Office. So I think you will see stripped down, touch optimized, Metro versions of Word, Excel and Powerpoint. The use case for these will be “when you aren’t at your desktop or laptop".

Believe it or not, there was actually announcements around Azure and ASP.NET yesterday. You’d never know it given all the focus on WinRT. I’m super excited about the new async support for controller actions in MVC4. I also think Azure’s replication story around tables and blobs is pretty sweet now.

So much more to come. Its an exciting time be a developer. Just try to remember that ships often look like they are sinking when you see them far off the horizon Smile

Thoughts after the Build Windows keynote: This changes nothing

Nothing has changed, and this is a good thing.

Here is what I took away from yesterdays keynote:

Everything I’m doing today with Windows desktop apps will work on Windows 8. No surprise there.
If I want to write these new WinRT apps I’ll have to leave Winforms or WPF behind and use what looks like some kind of desktop Silverlight UI control library which has been enhanced with some more controls. (The GridView was shown in the keynote.)
There is nothing else to say about the developer story. Everything else shown in the keynote was about consumer experience.

Watching my own twitter feed was rather comical. Everyone seemed to be hearing exactly what they wanted to hear. Sometimes it was the opposite of what I thought I just heard.

There are still lots of unanswered questions, but I’m sure that in the next few days these will all be answered via sessions and blog posts containing the content of the sessions. I’m surprised people aren’t more patient. I’m actually seeing a bit of FUD email and tweets asking questions that should be answered by the end of the week. Be patient.

Writing Software is not Comparable to Using a Hammer

I’m going to rant.

Take a look at the first two paragraphs and bullet list here: http://www.peteonsoftware.com/index.php/2011/08/23/programming-language-skills/

Which part of programming is as simple as using a hammer, a manual saw, a table saw, a router, a clamp?

I’d argue that these are fundamentals. If you want to compare, compare them to programmer fundamentals.

using the if statement – 20 years experience
using the for statement – 20 years experience
using recursion – 20 years experience
writing functions – 20 years experience
using variable assignment – 20 years experience
using math operators – 20 years experience
doing string manipulation – 20 years experience

Just as the Programming Language “Skiills” post says, you never really need to put this on your resume.

You can have many years of carpentry experience and just as in programming, maybe you have repeated the same one year many times, or maybe you have done something new every year.

A quick search for Cabinet Maker at monster.com shows a job posting: http://jobview.monster.com/Cabinet-Maker-Job-Rome-GA-101712507.aspx

Notice how the requirements are nothing like “we want 20 years experience using a hammer’” ?

Its because metaphor does not work.

Can we as programmers please stop using this metaphor?

Are Access Modifiers Antiquated?

I just wrote a rather lengthy reply to a Programmers StackExchange question which I’d summarize as “why are the types and or methods I want to extend often sealed in common Java and .NET frameworks and libraries?” Its actually titled “Why shouldn’t classes be designed to be ‘open’?’”

My reply is here:

Because they don’t know any better.

The original authors are probably clinging to a misunderstanding of SOLID principles which originated in a confused and complicated C++ world.

I hope you will notice that the ruby, python, and perl worlds don’t have the problems that the answers here claim to be the reason for sealing. Note that its orthogonal to dynamic typing. Access modifiers are easy to work in most (all?) languages. C++ fields can be mucked with by casting to some other type (C++ is more weak). Java and C# can use reflection. Access modifiers make things just difficult enough to prevent you from doing it unless you REALLY want to.

Sealing classes and marking any members private explicitly violates the principle that simple things should be simple and hard things should be possible. Suddenly things that should be simple, aren’t.

I’d encourage you to try to understand the viewpoint of the original authors. Much of it is from an academic idea of encapsulation that has never demonstrated absolute success in the real world. I’ve never seen a framework or library where some developer somewhere didn’t wish it worked slightly differently and didn’t have good reason to change it. There are two possibilities that may have plagued the original software developers which sealed and made members private.

1. Arrogance – they really did believe they were open for extension and closed for modification
2. Complacence – they knew there might be other use cases but decided not to write for those use cases

I think in the corporate framework world, #2 is probably the case. Those C++, Java and .NET frameworks have to be "done" and they have to follow certain guidelines. Those guidelines usually mean sealed types unless the type was explicitly designed as part of a type hierarchy and private members for many things which might be useful for others use.. but since they don’t directly relate to that class, they aren’t exposed. Extracting a new type would be too expensive to support, document, etc…

The entire idea behind access modifiers is that programmers should be protected from themselves. "C programming is bad because it lets you shoot yourself in the foot." It is not a philosophy that I agree with as a programmer.

I much prefer python’s name mangling approach. You can easily (much easier than reflection) replace privates if you need. A great write up on it is available here: http://bytebaker.com/2009/03/31/python-properties-vs-java-access-modifiers/

Ruby’s private modifier is actually more like protected in C# and doesn’t have a private as C# modifier. Protected is a little different. There is great explanation here: http://www.ruby-lang.org/en/documentation/ruby-from-other-languages/

Remember, your static language doesn’t have to conform to the antiquated styles of the code written in that language past.

Nuget could be more usable outside of visual studio

This is a reply to http://blog.davidebbo.com/2011/05/thoughts-on-installing-and-updating.html

I think you are wrong.

Everything in this post points out that you were wrong to base nuget on DTE.

The points here do explain "why this isn’t supported today" but it sounds like they are defending the lack of features as a good thing. It is not a good thing.

I sympathize with the lack of a strong foundation upon which to build. (limits of DTE) However, the idea of updating the csproj outside of visual studio point 1-3 and 7 in your post, is a sound idea.

The fact that #7 allows arbitrary code execution is something you will never overcome. As a packager might also automate something which is prevented by a GPO in a corporate environment, or utilize a COM object that doesn’t exist. You cannot solve all problems.

XAML Comments in Attributes.

Sometimes I wish that XML supported comments in attributes instead of just <!—style.

Almost always this is a XAML file that I wish had this.

Today I realized just how silly I was being.

xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:d="http://schemas.microsoft.com/expression/blend/2008" mc:Ignorable="d"

And now I can just d:Anything=”any comment”.

Sure, I can’t nest my quotes there, but this is good enough for a lot of things.

<Grid d:Purpose=”this is the grid that contains the other grid that contains the things”>…

CodeRush test runner for NUnit25 without NUnit installed.

What path is the Unit Testing\Test Runner options page expecting?
I have NUnit 2.5.9 downloaded from zip file, not installed from MSI and I try these paths and none of them work.
C:\Users\jrwren\Downloads\NUnit-2.5.9.10348
C:\Users\jrwren\Downloads\NUnit-2.5.9.10348\bin
C:\Users\jrwren\Downloads\NUnit-2.5.9.10348\bin\net-2.0
C:\Users\jrwren\Downloads\NUnit-2.5.9.10348\bin\net-2.0\framework

I get an error that says
—————————
Error
—————————
Test Provider ‘NUnit25’ can’t find required assemblies in this path
—————————
OK
—————————
I finally tried C:\Users\jrwren\Downloads\NUnit-2.5.9.10348\bin\net-2.0\lib and it worked.

I didn’t see this documented anywhere. It is now. (here)

Collection Encapsulation is Bunk

I heard someone ask a question about encapsulated collections today and pointed to this blog post http://www.lostechies.com/blogs/jimmy_bogard/archive/2010/03/10/strengthening-your-domain-encapsulated-collections.aspx

I don’t want to comment on the blog post exactly, but I do want to comment on encapsulating collections in general. I’ve struggled with it. For some reason the OO purist in me wants to strong type everything and when it comes down to collections a Collection<T> or List<T> just isn’t good enough. I want to go full FDGL and make MyTypeCollection that extends Collection<T> or implements IList<T> or something of the sort and have all sorts of nice checking and expose only what is needed on MyOtherTypeThatHasACollectionOfMyType.

But what value does this add?

None.

Zero.

Zilch.

Nada.

My years of PHP and Perl before finding the joys of strong and static types taught me that you just use what is at your disposal and you don’t worry about bugs that don’t exist yet. No one (that I ever saw) ever wrote collection types in these languages. We always just used the built in lists and arrays. If an API didn’t support you adding to a list at the wrong time, then things didn’t work and you would read the docs and/or source and find out just what was supported and what was not. I’m guessing things are this way in the Ruby and Python world too.

The idea that encapsulation is good came about because programmers were creating the same bugs over and over again and running into the same problems again and again. These were the bugs and problems that encapsulation could solve. Do you really think a django or rails programmer is going to go make sure that a controller or other consumer of a model cannot accidentally clear a collection of values on that model? Or add to it when the model thinks that it should not be added to? No. Its a waste of time to do these things before it becomes an issue. Its premature optimization to fix a bug that doesn’t exist yet. If you try, you are just writing code for no reason.

Its probably not important to spend hours or days writing it when you can just as easily document it and say "don’t do that." If you have team members who don’t read documentation, you have bigger problems. Better yet, make everyone on the team aware of the code. Work in a shared ownership environment. Solve problems of unintended use by working with people rather than creating extra work to prevent unintended use.

I’m tempted to make some "the state of this collection can never be invalid" types too. Lets promise each other that we won’t spend time on this. Lets solve better problems.