I give pretty many presentations about things an aspiring developer might want to know - how to spin up a Node.js service, how to get web sockets firing, how to do some duck typing in JavaScript - you know, fun stuff.

Before I give a presentation, especially a bigger one, I open OneNote and have a glance at my Show Time Checklist to make sure I’m running on a well-oiled machine and have given myself the best chance at a snag free show.

Here’s my list in case it improves your life in some way…

1. **Restart. **There’s nothing quite like a system restart. It’s the first thing I tell my grandma to do when things don’t work. What’s that, Grandma? You forgot your email password? Let’s go ahead and find that power button. I put a sticky note with an arrow on it last time I was visiting and you made me brownies.
2. Open IDE’s I’m usually using some combination of Visual Studio, Notepad++, and the browser (I <3 CodePen.io) to write code. There’s a delay opening VS or N++, so I get those warmed up before I start.
3. Uninstall previous trials. Sometimes I actually practice my presentation before show time… sometimes, and it’s always awkward when I have to create SampleProject2 because SampleProject always exists. It makes it look like I need to practice or something.
4. Close all browser tabs. You know those tabs where you were looking up the answer to what you’re just about to teach others? Yep, close ‘em.
5. Close everything. Close all the windows that you’re not going to use in the presentation. It’s obvious, but this list is a tickler, so I don’t have to think too hard, so I include it.
6. Open emulators or simulators. They tend to take some time loading their OS the first time, so it’s good to have them open. If you’re showing an Android emulator, open it. It will still be slow, but anyway. :)
7. Close your chat app. You should have already closed your chat app at step 5 when you closed everything, but this guy gets his own line because he’s a special offender. It’s awkward when your wife emails you a question from the pharmacy during your presentation!
8. Get your emergency backup in your ALT + TAB. You should never show anything you don’t have a backup for. It’s a rule I break all the time, but that doesn’t make it any less of a good idea. If I’m showing how my brilliant code turns into a beautiful UI, I should be ready for it to turn into a brilliant mess and have a rendered PNG version at hand - you know, from when I practiced this.
9. Pin presentation folder to Windows Explorer taskbar icon. I have a folder for every presentation with slide decks, code projects, etc. inside. I like to drag a shortcut to my Windows Explorer taskbar icon for show time. I can access it quickly with WIN + ALT + 4, since 4 is the position of my Windows Explorer shortcut on my taskbar. Yours might be different.
10. Go to presentation mode. In Windows, hit your Windows key and type presentation. You should see Adjust settings before giving a presentation. That opens your Presentation Settings where you can tell Windows to suppress notifications globally. You can also turn off your screen saver, set the volume, and change your desktop background, all of which will be reverted when you are done presenting. Super handy. I’m not sure if MacOS has an equivalent.
11. **Honey and water. **My throat loves to sabotage my efforts to speak. I keep honey packs in my bag and down one just before a show. It simultaneously sooths and delights.
12. Take some breaths. Sounds trite, but this is a big one. The best thing you can do before a show is calm down. Make some small talk with the folks in the front row. If you don’t have something prepared at the last minute, is it really going to help to do it now? I doubt it.

And here’s the list without all of my banter in case you want to drag it over to your own Show Time Checklist in OneNote…

1. Restart
2. Open IDE’s
3. Uninstall previous trials
4. Close all browser tabs
5. Close everything
6. Open emulators or simulators
7. Close your chat app
8. Get your emergency backup in your ALT + TAB
9. Pin presentation folder to Windows Explorer taskbar icon
10. Go to presentation mode
11. Honey and water
12. Take some breaths

Feel free to drop a comment below if you have other ideas for how to prepare for the big hour.

I’m not setting out to explain recursion in full detail right now. I just want to do my best to relay the concept.

Recursion, in simple terms, is logic that depends on itself. I honestly can’t tell you whether it’s the simplest or the most complicated of concepts. It’s sort of both. Let me attempt to explain.

A typical programming function looks like this (in JavaScript)…

function f(a,b) {
  return a+b;
}

It receives some things (a and b) and it returns something (the sum of those). It starts when it is called and it ends when it returns. It’s as simple as that.

But a recursive function is one that calls itself. What?! It’s a little weird. Let’s try this…

f(1,1);

function f(a,b) {
  return f(a,b); //the function calls itself!
}

//stack overflow!

Now, technically this is a recursive function, because it’s calling itself. But it’s not a very good one.

What’s wrong?

Can you tell what’s going to happen? It’s fun. It’s called a stack overflow. That is, when we call the function and it calls itself, that causes it to call itself, which causes it to call itself, which causes it to call itself, lather, rinse, repeat. Eventually (rather quickly actually) our system runs out of memory to hold this infinite stack of function calls and it throws an exception.

So, we successfully created a recursive function, but we didn’t limit it in any way. It’s like when you get a microphone too close to a speaker and it forms a feedback loop. Or it’s like when you plug a video camera into a TV and then point it at the TV. Or when you look in parallel mirrors just right. In every case, a somewhat perfect case is fulfilled. The output becomes the input… exactly as it is every iteration. The amplification continues, and you get strange and very extreme results.

Let’s change our function a bit so that instead of adding two numbers together, it simply takes a single number and then continues adding that number to itself minus one until it runs out of numbers (gets to zero). So you should be able to see that we now have a limiting case until we run out of numbers. That’s important.

f(17);

function f(n){
  return (n - 1 > 0 ? n + f(n-1) : n);
}

//153

Notice that the condition inside the function is asking if we reduce n by 1, is that still going to be bigger than zero?, and if it’s not (if n is 1 and thus n - 1 is zero) then we just return n. We don’t call ourselves again. That’s the critical piece. In order to avoid a stack overflow, there has to be some logic in your function that at some point allows the function to complete without calling itself again.

So, recursion obviously works great for finite mathematical operations like my example, but where else might you find this concept in the wild? The answer is all over the place. As it turns out, there are quite a lot of use cases. If you have ever worked with a folder structure or perhaps with a tree view control, you’ve likely discovered that recursion can turn hundreds of lines of code into a handful. Any data structure that contains an entity that can be involved as either the parent or child in relationships is inherently recursive. After all, who knows how deep the tree is? Who knows how many levels deep the relationships go?

I hope this helps you wrap your head around the concept of recursion. It’s a foundational one and mastering it gets you one step closer to being a computer scientist.

Have you noticed the overlap between WCF and Web API? I did.

And not only have I noticed it, but I’ve watched both of the frameworks change so that the overlap between them evolved, and I’ve done my fair share of speculating about what the potential paths forward are and when to use which.

Overall, the story with WCF and Web API is a convergent and not a divergent one. The teams at Microsoft are completely unified and so is the strategy. Nevertheless, the two frameworks exist as does the overlap and developers’ various solutions using one, the other, or some combination, so a little discussion on the matter might be helpful. A smidgen of official guidance on the subject is available from Microsoft’s developer network in an article called WCF and ASP.NET Web API, but it is by no means wordy and leaves a lot of architectural concepts and decisions to you, the developer.

I’ll try to be more specific and prosaic on the matter, but I won’t obviously be able to make any decisions for you, especially where existing solutions are already in place. I can, however, let you know a bit more about where Microsoft is on the matter and where I am as well and you can use your own noodle and your own intimate knowledge of your problem space to make the best decision. After all, that’s what they pay you for, right?

After reading this brilliant discourse on the topic, I highly suggest you take the time to watch Daniel Roth at TechEd North America 2013 present Serious Web Services. You’ll walk away from that an expert.

Guidance… Choose Web API (if you can)

Here’s where I advise you start - if you can choose Web API, choose it. You can choose Web API if the following are true for you…

• You can stick to the HTTP protocol. HTTP is a layer above TCP. That means that is uses TCP, but it adds some stuff. In adding some stuff it makes the communication just a tiny bit slower. Here’s a typical envelope for an HTTP request…

GET /mypath/myendpoint HTTP/1.0
From: [someuser@mydomain.com](mailto:someuser@mydomain.com)
User-Agent: HTTPTool/1.0

…and for a response…

HTTP/1.0 200 OK
Date: Tue, 23 Sept 2014 23:00:00 GMT
Content-Type: text/plain
Content-Length: 21

{response:'hi there'}

The round trip in total is not that large, but if you’re talking about 10’s of thousands of messages then it might become a consideration. Using HTTP messaging is hugely convenient in a number of ways - not the least of which is the practically instant compatibility with a lot of client systems. Everyone these days speaks HTTP with a wide variety of helper classes out there. If you’re in JavaScript you have jQuery’s ajax(), WinJS’s xhr(), and likely about a billion more. If you’re in C# you have the HttpClient helper class. Even if you don’t have any helpers, composing a text message like the sample above wouldn’t be rocket science (unless of course you’re in the aerospace industry).

WCF can speak HTTP, but it can speak a number of other protocols as well. The cool part is that all of the work you do to define your entities and your operations is independent of the transport protocol too. That means you can talk HTTP to some clients and straight TCP to others. That’s a big advantage.

If you know, however, that you can get away with only talking HTTP, then read on and keep on considering Web API.

• You don’t have a requirement to support SOAP. HTTP is an envelope on TCP. SOAP (Simple Object Access Protocol) is another envelope on that - on top of HTTP. And it’s a significant one too. Look at this SOAP message. Yowzer! And this is the best case scenario. Actual implementations usually end up with a lot more piled on top.

POST /mypath/myservice.asmx HTTP/1.1
Host: api.mydomain.com
Content-Type: text/xml; charset=utf-8
Content-Length: **length**
SOAPAction: [http://mydomain.com/MyAction](http://mydomain.com/MyAction)
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <MyAction xmlns="http://domain.com/">
      <GUID>string</GUID>
      <content>string</content>
      <paramsXML>string</paramsXML>
    </MyAction>
  </soap:Body>
</soap:Envelope>

As you may spot immediately, SOAP is XML, so besides its inherent, relative verbosity, it is also subject to the verbosity of XML. When you have to <thing> wrap all the things </thing>, they start to get pretty long, n’est pas? SOAP is the foundation of the WS* stack - a suite of standards to determine one way to implement web services. The problem is the WS* stack is pretty thorough and pretty pervasive in the enterprise. So if you’re an enterprise developer trying to introduce some agility to your group, you may run up against the constraint of having to speak SOAP.

• *You don’t need Reliable Messaging, WS-Transactions, or any of the other WS junk. **Web API implements web services using a variety of primitive and largely preexisting protocols such as HTTP, WebSockets, and SSL, so you don’t get the various higher level protocols such as RM or WS-Transaction. You don’t get the power of those protocols, but you also avoid the headache in my opinion. I have always felt the process of implementing such protocols was relegated either to suspicious black magic libraries or pain staking implementation ceremony.

There may be more, but those are the basic constraints I can come up with on a moment’s notice.

OData

It seems like everyone is talking about the raw and simple HTTP REST JSON approach, and that’s great, but there are a couple of other approaches to consider. One of them is a shaking of even the HTTP protocol. You can accomplish that by embracing web sockets. You can implement an entire API using Signal R and it would surely be very fast and very impressive. Another alternative is to keep the HTTP envelope but get more specific with your data format specification by embracing OData. A client can look at any OData set of data with standard tools or code because they’re always formatted the same. Additionally, OData allows me to query my data with clever URL strings so I only get back the data I want. OData is nifty. Here’s a simple HTTP request to an OData resource…

GET /mypath/widgets?$filter=name eq Widget1&$select=id HTTP/1.0

This is a simple GET to an OData resource (a collection of widgets it appears) that will take only the id column of the widget with the name “Widget1”. So that is going to return a microscopic result that looks something like…

{"id":17}

I used to consider it a strong advantage of WCF that I was able to create a WCF Data Service (a simple class inheritance), point it to a compliant data service (such as an EF DbObjectContext), and presto I had a full OData implementation of my dataset. It’s a great party trick (depending on the party), but Web API has matured to the point where the same solution (a very useful OData feed from a dataset) takes hardly any more effort and has the added advantage that it uses scaffolding so my service implementation is not hidden behind the façade of the WCF DataService class. Additionally, (and of critical importance) the WCF team has put some guidance out there that WCF Data Services is not the way forward. They’ve done a commendable job of implementing the basics of OData v4 to alleviate as many workplace constraints as possible, and I’m hearing, guessing, and hoping that they’ll do an equally commendable job of supporting existing namespaces and implementations, but it’s a sunset moment for WCF-DS.

That’s all I have on the subject for now, but feel free to engage me and the community via comments below.

Thanks to the following sites for info and inspiration…

http://www.dotnet-tricks.com/Tutorial/webapi/JI2X050413-Difference-between-WCF-and-Web-API-and-WCF-REST-and-Web-Service.html

http://en.wikipedia.org/wiki/SOAP

http://en.wikipedia.org/wiki/Web_services_protocol_stack

http://en.wikipedia.org/wiki/WS-Transaction

Based on two laps around the exhibitor hall at OSCON and a couple of years working in the sometimes awkward space between marketing folks and developer folks, following is my list of the 10 most overused words in tech.

You’ll find these on a zillion websites, banners, and those spring up signs that people drag around in the airport. There’s probably a name for those, but I’m glad not to know what it is. If you know, don’t tell me.

It’s all an attempt to make an API or a service that has no material substance come to shape and life in the mind of a developer so that he’ll use it and love it and maybe make some contributions to the repo or pay some money for it.

And here they are…

1. ninja. I have no idea how this expert in stealth, martial arts, and throwing stars came to represent the height of developer prowess, but it has… even though most developers wouldn’t be caught dead in black uni-suits or toe socks, and likely would be caught dead if they tried sneaking into the enemy’s lair under the cover of night.
2. awesome. The term that attempts to capture that moment when a mortal lays eyes on a select sunset, a view of the milky way, or the power of God himself is reduced to describe the experience of successfully requesting a client record and retrieving his sales history.
3. guru. One who knows everything about a religion becomes one who knows everything about his programming language.
4. leverage. Sometimes the word use would work just fine, but for some reason we’re still compelled to leverage things.
5. cloud. A list of clichés would not be complete without cloud. Never has a term risen so high so quickly. Hey, that sort of works! Do keep in mind that your cloud is actually on the ground. I’m just saying.
6. stack. A choice of collaborating technologies building on top of one another. A stack. Got it. Yep, that describes it.
7. bits. You’ve never seen a bit, but you talk about them all the time. Is that in the latest bits? Do you have access to the latest bits.
8. mind blowing. Sometimes it does feel like that, but not often. I can recall on fewer fingers than has one hand the number of technologies that have felt like they blew my mind. And even then my mind remained literally unblown.
9. real time. Even though most of the time it’s not true, it’s fun to say that your software runs in real time. The more honest claim near real time performance. What’s near? Within the hour?
10. bacon. And making the list due entirely to the fact that I saw it used an entire 3 times in one exhibit hall… bacon. I love bacon for breakfast. Heck, I love bacon for lunch and dinner and dessert too. It feels like a cheap shot though to compare your API to bacon so I’ll love it. I’m still going to use your API though… since you said bacon. I do love bacon.

codeShow is a app for learning to make apps. It’s very meta in that way. The whole project is an open source project with community contributions. Use it to learn the web platform and Windows app development.

You can download the app by visiting aka.ms/codeshowapp and you can find the source code at codeshow.codeplex.com.

codefoster.com is entirely overhauled and with it my provider for blog commenting functionality.

I chose DISQUS and I’m pretty happy with it so far. It was very easy to plug in and gives me the basic commenting functionality that I’d like. I like the fact that many web users have used the system before and are already authenticated. I also like that comment threads can be tied to the page URL and are not tied into the content management software.

In an attempt to engage you, my readers, I’d like to offer an Oakley backpack like the one pictured below except it’s branded with the new Microsoft logo in gray.

To enter, either leave a comment below with your answer to the following question: What are the most important 3 items to carry in your day pack and have at the ready? or leave a comment on any other blog post on codefoster.com.

Unfortunately, I can only ship to the U.S., but if you’re overseas I’d still love to hear your answer.

I’ll pick a random winner this Friday the 25th and announce it in a comment and on Twitter.

I’m starting a new venture and I’m announcing it now.

It’s been on my mind for some time and I’m finally going to make it happen.

It’s called CodeChat and it’s a casual, weekly conversation about code and the myriad of periphery topics that may be of interest to developers. Chats will be targeted at 30 minutes, but who knows. They may be 15 minutes or 40.

The first episode will air on July 7, 2014 and new episodes will be released every Monday morning until the demise of the universe.

CodeChat will be broadcast via Channel 9 which will allow me to distribute it in various formats simultaneously. I, for one, listen to a lot of podcasts and never want to be limited to audio or video. If I’m driving or jogging, the video is pointless, but when I’m just sitting around it’s great to have a video feed for a more immersive experience.

I hope you’ll get some value out of the discussions I have with Microsoft employees, community developers, and whoever else I decide to bring on the show.

I’ll be interviewed at an upcoming online Microsoft Learning event. Join to get tips from experts on emerging opportunities for developers. The panel will include senior executives from Dice, PayScale, and the Center of Excellence for Information & Computing Technology for Bellevue College. Register now

Ugh… if I hear one more time about the death of the PC…

I don’t mind naysaying persay, although I try not to partake. It’s very popular to be negative. Complainers are a plenty. A person can do better though than to spend their time getting frustrated as a response.

I I tend to enjoy more talking about what’s good about this and that whether it’s born out of a tech giant or a tech startup. I don’t mind pointing out what’s great about the competition. Where would we be without competition?

But the death of the PC topic is annoying because it is carrying so much more momentum than sense, and I don’t like things that carry momentum and not sense.

Critics talk about the recent 14% decline in PC sales as if it’s the locked trend that will soon see us into a world where PCs don’t exist, and furthermore, they continue to attempt to tie the future of Microsoft to that number.

A couple of thoughts. First, 14% is not a linear trend to the demise of PCs. Second, Microsoft is decoupled.

To my first point, I think we are quickly headed into a world where PCs don’t exist… at least, PCs as we now know them. The big box you slide under your desk - going away. The laptop that confines you to a mouse and keyboard and requires a special backpack - goodbye. The PC is already experiencing an evolution swift enough to call a revolution. Watch this Intel commercial for example.

“That’s just dinosaur PCs taking their right place”

So what’s with the 14% decline? That’s just dinosaur PCs taking their right place. When my wife wanted to look up a recipe three years ago, she dragged her 75 pound Dell laptop out and looked it up. And it seemed great compared to trekking to the office to spin up a desktop. But today the dinosaur is simply not the right tool for the job. If we were contemplating a device purchase for looking up recipes, we would contribute to the 14% decline in sales by buying a tablet device that turns on faster, stows quicker, and can be held in one hand. And actually, that feature on the Surface where you can turn the page without getting brownie batter on the screen is pretty awesome too!

There are a lot more than 14% of the use cases that a tablet or a phone will do great, yet people are still using their dinosaur PCs for that. Why? Because they have them. Not everyone goes out and buys the latest gadget in its infancy. But they’re not going to spend money on a new 15” screen when all they need is 8. We know that.

So expect to see PC sales drop. They’ll take their right place, and consumers will be better off using technology that applies to the task at hand. But don’t bet the farm that PCs are going to dye, because I know a lot of people that would sooner cut steak with a butter knife than use a get real work done.

And to my second point. Microsoft is not a static entity and does not have its future tied to the dinosaur PCs. Some components of Microsoft’s business that I think you’d agree are significant mostly if not entirely immune - Azure, Office, Xbox. And even Windows has proved its agility.

Never underestimate the creative engine at Microsoft constantly innovating and pivoting to not only keep up with this higher tech world, but to lead where possible as well.

That’s all.

If you’re looking to take an exam and get MCSD certified, have I got a deal for you!

I’m going to give away 25 (that means you have a high chance of winning!) coupons that will get you two exams for the price of one.

Here’s what you do to qualify…

• Follow me on Twitter (http://www.twitter.com/codefoster)
• Retweet this tweet
• Cross your fingers

I’ll randomly draw 25 people out of everyone that qualifies and send them a code via email to redeem your prize.

The drawing will be Friday, Oct 25.