Skip to main content

Kimberly Blessing

BlogHer '14: Preserving Your Online Content

4 min read

BlogHer 10th Anniversary Celebration

Earlier this year, I read (and raved about) Book of Ages: The Life and Opinions of Jane Franklin by Jill Lepore. One of the obvious realizations when reading this book is that today we have little first-source material of the average person's life from this era -- and especially little of it from women. It's only because of Jane's famous brother that her writing has survived -- and through that correspondence, we can learn so much.

That seems to be a theme for me, this year: I've been thinking a lot about how we document and preserve information -- stories, photos, videos, etc. -- online, whether for ourselves (ooh, the cloud), to share with family and friends (social media), or for posterity. I was first drawn to the web, 20 years ago, as cheaper means of communication... but like so many others, have realized the wealth of history we're documenting as well. It's important to me that we preserve that history... because, even though we think the Internet never forgets, it does.

So, when the good folks at BlogHer approached me about participating in this year's 10th anniversary conference, I thought this would be the perfect subject to talk about. Except I'm not talking... I'm running a Geek Bar instead! This means that I'll be helping bloggers who are interested in hands-on learning and help on how to preserve their online content. This post is a short summary of some of the material I expect we'll review and resources we'll need to reference, mostly for WordPress users (non-developers). Whether you're at my session or not, you may find this information useful and you're welcome to contribute your own! (I'll update this post later with anything else we cover.)


Backing up your blog

If you're blogging on a free or paid service, learn about what backups they're creating and whether or not you can get access to them. If you're paying for hosting and running your own blog, add a backup subscription service or set up your own backup solution.

  • For WordPress: VaultPress, Backup Buddy, and loads of other plugins.
  • If you're looking for something that will (likely) outlive you, submit your site to the Internet Archive for archiving (via the "save page now" form). Make sure your web page templates or robots.txt do not include NOARCHIVE.

Better broken links

Nobody likes getting a 404 (page not found)... and they're not good for search engines or archiving tools, if you want them to get your content! Help 'em out:

Moving and taking down content

If services go offline, you choose to switch providers or domains, or you simply choose to take content offline, you're going to want folks (and search engines) to know.

  • Familiarize yourself with the HTTP status codes. Here's a quick review of the most relevant ones:
    • 200 OK - this is what you want folks to get, in addition to your content
    • 301 Moved Permanently - if you're moving between services/URLs, you want this to be the redirect type
    • 302 Found or 307 Temporary Redirect - if you're having momentary issues and want to send readers somewhere else for a short time
    • 404 Page Not Found - the one we don't want people to get
    • 410 Gone - what you want to send when you've taken something down and don't ever intend for it to come back
  • If your site runs on Apache, learn about Redirect and Alias directives which you can set in your .htaccess file.
  • Yes, there are WordPress redirect manager plugins, too.

Solutions for all of your online content

What about your Facebook posts, tweets, Instagram pics, and other content on third-party sites? You can save those, too!

Kimberly Blessing

Code Archaeology: Dusting Off the Line Mode Browser

6 min read

Photo of an old IBM computer running the line mode browser, with the explanation page displayedThe line mode browser (LMB) info page, running on the line mode browser.

It's been over a month since I returned from my trip to CERN to participate in the line-mode browser hack days and I'm finally getting my photos and my notes in order. If you haven't read much about the event, Jeremy wrote an excellent summary of the whole experience.

I was on the "coding" team and spent a good deal of time reading through and tracing the logic of the line-mode browser (LMB) source code. It felt like every few minutes I was finding something new or interesting, and pointing it out to the rest of the team, so we could be sure to make note of a feature we needed to implement or something that might be a pitfall. I referred to this work as "code archaeology". Here are some of my more interesting findings:

  • The earliest style sheet (compiled into the browser) had six styles: normal, list, glossary, monospace, address, and heading. (Heading had a further seven nested styles for TITLE and H1-H6.) What changed with each of these styles? Left indent (two levels), right margin, alignment, capitalize states (two, one for each left indent), double spacing, number of blank lines before and number of blank lines after.
  • There's code in place to handle H0 as a heading level. It was mapped to the title heading style -- so if both TITLE and H0 were present, H0 would overwrite what was shown in the TITLE location (at the top right of the screen (see picture).
  • If you've been doing web development for long enough, you'll probably recall the ISINDEX element -- and perhaps, like me, wondered it was supposed to do. If it existed in a page, it added a keyword command to the list of options in the prompt (see picture). It doesn't look like this feature was fully implemented in the LMB -- I don't see any code that would return a list of pages matching the query. In addition, the LMB only recognized ISINDEX if the opening tag was in all caps.
  • Here's an HTML element that was new to most of us: LISTING, which is supposed to render plain text. The LMB code we were looking at had a bug, however: only the opening tag was parsed and any closing </LISTING> tag was left to render in the page (see picture).
  • Another element that we'd never heard of before was HP, for highlighted phrase. HP comes from SGML. It had the effect of forcing text into all caps. The LMB that we reviewed parsed <hp1> and <hp2> only.
  • Because of the way the LMB parses a document, HTML comments (e.g. <!-- -->) are ignored -- even though there were no comments in any of the early HTML documents we reviewed. In fact, any unknown tag is thrown away as a "junk tag", yet its contents (what's between the opening and closing tags) are still rendered to the screen. Thus, a modern web page with a <style> or <script> block would end up showing the user a whole lot of code!

My handwritten notes from my time at CERN My handwritten notes tracing the logic of the LMB, with Tim Berners-Lee's original proposal in the background

I'm not sure that we explicitly discussed it, but it soon became clear that we were building a simulator that we expected could render both current web pages as well as the earliest markup found in the first web site. This led to review of some very old markup, written by Tim Berners-Lee himself, and lots of experimentation with the old IBM system we had with us, which was running the LMB. Some more fun discoveries:

  • The HEAD element doesn't yet appear in HTML -- it would have been parsed out as a "junk tag". That said, in some old HTML documents, you'll find HEADER tags surrounding the TITLE and NEXTID. Fortunately modern browsers handle this old markup pretty well, so we didn't have to code anything special for our simulator.
  • These days, we're used to surrounding paragraphs of text with opening and closing tags... and, back in the day, we just putt hem at the start of paragraphs. Originally <P> tags were used as paragraph separators, to create space between paragraphs. This made the work of writing the simulator CSS, to render both old and new code correctly, a little tricky.
  • The LMB indicated a hyperlink by placing a number in brackets following the link text, e.g. [1]. If your link text was more than one word, it might be confusing or hard to determine what text was part of the hyperlink. That said, the list command would show all of the hyperlinks in a document... but it was only helpful if your URLs were descriptive (see picture). The LMB could be started with flags to disable the showing of hyperlinks, which may have been useful when also running in non-interactive mode -- perhaps when trying to cat contents to files for storage or printing.

You, too, can get the line-mode browser source code and read through the main file (www.c). See what jumps out at you!

As I've expressed before, I'm concerned that many web professionals don't understand the history of the web and thus are doomed to repeat past mistakes. My biggest hope is that anyone who writes code for the web today will spend just a few minutes using the LMB simulator to browse the first web site as well as to check out their own site -- and notice, at the very least, that well-marked up content was and still must be the foundation of the web, in order to have a decent experience, regardless of browser capabilities. Good markup never goes out of style.


Kimberly Blessing

Now we are 36

4 min read

Another year has passed. Now I am 36.

I wanted to have a party this year. I wanted to celebrate the 20th anniversary of my 16th birthday. To me, this sounded like the perfect way of acknowledging how I feel -- older in reality, but still celebrating my youth. But I've just been too busy to make it happen. And there have been more important things for me to worry about than a party for myself.

So instead I'm celebrating by writing this post.

What have I learned this past year?

I've finally realized that overcommitting myself does me no good. A year ago I would've acknowledged that it didn't do anyone else any good, but finally I can see that it does ME no good. I already said no to one opportunity that came my way recently, and it was really hard. But I need to keep saying no to doing for others. I need to keep saying yes to myself. Being selfish is okay.

I also learned that it's easy to get back into good habits, like working out every day -- but it's even easier to let yourself break those good habits because you think you'll go right back to them. I did lose about 8 pounds this year, but I've also gained it back. Once I establish a goal and a set of habits around the goal, I need to stick with it. (Part of that whole "it's okay to be selfish" thing.)

I think I've finally gotten the hang of not needing "stuff". I got rid of one of my cars right before my last birthday, and since July my other car has been in storage. I've been to conferences where I don't take the swag. I've been taking more books out from the library (and realizing that many of them just weren't that interesting). I took about a quarter of my clothes to Goodwill last year and now I'm looking at my closet and thinking about getting rid of half of what's in there. I take more digital pictures of things that are cute or visually appealing, rather than buy them to hang on to. Most significant, perhaps, is that I haven't been able to write a "want list" of any kind. I've learned that I have everything I need. I probably don't need everything I have.

Finally, in the past few months I have come to realize how incredible hard it is to take care of another person. It's a huge mental drain, even when it's not physically draining (which it often is). And managing other people's expectations when it comes to caretaking is probably the hardest part of the whole thing. I've always been a supporter of assisted suicide for the terminally ill, but I think we need to have more conversations about allowing the elderly to choose to leave this Earth in a dignified manner of their choosing.

What have I achieved in the past year?

One goal that I've stuck with for a few years is getting out of debt. When I got laid off in 2008 I established a set of financial habits that I have successfully maintained. I won't give specific numbers, but I will say that I now have more money saved as an emergency fund than I owe on all of my credit cards. In fact, I will be out of credit card debt by October! I check the numbers carefully every month (actually, daily), because part of me still can't believe it will happen -- but the other half of me doesn't quite know what to do with the free time I'll have soon, once I'm done obsessing about getting out of debt! I hope I can channel it towards my health goals.

Other "achievements" from this past year have weighed heavily on me, because I was giving too much of myself to make those things happen. So, in my mind, I've only achieved stressing myself out, which isn't all that great of an achievement.

Favorite experiences from the past year

  • Finding my old friend, Rose, and being able to tell her how much she influenced my life
  • Seeing the re-formed (reformed?) Revolting Cocks perform in Chicago
  • Running 5 kilometers with no pain, and actually enjoying the run
  • Waking up to my cat pawing me (her new-ish thing, so that I get up early to feed her)
  • Getting up early on a Sunday morning to drive to the shore for pancakes with Scott

What I'm looking forward to in the year ahead

  • Getting out of debt!
  • Completing two back-to-back terms on the Bryn Mawr College Alumnae Association Executive Board
  • Losing 10 pounds
  • Figuring out what I want to do when I grow up

I think that's pretty good for one year. Happy birthday to me.

Kimberly Blessing

Web Developer Job Search: Your Resume

6 min read

I estimate that I have spent a full work-week, over the course of my career, reviewing web developer resumes. That's enough time to produce some strong opinions on the topic. Allow me to finally continue the Job Search thread by sharing my advice for creating a top-notch web developer resume.

Resume Format and Structure

Your resume format should work to highlight your strengths. The chronological resume, perhaps the most traditional format, fails in this regard. A functional resume does a much better job of highlighting your experience in a specific role, but most web developers are good at more than one thing. I suggest mixing aspects of the two formats, organizing them in a way that makes sense for you and your strengths -- then you'll have a resume that stands out.

Here are the general sections found in a great web developer resume. With the exception of the first two, the rest can be ordered and/or further broken out according to your needs.

  • Objective: If you're searching for a job, you ought to know what you're seeking! Customize your objective, as needed, when replying to job postings. (Note: If you're not actively seeking a job, but still want to have a resume posted online, it's okay to omit this section.)
  • Summary of Qualifications: It's a cheesy headline, perhaps, and all too often the summary is filled with buzzwords -- but I have read really compelling summaries that made me want to know more about a candidate. Focus on describing your strengths and what you contribute to an organization.
  • Skills: This is where the keywords and buzzwords will start showing up. That's okay: you'll back them up with evidence in the other sections. You can subdivide this section in any number of ways: Technical vs. Soft Skills, Front-End vs. Back-End Skills, Design vs. Development Skills, etc.
  • Professional Accomplishments: Here you can include project accomplishments, awards, public speaking engagements, publishing credits, or descriptions of really awesome things you've accomplished. Like the Skills section, you can also break these out separately.
  • Work Experience: If you've done any combination of full-time work, freelancing, and volunteering, this is the most generic title you can use for your work history. Some people like to break out their professional experience from other work, but I think that can undermine the importance of having taken on freelance or volunteer work. If you list accomplishments for each job in this section, don't repeat them elsewhere, and vice versa.
  • Education: I don't like to see this section missing from a resume. Haven't gone to college? That's okay. Be proud of what schooling you have made it through and list it here. Oh, and that includes training programs, conferences -- anything you've forked out money for that you've learned something from!

Required Information

If your resume were to consist of only two things, it should be these:

  • Contact Information: You'd think this would be a no-brainer, but I have seen resumes where developers didn't list a phone number, email address, or personal web site (more on that below). In my opinion, it's a waste of space to display your full home address, especially if you are looking to relocate. No one's going to snail-mail you an invitation to interview, so city and state will suffice. HR will collect the rest of your contact information later.
  • URLs: I wish I could tell you exactly how many of those ~500 resumes didn't include a single URL... but my gut says that at least half didn't feature even a personal web site URL. Seriously? If you're a web developer, you should have some URLs to share. If you're brand-new to the field, put some of your school projects online. If you've only ever done intranet-type work, get permission to copy parts of the code and make it available, or create other projects of your own to demonstrate your skills. If you're serious about getting a web development job, you need this.

On the flip side, don't waste space on these bits of information: references (or the phrase, "References available upon request"), GPA, salary requirements, or personal information (except if you have hobbies that would be of interest to another geek and would increase the likelihood of getting invited in for an interview).

Frequently Asked Questions

Does my resume have to fit on to one or two pages? No, I don't think that it does. However, I think it's nice if a resume is so well edited and structured that, when printed, it fits to exactly one or two pages (one page if you're young, recently out of school, or switching careers; otherwise two pages). However, if you truly have so much awesomeness to report, then, by all means, go on! If you're really that super-duper, I'm sure I'll want to know all about it.

Does one resume fit all jobs? NO! Don't be afraid to tweak your resume format or content to the job you're applying for. In fact, if you have diverse enough skills and interests (design vs. development) you should probably have completely separate resumes for these purposes.

I am graduating soon and don't have much web development experience. What can I do to beef-up my resume? Use the "Objective" area to make it clear that you're looking for an entry-level position. Highlight your strengths in the "Summary of Qualifications" area and place the "Education" section next, so it's clear you're just coming out of school. List your technical skills, as well as any soft skills that you can support with extra-curricular or volunteer work. If you have been active in a tech community or have attended technical or web conferences, list those.

I'm switching careers. I've taken some web design and development courses and done some small projects. How do I reflect all of this in my resume? First, don't hide the fact that you're switching careers! Your prior experience, even if in a completely different industry, has (hopefully) taught you how to deal with people and has helped you understand your strengths. Start your resume with an "Objective" statement that spells out your desire to move into web development. Then list your skills, training and experience with the web so far before providing your employment history and other educational details. Highlight any experience that translates across industries, but otherwise keep the non-web details short.


I hope the above helps you create an awesome resume. Remember, your resume (supported with at least one awesome URL) helps get you in the door for an interview, so take some time to craft one that truly reflects you!

If you have questions I haven't addressed above, I'm happy to accept them in the comments below.

Kimberly Blessing

Pausing for a new year reflection

3 min read

Reflection, by Kimberly Blessing

Since my last real post here, over four months ago, I've been asked countless times why I don't blog more. I've received numerous emails from people who've thanked me for the advice I've offered here, and I can tell from the stats that people are still visiting. Don't worry -- I haven't given up on the blog, and I get that you're still interested in what I have to say. To which I can only say, thank you! I will get back to posting soon. But let me update you on some changes in my world.

Last month I transitioned into a new role at CIM: that of senior software architect, focused on web front-end engineering. It's exciting and it's scary, as any change is. I've put a lot of time and effort into developing my management and leadership skills and changing some bad behaviors, but I don't think any of that will go to waste in this new role. One becomes a software architect, in part, because of one's leadership skills, and having experienced managing some of the people I'll continue to work with only gives me greater insight into their talents and strengths, so I can help them accomplish more. From a technical skills perspective, while I've kept up on HTML, CSS, and browsers, there are a whole host of languages and technologies I need to brush up on or get acquainted with. I don't need to be the expert on everything, but I do need to hold my own in conversations with Java programmers, system administrators, and even other front-end developers. Most importantly, though, I need to buckle down and write more, so that my thoughts, research, ideas, and questions are available both to myself and others. As you, dear reader, can probably tell, sitting down and making myself write out my thoughts is not one of my strengths!

I will also be busy these next few months teaching a web application design and development class at Bryn Mawr College. I first had the opportunity to teach this "recent topics" computer science class at the end of 2008, and it was popular enough that the students asked the department chair to bring me back! I'm honored that every space in the class is full, and I hope to challenge both the students and myself by looking more into creating single web experiences which adapt nicely to the mobile environment. I am still thinking about whether I will re-present or make available the course materials to a broader audience, online.

I'm also preparing to present at some conferences this year and I'm working on a few other projects. I joked, on Twitter, that my theme word for 2011 should be "over-committed" and that's definitely true. So the mantra I'm repeating to myself is one I recently got in a fortune cookie:

You cannot be anything if you want to be everything.

A good reminder to all of us. Happy new year!

Kimberly Blessing

More thoughts on gender in the Web world

4 min read

Wow. This whole gender diversity thing really took off, but I wonder if it'll continue, or if it's dying. If you haven't gotten in on it yet, read Virginia DeBolt's summary at BlogHer. Some opinions I've enjoyed on this topic come from:

I also thought more about Eric Meyer's comment about publishing, and it took me back to the publish or perish concerns that many scientists and researchers have. Am I a woman scientist? pointed to this paper, which, while relating to the biological sciences, reiterates what I've learned about academic paper publishing both in general and in the computer science field.

There is a clear difference between men and women in science with regard to the quantity of their research output. On average, males publish more papers than their female counterparts, a trend that is consistent across scientific disciplines and exists even when obvious mitigating factors are taken into consideration. The causes of this difference are mysterious ... However, it may also be a consequence of social factors.

I believe that all of the above is true of publishing in the Web world.

The study also goes on to state that while women produce fewer papers, their papers are generally rated as being of better quality than those produced by men, and are more often cited in other research. I don't want to extrapolate this particular statement and apply it to the Web world, but it's something to think about.

Getting back to quantity, however... if the bulk of publications are produced by men, one might assume that the tendency to publish is more male than female. And thus arises another concern that I have -- that, in order for women to gain more prominence in our field, we're expecting them to behave like men. Is this fair? Is it right?

Robert Scoble said on Shelley's blog that one has to learn to beg [for links] via email and/or face-to-face meetings... men do this far far more often than women do. I also took issue with this, because, again, the expectation is that women should do what men do to get noticed.

I know it's been done already, but I'll again ask all of the people involved in this ongoing conversation to to stop and think not about what women can do to get noticed or be seen as an expert, but what they can do to help identify, encourage, and support women. The confidence to ask for links or the opportunity to publish or speak may need to be socialized more with women first -- you can't just expect them to be told to do something in order to see change.

And I'll ask the women out there to think about what we can be doing to help raise awareness of what we do as individuals, about what we contribute to the field, and how we should be promoting these things to the industry. What can we do to promote opportunities to contribute, what opportunities can we create for ourselves, and how do we foster this ongoing dialog?

While it was a man who helped to reignite this discussion, I ultimately think that women need to own it. I don't want to say that we've all been happy to take a back seat and be content with what we've got, because I know that's not true... but unless we continue to fuel this discussion, and unless we take ownership of steering it and educating others, we won't see many gains made.