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.
Wednesday, March 28, 2007
Richard M Stallman visiting Sri Lanka
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.
Subscribe to:
Posts (Atom)