All posts tagged with writing

My Web Perf Book For O’Reilly

Head over to HTTP Archive and check out their trends graphs. Notice anything? That’s right, web pages keep getting bigger and more complicated. The problem here is that — particularly in e-commmerce — consumers of your site expect it to load and become interactive quickly.

Turns out, the problems involved and solutions needed to fix them depend, mostly, on straightforward, Web Dev 101-level knowledge and technology. I recently wrote a short e-book on the subject for O’Reilly, Web Page Size, Speed, and Performance (free, registration required). There’s also an accompanying blog post on O’Reilly Radar, It’s time for a web page diet.

Slimming down web sites is not necessarily a matter of learning new and sophisticated programming techniques. Rather, getting back to basics and focusing on correct implementation of web development essentials — HTML, CSS and JavaScript — may be all it takes to make sure your own web sites are slim, speedy and responsive.

Interesting side note: mobile web users (and probably app users as well) expect faster interaction than on the desktop and are more likely to ditch an action if it’s slow. Think about the implications of that complication on your app development plans.

Writing About Code: Structure

In my previous post, I provided some tips about how to get started writing. That’s all well and good, but you would probably also appreciate some tips on what to write and how to organize your writing into something coherent and readable. Let’s dig into that now.

Many of us were taught a five-paragraph mode of construction: tell us what you’re going to tell us, tell us, then tell us what you told us. This is boring, repetitive, and evil. Don’t do it.

Instead, consider this structure for your writing:

  1. Problem
  2. Solution
  3. Next steps

It’s similar to the old five-paragraph model — there’s an introduction, a body and a conclusion — but I think this structure better directs the organization of your writing and makes for more interesting reading.

The problem statement

The problem statement is the introduction. It serves two purposes. First, it explains briefly what your article is about. Second, it’s your opportunity to grab the reader’s attention.

Starting with the second point, many readers think being outrageous or funny makes for a good hook. While that can work, it throws an unnecessary variable into the equation. Are you really funny? Is that enough to hook a reader? Are you sure?

Maybe it’s better to just clearly state what you’re writing about. Provide some context: what does it relate to (language, platform, type of development…), and why should I care (am I doing it wrong, does this make my code faster, stronger, less buggy…)? This is why I called it a “problem statement.”

Readers are often more interested when you clearly define your subject within a the scope of a problem they might encounter and one or more solutions that solve the problem. One approach, of course, is to literally solve a problem, but taking a more abstract view of the problem-solution structure can help guide your writing on other topics as well.

Keep your introduction brief, but it can be several paragraphs if necessary to set up the context in sufficient detail. However, make sure at least one paragraph — preferably the first or last paragraph of your introduction — clearly states what your entire post is about. People who will share your article in social media, aggregators, and newsletters will cut and paste. Make it easy for them.

Here’s a good example of a brief and to-the-point introduction in an article by Chris Eidhof on Lighter View Controllers.

View controllers are often the biggest files in iOS projects, and they often contain way more code than necessary. Almost always, view controllers are the least reusable part of the code. We will look at techniques to slim down your view controllers, make code reusable, and move code to more appropriate places.

Notice that, in three sentences, Chris explains the context (view controllers in iOS programming), the problem (they’re too big and not reusable) and what he’s going to explain (a solution for slimmer, more reusable view controllers).

Here’s a longer example from Charles Petzold’s DirectX Factor column in MSDN Magazine.

High school geometry comes in two distinct flavors: Euclidean geometry is oriented around constructions, theorems and proofs, while analytic geometry describes geometric figures numerically using points on a coordinate system, often called the Cartesian coordinate system in honor of the pioneer of analytic geometry, René Descartes…

In the previous installment of this column… I discussed how to use the ID2D1PathGeometry to render lines in a finger-painting application that runs under Windows 8. Now I’d like to step back and explore geometries in broader detail, and in particular investigate some of the intriguing methods defined by ID2D1Geometry for manipulating geometries to make different geometries.

This is a longer introduction, and I’ve even left out a paragraph for clarity, but you can see that it includes the same building blocks: a context (geometry in Windows 8 programming, continuing from a previous articles), a problem (geometry is hard, you need to know how it works), and a solution (learn about ID2D1Geometry).

If you can keep your introduction — your problem statement — focused like this, it will help you keep the rest of your article focused as well.

The solution

This is the meat of your article and where you’ll spend the most time writing. I won’t spend too much time on this as it’s really the focus of my first post on getting started writing. You just need to pick a subject and start writing.

The main portion of the article is where you can explain the problem or opportunity in more depth than a concise intro problem statement allows. Stop and provide some more context if necessary, though don’t let it distract from getting to the solution. If the problem starts to become the entire article, you might want to rethink what the article is about. Maybe that’s another writing project altogether, or maybe you can link to more context elsewhere.

How you write about your “solution” depends on subject and the way you want to organize your ideas. A few common patterns are:

  • Start from the beginning and work through to solving the problem
  • Pick a few key elements to explain
  • Top ten lists (pro tip: odd numbers work better)
  • Analysis of different patterns or implementation approaches
  • Pros and cons

There’s not necessarily a right or wrong way to organize the core of your writing. Go with your gut, pick something, and run with it. After you complete a draft, if the organizing theme you’ve selected doesn’t seem to be working, don’t try to force it. Rather, be open to refactoring and heading in a different direction. Reorganizing takes less effort than re-writing.

Next steps

I’m of the opinion that a blog post or article does not, in fact, require a formal conclusion. If you finish your subject and want to simply stop, that’s fine.

This is particularly true of very short blog posts that cover a single, very focused subject. Provide some context and a problem statement, explain yourself through your solution, and done!

If you do want to provide some closure, don’t simply restate your original thesis. Instead, you can just sum up quickly: “That’s a quick overview of recursive dohickies in action.”

Another approach, if there are other considerations, is to qualify your solution. Although I’ve warned against pedantic, edge-case addicted readers, you don’t need to be all-inclusive or all-encompassing in your solution. Just explain that there’s more to the subject: “This solution works well for most apps, but edge cases X, Y, and Z require additional hemming and hawing.” Maybe that’s fodder for future writing.

As implied by my heading, it’s always helpful to suggest some next steps for the reader: where to learn more or find additional examples. Other potential solutions or associated technologies. Ideas for further or more sophisticated implementations. You don’t need to go on at length. A simple mention and, perhaps, a link goes a long way.

Links are the lifeblood of the web, and links in your article are good. They let you pull related context and information into your post without having to write it. They also let you recommend quality sources of information and code to your readers, situating your own writing within the larger web of discussion on the subject.

You can (and should) link to your own previous posts. Go back and add links in previous posts if you cover the subject again later. This is particularly important for multi-part series of articles so a reader can find the beginning of the series from any post in the series, then follow through from the end of one post to the beginning of the next. If you make it easy for readers to stay on your site, they will.

Link to other people’s posts if they’re relevant and helpful. People (readers and writers) appreciate that, and if they’ve already covered a subject, it saves you from repeating it.

Link to apps, libraries, reference material and anything else that you use or discuss in depth so readers can find and use it too. Make sure you get the name right, though, and it’s a nice touch if you check occasionally that links still work.

Comments on the code examples

Code is great. You should definitely include code examples if they’re relevant to in your writing. But a code example does not replace an explanation.

If you show code, you should explain the code, even if it seems obvious to you. You wrote it. Of course it’s obvious. However, your reader is trying to learn. If it was obvious, they wouldn’t be reading… and many of your readers are going to be far less accomplished programmers than you. Help them understand.

In fact, this is where a lot of official documentation falls down. It shows the most basic example, but never take it farther than that. Then it jumps straight to a complete sample app. There’s often little explanation of how you get from A to Z.

And as we know, the API is rarely as straightforward to use as the author thinks. There are always inconsistencies and gotchas and misnamed features and things that look the same but do something completely different.

You don’t need to show all of your code if it’s available somewhere else. Just the important or interesting bits, and a link to peruse the rest.

If there are dependencies, make them clear.

Test your code in a fresh environment (VM maybe) to double-check that there are no unexpected dependencies. “It works on my machine… ” is never a good excuse.

The specific coding style choices you make are not as important as consistency and clarity. Pick something and keep with it. It can help to use super-clear naming that you might not use in real code.

More on writing about code

This is part of a series of posts discussing the main points of my “Writing About Code” presentation at Vermont Code Camp 2013. Here are all of the posts in the series:

Writing About Code: Getting Started

Writing About Code: Structure

Now, get writing…

Writing About Code: Getting Started

Writing code is job one for most software developers, but learning to write about code is almost as important. Whether you’re documenting an API or showing off your own smarts, when you set out to write about what you think you know, it tests how well you really know the subject. As you write, you’ll often end up deepening your understanding of how the code works and honing your skills as a developer.

In this post I’m going to provide some tips and tricks for programmers who haven’t done much writing that will help you get started and find early success that fuels more writing.

This is a distillation of the first part of my “Writing About Code” presentation at Vermont Code Camp 2013. I don’t believe dumping my slides on the web helps. Instead, I’m pulling the most important ideas from my presentation into a few blog posts that are easier to read, digest and use to fuel your own work.

Why write about code?

There are many reasons to write about code. Maybe you want to share your knowledge and enthusiasm for programming, to market a product or teach customers how to use it, to promote your own abilities or because it is (or should be) part your job.

But I’d like to suggest another, more valuable reason, best summed up in this ancient wisdom from Seneca the Younger: Docendo discimus (“by teaching, we learn”).

Whether you write for yourself or decide to write publicly, you’ll start to explain something and, often as not, start wondering: Really? Is that all there is to it? What am I missing? How does this work? Engineers — your target audience — are always going to point out edge cases and pedantic details. Are you ready?

Go ahead and second guess your assumptions about your code, dig into the how and the why. You will most likely learn something new and improve your skill as a developer.

My code speaks for itself, right?

Unfortunately, your code does not speak effectively for itself — not for a wide audience anyway.

A code example does not replace an explanation. Sure, there are times when sharing a simple code snippet seems sufficient, but even then it’s usually posted in the context of a discussion… usually via social media.

If you show code you should explain the code, even if it seems obvious to you. You wrote it, so of course it’s obvious. But there are many other people — your potential readers — who are trying to learn. If the concepts you present in your code were obvious, these people wouldn’t need to be reading about it.

Many of your readers are going to be far less accomplished programmers. Believe it or not, by simply taking the time to research and write a blog post, you become an expert. Help them understand.

In fact, this is where a lot of official documentation falls down. It shows the most basic example, but frequently fails to take it farther than that. Then it expects you to jump straight to a complete sample app. There’s often little explanation of how you get from A to Z.

You may think it’s all be written before. What do you have to contribute? We’re still figuring this programming thing out. Every bit of knowledge helps move the profession forward. People are still writing about C. People are still writing about Cobol! Your unique approach to the subject may be the key that unlocks a problem for some reader.

Fear of writing… or how I learned to stop worrying and just write

The most important tip: Write something. Anything. Just get it out of your head and on the screen. Make time to write every day. 100 words or 30 minutes or whatever seems achievable on a regular schedule. As you become more comfortable, try increasing your target time or word count.

Do make it a habit, but don’t make it a chore. If you get stuck, stop and come back to it later.

Use the tools and languages you use every day. Write about the thing on your mind right now. A distraction that often gets in the way of writing (and probably coding, too) is obsessing over the “best” tools. There is not best writing tool, and messing with different editors just keeps you from writing. Word is fine, but so is a basic text editor… your IDE will probably work fine if that’s where you’re most comfortable and productive.

Don’t underestimate the usefulness of pencil and paper.

A helpful approach for avoiding editorial paralysis is to commit yourself to at least two trips through the material. I think most people get in trouble by trying to edit while they write. The result is usually not writing. An outline or a list of the major points you want to touch on works well, but from that starting point, try to write stream-of-consciousness. Get as much down on paper as possible.

Don’t fixate on the entire article. Work idea by idea, section by section. Each sentence is a building block for a paragraph, and each paragraph is a building block for your article.

Although correct technical details are important, as are correct spelling and capitalization, don’t get hung up on researching each topic as you write. If there’s something I’m not sure about or that needs more detail, I prefer to make a note to myself inline to go back and double-check or add more information later. Better to have the sketched out skeleton of your writing in place rather than getting side-tracked by research from writing at all.

Write a complete first draft before making any edits or revisions. That includes fretting about spelling, grammar, and so on. Once that draft is complete, then read it through, fix mistakes, add details, re-order, refine, and refactor as needed.

Focusing your big ideas into byte-sized pieces

A common problem for writers is determining the scope of what you’re going to write about. If the idea is too big, you’re likely to run into two problems: You either never finish (which is frustrating) or you skip over important details to finish (which leads to a poor finished product).

At least when you’re starting out, focusing your writing on small, achievable goals will help you succeed more often, giving you confidence in your writing and setting up a positive feedback loop of writing, accomplishment and more writing.

It’s often better to focus in on a very specific detail and write about that as clearly as possible. You have a more clear goal for the writing in front of you. You can often think around the smaller concepts more easily. Plus, there’s less to write — you’ll finish more quickly.

You can stitch together other small, focused bits of writing into episodic blog posts (Oren Eini does this very effectively on his blog) or into a longer article.

You’ll often find that small topics aren’t really so small when you dig into them. Think about not just how you implement a solution, but how it works… and why. What are the edge cases? What’s helpful to know? How much is boilerplate, implemented for you by the IDE or framework? Can you explain how that all works? How much is “received wisdom” about how things should be done, or code IntelliSensed in with a keystroke?

In fact, I suggest, as an exercise to practice writing about your code: take a chunk of code and explain it block by block. I bet you’ll discover quite a few assumptions you’ve made along the way. It doesn’t have to be your code. Document some random source code just for the practice.

Avoid pasting in large code blocks. It hinders the flow of reading and distracts your reader while she deciphers the entire block. Instead, break your code into digestible snippets if at all possible. Explain each bit as you go through. At the end you can provide the entire code block for copying and pasting, or link to a file/repo.

I suggested digging into the details, but you don’t always have to explain how deep the rabbit-hole goes. Most of the time, unless you’re writing basic programming tutorials, you shouldn’t have to explain how a for loop works, or what you’re iterating or basics like that.

Instead, think about the conceptual building blocks of your idea. Break code down into snippets that let you discuss it in terms of those building blocks. For nuts and bolts coding, that may mean discussing code line by line within individual methods. Other times you might discuss the overall construction of an entire class (suitably simplified, if possible) or of classes within an application.

As an example, take a look at Chris Eidhof’s Lighter View Controllers article at objc.io, which examines code organization at the class and file level. Then consider Peteris Krumins’ Bash One-Liners Explained series of posts, which by definition examines one line of code at a time in great detail.

What to write about?

Still not sure where to start? Here are a few ideas:

  • Write about what you’re enthusiastic about
  • Write about what you’re curious about
  • Write about what you’ve done that makes you feel smart
  • Write about a problem you had to solve
  • Write about what annoys you or makes you smile
  • Write about what you don’t understand: you’ll learn along the way

There is a audience out there eager to learn. Start writing for them. It will do you some good, too.

People love to learn how things work… and why.

People love when someone else solves their problems.

People want to know what they need to know and where to find it. They want to know how to get started, and then they need to be handheld from the simple to the more complex.

People always appreciate clever and useful utilities and code snippets, and tips for how to use them.

Stop reading, start writing

You have some basic tools for getting started. Now put them to work and get started writing something every day. You don’t have to publish it. Just keep a journal for practice… a journal of ideas, which you might return to later for material as you become more confident in your writing.

This is part of a series of posts discussing the main points of my “Writing About Code” presentation at Vermont Code Camp 2013. Here are all of the posts in the series:

Writing About Code: Getting Started

Writing About Code: Structure

Now, get writing…

A Sim Racing Primer (2004 edition)

Back in 2004 I wrote this overview of the PC sim racing scene for my local BMW club newsletter. It’s very dated now — few, if any, of these games are even available, much less worth using. However, you might find it an interesting snapshot of the times and an indicator of how quickly things change in the gaming industry.

For context, I started sim racing in 1999 with Grand Prix 2. By 2001 I’d discovered Grand Prix Legends and a year later attended my first real-life track day.

Now, more than a decade later, I have a bit more experience with performance driving, both online and off, and the PC sim racing world has changed immensely. I’ll try to write that story soon. In the meantime, here’s the situation as I saw it back in 2004. (I’ve edited, where appropriate, to include currently relevant links.)


Now that winter is upon us and the track season is over, where does a true racing nut go for that much-needed fix of oil and adrenalin? Some may immerse themselves in preparing mind and machinery for next season. Others may head off to warmer parts of the country. But what if you could satisfy that desire to drive at the limits without leaving home… without even taking off your slippers?

Racing simulations might just provide the substitute you’ve been seeking for real track action, whether you’re waiting for spring to get the car back out on the grid, or you just can’t muster the time or budget for the real thing.

You may be thinking, there’s no way a console game can give the feeling of a real track experience. And you wouldn’t be entirely wrong. While racing simulations, or “sims”, are just computer games with cars, they are not like the games you’re accustomed to seeing on the consoles, or even the “arcade” racers like the Electronic Arts Need for Speed series. The best sim racers have sophisticated physics engines based on real-world performance data. Many provide extensive car setup options, creating a predictable and realistic effect on where the car goes and how well it gets there.

These are good days for sim racing. There are more high-quality racing games available market than ever before, and the internet communities that have grown up around these games provide something for everyone, whether it’s joining an online league, downloading (or creating) new tracks, or just talking about cars with other car nuts. So let’s take a look at the best of the current sim racers....

NASCAR Racing 2003

The NASCAR Racing series, created by Papyrus Racing Games, has long been considered the pinnacle of racing sims, providing realistic driving dynamics, beautiful visuals, and setting the benchmark for online racing. The latest version, NASCAR Racing 2003 Season, was created with specific technical input from Jasper Motorsports and Goodyear so that car setup, tire wear, and driving style have the same performance effects in the game as they would in real life.

NASCAR Racing 2003 provides for private testing sessions as well as racing against computer-controlled fields, but the multiplayer racing features are where this sim really shines. The game supports fields of over 40 human opponents, either through a local network or online servers. As you racers know, there’s nothing quite like wheel-to-wheel competition with error-prone, unpredictable, real-life folks to get the adrenalin pumping. But in this case you don’t have to pay for fixing a wrecked car.

Admittedly, Winston… I mean Nextel Cup racing isn’t for everyone. And here’s where the NASCAR Racing story gets interesting: Papyrus recently released a patch that, among other things, adds three additional physics models in the game. These include physics for the NASCAR Busch and Craftsman Truck series [edit: you’d know these as the Nationwide and Camping World Truck series now.], as well a pseudo Trans-Am series. All of these are somewhat limited by the spec-racing nature of NASCAR so, within a series, all of the cars use a single physics model. But each series provides unique and challenging handling characteristics, and the common physics between cars within a given series puts more focus on setup, strategy, and driving skill.

Project Wildfire is a group of artists and developers — many former or current Papyrus staff members — that is creating modifications, or “mods,” that make the Busch, CTS, IROC (based on the Busch physics), and Trans-Am series available to players within NASCAR Racing 2003. This includes the car models, tracks, car paint jobs, and other bits needed to run a realistic version of the series. The Busch, CTS, and IROC mods are complete and can be downloaded from the Project Wildfire web site. A beta version of the Trans-Am series mod is available, unlocking the physics, but still using the Cup car bodies and sounds.

Another group, supported by The US Pits sim racing community, has released a beta version of their Trans-Am mod for NASCAR Racing 2003. The mod is called The Pits Touring Car Challenge (TPTCC). The current version includes car models for Corvettes and Mustangs only. However, some enterprising souls have devised remarkably convincing Team PTG M3 GTR paint schemes for the Mustang, so you can compete as Bill Auberlen, Boris Said, or Hans Stuck.

The combination of graphics, physics, and multiplayer support make the Trans-Am mod for NASCAR Racing 2003 probably the best sim racing experience currently available.

F1 Challenge ‘99-‘02

The Formula One simulations from EA Sports have been getting better and better, and F1 Challenge is probably the best modern F1 driving experience most of us will ever get. This version is actually the end of the road for EA’s F1 sims — Sony recently negotiated an exclusive license to F1 video games and they pretty much pulled out all the stops.

In F1 Challenge, you can sit in for any driver from any team in the series between 1999 and 2002. Obviously that means you can drive a Williams BMW as Ralf, Juan Pablo, or Jensen, but you can also drive a McLaren, Ferrari, Arrows, or Prost if the spirits move you to do so. Changes in chassis, engines, and liveries are recreated for each year, as are changes to the circuits such as revisions to the Rettifilo Tribune chicane at Monza.

Appropriate to the technical sophistication of the series, F1 Challenge offers a dizzying array of chassis-tuning options and telemetry data. If you’ve always wanted to be a grand prix race engineer, here’s your chance. Likewise, there are a bewildering variety of controls to master within the cockpit, so keep the manual within grasp for your first few test sessions. F1 Challenge offers online racing against human opponents as well, but supports fewer online players than NASCAR Racing 2003.

One element that sets F1 Challenge apart from other racing sims is its ability to be customized. As a result, there are a wide range of mods available based on EA’s F1 sims. Historic Touring Car Championship and Aussie V8 Supercars [edit: now an add-on for rFactor.] are currently under development, and a beta version of the V8 Supercars is available.

Bimmer fans can choose from M3 Challenge, BMW World Series, and European Touring Car Championship. Of the three, the ETCC mod is the most polished and interesting. It includes most of the teams and cars driven in this exciting, hotly contested series, and really seems to capture the high-strung character of these cars. The developers also provide many of the tracks run during the ETCC season that aren’t already included in F1 Challenge.

Grand Prix Legends

Long considered the king of racing simulations, Grand Prix Legends recreates glory and danger the 1967 Formula One season — the second year of the 3-liter formula and the first year for Ford’s legendary Cosworth DFV engine. GPL, as it’s known to the initiated, was released by Papyrus back in 1998 and sold poorly due to its steep learning curve and high system requirements.

The cars are very light, very powerful, and run very hard, unforgiving tires. Little wonder few of the legendary drivers from that era survived. GPL features separate physics for each of the seven chassis included in the game: Brabham, BRM, Cooper, Ferrari, Honda, Lotus, and the beautiful AAR Eagle. Each has quirks derived from its real-life performances, meaning the Ferrari sounds wonderful, the Honda and Eagle are delicate, and the Lotus is wicked fast.

In the five years since its release, the game has developed a cult following of amazing proportions. There are photorealistic graphical updates for the cars and tracks, and hundreds of additional tracks have been created by the talented editing community. Since GPL includes an early version of the multiplayer features seen in the NASCAR Racing series, you can race online with up to 20 people through leagues or the popular WinVROC utility. An active community of GPL enthusiasts and extensive links to GPL add-ons and utilities can be found at Race Sim Central.

Live For Speed

Live for Speed is something of an anomaly among racing sims, as it’s being developed and distributed by a small group of independent coders. The game isn’t available in stores. Rather, you download the software and purchase a license from team’s Web site. A free demo is available as well.

Unusual distribution aside, this may be the model for racing sims of the future. Live For Speed may not be quite as polished in some areas as other titles. It also includes a rather funky selection of cars, leaning toward affordable European compacts rather than race-bred supercars. But the chassis dynamics are some of the best available and the game simulates the impression of speed, tire scrub, and body roll in a very believable manner. In addition, Live For Speed provides efficiently designed online racing functionality, though multiplayer grids are limited to 12 cars in the current version.

Rally Trophy

Worthy of mention due to its unique subject matter, Rally Trophy simulates — in very broad strokes — stage rallying in the ‘60s and ‘70s. You can drive classic cars such as the Ford Cortina and Escort, Lancia Fulvia and Stratos, Volvo Amazon, and Opel Kadett. The stages are a bit short, but it’s quite challenging to throw these softly sprung cars around, and each car has its unique quirks.

Half-Price Books seems to have bought up a supply of Rally Trophy and at press time was blowing them out for around $8. You can pick up some excellent updates, including new cars and stages, from No Grip Racing.

Zundfolge, February 2004.

Coder Interviews at the Code Project

I’ve been working with software developers for a long time now, and one thing I learned along the way is that coders are a diverse bunch. That’s one reason why it has been fun and entertaining to launch our A Coder Interview With… series of interviews at the Code Project. We started the series in August 2011 and have been posting a new interview more or less weekly since then.

The big idea behind these interviews is share the stories of working developers who are actively involved in larger coding community — whether that’s the Code Project in particular, open-source projects, or just folks who actively share their knowledge and enthusiasm about programming.

I’d like to acknowledge that The Setup provided much inspiration for this project. I really enjoy the consistent, concise format of these interviews. For Code Project we chose to use a similar set question format, but expand the topic to discuss topics like languages and frameworks of interest, how they learned to program, what advice they’d give to up-and-coming programmers and what they really despise in a codebase.

I heartily recommend reading through these interviews to get a good idea of what tools and techniques working developers are actively using today and the new technologies they’re embracing for tomorrow.

By the way, here are some of our most popular interviews so far:

Chris Maunder, co-founder of The Code Project.

Dave Ward, better known to many of his readers and followers as Encosia.

Sacha Barber, one of The Code Project’s most famous and most prolific members.

John D. Cook of the fascinating blog, The Endeavour.

Phil Haack, former ASP.NET team member, now a Githubber.

There are many other interesting interviews, and we keep adding more. For a taste of the fascinating folks we talk to check out:

Iris Classon, whose 18-month journey from newbie to pro-coder is a true inspiration.

Khaled S. Ali, an actual rocket scientist: he writes the code that controls the Mars rovers.

More are on the way. Stay tuned.

CSS3 Color and Opacity

The CSS3 Color Module much more solid than the other CSS3 proposals and experimental features. In fact, as of June 2011, it’s an official W3C Recommendation. New CSS3 Color features include HSL color specifications in addition to traditional hex and RGB values, as well as the ability to use opacity and gradients.

As a primer for using these new color features, I wrote an article over at The Code Project called CSS3 for Beginners: Color and Opacity. This should get you started. If you find the article helpful, please vote it up and share your thoughts in the article comments.

CSS Box Model Basics

A basic - but often misunderstood - feature of CSS styling is something called the box model, which defines the rectangular space around an element by means of border, margin and padding settings. It’s really very simple, but a combination of poor nomenclature and some subtle rendering rules confuse folks who are new to CSS.

To help you get up to speed with the box model, I wrote an article over at The Code Project called CSS Basics: The Box Model, Margin and Padding. Please check it out and, if you find it helpful, vote it up. I hope you learn something useful.

10 Great Features in 10 Different OSes

If you were making the ultimate operating system, what features would you choose? I’ve been fortunate to use a pretty wide range of OSes over the years — some by choice, others by necessity. Each OS has some nugget that we can enjoy, learn from and build on.

So here, in no particular order, are 10 different features I love in 10 different OSes (Redmondmag.com).

View all of the posts in the archive, browse the tags, or subscribe to the feed for All Posts. You can also subscribe to a feed of just the posts tagged with writing.