Surface Remix Project

Microsoft announced Surface 2 and Surface Pro 2 yesterday. Both look pretty cool and overall big improvements from the first gen products. I probably won’t be buying a Surface 2. I already own Surface 1 and can’t justify buying every iteration of the product. I am however in the market for a new ultrabook and I am now seriously considering the Surface Pro 2 (256GB).

What really peaked my interest about yesterday’s announcement was the hardware behind the Touch Cover 2 keyboard and the Surface Remix Project.

(Image Copyright Microsoft)

 

The inside of the Touch Cover was redesigned to contain 1092 sensors instead of 80, and the keys are also back lit.

(Image from Arstechnica.com)

This has the potential to open the touch cover to applications beyond a simple keyboard. Theoretically, we could overly any design we want over these 1092 sensors. Microsoft already showed us one really cool application for DJs with the Surface Remix Project and we are seeing some good conversations about other potential applications on Twitter today.

 

There really are so many possibilities for this technology. Off the top of my head, I can imagine specific applications for drafters and engineers. I can imagine amazing registers for high end stores and restaurants. Really, my mind is spinning with ideas right now. 

I think Caleb Jenkins said it best…this touch friendly, SDK-enabled light bright is a MUST HAVE. Microsoft, please make it available for us so you can take our money…

Options for Deploying an ASP.NET Application

There are many ways to deploy an ASP.NET web application. If you have done any research on the topic, you have probably heard Scott Hanselman tell you that You’re Doing It Wrong.

His post gives a very good overview of Microsoft’s Web Deploy technology and it’s many uses. I have used Web Deploy in the past and it works great. It especially works great if you are building an internal application that is deployed to a limited number of servers (ie. Dev / Test / Production). In this case, you can easily configure your build process to automatically make changes to your web.config and deploy to your various servers.

There is one scenario where I struggle with the web deployment process. I initially thought it was a very rare situation, but I have seen this three times. Either I am incredibly lucky (unlucky?), or this is actually more common than I thought.

Deploying a Web Application to Client Sites

Here is the scenario: You work for a company that builds a commercial product. The product is built using ASP.NET and (obviously) hosted in IIS. Here’s the screwy part…the application is not hosted on your own server. Instead, the application is deployed internally at each individual client site.

Why would you ever do that!?!?!? As it turns out, there are some good reason. There is a certain class of application, within a certain class of client that makes companies nervous about not having complete ownership over the data and environment of the application. Think banks, legal firms, telecom… These apps might not require huge servers or web farms and the database could easily be hosted on the same server as the website. The number of clients might vary anywhere from ten to hundreds.

 

Environments

 

 

What are your options

Use Web Deploy as much as possible!

For your internal deployments, use Web Deploy to automatically deploy to your Dev/Test/Prod servers as part of your build process.

For external client deployments, you probably want give the client some sort of package that will allow them to manage the initial install of the application. You probably have a large number of clients and a small team. You can’t possibly do all the installs yourself. The install might involve creating a database, configuration the application in IIS, deploying the application files to IIS, adjusting file and folder permissions, and countless other configuration tasks. Likewise when distributing updates to the application, you would like to provide the client with a package that will automate the update for them. This includes upgrading the database and the web application files.

Start by using web deploy to create a package for your application. This should be the same package as you used for your internal deployments. You should add any parameters that you might want the user to enter during the install process. This might include database connection string information and any other application settings necessary at install time. You can read more about parameterizing your web deploy packages here.

Next, you could create a package that would be distributed and installed using Microsoft’s Web Platform Installer. This walktrough will take you through the whole process of building the package and custom feed that you can publish to your clients. This option would work well for some applications, but I have found that with some legacy applications it can be difficult to accomplish everything you want to do using only Web Deploy and Web Platform Installer. For example, if your application was built using a database other than SQL Server, how do you manage your database creation and upgrades. Even some of the IIS configuration steps can be difficult to accomplish using Web Deploy.

Another option would be to use a deployment management tool such as Octopus Deploy. This is a great tool for managing your deployments, but it doesn’t work great for this scenario. First, the clients we mentioned above will perceive this tool as a security risk. I don’t necessarily agree with that assessment, but this has been my experience. Second, if you are managing 100s of deployments, it would mean managing 100s of configurations inside your deployment server. For each of those deployments, you would need to know the details of the clients database connection information and all their configuration settings. Chances are, you don’t really care what the name of your client’s database server is.

Yet another option would be to create an MSI using WIX or Install Shield. This is totally do-able and completely flexible, but rather painful to implement and maintain. I find myself needing to re-learn the technology every time I try to create an MSI.

Finally, you could take hybrid approach. Create a simple WPF or Win Forms application that looks something like an installer. Since it is now your own .NET code, you can add whatever logic you need to the install process. Using the Microsoft.Web.Administration.aspx) assembly, you can easily configure application pools, create applications, and basically do anything that you can do using IIS Manager. You could even detect when your application is already installed on the server by inspecting IIS to see what applications are there. You could build some nice forms to let the user select any necessary options. Best of all, you can still use Web Deploy to deploy the application in to IIS using the Microsoft.Web.Deployment.aspx) assembly.

Conclusion

For this very unique type of deployment, I find the hybrid approach works the best. Leverage Web Deploy for as much of the deployment as possible, then build a nice installer-like wrapper using WPF or Win Forms. This option gives you the best level of flexibility and will provide the best install experience possible for your clients.

NOTE: I am planning on building a sample application to demonstrate this concept and will update this post when it is completed.

I see your commit message and raise you a joke

Commit messages (check-in comments) are a very important part of the software development process. Source control keeps track of all changes to a file, but we need good commit messages to understand the intention behind a particular change to a file. Anders Sandvig has a good overview of how to write good commit messages in this blog post.

I remember explaining to a junior developer that when he checks in his code, he should write a comment describing what he was doing. He looked at me like I was an idiot and proceeded to commit with the following message:

Checking stuff in

Okay, that was my fault….I should have been more clear. I rephrased my instructions: “When you check in your code, write a comment that describes the change you made to the code.” The new instructions made a lot more sense to him and his comments improved over time.

Today, I was reviewing the commit history for Entity Framework 6 (http://entityframework.codeplex.com/SourceControl/list/changesets). I can’t remember exactly why I was there because I very quickly found myself laughing while reading through the commit messages. Apparently the EF team is staffed with comedians. Their commit messages start with a short joke, then proceed to explain the change like any good commit message would.

Here are a few of my favorites:

it’s late, it’s late, but not too late

<Everyone loves:xml="even though" xmlns:loves="to annoy everyone" />

If you build the factory they will come

Vegan Beat Manifesto

Revoking the 5th

What Happens in RelatedEnd stays in RelatedEnd

I’ll see your beta and raise you an rc

 

I like this approach. Start with a short joke, then explain the change. I think that humor in the workplace helps to keep us sane. Let’s face it: Our jobs can be very frustrating at times. Chances are if you are looking at the version history for a file, you hare having ‘one of those days’. Seeing a commit messages that makes you chuckle will probably improve your mood. Until TFS and Git allow us to attach pictures of kittens to our commits, humour is our only option.

Checking stuff in YEAH!!!!! | HAPPY KITTEN

Challenge yourself to insert some humor into your next commit messages. When all else fails….whatthecommit.com

Fiber to the home

When I announced my move to Grand Cayman, I said the 2 things that scared me the most where hurricanes and slow internet.

I turns out I don’t need to worry about the slow internet. Yesterday, I had Fiber internet installed and I am very happy with the speed: 12 Mbps download and over 15Mbps upload. I could pay more to bump my download speed to 50Mbps, but it’s not worth the price right now.

The test above is from Grand Cayman to Miami, which shows that I have a solid connection from my home back to the main land. It is also very interesting that my upload speed is higher than my download speed. The upload speed is higher than anything I ever had in Canada. (Shaw, your download speeds are great, but it’s time to do something about your upload speeds. 3Mbps just doesn’t cut it)

Yesterday, I added 1.2 GB of images to SkyDrive and it only look 25 minutes to upload. I had a Skype call and TeamViewer session with my brother in Saskatoon. The call was crystal clear and there was almost no delay when controlling his PC with TeamViewer.

Now if I could only do something about those hurricanes….

Running MiniProfiler.EF with Entity Framework 6 RC1

Last week, I tried testing some of the new EF6 features in my usual sample application. Unfortunately, the application crashed because the version of MiniProfiler.EF I was referencing only works with EF4/5. As someone pointed out on Mini Profiler community forum, EF6 support was added to GitHub but is not yet available in the Nuget package.

I am too impatient to wait for a new Nuget package, so I went over to Github and cloned the MiniProfiler repo.

Upon inspecting the MiniProfiler solution, I noticed there are 2 Entity Framework related projects: StackExchange.Profiling.EntityFramework and StackExchange.Profiling.EntityFramework6.

 

Why is this implemented in a different project? In short, because the EF team made it WAY easier to extend Entity Framework by implementing a new Provider Model. You can read more about that here. The Mini Profiler folks used this feature to implement hooks into Entity Framework 6. You can tell how much easier this was to implement because the old assembly (StackExchange.Profiling.EntityFramework) contains 10 classes. The new StackExchange.Profiling.EntityFramework6 assembly contains only 2 classes! The classes are very small too. Just a few short methods.

After snooping around in the code, I compiled the project and added a reference in my sample application to the new MiniProfiler.EntityFramework6.dll. Finally, I added the following code in my application start logic:


DbConfiguration.Loaded += (sender, a) =>
a.ReplaceService(
(services, o) =>
EFProfiledSqlClientDbProviderServices.Instance);

 

This is a little more complicated than initializing MiniProfiler for EF4/5, but I suspect the Mini Profiler team will provide us with a simple MiniProfilerEF.Initialize() method before they ship a Nuget package. In the mean time, you can follow the steps above to get Mini Profiler EF working with EF6 RC1.

UPDATE: I received an email from Tom Powers pointing out that the above can also be accomplished by setting the EF provider in your [Web.config / App.config.

As far as I can tell, the profiler output is unchanged:

](https://www.davepaquette.com/wp-content/uploads/2013/09/image_thumb.png "image")

It is also worth noting that simple SQL logging essentially built in to EF6. You can read more about that here.

Entity Framework 6 RC1

In case you haven’t heard, the Entity Framework team published a release candidate (RC1) last week. You can find the details in Rowan Miller’s blog post here. Enough with the unicorns…I am naming this version of Entity Framework Magic Narwhal Edition.

File:Narwhals breach.jpg(wikipedia)

I was excited to try out the new bits and I thought I would run a test today to see if EF6 provided any noticeable performance difference in my test application. Unfortunately, I ran into a couple issues that stopped me from finding out.

1) Many-to-Many Table Naming Convention

This one threw me for a loop. After updating to EF6, I got the common “your model has changed since the database was created” message. I used the usual “Add-Migration” command and was surprised by what I saw. Entity Framework created a migration that deleted a few indexes, foreign keys and tables and created some new tables. Upon further inspection, I saw that something seems to have changed with naming conventions for tables used in many-to-many relationships.

For example, my model has a relationship between Users and Groups. A user belongs to many groups, and a group can have many users. In my EF5 database, this was represented with a table named UserGroups. For some reason, EF6 wanted the table name to be GroupUsers.

What is really dangerous about the migration created by EF6 is that the data was deleted. The new table was created and the old table was deleted, without ever moving the data across. To fix this, I added a step before dropping the old table:

Sql(“INSERT INTO dbo.GroupUsers SELECT Group_Id, User_Id FROM dbo.UserGroups”)

I had to repeat this for each table that was renamed. I’m not sure if this is expected behaviour, but watch out for it. You might lose data when you were not expecting to.

2) Running MiniProfiler

I like to use MiniProfiler to profile the SQL that is executed by Entity Framework. Unfortunately, I could not get MiniProfiler to work properly with EF6. No matter what configuration I used, I would always get this error:

Unable to cast object of type ‘StackExchange.Profiling.Data.EFProfiledDbConnection’ to type ‘System.Data.SqlClient.SqlConnection’.

 

I will continue exploring EF6 RC1 and report on my findings here. I am curious to hear from anyone else who has tried it out.