ASP.NET MVC Web Application as a Desktop Application

Aug
05
2008

Way back in the day, when I was doing mostly PHP web development, I bought an application called Serlient. The basic idea was to combine a task-built web server and a web browser into a desktop application. I used it for quite a few utilities that were quick to write in PHP, but didn't necessarily need to run on a server or were really suited to be running on a workstation.

It also made re-using existing web apps easy and worked really well for showing prototypes and demos or anywhere I felt like whipping up a web app that wasn't multi-user and really deployed in more of a desktop context.

Eventually, I moved into more of a .NET context and just kind of forgot about it. Then, a couple of months ago, I ran across a mention by Scott Hanselman as a minor part of his post of something called the "IIS7 Hostable Core". As soon as I saw it, I wondered if it could be used in a similar way for ASP.NET web apps.

I've been grooving on the ASP.NET MVC framework projects I've been messing with. Among them are several of these types of apps that are really only for my own purposes (i.e. single user), but make total sense as web apps. For instance, my sandbox for MVC has been my invoicing app, Uome.

So, I gave the IIS7 Hostable Core bits a try in building the browser/server chimera. Unfortunately, it seemed to really orient toward .NET 2.0. After a few hours of heading down a unsuccessful paths, more pressing matters took over and I set it down.

Early Friday morning, I came back to the idea and went looking for the hostable web server again. This time, I stumbled acros aspNETserve as well as the other approach. When the aspNETserve site specifically mentioned .NET 3.x, I thought I might be able to get quicker results with it. I was right.

In fairly short order, this weekend, I was able to write a very usable prototype desktop application hosting both the behind-the-scenes web server and a WebBrowser control that browses that site directly. Even better, it worked with the default empty ASP.NET MVC project out of the gate, without any needed retooling.

I code-named the app Jackalope, mostly because a jackalope is an unnatural combination of 2 things that don't belong together: a rabbit and an antelope/deer. Since this thing combines a web server and a web browser in order to bring web applications to the desktop, I figured the name made sense. Besides, you've got to name the project something in order to start working on it.

Further, as part of my first Wildcard Monday, I looked at my list of skills I want to improve and decided to try to get up to speed with Camtasia. So, I put together an overview screencast that describes the idea and does a quick code walkthrough. I think I'm starting to get the hang of it and want to push forward in using it more.

That video is below and the code itself is up on this page: Jackalope. I'm interested in what other people end up using this for. I've got some distinct ideas for a 1st round of changes to make it more usable by non-developers.


Jackalope: ASP.NET MVC Web Applications on the Desktop from J Wynia on Vimeo.

Tweaking My Work Week: Wildcard Mondays

Aug
01
2008

Because I do the mercenary geek-for-hire thing doing wholesale consulting, I've got lots of formulas for how many billable hours to plan for, how many I need in order to cover the bills, etc. For instance, I typically project an average of 156 billable hours per month.

That comes from:

(52 weeks x 40 hours) - (8 holidays x 8 hours) - (18 days of sick/vacation/personal days x 8 hours)

Tack on a few hours for doing paperwork and the like as well as the overhead time of unbillable travel to the client site, etc. and it ends up being a pretty busy schedule. However, take a month like June and the billable hours got out of hand. In order to keep all of my client projects moving forward, I racked up 215 billable hours for June.

While on vacation, I decided that this just plain has to stop. Sure, I made really good money for that month, but at what cost? I was too busy to do much of anything else but work. I was stressed out, constantly tired, missing days at the gym, etc.

Fortunately, in order to get their IT budget back on track for the rest of the year, my main client was also wanting me to cut back on hours, asking for a cap (rather than average) of 148 a month for the rest of the year.

That sounded great to me. The only trick was to figure out how exactly to make it work. See, I've *tried* to show up, put in 8 hours and leave. It just doesn't work. Stuff comes up and needs to be dealt with, people schedule meetings at the end of the day, etc. Combine that with the fact that Shelly and I are carpooling and she often works 9+ hours a day herself and a 9 hour day becomes the standard pretty quickly.

I had a couple of options. First, I could just take longer lunches to turn the day into only 8 of the hours being billable. I don't like that approach because I've never liked taking a long lunch. It breaks up my rhythm.

Second, I could just "punch out" at 4:00 and not work on their stuff. Unfortunately, because I'd still be on site, I know from watching it happen that if I'm busy just reading feeds, or writing for this site, even if I'm not billing the client, someone who doesn't know that (and won't bother asking) will complain to the higher-ups at the client that "one of the consultants is just browsing the web". That leads to questions of why they're paying me, etc. Best just to avoid it.

Third was to just embrace my "natural" 9 hour day and switch to a 4 day week. With a half hour tweak here and there, it'd come in right at 148 every month. And, I'd get an entire day every week to work on my own stuff. Believe me, I've got a LONG list of stuff to work on with that time.

When I suggested the 4 day week, everyone seemed OK with it and figured I'd just do Friday. However, I've never really minded coming into the office on Fridays. People are generally in a much better mood than any other day of the work week. Plus there's free donuts and bagels. If I'm going to be onsite 4 days a week, I didn't want to skip out on Fridays.

Mondays, on the other hand, I could do without. People constantly complain about Mondays. They're still "attached" to the weekend, which can let you keep going on something you started on Sunday afternoon and the week always seems shorter when you don't have to work on Monday.

So, for the rest of 2008, I'll be in my home office on Monday's, working on my personal projects. With no commute, I'll effectively have from the time I get up at 5:00am until about 6:00pm or so to charge through things.

Given that several of the things on my list will result in non-consulting cash flow if they are successful, I'm hoping to bootstrap this whole thing into a permanent cut in consulting hours. We'll see.

Writing My Own Travel Agent in C#

Jul
30
2008

Yesterday, Garrick was describing the difference between a "search result" and "find". His short answer was:

Search Results Listings say, 'The answer might be here'. Find says, 'Here you are, get on with your day.'”

That distinction is something that has always struck me as irritating about using every travel site I've ever seen (later discussion revealed that, ironically, this distinction is talked about obsessively at Orbitz). That irritation is because every search I've made started out as something that doesn't fit in their search boxes: "Find me a cheap coach flight and a hotel near the conference center in Austin, TX for SXSW", "I'd like to go to San Francisco for a long weekend some time this fall; is there a way to do that for under $500?" or "Which one of these cities and which weekend will be cheapest in October for a 5 day weekend?".

Those aren't questions which naturally get answered by a search results page. You don't get to pose those questions to travel sites. What you are asked on every one of them is to choose specific dates and, in many cases, both airports. The sites don't even so much as hold on to the fact that 99% of my travel is based out of Minneapolis/St. Paul International Airport.

Rather, I get a constant flow of emails from the travel engines telling me about great deals to Miami/Las Vegas/New York for $89. Of course, if you are flying out of Minneapolis, that deal suddenly becomes $327 instead.

There is a place you could and can ask those questions and get your "find" satisfied. Travel agents pick up the phone, listen to just such a question and call you back later in the day with the results of your find. Unfortunately, they also are professionals who need to make a living. That means they're not entirely thrilled to, for instance, check daily for weeks at a time for a very specific set of criteria for a vacation I may take if the deal is good enough.

That does, however, smell of the kind of thing that I like sling a bit of code to solve. And, it's something I've wanted to solve for a very long time. Every couple of months, I go looking for a way to write code that searches for flights and hotels and have always come up empty.

Then, this weekend, I did it again and ran across the Kayak API, which looks like what I've been looking for all along. The API allows 1000 searches per day, per developer key. While that wouldn't let me create much of a public service or commercial application, it's a really roomy number if you're looking to do lots of permutations for your own travel needs.

Personally, I'd like to do things like have a list of cities I've never been to and have software grind away on it, finding a good deal for a "fall long weekend" or a "week-long summer vacation", etc. for one of those locations. Similarly, I'd like to be able to say, "I've got $300. Is there somewhere I can go and get a hotel for a 3 day weekend that's on my list?".

Software can easily handle digging through the tedious crap like seeing whether leaving on Thursday and coming back on Sunday is cheaper or more expensive than leaving on Friday and coming back on Monday. As a person, trying those combinations on the existing search results-oriented sites is tedious. Tedious is what software does best.

Before I start dreaming too big for what might be possible, I threw together a quick POC app to see how easy it might be to search and grab results. I created a really basic class library for doing the actual searches and a tiny console app to try out a single search.

I have to say, I like what I see and think that there are some real possibilities for coding up my own travel agent with Kayak.

The sample, half-finished POC code is available in PDF form if you want to look at it. It's got gaping holes all over (hard-coded, read-only properties, unused properties, concatenated strings, etc), but shows the basic idea for how to hit the service. This doesn't do anything to take advantage of any of the polling cycle that the API documentation describes, so the results are incomplete.

However, it proved what I wanted from the POC. I'm now pretty sure that I'll be able to get what I want out of that API. If you're interested in travel and writing software, it might be worth a look for you as well.

Quit Arguing From Anecdote: Take 2

Jul
28
2008

This morning, despite my better judgement, I clicked a link to an article entitled, "Why Should I EVER Buy a House?". By the time I was done reading it, I was reaching for the comments form. Finding none, I write here.

This article strikes one of my hot buttons: arguing from anecdote. I've written about this before. It's when you hand pick one particular scenario and use it to prove a larger point. Given that this article specifically

The article in question uses 2 residences in his comparison. The first is a 2BR/1BA house in Sacramento that sells for $400,000 and a monthly payment of $2,278.29. The second is a 1BR/1BA apartment that rents for $949.00. Leaving aside the fact that the house has an extra bedroom and 200 square feet on the apartment (itself already a flawed comparison), he then uses a bunch of calculations to adjust each number until he comes up with a monthly difference between the 2 of: $1,502.29.

In his scenario, that amount is then, of course, deposited into investments and grows for 30 years, leaving the renter with much more money at the end.

I'm not going to say that home ownership is "better" than renting. I think there's some pretty compelling arguments on both sides. This article isn't going to make either one of them however.

Curious about what *my* version of the anecdote would look like? Here's a comparison for my situation.

My house is 4BR/2BA on 1/3 acre that we paid $215,000 for in 2005. It's probably worth a little less than that at the moment because of a crappy market. For that, we pay $1340 a month. I hit Craigslist to see what a comparable rental would cost. I found 1 4BR/2BA going for $1400. When I expanded a bit to include nearby suburbs, the middle of the bell curve fell right between $1400 and $1700.

The more mathematically astute in the audience will note that, according to my anecdotal evidence, my house is the cheapest 4BR/2BA option available to me by anywhere between $60 and $360. Given the article's follow-on assumptions are entirely based on what you could do with the "extra" money, in the hypothetical-renter-version-of-me's rental scenario, that massive investment and subsequent return on the investment disappears.

I want to make abundantly clear that I am NOT using the above scenario as any sort of argument either way regarding renting vs. buying. Quite the opposite. My example is just as flimsy as his is.

To truly make comparisons, we'd have to be much more careful to construct the comparisons. For example, construct multiple hypothetical families looking for housing. Then take those families and evaluate their buying and renting options in a variety of neighborhoods in a variety of cities. After that, take all of the numbers and run the calculations for each scenario (including correcting his assumption that rent doesn't go up even once in 30 years).

Thus, a single guy would likely have a very different comparison profile to a married couple that has 2 dogs and each a home office. At the very least, I'd be amazingly surprised to find neat, tidy graphs that matched in all scenarios. And, given that he sees a $1+ million jackpot at the end, there actually are some serious dollars at stake if the numbers are off.

It's not that I think his thesis is wrong. It's that, if renting is better than buying (or vice versa), I'd love to see a *compelling* argument that doesn't rely on anecdote. Compare apples to apples. Every city and area of the country has a different mix of houses for sale and rental property and there's not a tidy 1:1 matching on both sides where everything available on one side is also on the other.

Make sure that things like having pets, having garage or workshop space, having your own laundry facilities, having a fenced-in private yard, being able to do 100% of the decorating/modifications you want, etc. are all factored into the equation on the buying side. Make sure that things like having someone else mow the lawn and shovel the snow, being able to call someone else to fix the plumbing, a fully equipped gym and pool to use, and being able to live in a neighborhood you might otherwise not afford are part of the renting side of the equation.

In the end, major life decisions are rarely as black and white as the advocates on either side make them out to be.  However, when those advocates do their arguing from anecdotal "evidence", they do a great disservice to those trying to work through the decision by clouding the waters. If you're trying to make one of those decisions, looking for non-anecdotal evidence and rejecting those sample stories and scenarios is a sure way to improve the information you're basing your choice on.

Mid-2008 Bookshelf Activity

Jul
21
2008
Bookshelves
Creative Commons License photo credit: gadl

Somehow, despite a June where I found myself working an absurd number of hours, I've actually managed to squeeze in some reading of the dead trees variety recently. Even more surprising is that it wasn't all non-fiction.

Part of the reading time came when Shelly started a new job in May that is barely a mile from my main consulting client. Since then, whenever it's made sense for post-work scheduling, we ride together. That, in itself, resulted in a serious of negotiations.

Since her car gets much better mileage than mine, it made obvious sense for us to share her car. That gave us our starting point. However, given how we've both driven to work in solitude for many years, we figured we should probably work out some of the other issues.

First was the radio. Because it's been made clear for nearly as long as we've known each other that I don't like listening to her choice of radio station. That meant that one of us was going to be listening to headphones. A quick discussion later, Shelly offered to do the driving. That put me in the passenger seat for many of the commutes over the last 6 weeks.

That conversation also resulted in rules like "little or no talking". It felt vaguely like Jerry and Elaine trying to figure out how to sleep together and still be friends. We were trying to figure out how we could drive to work together and still keep our relationship working like it already did. However, our attempt seems to have worked considerably better than theirs did.

Much of that time in the passenger seat has been filled with reading. So, what exactly *have* I been reading?

Odd Hours


Because I aim for rational, critical thinking in so much of the rest of my life, I enjoy my fiction, my TV and my movies with a strong dose of the impossible. In the case of Dean Koontz, that doesn't mean futuristic sci-fi, but often does mean granting some rule of nature being bent or broken, bringing a bit of the supernatural to otherwise modern stories.

The "Odd" series is one of my favorites (and clearly one that others like too, given the sales figures). The latest isn't quite as enjoyable as the last couple have been, but was still enjoyable, nonetheless. If you haven't read any of this series, featuring Odd Thomas, the fry cook who sees dead people and hangs out with the ghost of Elvis in Pico Mundo, CA, you should definitely read at least the first one.

If you have been following the series, this one follows a similar story to the others, with Odd falling into the middle of a big mess, relying on his supernatural gifts and the guidance of the silent ghost of Frank Sinatra to work things out.

It's also worth noting that the audiobooks in the "Odd" series are particularly well done as well.

On Intelligence


A while back, I saw an episode of Wired Science on PBS, featuring Jeff Hawkins (he founded Palm Computing) talking about the area of study that's pulled him in repeatedly: neuroscience. His description of the neocortex, including its similarity in size and thickness to a cloth dinner napkin and that thin layer of cells' pretty much *being* the thing that makes us human intrigued me. So, I bought his book.

On Intelligence is the book on this list that took me the longest to actually get through. It's not particularly long or even hard to read. However, every chapter led me to ponder quite a bit. As a result, I tended to read this one in fits and starts over a few months.

The central premise is his theory and the science to back it up focuses on the general algorithm for the neocortex. Oversimplified, every portion of the neocortex just watches for and stores patterns, combining them and replaying them. That goes for sensory input, our own motor control, etc.

Ever since reading this book, I've been seeing more and more in day to day life that fits with this theory. Should his model for how the brain works turn out to be completely right, it will be huge, particularly in the area of computer-based artificial intelligence.

I fully expect to continue mulling this one over for months and years to come.

The Back of the Napkin


Given how much time I spend at a whiteboard, I've often contemplated how to more effectively use that tool. A really well drawn diagram, particularly if it's accompanied by both a good analogy and a good example ends up hitting nearly all of the learning styles in a given room.

The Back of the Napkin was recommended to me as a really good book for how to improve whiteboard diagrams. That recommendation wasn't ill-founded. This approach gives a nicely structured system for how to diagram most common business situations. By focusing on the who/what/when/where/how much types of questions, you clarify your own thinking as well as ending up with things that are fairly easy to draw out.

Fortunately, if you're concerned about your ability to draw, this book should help to alleviate some of those worries. That's because nearly everything he shows could be drawn by a typical elementary school child. So, "I can't draw" is not a reason to avoid drawing in this kind of context.

Presentation Zen


In a similar vein, I've enjoyed the Presentation Zen site for quite a while. So, when I saw that the author of that site had put out a book, I had to take a look.

Like all of the stuff on his site and in conference presentations, etc. I've really found his message to be one that resonates with me. I'm still struggling with how to apply the "zen" approach to Powerpoint in more technical presentations, as opposed to the inspirational and conceptual presentations that dominate the examples, but it's clearly a direction in which to strive.

The book is in keeping with the website content, and bundles it together quite nicely. Much like the presentations themselves, the book makes really good use of white space, vivid photographs and nice layouts.

If you're still using the standard bullet-point layouts from Powerpoint (and the default Keynote layouts aren't really any better, FYI), you should definitely read this one.

Crisis of Abundance: Rethinking How We Pay for Health Care


I read this really short book on a flight from Chicago in preparation for an economics book club that I joined this past month. It wasn't particularly engaging (I'm not really as much into the policy and politics of economics as I am the other aspects of the discipline), but did tackle a very timely topic: upwardly spiraling health care costs.

His thesis is that among the tradeoffs we could employ, most, including limiting access to procedures are extremely unlikely and distasteful to Americans. The remaining possibility (other than just living with the higher costs) is to remove the insulation from the costs that plagues the US health care system.

Our current system grew out of wage freezes in the post-WWII era where employers attempted to attract employees by adding perks, among them health care. A couple of generations later, everyone presumes that this is the way it's always been and end up going to the doctor where an appointment resulting in a couple of Tylenol and one where you get an MRI and dozens of lab tests cost exactly the same.

If you remove that price insulation (as you've got with things like LASIK surgery), the market does a bunch of work on your behalf to pressure the prices.

It's an interesting theory and one we discussed on Tuesday at the book club. This is the kind of thing that's interesting if you find that sort of thing interesting. If not, skip it.

The Mythical Man-Month: Essays on Software Engineering


Most of the stuff in Fred Brooks' Mythical Man-Month is stuff I've read in one place or another over the years. However, I'd never read all of it in one place and it had been a while. When I heard the audio of his presentation at OOPSLA 2007, I grabbed a copy and read it through.

The details and examples are definitely showing their age, but the underlying principles, including the source of the title still ring true 35 years after he wrote them the first time. There are some myths of software development that just seem to have imbibed the zombie powder. They just won't die.

I've lost count of the number of project managers who seem to think that they're going to be the first to add people to a late project and speed it up. Re-reading these essays invigorates my desire to challenge that assumption more emphatically when it comes up.

Predictably Irrational: The Hidden Forces That Shape Our Decisions


Behavioral economics is a field that interests me deeply. For some reason, I'm drawn in whenever someone gathers data about not only *what* we do (rather than what we think we do), but why we do it.

When those things come together, it provides a model for understanding my own behavior and, when necessary, modifying it. This book hits one right up the middle in that way, as does the author's site.

He examines some of the behaviors we all exhibit that don't mesh with what a purely rational/logical behavior would be in the same situation. For instance, we nearly all have a completely irrational desire to avoid closing off options. We'll go to absurd lengths to keep our options open, even when 1-2 of those options are demonstrably better in every way.

That's an impulse I feel regularly that has bothered me. After reading this book, there's a lot of those kinds of things I see myself doing that bother me. Fortunately, now that I recognize them, I can actually stop and adjust my behavior. On the flip side, I also now understand other people's behavior a little better as well. That can help when you're working with others and need a better model in your head for how they're going to act in day-to-day situations.

Overall, definitely an eye-opening book and approach.

Wrap Up

When I sat down to write this up, I figured it would be a quick post. I had a couple of books that I finished and wanted to mention. As I started writing, I saw how many books were lying around that I knew I'd finished recently and, next thing you know, I've slobbered nearly 2000 words into this post.

A while back, I read a comment that said you should only pass along books worth reading. The person in question thought that if you didn't really enjoy a book, you shouldn't donate it to charity, etc. as it would encourage someone to read an unworthy book.

I don't think I agree with that (too many books are liked or disliked on largely subjective terms), but it does make me think whenever mentioning a book to make a point of being fairly clear about whether it worked for me or not and why. And, for this list, there you are.

« Older Entries   Newer Entries »

J Wynia

For better or worse, I'm the guy who runs things here. I'm a web consultant, software developer, writer and geek from Minneapolis, MN. This site is a fairly wide cross-section of the things I'm interested in and enjoy writing about.

Oh, and if you happen to be looking for hosting for your Subversion repositories or just web hosting in general, take a look at Dreamhost. It's what I use for Subversion and your signup helps me out.

Feeds and Links


www.flickr.com
This is a Flickr badge showing public photos from J Wynia. Make your own badge here.

Search


Pages

Archives

Computers Blog Directory
© 2003-2008 J Wynia. All original content is licensed under the terms of the Creative Commons Attribution license unless otherwise noted. Content from other sources is licensed under its original terms.