Home >  Archive >  2010 >  June >  30

Previous / Next

Christmas Tree
This site contributes to the scripting.com community river.
About the author

A picture named daveTiny.jpgDave Winer, 56, is a visiting scholar at NYU's Arthur L. Carter Journalism Institute and editor of the Scripting News weblog. He pioneered the development of weblogs, syndication (RSS), podcasting, outlining, and web content management software; former contributing editor at Wired Magazine, research fellow at Harvard Law School, entrepreneur, and investor in web media companies. A native New Yorker, he received a Master's in Computer Science from the University of Wisconsin, a Bachelor's in Mathematics from Tulane University and currently lives in New York City.

"The protoblogger." - NY Times.

"The father of modern-day content distribution." - PC World.

"Dave was in a hurry. He had big ideas." -- Harvard.

"Dave Winer is one of the most important figures in the evolution of online media." -- Nieman Journalism Lab.

10 inventors of Internet technologies you may not have heard of. -- Royal Pingdom.

One of BusinessWeek's 25 Most Influential People on the Web.

"Helped popularize blogging, podcasting and RSS." - Time.

"The father of blogging and RSS." - BBC.

"RSS was born in 1997 out of the confluence of Dave Winer's 'Really Simple Syndication' technology, used to push out blog updates, and Netscape's 'Rich Site Summary', which allowed users to create custom Netscape home pages with regularly updated data flows." - Tim O'Reilly.

8/2/11: Who I Am.

Contact me

scriptingnews1mail at gmail dot com.

Facebook

Twitter

Friendfeed

My sites
Recent stories

Recent links

My 40 most-recent links, ranked by number of clicks.

My bike

People are always asking about my bike.

A picture named bikesmall.jpg

Here's a picture.

Calendar

June 2010
Sun
Mon
Tue
Wed
Thu
Fri
Sat
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
 

May   Jul

Warning!

A picture named warning.gif

FYI: You're soaking in it. :-)


A picture named xmlMini.gif
Dave Winer's weblog, started in April 1997, bootstrapped the blogging revolution.

Why people buy iPhones Permalink.

BTW, I lined up to buy an iPhone 4 on the first day.

"I don't care."

Writing good bug reports Permalink.

A picture named sneakers.jpgThe other day I wrote about the Zen of being a tester of a new piece of software. Be patient. It's a long journey. The bugs are there for a reason, it's best to assume they will always be there then you will be surprised and delighted in the unlikely event that one of them goes away.

Today we get a little bit more pragmatic.

You've been asked to test the software because the people who are writing it would like your help to make it better. They want to fix bugs, and the easier you make it for them, the more likely it is they will be able to. Sometimes people produce bug reports that are so insightful they lead the programmer right to the mistake in the code.

The basic information a bug report should contain is this:

1. What you were doing.

2. What you expected to happen.

3. What actually happened.

All three parts are very important. If you really did discover a bug, the programmer will need to know what you were doing so he or she can try to reproduce it. If they can't, it will be next to impossible to fix it.

The second part helps nail down the first part. Usually people know what they were expecting. Also, it's possible that what you were expecting isn't what the software does. An extreme example: "I was expecting that when I pressed the blue button at the bottom of the screen I would be granted three wishes."

For the third part a screen shot can help. It may contain information that's meaningful to the programmer that you wouldn't think to include in your report.

Another way to help the programmer is to say if the problem is or isn't reproducible. That is, if you try step #1 again, do you get the results in step #3? By trying to reproduce it you may add important information to the first part of the report.

PS: All bugs are reproducible, that's almost the definition of a bug.

PPS: Another howto re bug reports.

Testing notes Permalink.

Doing some testing with Scripting2 this morning.

1. There have been some reports of duplicate posts. I think this happens when you, perhaps accidentally, click the Save button more than once the first time you're saving the post. The reason this is a problem is that there's invisible metadata stored on the "summit" of the post, the line that holds the title. One of the bits of data is the ID of the post. The first time you save there is no ID, that's the cue to the server to create a new post to store the text. If you click it twice, normally that's not a problem -- it just saves the post twice. But could be a problem the first time.

The simplest way to deal with this is to have the button wait until the save is complete. I've been doing it in a separate thread, mostly for esthetic reasons (if I remember correctly). I'll try not doing it in a thread.

My theory is wrong in every respect. I have a duplicate post myself and I surely didn't hit the Save button too rapidly. I have years of training, and in all that time this has never happened. So the obvious answer is there is a bug in the server side that creates duplicate posts. Or something like that.

2. How to insert a hyperlink. The right-click menu in the outliner offers a way to create a link node. See the OPML 2.0 spec for an idea what that is. That usually isn't what users want -- they want to hot-up a bit of text with an address. That's what the Add Link command in the HTML menu is for. First, put the URL on the clipboard. Then select the text you want to link from. Then choose Add Link from the HTML menu.

Testing notes Permalink.

Doing some testing with Scripting2 this morning.

1. There have been some reports of duplicate posts. I think this happens when you, perhaps accidentally, click the Save button more than once the first time you're saving the post. The reason this is a problem is that there's invisible metadata stored on the "summit" of the post, the line that holds the title. One of the bits of data is the ID of the post. The first time you save there is no ID, that's the cue to the server to create a new post to store the text. If you click it twice, normally that's not a problem -- it just saves the post twice. But could be a problem the first time.

There are two approaches I could take. I'm going to do an experiment now to see which one I'll try.



© Copyright 1997-2011 Dave Winer. Last build: 12/12/2011; 1:42:28 PM. "It's even worse than it appears."

RSS feed for Scripting News


Previous / Next