OWIN and Katana

I've been trying to learn more about OWIN and Katana so let me see if I can break it down here for you.

OWIN is Open Web Interface for .NET. It is a specification for how a web application interact with a web server. It creates an abstraction between web servers and framework components. On top of that it was designed to be simple and have few dependencies on other frameworks. What this allows is for new components to be more easily developed because you don't have a tight coupling to another framework. It also decouples your .Net web sites from IIS so you can run them on other servers/platforms or self host them.

OWIN uses the concept of a pipeline through which requests and responses are passed. OWIN components in the pipeline do something with the request and response and the result is sent back to the user.

Katana on the other hand is Microsoft's implementation of a set of OWIN components.These components include things from servers and hosts to components such as authentication and bindings to frameworks. It is designed to be composed of a number of small focused components that can be added in as needed. This makes your application more efficient because it doesn't have a bunch of things it doesn't need in the pipeline. These components are added via Nuget packages.

You'll often hear the term "middleware" when working with Katana. This is simply one of the logical layers of a Katana application. From bottom to top the layers are Host, Server, Middleware and Application. So as you can see middleware is in the middle between the host/server and your application. This is where the OWIN pipeline components that your application depends on live. These components are specified in your application's startup code. These components can be as simple as a request logger to as complex as the ASP.Net Web API framework.

If you want to get into more details I recommend reading this article.

GitHub

I recently created a sprite API library for TypeScript and decided that I wanted to make it open source. Maybe give myself some more programmer cred. Since GitHub seems to be the coolest place these days to put open source code I decided to try it out. Perhaps I was a bit naive, but I thought it would be pretty simple to do. I figured I would just go up to the website and upload a few files and voila, I'd have an open source repository. Boy was I wrong.

It was pretty easy to set up an account and create a new code repository. But then I couldn't find any way to add files to it. You can add new files, but you can't upload existing files from the web site. After much research I realized that you need to install Git (an open source version control system) on your computer and use that to manage the files.

GitHub actually has a GUI for Git that makes it easier to use. I installed it but it didn't work. The process would start but then die a few seconds later. So then I decided to go install Git directly and do it the old fashioned way. Git is primarily a command line tool, but it does have a simple GUI with it. That did work but it took a while to figure out how to fetch and commit and push files. It's a completely different process than I'm used to as we use Perforce where I work.

Finally, after many hours, I did get my code files up on GitHub and am getting the hang of it. But what I thought would take an hour at most turned into many hours and a lot of learning new things. I ended up putting up two repositories which you can find here: https://github.com/jodymgustafson?tab=repositories

Finding Good Programmers

Today I heard about a question that was asked at an interview for a programmer. It was something like if you had 25 horses and raced 5 at a time how many races would you have to run to find the order from best to worst. I don't know, but to me that sounds like the dumbest interview question ever. How does that tell you anything about the person's programming ability. It would tell you if they're good at solving esoteric riddles maybe. But tells you nothing about their programming skills.

It reminds me of an interview I had early in my career. They wanted me to take a 2 hour "quiz" where they gave me a couple dumb problems, like the one above, and I had to figure out how to program them. Not on a computer mind you, but with paper and pencil. I don't know about you, but I make a lot of changes as I program. Needless to say it didn't go so well.

Then there are the people who ask trick questions, usually about oddities in their programming language of choice. You know the ones I'm talking about. Maybe they give you a piece of code where you have to find the missing semicolon or something dumb like that.

So I started thinking: what is a good way then to tell if someone is a good programmer? Well, first you need to define what you mean by a good programmer. In the above cases they must think a good programmer is someone who can solve riddles very quickly. Or can program using the least number of  lines of code. Or is good at finding typos.

Now for my definition. Let's look at what a good programmer really does. I think most importantly they write code that is easy to read and understand. Their code is modular and efficient. Because they write code in this fashion it's relatively bug free and it's easy to modify. Good programmers are excellent at breaking down complex processes into simple, easy to understand chunks. They find a way to share common code rather than copy and paste it.

Now that you know my definition, how does one test for that? Here's my idea. Find the worst piece of code that you can. You know you have some. Maybe you didn't write it, but some guy that got fired 5 years ago did and no one will touch that code now. Or just go make up some bad code. I've seen enough bad code to know what it looks like. It's almost impossible to read; it's one huge method with 500 lines of code; it's verbose and inefficient; etc, etc.

Then sit the candidate down in front of a computer with the IDE you use and tell them to make it better. If they ask "better in what whay?" say "any way you want". Now see what they do. You can tell a lot just by watching someone work at programming. Some people do everything the slowest way possible (like copy and past using context menus). Unless they are applying for an entry level position this may indicate that they don't really care enough about getting things done quickly to learn some keyboard shortcuts. When I first started out I was absolutely amazed at how quickly the people that were my mentors could move code around. It didn't take me long to learn.

Watch what changes they make. Are they attempting to make the code more or less readable. Are they breaking things out into method calls to make the code easier to read and consolidating common code. Are they using variables to hold values that are computed multiple times. If you've been programming a while you get the drift of what I'm talking about.

Then when you're done with that, and they've done a good job, ask them to describe at a high level how they would implement something that you've implemented in the past. This will give you an idea of how good their architecting skills are. These are the kind of problems you should be asking someone to solve rather than a riddle that has nothing to do with the job.

These are the things that make someone a really good programmer. If you are interviewing people and you don't know how to assess these things then get one of your senior programmers to help you. There are a lot of people who are good BS-ers, but they can't BS their way through this.

What do you think? Am I completely whacked out or are these the kinds of things that programmers should be asked in an interview.

Life Without JQuery

There's been a lot of discussion lately about not needing to use any kind of library when writing JavaScript. Even JQuery. JQuery has been a staple in every app I've written since I first started writing JS apps four or five years ago. So I decided to give it a try and see if I could write an app without JQuery.

I've been working on building a library of classes in TypeScript to make it easier to work with HTML elements in my single page applications. So I set a goal of making this library not depend on any other external library, including JQuery. My other goal was that it would work for all browsers that support HTML5, including IE9. (One could argue either way that IE9 supports HTML5, at least minimally, and after this experience I'm starting to lean against.)

Things stated off pretty well. It's now very easy to do JQuery-like lookups to find elements in the DOM. I was feeling pretty confident that it was going to be easy to ditch JQuery. Then I ran into my first problem. I wanted to provide a method to get mouse event coordinates relative to the element they occurred in. You do this by getting the offset of the element on the page and subtracting that from the page coordinates of the mouse. It's easy to get the offset when you're using JQuery but not so much without it. I was able to figure it out with some help from the internet though and moved on.

From there everything was looking great. I actually went back and refactored one of my apps (Daylight Calculator) to use my library and chucked my reference to JQuery! It started to look like these guys were right. You might need to do a little extra work yourself but it is possible to write an app without JQuery.

Buoyed by my success I continued with developing my library without JQuery. I started working on a more complex application, one that did a lot of DOM manipulation and changing of CSS styles at runtime. Here's another area that JQuery excels at. When you start trying to do this stuff yourself you see that it's not so simple. There are new low-level things you have to know about like computed styles compared to declared. When you're using JQuery you don't have to care about any of that. It just works.

After figuring out the HTML element API I continued on my journey. And it was going great until I tested it in IE9. Then all of sudden everything broke. Seems that it's not that easy to change styles or classes in IE9 as it doesn't implement the standard HTML5 interfaces. Another problem I ran into was that IE9 actually changes the type attribute of an input element if it doesn't like it (e.g. "number" changes to "text") while I was depending on it not changing (other browsers only change it in the underlying API) . I was able to fix most these issues in my library as well with a little research. But at this point it's starting to look like a clone of JQuery!

So now I'm starting to think, "Why am I doing this again??" Should I just go back to depending on JQuery? Or should I just drop support for IE9 from my list of requirements? I really don't want to go back to using JQuery after all of the work I put into making it work without it. I would also like my library to work with IE9 but I don't have the time or desire to figure out all of these little quirks.

So are we ready to jump ship and say goodbye to JQuery? I guess it depends on the context. If you are doing really simple stuff in a modern browser, probably. If you are writing highly interactive single page apps with a lot of DOM manipulation maybe not, unless you like spending time figuring out how to make things work. Especially if you want to support older browsers. Although things are improving there are still some things JQuery does that we take for granted. Personally I like to spend my time writing apps and not worrying about low level stuff and nonsense.

Continuously Reactive Web Page

I recently created an HTML5 application that was a slide presentation, like PowerPoint. You might be asking, why not use PowerPoint then? Well, because my presentation was on HTML5 so I wanted to write it in HTML5 to show as an example. Plus I like writing HTML5 apps.

Anyway, one of the points of my presentation was that HTML5 apps can run on any device no matter what screen size. So I had to make it reactive so that it would look good whether viewed on desktop or phone. My first thought was to use CSS media queries which is the usual way to make reactive layouts. Unfortunately there were dead zones in my media queries where it just didn't look right. I had queries for a lot of different screen sizes but it wasn't enough. Also I wanted to maintain the correct width to height ratio no matter what the size.

Finally I came up with a pretty cool solution that didn't involve media queries. This solution uses JavaScript and font sizes in CSS. What I found is that if you set the font size of an element using EMs then all of the sizes specified using EMs below that will be relative to the parent's size. For example, say 1em is the same as 16 pixels (the default in most browsers). If I have a parent element and I set the font size of it to 2em then the text will be 32 pixels. Now if I set the font size of a child element to 2em what size will it be? No, not 32 pixels. It will actually show up on the page as 64 pixels. Why? Because the child's font size is multiplied by the parent's font size. So in this case 2em * 2em = 4em which is 4 * 16 = 64 pixels.

The fun doesn't end there. You can specify the size of anything in CSS using EMs, including elements. Those sizes will also be relative to the font size. So if I set an element's font size to 2em and the width to 20em then the size will be 2em * 20em = 40em which is 40 * 16 = 640 pixels. This fact allows us to easily create a continuously reactive layout in which no matter how large or small the screen size it will always look the same.

Here's how it's done. Let's say we have HTML that look something like this. The slide element will be the content element and the one that needs to resize when the browser size changes.

<body>

    <div class="wrapper">

        <div class="slide">

        </div>

    </div>

</body>

First we set the font size of the body to 16px just to make sure it's always the same in each browser.

body
{
    font: 16px Times, serif;

}

Then we use EMs to define the size of everything else, from element width and height to border sizes to margins. For example we set the size of our slide element using EMs.

.slide

{

    width: 40em;

    height: 30em;

    padding: 1em;

}

Then we can change the font size of the wrapper element to adjust the size of the slide element. By default the width of the slide is 40 * 16 = 640 pixels. The height is 30 * 16 = 480 pixels. Now if we change the wrapper element's font size to 2em then the width of the slide element is 2 * 40 * 16 = 1280 pixels. If we change it to 0.5em then the width is 0.5 * 40 * 16 = 320 pixels.

The tricky part is figuring out what font size to set the wrapper element to. That requires some JavaScript. In our JavaScript we need to get the default width, height and ratio of the slide element before we do any resizing. This gets the values in pixels.

var defaultWidth = $(".slide").width(),

    defaultHeight = $(".slide").height(),

    defaultRatio = defaultHeight / defaultWidth;

Next we need to add a window resize event handler. In there we will write the code that adjusts the wrapper element's font size.

$(window).resize(onResize);

And here is the onResize function.

function onResize()

{

    var fontSize = 0;

    if (window.innerWidth * defaultRatio > window.innerHeight)

    {

        fontSize = window.innerHeight / defaultHeight;

    }

    else

    {

        fontSize = window.innerWidth / defaultWidth;

    }

    $(".wrapper").css("font-size", fontSize + "em");

}

First thing we do is figure out if the browser window is taller or wider compared to the slide's ratio of with to height. If it's wider then we need to adjust the size depending on the height of the window. If it's higher then we adjust the size depending on the width of the window. Dividing by our default slide width or height we get the factor that determines how much the slide element needs to be scaled to fit the window. Now all we need to do is set the font size of the wrapper element and like magic the slide element is scaled to the correct size.

Here's the HTML5 presentation that uses this technique to keep the slide always the correct size. Try changing the window size and the slide will always look the same.