 |
Monday, January 05, 2004 |
Blogging and RSS — The "What's It?" and "How To" of Powerful New Web Tools for Educators. Yet another cool intro to blogging and RSS for educators article from the prolific Will Richardson.
QUOTE The
internet has long been valued by teachers and librarians as a powerful
research and communications tool, and in the last 10 years, it has
brought about a sea change in the way students find, manage, and use
information. But the promise of the Web as more than just a readable,
searchable resource has been slow to be realized ... until now. Two new
Internet technologies, Weblogs and RSS (Real Simple Syndication), are
redefining the way students and teachers use the Internet, turning them
from mere readers into writers to the Web as well, and making it easier
to filter and track the ever-growing number of resources coming online
each day. In fast-growing numbers, educators across the country and
throughout the world are finding just how powerful this new interactive
Internet can be.
Weblogs, or "blogs," as they are called, can best be defined as Web
sites that are easily created and updated by those with even a minimum
of technology know-how. What used to be a messy process for Internet
publishing is now almost as easy as sending e-mail; no code, no file
transfer, and in many cases, no hosting setup. Just login to your site
from any Internet connection, enter the content in a typical Internet
form, press a button, and your Weblog is updated. And it's not just
text. Blogs can display pictures and video, include audio and Flash,
and even store other files like PowerPoint presentations or Excel
spreadsheets for linking.
UNQUOTE [Roland Tanglao's Weblog] 
|
|
Content Feeds with RSS 2.0. (SOURCE:Content feeds with RSS 2.0)- Excellent QUOTE
A lot has happened in the RSS world since developerWorks
last looked at RSS: Two new specifications have come out, RSS has
become one of the most popular XML standards, and tools and feeds are
popping up everywhere. RSS has contributed to the explosion of weblogs,
and it is becoming a standard part of other Web sites, too. This
article reviews RSS 2.0, looks at new RSS developments, and jump-starts
your understanding of this important format.
It's been three years since I wrote my last article on RSS for developerWorks, "An introduction to RSS news feeds."
At that time, RSS was one of the more popular uses for XML. Since then,
Netscape abandoned the format, five (count 'em, five) new versions of
the RSS spec have come out, and there was an acrimonious fork in the
format.
In spite of these setbacks, RSS is now more popular than ever.
UNQUOTE [Roland Tanglao's Weblog]
|
|
Re-design done for now. The re-design is done for now. I plan on tweaking this further though!
Some notes:
- Minor bug in Scoble's code.
Relative URLs for the stylesheet don't work in categories. I fixed it
by putting an absolute URL. Other than that, the code is minimalist and
fast loading. Thanks again Robert!
UserLand's comment server is
over-loaded and slow and causes my blog to load much slower than it
could. Hopefully this will get better with the new management team at UserLand. If not, I may run my own comment server or investigate other solutions someday when I have some free time.
- Removed the links to a Google Search on the text of the title. Cool hack but I doubt anybody used it.
- Removed k-collector.
Awesome concept but it's too slow to enter both categories and
k-collector topics. If the k-collector topics were integrated into
NetNewsWire or into the Radio post form, I'd use it.
- Removed activeRenderer.
It's awesome, but it slows down the rendering speed of my blog. Seems
like the browser's waiting for the entire blog to be loaded before
being "activeRender-ed".
- Need to add my picture back.
[Roland Tanglao's Weblog]
|
|
Mars moblog: amazing photos beamed home from NASA Spirit. 
Now
*that* is a photoblog. Chronologically indexed gallery of
interplanetary snapshots from this weekend's Mars landing. The first
images sent back are of limited quality -- and only in black and white
-- because data transmission rate from Spirit's antenna back to Earth
is limited. Higher-res color images are expected to be relayed back
from the orbiting Mars Global Surveyor and Mars Odyssey Spacecraft
later today, according to Mission Control. At left:
"This mosaic image taken by the navigation camera on the Mars
Exploration Rover Spirit has been further processed, resulting in a
significantly improved 360 degree panoramic view of the rover on the
surface of Mars."
Link to NASA's Mars moblog, link to full-size, 360-degree composite panorama image. Link to AP
story with details on how NASA's coping with bursting web traffic for
the online images (= 1300 web servers around the world!). (Thanks, Warren)
[Boing Boing Blog]
|
|
The challenges of synching. I predicted the other day
that synching would appear in lots of newsreaders in 2004. (Some have
it already, yes, but they don’t have it as I’ve defined it below.)
A good question would be: why isn’t synching already a feature of every
newsreader already? It can’t be that hard, right—just read and write
from a file somewhere that two copies of your newsreader can access.
I mean, what’s the hold-up? You just need something like a .newsrc. No
big deal, it’s an old problem that’s been solved many times before.
Okay, so the rest of this post will be about the challenges in implementing synching. What is synching?
First we need to define what synching is. It’s really a collection of features and requirements.
1. It’s merging, not cloning, of subscription lists.
2. It also synchs read/unread states of individual items.
3. Your newsreader uploads and downloads your synch data so you don’t
have to do it manually with a browser or FTP client or whatever.
4. Your newsreader knows (or at least guesses) when it needs to download and upload synch data.
5. It works between different newsreader software on different operating systems.
I’ll take these one at a time. Merging
Cloning is easy, merging is hard—but synching has to be merging.
For instance, imagine you have a newsreader at home and one at work.
You subscribe to the same feeds—except that at work you also subscribe
to some at-work-only feeds that you can’t get at home.
So when you get into work in the morning, you want to synch your data
from last night at home. If it’s just cloning your subscription list,
then the additional at-work-only feeds would get deleted, since you
aren’t subscribed to them at home. Since we’re merging, not cloning,
your at-work-only feeds do not get deleted.
But this leads to an interesting problem: what happens if you
unsubscribe from a feed at home? The synching mechanism won’t delete it
from your work subscription list, because for all it knows that feed
could be a work-only feed.
And there’s another entire set of problems that come up because for
most newsreaders the subscription list is an outline rather than a flat
list. Merging hierarchies is far more difficult than merging flat lists. Synching read/unread states of news itemsThis is possibly the toughest of the challenges.
In an ideal world, you can identify every item in an RSS feed with a
unique id of some sort. So the synch data would be able to pair a
unique ID with its read/unread status.
But not all versions of RSS have the concept of a unique ID. And, even
in the versions that do have unique IDs, they’re not mandatory, and
lots of feeds don’t use them. (And sometimes feeds have a terrible bug:
they have unique IDs that aren’t actually unique.)
So, in the absence of a unique ID, how do you identify an item in a way
that will work every single time? Answer: you can’t. There is no
solution that will work every single time. (And this is why sometimes
you notice in your newsreader items that are unread that you know
you’ve read. They’ve been edited.)
Even if you include an entire item, all its text and links and various
elements, it’s possible that the item was edited between leaving home
and arriving at work.
So instead the synching has to do the best it can. Any format will
probably use links and titles and whatever else so newsreaders can do a
best guess. (I suspect that most developers hate situations like this,
by the way, and it may be the single biggest reason why synching isn’t
yet universal among newsreaders.)
Uploading and downloading
You’ll want to tell your newsreader where to save your synch data so you can get it at home and at work.
You
might say, why not use .Mac? Because not everyone has an account.
Because your newsreader at work might be on Windows. (And there are
some other technical reasons which I’ll skip.)
Why not use FTP? Or HTTP-upload? Or...?
The answer is probably that a couple different methods may need to be
made available. (FTP and HTTP-upload seem like obvious candidates, but
I’m just guessing.)
But here’s the deal: I doubt that every newsreader already includes
code for uploading files by the various methods people will want to
use. Sure, there are libraries available, but newsreader developers
will still have to write code and do a bunch of testing. Even a
seemingly small thing like this still takes time and effort.
Knowing when to upload and downloadThis may be the easiest part.
When
you launch your newsreader, it can ask if you want it to synch. It
would then download your synch data from wherever and do the synch.
Similarly, when you quit, it could ask if you want to upload your synch data.
There may be more sophisticated algorithms that would make sense too, but the above is I think a good minimum.
Different newsreaders, different operating systemsThis
means getting a bunch of developers to agree on a format for synch
data. That’s probably the easy part—the hard part will be testing to
make sure X can synch with Y and Y can synch with Z and Z can synch
with X.
That, by the way, is where you come in. [inessential.com]
|
|
Economy: Peter Drucker drops the ball. Fortune (sub only). Peter Drucker
is great, I typically love his insightful analysis. However he was dead
wrong in a recent Fortune interview. In the interview, Peter claims
that job losses due to offshoring don't matter because so few
industries are impacted. He reasons that only jobs that build products
where over 20% of the total cost to produce it are labor costs, are
vulnerable. Further, he adds: these jobs typically don't matter since
they are low paying (like textiles). My response: What about software?
What about all knowledge worker tasks from accounting to xyz? Not well
reasoned Peter, you can do better. [John Robb's Weblog]
|
|
RSS vs. HTML. Ken Camp takes on my claim that RSS is more productive than HTML (more in my comments here).
Standard refrain that evangelists hear. "Prove it's better." Roger Karraker got it in the 1980s. No different today.
Ken's right. It's arrogant of me to tell everyone that RSS is better
for him than HTML. But, what the heck, evangelists have to be arrogant,
no? Think Roger Karraker wasn't arrogant when he brought a Kaypro into
his classroom and said "this is how journalism will be done?"
Anyway, I've identified several things that RSS does better than HTML. Here they are:
1) RSS is faster to display. Why is this? Well, HTML (er,
your web browser) needs to call a Web server. Wait for it to respond.
Then wait for it to send its stream of HTML. Then wait for it to
display what it gets. On some weblogs that process can take as long as
1.5 minutes!!! Yeah, mine is faster, but only cause I've tried to
optimize it a bit. Most webloggers don't know what CSS is. Or what
optimization is. Or, even, what HTML is.
2) With RSS I only need to read one out of 10 sites. Why is
that? Because with a web browser you need to visit every single site.
With RSS you only read the sites that have changed since the last time
you've read the feed.
3) RSS is faster to read. Why is this? Well, if you visit my
weblog in a web browser, how do you know what's new? You need to look
at the dates. Now, what about a page like http://msdn.microsoft.com.
Quick, tell me what's changed in the past 24 hours. In the past week.
In the past month. With RSS I INSTANTLY know what has changed since the
last time I visited.
4) RSS is more efficient to read. Most RSS feeds only give
you the content. Not the advertising. Not the color banners. Not the
crappy links. Not the weird fonts. Not the bizarre color background.
5) RSS lets you escape the browser. Maybe the browser isn't
where you want to read. Maybe you like Outlook better. Maybe you like a
Mac OSX app that Brent Simmons wrote. Maybe you wrote your own app on
Linux. RSS is XML, which lets you programmatically import it and deal
with it anywhere you want (Howard Dean's supporters wrote a little RSS
app, for instance, that gives Windows users a little "toast" alert at
the bottom of the screen - far nicer than if that same app were forced
to use a web browser).
Now, where does RSS go wrong?
1) Many feeds don't give you all the content. So, this forces you to use a Web browser, with all the problems therein.
2) Many feeds don't give you images, or other features on the web page (some don't include comments, for instance).
3) If a web site is more of an application (like, say, eBay) than
just delivering words, then RSS is not as good a solution as visiting
in a browser (not saying RSS doesn't have a part to play here, just
that to order a book off of Amazon, or order something on eBay, you'll
need to visit a web site, not an RSS Feed).
Anything I've missed? I'm having a bit of merlot, so have probably missed something. [The Scobleizer Weblog]
|
|
RSS can bring 10x improvement to your productivity. One
last thing. What's funny is I've spent a bit of time making my weblog
more efficient for the folks who read my blog via a Web browser. What's
really weird is that people are still using browsers to read blogs at
all.
Why do I say that? Because if you read my blog via an RSS News
Aggregator, it's at least 10 times faster to read there than to read
via a Web browser. How do I know that? I have been timing how long it
takes to read an RSS feed vs. reading the same thing in the browser.
There is at least a 10x difference.
So, if you're reading this via a browser, you're wasting your time. Thought you'd like to know.
How significant is this? I now read more than 600 RSS feeds in less than an hour.
Here's a good article on blogging and RSS (from an educator's standpoint). [The Scobleizer Weblog]
|
|
Partners like Neil are FANTASTIC!. Occassionally I get a comment that I think just needs to be on the front page here. This is one of those times. Here's Neil Cowburn's comment (from this thread about open source) in full:
I read the comments about and felt I had to add my own two pennies worth. I'm
one of the co-founders of an open source software house that develops
against the .NET Compact Framework. OpenNETCF.org was formed a couple
of months after the official release of the .NET Compact Framework and
since then has grown trememdously over the past 8 months or so. Our
bread and butter is to fill the API space left by Microsoft. Initially,
we did this by releasing individual UI controls and class libraries via
our web site. That has amassed us more than 25,000 downloads so far.
Now we're currently beta testing our own framework that compliments the
.NET Compact Framework. The support we get from our
peers and from Microsoft is immeasurable. In fact, we owe Microsoft a
huge debt of gratitude for being enthusiastic about OpenNETCF.org. We
even got mentioned by one particular Microsoft speaker at the PDC
during one of his presentations. That was definitely a Keanu
Reeves-style "Whoa!" moment for me. Our team consists
mainly of MVPs who are dedicated to the platform we develop for and we
don't mind giving up some of their free time to help make the adoption
path for the .NET Compact Framework a little smoother. We work hard on
producing the best code we can -- all for free -- not so that Microsoft
can make more money (like the .NET Framework, the .NET Compact
Framework is free), but so that will see the possibilities of the
platform and become as enthused by it as we are. We want to see
Microsoft succeed with the .NET Compact Framework. We will do whatever
we can to help Microsoft to achieve this goal. We don't ask for money.
We don't ask for recognition). We code because we want to. It's what
gets us out of bed in a morning. As a side note, we all have day jobs. Most of us are work with Mobility day in, day out. Such is our love for what we do. [The Scobleizer Weblog]
|
|
Weblog Optimization Comparison. Want
to see the difference weblog optimization makes? Open my weblog and
then compare the time it takes to open it when compared with Sean and Scott's weblog,
which also is done in Radio UserLand. Now, look at their code. First
off, they have indents in their code that are done with spaces. Get rid
of the indents and you save 5% or more on file sizes. Then, look at all
the MS Office stuff.
Is optimization important for weblogs? You be the judge. [The Scobleizer Weblog]
|
|
© Copyright 2004 William J. Maya.
|
|
|
