feedburner

Subscribe

View Venkat Varkala\

Programming Truth and Fiction

Labels:

Fiction: HTML is not a programming language. It is a markup language. It lacks all necessary functionality (like if-else branching, variables, loops) to program in it, and in fact, even comparing it to a programming language completely misses the point of HTML’s beautiful simplicity. Truth: Many managers in IT work environments understand HTML is a kind of programming language. And CSS is, too. Telling them that “HTML programming” is a contradiction in itself will only add to the confusion and should be avoided.

 

Fiction: In a programming language, you can express your thoughts; you can permanently lay down a rule system which can then be recreated on other machines, over and over. To some extent, the programmer simply manifests a detailed model of how the software is supposed to work, so that this model is turned to “virtual” reality. Truth: Many IT managers know that programming is the thing that you do in some kind of text editor, with long lines of something called “code” which nobody understands really except the programmer (who was born with the talent of understanding it). It’s a bit like nerd magic, void of real meaning. Most definitely, the actual model of the software is contained in the PowerPoint accompanying the project, not the software itself. At best, the code is a symptom of the model of how the software is supposed to work as detailed in the PowerPoint or Word document – at worst, it introduces bugs on its way to “finalization” of the software.

 

Fiction: Software needs to be flexible so that changes can be introduced at any time. However, as some changes can’t be foreseen even with the longest discussion with clients, you better get into writing code early on so you have a prototype to show off. It’s up to the programmer’s intuition to solve the non-trivial task of introducing the right level of flexibility into the software. For example, when the programmer believes the web application will need registration at some point, but the client promises this is never needed, the programmer may still create a model that will enable her to easily add this feature in a future revision. Truth: Your manager can foresee the evolution of the software, precisely and up to 5 floating point digits, using his UML editor of choice and/ or a Word file converted to PDF (converting something to PDF increases its level of authority by the factor of six). As the customer agreed to the feature specifications, there’s no way more features could ever be wanted.

 

Fiction: The function you write today will turn into a class tomorrow. That class will turn into a program. That program will turn into software. This software will then be used not just by you, but by your colleagues as well. And soon, it will be sold to a dozen customers. Your seed function of the first day, in a way, contained the “DNA” of the program that would grow out of it. Therefore, it makes sense to always write good code and refactor heavily along the way – even if you think you’re going to throw away the software eventually. Truth: The manager will tell you that this software needs to be finished tomorrow, and that it will only go live for a week. After that, the software isn’t needed anymore, so you don’t need to take great care during implementation right now (considering that there’s no time anyway to do so, that’s good to hear).

 

Fiction: Self-explanatory code is also self-commenting. Given the choice between a comment and a piece of self-explanatory code, a good programmer will always prefer self-explanatory code. Some programmers even remove comments from code to fully understand it. Often, comments “lie” about the code – they may say X, which was true in 2001, but they didn’t get changed to Y, which is what happens in 2006. Temporary variables to avoid “magic numbers” and short, verbosely named functions aid readability better than many comments do. Truth: The more comments you write, the better your software can be maintained. A large Word document saved far away from the actual running code helps as well. Temporary variables waste both storage and CPU cycles during execution of the code. The best programmer is the one using the most comments, end of story.

 

Fiction: Programming style is debatable, and such debates are often long and fruitless. Thus, a controversy erupting on coding conventions is not constructive. If there would be “one better way” to code, surely all the brains in the world would have come to an authoritative solution by now. Therefore, either go for one coding convention, agree that it’s arbitrary, and get on with work... or allow everyone to code in whatever style he or she feels is most appropriate. Truth: Curly brackets must always go in the next line, and you must use tabs, not spaces.

 

Fiction: People can write good programs without multiple inheritance. Sometimes, OOP for the sake of OOP is just as silly as a 400 lines long function. The danger of “gold coating” a software is just as imminent as is the danger of quick’n’dirty throw-away approaches. A pragmatic programmer will use OOP, but never fall in love with the design of his own classes. Truth: A complicated class structure only shows the programmer did a quality job. Inheritance is a necessary complexity, and simply can’t be overused.

 

Fiction: There’s a great many programming languages around. Often, the selected language was just cheaper to use, or pre-installed in your intranet, or the server, or it’s used because of its great library. While some languages are more elegant than others, that doesn’t really help your software much. A good programmer will know the pros and cons of many different programming languages and use whatever tool works best for the challenge at hand. Truth: Real programmers use Java. No, make that Python. I mean C#. As long as it’s not PHP. Or anything that looks like BASIC.

 

Fiction: Today, there are many great web apps that were coded in prototype-ish, no variable declaration, try-as-you-go type of tools. These are programming languages but because of their high usability and behind-the-scenes compilation, they are called scripting languages. They are not better or worse, and the lines are often blurred. Truth: There’s a huge difference between scripting languages and programming languages. Real programmers won’t touch a scripting language with a thirty foot pole, and rightfully so. If someone mentions that he uses X, a scripting language, he should be rightfully put down in front of others by pointing out the difference between scripting and programming (putting someone down is especially constructive in public newsgroups).

 

Fiction: A team discussing a lot and getting along great and programming a lot is more valuable than a verbose software specification. Truth: “Getting along” is really too fuzzy and social to be part of any professional software development team. Actually, it’s about coding standards, keeping to the MS Project schedule, and not thinking too much outside of the box (as that endangers keeping to the schedule). In fact, with the right project plan you can put any random 5 programmers into the basement and shut the door close (and open up again when the deadline arrives), as long as you remember to feed them pizza.

 

Fiction: Programming is a craft; as such, it contains element of art as do other crafts. A creative programmer is creative enough to make synergies (e.g. graphics + code, or usability + software) work for her. A good work environment will not only facilitate these synergies, but demand them. Truth: There is a need for strictly separated work groups, from management, to graphics, to concept, to writing content, to finally programming the whole thing. There are sub-categories here, e.g. Flash falls neatly into the “graphics” category (even ActionScript mainly moves graphics around). After all if a programmer was allowed to do a concept, he’ll end up choosing the simplest route to get from A to B without any of the glitz end users want to see. Truth is that programmers can’t draw, and artists can’t think logically. In fact, there is a certain danger of an artist thinking about software for longer stretches of time, as it effectively dries his inner well of creativity.

 

Fiction: Programming can be an interesting, adventurous, highly rewarding, creative, and fun thing to do. It should be taught in schools. People should be introduced to it at a young age, with a simple programming language. Not everyone will like it, but those who do will become incredibly great programmers who in the future will be creating incredibly great software. Truth: Programming is for nerds! If you want to teach it, wait until 9th grade and use Java. Seriously. Source : http://blog.outer-court.com/archive/2006-02-15-n25.html

Finding Nth row in SQL Server

Labels:

Use Pubs
Go

Create table Employee
(
Eid int,
Name varchar(10),
Salary money
)
Go

Insert into Employee values (1,'harry',3500)
Insert into Employee values (2,'jack',2500)
Insert into Employee values (3,'john',2500)
Insert into Employee values (4,'xavier',5500)
Insert into Employee values (5,'steven',7500)
Insert into Employee values (6,'susana',2400)
Go
A simple query that can find the employee with the maximum salary, would be:
Select * from Employee where salary = (Select max(Salary) from Employee)
How does this query work? The SQL Engine evaluates the inner most query and then moves to the next level (outer query). So, in the above example inner query i.e. Select max(Salary) from Employee is evaluated first. This query will return a value of 7500 (based on the sample data shown as above). This value is substituted in the outer query and it is evaluated as:
Select * from Employee where salary = (7500)
Returns:
Eid	Name	Salary
5	steven	7500
If the same syntax is applied to find out the 2nd or 3rd or 4th level of salary, the query would become bit complex to understand. See the example below:
Select * from Employee where salary =
	 (Select max(Salary) from Employee where salary
	< (Select max(Salary) from Employee where
		Salary < (Select max(Salary) from Employee where
			   SalaryThe above query would go on and on, depending on the level of salary that is to be determined. As mentioned earlier, the SQL Engine evaluates the inner most query first and moves the next outer level. One wouldn?t want to write such a big query just to find out this simple information.

The same result can be achieved with a simple syntax and easily understandable logic, by using a CORRELATED SUBQUERY. This article doesn?t explain about correlated sub-query as it is out of scope of this article.  (You may want to take a quick look on CORRELATED SUBQUERY.) As a "Rule of Thumb" keep these points in mind, when you use a correlated sub-query
  1. Correlated sub-query is a performance overhead to the database server and so, you have to use it only if it is required
  2. Avoid using Correlated subquery on large tables, as the inner query is evaluated for each row of the outer query
Having said that, let?s look at the query that captures the Nth maximum value:
Select * From Employee E1 Where
    (N-1) = (Select Count(Distinct(E2.Salary)) From Employee E2 Where
		E2.Salary > E1.Salary)
(Where N is the level of Salary to be determined) In the above example, the inner query uses a value of the outer query in its filter condition meaning; the inner query cannot be evaluated before evaluating the outer query. So each row in the outer query is evaluated first and the inner query is run for that row. Let?s look into the background process of this query, by substituting a value for N i.e. 4,(Idea is to find the 4th maximum salary):
Select * From Employee E1 Where
    (4-1) = (Select Count(Distinct(E2.Salary)) From Employee E2 Where
		E2.Salary > E1.Salary)
Since the outer query?s value is referred in the inner query, the operation is done row-by-row. Based on the sample data as shown above, the process starts with the following record:
	Employee E1
----------------------------------
Eid	Name	Salary
1	harry	3500
The salary of this record is substituted in the inner query and evaluated as:
Select Count(Distinct(E2.Salary)) From Employee E2
	Where E2.Salary > 3500
Above query returns 2 (as there are only 2 salaries greater than 3500). This value is substituted in the outer query and will be evaluated as:
Select * From Employee E1 Where (4-1) = (2)
The "where" condition evaluates to FALSE and so, this record is NOT fetched in the result. Next the SQL Engine processes the 2nd record which is:
	Employee E1
----------------------------------
Eid	Name	Salary
2	jack	2500
Now the inner query is evaluated as:
Select Count(Distinct(E2.Salary)) From Employee E2
	Where E2.Salary > 2500
This query returns a value of 3 (as there are 3 salaries greater than 2500). The value is substituted in the outer query and evaluated as:
Select * From Employee E1 Where (4-1) = (3)
The "where" condition evaluates to TRUE and so, this record IS fetched in the result. This operation continues for all the remaining records. Finally the result shows these 2 records:
Eid	Name	Salary
2	jack	2500
3	john 	2500
The above query works in the same manner in Oracle and Sybase as well. Applying the same logic, to find out the first maximum salary the query would be:
Select * From Employee E1 Where
    (1-1) = (Select Count(Distinct(E2.Salary)) From Employee E2 Where
		E2.Salary > E1.Salary)
If you are able to understand this functionality, you can workout various other queries in the same manner. The bottom line is, the query should be efficient and NOT resource hungry. This article is from http://www.sqlteam.com/item.asp?ItemID=16134

Search Stored Procedures

Labels:

Search in procedure name

SELECT SPECIFIC_NAME FROM    INFORMATION_SCHEMA.ROUTINES WHERE  ROUTINE_DEFINITION LIKE ‘%text%’ Search in procedure name select text from sysobjects o, syscomments s where  o.id = s.id  and xtype = 'P' and text like '%text%'

@@IDENTITY, SCOPE_IDENTITY, and IDENT_CURRENT

Labels:

After an INSERT, SELECT INTO, or bulk copy statement completes, @@IDENTITY contains the last identity value generated by the statement. If the statement did not affect any tables with identity columns, @@IDENTITY returns NULL. If multiple rows are inserted, generating multiple identity values, @@IDENTITY returns the last identity value generated. If the statement fires one or more triggers that perform inserts that generate identity values, calling @@IDENTITY immediately after the statement returns the last identity value generated by the triggers. If a trigger is fired after an insert action on a table that has an identity column, and the trigger inserts into another table that does not have an identity column, @@IDENTITY will return the identity value of the first insert. The @@IDENTITY value does not revert to a previous setting if the INSERT or SELECT INTO statement or bulk copy fails, or if the transaction is rolled back. @@IDENTITY, SCOPE_IDENTITY, and IDENT_CURRENT are similar functions in that they return the last value inserted into the IDENTITY column of a table. @@IDENTITY and SCOPE_IDENTITY will return the last identity value generated in any table in the current session. However, SCOPE_IDENTITY returns the value only within the current scope; @@IDENTITY is not limited to a specific scope. IDENT_CURRENT is not limited by scope and session; it is limited to a specified table. IDENT_CURRENT returns the identity value generated for a specific table in any session and any scope. For more information, see IDENT_CURRENT. Assuming that your database has no other actions that occur between the INSERT statement and the SELECT @@IDENTITY statement, then you will get back the newly created RegionID value for the new Region row. But what if there is n Insert Trigger, for example, on the Region table that inserts a record into another table that also has an IDENTITY column. (Perhaps it does this to audit data.) In this case, the sequence of events would be: 1. the stored proc fires 2. insert the new region record 3. the trigger fires 4. the trigger’s code inserts the audit record 5. the stored proc then executes the SELECT @@IDENTITY, which then returns the ID that was created by the last statement, which is the audit table’s ID The scope of the @@IDENTITY function is the local server on which it is executed. This function cannot be applied to remote or linked servers. To obtain an identity value on a different server, execute a stored procedure on that remote or linked server and have that stored procedure, which is executing in the context of the remote or linked server, gather the identity value and return it to the calling connection on the local server.

Great attitude = great managers

Labels:

The prime impetus to pursue a management specialisation is the fact that it is the most sought-after qualification today. There is no denying the importance of management education, since it is the acquisition of this knowledge that instils a new confidence and poise, making individuals ready to meet the challenges and opportunities of the corporate world. But beyond the management concepts and skills that you imbibe at B-school, the one critical aspect that makes or mars your career is attitude. The right attitude centres on the WIN principle -- Work hard, Innovate and Never give up. Most people work for 25 to 30 years, which can be broadly divided into four phases of five to seven years each. The first lasts roughly five years during which you learn to perform as an individual and as part of a team. Along the way you learn the significance of individual performance to the results achieved by the team. In the second phase, when the individual leads the team as a manager, he learns that he is as good as his team. If he is able to motivate his team to put in 100 per cent, he can deliver 100 per cent. In the process, he hones his people management, relationship building, crisis resolving and decision-making skills. The third and fourth phases are the most critical, where the practical training and exposure of the first two phases are instrumental in helping you withstand the pressures of the top and succeed. In the fourth phase, you are expected to take care of the CEO: Customers, Employees and the Organisation/owners. That's where your experience, foresight and understanding of the business model and its needs come into play. Remember, the top of the pyramid is narrow -- there's room only for the best. --http://in.rediff.com/money/2006/feb/02guest.htm

Push Vs. Pull - The Battle for the Best CMS

Labels:

Push CMS, content is aggregated from the repository and "baked" into a standard file which is then pushed, via open standards, to the appropriate Web server(s). Pull CMS, the necessary content pieces are pulled from the database and assembled into a single page. Ektron & DNN are sure PULL CMS solutions but I wonder about MCMS, which is some where between PULL & PUSH. Good article on PULL & PUSH CMS

India vs. China: Who Has the Edge?

Labels:

Good comparision of India & China. Whatever the case INDIA has bright future I put my money in INDIA. The contrast between your first impression of China and India could scarcely be more extreme. You arrive at China's financial capital, Shanghai's new Pudong International Airport, and walk through spacious, clean corridors to the world's fastest train, the Maglev. Your 30 km (18.6 miles) trip takes only eight minutes on this train that floats magnetically above the tracks and reaches speeds of 430 kph (267 miles per hour). From the Longyang Road Metro Station at the outskirts of the city, an air-conditioned taxi takes you to the Grand Hyatt Hotel. As you exit the car you marvel at the other towering skyscrapers that surround the world's highest hotel, located on the 53rd to 87th floors of the Jin Mao Tower. Contrast that with a trip to Mumbai, the financial capital of India. You arrive at the decrepit Mumbai International Airport, fight your way through crowds of beggars and unsolicited "helpers" before finding a taxi that takes to you your hotel at the southern edge of Mumbai. Although the trip is only 20 km (12.4 miles), the ride may take 90 minutes or more. There is no direct route as the driver wends his way through side streets trying to find the least crowded route. http://finance.yahoo.com/columnist/article/futureinvest/2369