I am really amazed with the number of Web 2.0 sites (or should I say – applications?) that appear daily. There is a great site (eHub ) which hosts a constantly updated list of almost everything related to Web 2.0 – and almost every day some new resources are being added. While being amazed with the execution and design of the majority of these sites, I am at the same time surprised with their similarity. It seems like the developers are just remixing a few ideas, waiting that somehow they will eventually stumble upon the winning combination. “Friendster meet epinions”, “mashup between del.icio.us, flickr and yahoo news”, “sex offender data with google maps”… Every idea by itself sounds exciting and promising – but all together they give an impression of the same pattern being repeated over and over again and again.
I do not see this as a fundamental problem with Web 2.0 concept – I just think that for too many developers it’s still just an opportunity to play with new toys and to create a cool-looking modern web application.
Tuesday, October 11, 2005
Thursday, October 06, 2005
HBO poisons BitTorrent
O’Reilly Radar writes about HBO poisoning BitTorrent downloads of the show “Rome”. It sounds to me like a near-criminal way of stopping an “officially criminal” activity, and, thus, is really disturbing. From the formal point of view, HBO probably does not violate any law, and BitTorrent downloaders are, definitely, pirates. But from a position of a common sense, I cannot wholeheartedly call the BitTorrent users criminals. If I just watch the show – I’m not a criminal. And if I record the show on my DVR – I am also not a criminal. And if I remember that they taught me at school “Sharing is caring” and will share the record with a couple of my friends – will I become a criminal then? Where is the thin line that separates caring people from pirates?
And looking at the actions of HBO, I would say that they are almost indistinguishable from hacking into a network and disrupting the data transfer, which is a crime. They’d better spend their resources on developing a new distribution / business model – this, and not the poisoning, may help reduce pirating of their shows.
And looking at the actions of HBO, I would say that they are almost indistinguishable from hacking into a network and disrupting the data transfer, which is a crime. They’d better spend their resources on developing a new distribution / business model – this, and not the poisoning, may help reduce pirating of their shows.
Monday, October 03, 2005
Trick: "Report a problem" button
Today, I think, is a good time to stop being grumpy for a while. I want to share a trick I found very useful when I was working on a small application.
So, here is the problem: there is a small application, which works like a “wizard” – i.e. the users fill in some data on several pages, and, at the end, the application does something quite complex with the data (writes it to the database, creates some content – it doesn’t matter). The requirements are poorly specified, the business logic is changing often, and there are not enough QA resources to thoroughly test the application. As a result, the application sometimes behaves strangely – sometimes because of a bug, sometimes as a result of user actions. The question is – how to troubleshoot the application? The users being mostly non-technical people, it became a tough problem for me, how to find out what exactly caused the application to misbehave? I was getting several calls per week– and quite often I had to spend a lot of time trying to re-create the bug and interrogating the user – what exactly did she entered on all pages before the problem became evident.
Then I came with a solution. On the top of each page I’ve placed a button “Report a problem”. When clicked, the button opened a pop-up with a textbox for the description of the problem and a “Send report” button. The users were instructed, that in case of trouble they should click on the button, type in the description of the problem and submit the form. Behind the scenes this small pop-up did a very useful job: it dumped all the relevant data (session variables, URL, request data etc.) and appended the data to the problem description. I’ve also added a small piece of code to every page, which recorded the visit of the page in a session variable, so I could get a trace of which pages were visited in this session and in which order. The message was then e-mailed to me.
This little hack – as simple as it is – made the troubleshooting a lot easier. The users were also happy – they liked the simple way to submit a bug report and the speed at which the issues were resolved. Of course this solution will not, probably, work so well for huge applications (too much data to dump), but for small-to-medium applications it’s definitely worth trying.
So, here is the problem: there is a small application, which works like a “wizard” – i.e. the users fill in some data on several pages, and, at the end, the application does something quite complex with the data (writes it to the database, creates some content – it doesn’t matter). The requirements are poorly specified, the business logic is changing often, and there are not enough QA resources to thoroughly test the application. As a result, the application sometimes behaves strangely – sometimes because of a bug, sometimes as a result of user actions. The question is – how to troubleshoot the application? The users being mostly non-technical people, it became a tough problem for me, how to find out what exactly caused the application to misbehave? I was getting several calls per week– and quite often I had to spend a lot of time trying to re-create the bug and interrogating the user – what exactly did she entered on all pages before the problem became evident.
Then I came with a solution. On the top of each page I’ve placed a button “Report a problem”. When clicked, the button opened a pop-up with a textbox for the description of the problem and a “Send report” button. The users were instructed, that in case of trouble they should click on the button, type in the description of the problem and submit the form. Behind the scenes this small pop-up did a very useful job: it dumped all the relevant data (session variables, URL, request data etc.) and appended the data to the problem description. I’ve also added a small piece of code to every page, which recorded the visit of the page in a session variable, so I could get a trace of which pages were visited in this session and in which order. The message was then e-mailed to me.
This little hack – as simple as it is – made the troubleshooting a lot easier. The users were also happy – they liked the simple way to submit a bug report and the speed at which the issues were resolved. Of course this solution will not, probably, work so well for huge applications (too much data to dump), but for small-to-medium applications it’s definitely worth trying.
Subscribe to:
Posts (Atom)