Monday, April 11, 2005

Re: More on Mono

UML and strict development is good, but it's important not to get caught up in it. While I agree with their usefulness in practical situations, one must always remember that the final aim to churn up good code - and good software CAN be designed and implemented using basic common sense and just applying your mind to the problem and breaking it up into smaller parts.

When you try to make something too systematic, you run the risk of unnecessarily complicating matters. It's for us to decide where to draw the line. Use the 'formal' tools on a broad level but don't limit yourself to those or try to adhere to them like they're sacrosanct. Keep the big picture in mind and let creativity gain the upper hand! At the same time, you can't just 'hack' your way through in large apps. It's for the individual to optimize based on his requirements.

As far as mono goes, I don't have experience with it but based on whatever little I've read/heard about it, here's my two cents anyway! I don't have a great feeling about mono. It might pick up, you never know but if I were to develop a software, I wouldn't use mono! It's hard to give precise reasons; it's just a general feeling you get.

Sunday, April 10, 2005

Re: More on Mono

Firstly, seems like I struck a nerve. Seriously didn't mean to offend.

Everything you said is valid. No doubt. I was just trying to say that it really seems like things tend to become quite complicated. As you said UML is a recognized standard for communicating but it isn't required in every situation. UML is something that has come up with OOP. What about developers not using OOP? Correct me if I'm wrong, but most Linux/open source projects are still done in lower level, non-OO languages, primarily C. Many of these projects are quite huge and the ideas need to get across to many developers. How are they able to do it?

I have not downloaded or worked on any open source projects, even ones based on .NET or Java at places like sourceforge.net, but I wouldn't be surprised if there were no UML diagrams available with the source at these places. I suppose there are tools that will generate these diagrams automatically for you from source. VS .NET 2005 has this capability. I believe there are plug-ins for Eclipse also.

And what about Scripting. I've mentioned over a few posts about its gaining popularity. They are shedding their "toy" status and are being used in larger projects too. A lot of them are OO oriented, but not in the strict sense as in Java and .NET. So again, I wouldn't think UML is very popular in those communities.

I probably threw one too many things in the same boat by including Design Patterns in my dumb rant. I have'nt read the book you mentioned. I should, before saying more. I've primarily referred to this site. It seems to have most, if not all, the major ones listed. As an interesting point, I feel design patterns will be added into languages. For example, the Observer pattern is already a built in component of .NET with Delegates and Events. The next version will include a way to create a "static" class, wherein you can't create an instance of it - i.e. Singleton. If you think about it even getters/setters are in a way design patterns and they are built into .NET languages.

I'm digressing quite a bit, but this is just an example of what I'm talking about. I know I'm taking it out of context... I'm only talking small projects. But can't help but think that the trend is towards more complexity even though things like XP are trying to put up some resistance.

As an aside, dyou understand how open source projects work? How are so many people able to work on a project "unsupervised" as it were? Somehow it's just hard to imagine.

Personally I am very skeptical of Mono being used widely.

I'm assuming this is because of it being tied to .NET. Do you feel Linux guys will always reject it because of the "connection" to MS, even though it might be something useful?

Saturday, April 09, 2005

Re: More on Mono


One of the questions in the interview was about the development process behind Mono. He gives a really good answer about not being a great fan of UML and strict development processes. They are all great hackers and just want to do it because they are having fun... enjoying it. Strict dev practices etc... limit creativity and the "art" of programming.

What dyou think of his answer? I want to learn good practices about developing software because right now we all lack any substantial experience with it. But at the same time, I read about UML, design patterns, agile development, "some new hyped up buzzword" etc... and it all just seems so "messy" or tends to complicate matters. Same feeling I have with some Java developments. I've mentioned them before. It feels a lot of over engineering.


UML is a diagrammic notation to express Software design at various stages of development. You should learn UML because it is the de-facto method for communication between dev's. So if I show you a UML Class diagram you immediately know what inherits what and methods etc.. blah blah. As I mentioned various stages of developement exist for a particular piece of software. In the initial stage a Use Case diagram is made, then Analysis diagrams, then Design diags. All these help in development.

Now there are many methodologies for developing software. The various stages I mentioned were wrt the Waterfall process (or the Unified Dev Process), which I must admit is very boring. Too much documentation and managerial in nature. But understandably in a large organisation these things become important. Other methodologies include the Agile process. Agile process includes XP development practices which seem more Developer friendly. Many methodologies or processes use UML diagrams to express artifacts (or products) at various stages of development.

So firstly you should learn UML diagrams. Reading about various Development processes is also good. You will get an idea as to how many co's work. Dinesh could probably tell us a bit about his company. Which process you apply is a different matter.

And Design Patterns is a separate issue altogether. Which book for patterns or articles have you read?? Design Patterns was the first book to talk about patterns and is simply put a Bible. I have had the book since a while and even suggested to you guys to read the book. But to be frank I have not been able to understand too many patterns. We did try to apply a few in the Object Oriented Analysis and Design Module here at Ncb. Recently I read a sample from this book from Oreilly Head First Design Patterns. Read the sample chapter. The style of the book is very different, and I really loved it. Only after you read a few design patterns do you realise how beautiful solutions to generic problems can be !!

And complications in Java is another issue. I'll talk about Java some other time. I think you have mixed too many questions in one paragraph. Read about stuff to get an idea of things. UML and Design Pattens should be high on the priority list.


Also, any opinions about Mono? From his blog sometime back - "7 out of the 20 top-rated apps on gnomefiles.org are mono apps".


Even since coming here to Ncb I have harldy booted into Gentoo, and am not aware of whats going on in the Linux world. Probably Hrishi could shed more light on the popularity of Mono apps. Personally I am very skeptical of Mono being used widely.

Friday, April 08, 2005

More on Mono

Kinda obvious, but one of the great things about the programming world is that you interact, learn from, help and work with people from all over the world. Here's a video from Turkey interviewing Miguel De Icaza - the Mono dude (also GNOME founder). Can't understand half the things the interviewers are saying. I thought they were talking Turkish... turns out it was English.

Anyway, I really got a lot of respsect for Miguel. His blog gives you a good insight into his views - and not just programming related. He's like a really experienced open source hacker. Just feel like if you worked under him you would learn a lot. One of the questions in the interview was about the development process behind Mono. He gives a really good answer about not being a great fan of UML and strict development processes. They are all great hackers and just want to do it because they are having fun... enjoying it. Strict dev practices etc... limit creativity and the "art" of programming.

What dyou think of his answer? I want to learn good practices about developing software because right now we all lack any substantial experience with it. But at the same time, I read about UML, design patterns, agile development, "some new hyped up buzzword" etc... and it all just seems so "messy" or tends to complicate matters. Same feeling I have with some Java developments. I've mentioned them before. It feels a lot of over engineering. Granted this is coming from someone with little experience, but haven't you read an article which goes on about something and at the end of the 20th page you think, what the hell was that? Just seems so complicated for something which could have been done more simply.

Also, any opinions about Mono? From his blog sometime back - "7 out of the 20 top-rated apps on gnomefiles.org are mono apps". I was quite surprised/impressed. It looks like it's use has picked up.

Sunday, April 03, 2005

Google: Behind the scenes

Streaming vid (~1 hr): Behind the scenes at Google

One (more) thing which is impressive is they've built their services on top of commodity hardware... no super expensive machines. Just regular stuff with a lot of redundancy. Also, they have a ton of in built stuff - from a Google File System to some map/reduce algorithm which is infrastructure code to be fault tolerant and distribute the load among different machines (mentioned in the talk). They've recently started to share some of this.

Re: Databases Part 1

Waiting on part deux.

You'll have to wait for some more time... Very busy with the current module at Ncb as reaching the submission deadline.


A table can have a primary key.

When you say "can" dyou mean a primary key is NOT necessary? I thought it would be.


Right. A primary key is NOT necessary. But searching for a particular row will be more complicated as duplicates can be added to the table.


One thing that needs to be considered is where the error checking happen? Does it happen in the "business logic" layer or directly in the data layer? I would think a lot of times the database should ONLY be conserned with storing information.

I guess the question comes down to what responsibilities the database should take on. It seems the trend is to make more and more things happen in the data layer.


Basically databases are becoming more intelligent. So more Business logic is being pushed into the databases. It seems like mixing of responsibilities, but only specific business logic could be put into the db. Like you need to retrieve some data occasionally which spans across many tables and this is done very often. Rather than have loads of SQL in your business logic, just call a stored proc.

Another trend is distributed databases, which still have to mature well.

Error handling is possible in Stored procs. But I am not very sure how errors are sent to the host language. I think a simple SQLError could be returned by the db. We returned C-style status codes from the Stored procs.


Each trigger is associated with a TABLE on some event.

This is quite cool. I didn't know this was possible. You can basically keep a log/trace of everything that's going on in your database this way.


Care has to be taken that triggers are not written on 'events' of heavily used tables. Events could be insert, delete. Now if I have 500 inserts per sec on a table and I write a trigger on that event, its going to really load the server.


I'm interested in Stored Procedures just because I've read that they are beneficial to app performance. Is that really true?


Yes its true.

Now for some explanation.

When a simple query is submitted to a database, a few steps are carried out after which the result is returned. These include checking if the query is valid and tries to reference valid tables and columns. Then optimization of the query is done. Most queries in SQL are commutative and associative, so the order of the operations in the query can be changed without changing the meaning of the query as a whole. So the db does this based on the information it has about its tables and some heuristics as well. After this, the new SQL query tree is compiled and finally executed to return a result. Now as you have noticed, this is a very complicated and lengthy process. (and trust me, db's are really smart already wrt optimization!!)

Back to Java. There are three ways to execute a query in Java SQL - A Statement, a PreparedStatement and a Callable statement.

Now in a simple statement, the query is sent from the host language, then goes through all the steps of checking and optimization mentioned above.

A prepared statement is cached into the db for some time. So it does not have to go through all the optimizations steps each time. Probably only the new arguments have to be checked which should be faster.

A Callable statement is used to run a Stored Procedure. Now a stored procedure query resides IN the db. Only arguments are passed similar to a Prepared statement. So all optimization, compilation is already done.

I guess that should explain performance effects of various methods.

Also Stored procedures have other advantages like Mohn mentioned in his Hacking Websites blog.

< Excerpt Begin >
Be paranoid and ALWAYS validate data coming from the client. And as far as possible use Stored Procedures. Besides getting a performance boost (since they are compiled vs SQL statements that are interpreted), they use typed parameters
< Excerpt End >


What db are you working with? I've had basic experience with Access and SQL Server.


I used to work on Access before leaning what a 'real' db is supposed to do. We worked on SQL Server here at Ncb. Access does not do most of the things I blogged about. Just has tables with Primary and Foreign keys. Probably something more!!

I guess this blog introduced Stored procedures well enough. An example later..