Modern JavaScript Development: Scope
After hearing an interview Scott Hanselman did with Scott Cate about JavaScript a while ago, I decided to use one of my presentations into a screen cast. In this two-part screen cast, I cover how scope works in JavaScript and how we can use object literal notation to fake namespaces.
Making JavaScript Less Painful part 1
Making JavaScript Less Painful part 2
I’m still finding my way around screencasts. Eventually I’ll upload these to vimeo, screencasts.com,, and youtube as well as making them embeddable and providing embed code.
Episode 18: Matt Podwysocki on F# and Functional Programming
This week Matt Podwysocki puts the fun in functional programming with a deep dive into F#. We’ve heard plenty of high level discussions of F# and functional programming lately, so we tried to dig into the gory details as much as possible: What is functional programming, and why should we care? Types of applications that [...]Herding Code #17
We’ve gotten a lot of great feedback about our podcast. Despite that, we’ve continued recording them and have made it to episode 17 – Browser Roundup.
There has been a lot of activity in the browser and JavaScript arena. IE 8 beta 2, Chrome, FireFox 3.1 beta, TraceMonkey, V8, SquirrelFish,etc… And most of us on the podcast are web developers at some point or another during our day jobs. We had to cover it. You’ll get to hear me misrepresent what .NIB files are and mispronounce OS X.
There is also a good description on the Chromium blog about how Chrome utilizes multiple processes.
Debugging Managed Web Applications on x64
I ran into an interesting problem a while back. I needed to fire up the debugger and figure out what was going on in a web application. I tried my usual keystroke, F5, to start debugging the web application but received an exception telling me that the debugger could not start.
No big deal, I’ll just attach to the web server process. Ah, but there’s a catch. I’m running Windows XP 64-bit. My web application is written in managed .NET code but it’s running on IIS which is native x64 code. So when I look at my process list, I see that T-SQL, Managed, and Native code is running in that process.
If I let the “Attach to process” dialog pick the correct debugger for me, it appears to try and debug the native x64 code running in that process. Since I’m trying to debug my managed application, I guess the debugger can’t switch between managed code and native code.(1).
So the key here is to make sure I select “Managed code” from the debugger dialog.
This ensures that I’m using the correct debugger and my breakpoints are getting hit.
Now, I’m back to having to figure out what the application is doing.
(1) – I’m sure there is a better technical explanation for what is happening here. If anyone can explain it better, please leave a comment with the explanation or a link to a blog/forum/arcticle.





