The Netflix Watch Instantly feature is pretty cool. There are a bunch of interesting documentaries, some good foreign films, and loads of kids shows on there (including Doggy Poo). Since we have decided to see how long we can hold out before paying for cable or satellite TV, I thought I'd ease the pain a bit by rigging up a Watch Instantly setup for our TV. Here's how I did it.
First, I already had an old PC with a Radeon 7000 in it. So I had RCA video out. I also had a sound card. I needed the two cables: one RCA video cable to go from the video card to the VCR or TV, and the sound card-to-RCA splitter cable. This has a headphone-like plug on one end (for the sound card) and the red-white RCA cables for left and right audio on the other end. I plugged these from the computer into the VCR, because it was more accessible.
Next, I had to get network to this box. I was so tired of wireless dropping out when the neighbor microwaved their popcorn or whatever that I actually wired Cat5 to my entertainment center. Once that was working, I verified I could play the netflix movies on the TV. I set my resolution down to 800x600 to be truer to the TV's 648x486 or whatever it is. If I had a decent TV, I could have left it at a more readable resolution I'm sure.
The final step was finding some way to control the PC so that I could browse movies and select the one I wanted to play. Reading text on the TV was extremely difficult, so I wanted a better screen.
I realized that since Elly always has her laptop going, I could just set up VNC between that and the TV's PC. The laptop would be a really big, but versatile, remote control. So that's what I did. RealVNC on the PC and Chicken of the VNC on the laptop. It works like a charm:
It's tricky learning design, especially as a developer. And I'm not talking about the aesthetic stuff--for some developers that may be downright impossible--I mean the technical world of HTML and CSS. The problem I've had over the years is that, as a developer, most CSS/HTML information on the web is not targeted at someone with my background. If you're like me, then you have a BS degree in computer science or engineering from a university where you were made to sit and think about everything from processor pipelines to XOR gates to compiler optimization to how much wood could a wood chuck chuck if a wood chuck could chuck wood and what would be the complexity of said wood-chucking in big-O notation, thank you very much, here is your degree, now go learn Java or Xt or MFC or whatever in the real world on your own.
So you know enough to write the CSS parser and rendering engine, at least on a theoretical level. But that won't help you to use it. Nor will it help you to know the quirks of the several rendering engines out there in the real world.
So I find myself in this quandary of knowing too much for my own good when I sit down to learn about CSS/HTML. Then I get impatient. I want the articles targeted at design-people to just cut to the chase. Stop talking about "If you wanted to have these pretty flowers in the upper left corner, you would float DIV x and put a background..." Show me the money. I'm not an art major. My web pages may suffer for that, but I can understand the box model if you would just tell it to me already.
The purpose of me writing this post, then, is to collect a few choice resources I've discovered in my own haphazard and unofficial CSS/HTML career.
Find a good CSS reset to start from ground zero. My philosophy is to know as little as I need to about the difference between browsers. The less you fill your brain with that meaningless crap, the more room you have up there for knowledge that might actually enrich your existence. One way to cut down on the browser-difference arcana in your head is by never using the default styles, which vary from browser to browser. You can choose from many of the reset CSS recipes out there:
Don't using clearing elements. I used break tags (BR) with a style of "clear: both;" for a long time to clear floats. Even though it is the W3C-recommended approach, clearing floats in this way will drive you crazy. (It is difficult, if not impossible, to get those clearing elements to share a uniform height across browsers.) I use Tony Aslett's clearfix method personally, although Dave pointed this out to me. It is a more recent technique, but I'm a bit hesitant to start using overflow to achieve clearing. It gives me scrollbar nightmares.
Understand the Holly Hack. I never understood the difference between clearing floats in IE and other browers until a I read an explanation about why the Holly Hack fixes it. I wish I had read this years ago.
Use Chris Pederick's Web Developer Toolbar. This is the single most awesome CSS tool that I use. The Edit CSS and View Style Information tools are almost all I need. Occasionally I will drop into Firebug when the View Style Information tool doesn't do the trick (it doesn't show the inherited styles as well as Firebug).
Don't take on IE6 without CSSVista. If you're like most people, you develop everything in Firefox or Safari first, then drop into the depths of hell to work out whatever is broken on IE6. One nice tool that lets you interactively edit CSS in IE and FF at the same time is CSSVista. It's free. It's not perfect, but it's the best I've seen for IE yet. The IE Developer Toolbar is also nice to have.
Don't buy reference books. It's funny how many CSS reference books there are. Same with HTML. You don't need me to tell you that these are a waste of paper, including that green paper that is your money. But there are some good CSS books that discuss layout techniques and browser bugs. It is definitely worth having one of these. I like this one a lot. It is also good to have a CSS cookbook on hand when you need to remember the right way to do some common CSS task. I use the CSS Anthology from time to time.
Read this book. For all of us who are not graphic design majors, who didn't know all those fancy terms in that documentary on Helvetica, I recommend The Non-Designer's Design Book. Nothing has helped me more in grasping the basic aesthetic principles of laying out a page. If you have to do anything with design, even if it's just laying out your church bulletin, you should read this book. It's short, easy, and will have you making passable designs in one day.
If you are a dev who has been designing for a while, this is probably all old hat to you. But if you're like I was a couple years ago (clueless), then an hour spent reading the links above will hopefully be a great starting point for you.
Birds I've seen in the past few weeks as the direct result of owning a dog and walking it in the early morning/evening:
These are only the ones I can identify. I have seen many others that I can only describe as "little brown bird in the grass" or "big black bird with white neckline" or "mini black duck."
Other wildlife that we've observed and/or barked at:
I just got forwarded an article by Hank Williams from a client who has been watching the ongoing Twitter scalability rumpus that has kept us entertained for literally years now. Blaine's recent point about scalability is one I would mostly agree with, and one which I'm sure he's tired of making. I haven't really been following the Twitter-talk on all of the techie blogs, except through hearsay. "Did you hear that TechCrunch said Twitter is dumping Rails?" "Did you see that post about Twitter scaling?" Yada yada yada. Half of it is inaccurate the moment it is posted, and the other half is fraught with misunderstanding and wild speculation.
One of the reasons I've been loath to follow these discussions is underlined by William's concession at the end of his post that, indeed, Twitter's scaling challenge is a "hard ... problem that requires a very specialized ... architecture." Aren't they all? And so that is why I don't read the pseudo-tech jibba-jabba of TechCrunch and others about the scalability of Rails in general based on the experience of one very unique site. Scalability is unique to each site. Indeed, you are a unique site when you have to worry about scalability. That means you are getting lots of traffic, and probably making money. Most sites don't make it that far.
But I didn't write this post to join the Rails scalability rant. I just wanted to mention one observation that I haven't heard yet in the Rails scalability discussion. Here it is: the web is a moving target, and the current discussion often fails to acknowledge that. The web today is demanding more of frameworks, languages, developers, and system architectures. For instance, on MOG, we knew scaling would be a major problem from the get-go because a central piece of the application involved hundreds of thousands of agents running on users' disks, reporting tens of thousands of songs. What website was doing that in 1997? For what piece of software are those numbers not a scalability issue? It's the same with Twitter (as Hank points out): millions of people tweeting all at once, very frequently, via web, phone, Facebook apps--who knows, maybe there's even a Twitter client for your hair dryer or coffee maker now. This sort of challenge is (relatively) new for the web. And new ones like it are being invented every day. The target is constantly moving and changing shape.
If we nailed down the goalposts of web scalability, no one would bother posting and trolling and debating about Rails scalability. It would be solved by a handful of good engineers in a couple of weeks. For good. But what would be the fun in that? You'd never hear about another site that does something you wouldn't think possible 5 years ago. And, as an engineer, you'd never have the fun of solving new scalability challenges to support those new sites.