What makes Parakey different from Desktop.com and WebOS, two companies that looked like they had a decent future during the internet bubble? Desktop.com had a full operating system inside Netscape 4.5 and IE 4. You could share file, folders, etc. with your friends, use online "AJAX" applications, etc. WebOS had a very slick interface, too.
At Desktop.com, we had a couple of problems making the product fly. The first was technical: it bloated the browser up to 32Megs and made it unstable. (Nowadays, I don't bat an eye when Firefox is hungrily consuming 250M.) The second was usability: the online experience just wasn't as smooth and easy as a local application. This was partly due to the lower connection speeds that people were using back then, but also due to the inability to seamlessly interact with local files. And the really big problem was the business model: you either have to charge the users, or figure out how to put ads somewhere where people aren't used to ads -- like in the application title bar. Ick.
So, "one interface, not two" is all fine and dandy, but I'll be interested in seeing if they actually make it work and worthwhile.
I live outside the US and I bought a subscription to Audible precisely because I could no longer get my NPR fix in the car every day. I also have a pretty long commute (40 minutes at best, 3 hours when there are demonstrators closing the bridges) and the available radio sucks.
Everything was fine until NPR decided to cut off Audible because they wanted to experiment with podcasting[1]. Podcasting is fine with me, but they waited six months before getting something online -- and what they put up was "Most E-Mailed Stories". I don't want the most fucking e-mailed stories, I want "All Things Considered"!
Anyway, this really got me pissed off at NPR. Here I was actually paying them (through Audible) and they went and cut me off.
Bastards.
[1] Here's the response I got from Audible Customer Service:
Response (Rob Denuto) 06/08/2005 05:56 PM
Thanks for contacting Audible, the world's largest online destination for downloadable audiobooks and other spoken-word entertainment.
We do apologize for the inconvenience, but unfortunately NPR has decided not to renew its contract with us to carry those particular shows. We do have a vast array of other monthly subscriptions available. They can all be found under the Periodicals & Radio category.
If you need further assistance, please try our online Help Center, where you'll find quick answers to many common questions and issues. You may also contact us directly during our regular business hours: Monday through Friday, 9 a.m. to 9 p.m.; and Saturday, 10 a.m. to 6 p.m. Eastern Standard Time. (Should you need to reply to this e-mail with additional comments or questions, please include the text of this message.)
We appreciate your interest in Audible, and wish you many hours of great listening.
I have had (am having) the displeasure of being part of a pilot project for an in-house MDA utility based on Rose and Eclipse. In a nutshell: it sucks.
There are two general problems that I've encountered:
Poor granularity
Crappy tools
The granularity problem is that you have to spend a lot of time specifying fine-grained details in the model that are more easily expressed in code. Examples are: method calls, persistence, behavior parameters, etc. Often these details don't even show up on the screen. This makes them almost useless for someone trying to understand what is going on. This is a big problem and not going away.
The tool problem is that if the tools don't help you work effectively, the whole process fails. Using Rose is like sticking pins under your toenails and kicking a wall. Rose seems to get in your way on purpose with a hideous interface. Sure, this problem is tool-related, but its impact is huge. It can turn what should be simple into a marathon of pain.
So far, we've spent weeks on a toy application that should have taken two days. Perhaps these in-house tools will evolve to the point of usability, but somehow I doubt it.
I think it's interesting to note that AJAX and online desktops were presaged by Desktop.com in 1999-2000. I worked there, so I can say with authority that we did have a full web-based operating system going in Netscape 4 and IE 4. The stuff that's done now isn't as complex as the stuff we had, in general, though recently (GTalk through GMail, for example) it's started coming close. (I admit I haven't been following some of the other sites mentioned, so maybe some other folks are further along.)
We ran into a couple of killer problems:
* Browser instability -- we had no control over this. Netscape lasted on average 10-15 minutes and ate tons of memory. IE lasted longer, but also consumed memory until it crashed.
* Slow connections -- we had a good 500K download at first connection (or empty cache), which was *slow* over dailup, which was the norm.
* Apps -- nobody is going to come if the apps aren't there. In the day, even making a notepad clone was difficult because native HTML controls were always on top.
The first two of these problems have been/are being slowly overcome. The third one is still a problem.
But the problem of privacy has never really been foremost in the minds of users. Maybe it will be, but with everyone using web mail, I'm kinda doubtful.
I just copy the whole workspace, then delete (or omit in the first place) the projects I don't want. This works really well if you have to work on two CVS branches at the same time.
You can try exporting preferences, but this has never worked to my satisfaction. Throw in badly-behaved plugins (like Jalopy) and all hope is lost.
Copy the whole workspace -- it's the only way to be sure.
Desktop.com had this stuff in 1999, but unfortunately the browsers of the day (IE4 and Netscape 4) weren't really capable of staying up long enough to make it worthwhile. There was even a company that had a nice little web-based spreahsheet app.
Still, I haven't seen a good, platform-independant, integrated sever- and client-side solution yet. Back at Desktop in was *all* client side except the actual persistence of objects so it wasn't really an issue.
Yahoo! just seems to be agregating shows that already exist. They do not have whole NPR shows, just the crappy podcasts that are already available from the NPR site.
I'm still pissed that NPR abandonded Audible.com with no backup plan. I mean, what the hell? Who had the brilliant idea?
"I know, let's turn of this service that is generating a revenue stream and replace it with... ground seashells and sand! I wonder if anyone will notice."
We use McCabe (http://www.mccabe.com/) to point us to problem code. Running their tool gives you a good idea of where the complexity of an application lies and where you should focus your testing.
It works kinda like this: First the tool parses everything and generates a ton of metrics. This will point you to the complex modules of the application. Then it breaks down each function/method in the module into its possible execution paths and turns this into a graph. By looking at the graph, you can see what you need to do to get your test to follow a particular path.
McCabe also tells you how many test cases you'll net to completely test a give block of code. It assumes, however, that all of the tests are independent, which is not always the case.
On the down side, McCabe is big, expensive, and sometimes returns unreliable data. But it's a lot better than nothing.
If you're looking for free tools, look for things that calculate "cyclomatic complexity". This is the measure of the number of paths through a given block of code. Armed with that, you should be able to make some headway.
I don't think that's entirely a fair statement. I find that being able to visualize a codebase can help significantly -- even when it is a mess.
Where I work we have some home-grown (and not terribly good) tools that help us visualise a project's architecture, from both the design and the implementation point of view. For projects that are good, these two views mesh perfectly. For projects that are crap, they diverge wildly. This gives a you a good idea where a little refactoring might to a lot of good. When working on a new code base, I start like this -- making small, incremental changes, documenting places that I find difficult to understand, and above all talking with more experienced developers.
Also, as someone that hates to write documentation, I find it invaluable when trying to describe large systems. But my documentation always has pictures, because they are fundamentally easier to grasp quickly than ten dense pages of text. Unfortunately, it's difficult to put good diagrams in comments.
(As an aside, back in my university days, I worked on a project where we did all of our coding in FrameMaker. This allowed us to put in pictures, colored comments -- basically anything. The build script turned the FrameMaker file into C++ source, which then got compiled. It was kind of the extreme version of self-documenting code.)
This is excellent. I'm going to have to try building on myself. I have bins of old Apple ][ disks that I'm trying to save and I'm guessing that moving to a hard drive would be a good idea.
Back in the day (1994), I started making a remote filesystem for my Apple that would communicate with my Sparc via serial. Unfortunately, it was dog slow and I gave up.
BTW, if anyone really wants to start hacking on the Apple//e, I would recommend "Understanding the Apple//e" by Jim Sather. It is fabulous. It is out of print right now, but I managed to pick one up a couple of years ago by being resourceful.;-)
bash$ telnet foo.bar.net 22
Trying 0.0.0.0...
Connected to foo.bar.net.
Escape character is '^]'.
Connection closed by foreign host.
I try telnetting to port 443 and I get the same thing. However https sites work fine. So it can't be a blocked port. Since telnetting doesn't even bring up the SSH version id, it doesn't seem like it's a problem with client.
Woohoo! Now from there I can easily access foo.bar.net with no problems at all. So I tried checking to see what the servers sent that might explain it. It turns out that they send different id strings at the start:
Now comes the tricky part. I noticed that a connection I had open *before* the switchover was still active this morning. And *that* was an ssh connection to foo.bar.net. So, I tried setting up a IP alias on eth0 (eth0:1) that used the old settings from pre-switchover times. Then I made a static route on the new interface to foo.bar.net. And now SSH to foo.bar.net works _fine_.
So, I'm thinking that AT&T is blocking some ssh connections. The question is, "Why?" I haven't had time to try to set up a fake server that just spews the SSH welcome message and see if it gets blocked, but I am going to investigate further.
The French are not more online. My girlfriend just went through hell trying to pay her French taxes "online" and the French government did a fine job of "losing" her payment, forcing her to send a paper payment later causing them to label her account as "delinquent".
As a matter of fact, we spent the first part of this year trying to get the right tax forms from the French government. We looked online and they only had forms that were two years old online. The site hadn't been updated since 1999. That doesn't seem more online to me. (Hell, they're barely offline, either -- the local office didn't have the damn forms either.)
In the US, we can go online and get all sorts of information -- including the proper tax forms for the year. Sure, it's not all nicely packaged in one happy Big Brother box, but it's there. Heck, even the INS has its forms online.
So, don't go touting the French thing as some amazing online revolution, because it's sure not to live up to all the promises.
This is a good example of how software is not tested.
According to the article the problem was due to the mother's age not
being correctly calculated. My question is, were there any sanity
checks on the mother's age in the first place? Probably not.
It seems logical that for a critical application you would try to
have as much sanity-checking code as possible. It should be plainly
obvious that no one should have a negative age or be giving birth if
they are over 100 years old. And sanity checking code is
easy.
The common excuse, though, is the ol' "garbage in, garbage out".
Which is fine -- but what if you don't know you have garbage? The
software -- if it can -- should at least give a warning.
This gets down to one of the basic questions for software testing:
What inputs can you rely on?
Software engineers know by now (at least mostly) that all user
input has to be checked and validated. But what about system data,
especially something as basic as the date?
The only way to protect against unexpected bad data is to do
sanity checking at all steps in the process. If you know even a
little bit about the domain, you can usually set reasonable bounds.
Software isn't really engineered unless it makes these
kinds of checks.
Personally, I can't stand grafitti. Everyone with a Palm tells me, "Hey, you get used to it." The hell with that. I want it to get used to me.
I hope that eventually the Palm catches up with the Newton and lets me write more than one character at a time. Maybe going to the ARM will help that out.
Slashdot Mirror
What makes Parakey different from Desktop.com and WebOS, two companies that looked like they had a decent future during the internet bubble? Desktop.com had a full operating system inside Netscape 4.5 and IE 4. You could share file, folders, etc. with your friends, use online "AJAX" applications, etc. WebOS had a very slick interface, too.
At Desktop.com, we had a couple of problems making the product fly. The first was technical: it bloated the browser up to 32Megs and made it unstable. (Nowadays, I don't bat an eye when Firefox is hungrily consuming 250M.) The second was usability: the online experience just wasn't as smooth and easy as a local application. This was partly due to the lower connection speeds that people were using back then, but also due to the inability to seamlessly interact with local files. And the really big problem was the business model: you either have to charge the users, or figure out how to put ads somewhere where people aren't used to ads -- like in the application title bar. Ick.
So, "one interface, not two" is all fine and dandy, but I'll be interested in seeing if they actually make it work and worthwhile.
I live outside the US and I bought a subscription to Audible precisely because I could no longer get my NPR fix in the car every day. I also have a pretty long commute (40 minutes at best, 3 hours when there are demonstrators closing the bridges) and the available radio sucks.
Everything was fine until NPR decided to cut off Audible because they wanted to experiment with podcasting[1]. Podcasting is fine with me, but they waited six months before getting something online -- and what they put up was "Most E-Mailed Stories". I don't want the most fucking e-mailed stories, I want "All Things Considered"!
Anyway, this really got me pissed off at NPR. Here I was actually paying them (through Audible) and they went and cut me off.
Bastards.
[1] Here's the response I got from Audible Customer Service:
I have had (am having) the displeasure of being part of a pilot project for an in-house MDA utility based on Rose and Eclipse. In a nutshell: it sucks.
There are two general problems that I've encountered:
The granularity problem is that you have to spend a lot of time specifying fine-grained details in the model that are more easily expressed in code. Examples are: method calls, persistence, behavior parameters, etc. Often these details don't even show up on the screen. This makes them almost useless for someone trying to understand what is going on. This is a big problem and not going away.
The tool problem is that if the tools don't help you work effectively, the whole process fails. Using Rose is like sticking pins under your toenails and kicking a wall. Rose seems to get in your way on purpose with a hideous interface. Sure, this problem is tool-related, but its impact is huge. It can turn what should be simple into a marathon of pain.
So far, we've spent weeks on a toy application that should have taken two days. Perhaps these in-house tools will evolve to the point of usability, but somehow I doubt it.
IanI think it's interesting to note that AJAX and online desktops were presaged by Desktop.com in 1999-2000. I worked there, so I can say with authority that we did have a full web-based operating system going in Netscape 4 and IE 4. The stuff that's done now isn't as complex as the stuff we had, in general, though recently (GTalk through GMail, for example) it's started coming close. (I admit I haven't been following some of the other sites mentioned, so maybe some other folks are further along.)
We ran into a couple of killer problems:
* Browser instability -- we had no control over this. Netscape lasted on average 10-15 minutes and ate tons of memory. IE lasted longer, but also consumed memory until it crashed.
* Slow connections -- we had a good 500K download at first connection (or empty cache), which was *slow* over dailup, which was the norm.
* Apps -- nobody is going to come if the apps aren't there. In the day, even making a notepad clone was difficult because native HTML controls were always on top.
The first two of these problems have been/are being slowly overcome. The third one is still a problem.
But the problem of privacy has never really been foremost in the minds of users. Maybe it will be, but with everyone using web mail, I'm kinda doubtful.
Ian
I just copy the whole workspace, then delete (or omit in the first place) the projects I don't want. This works really well if you have to work on two CVS branches at the same time.
You can try exporting preferences, but this has never worked to my satisfaction. Throw in badly-behaved plugins (like Jalopy) and all hope is lost.
Copy the whole workspace -- it's the only way to be sure.
Desktop.com had this stuff in 1999, but unfortunately the browsers of the day (IE4 and Netscape 4) weren't really capable of staying up long enough to make it worthwhile. There was even a company that had a nice little web-based spreahsheet app.
Still, I haven't seen a good, platform-independant, integrated sever- and client-side solution yet. Back at Desktop in was *all* client side except the actual persistence of objects so it wasn't really an issue.
Ah, well.
I'm still pissed that NPR abandonded Audible.com with no backup plan. I mean, what the hell? Who had the brilliant idea?
"I know, let's turn of this service that is generating a revenue stream and replace it with ... ground seashells and sand! I wonder if anyone will notice."
Feh.
We use McCabe (http://www.mccabe.com/) to point us to problem code. Running their tool gives you a good idea of where the complexity of an application lies and where you should focus your testing.
It works kinda like this: First the tool parses everything and generates a ton of metrics. This will point you to the complex modules of the application. Then it breaks down each function/method in the module into its possible execution paths and turns this into a graph. By looking at the graph, you can see what you need to do to get your test to follow a particular path.
McCabe also tells you how many test cases you'll net to completely test a give block of code. It assumes, however, that all of the tests are independent, which is not always the case.
On the down side, McCabe is big, expensive, and sometimes returns unreliable data. But it's a lot better than nothing.
If you're looking for free tools, look for things that calculate "cyclomatic complexity". This is the measure of the number of paths through a given block of code. Armed with that, you should be able to make some headway.
Good luck!
I don't think that's entirely a fair statement. I find that being able to visualize a codebase can help significantly -- even when it is a mess.
Where I work we have some home-grown (and not terribly good) tools that help us visualise a project's architecture, from both the design and the implementation point of view. For projects that are good, these two views mesh perfectly. For projects that are crap, they diverge wildly. This gives a you a good idea where a little refactoring might to a lot of good. When working on a new code base, I start like this -- making small, incremental changes, documenting places that I find difficult to understand, and above all talking with more experienced developers.
Also, as someone that hates to write documentation, I find it invaluable when trying to describe large systems. But my documentation always has pictures, because they are fundamentally easier to grasp quickly than ten dense pages of text. Unfortunately, it's difficult to put good diagrams in comments.
(As an aside, back in my university days, I worked on a project where we did all of our coding in FrameMaker. This allowed us to put in pictures, colored comments -- basically anything. The build script turned the FrameMaker file into C++ source, which then got compiled. It was kind of the extreme version of self-documenting code.)
Right! We need to fight spam with violence! Or is it violence with spam ? Both!
This is excellent. I'm going to have to try building on myself. I have bins of old Apple ][ disks that I'm trying to save and I'm guessing that moving to a hard drive would be a good idea.
//e, I would recommend "Understanding the Apple //e" by Jim Sather. It is fabulous. It is out of print right now, but I managed to pick one up a couple of years ago by being resourceful. ;-)
Back in the day (1994), I started making a remote filesystem for my Apple that would communicate with my Sparc via serial. Unfortunately, it was dog slow and I gave up.
BTW, if anyone really wants to start hacking on the Apple
You are correct. AT&T has the forward and reverse DNS out of sync. I just changed the /etc/hosts.allow to include my (now dynamic) IP and all is well.
Thanks!
I'm using AT&T in PDX and besides having to switch from a static IP to a dynamic IP, the transition went fairly smoothly.
I still have one hiccough: ssh seems to be cut off for *some* versions of ssh.
Here are the symptoms:
I try to ssh into my personal box:
bash$ ssh foo.bar.net
ssh_exchange_identification: Connection closed by remote host
I try to ssh into the box through the SSL backdoor on port 443:
bash$ ssh foo.bar.net -p 443
ssh_exchange_identification: Connection closed by remote host
I try telnetting to port 22:
bash$ telnet foo.bar.net 22
Trying 0.0.0.0...
Connected to foo.bar.net.
Escape character is '^]'.
Connection closed by foreign host.
I try telnetting to port 443 and I get the same thing. However https sites work fine. So it can't be a blocked port. Since telnetting doesn't even bring up the SSH version id, it doesn't seem like it's a problem with client.
So, I try ssh-ing to my old school address:
bash$ ssh old.school.edu
user@old.school.edu's password:
Woohoo! Now from there I can easily access foo.bar.net with no problems at all. So I tried checking to see what the servers sent that might explain it. It turns out that they send different id strings at the start:
foo.bar.net: SSH-1.5-OpenSSH-1.2.3
old.school.edu: SSH-1.99-2.0.12 (non-commercial)
Now comes the tricky part. I noticed that a connection I had open *before* the switchover was still active this morning. And *that* was an ssh connection to foo.bar.net. So, I tried setting up a IP alias on eth0 (eth0:1) that used the old settings from pre-switchover times. Then I made a static route on the new interface to foo.bar.net. And now SSH to foo.bar.net works _fine_.
So, I'm thinking that AT&T is blocking some ssh connections. The question is, "Why?" I haven't had time to try to set up a fake server that just spews the SSH welcome message and see if it gets blocked, but I am going to investigate further.
The French are not more online. My girlfriend just went through hell trying to pay her French taxes "online" and the French government did a fine job of "losing" her payment, forcing her to send a paper payment later causing them to label her account as "delinquent".
As a matter of fact, we spent the first part of this year trying to get the right tax forms from the French government. We looked online and they only had forms that were two years old online. The site hadn't been updated since 1999. That doesn't seem more online to me. (Hell, they're barely offline, either -- the local office didn't have the damn forms either.)
In the US, we can go online and get all sorts of information -- including the proper tax forms for the year. Sure, it's not all nicely packaged in one happy Big Brother box, but it's there. Heck, even the INS has its forms online.
So, don't go touting the French thing as some amazing online revolution, because it's sure not to live up to all the promises.
This is a good example of how software is not tested. According to the article the problem was due to the mother's age not being correctly calculated. My question is, were there any sanity checks on the mother's age in the first place? Probably not.
It seems logical that for a critical application you would try to have as much sanity-checking code as possible. It should be plainly obvious that no one should have a negative age or be giving birth if they are over 100 years old. And sanity checking code is easy.
The common excuse, though, is the ol' "garbage in, garbage out". Which is fine -- but what if you don't know you have garbage? The software -- if it can -- should at least give a warning.
This gets down to one of the basic questions for software testing: What inputs can you rely on?
Software engineers know by now (at least mostly) that all user input has to be checked and validated. But what about system data, especially something as basic as the date?
The only way to protect against unexpected bad data is to do sanity checking at all steps in the process. If you know even a little bit about the domain, you can usually set reasonable bounds.
Software isn't really engineered unless it makes these kinds of checks.
I hope that eventually the Palm catches up with the Newton and lets me write more than one character at a time. Maybe going to the ARM will help that out.