I’ll be Speaking @ Progressive .NET Tutorials in July

Why

Recently Microsoft has really gotten it’s act together, at least for those of us that really love some of the Microsoft tools, but really don’t want to touch Windows. I’m perfectly happy not dealing with Windows, so this has been great news for me.

With the recent Build event Microsoft released Visual Studio Code, which is a fully cross-system compatible IDE that is lean, fast, and allows for building software with multiple languages. Of course, it works with several .NET languages such as F# and C#, and even will let you dive heavily in JavaScript Node.js based applications. I wrote a quick “Notes From the Front: 5 Minutes With Visual Studio #Code” a short while ago. Along with that I wrote “OS-X and F# [Clone It, Build It, Install It, Hack It]” and “Why F#, and Why Not Windows” as a follow up to this new growing world of Microsoft options.

Now, don’t get me wrong, Windows definitely has some plusses. It just isn’t the system I’d prefer these days, as it doesn’t hack it in the startup lands of Silicon Valley, Portland, Seattle, Vancouver BC, or other such places. In these lands, people speak and work with the *nix landscape first, and everything else is secondary. But that doesn’t remove the desire I have for applications, devices, and other tooling that enables compatibility across all of these systems.

With those thoughts, I sat down and started putting together some presentations on what’s possible with this new freedom around Microsoft tooling. Already I’d worked pretty extensively with Node.js and the tooling Microsoft has added to Visual Studio, Azure, and all those related things. Now I’m looking forward to checking out some of the other capabilities around F#, and the respective API options and other new OSS technologies like Akka .NET, and even M-brace. So here’s the gist of my presentation so far, and as I give this talk I’ll provide other related information on the page I’ve setup for the talk here.

Presentation Title: Visual Studio & .NET on OS–X, Linux, and Windows

“From the inception of Mono on through to today’s Omnisharp and the introduction of Visual Studio Code at Build 2015. I’ll take a look at where cross-platform compatible solutions have been and where we are now with code samples along the way with some discussion on mobile topics too.”

I’ll be adding a bit more to this also, and will have the demos and related code samples located here.

Who, What, When, Where

So where am I giving this presentation? Check out Progressive .NET Tutorials 2015 for more information. The conference is in London and I’m officially on the program page (so obviously I’m going eh!). They haven’t released the exact time of each talk, but what you should do is just come attend the whole conference! I’ll be speaking on the 3rd. The location of the conference is in the grand city of London, located specifically at this fine establishment.

I’ll have more about the conference and other technical tidbits in the near future. Very soon I will also be announcing a chance to win a ticket to Prog .NET Tutorials, so stay tuned, subscribe, and follow me on Twitter @adron for more info.

Simplifying bash & repl Use With F#

That prompt… let’s get F# so that we can compile and run a file in about a zillionth of a second from the repl.

First I setup a bash script that would be used to compile and then run the file. I created the file and simply named it “fs”. Inside the file I wrote the following script.

[sourcecode language=”bash”]
echo "Compiling F#" + $1
fsharpc "$1.fs"
mono "$1.exe"
echo "Running Executable" + $1
[/sourcecode]

I put that in my scripts folder that I have added to my path in my ~/.bash_profile (or bashrc depending on what you’re rolling with).

[sourcecode language=”bash”]
export PATH="$PATH:~/Codez/scripts"
[/sourcecode]

So now I have the ability to type in the following command and filename and the compile and the executable will be run. It makes for much easier repl usage.

[sourcecode language=”bash”]
fs theFileNameGoesHere
[/sourcecode]

Got any tips or tricks to running F# somewhere besides Windows? Let me know and I’ll be sure to give you a shout out on Twitter and whenever I’m giving a presentation on hacking F# without Windows.

Why F#, and Why Not Windows

I posted my previous entry and got a few retweets and favorites. One reply came back and made me think, “ah, it might not be obvious why I’d like to have F# on something besides Windows.” Well, here’s a list of why I want to use F# on non-Windows platforms.

  1. F# is a good language. I can’t say the best, since I honestly don’t have enough experience with it or other functional languages to really declare a victory in my opinion. However I’ll be doing some work with Scala, Haskell, and Erlang in the next couple of weeks for testing and use with some upcoming projects.
  2. There are only two technology stacks that will let one spin up an actual application on all of these technologies: OS-X Cocoa, Windows, Linux, Android, and iOS. These two tech stacks are .NET and than the Node.js JavaScript stack – with the latter being purely web based. (Yes, some could argue Adobe’s tools or the Java stack, but I’m not going down that route right now, as both are somewhat bloated and convoluted in ways we can go into at some other time)
  3. With F# I get a clean functional language that I can build native mobile, tablet, or OS apps and all the web services that I want with two advantages over Node.js. The first is the performance edge and can likely be tuned more anyway. Being paired with SignalR one can even get some wicked simple and fast real-time capabilities with minimal code. The second is it takes less F# code to do similar JavaScript things and compute, let me tell you about compute with F#. F# can run things that JavaScript just really can’t measure up to when it comes to compute. But aside from these things, they’re both excellent tools and I wanted to have F# in my tool belt.
  4. There’s always the backup plan of just converting to JavaScript too, if I needed that sort of thing. Check out FunScript.
  5. The community around F# is actually pretty cool, there are good, solid, intelligent, and friendly people in that community. Having a good community of people always makes getting into a new language or related tech much better then when the community consists of asshats or jack ass savants.

Other great things that add to the usefulness of F# include WebSharper, .NET MVC 5 and Web API, Nancy API, Suave.io, and there are others.

So those are the reasons I decided to move forward with F#: solid language, provides a solid technical stack with options, it’s functional and clean with extra compute power, and a kick ass community. Of course F# came from the land of Windows and Softies (that’s short for Microsofties, and I didn’t make that up). But F# was handed over to the open source community and currently moves forward autonomously of Microsoft. By proxy of this event, and other culminating events of late, F# can easily run on operating systems besides Windows. I’m not a fan of Windows, and here’s a few snarky (yet very real) reasons why I don’t even want to mess with Windows (except in the situation where I really do want to or need to use Visual Studio).

  1. Windows is still slow. I could go into the reasons, but it tends to build slow, behave slow, be prone to the attention of spammers and such, only in the last X years has it managed security in a half ass decent way, which also leads to slowness, and … oh you get the idea. It’s a slow OS.
  2. It’s flippin’ humongous. Now is this really a problem? Not really, but it’s annoying to force fit it in when I’m doing DevOps work or actually attempting to load Windows related images with it. The OS itself is still a nightmare of gigantic proportions compared to spooling up other systems. If one wants to fight with it, that’s great, I don’t really feel a keen desire to fight with it.
  3. Linux == Smaller footprint, more features, let’s not bring up security, is actually used on major systems, large scale systems and super-computers. Windows has less than 2% market share in that space. Even Microsoft is decreasing their reliance on Windows, offering oodles of Linux options.
  4. Windows doesn’t tend to get, run, or have the bleeding edge tech options built for it. Go look at the open source massive distributed systems applications and other excellent leading platforms and tooling that are leading companies into the future. If Windows is involved at all, it’s often an afterthought. :-/
  5. Windows 8 interface. I’m just going to leave that one right there. I like a lot about it, but I’m with Microsoft, even with Windows 10 they’re not trying to push this UI/UX catastrophe any longer.
  6. SSH not built in. End of story.

Don’t get me wrong, the tooling on Windows for doing Windows specific development and even doing crud apps with lots of business rules is spectacular. I’d even bet that the .NET ecosystem does a better job, sometimes dramatically better, than the Java ecosystem when it comes to those types of applications. I however, haven’t built these style of applications in a long while. Whenever I do, Windows might be a prime option, but otherwise I’ll stick to the operating systems that get me into the coding faster, sooner, and with less resistance.

Outside of Windows there are a lot of great Microsoft tools and technologies that I’d love to have on non-Windows operating systems. One of those is F#. Another is Visual Studio, which I’m betting will continue to get better and better. I’d like to have C# (which I do with Xamarin and such) and a whole ton of other scaffolding and crud tools and other things that are available. I just prefer them without Windows.

As I often say, to each their own. Mine just isn’t Windows these days.

OS-X and F# [Clone It, Build It, Install It, Hack It]

Ok.

Mission: Get F# running on OS-X and executing via repl.

There are a number of steps here, that if you don’t have everything covered things just won’t work. So let’s knock out the prerequisites first. This will include getting autoconf installed. There are some other tools that I’ve added below that are good to have installed too, so get autoconf, automake, and libtool installed.

[sourcecode language=”bash”]
export build=~/devtools # or wherever you’d like to build
mkdir -p $build

cd $build
curl -OL http://ftpmirror.gnu.org/autoconf/autoconf-2.68.tar.gz
tar xzf autoconf-2.68.tar.gz
cd autoconf-2.68
./configure –prefix=/usr/local
make
sudo make install
export PATH=/usr/local/bin

cd $build
curl -OL http://ftpmirror.gnu.org/automake/automake-1.11.tar.gz
tar xzf automake-1.11.tar.gz
cd automake-1.11
./configure –prefix=/usr/local
make
sudo make install

cd $build
curl -OL http://ftpmirror.gnu.org/libtool/libtool-2.4.tar.gz
tar xzf libtool-2.4.tar.gz
cd libtool-2.4
./configure –prefix=/usr/local
make
sudo make install
[/sourcecode]

Now we’re ready to get some F# (64-bit flavors too) running on OS-X. This is very likely to take more than a few minutes because we’ve got two actual builds to do here.

First step is to get mono built and installed.

[sourcecode language=”bash”]
git clone https://github.com/mono/mono
cd mono
./autogen.sh –prefix=/mono64 –enable-nls=no
make
sudo make install
[/sourcecode]

Now clone fsharp, build and install it.

[sourcecode language=”bash”]
git clone https://github.com/fsharp/fsharp
cd fsharp
./autogen.sh –prefix=/mono64
make
sudo make install
[/sourcecode]

Finally get the binary executable paths added to the paths file.

[sourcecode language=”bash”]
vi /etc/paths
[/sourcecode]

Add the following paths to the paths file.

[sourcecode language=”bash”]
/mono64/bin/mono
/mono64/bin
[/sourcecode]

Once that’s done, run the tests to confirm everything has built right and is operable.

[sourcecode language=”bash”]
cd tests/fsharp/core
./run-all.sh
[/sourcecode]

Now… that should all be ok.

repl

What I wanted now is something to sling some code and execute it. The easiest way, is to use the ‘fsharpi’ repl. At the OS-X terminal launch the repl.
Enter this line…

[sourcecode language=”bash”]
let x = 5;;
[/sourcecode]

Then let y to a value…

[sourcecode language=”bash”]
let y = 20;;
[/sourcecode]

Then enter…

[sourcecode language=”bash”]
y + x;;
[/sourcecode]

…and you should see the math calculated. Then you can quit out of the repl with the following command.

[sourcecode language=”bash”]
#quit;;
[/sourcecode]

The overall repl should come out looking like this.

[sourcecode language=”bash”]
> let x = 5;;

val x : int = 5

> let y = 20;;

val y : int = 20

> y + x;;
val it : int = 25
> #quit;;

– Exit…
[/sourcecode]

Compilation – A Step Further

Just to show one more step. Let’s do a compile of a file with F# Code in it. Create a file called process.fs and enter the following code.

[sourcecode language=”fsharp”]
open System

[<EntryPoint>]
let main (argv :string[]) =
printfn "Hello World"
Console.ReadLine() |> ignore
0
[/sourcecode]

Now run the compiler ‘fsharpc’.

[sourcecode language=”bash”]
fsharpc process.fs
[/sourcecode]

Now before you freak out screaming “OMG WTF am I supposed to do with a process.exe file…!!!” just calm down and execute the following command.

[sourcecode language=”bash”]
mono process.exe
[/sourcecode]

There you’ll see the execution of “Hello World”. Welcome to F# on OS-X. More to come, Keep thrashing code!

Note: I’ve got a github repo for this and coming F# coding available at sharpgrounds.

Documentation First w/ README.md && Project Tree Build

I’m sitting here trying to get the folder structure for my project into a kind of ASCII Tree or something. I wasn’t going to manually do this, it would be insane. Especially on any decent size Enterprise Project with an endless supply of folders and nested content. I went digging to come up with a better solution. On Linux I immediately found the Tree Utility which was perfect.

Except I was on OS-X.

First option I gave a go to was to build the thing. Because I like to do things the hard way sometimes. First I needed to get the source, which is available here.

[sourcecode language=”bash”]curl -O ftp://mama.indstate.edu/linux/tree/tree-1.7.0.tgz[/sourcecode]

Once downloaded, unzip the source into a directory and find the following section for the particular operating system you want to use the utility on. The section for OS settings looked like this when I finished editing it.

[sourcecode language=”bash”]
# Uncomment options below for your particular OS:

# Uncomment for OS X:
CC=cc
CFLAGS=-O2 -Wall -fomit-frame-pointer -no-cpp-precomp
LDFLAGS=
MANDIR=/usr/share/man/man1
OBJS+=strverscmp.o
[/sourcecode]

Now get a good build of the command file.

[sourcecode language=”bash”]
./configure
make
[/sourcecode]

Now let’s get tree into the executable path.

[sourcecode language=”bash”]
sudo mkdir -p /usr/local/bin
sudo cp tree /usr/local/bin/tree
[/sourcecode]

Make sure your ~/.bash_profile is setup right, include this.

[sourcecode language=”bash”]
export PATH="/usr/local/bin:$PATH"
[/sourcecode]

Reload the shell and tree should be available as a command.

The other option which is really simple, if you don’t want to compile to code, is to just use brew to install it.

[sourcecode language=”bash”]
brew install tree
[/sourcecode]

So now you can use tree, and do cool stuff like pipe it out to a file. If you’re running this against a Node.js Project you may want to delete the node_modules directory and then just reinstall it after running the tree command.

[sourcecode language=”bash”]
tree > prof-tree.md
[/sourcecode]

Then in your README.md file you can include the folder structure in the description of the project. Here’s a sample output!

[sourcecode language=”bash”]
.
├── README.md
├── client
│   └── README.md
├── package.json
├── proj-tree.md
├── server
│   ├── boot
│   │   ├── authentication.js
│   │   ├── explorer.js
│   │   ├── rest-api.js
│   │   └── root.js
│   ├── config.json
│   ├── datasources.json
│   ├── middleware.json
│   ├── model-config.json
│   └── server.js
└── test
└── test_exists.js

4 directories, 14 files
[/sourcecode]

That’s a super easy way to offer better documentation that provides some real insight into what various parts of the project structure are actually for.