Entries tagged with ‘VisualStudio’:
Using a MacBook to run VisualStudio
Earlier in the year, I found myself in the middle of a great tragedy: the harddrive in my aging 12” powerbook decided it was time to say farewell. Now, I’m not certain, but I’m going to assume the main reason it left us, was to be with the superdrive which had also passed away about 8 months prior.
Clearly the only way to survive this whole affair was to sever all ties to the powerbook, and rebound with a new laptop. Clearly.
Since my primary development environment is VisualStudio.NET, I’d pretty much decided that my next computer would probably be a windows… Unfortunately, once I started shopping around, none of them met my small list of requirements:
- Small—I’m one of those people that thinks “the smaller the better”. The idea of lugging around a 17” monster is not for me.
- Runs VisualStudio.NET
- Has DVI Out—I’ve got that fancy widescreen 22” display at home. When I’m there, I want to be able to plug into it. (And, once you see the difference of DVI vs. VGA, you’ll never go back)
It seems that if you’re looking for a laptop from HP/Dell/IBM, you can’t get these things. Hardly any PC laptops have DVI out, and the ones that do tend to be those 17” beasts.
And then there’s the new Intel-based Macbooks. Core2Duo, DVI out, 13” widescreen… but could I really run VisualStudio.NET in parallels? I figured “what the hell”, and plopped down the money to see if it would work. One great thing about Apple machines is their high resale value. I figured, if I hated it, I could craigslist the damned thing, and get back most of the money.
So I ordered one of sexy black ones, with 2GB of RAM and a 160GB disk. It’s been a month now, and it’s going “OK”. The macbook is a lovely machine, but everything you read about fingerprints on the black are no exaggeration—the goddamned thing is a grease magnet. I’ve been using a microfiber polishing cloth to clean it, and I’m to the point of having to do it daily (damned OCD).
VisualStudio in parallels is also “just OK”. I’ve run into a number of weird issues with the Parallels Windows XP installer, where it appears to set permissions on the disk weirdly, and VS just can’t seem to cope with it.
I've also had a number of issues regarding disk corruption with the parallels disk image (not bootcamp)… maybe this is related to the above problem.
Parallels doesn’t like to sleep. If i just close the macbook while parallels is running, there's a 75% chance that the mac book won't make it into sleep mode, and also won't seem to wake back up. If I suspend Parallels before sleeping, it seems like there’s about a 40% chance that Windows will bluescreen on resume. I’ve finally learned to just shut Windows down all the time now, which is kind of a bummer.
Parallels is also just not as fast as I want it to be. When checking out the main Presto solution, there’s a number of web applications, web services, an instance of SQL Server, some device simulators, etc. that all need to be running. It’s do-able, but it feels like it’s running at the speed of my old 1.4Ghz windows desktop. Not awful, but after having everything in the Mac OS X go so fast, it’s a bit of a let down.
I’m finding that my natural work habits now are to run only VS in parallels, and run everything else (Mail, IM, browsers) in the mac OS… which I reckon is fine, though it's not quite what I expected.
Ruby on Rails from a C# Perspective
Well… So, it looks like I bought into the hype. I’ve now completed rewriting this weblog from C#/ASPNET to Ruby on Rails.
It’s kinda funny, I guess, that I spend time writing, (and rewriting, and rewriting, and rewriting) this weblog when I never actually write in the damn thing. So it goes.
I reckon it’s become an interesting project for me these days, and a good practical exercise when working with a new language or a new environment. And, since I’ve written the damn thing at least half a dozen times now, I’ve learned a lot about what it means to build an effective administration UI, what it means to keep the data in the DB portable (because I assure you that in a couple of months I’ll be looking at rewriting this in smalltalk, python, or lisp), and how helpful it is to fully separate your logic from your presentation.
Anyway… back to the subject at hand: some of my perspective as a C#/ASPNET developer on Ruby on Rails, and how porting this blog to ROR went. There’s a number of things about ROR that I really like, so let’s let the glass be half-full, and start there.
- Ruby is an incredibly “clever” language. There’s a lot of little stuff that (once you get the hang of) you think: “Well doggone, that’s pretty clever…” Before starting with rails, I actually tried to dig into the Ruby language itself. This document I found to be both well written, and pretty useful.
- After about a week, I found Ruby syntax becomes incredibly automatic (albeit still very weird). There have been a number of times where I’d think to myself, “That can’t be the right syntax…” but, I’d save the document, try it, and sure enough, it would be right.
- The Rails framework is also quite clever. It does a great job of cramming MVC down your throat and making you really keep your code tidy.
- Obviously, the extremely demo-able scaffolding is very smart, but there’s a lot of other really smart stuff, like generating XML documents programmatically with rxml. I’m sure many of the features of the framework could be built in C#, but it’s very nice to get them for free.
- I’ve found myself really liking the way the ActiveController “method-as-page” metaphor works. It organizes your code in a very different way than a traditional ASPNET web application, and is pretty cool.
- The built-in webserver for development (mongral on my macbook) is awesome. The VS 2005 built-in development still server has quite a few bugs, and the goddamned thing still does not want you to run your web application at “/”.
- And not to be a broken record, but the rake tool—especially when using it for database migrations is really clever. I’m looking forward to diving in a little deeper here, because it feels like I’ve only scratched the surface.
- Another small thing: the Rails’ built in logging, is also nice. I’m tired of always having to BYO logging to my ASPNET web applications.
Now, after all that praise, let’s talk about what doesn’t work well from my perspective…
- Probably the biggest issue I have is that I miss my IDE. VisualStudio, even with all it’s lumps and warts, I still think is a fine IDE. For Rails development, I’ve been using TextMate and, while it’s a fine editor, I really miss all the goodies of IntelliSense™, tab-completion, class browsing, and inline debugging.
- Speaking of debugging… From what I’ve read, it’s fairly lame in rails. I say read, because with my macbook I currently get “Breakpoints are not currently working with Ruby 1.8.5”. Right… That makes it just about useless.
- The ruby language (which I just praised above) I have to admit, I’m really not a fan of.
- You can use parenthesis, but you don’t have to.
- You can use curly brackets, but you don’t have to.
- You can use line breaks, but you don’t have to.
- And whitespace formatting is all over the map.
Powerful? Sure. But damned confusing when you’re trying to read it. C# might not be the best language in the world, but it really does lend itself to reading well. Having VS also enforce basic formatting rules, helps keep things consistent, too. - Documentation, documentation, documentation. Both the Ruby documentation and the ROR docs are pretty pitiful. Say what you want about .NET, but the MSDN documentation is pretty damned good. One of the things that drives me crazy in the Rails API is for many methods there's just an “options={}” as one of the args, but no mention what so ever as to what these mythical options may be.
- Although I think I need to give it another shot, I wasn’t very impressed with RDoc. Again, VS and it’s Xml Comments setup seems much more practical, easy to generate, and infinitely more readable.
- Did I mention how much I miss IntelliSense™? I really, really do.
All in all, it's been an interesting experiment. I’m not sure I’d ever choose ROR for a “real” development project (I still have lots of questions about fcgi, and some of the more “backendy” things that rails does) but for building internal tools, or (like this case) a simple blog, it seems pretty slick.
I imagine I’ll tinker on modifying this weblog app a bit more, and then try and rebuild one other side projects in rails—an online photo album
Programmatically removing a page from ASP.NET’s output cache
So here’s an interesting thing I thought I should mention. In working on some of the code for this blog engine, I’ve been using the ASP.NET OutputCache directive on some of the .aspx pages to help speed things up. This way, in the event of a slashdotting, or some other sudden increase in traffic, you’re not rebuilding the page or hitting the DB for each request. Nice, huh?
So that’s all fine and good, but what about when you want to blow the page out of the cache? Case in point, in adding comments to the blog engine, the user will expect to see the comment posted immediately, not in 3 minutes.
Sure, I could go in and just make sections of the page cacheable, but… eh… that’s a lot of work. I want to be lazy and just blow the cache away. Sounds simple enough, right? But, for the life of me, I just could not get it to work.
After doing some googleing on the topic, playing around with both the Cache.Remove() as well as the HttpResponse.RemoveOutputCacheItem() methods just seemed to not work.
After several hours of pulling my hair out, I realized the mistake was in the OutputCache directive on the page. I had been using:
<%@ OutputCache Duration="60" VaryByParam="*"%>
What I was missing, was adding the Location parameter to the statement. By changing it to
<%@ OutputCache Duration="60" VaryByParam ="*" Location="Server" %>
the HttpResponse.RemoveOutputCacheItem() method would now work. Woo-hoo!
The other trick I found was when calling the HttpResponse.RemoveOutputCacheItem() method, for the path parameter should be the full virtual path to the page. So, for some site: http://foo.com/somedir/somepage.aspx the path param would be "/somedir/somepage.aspx". Also, it shoud not include any QueryString information.