The Debian Project is pleased to announce the official release of Debian GNU/Linux version 4.0, codenamed etch, after 21 months of constant development. Debian GNU/Linux is a free operating system which supports a total of eleven processor architectures and includes the KDE, GNOME and Xfce desktop environments. It also features cryptographic software and compatibility with the FHS v2.3 and software developed for version 3.1 of the LSB.
Using a now fully integrated installation process, Debian GNU/Linux 4.0 comes with out-of-the-box support for encrypted partitions. This release introduces a newly developed graphical frontend to the installation system supporting scripts using composed characters and complex languages; the installation system for Debian GNU/Linux has now been translated to 58 languages.
Also beginning with Debian GNU/Linux 4.0, the package management system has been improved regarding security and efficiency. Secure APT allows the verification of the integrity of packages downloaded from a mirror. Updated package indices won't be downloaded in their entirety, but instead patched with smaller files containing only differences from earlier versions.
Debian GNU/Linux runs on computers ranging from palmtops and handheld systems to supercomputers, and on nearly everything in between. A total of eleven architectures are supported including: Sun SPARC (sparc), HP Alpha (alpha), Motorola/IBM PowerPC (powerpc), Intel IA-32 (i386) and IA-64 (ia64), HP PA-RISC (hppa), MIPS (mips, mipsel), ARM (arm), IBM S/390 (s390) and – newly introduced with Debian GNU/Linux 4.0 – AMD64 and Intel EM64T (amd64).
Debian GNU/Linux can be installed from various installation media such as DVDs, CDs, USB sticks and floppies, or from the network. GNOME is the default desktop environment and is contained on the first CD. The K Desktop Environment (KDE) and the Xfce desktop can be installed through two new alternative CD images. Also newly available with Debian GNU/Linux 4.0 are multi-arch CDs and DVDs supporting installation of multiple architectures from a single disc.
Debian GNU/Linux can be downloaded right now via bittorrent (the recommended way), jigdo or HTTP; It will soon be available on DVD and CD-ROM from numerous vendors, too.
This release includes a number of updated software packages, such as the K Desktop Environment 3.5.5a (KDE), an updated version of the GNOME desktop environment 2.14, the Xfce 4.4 desktop environment, the GNUstep desktop 5.2, X.Org 7.1, OpenOffice.org 2.0.4a, GIMP 2.2.13, Iceweasel (an unbranded version of Mozilla Firefox 2.0.0.3), Icedove (an unbranded version of Mozilla Thunderbird 1.5), Iceape (an unbranded version of Mozilla Seamonkey 1.0.8), PostgreSQL 8.1.8, MySQL 5.0.32, GNU Compiler Collection 4.1.1, Linux kernel version 2.6.18, Apache 2.2.3, Samba 3.0.24, Python 2.4.4 and 2.5, Perl 5.8.8, PHP 4.4.4 and 5.2.0, Asterisk 1.2.13, and more than 18,000 other ready to use software packages.
Monday, April 09, 2007
Wednesday, April 04, 2007
Gutter Tactics of Amnesty International (AI) Condemned - SPUR
It is indeed a woeful situation to see an organization, which claims itself to be protecting human rights has been engaged in an unethical, low quality mode of operations against a democratic nation. Reports from the Perhaps it is the same reason why the AI has chosen to attack the SL cricket team. Perhaps, the AI might be thinking that the blood of the Sri Lankan's is cheap so that they do not have a right to fight against terrorism. Perhaps it wants to ensure that the third world remains where it is forever.... The Society for Peace, Unity and Human Rights for
The Chair of the Board of Management
Amnesty International
Locked Bag 23
BROADWAY NSW 2007
2 April 2007
Dear Sir/Madam,
SPUR unreservedly condemn this unethical, underhand action by Amnesty International and request that you inform your counterparts in the Caribbean as well as the Head Office in
Furthermore, we will hold AI responsible if any abuse or pressure is brought upon any members or support staff of the cricket team by the public in the
Inaction will only confirm AI's bias in favour of terrorists. Don't give us the bunkum that your charter is limited to keeping democratically elected governments honest.
Trust you will put your money where your mouth is and immediately take necessary steps to stop violating the fundamental rights of Sri Lankan cricketers and their supporters enjoying a peaceful game of cricket.
Thanking you,
Dr Dasarath Jayasuriya
President
Monday, April 02, 2007
World's Strongest Dad, A Tribute to Rick & Dick Hoyt
Dick and Rick Hoyt are a father-and-son team from
It’s a remarkable record of exertion — all the more so when you consider that Rick can't walk or talk.
http://www.teamhoyt.com
Wednesday, March 28, 2007
Richard M Stallman visiting Sri Lanka
Further to an invitation by the ICTA, Richard Stallman has confirmed that he will be visiting
Exact dates are yet to be finalized, but it will most probably be in the 2nd week of Jan. ICTA expect him to stay 2-3 days and may be a bit longer if he wants to travel around Sri Lanka. We the FOSS community is planning to organize some FOSS events around his visit.
January 2008 is still a long time a way, but it gives us plenty of time to plan a decent agenda and organize some really good events.
ICTA will officially host him, and take care of his travel logistics and expenses.
Monday, March 26, 2007
MPlayer - The Movie Player (http://www.mplayerhq.hu)
I have listed the MPlayer's most useful Keyboard Control keys for its users quick references.
Seek backward/forward 10 seconds.
up and down
Seek backward/forward 1 minute.
pgup and pgdown
Seek backward/forward 10 minutes.
[ and ]
Decreases/increases current playback speed by 10%.
{ and }
Halves/doubles current playback speed.
Backspace
Reset playback speed to normal.
<>
backward/forward in playlist
HOME and END
next/previous playtree entry in the parent list
INS and
next/previous alternative source (ASX playlist only)
p / SPACE
Pause movie (pressing again unpauses).
Step forward. Pressing once will pause movie, every consecutive press will play one frame and then go into pause mode again (any other key unpauses).
q / ESC
Stop playing and quit.
+ and -
Adjust audio delay by +/- 0.1 seconds.
/ and *
Decrease/increase volume.
Decrease/increase volume.
M
Mute sound.
F
Toggle fullscreen (also see -fs).
Toggle stay-on-top (also see -ontop).
w and e
Decrease/increase pan-and-scan range.
o
Toggle OSD states: none / seek / seek + timer / seek + timer + total time.
Toggle frame dropping states: none / skip display / skip decoding (see -framedrop and -hardframedrop).
v
Toggle subtitle visibility.
b / j
Cycle through the available subtitles.
F
Toggle displaying "forced subtitles".
a
Toggle subtitle aligment: top/middle/bottom.
z and x
Adjust subtitle delay by +/- 0.1 seconds.
Move subtitles up/down.
i
Set EDL mark.
3 and 4 Adjust brightness.
5 and 6 Adjust hue.
7 and 8 Adjust saturation
Following is the default input.conf file which is MPlayer input control file to redefine default keyboard/joystick/mouse/LIRC bindings, or to add new ones according to users choice. Free as in free choice :)
This file should be placed in the $HOME/.mplayer directory.
RIGHT seek +10
LEFT seek -10
DOWN seek -60
UP seek +60
PGUP seek 600
PGDWN seek -600
- audio_delay 0.100
+ audio_delay -0.100
q quit
ESC quit
ENTER pt_step 1 1
p pause
SPACE pause
HOME pt_up_step 1
END pt_up_step -1
> pt_step 1
<>
Friday, March 23, 2007
Top ten things of professional software development has taught me
1) Object orientation is much harder than you think
Maybe it's just me, but coming from Computer Science class I thought that OO was easy. I mean, how hard can it be to create classes that mimic the real world? It turns out that it's pretty hard. Seven years later, I'm still learning how to model properly. I wish I spent more time reading up on OO and design patterns. Good modeling skills are worth a lot to every development team.
2) The difficult part of software development is communication
And that's communication with persons, not socket programming. Now and then you do run into a tricky technical problem, but it's not at all that common. Much more common is misunderstandings between you and the project manager, between you and the customer and finally between you and the other developers. Work on your soft skills.
3) Learn to say no
When I started working, I was very eager to please. This meant that I had a hard time saying no to things people asked of me. I worked a lot of overtime, and still didn't finish everything that was asked of me. The result was disappointment from their side, and almost burning out on my part. If you never say no, your yes is worth very little. Commit to what you can handle, and if people keep asking you for more, make it very explicit that this would mean not doing something else. What I did was to have a list of stuff that I needed to do on a piece of paper with me. When someone asked for something, I showed them the list and asked what I should bump to have time to help them. This allowed me to say no in a nice way.
4) If everything is equally important, then nothing is important
The business likes to say that all the features are as crucial. They are not. Push back and make them commit. It's easier if you don't force them to pick what to do and what not to do. Instead, let them choose what you should do this week. This will let you produce the stuff that brings value first. If all else goes haywire, at least you've done that.
5) Don't over-think a problem
I can spend whole days designing things in front of the white board. That doesn't mean it will be any better, it just means it will be more complicated. I don't mean to say you shouldn't design at all, just that the implementation will quickly show me stuff I didn't think of anyway, so why try to make it perfect? Like Dave Farell says: "The devil is in the details, but exorcism is in implementation, not theory."
6) Dive really deep into something, but don't get hung up
Chris and I spent a lot of time getting into the real deep parts of SQL Server. It was great fun and I learned a lot from it, but after some time I realized that knowing that much didn't really help me solve the business' problems. An example: I know that at the table level, SQL Server will not take an IU lock - it will only take a IX lock. This is a performance tweak, since most of the time, the IU lock will have to be escalated into a IX lock anyway. To find this, I spent countless days experimenting, I read loads of material and talked to Microsoft people at conferences. Have I ever had any use of this knowledge. Nope.
7) Learn about the other parts of the software development machine
It's really important to be a great developer. But to be a great part of the system that produces software, you need to understand what the rest of the system does. How do the QA people work? What does the project manager do? What drives the business analyst? This knowledge will help you connect with the rest of the people, and will grease interactions with them. Ask the people around you for help in learning more. What books are good? Most people will be flattered that you care, and willingly help you out. A little time on this goes a really long way.
8) Your colleagues are your best teachers
A year after I started on my first job, we merged with another company. Suddenly I had a lot of much more talented and experienced people around me. I remember distinctly how this made me feel inferior and stupid. I studied hard, reading book after book but I still didn't catch up. They had too much of an advantage on me, I figured.
Nowadays, working with great people doesn't make me feel bad at all. I just feel I have the chance of a lifetime to learn. I ask questions and I try really hard to understand how my colleagues come to the conclusions they do. This is why I joined ThoughtWorks. See your peers as an asset, not competition.
9) It all comes down to working software
No matter how cool your algorithms are, no matter how brilliant your database schema is, no matter how fabulous your whatever is, if it doesn't scratch the clients' itch, it's not worth anything. Focus on delivering working software, and at the same time prepare to continue delivering software using that code base and you're on the right path.
10) Some people are assholes
Most of the time, most of the people around you are great. You learn from them, and they learn from you. Accomplishing something together is a good feeling. Unfortunately, you will probably run into the exceptions. People that because of something or other are plain old mean. Demeaning bosses. Lying colleagues. Stupid, ignorant customers. Don't take this too hard. Try to work around them and do what you can to minimize the pain and effort they cause, but don't blame yourself. As long as you stay honest and do your best, you've done your part.
Maybe it's just me, but coming from Computer Science class I thought that OO was easy. I mean, how hard can it be to create classes that mimic the real world? It turns out that it's pretty hard. Seven years later, I'm still learning how to model properly. I wish I spent more time reading up on OO and design patterns. Good modeling skills are worth a lot to every development team.
2) The difficult part of software development is communication
And that's communication with persons, not socket programming. Now and then you do run into a tricky technical problem, but it's not at all that common. Much more common is misunderstandings between you and the project manager, between you and the customer and finally between you and the other developers. Work on your soft skills.
3) Learn to say no
When I started working, I was very eager to please. This meant that I had a hard time saying no to things people asked of me. I worked a lot of overtime, and still didn't finish everything that was asked of me. The result was disappointment from their side, and almost burning out on my part. If you never say no, your yes is worth very little. Commit to what you can handle, and if people keep asking you for more, make it very explicit that this would mean not doing something else. What I did was to have a list of stuff that I needed to do on a piece of paper with me. When someone asked for something, I showed them the list and asked what I should bump to have time to help them. This allowed me to say no in a nice way.
4) If everything is equally important, then nothing is important
The business likes to say that all the features are as crucial. They are not. Push back and make them commit. It's easier if you don't force them to pick what to do and what not to do. Instead, let them choose what you should do this week. This will let you produce the stuff that brings value first. If all else goes haywire, at least you've done that.
5) Don't over-think a problem
I can spend whole days designing things in front of the white board. That doesn't mean it will be any better, it just means it will be more complicated. I don't mean to say you shouldn't design at all, just that the implementation will quickly show me stuff I didn't think of anyway, so why try to make it perfect? Like Dave Farell says: "The devil is in the details, but exorcism is in implementation, not theory."
6) Dive really deep into something, but don't get hung up
Chris and I spent a lot of time getting into the real deep parts of SQL Server. It was great fun and I learned a lot from it, but after some time I realized that knowing that much didn't really help me solve the business' problems. An example: I know that at the table level, SQL Server will not take an IU lock - it will only take a IX lock. This is a performance tweak, since most of the time, the IU lock will have to be escalated into a IX lock anyway. To find this, I spent countless days experimenting, I read loads of material and talked to Microsoft people at conferences. Have I ever had any use of this knowledge. Nope.
7) Learn about the other parts of the software development machine
It's really important to be a great developer. But to be a great part of the system that produces software, you need to understand what the rest of the system does. How do the QA people work? What does the project manager do? What drives the business analyst? This knowledge will help you connect with the rest of the people, and will grease interactions with them. Ask the people around you for help in learning more. What books are good? Most people will be flattered that you care, and willingly help you out. A little time on this goes a really long way.
8) Your colleagues are your best teachers
A year after I started on my first job, we merged with another company. Suddenly I had a lot of much more talented and experienced people around me. I remember distinctly how this made me feel inferior and stupid. I studied hard, reading book after book but I still didn't catch up. They had too much of an advantage on me, I figured.
Nowadays, working with great people doesn't make me feel bad at all. I just feel I have the chance of a lifetime to learn. I ask questions and I try really hard to understand how my colleagues come to the conclusions they do. This is why I joined ThoughtWorks. See your peers as an asset, not competition.
9) It all comes down to working software
No matter how cool your algorithms are, no matter how brilliant your database schema is, no matter how fabulous your whatever is, if it doesn't scratch the clients' itch, it's not worth anything. Focus on delivering working software, and at the same time prepare to continue delivering software using that code base and you're on the right path.
10) Some people are assholes
Most of the time, most of the people around you are great. You learn from them, and they learn from you. Accomplishing something together is a good feeling. Unfortunately, you will probably run into the exceptions. People that because of something or other are plain old mean. Demeaning bosses. Lying colleagues. Stupid, ignorant customers. Don't take this too hard. Try to work around them and do what you can to minimize the pain and effort they cause, but don't blame yourself. As long as you stay honest and do your best, you've done your part.
Wednesday, March 21, 2007
Web Services Made Easy with Ruby
It's easy to develop Web services using Ruby. This article looks at how to develop a Web service client to access the Web services that are hosted in the Internet and how to develop a Web service with simple steps using Ruby.
An Overview
Ruby is the interpreted scripting language invented by Yukihiro Matsumoto for quick and easy object-oriented programming and is more popular in Japan than in other countries. Ruby's open-source nature makes it free for anyone to use. All data structures in Ruby are objects, but you can add methods to a class or instance of a class during runtime. Because of this, any instance class can behave differently from other instances of the same class. Ruby's dynamic typing nature doesn't require explicit declaration of variable types. It features a true mark-and-sweep garbage collector that cleans all Ruby objects without needing to maintain a reference count. (See www.ruby-lang.org for the complete features of Ruby.) The following libraries are developed with Ruby:
# Ruby/DBI: To access different databases
# Ruby/LDAP: To search and operate on entries in the LDAP
# XSLT4R: For XSL transformation
# XMLRPC4R: For writing and accessing Web services
# SOAP4R: For writing and accessing Web services
SOAP Programming Using Ruby
SOAP4R is the implementation of Simple Object Access Protocol for Ruby developed by Hiroshi Nakamura. SOAP4R depends on the XML processor, http-access, logging, and date-time packages. (To install SOAP4R and its dependencies refer to its home page at www.jin.gr.jp/~nahi/Ruby/SOAP4R.)
Develop SOAP4R clients
The SOAP::Driver class provides support for writing SOAP client applications using Ruby. I'll explain how to use this class in order to develop the SOAP client. To invoke a SOAP Service the client should know the URL of the SOAP Service, namespace of the service methods, and the names of the service methods and their parameters. With this information let's develop a SOAP client in Ruby.
I've chosen a "SendEmail" Web service that is listed in Xmethods' Web services list. The client we're developing invokes a service named SendEmail to send an e-mail message to any mail address (see Listing 1).
In the first line I load the feature "soap/ driver", which implements the SOAP::Driver class. Then I define four constants like NAMESPACE, URL, SOAPACTION, and HTTP_ PROXY, which are required to create an instance of SOAP::Driver class by calling its new method.
driver = SOAP::Driver.new(log, logId, namespace ,
endpoint, httpProxy, soapAction )
Where
namespace = namespace to use for RPC calls
endpoint = URL of the SOAP service
httpproxy = to specify the proxy server,
instead of direct connection to SOAP server
soapaction = value for SOAPAction field of the SOAP Header
After creating an instance of the driver class, call the addMethod method passing the name of the SOAP service method and its parameters' names. SOAP method parameters are often not taken into account on the SOAP server side but it is important to know the order of the parameters that were passed to the service.
The SOAP::Driver class has two methods to add service methods:
SOAP::Driver.addMethod(name, *paramArg)
SOAP::Driver.addMethodWithSOAPAction(name, soapaction, *paramArg)
Where name = the name of the remote procedure
soapaction = soap action header to be used instead
of the default one specified on SOAPDrivers newmethod
paramArg = to specify the names and modes of the remote
procedures parameters. The parameter modes are input parameter,
output parameter or in out parameter.
After adding the service method to the Driver class, invoke it by passing the parameters with values.
SOAPDriver::ServiceMethod( *paramvaluesArg)
Where ServiceMethod is the name of the remote procedure, that was added using addMethod API.
The Web services client is now ready for testing. Test the client using the following command:
ruby SendEmail.rb
Just three steps are needed to develop a Web services client using SOAP4R.
Develop SOAP4R Services
SOAP4R supports the following servers:
# CGI/Fast CGI-based servers (SOAP::CGI Stub)
# Stand-alone server (SOAP::Standalone Server)
Now let's look at how to develop services using the stand-alone server. I'll develop a temperature conversion service that converts the temperature from Celsius to Fahrenheit (see Listing 2).
Develop a class called Temperature_ Conversion_Server and inherit from SOAP:: StandaloneServer, which inherits from SOAP:Server.
class Temperature_Conversion_Server
< SOAP::StandaloneServer
# declare methods
# define methods
end
Declare your service methods by overriding the methodDef method in the StandaloneServer. For example, convert_to_ Fahrenheit, which takes degrees as input parameters:
def methodDef addMethod(self,
'convert_to_Fahrenheit', 'degrees' )
end
The methodDef method is implicitly called from SOAP::Server's initialize method, which exposes one of the following two ser-vice methods.
Class Server < Devel::Application
def addMethod( receiver, methodName, *paramArg )
end
def addMethodWithNS( namespace, receiver, methodName, *paramArg )
end
end
Where
Receiver = the object which contains the methodName method.
Use "self" if the service method is in the same class
methodName = the name of the method that is called through an RPC request
paramArg = to specify the parameter names and parameter modes
namespace = in order to specify the namespace for the method.
Use this if you want different namespace for each method.
After you declare the service method, define it as:
def convert_to_Fahrenheit( degrees )
temp = (9*degrees + 160)/5
return temp
end
The StandaloneServer constructor looks like:
class StandaloneServer < Server
def initialize( appName, namespace, host = "127.0.0.1", port = 8080 )
end
appName - to specify the applications log Id paramters
namespace - Namespace parameters apply to default namespace
for all the service methods.app host to specify the server
host by default it is local host i.e "127.0.0.1",
port to specify the port number for the server ,
by default it is 8080.
Create an instance of the StandaloneServer class and start the server:
myServer = Temperature_Conversion_Server.new('ConversionServer',
'urn:ruby:conversionservice', 'localhost', 8080)
myServer.start
The temperature conversion service is now ready for testing. Start the server using the following command:
ruby ConversionServer.rb
Develop a Web service client application to test the Temperature conversion service (see Listing 3) and test the service using the command:
ruby ConversionClient.rb
In order to monitor the Web service traffic (i.e, SOAP Request and SOAP Response), run the monitor application, which is included with the XML-RPC samples.
Conclusion
It's easy to develop Web services with Ruby. SOAP4R supports logging for the client side and server side as well and supports the user-defined data types. SOAP4R provides the ability to customize the mapping between the Ruby and the SOAP Types. It has good support for SOAP Parameters like IN, OUT, INOUT, and return, and supports WSDL as well. Refer to the samples that come with SOAP4R for more information.
References
# Ruby: www.ruby-lang.org/en/
# SOAP4R: www.jin.gr.jp/~nahi/Ruby/SOAP4R
An Overview
Ruby is the interpreted scripting language invented by Yukihiro Matsumoto for quick and easy object-oriented programming and is more popular in Japan than in other countries. Ruby's open-source nature makes it free for anyone to use. All data structures in Ruby are objects, but you can add methods to a class or instance of a class during runtime. Because of this, any instance class can behave differently from other instances of the same class. Ruby's dynamic typing nature doesn't require explicit declaration of variable types. It features a true mark-and-sweep garbage collector that cleans all Ruby objects without needing to maintain a reference count. (See www.ruby-lang.org for the complete features of Ruby.) The following libraries are developed with Ruby:
# Ruby/DBI: To access different databases
# Ruby/LDAP: To search and operate on entries in the LDAP
# XSLT4R: For XSL transformation
# XMLRPC4R: For writing and accessing Web services
# SOAP4R: For writing and accessing Web services
SOAP Programming Using Ruby
SOAP4R is the implementation of Simple Object Access Protocol for Ruby developed by Hiroshi Nakamura. SOAP4R depends on the XML processor, http-access, logging, and date-time packages. (To install SOAP4R and its dependencies refer to its home page at www.jin.gr.jp/~nahi/Ruby/SOAP4R.)
Develop SOAP4R clients
The SOAP::Driver class provides support for writing SOAP client applications using Ruby. I'll explain how to use this class in order to develop the SOAP client. To invoke a SOAP Service the client should know the URL of the SOAP Service, namespace of the service methods, and the names of the service methods and their parameters. With this information let's develop a SOAP client in Ruby.
I've chosen a "SendEmail" Web service that is listed in Xmethods' Web services list. The client we're developing invokes a service named SendEmail to send an e-mail message to any mail address (see Listing 1).
In the first line I load the feature "soap/ driver", which implements the SOAP::Driver class. Then I define four constants like NAMESPACE, URL, SOAPACTION, and HTTP_ PROXY, which are required to create an instance of SOAP::Driver class by calling its new method.
driver = SOAP::Driver.new(log, logId, namespace ,
endpoint, httpProxy, soapAction )
Where
namespace = namespace to use for RPC calls
endpoint = URL of the SOAP service
httpproxy = to specify the proxy server,
instead of direct connection to SOAP server
soapaction = value for SOAPAction field of the SOAP Header
After creating an instance of the driver class, call the addMethod method passing the name of the SOAP service method and its parameters' names. SOAP method parameters are often not taken into account on the SOAP server side but it is important to know the order of the parameters that were passed to the service.
The SOAP::Driver class has two methods to add service methods:
SOAP::Driver.addMethod(name, *paramArg)
SOAP::Driver.addMethodWithSOAPAction(name, soapaction, *paramArg)
Where name = the name of the remote procedure
soapaction = soap action header to be used instead
of the default one specified on SOAPDrivers newmethod
paramArg = to specify the names and modes of the remote
procedures parameters. The parameter modes are input parameter,
output parameter or in out parameter.
After adding the service method to the Driver class, invoke it by passing the parameters with values.
SOAPDriver::ServiceMethod( *paramvaluesArg)
Where ServiceMethod is the name of the remote procedure, that was added using addMethod API.
The Web services client is now ready for testing. Test the client using the following command:
ruby SendEmail.rb
Just three steps are needed to develop a Web services client using SOAP4R.
Develop SOAP4R Services
SOAP4R supports the following servers:
# CGI/Fast CGI-based servers (SOAP::CGI Stub)
# Stand-alone server (SOAP::Standalone Server)
Now let's look at how to develop services using the stand-alone server. I'll develop a temperature conversion service that converts the temperature from Celsius to Fahrenheit (see Listing 2).
Develop a class called Temperature_ Conversion_Server and inherit from SOAP:: StandaloneServer, which inherits from SOAP:Server.
class Temperature_Conversion_Server
< SOAP::StandaloneServer
# declare methods
# define methods
end
Declare your service methods by overriding the methodDef method in the StandaloneServer. For example, convert_to_ Fahrenheit, which takes degrees as input parameters:
def methodDef addMethod(self,
'convert_to_Fahrenheit', 'degrees' )
end
The methodDef method is implicitly called from SOAP::Server's initialize method, which exposes one of the following two ser-vice methods.
Class Server < Devel::Application
def addMethod( receiver, methodName, *paramArg )
end
def addMethodWithNS( namespace, receiver, methodName, *paramArg )
end
end
Where
Receiver = the object which contains the methodName method.
Use "self" if the service method is in the same class
methodName = the name of the method that is called through an RPC request
paramArg = to specify the parameter names and parameter modes
namespace = in order to specify the namespace for the method.
Use this if you want different namespace for each method.
After you declare the service method, define it as:
def convert_to_Fahrenheit( degrees )
temp = (9*degrees + 160)/5
return temp
end
The StandaloneServer constructor looks like:
class StandaloneServer < Server
def initialize( appName, namespace, host = "127.0.0.1", port = 8080 )
end
appName - to specify the applications log Id paramters
namespace - Namespace parameters apply to default namespace
for all the service methods.app host to specify the server
host by default it is local host i.e "127.0.0.1",
port to specify the port number for the server ,
by default it is 8080.
Create an instance of the StandaloneServer class and start the server:
myServer = Temperature_Conversion_Server.new('ConversionServer',
'urn:ruby:conversionservice', 'localhost', 8080)
myServer.start
The temperature conversion service is now ready for testing. Start the server using the following command:
ruby ConversionServer.rb
Develop a Web service client application to test the Temperature conversion service (see Listing 3) and test the service using the command:
ruby ConversionClient.rb
In order to monitor the Web service traffic (i.e, SOAP Request and SOAP Response), run the monitor application, which is included with the XML-RPC samples.
Conclusion
It's easy to develop Web services with Ruby. SOAP4R supports logging for the client side and server side as well and supports the user-defined data types. SOAP4R provides the ability to customize the mapping between the Ruby and the SOAP Types. It has good support for SOAP Parameters like IN, OUT, INOUT, and return, and supports WSDL as well. Refer to the samples that come with SOAP4R for more information.
References
# Ruby: www.ruby-lang.org/en/
# SOAP4R: www.jin.gr.jp/~nahi/Ruby/SOAP4R
The Philosophy of Ruby
Summary
Yukihiro Matsumoto, the creator of the Ruby programming language, talks with Bill Venners about Ruby's design philosophy, including design imperfection, the danger of orthogonality, and the importance of the human in computer endeavors.
Yukihiro Matsumoto, the creator of the Ruby programming language, talks with Bill Venners about Ruby's design philosophy, including design imperfection, the danger of orthogonality, and the importance of the human in computer endeavors.
Yukihiro Matsumoto, or "Matz," as he is known online, is the creator of the Ruby programming language. Ruby is an object-oriented language suitable for writing day to day scripts as well as full-scale applications. Matz began work on Ruby back in 1993, because he wanted a language that made him productive while being fun to use. Initially popular in Japan, Ruby has been finding its way into the hearts of programmers all over the world.
On September 24, 2003, Bill Venners met with Yukihiro Matsumoto at the JAOO conference in Aarhus, Denmark. In this interview, which will be published in multiple installments on Artima.com, Yukihiro Matsumoto discusses Ruby's design philosopy, the features of the Ruby language, and becoming a better programmer. In this initial installment, Matz waxes philosophic about design imperfection, the danger of orthogonality, granting freedom with guidance, the principle of least surprise, and the importance of the human in computer endeavors.
No Perfect Language
Bill Venners: Dave Thomas, coauthor of Programming Ruby: A Pragmatic Programmer's Guide, told me that you don't think a language design should be perfect. Why not?
Yukihiro Matsumoto: Language designers want to design the perfect language. They want to be able to say, "My language is perfect. It can do everything." But it's just plain impossible to design a perfect language, because there are two ways to look at a language. One way is by looking at what can be done with that language. The other is by looking at how we feel using that language—how we feel while programming.
Because of the Turing completeness theory, everything one Turing-complete language can do can theoretically be done by another Turing-complete language, but at a different cost. You can do everything in assembler, but no one wants to program in assembler anymore. From the viewpoint of what you can do, therefore, languages do differ—but the differences are limited. For example, Python and Ruby provide almost the same power to the programmer.
Instead of emphasizing the what, I want to emphasize the how part: how we feel while programming. That's Ruby's main difference from other language designs. I emphasize the feeling, in particular, how I feel using Ruby. I didn't work hard to make Ruby perfect for everyone, because you feel differently from me. No language can be perfect for everyone. I tried to make Ruby perfect for me, but maybe it's not perfect for you. The perfect language for Guido van Rossum is probably Python.
Orthogonal versus Harmonious
Bill Venners: Dave Thomas also claimed that if I ask you to add a feature that is orthogonal, you won't do it. What you want is something that's harmonious. What does that mean?
Yukihiro Matsumoto: I believe consistency and orthogonality are tools of design, not the primary goal in design.
Bill Venners: What does orthogonality mean in this context?
Yukihiro Matsumoto: An example of orthogonality is allowing any combination of small features or syntax. For example, C++ supports both default parameter values for functions and overloading of function names based on parameters. Both are good features to have in a language, but because they are orthogonal, you can apply both at the same time. The compiler knows how to apply both at the same time. If it's ambiguous, the compiler will flag an error. But if I look at the code, I need to apply the rule with my brain too. I need to guess how the compiler works. If I'm right, and I'm smart enough, it's no problem. But if I'm not smart enough, and I'm really not, it causes confusion. The result will be unexpected for an ordinary person. This is an example of how orthogonality is bad.
Bill Venners: In other words, the orthogonal features will work once the compiler writer understands them and gets them to work. But it is hard for programmers to understand it when they look at it, because it is complicated, because I have to figure out how these two things go together.
Yukihiro Matsumoto: The orthogonal features, when combined, can explode into complexity.
Bill Venners: So what's the alternative? What would be more harmonious?
Yukihiro Matsumoto: Just pick up one of those two to put into the language. You don't have to do everything that you can think of. You need to pick one of them, even though both are good.
Freedom and Comfort
Bill Venners: One of the design philosophies in the Python community is providing one and only one way to do things. If you provide fifty different ways to do the same thing, then you've provided convenience for code writers. People can write things in their favorite way. The tradeoff is for code readers. When I read your code, you might have written it one way. When I read the next person's code, they may have written it another way. So as a reader I end up needing to be familiar with all ways to accomplish the task, not just my favorite way of writing it. That's the design tradeoff. The Python community seems to prefer the one and only one way approach, but Ruby seems to provide multiple ways to do the same thing.
Yukihiro Matsumoto: Ruby inherited the Perl philosophy of having more than one way to do the same thing. I inherited that philosophy from Larry Wall, who is my hero actually. I want to make Ruby users free. I want to give them the freedom to choose. People are different. People choose different criteria. But if there is a better way among many alternatives, I want to encourage that way by making it comfortable. So that's what I've tried to do. Maybe Python code is a bit more readable. Everyone can write the same style of Python code, so it can be easier to read, maybe. But the difference from one person to the next is so big, providing only one way is little help even if you're using Python, I think. I'd rather provide many ways if it's possible, but encourage or guide users to choose a better way if it's possible.
The Joy of Ruby
Bill Venners: In an introductory article on Ruby, you wrote, "For me the purpose of life is partly to have joy. Programmers often feel joy when they can concentrate on the creative side of programming, So Ruby is designed to make programmers happy." How can Ruby make programmers happy?
Yukihiro Matsumoto: You want to enjoy life, don't you? If you get your job done quickly and your job is fun, that's good isn't it? That's the purpose of life, partly. Your life is better.
I want to solve problems I meet in the daily life by using computers, so I need to write programs. By using Ruby, I want to concentrate the things I do, not the magical rules of the language, like starting with public void something something something to say, "print hello world." I just want to say, "print this!" I don't want all the surrounding magic keywords. I just want to concentrate on the task. That's the basic idea. So I have tried to make Ruby code concise and succinct.
Bill Venners: Allowing programmers to write code that's concise and succinct is one way to make them happy.
Yukihiro Matsumoto: Yes, so they can concentrate on the problem itself. Sometimes people jot down pseudo-code on paper. If that pseudo-code runs directly on their computers, it's best, isn't it? Ruby tries to be like that, like pseudo-code that runs. Python people say that too.
Bill Venners: Yes, Python people do say that Python is executable pseudo-code. What else is in Ruby to make programmers happy?
Yukihiro Matsumoto: In our daily lives as programmers, we process text strings a lot. So I tried to work hard on text processing, namely the string class and regular expressions. Regular expressions are built into the language and are very tuned up for use. We also need to call into the operating system a lot. Ruby can call every system call in Unix and most of the Windows API. This brings the power and function of the operating system to the interpretive language environment. So you can do daily systems administration and text processing programming. That's the major domain of at least my life, so I worked hard on making that good.
Bill Venners: So basically Ruby helps me enjoy my life by helping me get my job done more quickly and with more fun?
Yukihiro Matsumoto: It helps me do that. I'm not sure Ruby works for you, but I hope so.
The Human Factor
Bill Venners: In an interview, you said, "Don't underestimate the human factor. Even thought we are in front of computers, they are media. We are working for human, with human." What do you mean by that?
Yukihiro Matsumoto: Imagine you are writing an email. You are in front of the computer. You are operating the computer, clicking a mouse and typing on a keyboard, but the message will be sent to a human over the internet. So you are working before the computer, but with a human behind the computer. Most of the tasks we do are for humans. For example, a tax calculation is counting numbers so the government can pull money out from my wallet, but government consists of humans.
Most of our tasks are related to humans after all. So in programming, either we ask the computer to work for a human, or we describe our thoughts to a computer in a very unambiguous way that even computer can execute. In the first case, making the computer work for humans, the target is a human through the computer. In the second case, expressing our thoughts clearly enough to be understood and executed by computers, we express intent from our human brains and as a result it is performed by the computers. So in both cases the object here is human.
Bill Venners: What is important about thinking that way? You say, "Don't underestimate the human factor." Why?
Yukihiro Matsumoto: Because computers don't mind if I must make effort to communicate with them or if it is easy to communicate with them. They don't care if I put the numbers of instruction byte sequences in a file and feed it to them to run, or if a very high level language generated the instructions. The computers don't care. We humans care about the effort we pay. Often people, especially computer engineers, focus on the machines. They think, "By doing this, the machine will run faster. By doing this, the machine will run more effectively. By doing this, the machine will something something something." They are focusing on machines. But in fact we need to focus on humans, on how humans care about doing programming or operating the application of the machines. We are the masters. They are the slaves.
Bill Venners: For the time being anyway.
Yukihiro Matsumoto: For the time being anyway, until the age of Terminator.
Principle of Least Surprise
Bill Venners: In an interview, you said "I designed Ruby to minimize my surprise. I was very amazed when people around the world told me that Ruby reduced their surprise and enhanced their joy of programming. Now I'm pretty sure that programmer's minds are alike all over the world." Why the principle of least surprise?
Yukihiro Matsumoto: Actually, I didn't make the claim that Ruby follows the principle of least surprise. Someone felt the design of Ruby follows that philosophy, so they started saying that. I didn't bring that up, actually.
I wanted to minimize my frustration during programming, so I want to minimize my effort in programming. That was my primary goal in designing Ruby. I want to have fun in programming myself. After releasing Ruby and many people around the world got to know Ruby, they said they feel the way I feel. They came up with the phrase the principle of least surprise. But actually, it's often misunderstood.
Bill Venners: How is it misunderstood?
Yukihiro Matsumoto: Everyone has an individual background. Someone may come from Python, someone else may come from Perl, and they may be surprised by different aspects of the language. Then they come up to me and say, "I was surprised by this feature of the language, so therefore Ruby violates the principle of least surprise." Wait. Wait. The principle of least surprise is not for you only. The principle of least surprise means principle of least my surprise. And it means the principle of least surprise after you learn Ruby very well. For example, I was a C++ programmer before I started designing Ruby. I programmed in C++ exclusively for two or three years. And after two years of C++ programming, it still surprised me.
Tuesday, March 13, 2007
The death of computing science discipline
Neil McBride says computer science was populated by mathematicians and physicists but now virtual robots can be created by eight-year olds without needing programming, logic or discrete mathematics skills. Does that mean we have a dying discipline?
We all know there's a crisis in university computer science departments. Student numbers are dwindling - down 115 just last year.
At the same time the computing unit of funding has fallen. And the onset of fees has made students think twice about joining a profession where the plethora of new jobs in the 1990s has reduced to a trickle and it's only just looking as if employment prospects may be on the upturn.
Dropping numbers of A Level students, a view that IT is a job for geeks and social misfits and a perception that there’s nothing interesting in computer science doesn’t help. Even the value of the research base is being questioned.
And the problem's global. In the US, the number of students choosing computer science dropped by 39 per cent between 2000 and 2005. In Australia, cuts in IT academic staff are the order of the day.
In such dire circumstances, it's tempting to hanker after the glory days when computer science ruled, departments were full, and students flocked to a leading edge discipline where the ideas were fresh.
It's easy to be nostalgic about the days when the income from computer science subsidised other departments and computing was the Prince of the university not the Cinderella.
We long for the days when assembler programming ruled, when programming was exciting and leading edge, when distributed computers were being created and there were uncharted vistas of applications to be written, and single applications such as ledgers and transaction systems transformed businesses. But that is the past. Today the ship is holed below the waterline.
As the ship sinks, we computer scientists fiddle on the deck hoping to avoid the icy waters. We claim, as the President of the BCS has recently, that there is still a massive need for computing students in the UK today.
We look to games programming for our salvation, designing games programming courses and reducing a wide-ranging industrial discipline to a set of geeks programming computers to zap spacecraft and dismember aliens.
It's a sorry sight to see computing academics fighting for the last few lifeboats. But the heyday of massive liners, full of programmers, plying the commercial sea-lanes is over. There may be room for a few luxury liners, but most of us fly on budget airlines.
It's easy to think that the problem is that people (read potential students) just don't understand how exciting computing is and that this can be fixed by a bit of sharp marketing, slick videos and some school visits. But the students are not that gullible. The real nature of the problem lies at the roots of the discipline.
Something significant has changed. There is the smell of death in the air.
In the early days, computer science was populated by mathematicians and physicists excited at the prospect of vastly accelerated computation. New languages were developed. FORTRAN, Algol, COBOL, and PL/1 took root. The foundations of programming were laid.
There was excitement at making the computer do anything at all. Manipulating the code of information technology was the realm of experts: the complexities of hardware, the construction of compliers and the logic of programming were the basis of university degrees.
The power of hardware has increased, as IBM 370s in air-conditioned warehouses gave way to computers in the home and advanced robots become this year's Christmas toy.
However, the basics of programming have not changed. The elements of computing are the same as fifty years ago, however we dress then up as object-oriented computing or service-oriented architecture. What has changed is the need to know low-level programming or any programming at all. Who needs C when there's Ruby on Rails?
Now vastly complex applications for businesses, for science and for leisure can be developed using sophisticated high-level tools and components.
Virtual robots - Zooks - can be created by eight-year olds without needing programming, logic or discrete mathematics skills. Web designers build complex business sites, graphic designers build animations, accountants assemble business systems without needing to go object-oriented.
Computer science has lost its mystique. There is no longer a need for a vast army of computer scientists. The applications, games and databases that students once built laboriously in final year projects are bought at bookshops and newsagents.
If the gap between public knowledge and academic curriculum isn't large enough, the gap between academia and industry practice is a gaping hole. While academic departments concentrate on developing new computer systems in an ideal organisational environment, a lot of industry has moved away from in-house development to a focus on delivering a service.
As commercial software products have matured, it no longer makes sense for organisations to develop software from scratch.
Accounting packages, enterprise resource packages, customer relationship management systems are the order of the day: stable, well-proven and easily available. IT departments now focus on contracts, tenders, service level agreements, training, system usage and incident management.
Interrupts, loops, algorithms, formal methods are not on the agenda. IT is about deploying resources to meet the information needs of its customers.
Implementation, facility management, systems integration, service management, organisational change even environmental audit are the language of IT. These hardly feature on computer science courses.
The environment within which computing operates in the 21 century is dramatically different to that of the 60s, 70s, 80s and even early 90s. Computers are an accepted part of the furniture of life, ubiquitous and commoditised.
Like cars, a limited number of people are interested in their construction, more live by supporting and maintaining them; most of us accept them as a black box, whose workings are of no interest but which confer status, freedom and convenience.
Indeed, whereas building a new car needs mechanical know-how, building a new computer application can be done by the user who has no grounding in computer science.
Computing is also affected by globalisation. The loss of jobs in IT and the declining computer science enrolments is a global problem for developed countries. Since the software product can be transmitted almost instantaneously, why develop it in expensive facilities in the west?
Armies of highly trained computer scientists are available in India, Sri Lanka and China. The expertise is easily off-shored. In India, over 100,000 new IT graduates a year are ready to support an off-shored IT industry.
Companies like Microsoft, Hewlett-Packard and Siemens have well established software development operations in India. Why are we not co-operating more with the Indian IT industry?
So where does that leave computing departments in universities? Do we pull up the drawbridge of the castle of computational purity and adopt a siege mentality: a band of brothers fighting to the last man? Or do we recognise that the discipline is dying if not actually dead, and breathing shallowly.
The old man has run his race well. He has changed the nature of human existence. Do we let go gently, realising that the discipline has run its course? The actual problem is one of the perception of the proponents of our discipline, not the potential students.
The old generation needs to look to a new generation, to new approaches. The focus is moving away from system construction. The jobs are in the application of technology. There is a need to be closer to the application, closer to the user, to replace a reductionist, convergent discipline with a complex, divergent discipline.
The complexity of embedded systems, of modern computing applications requires a different way of thinking. A reductionist, programming mindset does not adapt well to uncertainty, emergent behaviour, the unexpected and the study of the whole.
Relationships are important. The new computing discipline will really be an inter-discipline, connecting with other spheres, working with diverse scientific and artistic departments to create new ideas. Its strength and value will be in its relationships.
There is a need for innovation, for creativity, for divergent thinking which pulls in ideas from many sources and connects them in different ways.
The new computing department will be the department of interdisciplinary studies, drawing ideas from biology, design, history, medicine and contributing a rich computing foundation to those disciplines. It will be looking outwards rather than inwards, concerned to address the vast landscapes of computing application.
So how many computer science departments will exist in 30 years time? Perhaps a few will support the elite luxury liners. Most will have given way to interdisciplinary study departments, and computing service departments, producing innovative graduates who can corral and manage the IT resources organisations need.
Computer science curricula are old, stale and increasing irrelevant. Curricula needs to be vocational, and divergent, widening the computing student's view of the world, not creating a sterile bubble, closed off from the wider issues in the world, and from the networking, the integration, the global reach of computers.
There is a need for a drastic rethinking of what the discipline is about. There is a need for new curricula which represents a real paradigm shift, not just a move from keyboards to pen computing.
Here at De Montfort I run an ICT degree, which does not assume that programming is an essential skill. The degree focuses on delivering IT services in organisations, on taking a holistic view of computing in organisations, and on holistic thinking.
Perhaps this represents an early move towards a new kind of computing discipline. As the roots rot and the tree falls a vast array of new saplings appear. Those saplings may be the start of a new inter-discipline: new computing for the 21st century.
Neil McBride is a principal lecturer in the School of Computing, De Montfort University.
Monday, March 12, 2007
Tribute to Major General Hamangoda - A noble death for a noble cause
A valiant officer's sudden loss is irreparable to his motherland and its natives, in the sense that the making of a fully-fledged soldier itself is not only a question of time, but also a process for embodiment of many other factors such as proper command, decision-making, valour, strategy, values, etc. to name a few.
The Army, in its lifespan of over 50 years while simultaneously transforming itself to be one of the most challenging and battle-hardened professional outfits, deviating from its former ceremonial role, hitherto perhaps remains the only organ that has so far produced the finest assortment of military leaders for the country, fondly remembered by right-thinking countrymen in all corners of our country. They certainly laid down their lives for others, and to make our tomorrow better.
Ten years seems such a long time, and yet the memories of our protagonist, Major General Ananda Sri Sisira Kumara Hamangoda USP Msc Psc, popularly called, 'Ananda' is vivid among many of his associates and fellow military men who used to admire him as a source of strength and inspiration.
Major General Hamangoda's sudden demise on July 4, 1996 following an LTTE suicide attack with several other soldiers in the heart of
My close association with General Hamangoda, though he was senior to me, dates back to our good old days in school at Kurunegala Maliyadeva College in the early 1970s, where General Ananda excelled in many spheres as sportsman, student leader, house-captain, senior cadet, and more importantly, as the school's best orator, thus bringing fame to our Alma Mater.
Budding Ananda was exemplary, energetic, innovative, admired and often picked by our Principals and teachers alike as a role model for the school. He was the captain for the school's badminton team in 1971 and in the same year he won the Gold Medal for overall best performance in the school. We, as juniors in the college looked up to him with respect as a prefect, beacon of hope and a guiding light.
His exit from the college saw his enlistment to the Sri Lanka Army (Regular Force) as cadet officer in 1973 and to receive his commission later on as a Second Lieutenant in the 4th Regiment of Sri Lanka Artillery. From that stage onwards, the Second Lieutenant Hamangoda turned Lieutenant in 1976, Captain in 1979, Major in 1983, Lieutenant Colonel in 1990, Colonel in 1994 and finally Brigadier on 15th November 1995 before he suddenly departed us. His reach to the mantle of his career was only through his commitment to the cause and his brilliant approach to situations, no matter what it got to be.
The warrior, Ananda was posthumously promoted to the rank of Major General after his supreme sacrifice in 1996 in recognition of his achievements.
His illustrious, dedicated and exemplary career in the Army was not without productive results or cherished memories. For two years (1981-1983) he served as Adjutant for his own 4th Regiment of Sri Lanka Artillery before he was posted to the Staff Officer appointment in the 5th Regiment of Sri Lanka Artillery (Volunteer) for about two years.
With the rapid expansion of the Army, he on his own initiative raised a new Field Battery in the newly founded 6th Regiment of Sri Lanka Artillery and became its first Battery Commander.
Afterwards he was also appointed the first Second in Command in the newly raised 7th Light Artillery Regiment in November 1988, particularly taking stock of his excellent and extensive knowledge on Artillery, and his wide experience in the battlefield.
His dedication towards the Artillery Regiment, judged by all what he did, was commendable and has gone on record as a warrior who rendered a yeoman service to the Regiment with the help of his ocean of knowledge and experience.His distinguished tenure of service spanning about 23 years covered almost every corner of our beloved motherland, including war-torn operational areas in the north and east. He was an arch-enemy to separatists.
His expertise derived from various professional study courses, both at home and abroad, needless to mention, kept him in good stead and served him very well in his pursuit of professionalism in all of his undertakings.
Until his supreme sacrifice, Major General Hamangoda braved relentlessly to defend the territorial integrity of this island-nation with thousands of his fellow troops amidst enemy fire, on many occasions, even at the risk of his own life.
Needless to say, his warfare was professional and needed elaborate planning. His proven ability to execute operations after meticulous hard work and subsequent successful launch of them against the enemy came in for high praise of his superiors, and his enthusiastic valour was therefore well recognised with the conferment of medals such as Uttama Seva Padakkama (USP), Long Service Medal for Sri Lanka Armed Forces, Vadamarachchi Operations Medal, President's Accession Medal and Poornabhumi Padakkama, to cite a few.
His sporting prowess in cricket, volleyball as well as in boxing contributed immensely to the promotion of sports activities in the Army while helping the Army to produce a number of Army sportsmen of national and international standards. Thanks to his selfless commitment, all those projects are still on. Major General A. S. S. K. Hamangoda remains close to the hearts of his fellow schoolmates as a character par excellence that symbolised many, a talented and brave officer to all Army personnel, and not least, a wonderful husband and father to his bereaved family, Mrs. Indrani Hamangoda, son Dulshan and his daughters Buweni and Maheshani.
As Field Marshal Viscount Montgomery once quipped, "The good General is the one who wins his battles with the fewest possible casualties," late Major General Hamangoda, as one of the Army's best products during the most critical junctures of our recent history, fulfilled his sacred mission to the best of his ability and for the greater benefit of our society. His sense of humour, rich with vituperative jokes brought his associates closer to him whenever and wherever they met, no matter what the occasion was.
Such was his simplicity amidst a gathering of his friends and others because General Ananda wanted to be fair by all at all times, in spite of his formal ranks.
So, farewell, dear Sir until we meet again in this journey of Samsara. May you attain supreme bliss of Nibbana!
-Bgdr DR
Wednesday, March 07, 2007
Thursday, March 01, 2007
Introducing iPhone
iPhone combines three amazing products — a revolutionary mobile phone, a widescreen iPod with touch controls, and a breakthrough Internet communications device with desktop-class email, web browsing, maps, and searching — into one small and lightweight handheld device. iPhone also introduces an entirely new user interface based on a large multi-touch display and pioneering new software, letting you control everything with just your fingers. So it ushers in an era of software power and sophistication never before seen in a mobile device, completely redefining what you can do on a mobile phone.
Monday, February 26, 2007
Richest man's Richest attitude
There was a one hour interview on CNBC with Warren Buffet, the second
richest man who has donated $31 billion (85% of his fortune) to charity.
Here are some very interesting aspects of his life:
1) He bought his first share at age 11 and he now regrets that he started too late!
2) He bought a small farm at age 14 with savings from delivering newspapers.
3) He still lives in the same small 3 bedroom house in mid-town Omaha, that he bought after he got married 50 years ago. He says that he has everything he needs in that house. His house does not have a wall or a fence.
4) He drives his own car everywhere and does not have a driver or security people around him.
5) He never travels by private jet, although he owns the world's largest private jet company.
6) His company, Berkshire Hathaway, owns 63 companies. He writes only one letter each year to the CEOs of these companies, giving them goals for the year. He never holds meetings or calls them on a regular basis.
7) He has given his CEO's only two rules.
Rule number 1: Do not lose any of your share holder's money.
Rule number 2: Do not forget rule number 1.
8) He does not socialize with the high society crowd. His past time after he gets home is to make himself some pop corn and watch television.
9) Bill Gates, the world's richest man met him for the first time only 5 years ago. Bill Gates did not think he had anything in common with Warren Buffet. So he had scheduled his meeting only for half hour. But when Gates met him, the meeting lasted for ten hours and Bill Gates became a devotee of Warren Buffet.
10) Warren Buffet does not carry a cell phone, nor has a computer on his desk.
11) His advice to young people: Stay away from credit cards and invest in yourself.
richest man who has donated $31 billion (85% of his fortune) to charity.
Here are some very interesting aspects of his life:
1) He bought his first share at age 11 and he now regrets that he started too late!
2) He bought a small farm at age 14 with savings from delivering newspapers.
3) He still lives in the same small 3 bedroom house in mid-town Omaha, that he bought after he got married 50 years ago. He says that he has everything he needs in that house. His house does not have a wall or a fence.
4) He drives his own car everywhere and does not have a driver or security people around him.
5) He never travels by private jet, although he owns the world's largest private jet company.
6) His company, Berkshire Hathaway, owns 63 companies. He writes only one letter each year to the CEOs of these companies, giving them goals for the year. He never holds meetings or calls them on a regular basis.
7) He has given his CEO's only two rules.
Rule number 1: Do not lose any of your share holder's money.
Rule number 2: Do not forget rule number 1.
8) He does not socialize with the high society crowd. His past time after he gets home is to make himself some pop corn and watch television.
9) Bill Gates, the world's richest man met him for the first time only 5 years ago. Bill Gates did not think he had anything in common with Warren Buffet. So he had scheduled his meeting only for half hour. But when Gates met him, the meeting lasted for ten hours and Bill Gates became a devotee of Warren Buffet.
10) Warren Buffet does not carry a cell phone, nor has a computer on his desk.
11) His advice to young people: Stay away from credit cards and invest in yourself.
Sunday, February 25, 2007
Saturday, February 24, 2007
If Operating Systems Ran The Airlines...
Different operating systems. Different styles. But what if the quirks and styles of the different operating systems were applied to AIRLINES? What if airlines ran things the way operating systems do? This humorous analogy, applying operating system philosophies as if they were airlines, is a long-standing much-circulated amusing story, and I'd credit the author if I knew who wrote it!
UNIX Airways
Everyone brings one piece of the plane along when they come to the airport. They all go out on the runway and put the plane together piece by piece, arguing non-stop about what kind of plane they are supposed to be building.
Air DOS
Everybody pushes the airplane until it glides, then they jump on and let the plane coast until it hits the ground again. Then they push again, jump on again, and so on...
Mac Airlines
All the stewards, captains, baggage handlers, and ticket agents look and act exactly the same. Every time you ask questions about details, you are gently but firmly told that you don't need to know, don't want to know, and everything will be done for you without your ever having to know, so just shut up.
Windows Air
The terminal is pretty and colourful, with friendly stewards, easy baggage check and boarding, and a smooth take-off. After about 10 minutes in the air, the plane explodes with no warning whatsoever.
Windows NT Air
Just like Windows Air, but costs more, uses much bigger planes, and takes out all the other aircraft within a 40-mile radius when it explodes.
Windows XP Air
You turn up at the airport,which is under contract to only allow XP Air planes. All the aircraft are identical, brightly coloured and three times as big as they need to be. The signs are huge and all point the same way. Whichever way you go, someone pops up dressed in a cloak and pointed hat insisting you follow him. Your luggage and clothes are taken off you and replaced with an XP Air suit and suitcase identical to everyone around you as this is included in the exorbitant ticket cost. The aircraft will not take off until you have signed a contract. The inflight entertainment promised turns out to be the same Mickey Mouse cartoon repeated over and over again. You have to phone your travel agent before you can have a meal or drink. You are searched regularly throughout the flight. If you go to the toilet twice or more you get charged for a new ticket. No matter what destination you booked you will always end up crash landing at Whistler in Canada.
Linux Air
Disgruntled employees of all the other OS airlines decide to start their own airline. They build the planes, ticket counters, and pave the runways themselves. They charge a small fee to cover the cost of printing the ticket, but you can also download and print the ticket yourself.
When you board the plane, you are given a seat, four bolts, a wrench and a copy of the seat-HOWTO.html. Once settled, the fully adjustable seat is very comfortable, the plane leaves and arrives on time without a single problem, the in-flight meal is wonderful. You try to tell customers of the other airlines about the great trip, but all they can say is, "You had to do what with the seat?"
More Interesting topics at http://www.zyra.org.uk/os-air.htm
UNIX Airways
Everyone brings one piece of the plane along when they come to the airport. They all go out on the runway and put the plane together piece by piece, arguing non-stop about what kind of plane they are supposed to be building.
Air DOS
Everybody pushes the airplane until it glides, then they jump on and let the plane coast until it hits the ground again. Then they push again, jump on again, and so on...
Mac Airlines
All the stewards, captains, baggage handlers, and ticket agents look and act exactly the same. Every time you ask questions about details, you are gently but firmly told that you don't need to know, don't want to know, and everything will be done for you without your ever having to know, so just shut up.
Windows Air
The terminal is pretty and colourful, with friendly stewards, easy baggage check and boarding, and a smooth take-off. After about 10 minutes in the air, the plane explodes with no warning whatsoever.
Windows NT Air
Just like Windows Air, but costs more, uses much bigger planes, and takes out all the other aircraft within a 40-mile radius when it explodes.
Windows XP Air
You turn up at the airport,which is under contract to only allow XP Air planes. All the aircraft are identical, brightly coloured and three times as big as they need to be. The signs are huge and all point the same way. Whichever way you go, someone pops up dressed in a cloak and pointed hat insisting you follow him. Your luggage and clothes are taken off you and replaced with an XP Air suit and suitcase identical to everyone around you as this is included in the exorbitant ticket cost. The aircraft will not take off until you have signed a contract. The inflight entertainment promised turns out to be the same Mickey Mouse cartoon repeated over and over again. You have to phone your travel agent before you can have a meal or drink. You are searched regularly throughout the flight. If you go to the toilet twice or more you get charged for a new ticket. No matter what destination you booked you will always end up crash landing at Whistler in Canada.
Linux Air
Disgruntled employees of all the other OS airlines decide to start their own airline. They build the planes, ticket counters, and pave the runways themselves. They charge a small fee to cover the cost of printing the ticket, but you can also download and print the ticket yourself.
When you board the plane, you are given a seat, four bolts, a wrench and a copy of the seat-HOWTO.html. Once settled, the fully adjustable seat is very comfortable, the plane leaves and arrives on time without a single problem, the in-flight meal is wonderful. You try to tell customers of the other airlines about the great trip, but all they can say is, "You had to do what with the seat?"
More Interesting topics at http://www.zyra.org.uk/os-air.htm
Mobitel’s new marketing strategy
This is a true story of a young college girl who passed away last month. Her name was Janaki. She was hit by a lorry. She has a boy friend named Prabath. Both of them are true lovers.
They always hang on the phone. You can never see her without her hand phone. In fact she also changed her phone from Dialog to Mobitel, so both of them can be on the same network, and save on the cost. She spends half of the day talking with Prabath. Janaki's family knows about their relationship. Prabath is very close with Janaki's family. Before she passed away she always told her friends "If I pass away please burn me with my hand phone" she also said the same thing to her parents. \
After her death, people couldn't carry her coffin. A lot of them tried to do so but still couldn't everybody tried to carry the coffin, the result was still the same. Eventually, they called their neighbor, a religious man from a village, who is a friend of her father. He took a stick and started speaking to himself slowly. After a few minutes, he said "this girl misses something here".
Then her friends told the learned man about her wish to burn her with her phone. He then opened the coffin and places her phone and SIM card inside the casket. After that they tried to carry the coffin. It could be moved and they carried it into the van easily. All the people were shocked. (Can u feel the fear? I'm shaking at this moment) Janaki's parents did not inform Prabath that Janaki had passed away.
After 2 weeks Prabath called Janaki's mom. Prabath..."Aunty, I'm coming home today. Cook something nice for me. Don’t tell Janaki that I'm coming home today, I wanna surprise her." Her mother replied....."You come home first, I wanna tell you something very important." after he came, they told him the truth about Janaki.
Prabath thinks that they were playing a fool. He was laughing and said "don’t try to fool me - tell Janaki to come out, I have a gift for her Please stop this nonsense". Then they show him the original death certificate to him. They gave him proof to make him believe. (Prabath started to sweat)
He said... "It’s not true. We spoke yesterday. She still calls me. Prabath was shaking. Suddenly, Prabath's phone rang. "See this is from Janaki, see this..." he showed the phone to Janaki's family. All of them told him to answer. He talked using the loudspeaker mode. All of them heard his conversation.
Loud and clear, no cross lines, no humming. It is the actual voice of Janaki & there is no way others could use her SIM card since it is nailed inside the coffin they were so shocked and asked for the religious mans help again. He brought another religious man along to solve this matter.
They both worked for 5 hours. Then they discovered one thing...
...
...
...
...
...
MOBITEL has the best coverage :) LMAO
Simple solutions
This is a mail i got from my university mailing list. Thought of sharing it here as it's underlying moral is significant most of the BIG thinkers!!!
Case 1
When NASA began the launch of astronauts into space, they found out that the pens would not work at zero gravity (ink will not flow down to the writing surface).
To solve this problem, it took them one decade and $12 million. They developed a pen that worked at zero gravity, upside down, underwater, in practically any surface including crystal and in a temperature range from below freezing to over 300 degrees C. And what did the Russians do...? They used a Pencil!
Case 2
One of the most memorable case studies on Japanese management was the case of the empty soapbox, which happened in one of Japan 's biggest cosmetics companies. The company received a complaint that a consumer had bought a soapbox that was empty.
Immediately the authorities isolated the problem to the assembly line, which transported all the packaged boxes of soap to the delivery department. For some reason, one soapbox went through the assembly line empty. Management asked its engineers to solve the problem. Post-haste, the engineers worked hard to devise an X-ray machine with high-resolution monitors manned by two people to watch all the soapboxes that passed through the line to make sure they were not empty.
No doubt, they worked hard and they worked fast but they spent whoopee amount to do so.
But when a rank-and-file employee in a small company was posed with the same problem, he did not get into complications of X-rays, etc., but instead came out with another solution. He bought a strong industrial electric fan and pointed it at the assembly line. He switched the fan on, and as each soapbox passed the fan, it simply blew the empty boxes out of the line.
Moral
Always look for simple solutions. Let us devise the simplest possible solution that solves the problems.
Case 1
When NASA began the launch of astronauts into space, they found out that the pens would not work at zero gravity (ink will not flow down to the writing surface).
To solve this problem, it took them one decade and $12 million. They developed a pen that worked at zero gravity, upside down, underwater, in practically any surface including crystal and in a temperature range from below freezing to over 300 degrees C. And what did the Russians do...? They used a Pencil!
Case 2
One of the most memorable case studies on Japanese management was the case of the empty soapbox, which happened in one of Japan 's biggest cosmetics companies. The company received a complaint that a consumer had bought a soapbox that was empty.
Immediately the authorities isolated the problem to the assembly line, which transported all the packaged boxes of soap to the delivery department. For some reason, one soapbox went through the assembly line empty. Management asked its engineers to solve the problem. Post-haste, the engineers worked hard to devise an X-ray machine with high-resolution monitors manned by two people to watch all the soapboxes that passed through the line to make sure they were not empty.
No doubt, they worked hard and they worked fast but they spent whoopee amount to do so.
But when a rank-and-file employee in a small company was posed with the same problem, he did not get into complications of X-rays, etc., but instead came out with another solution. He bought a strong industrial electric fan and pointed it at the assembly line. He switched the fan on, and as each soapbox passed the fan, it simply blew the empty boxes out of the line.
Moral
Always look for simple solutions. Let us devise the simplest possible solution that solves the problems.
Wednesday, February 21, 2007
Meet "The Artist" of the Google Logos
More than 150 million Web surfers around the globe celebrated Korean Independence Day Aug. 15, 2001. Well, at least for a few moments while they were visiting the popular Internet search engine Google. That day, the Korean national flag and several roses of Sharon, the Korean national flower, adorned the familiar "Google" logo on the homepage of the Web site.
With its seemingly magical ability to produce the most relevant search results, Google is already an established destination for the Internet savvy. Recently, Hwang's creative logos have been expressing the playful heart of Google behind the impressive technology.
For Piet Mondrian's birthday, Hwang transformed the "Google" logo to emulate the artist's signature style of utilizing colorful blocks. Claude Monet's birthday saw the logo turned into a dreamy watercolor, complete with floating lily pads.
Hwang recently spoke with The Korea Herald to give his take on the artistic side of the popular Internet search engine.
The Korea Herald: How long did you live in Korea as a child? What was it like?
Dennis Hwang: I was born in Knoxville, Tenn., but moved to Korea when I was about five years old. My hometown was Gwacheon where I had a very normal childhood. I went through public schools like everyone else, spending six years at Gwacheon Elementary School and two years at Munwon Middle School. Actually, much of my ideas and style stem from the time I spent during my childhood in Korea. Whatever challenges the logos bring, I can often rely on the little doodles that I used to do in school when I was young. Something that used to be frowned upon turned out to be my greatest asset.
Herald: When did you move back to the United States?
Hwang: I came back in 1992 when my father received a Fulbright Scholarship to research in the United States.
Herald: What was it like going to an American school all of a sudden?
Hwang: I was placed in a public middle school but was completely unprepared for it. I didn't speak a word of English. For the first six months, I couldn't communicate with the teachers or students. With the help of ESL programs though, I got better. My father returned to Korea, but my brother and I decided to continue our education in the States. My parents have made unimaginable sacrifices for us over the last 10 years, and I wouldn't be this successful without their support.
Herald: What was the first logo you designed for Google?
Hwang: Google had been using outside contractors to do the earlier logos, so the first project I got was modifying the Fourth of July logo in 2000. The two founders, Larry Page and Sergey Brin, wanted something more fun, so I redrew parts of the image. The next logo was for Bastille Day, which is the first logo I did from scratch.
Herald: Which letters are your favorite targets for manipulation?
Hwang: Understandably, the "O" and the "L" are the easiest to deal with. The "O" has become a Halloween pumpkin, a Nobel Prize medal, the Korean flag symbol and the planet earth. The "L" has been used as a flagpole, the Olympic flame cauldron or a snow ski. The first "G" is the most difficult to deal with, and I don't think the "E" has gotten much action because of its location.
Herald: How did you come to do the Korean Independence Day logo?
Hwang: Google makes a big effort to recognize holidays that aren't necessarily mainstream. The Korean Independence Day logo was seen globally by tens of millions of people. Numerous Korean-Americans wrote to thank us on Aug. 15 last year. Many expressed how proud it made them to see the Korean flag.
Herald: Do you have plans for other Korea-related logos in the future?
Hwang: I'll definitely to a special logo for Korea hosting the World Cup.
Herald: You're only 23 years old. What are your future plans?
Hwang: Who knows? It's very important to me that I can work both technically and artistically. Google is a perfect place to do that. It allows me to have a programming job while letting me express myself artistically, with the added bonus of having my work be seen by tens of millions of people in a single day.
Herald: What is your favorite letter among the ones found in the word "Google?"
Hwang: I've stared at the logo for so long and so often. I love them all equally.
Tuesday, February 20, 2007
Windows VISTA - Microsoft's Biggest MISTAKE
"David Short, an IBM consultant who works in the Global Services Division and has been beta testing Vista for two years, says users should consider 4GB of RAM if they really want optimum Vista performance. With Vista's minimum requirement of 512MB of RAM, Vista will deliver performance that's 'sub-XP,' he says. (Dell and others recommend 2GB.) One reason: SuperFetch, which fetches applications and data, and feeds them into RAM to make them accessible more quickly. More RAM means more caching."
CrAzy/BeAuTifuL
"crazy/beautiful" is the first teen romance I've seen, since, the last Kirsten Dunst movie. I used to go to a lot of teen flicks, but they were getting so bad even I couldn't stoop to ogle that much.The writers clearly saw "Mad Love" and said "We can do better than that." And they do. They follow a very similar story line and add a non-stereotypical Latino twist for a different take on Romeo and Crazy Juliet.
While the ending isn't entirely believable, it is satisfying for a movie. With many thanks to Deepali...
Its been 7 years...
Its been 7 years i am not a pilot neither an Aero Engineer.
And i am still dreaming to become one.
And i am still dreaming to become one.
Monday, February 19, 2007
64 DVDs on a disc: holographic storage to ship
February 12, 2007 (Computerworld) -- InPhase Technologies Inc. announced today that it will start bulk shipments of the industry's first holographic disc drive this July in a format able to store 300GB of uncompressed data on a single platter. That capacity will expand to 1.6TB per disc within three years, the company said. 
The Tapestry HDS-300R, which is the first rev of the product, will use a write-once format suited to regulatory agencies and is aimed strictly at the archival market for industries such as IT, health sciences, government agencies and professional video recording. InPhase plans to come to market with a re-writable format disc by the end of 2008.
The initial Tapestry HDS-300R holographic disc drives shipped in December to beta users
The Tapestry HDS-300R, which is the first rev of the product, will use a write-once format suited to regulatory agencies and is aimed strictly at the archival market for industries such as IT, health sciences, government agencies and professional video recording. InPhase plans to come to market with a re-writable format disc by the end of 2008.
"We're not going to play in the backup market at all," said Nelson Diaz, CEO of InPhase, in Longmont, Colo.
InPhase's first generation product has a data transfer rate of 20MB/sec., 100,000-hour meantime between failure rate and a 50-year expected lifespan. By the end of 2008, InPhase plans a second-generation 800GB optical disc with data transfer rates of about 80MB/sec., with plans to expand its capacity to 1.6TB by 2010. Diaz said his company plans to make all of its products backward compatible.
Diaz also said InPhase announced today that it has signed a partnership with jukebox manufacturer DSM Handhabungssysteme GmbH & Co. KG in Germany, to adapt its holographic drives to a library system. Diaz said DMS plans to have a holographic library out in early 2008 with up to 675TB of capacity. InPhase is also working with a number of other tape library manufacturers to adapt their technology.
Each holographic disk actually holds up to 600GB. Diaz said the remaining 300GB not being used for data storage is taken up by error correction software. "We have lots and lots of data redundancy. Because we're going after the archive market we've really erred on the side of caution in terms of data recovery," said Liz Murphy, vice president of marketing at InPhase.
To a backup server the holographic disc looks like a drive letter, allowing users to drag and drop files, Murphy said.
"We've also tried to make as easy to integrate as possible from a software perspective. So it can emulate a DVD, CD-R, magnetic optical disc or tape drive. So software companies don't have to do any major changes to write to it in native mode," Murphy said.
The optical platters are encased in a 5.25-in. square casing that looks like a floppy disk, except that they're 3 millimeters thick. The platter itself is 1.5 millimeters thick and data is written as a holographic image throughout the substrate of the disc.
Unlike CDs and DVDs where data is written on the surface, data is written throughout the substrate of the disc, meaning scratches, dust or dirt have little effect on data retrieval, Diaz said.
InPhase was spun off the technology from Bell Laboratories in 2000. The company plans to sell the product through resellers. Hitachi Maxell Ltd. will be manufacturing the tapestry line of holographic discs with photopolymer materials from Bayer MaterialScience AG.
Diaz said he already has orders for the product from big-name organizations such as Turner Broadcasting System Inc., the U.S. Geological Survey and Lockheed Martin Corp.
Subscribe to:
Posts (Atom)