__3 “Going the Full Mile, Continuous Delivery.”

In the last few issues of this series, the team has done the following:

  1. Introducing the Thrashing Code Team & Projects” – Know who’s working on what and what the projects are.
  2. Getting Started, Kanban & First Steps for a Sharing App” – Getting the kanban put together and the team involved.
  3. Starting a Basic Loopback API & Continuous Integration” – Getting the skeleton of the API application setup and the continuous integration services running.

In this issue of the series Keartida is continuing with setup and configuration of the next step, getting to a basic continuous delivery of services with a basic AWS Elastic Beanstalk setup.

AWS Elastic Beanstalk

Let’s talk a little bit about the solutions and working with teams in the solutions before diving into Keartida’s efforts. With each of the SaaS solutions that I’ve pointed out in the last couple of entries each has a specific connection, integration, or reliance on Github. This is, of course perfect so that each part works seamlessly together. AWS has it’s own user management system which also needs to be taken into account.

In CodeShip

It’s easy to add members to a build, which I covered in the previous entry in this series.

In Waffle.io

Waffle.io actually is pretty simple. Simply sign in with your github account and you’re in with an account. But to access certain projects one does have to setup and share the respective kanban boards. The way to do this with Waffle.io is to actually setup users based on the github permissions setup for the user for the particular project.

In AWS

To get users setup in AWS is a little differently. What we need to setup a full build and delivery of the application to AWS is to get the user’s key pair. Let’s take a look at setting up a group and a user in Amazon for this purpose. In this case I am going to create a user for deployment purposes.

On the main AWS Dashboard here, click on Identity & Access Management.

AWS

AWS

On that page there are several options listed on the left hand side. Click on the Groups and then click on the Create New Group button. After that a wizard will come up.

Groups

Groups

Enter the group name and click next.

Group Name

Group Name

In the Attach Policy step, slect the S3 Full Access and Elastic Beanstalk Full Access policies for this account.

Selecting Policies

Selecting Policies

Once the appropriate polices are selected to be attached, click on next step, review and then add the group. Then select the group that was just created and click on the

Add Users to Group

Add Users to Group

Once the appropriate user is added, then the parts to wrap up the delivery part of the deployment are all set. Back to what Keartida was working on!

Keartida Deploys coder-swap

First step, Keartida logged into the AWS management console.

AWS Management Console

AWS Management Console

Since this is the first Elastic Beanstalk Application that Keartida has deployed, when she clicks on Elastic Beanstalk this screen appears.

Welcome to Elastic Beanstalk

Welcome to Elastic Beanstalk

From here, she selected Node.js from the drop down and Launch Now. From there a quick wizard appears and let her enter the name of the application and a description.

Creating the first Node.js Application

Creating the first Node.js Application

The application starts being created.

Creating the Application.

Creating the Application.

When this is created, the funny thing is the wizard creates a application environment name that causes problems. Keartida and I found this out the hard way, and figured out it is best to just delete this application and create an application and an environment name that works better.

Deleting the Application With the Odd Naming

Deleting the Application With the Odd Naming

So this time going back she created the application space specifically and went through the various steps to create the application.

Creating the New Environment in the new Application Space.

Creating the New Environment in the new Application Space.

Creating a new environment.

Creating a new environment.

Creating a load balanced, auto-scaled elastic beanstalk application

Creating a load balanced, auto-scaled elastic beanstalk application

Basic Settings

Basic Settings

More Settings.

More Settings.

Keep clicking next and then…

Then let the beanstalk start.

Then let the beanstalk start.

Now that this is started Keartida logged into CodeShip to setup the final deployment steps for good builds to deploy directly to this beanstalk application.

CodeShip Builds and Where to find Deployments

CodeShip Builds and Where to find Deployments

Once Keartida clicked on Deployment she had options to pick what to deploy to. One of the options is of course Elastic Beanstalk.

Selecting a Branch and What to Deploy To

Selecting a Branch and What to Deploy To

Selecting Elastic Beanstalk to deploy to

Selecting Elastic Beanstalk to deploy to

The next screen provides options to select branches of the build to deploy with and related information.

Set the Elastic Beanstalk Parameters

Set the Elastic Beanstalk Parameters

Keartida set the key ID and access key. After that she selected the US West 2 data center, the environment and application names, and the S3 bucket. She retrieved the S3 bucket name by navigating into the S3 service and finding the name on the management console as shown.

S3 Buckets

S3 Buckets

Once all the parameters were entered Keartida then clicked on create and CodeShip then shows the settings saved as shown below.

Saved Settings

Saved Settings

After that Keartida created the production branch and pushed it to github. There the build started as shown and began the deploy to AWS Elastic Beanstalk.

Beanstalk Deploy starts after the build

Beanstalk Deploy starts after the build

Finally once the deployment is detected to have successfully been pushed out and launched in AWS Elastic Beanstalk a message will appear and the build will go green.

Deployment Successful!

Deployment Successful!

Now, after Keartida completed this it’s time to really dive into the workflow of development. Next up, we’ll get a basic site and API services up and running.

Progressive .NET Tutorials 2015

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.

echo "Compiling F#" + $1
fsharpc "$1.fs"
mono "$1.exe"
echo "Running Executable" + $1

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).

export PATH="$PATH:~/Codez/scripts"

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.

fs theFileNameGoesHere

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, but I’m not going down that route right now)
  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.

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

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.

git clone https://github.com/mono/mono
cd mono
./autogen.sh --prefix=/mono64 --enable-nls=no
make
sudo make install

Now clone fsharp, build and install it.

git clone https://github.com/fsharp/fsharp
cd fsharp
./autogen.sh --prefix=/mono64
make
sudo make install

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

vi /etc/paths

Add the following paths to the paths file.

/mono64/bin/mono
/mono64/bin

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

cd tests/fsharp/core
./run-all.sh

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…

let x = 5;;

Then let y to a value…

let y = 20;;

Then enter…

y + x;;

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

#quit;;

The overall repl should come out looking like this.

> let x = 5;;

val x : int = 5

> let y = 20;;

val y : int = 20

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

- Exit...

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.

open System

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

Now run the compiler ‘fsharpc’.

fsharpc process.fs

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.

mono process.exe

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.

curl -O ftp://mama.indstate.edu/linux/tree/tree-1.7.0.tgz

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.

# 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

Now get a good build of the command file.

./configure
make

Now let’s get tree into the executable path.

sudo mkdir -p /usr/local/bin
sudo cp tree /usr/local/bin/tree

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

export PATH="/usr/local/bin:$PATH"

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.

brew install tree

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.

tree > prof-tree.md

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

.
├── 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

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.

Computer Repair Shit Storm

Notes From the Front: 5 Minutes With Visual Studio #Code

Ok, so Microsoft released a Visual Studio version on Linux and OS-X called Visual Studio Code. It’s also available for Windows but it’s so minimalistic compared to Visual Studio one might not want to use it on Windows.

Getting Setup on Ubuntu

Getting Setup on Ubuntu

There is however potential for this new IDE that Microsoft has released. It’s minimal and super fast at this point. On OS-X you can set it to launch as many of us OS-X users use Sublime (or your favorite editor here) to open entire projects.

Starting

Add this to the end of your bash startup script and you’ll have the magic sauce available via the command line.

code () {
    if [[ $# = 0 ]]
    then
        open -a "Visual Studio Code"
    else
        [[ $1 = /* ]] && F="$1" || F="$PWD/${1#./}"
        open -a "Visual Studio Code" --args "$F"
    fi
}

You’ll then be able to open projects with the standard command notation as shown.

✔ ~/Codez/React-Studies [master|…9]
16:28 $ code .

That pulls up a project in the editor just like this.

Visual Studio Code in Action

Visual Studio Code in Action

From there, just do what ya do and sling some code. There’s other features that are detailed on the Visual Studio Code site, but I’ll let you read up on those there.

Git Integration

The next thing I thought was pretty cool was the git integration, if for any reason because it just kind of looks nice. Nothing revolutionary here, but it’s nice to easily see without diving out to the bash to see what’s up.

Git Integration

Git Integration

…and the commit screen…

Committing and Commit Messages

Committing and Commit Messages

Now mind you, you can commit but not attach to any remotes and actually work with those. That’s kind of… disconnected? It’s fine though, whatever.

Quick Summary

So that’s my 5 minutes review. My main takeaway from all of this though, is that Visual Studio Code is not ready for prime time usage. It’s sorely missing a ton of features or capabilities that other editors, like Sublime or Atom, already have. I’m sure in the coming versions there will be more features and capabilities added, but currently I’ll be sticking to my WebStorm, Atom, Sublime, or Brackets usage for development needs still. For existing or future C#/F# Development I’ll just be using Xamarin’s tools most likely or diving into a Windows VM with full fledged Visual Studio. Until the future, I’ll just have to keep an eye on Visual Studio Code.