I enjoyed watching the Wimbledon ladies final between the Williams sisters the previous day and their doubles final. Just when I thought I have seen everything in this edition, I was proved wrong the next day when I witnessed the greatest men's tennis final ever on grass. While Federer was trying to win the title for the 6th time in a raw (and breaking Bjorn Borg's record), Nadal eying at his first Wimbledon title having lost to Federer last two occasions.
Both the players were equally up to the task and you can hardly tell who had the upper hand. However, if you watched the match, you won't disagree with me that Nadal was a little better than Federer on that day. And rightfully Nadal won the title at the end in his 4th championship point. It was a pretty close match - 6-4, 6-4, 6-7 (5-7), 6-7 (7-9 Nadal missed two championship points), 9-7 (What a sporting feast for Spain who recently clinched Euro cup 2008 beating Germany as well). I was fascinated by the masterclass of tennis played; it was unbelievable how they converted aces and winners into shots and difficult-to-hit ones into winners. Nadal also went to record books by being the first player to win back-to-back French Open and Wimbledon after nearly 3 decades. This match also the longest match to the date (without the rain breaks). Both played very professional tennis and I was simply amazed how graciously both handled the pressure where an armature would have screamed or even outcried at a miss. Great Match!
During the rain-interruption I was able to watch (thanks to espn360) the Asia cup final where our team (Sri Lankans) thrashed Indians. I was really happy to see Sanath hitting a winning century in this match and Ajantha Mendis, the new found spinner, was simply unplayable for Indians. Well done Lions!
Tuesday, July 8, 2008
Tuesday, July 1, 2008
Out of Print (Newspapers)?
Most of the things mentioned in the blog entry 'Are newspapers doomed?' by Richard Posner go well with my opinion on the subject (i.e. the online news media taking over the space of the print media). The idea of bundling in his note is well taken although I am not an expert in economics ;-).
"A bundled product is one that combines a number of products the demands for which may be quite different--some consumers may want some of the products in the bundle, other consumers may want other products in the bundle (sports, weather, politics and you name it)...Bundling is efficient if the cost to the consumer of the bundled products that he doesn't want is less than the cost saving from bundling..." The key take away point is that bundled product may be cheaper than the total price of the individual unbundled component.
It is disputable if bundling or specialization the way to go in online media. I put my money on specialization as a start-up option mainly due to the following two reasons.
1. There are much more competitors in the online market than print media.
2. It's easier to aggregate views from many different sources and provide a through view of the news at hand.
As the business grows, bundling may be considered to attract more audience.
Further, he indicates that older generation prefer to read hard copies compared to the younger generation. While this may be true for the current demographic spread (may be due to print media being the dominant source when they were young), I think this trend will also change in the future; when people get used to online news when they were young, they'll probably continue to read online (resistance to change factor comes to play).
Few years ago (when I was in Sri Lanka), every Sunday morning I used to read Lakbima, Sunday Times and/or Sunday Observer (Sri Lankan news papers), but here in USA, I prefer to read news online. I'm not alone, these sources [1, 2] back up the fact that more and more people get information online, shrinking the market for the printed newspapers. I think, among other things, following contributed to this trend.
1. It's much cheaper to circulate information online.
2. Most printed newspapers rely on ads to generate revenue. With the advent of online advertising including free (like craiglist) services, their revenue through ads started to diminish, propelling them to look into alternatives.
I am more interested in the technical challenges in realizing the above trend. A part of my research is directed towards efficient and secure content distribution. Looking at the trend I think my research can make a positive impact in the future in this area; I always want to do something that is useful to people. Who knows, in the near future, you'll see many people reading their morning news through hand held wireless readers!
"A bundled product is one that combines a number of products the demands for which may be quite different--some consumers may want some of the products in the bundle, other consumers may want other products in the bundle (sports, weather, politics and you name it)...Bundling is efficient if the cost to the consumer of the bundled products that he doesn't want is less than the cost saving from bundling..." The key take away point is that bundled product may be cheaper than the total price of the individual unbundled component.
It is disputable if bundling or specialization the way to go in online media. I put my money on specialization as a start-up option mainly due to the following two reasons.
1. There are much more competitors in the online market than print media.
2. It's easier to aggregate views from many different sources and provide a through view of the news at hand.
As the business grows, bundling may be considered to attract more audience.
Further, he indicates that older generation prefer to read hard copies compared to the younger generation. While this may be true for the current demographic spread (may be due to print media being the dominant source when they were young), I think this trend will also change in the future; when people get used to online news when they were young, they'll probably continue to read online (resistance to change factor comes to play).
Few years ago (when I was in Sri Lanka), every Sunday morning I used to read Lakbima, Sunday Times and/or Sunday Observer (Sri Lankan news papers), but here in USA, I prefer to read news online. I'm not alone, these sources [1, 2] back up the fact that more and more people get information online, shrinking the market for the printed newspapers. I think, among other things, following contributed to this trend.
1. It's much cheaper to circulate information online.
2. Most printed newspapers rely on ads to generate revenue. With the advent of online advertising including free (like craiglist) services, their revenue through ads started to diminish, propelling them to look into alternatives.
I am more interested in the technical challenges in realizing the above trend. A part of my research is directed towards efficient and secure content distribution. Looking at the trend I think my research can make a positive impact in the future in this area; I always want to do something that is useful to people. Who knows, in the near future, you'll see many people reading their morning news through hand held wireless readers!
Tuesday, June 24, 2008
The Security Mindset
I recently read an interesting blog post by Bruce Schneier on the type of mindset you need to have to develop software/applications with better security.
"Security requires a particular mindset. Security professionals -- at least the good ones -- see the world differently. They can't walk into a store without noticing how they might shoplift. They can't use a computer without wondering about the security vulnerabilities. They can't vote without trying to figure out how to vote twice. They just can't help it.
...
This kind of thinking is not natural for most people. It's not natural for engineers. Good engineering involves thinking about how things can be made to work; the security mindset involves thinking about how things can be made to fail. It involves thinking like an attacker, an adversary or a criminal. You don't have to exploit the vulnerabilities you find, but if you don't see the world that way, you'll never notice most security problems..."
The biggest question is how we prove that the block of code we have written is correct (no security holes what so ever)? Our proof of correctness depends on our curiosity about what might possibly go wrong - have we considered all remote and corner cases? It's more or less analogous to theorem proving in Mathematics; we say a theorem is correct only if we can prove it to be correct for all cases.
I agree with him that the lack of security mindset is a major cause for many security problems we experience today; looking at things from an attacker's perspective and analytical (Math) skills can certainly help!
"Security requires a particular mindset. Security professionals -- at least the good ones -- see the world differently. They can't walk into a store without noticing how they might shoplift. They can't use a computer without wondering about the security vulnerabilities. They can't vote without trying to figure out how to vote twice. They just can't help it.
...
This kind of thinking is not natural for most people. It's not natural for engineers. Good engineering involves thinking about how things can be made to work; the security mindset involves thinking about how things can be made to fail. It involves thinking like an attacker, an adversary or a criminal. You don't have to exploit the vulnerabilities you find, but if you don't see the world that way, you'll never notice most security problems..."
The biggest question is how we prove that the block of code we have written is correct (no security holes what so ever)? Our proof of correctness depends on our curiosity about what might possibly go wrong - have we considered all remote and corner cases? It's more or less analogous to theorem proving in Mathematics; we say a theorem is correct only if we can prove it to be correct for all cases.
I agree with him that the lack of security mindset is a major cause for many security problems we experience today; looking at things from an attacker's perspective and analytical (Math) skills can certainly help!
Monday, June 23, 2008
Is XML worth it?
Every now and then I meet people who hate XML (some of my lab mates are also in the 'XML sucks crowd'). As a person interested in XML related technologies, I thought of looking into this issue and see if XML really sucks or it's just that you cannot satisfy everybody.
One of the criticism is that XML is slow to parse compared to flat files such as CSV files. This fact about the speed is true. However, the comparison is quite flawed as it's like comparing apples with oranges. XML provides a parsable definition of a document structure while CSV's or similar approaches do not. We need to realize that the benefit comes at an extra cost!
In XML-sucks web sites, they deliver the message that XML is hard to deal with in programming paradigm. IMO, this fact was true during the early days when XML was invented about a decade ago where there were only a few libraries and tools to work with. Now, the situation has changed; there are many libraries (both DOM and SAX) for various languages which are not that hard to master once you spend some to learn the basics.
Another criticism is that XML is verbose (use more bandwidth than required to do the job). With the multimedia age, I don't think this addition of markups going to create a huge difference in the bandwidth usage (provided that we judiciously use namespaces). Further, there are compression techniques on XML already available which help reduce the message size. If you are really really concerned about the message sizes and the interoperability or any other cool things about XML are not required, I suggest you don't use XML. In my opinion, the gain we get is well worth the price we pay for the additional
bandwidth, which is after all textual information.
I agree that while XML itself is quite simple, it gets complicated with the proliferation of related technologies. However, complexity is partly under our control as we decide what we want to use along with XML. The trick is to use only those technologies that are absolutely necessary and have matured to become standards.
XML is for hierarchically structured data and can be an overkill for data with no hierarchy. For example, if a property-value file (like in Java) is sufficient for the job, you will not gain anything by using XML but loose for performance. XML-suck groups compare the data of the latter type in XML with other alternatives available and gives a false impression. If your data is not hierarchically structured and do not have a requirement to use a specific document format, I would go for a flat file format.
Some of the cool features of XML that makes it stand out from other approaches:
Addresses the internationalization (i18n for short) issue
If you don't know what encoding the data is in, the data is virtually useless. With the global economy becoming one single market, internationalization (which allows to adapt to various languages and regions without engineering changes) of data becomes necessary. So, the encoding becomes an import factor. An XML document knows what encoding it's in. There's no ambiguity in an XML document which is a sequence of characters and these characters are coded and then encoded in a specific character encoding. The encoding used decides the number of bytes required for the coded characters (for example UTF-8 requires 1 byte). No matter what software you use, it can process any XML document making it ideal for data exchange.
Enforces creating well-formed documents
XML syntax enforces to have properly nested documents which allows you to verify the document is structurely correct to a certain degree.
Can enforce to create valid documents
In addition to proper nesting, you may need to make sure the document includes only certain elements and attributes, their data types, etc. These documents are declared to meet a DTD or XML Schema (successor of DTD). The nice thing about XML Schema is it itself is written in XML and there are a whole bunch of validation tools out there to validate the XML document against the schema.
Promotes syntax-level interoperability
In the software industry, interoperability has been one of the hardest goals to achieve. People initially thought that having well defined API's is the way to go. However, this approach does not work across heterogeneous operating systems. If you look at the success of the Internet and its related technologies, one thing is common; they all have bits-on-the-wire definitions (i.e. syntactic level).
A safe way of keeping data long term
As we all know, information/data outlives technologies we have today. Therefore, keeping data in proprietary formats may not be a good choice especially if the data are anticipated to be used much later down the time line. XML solves this problem as it's an open specification and is not tied to any specific technology.
To sum up, if you use XML only for those tasks for which it is designed to be used, it can pay you off; XML is not a solution to every data problem we encounter.
Main References:
Why XML Doesn't Suck
One of the criticism is that XML is slow to parse compared to flat files such as CSV files. This fact about the speed is true. However, the comparison is quite flawed as it's like comparing apples with oranges. XML provides a parsable definition of a document structure while CSV's or similar approaches do not. We need to realize that the benefit comes at an extra cost!
In XML-sucks web sites, they deliver the message that XML is hard to deal with in programming paradigm. IMO, this fact was true during the early days when XML was invented about a decade ago where there were only a few libraries and tools to work with. Now, the situation has changed; there are many libraries (both DOM and SAX) for various languages which are not that hard to master once you spend some to learn the basics.
Another criticism is that XML is verbose (use more bandwidth than required to do the job). With the multimedia age, I don't think this addition of markups going to create a huge difference in the bandwidth usage (provided that we judiciously use namespaces). Further, there are compression techniques on XML already available which help reduce the message size. If you are really really concerned about the message sizes and the interoperability or any other cool things about XML are not required, I suggest you don't use XML. In my opinion, the gain we get is well worth the price we pay for the additional
bandwidth, which is after all textual information.
I agree that while XML itself is quite simple, it gets complicated with the proliferation of related technologies. However, complexity is partly under our control as we decide what we want to use along with XML. The trick is to use only those technologies that are absolutely necessary and have matured to become standards.
XML is for hierarchically structured data and can be an overkill for data with no hierarchy. For example, if a property-value file (like in Java) is sufficient for the job, you will not gain anything by using XML but loose for performance. XML-suck groups compare the data of the latter type in XML with other alternatives available and gives a false impression. If your data is not hierarchically structured and do not have a requirement to use a specific document format, I would go for a flat file format.
Some of the cool features of XML that makes it stand out from other approaches:
Addresses the internationalization (i18n for short) issue
If you don't know what encoding the data is in, the data is virtually useless. With the global economy becoming one single market, internationalization (which allows to adapt to various languages and regions without engineering changes) of data becomes necessary. So, the encoding becomes an import factor. An XML document knows what encoding it's in. There's no ambiguity in an XML document which is a sequence of characters and these characters are coded and then encoded in a specific character encoding. The encoding used decides the number of bytes required for the coded characters (for example UTF-8 requires 1 byte). No matter what software you use, it can process any XML document making it ideal for data exchange.
Enforces creating well-formed documents
XML syntax enforces to have properly nested documents which allows you to verify the document is structurely correct to a certain degree.
Can enforce to create valid documents
In addition to proper nesting, you may need to make sure the document includes only certain elements and attributes, their data types, etc. These documents are declared to meet a DTD or XML Schema (successor of DTD). The nice thing about XML Schema is it itself is written in XML and there are a whole bunch of validation tools out there to validate the XML document against the schema.
Promotes syntax-level interoperability
In the software industry, interoperability has been one of the hardest goals to achieve. People initially thought that having well defined API's is the way to go. However, this approach does not work across heterogeneous operating systems. If you look at the success of the Internet and its related technologies, one thing is common; they all have bits-on-the-wire definitions (i.e. syntactic level).
A safe way of keeping data long term
As we all know, information/data outlives technologies we have today. Therefore, keeping data in proprietary formats may not be a good choice especially if the data are anticipated to be used much later down the time line. XML solves this problem as it's an open specification and is not tied to any specific technology.
To sum up, if you use XML only for those tasks for which it is designed to be used, it can pay you off; XML is not a solution to every data problem we encounter.
Main References:
Why XML Doesn't Suck
Tuesday, June 3, 2008
For a Good Cause
With the rising cost of living, many people in Sri Lanka find it hard to meet their ends. It is unfortunate to see many drop out from schools and universities due to financial difficulties. A small helping hand for those needed can go a long way since the education is the backbone of any country. It can also be a bridge to increase the mutual understanding between people of different ethnic groups in our country. For the last couple of years, Educate Lanka non-profit organization has been working towards achieving this goal. I'm fortunate to be a part of this effort and help some university students continue their studies. They have a well-managed program and support elementary, secondary and university students. You don't need to be super rich to be a sponsor; all it takes is a few bucks per month. Our collective effort can make a difference!
Monday, June 2, 2008
Ubuntu + PHP + MySQL
For a project I've been working on, I wanted to get MySQL (5.x) working with PHP (5.2.x) in Ubuntu (Fiesty Fawn, haven't switched to Hardy Heron yet). I haven't worked with these software for quite some time. I tried to get it working by manual configurations (installing the required packages and editing the php.ini to have the mysql.so extension), but had little luck with it. Fortunately, I found the this reference. I first completely removed apache2, php5 and mysql from my distribution and apt-get installed the following.
sudo apt-get install apache2
sudo apt-get install mysql-server libmysqlclient15-dev
sudo apt-get install php5 php5-common libapache2-mod-php5 php5-gd php5-dev
You can set a root password for MySQL server with the following command (initially the root password is blank).
sudo /etc/init.d/mysql reset-password
Now php should work along with apache2. However, we still need to get it glued with MySQL. Installing phpmyadmin does the trick.
sudo apt-get install phpmyadmin
For PHP to work with MySQL, we need the php5-mysql package. Installing above phpmyadmin package automatically installs php5-mysql for you. Now you should see a section for MySQL in phpinfo(). If you go to http://localhost, you will see a folder called phpmyadmin which provides a web interface to your database server.
If you happen to forget the root password of your MySQL (which happened to me), you can do the following to reset.
First stop the already running MySQL server:
mysql server /etc/init.d/mysql stop
Start MySQL in safe mode with privilege checking switched off:
mysqld_safe --skip-grant-tables
Log into MySQL as root user:
mysql --user=root mysql
Execute the following:
update user set Password=PASSWORD('new-password');
flush privileges;
exit;
Now kill the MySQL daemon started in safe mode and you are all set to work in the regular mode.
sudo apt-get install apache2
sudo apt-get install mysql-server libmysqlclient15-dev
sudo apt-get install php5 php5-common libapache2-mod-php5 php5-gd php5-dev
You can set a root password for MySQL server with the following command (initially the root password is blank).
sudo /etc/init.d/mysql reset-password
Now php should work along with apache2. However, we still need to get it glued with MySQL. Installing phpmyadmin does the trick.
sudo apt-get install phpmyadmin
For PHP to work with MySQL, we need the php5-mysql package. Installing above phpmyadmin package automatically installs php5-mysql for you. Now you should see a section for MySQL in phpinfo(). If you go to http://localhost, you will see a folder called phpmyadmin which provides a web interface to your database server.
If you happen to forget the root password of your MySQL (which happened to me), you can do the following to reset.
First stop the already running MySQL server:
mysql server /etc/init.d/mysql stop
Start MySQL in safe mode with privilege checking switched off:
mysqld_safe --skip-grant-tables
Log into MySQL as root user:
mysql --user=root mysql
Execute the following:
update user set Password=PASSWORD('new-password');
flush privileges;
exit;
Now kill the MySQL daemon started in safe mode and you are all set to work in the regular mode.
Monday, May 12, 2008
University of Moratuwa, Sri Lanka, on top of the GSoC list
It's great to see that the university where I did my undergrad studies tops the GSoC list [1, 2, 3], not only in the number of applications but also, more importantly, in the number of accepted proposals. Google Summer of Code is considered to be a major effort promoting open source projects among universities. It's quite competitive to get a proposal accepted.
Getting started is the hardest part of anything. If we look at the last 3 years, I recognize one person, Dr. Sanjiva Weerawarana, who, I am sure, would be happier than anyone else to see these current figures. Dr. Weerawarana has been encouraging and helping university students through LSF and WSO2, as well as being a part-time lecturer to participate in open source projects including GSoC. We should also recognize the effort by the faculty and the heads of the departments (including my undergrad department) of University of Moratuwa to drive students to obtain real world experience through practical open source projects.
Go Mora!
Getting started is the hardest part of anything. If we look at the last 3 years, I recognize one person, Dr. Sanjiva Weerawarana, who, I am sure, would be happier than anyone else to see these current figures. Dr. Weerawarana has been encouraging and helping university students through LSF and WSO2, as well as being a part-time lecturer to participate in open source projects including GSoC. We should also recognize the effort by the faculty and the heads of the departments (including my undergrad department) of University of Moratuwa to drive students to obtain real world experience through practical open source projects.
Go Mora!
Subscribe to:
Posts (Atom)