Excellent Applet
Check this out.
This blog is a collection of my thoughts on the happenings in the software world influenced heavily by having had the opportunity to work in a variety of interesting products and doing some exciting work with very smart people. I hope you find it worth your while.
Other Blogs :
general | My Photography
Paul Graham's Great Hackers essay has really touched a lot of people's nerves. The wires are choked with people giving their point of view -
Posted by
Sachin
at
9:36 PM
13
comments
I have been training someone in Java over the last couple of weeks. This is my first serious experience teaching programming at a one-on-one level. Although, several times, I have been asked to give training or product demonstrations they were for an audience that had already bought into the concept and were simply looking for a human user manual. Not so here.
The person I am teaching knows C and can "think in C". He thinks of logic as a set of functions into which you pass data (mostly primitive types) which operate upon them and so on. I am trying to teach him Java and I am more interested in getting him thinking about objects, design, patterns, etc. I have, however, been having trouble showing him the benefits of OOP(Object Oriented Programming).
OOP has the following advantages:
Posted by
Sachin
at
7:15 PM
3
comments
I have been spending copious amounts of time trying to speed up our Web server. The results have been heartening and the experience typical of performance engineering. It's one of the most amazing activities of software development. Incredibly frustrating when you cannot speed it up but an adrenaline-rush when it does and the first person I bother when it works is poor Rajiv.
I am trying to log the various performance enhancements - some are just tips and some are things I discovered or used. Some you know, perhaps, some you don't.
Posted by
Sachin
at
11:49 PM
10
comments
Check out Neostream Interactive's latest Flash extravaganza!! These guys are creative geniuses! Extremely stylish artists. It's a largish download so you will have to wait a bit - but its worth it.
They have released a lighter wire-frame version of their . In case you missed out on the whack fun in the main flash page, go back and try it.
Posted by
Sachin
at
12:42 AM
0
comments
I recently spent several hours ridding a computer of a virus which had managed to avoid virus scanners. The experience was interesting and quite exhilarating. I am sharing my learnings with the hope that you might find it worth your while and might have some of your own to share. If you find it useful, let me know :-).
HKLM = HKEY_LOCAL_MACHINEHKCU = HKEY_CURRENT_USER
Posted by
Sachin
at
10:37 PM
0
comments
My interest in Google continues.
GET /search?q=geek&sourceid=mozilla-search&start=0&start=0&ie=utf-8&oe=utf-8 HTTP/1.1
Host: www.google.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040206 Firefox/0.8
Accept: text/xml,text/html;q=0.9,text/plain;q=0.8,video/x-mng,
image/png,image/jpeg,image/gif;q=0.2,*/*;q=0.1
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cookie: en_IN; PREF=ID=52eef62d74670ae2:
FF=4:LD=en:NR=10:CR=1:TM=1048623851:
LM=1069183668:S=c2RqGKqGOQXoZV8g
Posted by
Sachin
at
12:58 AM
0
comments
I was invited onto Gmail by Rajiv recently. Google continues to surprise and amaze with its excellent technological grasp. Its amazing how someone can redesign something as traditional as web-email so fundamentally. Some very core and interesting concepts -
Only ads classified as Family-Safe are distributed through our content network and to your Gmail inbox. For example, Google would block certain ads from running next to an email about catastrophic news.
Posted by
Sachin
at
9:19 PM
2
comments
A 404 page sent to IE has to be 512 bytes at least otherwise IE will ignore the page. What a wierd quirk.
The link has a list of other pages for which IE has different size limits.
Posted by
Sachin
at
12:34 AM
0
comments
Finally, we are talking Integration as the primary use of Web Services. All the inital hype and hoopla about it being the panacea for diverse applications so that you can discover and use any application that suits your query is giving way to more sensible uses like integrating diverse systems.
SOA is becoming a huge buzzword. Although, Web Services are a way to achieve SOA, it is today considered almost synonymous. BEA is talking about SOA along the lines of integration too.
[BEA's QuickSilver project one implementation of this vision. While no shipdate has been announced, the BEA vision is to provide J2EE developers a console-driven suite of integration software built around Web services protocols, the purpose is to enable them to transport data and business rules between Java and non-Java systems with as little coding as possible, using abstractions and an integration-enabled container (tied into the development/deployment console).]
Posted by
Sachin
at
8:32 AM
1 comments
After several years I have again started working on Borland Delphi. I used to be quite proficient at it. Its interesting how my perspective for things have changed. It still remains an incredibly productive environment for Windows programming especially for a hobbyist programmer like me.
The environment has changed a little since the version 2.0 I was using and the version 7.0 that I have now. However, the changes are quite miniscule compared to the jump in versions. I believe this speaks volumes about their excellent design in their first few versions. They have extended it to support Web Services, XML, Internet programming, newer debuggers, a host of new things but the original clean, easy-to-use framework remains.
Delphi 2.0 used to have an excellent coding editor. Visual C++ had an equally good one. They had identical debuggers of very high quality. The debugging abilities have remained quite the same, I think. Their ability to always run with debug on is quite convenient.
However, all is not great. I believe Delphi's innovation at basic coding productivity is very very low.
Comparing with any of the existing Java editors like IntelliJ Idea, Eclipse, Pramati Studio and you will find an a variety of tools that are integrated into the editor that pop up "Just-In-Time" to provide an excellent coding environment. Both languages, Java and Delphi, have coding tasks that interfere with the basic thought process. Delphi has a whole lot more than Java. Java needs import statements too be added which its IDEs do automatically. Delphi needs function prototypes, variable declarations, imports and some more house keeping which the Delphi editor does not do. VERY IRRITATING.
All the Java editors do online validation of code so that you always know what went wrong and they will manage code completion irrespective of syntax and semantic errors. The Delphi editor after half a decade of evolution cannot do that. It simply says that code completion is not available. That is unbelievable.
Posted by
Sachin
at
3:50 PM
3
comments
Ramesh's blog on the ongoing JBoss and TSS (The Server Side) Feud capture exactly what I felt on this issue. All parties involved are getting equally unethical.
Interestingly Ramesh's blog is beginning to get quite popular - so popular infact that they are having a TSS style argument in the comments section of his article! Kudos!
Posted by
Sachin
at
10:19 PM
0
comments
To what extent do you use the tools at your disposal? We were involved, for the longest time, in writing a set of productivity tools for developers. We had excellent competition but our experience with our customers and their users was always that people knew very little about their tools and its capabilities.
How much do you know your tools? I have used IntelliJ Idea. Its a brilliant IDE. I have seen other people use it. They suck at it. They could as well use any other text editor with code completion. They have no idea what Idea can do for them (no pun intended).
Posted by
Sachin
at
8:09 PM
2
comments
I had a chance to meet James Gosling at a meeting with HYSEA which he graciously (albeit in a slightly bored manner) attended and gave us a few minutes of insight into his thoughts on a variety of subjects and primarily on Java.
Some excerpts : (I am writing this from memory so the words arent the same ones he used and I shall try to the best of my knowledge to convey what I understood :-) )
What do you think about releasing a version of Java which embraces the Windows platform, e.g. providing easy access to the Win32 API without having to resort to JNI?
Developers are not feeling a need for such a release. The way Java works is that if a bunch of people need a particular feature say Scanning, then the go out and design a high level API that captures the essence and much more of the requirement which will have the default implementation perhaps only on Windows but the ability to extend it remains. Other examples are the NIO subsystem.
What would you design differently in Java if you got to design it again?
I wanted to make the syntax as close to C or C++ at that time because they were the most commonly used languages. At the end however, syntax is syntax. I would have changes the syntax of the switch statement.
What can we expect in the JDK 1.6 release?
Its too early to say what can be expected in the JDK 1.6 release. However, if you feel strongly about something you should talk to the expert group at the JSR. JDK 1.5.1 will have a release providing features similar to AOP.
What do you think about Java being taught in colleges?
Pascal used to be taught because if you made any mistakes, it was easy to explain them. In C if you go past an array, you find out about it in mysterious ways. Java has an easy to use memory-model and has the same qualities as Pascal. Pascal did not have too many commercial implications. Java has considerably many. Therefore using Java in colleges to teach programming makes a lot of sense.
And some more...maybe later
Posted by
Sachin
at
11:24 PM
0
comments
Recently I concluded an engagement which involved reviewing and commenting on someone's Java code. While submitting the results, the discussion turned towards some common problems. Interestingly we are grappling with the same problem at my work place too. How do you do error handling, good exception handling with effective user feedback?
It all drills down to being able to identify the exact cause of the problem and to be able to suggest solutions to it. It so turns our that this seems to be quite difficult to do.
Where does the difficulty lie? I think the difficulty builds over time. e.g.
If I write some code that does a file copy I will end up doing the following
public void copy(InputStream src, OutputStream dest) throws IOException;
What is wrong with this code? A bunch of things and I do not know what to fix in it.
IOException has about 20 different direct sub-classes. Out of which this operation could potentially raise over half of them. Most implementations handle this by simply catching it and if they do not ignore it (god forbid) they just show an IO Error message to the user. If you have a Java aware user, well good for you (my experience with Java aware developers are that they do not understand these exceptions anyway) but for a Java unaware user what do you say?
The only way you can provide effective feedback is to catch every single type of exception and try and figure out what it means. Would you find in yourself the motivation to do that?. You are still left with a bunch of IOExceptions ranging from not enough diskspace to remote file system is not accessible, permission problems etc. You are still constrained by the effective user messages of your library.
How does one solve this problem? Our customer asked us if we knew of any third party exception handling package that he could download. Now thats a killer application.
Check out who all are arguing about it too...
gosling@artima
Hejlsberg@artima
Posted by
Sachin
at
9:23 PM
1 comments
Joel has an Excellent new article that I agree with very strongly. About how software development is considered to be something anyone can do quite easily. Most people do not realize the complexities of software development. Along the same lines, recruitment processes in most companies are driven by aptitude expecting that a person with a good aptitude (IQ) will be able to code better because its all about logic.
I dont think so.
I think its much more than just logic. Programming well requires a discipline, requires you to enjoy what you are doing, it requires a way of thinking that comes from practise as well as love for programming. Its like saying that spending 4 years in college learning software development is a waste of time. It doesnt teach you everything but it makes you much better than someone who learnt something else.
Joel touches on several other aspects of how software development is complex and involves a lot of variables. An excellent read!
I have come across recent examples of working code which is so terrible that its disgusting. These are examples of high aptitude people who are coding for the amount of time needed by when they can be automatically promoted to a position where they can delegate it to someone. These "managers" will of course continue to fuel jokes in Dilbert.
Posted by
Sachin
at
11:06 AM
1 comments
An interesting performance problem got solved this week. One of our clients noticed dramatically bad performance in our Java servlet/jsp web-server compared to a competitor.
The usual trick to narrow these down are to take thread dumps at the time when the server looks busy. It kept showing us dumps that seemed like most of the time was spent waiting for the database to respond. A quick timing calculation showed that the database was taking a short fraction of the time. After introducing more timing stats between some large pieces of execution we managed to find a bottleneck only to see that it moved the next run - thus making us suspect Garbage Collection. Switch on -verbose:gc and there we were minor Garbage Collection Runs a full 8 and a half seconds.
The Usual Suspects are runaway streams, memory leaks, excessive object creation none of which could be caught in our JVMPI profiler. Amazingly, even after 3 days of intense debugging we knew it was GC that was leading to our problems but we could not isolate what it was that caused it!
We tried IBM JDK and its VM and we compared identical to our competitor. IBM JVM is an amazing piece of software but thats a story for another time.
None of the usual suspects seemed to be involved. We went back to commenting out pieces of the offending JSP and isolated the problem to excessive try-finally blocks in our code generation. We got rid of them and lo behold! we were as fast too!
Why would try-finally result in such high GC times in Sun JVMs? I can only suspect if GC happens when there are a lot of try finally blocks the code is unoptimized? Would love the answer to that one...
Posted by
Sachin
at
9:46 PM
1 comments