Wintellect F# Blog Post Collection

/

I know it seems I've been MIA lately, but the truth is I've actually been blogging quite a bit on F# at my spot in Wintellect for a little while. Below is a collection of what's currently out there.

There will definitely be more in the future so keep an eye out there for more posts on F# and there may even be a few on Xamarin with F#.

Introduction to Paket

/

Paket has been quite the talk lately in the .NET community, and for very good reason. It is essentially another way to manage dependencies in your .NET projects.

But why replace NuGet?

Paket is basically a NuGet replacement so I'm sure you're wondering, "why would we need to replace NuGet?" Paket essentially just takes the functionality of NuGet and adds some extra nice features.

For one thing, Paket makes it able for you to control exactly what's happening with your package dependencies. No more conflict between different packages if those packages reference different versions of the same dependent package.

Another really cool thing Paket does is that it can reference a single file from GitHub. How many times have you needed that and just wound up downloading what you needed and using it that way? If a new version of that file comes along, you'll have to repeat that process.

But I'm already using NuGet

No problem at all! Paket has a nifty convert-from-nuget command to get you up and going.

I'm hooked...but how do I get started?

First, you need to include a .paket folder in the root of your solution. This will include paket.exe that will be used to install and restore packages.

Once that folder and its contents are there, you'll need to create a paket.dependencies file in the root directory of your solution. This file will be similar to the following:

source http://nuget.org/api/v2
nuget FSharp.Data
nuget FAKE

This file tells Paket what the sources are (NuGet or GitHub) and the package/file names so it can be downloaded.

You can then use a build.cmd file or manually call paket.exe like below.

\.paket\paket.exe install

This will create a packages folder that will include all the libraries.

From here you can always manually reference the libraries that you want, but Paket makes this easy as well. In each of the folders where you have a project file, create a paket.references file that contain the names of each library you want to be referenced, like below.

FSharp.Data

Note that FAKE isn't in the file since it won't get referenced. The paket.references file will only add to the project if the library is in a lib folder. FAKE is in a tools folder. This isn't a problem since it can be referenced manually in the build.fsx file.

To get Paket to use the references file, simply rerun the install command with the --hard switch.

\.paket\paket.exe install --hard

This will look at the paket.references file and use that to automatically reference the project with the appropriate libraries.

After that, you're good to get started on your project.

Conclusion

Hopefully this walkthrough will help you get started with using Paket to make your package management easier than before. This is still a young and very active project so I wouldn't be surprised if there are tons of things that this can do for all of our .NET projects.

Xamarin Evolve - Recap

/

I wanted to get a day two recap out Thursday night like I did the day before with day one but, and I'll be honest with you, day two was just so much fun and action packed that as soon as I got back to the room I went straight to bed to try to get enough rest for the final day. So in this post, I'll go over day two and the final day of the conference.

Day Two

Day two of the conference was all about the sessions. Here are a few of the ones I attended.

Sketches

This was one of the secret sessions they had listed on the schedule and I'm glad I went to it to find out more. Mostly this was just an expansion of what they shown in the keynote but with a bit more of an elaborate demo. The cool thing, for me, is that Sketches will support F# as well soon. That'll be good for just having a sandbox to learn more about the language.

Xamarin Studio

One of the more interesting sessions was this one on how to master Xamarin Studio itself. What impressed me most about Xamarin Studio was that there is a setting in the preferences (Text Editor -> Source Analysis) that has a very similar analysis that ReSharper has for Visual Studio...and before Visual Studio even incorporated it!

Cross-platform Apps in F

I admit, one of the main reasons I wanted to come to Xamarin Evolve was to go to these F# sessions and they certainly didn't disappoint. This was the first one where Rachel Reese gave her talk on running iOS and Android apps using F# with a bit of a nice F# introduction mainly concerning with why we would want to use it.

Closing

The final day was just a few more sessions in the morning then the closing announcements.

Awesome Apps in F

This fun talk was mainly with why use F# (or basically any functional language) and showed how much more concise and readable refactoring from an object oriented way to a functional way can be.

Conclusion

The best way to describe this experience was that it was nothing short of amazing! Big thanks to Xamarin and all of their employees for making this happen and being awesome! I really look forward to next year and I've gotten the thought in my head to even try to present at the next one.

Xamarin Evolve - Day 1 Summary

/

Considering this is my first time going to an actual conference, especially one at this size, I believe I could be easily impressed by anything done at Xamarin Evolve. And indeed, I was impressed! From all the the quality of the presentations to just how well this event is being run, this is definitely an event I'll remember and will want to come back to next year.

I admit, I haven't done much with Xamarin and their tools other than getting excited over this conference and some small playing around with Xamarin Studio. After this first day, though, I'm excited to play around with it a lot more and utilize it for mobile apps.

Keynote

Things started off with the co-founders on stage giving a keynote that contained quite a few surprises.

Profiler

First thing announced was a profiler for Android and iOS apps to help developers dig deeper into performance issues. This is apparently helpful since there isn't really an alternate solution for profiling mobile apps. Especially one as nice as they have made.

Mobile UI Tests

This one really got me excited the more I saw demos of it in use. The Xamarin team has created a library to create unit tests that can launch the app and perform actions within the app. If certain items on the screen can't be found or an action can't be performed, it will fail the test.

Now this by itself can be useful for an integration test suite, but what's really exciting is this is integrated into the Xamarin Test Cloud so the tests can be run on all devices that it needs to be run on!

Android Player

I'm sure that if you ask any Android developer what the biggest pain point is in developing an Android app is that the emulator take a really long time to start up when debugging/running an application. Really...you can probably go on a 30 minute walk and it may be finished loading the OS and start your app.

What Xamarin has done was to create a way better experience for this. During the demos the Android Player took way over half the time to launch, start the OS, and launch the app than with the emulator. This by itself definitely got most people excited.

Sketches

Another interesting thing they announced is Sketches which is a live coding environment that executes the code as you type. The interesting thing with this, though, is that they've integrated an analysis pane. Xamarin has allowed graphing within Sketches. If prototyping a small UI, you can even use Android or iOS components right within Sketches.

Xamarin Insights

Xamarin also announced a way to monitor apps when they have been published and out for the public to use.

Xamarin Insights looks like it has a lot to offer than the other services that do this. Just by adding only a few lines of code in your app you can get real time notifications of errors that includes stack traces and even show how users will interact with your app.

This and the UI tests together will make a world of a difference in the quality of your mobile apps.

Day One Conclusion

Just after day one I'm glad I decided to come to this conference. I've already learned a ton and got back some excitement from coding that I used to have. I can't wait for what's in store for day two.

Why F# for the Enterprise

/

I have gotten bit by the F# bug lately. After helping to release the F# portion of Exercism I've started to enjoy more and more of what F# has to offer. Of course, F# is a sort of "hybrid" language where you can do object oriented and procedural programming if you make it that way, but out of the box it's trying to get you to go more functional.

Several folks have posted as to why learn F# in the first place, but I figured I'd give some reasons why I think F# would be great for scenarios inside enterprise applications. While a few what others have mentioned as good reasons to learn F# in the first place, I believe these would also be the top reasons for enterprise development.

What's wrong with the current enterprise solutions?

Well, nothing, really. Of course, just because one solution works doesn't mean it's the most productive or easiest to maintain. For example, CSS precompilers like SASS and LESS do this with plain CSS stylesheets.

Why not use something that makes our lives, as developers, easier and helps to bring back the fun in developing again?

No More NullReferenceExceptions

While the above always tends to make me laugh, I'm quite sure each and every developer has fixed a production defect that involved this error. 

In F# there are is no thought of "null". You'll even get a compiler error if you try to use "null" in a pure F# program. For example, take a peek at the below code:

We're just defining some record types - Person and Employee - and let binding the Employee record with some values. Now, what happens if I set Person to null?

The compiler won't even let us try that...

Trying to assign null to a record type.

So this shows that, in pure F# code, the compiler won't allow us to set records as null which greatly reduces, perhaps even eliminates, NullReferenceExceptions.

What if we still need null?

There are some exceptions where F# will allow you to use null. Both of which involve using the .NET libraries.

  • As a parameter when calling one of the .NET libraries.
  • Handling if a call to a .NET library returns null.

Even using null in these scenarios can greatly reduce the NullReferenceException occurring in your application. To me, that's just one less thing I need to worry about.

But I still need it in my F# code

No worries! The language has you covered on that aspect as well. Allow me to introduce the option type. This is used if a value might not exist.

Let's take a small example of a bank account.

If the account isn't open yet or has already been closed, we don't expect a value. Otherwise, we do expect some value.

None vs null

How is this different than assigning to null? Remember that None is an option type. Because of that, the compiler will help us out if we may have missed anything. For example, in F# you can do pattern matching. Let's see how we can use pattern matching with the option type.

Good to go there. But, what if we happened to miss a match on None? We'll get this warning:

Pattern match warning.

Units of Measure

Units of Measure allow you to explicitly type a certain unit. F# does have predefined unit names and unit symbols in the Microsoft.FSharp.Data.UnitSystems.SI.UnitNames and Microsoft.FSharp.Data.UnitSystems.SI.UnitSymbols namespaces.

For example, say we wanted to use meters. Instead of assuming our application is using meters throughout all the calculation, which has a probability of being converted to another unit but still being represented as meter, we would just need to do the following:

Microsoft has included a few units of measure for us, as mentioned earlier, but we can definitely create our own. Say we had an application that dealt with different types of world currencies. We can easily define them as units of measure.

Now, what does this do for us exactly? Let's try to convert how many euros are in a dollar amount.

The first method we defined works just fine since we're using the units of measure. However, the second method generates a compile error since it can't infer what type "0.74" should be.

Since a unit of measure is typed, it will generate compile errors and reduce the amount of defects your application can cause due to a mismatch of units. This type of error does happen in real world applications...even to NASA engineers.

Type Providers

Type providers in F# is essentially a way to access all sorts of data. There are quite a few of them all ready for you to use now.

Just the SQL type providers alone are worth it for enterprise applications. Even better, you can even use them to access Entity Framework and LINQ to SQL.

Another important one that may be of great use to enterprise applications is the JSON type provider. 

Type providers provide an easy way to consume data within F# and, if you'd like, use C# to handle that data.

 

The above are just a few reasons of why I believe F# to be of great use to developing enterprise applications. Using the above, the risks of error would be greatly reduced and productivity would be increased. I know I'll be doing more F# in my applications from now on and I can only see it getting even better in the future as this language evolves.