FAKE It Till You Make It

Chris Missal - 18 August, 2015. It was a Tuesday.

I’ve been studying build systems in .NET recently. I believe that automation is one of the most important pieces to any successful software project. Previously I wrote about Cake and how I liked the ease of use as well as how nice it was to contribute to the project. I mentioned in the comments of that post that I would be blogging about FAKE as well, and this post is that.

FAKE isn’t anything new. In fact, it’s been around for well over 5 years. Scott Hanselman had a really good post about it back in March of last year. If you’ve been keeping up, this will be nothing new, but for the readers that haven’t been following the activity, I hope my thoughts about it will be helpful to you.

Last week I presented at Headspring on this same topic with Patrick. Patrick is a fan of FAKE and I won’t speak for him, but I’m fairly certain he agrees with me in that I’d like to see more people and teams using it. There were two objectives to the presentation:

Introduce FAKE to those that aren’t familiar.
Convince people to give it a shot.

Now I can’t make you or my coworkers use it; that’s not the point. I just want to show you what you may be missing and let you choose your own build strategy from here on. I like FAKE and think it’s the best solution to the build and automation problem we face in .NET every day. I’d like to go over a few reasons why I think so. Before I do that, I’m going to talk about a few reasons why you shouldn’t use it.

Why You Shouldn’t be Using FAKE

You’re a Pro at PowerShell

You can whip together some PS code in no time. You never forget the equality operators, you even know the commands for file manipulation without having to Google them. That’s awesome and I wish I had the same skills as you. PowerShell is a very powerful language and can do a ton of amazing things! I don’t want to take anything away from PowerShell, but I don’t spend a lot of time in it. Because of this, I’m not nearly as efficient when writing it. If you have no problems with these things, this post might not be for you, sorry I can’t give you much to read about.

If, however, you have the same problems I have, maybe you should keep going.

You Don’t Want to Write F

The assumption that you need to be proficient in F# to use FAKE is a false one. I hear this often and I don’t know where it came from, and I can only easily assume why. The good thing about FAKE is that it doesn’t require a deep understanding of F#. It’s a DSL built on F# and writing FAKE is much different, I’ll say easier, than writing F#.

You’ve Adopted Gulp/Grunt

You might not want to give FAKE a try because you’re already invested in using JavaScript as your build language. I love JavaScript, don’t get me wrong, but these approaches require a bit more setup than your standard .NET build script. You need some extra dependencies that fall outside the default stack. (Yes, I realize that Gulp/Grunt tasks are now built in to Visual Studio. I’m not sure how I feel about this yet.) FAKE can be downloaded via NuGet, and you are off to the races. Sometimes a JavaScript dependency isn’t always ideal for a project because it’s possible that the only JS is in the build. You’re not really gaining anything at this point.

Why You Should be Using FAKE

It’s Best of Breed in .NET

There are several build tools out there, but through all the ones I’ve used, FAKE is winning. It has the biggest community around it, most built-in features (that I’m aware of), it’s still actively developed and maintained, and runs on Linux.

The Help is Fantastic

When you need assistance, there are a lot of options available: great documentation, terrific responses on GitHub, and even Google and Stackoverflow are helpful. Oh, and let’s not forget the entire F# community!

Faster and Easier

I’m still no veteran when it comes to writing FAKE scripts, but I can honestly say that it’s far more of an efficient use of my time than any other build tool I’ve used. With all the “Helpers” (over 100 in fact) there’s not much that you have to write on your own. You’re literally just putting building blocks together in the order and direction you want them.

A Sample Script

Anyway, on with the sample code! This tiny little snippet comes directly from the FAKE site, and I’ll leave it with you and let you browse on over there to check out more samples since that won’t get out of date as fast as this may.

#r "tools/FAKE/tools/FakeLib.dll" // include Fake lib
open Fake


Target "Test" (fun _ ->
    trace "Testing stuff..."
)

Target "Deploy" (fun _ ->
    trace "Heavy deploy action"
)

"Test"            // define the dependencies
   ==> "Deploy"

Run "Deploy"

Closing Thoughts

Like other FAKE fans, it’s one of those “why wasn’t I using this long ago?!” thoughts. I could keep going on, but I’ll let you check it out and form your own opinions. As somebody who doesn’t like to change things up too often, I’m VERY glad I’ve made the switch from PowerShell (in my case) to FAKE.

Top 3 Favorite Open Source Projects?

Chris Missal - 10 August, 2015. It was a Monday.

Tough question right?! Before getting into my list, some background:

Sindre Sorhus came up with an interesting use for GitHub. You can fork a repo, and nearly instantly have your own AMA page using issues. Simple concept, but lots of fun!

I decided to give this a go and received a really great question from Una Kravets.

I gave it a bit of thought and came up with four Top 3 lists. I’d like to share because I’m interested in what others think of this question:

What are You Top 3 Favorite Open Source Projects?

Feel free to share here or on my AMA question above as a comment. (Or just write your own blog post!) Anyway, here are mine right now:

My Favorite Projects to Work On

RoundhousE – I’ve been using RH for a long, long time and it has made my experience working with databases so much nicer! I recently started helping out with maintenance, while challenging, it’s still rewarding to see the project stay alive and healthy.
Quiche – This one might only be used by me, but I really like(d) building it and working on it.
Cake – This one is still new to me, but it’s been an absolute pleasure working on. Great group of contributors and excellent code/docs/etc.

The Projects I Most Enjoy Using

HuBot – My coworkers and I frequently add useful and goofy scripts for HuBot in our HipChat rooms. It’s a lovely API and super easy and fun to work with.
React – React has worked very well so far with the projects we build at work. I also really dig the opinions on how the framework should be used, it’s wonderful.
Atom – It didn’t take much use of Atom for it to replace all my other editors. I love the power that it gives me and the fact that it’s open source and wildly extensible.

Projects that Have Benefitted Me Most

AutoMapper – I’ve been using AutoMapper for years now and it’s made my life better by saving me thousands of unnecessary keystrokes.
Fixie – Fixie is the test framework I didn’t know I needed until I started using it on personal projects. I love having the control of testing my code the way I want to.
MediatR – A simple project that implements a simple pattern. Like the previous two, this gets out of the way and makes coding more productive and fun.

Projects That Have Helped Others

WebApiContrib – A few people got together and built a small library of useful patterns that have tons of downloads (for me anyway). I’m judging by download counts that this is a success. And that makes me happy!
Up-For-Grabs.net – I love spreading the OSS love and this site that my friend Keith built is perfect for it. I’m always looking for more ways to share!
Formo – This only makes the list because it’s the most popular project that I run by myself. I do like it and still use it so I have to put it in one of these lists.

If you decide to type up your own list(s) I’d love to read it!

Texas JavaScript 2015

Chris Missal - 27 July, 2015. It was a Monday.

Last week I was lucky enough to have a great JavaScript conference in my backyard. Another edition of Texas JavaScript (TXJS) was held in downtown Austin on Friday, July 24th.

I wanted to share some thoughts and notes from the talks.

The Scary Stuff

Check out Simon Swain’s Cold War! Do it now, it’s incredible
Yan told us about Let’s Encrypt, a new, free, automated, and open Certificate Authority
Jed’s talk on inline styles was thought provoking and very entertaining. Oh, he was defending them for what it’s worth.

UX & Performance

These talks were great, they all focused on people, not developers. It’s great to be reminded that what we do as developers is pointless if there’s nobody using what we build.

Michelle talked about building component libraries to be able to give users a consistent and comfortable feel (and providing that value faster)
Andy discussed the benefits and value of delivering faster web experiences with HTTP/2.
Alice showed us the troubles and successes of making web sites usable. And not just “nice”, but actually usable for all types of users from any background imaginable. Not everybody uses the web like you and I.

Framework Unshootout

Brian, Tom, and Pete got together back to back to back, and talked about how the Angular, Ember, and React teams are all actually on the same team (more or less). They’ve all ~~stolen~~ borrowed ideas from each other, and they’re all moving forward together, not in spite of one another.

The Once & Future Web

Future! Here we got schooled on how to use some new toys. Rushaine talked ES6, Mat “Wilto” convinced me that images are ruining the web and need to be fixed, and Jake told us, among many other progressive enhancements, how a network connection is something to be considered as a feature you might not have when building web apps.

Expand Your Mind

Our minds were expanded and partially blown by Jenna explaining the similarities between JavaScript and our brains’ language processing. If that was enough to melt your mind, David showed us the awesome ClojureScript compiler (I have a lot to learn here). Finally, Jenn schooled and entertained us with arrays. Trust me, it was great!

Awards

Best phone call: Alex & Pizza Delivery
Best wardrobe change under pressure: Alice Bartlett
Best Game: Cold War
Best Slide Images: Jenna for Adventure Time
Best JavaScript Conference in Austin: All the organizers and speakers, great job!

You can find the full stream of the event on YouTube

Photo credit @jaffathecake

Who Wants Cake?!

Chris Missal - 22 July, 2015. It was a Wednesday.

I’ve been learning and trying out new build systems in .NET recently and decided to give Cake a sample. (See what I did there?)

First Impressions

Right away I liked how the scripts look and feel. This is quite important to me and one of the reasons I dislike scripting things in Powershell. Powershell is more difficult for me to read and understand than I would like. I believe it’s largely due to the common coding styles, but that’s my problem.

Here’s a sample script:

var target = Argument("target", "Default");
var configuration = Argument("configuration", "Release");
var buildDir = Directory("./src/Example/bin") + Directory(configuration);

Task("Clean")
  .Does(() => {
    CleanDirectory(buildDir);
});

Task("Restore-NuGet-Packages")
  .IsDependentOn("Clean")
  .Does(() => {
    NuGetRestore("./src/Example.sln");
});

Task("Build")
  .IsDependentOn("Restore-NuGet-Packages")
  .Does(() => {
    MSBuild("./src/Example.sln", settings =>
      settings.SetConfiguration(configuration));
});

Task("Default")
  .IsDependentOn("Build");

RunTarget(target);

To me (and possibly because I write C# nearly every day) this is very readable and nice to look at.

Tools

There are loads of tools out of the box, but a couple more that I needed. I was able to get Fixie into the v0.5.0 release, so that was nice. The other is RoundhousE, which should be coming soon!

Contributing

Many Kudos to Patrik for maintaining a very clean and intuitive codebase! Everything is well thought out, in the right place, and easy to understand and follow. If you want to fix a bug or add a feature to this project, it won’t be hard. In fact, it will probably be a pleasure! Additionally, the issues on GitHub are a great place to ask questions, request features, or submit bugs. You’ll likely get a response from Patrik or somebody else the same day; as a maintainer of other open source projects, I wish I was that good.

All of these reasons make this a very nice project to work on if you’re looking to get more into open source. There are even some Up For Grabs Cake issues you could work on today!

Happy 10th Birthday Git!

Chris Missal - 7 April, 2015. It was a Tuesday.

If you read this blog, you’ve probably already heard that today marks the 10 year anniversary of Git’s first commit (of its own code). My buddy Ryan and I decided to build this really cool web site to celebrate, but ideas are easy and execution can be tough. We have a simple static that references the first commit:

http://gitbirthday.com

The fun feature we didn’t get around to adding was an interactive page to display the most recent commit, but always 10 years in the past. Even though we didn’t get around to completing that before the actual “10th birthday”, we decided to make the source open so anybody can give back to git with a pull request for neat features you have.

Also, thanks to Linus, Junio, and the rest of the contributors for giving us git!

Your Old Crappy Code

Chris Missal - 18 July, 2014. It was a Friday.

If you’re not new to software, you’ve probably come across some old code of yours and thought:

Oh snap! What is this? What was I thinking?

I’ve done it. My friends and colleagues have done. You’ve probably done it as well.

Recently some friends and former co-workers of mine reached out and asked if I’d like to help out part time doing some front-end work. I thought it might be fun to do some contract work on the side and even more fun to work with awesome people I haven’t worked with in about 2.5 years.

Last night, I came across some old JavaScript of mine, here were my reactions:

Nostalgia: Oh hey! I wrote this!
Shame: Wow, this isn’t very good. I can do much better now. How embarrassing to think that I once thought this was production worthy.
Sleep: I actually went to sleep because it was late.
Pride: That code still works fine even though it’s not super pretty. Even better, since I wrote it over 5 years ago, by my calculations it’s been successfully executed over 7 billion times!

I woke up feeling much better about my “not perfect” code. It’s not about beauty, it’s about value. So next time you find that ugly, embarrassing code you wrote 1 year, 5 years, or even further back in time. If it’s still in production and providing value, take some pride in it!

Recruiting and Being Recruited

Chris Missal - 1 July, 2014. It was a Tuesday.

We all know that the software industry is in dire need of more developers. This means that there is also a huge market in finding and hiring those people for companies. Whether it’s an internal team, or an agency, here are my personal tips and tricks for doing it the right way from both sides.

Recruiting

Always send a personal email when you can. Anything that’s copy and paste is likely going to show and be ignored by most developers I’ve talked to.

When sending that email, actually take an interest in the person you’re going after. If you talk to me about my projects on GitHub or blog posts that I’ve written, I’ll be impressed. It’s what I do for fun and what motivates me. If you can tie that back to a reason why you’re interested in me, I might start to listen.

Don’t call me. I don’t like to talk on the phone, it’s wasted time in my opinion because there isn’t a whole lot you can do when you’re on the phone. Also, if it’s during the day and I’m at work, I’m probably not going to give you much attention because I don’t want all my co-workers to know that there’s a chance I might be leaving for another place.

If my name was given to you by a developer that you know, see if they’ll reach out to me instead of you. No offense, but I’d rather hear about a place from somebody that’s doing what I’ll be doing.

Being Recruited

Don’t be a jerk. These people are just doing their jobs, the alternative is that you never get contacted and that could mean a variety of things, including the fact that you might not be too desirable as a developer. Not all messages are going to be genuine, but it’s clear that some can be taken as a compliment.

If you get a call and don’t like phone calls (like me), add that phone number to a contact on your phone named Recruiter. You won’t have to worry about answering another call you may not be interested in, or if you are, it gives you time to walk somewhere private so you are free to chat without broadcasting to your peers that you’re spending time on the phone with recruiters.

Feel free to ignore the copy/paste emails. If it’s not sent to you personally, it’s probably alright not to respond personally.

Respond to the personal ones. I’ve found that even things as simple as “Thanks, but I’m not looking at the moment.” go a long way. You might be a great developer, but nobody wants to work with a jerk. If you curse and yell back, you’re just telling them that you’re difficult to work with and probably not a very nice or polite person.

Don’t be jerk. I don’t know why I have to repeat this. Doesn’t this advice just go with being a person? I get several people per week reaching out to me. I assume largely because I’m not terrible at what I do and I spend a lot of time out in the open online. Maybe you get so many that you can’t respond to them all, I’d love to hear your thoughts on the topic.

Thoughts?

These are just my thoughts; we all have different experiences and different opinions, but I’d love to hear how others feel on this topic.

My Pablo’s Fiesta Experience

Chris Missal - 29 October, 2013. It was a Tuesday.

My Pablo’s Fiesta Experience

In case you missed it, Pablo’s Fiesta was this past weekend. As usual, it was great! In addition to meeting smart new people and seeing tons of old friends, I also learned a thing or two at Pablo’s Fiesta over the weekend:

The sessions I attended

Side Projects – Lots of good notes and advice here in this one. Click through to see some bullets on what we talked about.
NuGet at Work – A general discussion of how people are using NuGet, some pros/cons, etc.
GitHub AMA – An excellent peek inside GitHub convened by @halfogre.
Developing Developers – How can managers and leads help build up their teams and get them more passionate about their craft?
Continuous Integration Discussion – An open discussion of what people are currently using for continuous integration, continuous deployment, and database deployments.
Ripple – This sounds like something I need to try on my next project. It’s NuGet, but seems to be less messy and brittle.
Fixie – The demo and discussion of Fixie was great! Patrick and the room came up with lots of good questions, feature suggestions, and ideas on how to make it even more kickass!

New things I need to check out

Bender – XML and JSON serialization/deserialization. For when you need something lightweight and fast.
NuDoq – Documentation pulled from NuGet packages!
FubuTransportation – Low friction Service Bus using the best of the Fubu world
Karma – Spectacular Test Runner for JavaScript

10 Uses for Realtime Web Technologies

Chris Missal - 3 September, 2013. It was a Tuesday.

By: Brad Carleton

So far, this series on Building Realtime HTML5 Apps has been fairly abstract/technical, which is great for my inner nerd. But for this final article, I wanted to focus on real life uses for realtime web technologies. Hopefully, this will give you some interesting ideas for your next side-project or startup idea. Also, if you want to checkout the previous articles, here’s the list:

On to the list of 10 uses for realtime web technologies:

1. Realtime web analytics

Google has already started pushing into this market with Google Analytics, but there are a lot of other startups exploring this space. If you think about it, there is a ton of opportunity there, as you have the ability to capture and transmit interactive user data like never before. You can track where the mouse floats across the screen, the orientation of a mobile device, and any number of other user interactions. Not only could you track them, but you could actually watch them as they happen!

2. Digital Advertising

The digital advertising world has long been a solid revenue generator for web-based businesses. With realtime web technologies, advertisers can move towards more interesting advertising paradigms, such as charging for ads based on the amount of time the ad is visible on a user’s screen or other realtime interaction metrics vs the CPM and CPC metrics that have long been the standard.

3. E-Commerce

E-commerce has always been a hotbed for engaging customers and customer interactions. Showing shoppers what other shoppers are looking at online, or pushing out online deals directly to all connected browsers are the types of realtime features that e-commerce platforms will look to adopt in the future.

4. Publishing

Keeping eyeballs on the screen is the primary goal on any online publisher, and one way to keep visitors on your site is to keep them engaged. Realtime data can lead to some very interesting infographics, and it can also help connect viewers like never before. A great example is some of the realtime comments like Disqus.

5. Massively Multiplayer Online Games

Those big MMO games are making there way on to the web, and they will surely find a friend in realtime web technologies. Many multiplayer games depend on low latency communications between individual gamers, and for this technologies like WebSockets are ideal.

6. Backend Services and Messaging

Our backend systems have grown in scale and complexity over the last decade, and it is becoming increasingly important to propagate messages across very large systems effectively and efficiently. The realtime web is going to be great for these types of functions.

7. Project Management & Collaboration

Google docs and other platforms have already demonstrated the value (and potential complexity) in implementing realtime collaborative environments on the Web. The new era of realtime web technologies will hopefully make the development of these types of applications simpler and easier to build. Which is great because most web applications are not built in a vacuum, so having the ability to connect all those users together in constructive and insightful ways should be able to add value their workflows.

8. Realtime Monitoring Services

The bi-directional communication channel is great for remote devices or servers to stay connected to a central monitoring service. This gives techs and admins the ability to watch what their endpoints are doing in realtime without logging into the machine, and also gives the ability to send realtime alerts.

9.Live Charting and Graphing

Charts and graphs have always been a great way to visualize data. Now you can have those graphs and charts connected to realtime data flows. The possibilities are literally endless, from displaying temperature data measured from a connected home device to streaming stock prices to realtime chart.

10. Group and Private Chat

Chat has long been the de-facto example for realtime since by it’s very nature it requires realtime bi-directional communication. Chat is a great use for realtime web technologies, and variations on group chats and private chats could lead to more innovation in this area over the coming years.

This is the last article in my series on Building Realtime HTML5 Apps. I hope that you were able to take away some key insights about this exciting new web technology. Please feel free to follow me on the twitter, and let me know about your adventures building realtime HTML5 apps!

Brad is a badass JavaScript coder who enjoys building cool stuff and long walks on the beach. As the Founder/CTO at TechPines, he has worked with large companies and startups to build cutting-edge applications based on HTML5 and Node.js. He is the creator of Bone.io, a realtime HTML5 framework, and is the author of Embracing Disruption: A Cloud Revolution Manifesto.

Realtime User Interface Design

Chris Missal - 20 August, 2013. It was a Tuesday.

By Brad Carleton

This is the third installment in a series on Building Realtime HTML5 Apps. Most of the thoughts and ideas from these articles stem from my experience building bone.io, a realtime javascript framework. The previous articles focused on Websockets vs AJAX and Single Page Apps & Realtime. This article will focus primarily on understanding Realtime User Interface Design as opposed to MVC for browser-based applications.

The Evolution of the Browser

As web applications have moved from the server to the browser, there have been a few important milestones in how we think about browser-based applications. Now obviously this evolution has been complex with many actors, organizations, and open source projects, but I’m going to try and condense it down a bit for clarity’s sake.

The first major advancement was the introduction of jQuery and other cross-browser DOM manipulation libraries. This allowed developers to program functionality into the browser with relative confidence that their code would work across the Web. A proliferation of plugins and other goodies soon popped up which made the Web a fertile playground for interactivity.

The next major advancement in front-end development was the MVC-based frameworks that were able to abstract DOM manipulation and data retrieval into a broader structure. This gave developers the opportunity to build larger more complex browser-based applications, and was brought about mainly by libraries such as Backbone and Angular.

As the HTML5 specification grows in features and complexity, what are the paradigms and philosophies that will help deliver the next generation of applications?

The Case against MVC in the Browser

I don’t believe that MVC is the best paradigm for understanding and structuring browser-based applications. The usefulness of the “Model” as a first class concept in the browser doesn’t make sense in many circumstances, especially when the data involved is transient in nature. If your main goal is to get “hot” data to the DOM, then the added abstraction layer of a “Model” often gets in the way of what you want to do.

For instance, let’s take a real life example, “Google” search.

Does the MVC architecture really describe this model of user interaction well?

If I had to break this “Google” search box into its separate concerns, here is how I would describe it:

[DOM Event]: A user interacts with the Search Box by Pressing Keys on the Keyboard
[Data Out]: When a Keyboard Interaction Occurs, contents of the Text Box are sent to the Server
[Data In]: Receive Search Results from the Server
[DOM Manipulation]: Render Search Results to the Search Results Box for the user to see

In this example, you don’t really “care” about the data for the Search Box, because the data itself is transient and volatile. You just care about rendering meaningful search results as fast as the user can type.

For this reason, I feel like the following diagram, the view.io pattern, provides a better framework for understanding the “Google” search box.

view.io

The “Google” search example can be generalized to be largely “data-agnostic”, maybe it’s a search for books, condos, web pages, whatever. “Modeling” the search results or the text box that generates them is largely irrelevant.

How we access Data, Drives how we build Applications

In a lot of ways, how we access data drives how we build our applications. For example:

A search box is most likely powered by a Search Backend (maybe Lucene or ElasticSearch)
A data table is likely powered by a SQL database (maybe MySql or Postgres)
An activity stream is likely powered by a NoSQL database (maybe Cassandra or Redis)

In all of these instances, a generic user interface component largely drives the selection of the underlying “database” technology. As long as the server can send data in a format that fits the “search box” model or the “data table” model, then it can easily be rendered onto the DOM.

Therefore, when working on realtime HTML5 applications, I believe it is a better approach to construct applications in terms of “data-agnostic” user interface components. Components that can be easily reused, regardless of the different types of data flowing through them.

I hope you enjoyed this article, and please read the next in the series on Building Realtime HTML5 Apps.