Introducing the TypeScript Cookbook

Do you use TypeScript? Ever wanted to know how to get the return type of a function? How about rolling your own nameof operator?

I've started a GitBook I'm calling TypeScript Cookbook. It's a place for all of my favorite TypeScript recipes, from real-world best practices to esoteric tricks I've picked up along the way. Hot, fresh and guaranteed to please!

It's still very much a work in progress, so please feel free to check it out early and often!

By the way, I'm looking for contributors! If you have any awesome TypeScript recipes to share, please get on GitBook and contribute! The book is fully open source!

Click here and check it out!

Reviewing GitPitch and Spectacle, two presentation solutions for developers

GitPitch is a recent discovery of mine. For someone used to writing code in PowerPoint/Keynote, it's very nice - write your slides in Markdown, post to GitHub, and GitPitch will construct a nice looking presentation for you, hosted on their website. The only steps involved are: add a file called PITCHME.md to your GitHub repo, point GitPitch to it, and off you go.

I found GitPitch to be appealing as I rarely do code demos except in very controlled circumstances, so my slides are extremely code-heavy. I don't know if you know this, but writing code directly in PowerPoint or Keynote sucks. Everything wants to help you with autocorrect or by formatting my punctuation. Plus I have to do all code highlighting myself, and I think proper code highlighting is essential to getting your point across when you're presenting any kind of code.

I did a talk at Chicago Code Camp on TypeScript's type system. I had written an outline for it before my trip and planned to write the slides on the train ride up. Originally, I was going to use Ken Wheeler's Spectacle, but I gave GitPitch a shot since I already knew Markdown and had a lot of slides to write. (You can see the final result here - the repo with the presentation markdown is here.)

Without further ado, here's my brief review on both.

Re: GitPitch only

  • GitPitch supports embedding code blocks in either Markdown code blocks or Gists. I opted for code blocks as Gists will not show up if your presentation is offline (did I mention you can export your presentation and run it offline? This is a critical feature for me as I never count on conference Internet working right.)

  • Speaking of code - it uses Github Flavored Markdown so you get syntax highlighting for free. This was another critical feature for me as my code has to look like it's in an IDE. Something something suspension of disbelief.

  • You can add your own styles to GitPitch, which ended up being critical for me. I don't think the margin on the code blocks is enough (text is not separated from the body enough IMO) and I didn't like the fact that it did full-caps on code lines created by backticks (e.g. this), so I tweaked those and was happy with the final result.

  • GitPitch caches the presentation on the master branch for 180 seconds. For feature branches, it's 20 seconds. I knew that it was probably cached (this makes sense) but at first it was pretty confusing when I was making changes and they weren't reflecting. Lesson: RTFM.

Re: GitPitch vs Spectacle

  • Spectacle is written in React, so you have to know at least something about React to use it. GitPitch uses Markdown, which means it has a very small learning curve (comparatively speaking).

  • Out of the box, Spectacle makes very nice looking slides with lots of options to tweak them. If I wanted to deeply customize my slides, I'd go with Spectacle hands down. There's no comparing a full view framework (React) with Markdown. However, what you get out of the box with GitPitch is nice too.

  • In Spectacle, code has to be in a separate file or inline inside of your HTML attribute, e.g. code="var yourCode = 'here'". I liked doing it inline inside of the Markdown personally - it's just one less step.

  • Spectacle threw errors when I set my code formatting to TypeScript. I don't think the highlighter (prism.js) supported TypeScript at that version, so I updated it... but it still didn't work. I could have used JavaScript code highlighting, but with something like TypeScript with lots of different syntax, I wanted to make sure everything that should be highlighted was highlighted. Ultimately, this and a couple of other small issues prevented me from using Spectacle for my TypeScript presentation. I wanted to write slides, not debug a web app. This was more of a timing choice than anything - it's what I get for waiting to construct my deck at the last minute. :)

  • Spectacle features a presenter mode that shows you the time plus what your next slide will be. I couldn't find a presenter mode for GitPitch. Needless to say, this feature would be invaluable. UPDATE: GitPitch released a presenter mode on the same day as my presentation... might be why I missed it.

  • This extension for Spectacle is the number 1 reason I would use it. You simply can't do this in Markdown. Stepping thru code line-by-line without using an IDE is just... well take a look at the result for yourself. It's awesome. Shoutout to James Kyle for an excellent plugin.

Stepping through code using Spectacle

  • Because GitPitch uses Markdown + GitHub, the slides are a lot easier for others to download and mess around with. I don't know how important this is, but the fact that I don't need someone to run an entire web app to see my slides is kind of nice.

  • Nitpicky, but I wish GitPitch would change the URL based on what slide I'm on. With GitPitch, you have to define custom navigation points to go to different slides. Spectacle just does this out of the box.

Bottom line

Would I use GitPitch again? Definitely.
Would I use Spectacle ever? Definitely.
Will I ever use PowerPoint/Keynote again? Probably not.

Both are awesome presentation choices that solve similar problems. I personally will probably use GitPitch more frequently for not-code-heavy presentations - it's very easy to make really nice looking presentations. That said, I will likely convert my TypeScript types talk to Spectacle for that awesome stepping-thru-code thing when I give that talk again at Detroit.Code() and Kansas City Developer Conference.

Emojis and String.Length

Are you using String.Length to compute the length of a string that might include emojis?

If you compute String.Length for such a string, you may not get back exactly what you expect:

This will write 12 to the screen. What were YOU expecting?

String.Length with emojis will not do what you expect

This happens because C# strings are UTF-16 by default and Unicode characters that fall outside of these 16-bit lengths are stored as surrogate pairs, or two chars that represent one 32-bit character.

However, you may be wanting the number of Unicode characters, not the actual length of the char array, in which case you should use System.Globalization.StringInfo to compute the length of your strings. Like so:

This will yield what you're looking for:

StringInfo will give you the actual number of characters in a string

Want more reading? Check out Joel Spolsky's very excellent article on strings and encoding. Remember, there is NO such thing as plain text!

on React, Angular 2, ReactJS

VIDEO - Discussing React and Angular 2 with Adam Morgan

TL;DR: I've gotten really excited about React as a web framework since starting with Angular and then Angular 2. The combination of JSX + easy-to-understand component model have made React a winner to me.

I've been tweeting a lot recently about React recently. After doing a lot of Angular 2 work for the majority of 2016 including a successful workshop at a few conferences, I started learning React early this year and was instantly hooked. A friend of mine wanted me to show him what all the excitement was about, and, well:

...which caught the attention of a Twitter friend of mine, Adam Morgan. He asked to see a repo - I said, let's do one better and make a video, which you can find here:

In the video, I walk through the three things that really make React stand out to me over Angular 2, with questions and commentary from Adam. The long and the short of it:

  1. JSX is awesome. As Cory House wrote: "it’s more logical to enhance JavaScript to support markup than to enhance HTML to support logic." Plus, compile time checking of your views makes writing components a much easier process.
  2. It's just JavaScript. No need to learn any framework-specific DSLs like with Angular/Angular 2/Aurelia/etc. You only need to know JavaScript and HTML to write React apps.
  3. Low API surface and learning curve. Fewer moving parts means it's easier to understand and become productive with quickly.

Here are some of the resources I've used to get started.

Building Applications with React and Redux using ES6 - Pluralsight course by Cory House
Presentational vs Container components by Dan Abramov Getting Started with Redux - course by Dan Abramov, creator of Redux
React Slingshot - React starter kit by Cory House
ASP.NET Core SPA Generator/Starter Kits, which includes templates for React and React with Redux.

International speaker achievement unlocked + Quick note on NDC

It was a huge moment of pride in October when I received my Microsoft MVP award. It was as big a moment when I got my acceptance to NDC London to speak on RESTful APIs using ASP.NET ten days later.

I'm thrilled and grateful that another one of my talks was picked up for the 10th NDC Oslo - this time on a maintainable RESTful API architecture using ASP.NET Core. It's really the sequel to the talk I gave at NDC and several other conferences/user groups last year. I'm moving beyond the theoretical and diving into implementation of a API architecture that I think is maintainable for the life of your API.

I wanted to take a moment and thank NDC for giving me a chance to present at not only one but two conferences this year. As far as conferences go, NDC has the whole package - they have a content lineup that is unrivaled and go out of their way to make their attendees and speakers feel loved.

I'm told that NDC takes chances on newer speakers. For taking a chance on this new speaker from my little corner of the Midwest, I'm very grateful. You've created an eternally loyal speaker in me.

This is going to be an exciting year.