Monday, May 30, 2016

Ham or Spam with F# & Xamarin

I'm continuing my F# journey with a second course from FSharpTV called Functional Programming with F#.

The course picks up the familiar approach of small learning units sprinkled with coding exercices. It's a format that works very well with me, particularly when I might have not more that half an hour free. Small and focused learning sessions for the win.

This time, the course departs of the purely fun aspect of learning F# and tackles pragmatic issues.

The first section gets our hand dirty with test units and publishing a library. This might seems trivial steps for those already versed in the .NET universe, but for those new to the ecosystem, it provides much needed guidance.

The second section builds nicely on the core concept of the first course. It gives a very approachable introduction to the concept of Bayes theorem and machine learning trough a spam filtering project.

The final part of the project concerns itself with dealing with command line arguments through an (for me) elaborate library called Argu. After having my understanding of F# solidified, I felt a bit like Alice in Wonderland when I saw some Cheshire Cat syntax like <@ @>. Can't wait to eat the cake and learn more on my next course!

Saturday, April 30, 2016

Learning F# with Xamarin

I've been interested in F# for a while now, but at the end of last year, I decided to at least learn the basics.

(For an idea of why you might be interested in learning F#, I suggest this article: The Case for F#)

I'm on a Mac, and didn't even have Mono installed. I fiddled a bit in getting started with either Atom or Visual Studio Code, but always had some small problems. Shortly after, I found out about FSharpTV's Start Programming With F# Today. It was using Xamarin, which had a free edition at the time and that is now not only free, but open-sourced!

I installed Xamarin and the today from the class titled turned out to be true! I didn't have to fiddle with anything and I could learn with the class instructions without having to make mental translations to another coding environment.

There are so many learning platforms now, but I really liked the choice of Udemy. The UI is straight forward and intuitive. I also do a lot of learning on my daily commute, and the Udemy app with offline capabilities for the videos is absolutely essential to me.

I'm just gonna say right here that the class turned out to be a perfect fit for me. The basic format of having short lessons peppered with coding exercises is great for actual learning. It's my biggest problem when learning a language to just read and read and not do actual coding. With this class, I just had to, and it didn't feel like a chore, it was a pleasure! The gist of the class is to get us to generate spirographs. The combination of incrementally adding features while learning the language and experimentations with the interactive shell made the experience very dynamic and rewarding. F# is statically typed, but the development environment is very much dynamic!

The class is in Beta, and some videos were being remade while I was taking it. As such, it could happen that a later video was not perfectly in sync with what had been done in a previous video. Nothing that threw me off, though.

The class didn't try to cram us with everything. It is a really enjoyable introduction to the F# language and just enough of the ecosystem to get us started (specially for me who didn't already a .NET environment in place.)

All the while I was following the class, I was wondering how the parsing and dealing with a Domain Specific Language for the spirographs was going to be dealt with in an introductory course. It turned out to be made simply, elegantly and unexpectedly. It blew my mind, but I won't tell you how; you'll just have to go through the class!

In short, Start Programming With F# Today is a great on-boarding experience for learning the rudiments of F#!

Monday, April 25, 2016

Programming language/framework as a secret weapon

I recently tweeted:
Now, I do not mean that your team isn't more productive or better with the PL/framework of their choice.

What I mean is there's a lot to (human) execution. For somewhat similar tools, I bet your team can rock it irregardless.

But that's not what I'm getting at.

Some companies strive to keep their PL/framework a secret, fearing competitors would use it gain the upper hand. In my experience, it's already hard enough to convince colleagues to try a radically different language/framework, I find it unlikely. And even if the competitors suddenly adopt your PL/framework, it doesn't mean it's a good fit for their team. Or if their team is already rocking it with their own tools, would it really make a significant difference for them to adopt yours? It doesn't mean it's never the case either. I'm making general observations.

What I'm really getting at.

Keeping closed knowledge about your usage of a public PL/framework hurt your company and hurt the community. Your team won't get as much benefit from the community if they don't actively participate in online forums and local user groups. You're also losing the opportunity to sow knowledge that would benefit the community, grow, and get back to you!