A repository of my thoughts, a blog, a source to get insight, know-hows, my views on Software Development and everything else in between......
Friday, April 13, 2007
Fibonacci Series..........
Series :0, 1,1,2,3,5,8,13,21, 34, 55, 89, 144, 233, 377, 610, 987, 1597, 2584, 4181, 6765, 10946, 17711, 28657, 46368, 75025, 121393, 196418, 317811, 514229, 832040, 1346269, 2178309, 3524578, 5702887, 9227465, 14930352, 24157817, 39088169
1. Fibonacci numbers whose internal digits form a Fibonacci number. Or Fibonacci numbers from which deleting the MSD and LSD leaves a Fibonacci number.
0, 1,1,2,3,5,8,13,21,34, 55, 89, 233, 610, 987 (The sequence is finite.)
2. Fibonacci numbers whose external digits form a Fibonacci number. Or Fibonacci numbers whose MSD and LSD form a Fibonacci number.
0, 1,1,2,3,5,8,13,21,34, 55, 89,121393, 1836311903, 2504730781961, 10610209857723, 10284720757613717413913, 184551825793033096366333, 59425114757512643212875125, 155576970220531065681649693
3. Fibonacci numbers whose external digits as well as internal digits form a Fibonacci number.
0, 1,1,2,3,5,8,13,21,34, 55, 89
Thursday, April 12, 2007
Discovered a nice thing!!!!!!!!!!(hey look at what I’ve found and I’m excited about researching!)
computer games, i saw this when i went to find my little brother and found that he was in a net cafe playing games with his friends, i just saw from some distance how they were behaving, i came to a point that children can learn faster when they are in groups and by their natural curiosity.It seems that being in a group was a major component to self-learning.
But it makes sense. People don’t learn by rote memorization or being forced to learn something. They don’t really truly learn material by sitting at a desk and forcing it into their brains. we learn by practicing, doing, asking questions, figuring stuff out. NOT by lecture. we learn because we have a question, a problem, or out of curiosity.lectures can help us prepare for tests, but this kind of “figure stuff out” method is what gets you to really learn something.
So what’s the real difference between adults and kids? Just that adults “can’t” learn new things? No. it’s more like the sense of curiosity and self-confidence just fades or grows out of them or something. So the key to always being able to learn is to retain your sense of curiosity and spontaneity.
All these things are sort of “common sense”, but now there’s some sorta scientific “proof”(my experiment) that this is true.
I just wish that we had an educational system that matched research like this. individual teachers who model their classrooms around these ideas are awesome, but when they’re forced to “teach to the test” or their kids will fail and they’ll lose their funding… it just hurts everyone.Why can't we take this example for teaching the machines to learn????????any body can help me out ???????????
Anyway, got to get back to work… just didn’t want to forget to write about this.
Who is the Next President of India?
Wednesday, April 11, 2007
Dynamically removing dynamically added controls
foreach(Control contrl in this.Controls)
{
if (contrl .GetType() == typeof(TextBox))
{
this.Controls.Remove(contrl );
}
}
But this code removed only alternative textboxes. At first i was unable to find it out,but then after searching on net i found that when you remove a control from the ControlCollection, subsequent controls are moved up to fill that space. And found the solution to my problem. The code that must be used is like below.
foreach (Control contrl in this.Controls)
{
if (contrl.GetType() == typeof(TextBox))
{
ContrlToRemove.Add((TextBox)contrl);
}
}
foreach (TextBox txtbox in ContrlToRemove)
this.Controls.Remove(txtBox);
Other Alternatives:
1. You can do it in a single loop when removing items from any sort of indexed container,it is always best to remove them in reverse order starting at the end.And also when manually removing windows controls from a container,it is best to Dispose them at the same time. Otherwise you may have a memory leak.
If you find other alternatives too keep me informed.
Saturday, April 07, 2007
Great Tools for Web Developers
For Internet Explorer:
1. Web Development Helper (www.nikhil.net)
2. DebugBar (www.debugbar.com)
3. CompanionJS (http://my-debugbar.com/wiki/CompanionJS/HomePage)
For FireFox:
1. Firebug (www.getfirebug.com)
2. Web Developer (www.chrispederick.com/work/webdeveloper/)
3. Colorzilla (www.iosart.com/firefox/colorzilla/index.html)
4. Live HTTP Header (http://livehttpheaders.mozdev.org/installation.html#)
Tuesday, March 27, 2007
Books -- Great Innovation
Funtion to Find whether the String is Palindrome or Not
class test
{
private static void Main()
{
Console.WriteLine("Is 'ada' Palindrome : {0}",IsPalindrome("ada"));
Console.ReadLine();
}
public static bool IsPalindrome(String strParam)
{
int iLength,iHalfLength;
iLength = strParam.Length - 1;
iHalfLength = iLength/2;
for(int iIndex=0;iIndex<=iHalfLength;iIndex++)
{
if(strParam.Substring(iIndex,1)!=strParam.Substring(iLength - iIndex,1))
{
return false;
}
}
return true;
}
}
Detect OS Version Using C#
OperatingSystem os = Environment.OSVersion;
MessageBox.Show (vs.Major.ToString());
//vs.Minor;
//vs.Revision;
//vs.Build;
Adding Errors to Event Log
private void AddLog(string sErrSource, string sErrMessage, EventLogEntryType ErrType)
{
EventLog objLog = new EventLog("AppLog");
objLog.Source=sErrSource;
objLog.WriteEntry(sErrMessage,ErrType);
}
Debugging Problems in ASP.NET
When you try to debug an ASP.NET application in Visual Studio.NET. you may receive the following debugging error.
Error while trying to run project: Unable to start debugging on the web server. The project is not configured to be debugged.
Following are reasons and solutions for this problems.
Possibility 1:
You are not a part of debugger group.
Solution
Local Users and Groups ->Users- > add yourself as a Debugger User (Also check if you are a VSDeveloper
Possibility 2:
You dont have execute permissions on your virtual folder.
Solution
Step 1: Control Panel -> Administrative Tools- >Internet Service Manager
Step 2: Default Web Site -> Right Click on your Project-> Properties->Execute Permissions -> Scripts and Executables
Possibility 3:
You have kept ASP.NET debugging unchecked.
Solution
In VS.NET IDE,
Right Click Project - >Properties->Configuration Properties ->Debugging-> Debuggers Enable Check the checkbox for ASP.NET Debugging
Monday, March 26, 2007
Progammers Productivity
Today's Prgamming :skills to make it work
The quality of a good programmer is the ability to know how to beg borrow and steal the right code - AND when not to try and solve a problem from scratch.
Interview of two candidates
Q Write a class to put these items in a linked list.
Candidate 2 Derived class from a library linked list class, and used sample code - Got job and went down to pub to celebrate!
As a Software Engineer, problem solving skills are 80% of software engineering. The syntax of programming and programming well is the difference between a good programmer and a great programmer.
I was passed over for a job because I couldn't "Write a function to compute the moving average of a stock price." Heck, I didn't even know what a "moving average" was. But when I got home I sat down and 20 minutes later I had a nifty little recursive function that answered the question. Why couldn't I do that in the interview? Because in the interview I didn't have the resources I would normally have while on the job. A good Software Engineer knows how to use those resources to solve programming problems.
Programmers!!!!!!!!!!????????????
University is not an exercise in cramming your head full of knowledge it's an exercise in learning how to learn quickly and efficiently.
When you know the basics you can teach yourself a new language in a few hours, and depending on the complexity learn a new API in an hour to day. Many grads I find dont have that capacity.
I remember at my first .NET course the teacher asking how many people never programmed before. Many hands were raised, and I felt bad for them for choosing a future profession without knowing what it actually was about. Then he asked how many people never touched a keyboard before. How shock was I to see at least 10 persons raise their hand, mostly women.
I think there are too many people out there who don't know how to write code in their head..
But..
That doesn't make them a bad coder or designer to be apt. Coding has become so abstract that most modern coders tend to be designers due to working with heavily gui based apps from Windows form coding to Web apps. So we could blame MS for doing this, but its not really their fault.
The days of the lone coder are gone, most if not all coders have no need to learn or retain any of the stuff they get taught in their college/uni and certainly its not a requirement in a job.
However I think coding should be about architecting a solution and that means working from the ground up. A good coder is someone who has knowledge of each area they are interacting with, not necessarily deep knowledge of a technical component but enough of an understanding to appreciate how their solution will fit into the wider picture.
Coding should be about elegance. It should be like designing a really well made web page that employs lush CSS and is a visual treat to look at. Code should be the same, well commented and fluid in its layout making the code appealing to read.
I have come across too many coders who simply code out of need, usually to meet out of proportion expectations resulting in badly formed code or a solution that has far too many shortcuts in place.
Each to their own though, every problem has a particular solution however I think what this article was touching on was the fact that the core foundation skills of a coder are not present in most interview cases and this is worrying but I think a growing trend.
When you have hand-holding applications like Visual Studio.NET there is no real need to retain information as you can for the most part, cut and paste your way to a solution. :P
199 out of 200 programmers can't write code....!!!!
What i think is we cannot judge a person simply taking interview for 30 minutes or 45 minutes.We can always learn to pass interview tests of any kind - that doesn't mean We can program or not. These days Technological growth is very rapid which makes us to remember only the concept not the syntaxes. So we cannot expect every one to remember each and every thing.
We studied many concepts during our Engineering Day's in College but many of the concepts we never used at all.For example, I wrote programs like generating Fibonacci series etc which I never used at all in my programming so far.
If someone were to ask me how to swap two variables w/o a temp variable I'd ask them to give me a good reason why.
Not being able to answer that particular question certainly doesn't preclude someone from being a good programmer. That'd be like asking a C# programmer how to do modulo 16 using only a logical and. Why the hell would they need to know that, and how does that help you determine that they understand the ASP.Net framework, etc.?
What matters most is whether we have logical and analytical ability to understand the problem well.
The most obvious way to decide - for me - is to run through these tests (assigning some tasks to perform), emply the person you like the best and then look at the code they've produced after a week. Then you'll know if they can do what you need.
Links.......
If that wasn't enough, here's a Canadian company testing a quantum computer.
There's still some doubt. But if parallel machines weren't enough, quantum computers are just around the corner no matter what. Project V can handle anything that comes along. I couldn't care less what the platform is. What other technology can claim the same?
Here's an article on making best use of system resources, especially the cache, in multi-core systems. This is all too important if you're doing low level programming. Unfortunately, I doubt most people will understand how to properly take advantage of this. Most languages don't let you deal with the cache anyhow.
Celsius to Fahrenheit
int Celsius2Fahrenheit(int Celsius)
{
return 9*Celsius/5+32;
}
limitation: what if we want to pass a floating point number?
How to Interview a Programmer
How to Interview a Programmer
by Bill Venners
Summary
Recognizing good programmers among job applicants is not easy. This article contains interview techniques, garnered from a recent summit on writing better code, that can help you can find the most qualified programmers for your project.
Seven Golden Rules
- Explore an Area of Expertise
- Have Them Critique Something
- Ask Them to Solve a Problem
- Look at Their Code
- Find Out What Books They Read
- Ask About a People Problem
- Get to Know Them
In January, I attended a Writing Better Code summit in Portland, Oregon, organized by Scott Meyers and Bruce Eckel. At the three-day summit, 15 people gathered to discuss code quality and how they could improve it. Throughout this discussion, one theme was clear: good code is written by good programmers. Therefore, one great way to improve the code quality within an organization is to hire better programmers. The trouble is, recognizing a good programmer among a pool of job applicants is not easy.
Finding good programmers is hard because good programming is dependent on much more than just knowledge of programming language syntax. You need someone who, despite wearing striped pants with a polka dot shirt, has a good sense of taste in OO design. You need someone who is creative enough to find innovative solutions to problems, yet anal retentive enough to always line up their curly braces. You need someone who is humble enough to be open to suggestions for improvement, but arrogant enough to stand firm and provide leadership when they are the best person to provide it. How can you tell all this about a stranger by spending 30 minutes with them in a conference room?
The final morning of the Writing Better Code summit, Bruce Eckel announced he was "hijacking" the meeting. Bruce wanted each person at the table to share his or her interview techniques. He wanted to know how we recognize a good programmer in an interview. In this article, I highlight some interview techniques discussed that morning. If you have more ideas or would like to discuss any techniques presented here, please post a comment to the News & Ideas Forum Topic, How to Interview a Programmer.
Explore an Area of Expertise
Although various interview methods were tossed about that morning, a few fundamental techniques emerged from the discussion. For example, rather than simply look for expertise and experience in the exact area in which the candidate will work, you should look for general programming talent and ability. One way to explore and judge a candidate's talents is to explore an area of their expertise:
Dave Thomas: Hire for talent. One of the biggest mistakes companies make is to recruit from a shopping list: I need a programmer with six years Java, three years Oracle, and two years EJBs. The world changes, so you need to hire folks who change with it. Look for people who know computing, not necessarily particular narrow niches. Not only will they adapt better in the future, they're also more likely to be innovative in the present.
Chris Sells: To identify how good the candidates are technically, I let them choose an area in which they feel they have expertise. I need them to know something well, and I ask them about that. I ask them why. I want them to know why something in their area of expertise works the way it does. I'm not necessarily after an expert in the area I need. If they learned why in the past, I have confidence they'll learn why in the future.
Have Them Critique Something
Another technique involves the importance of creating a dialog with the candidate. To get to know the candidate's talents and personality, you can't merely ask questions that have short factual answers. You have to find a way to engage a conversation. To stimulate dialog, you can ask the candidate to critique some technology:
Josh Bloch: I ask candidates to critique a system or platform that we both have in common, preferably something they will use on the job. For example, I might ask, "What parts of Java don't you like and why?"
Pete McBreen: I give candidates samples of our current code and ask them to explain and critique it. This gives me a sense of their skills, but also lets them know what they can expect.
Ask Them to Solve a Problem
Another way to foster an open-ended dialog is to ask the candidate to perform a task: to solve a problem or create a design. Although everyone at the meeting seemed to agree that this was important and useful technique, it also generated a lot of concern. People felt that asking the candidate to solve puzzles and problems needed to be done with care:
Josh Bloch: I like to ask a candidate to solve a small-scale design problem, finger exercises, to see how they think and what their process is: "How would you write a function that tells me if its argument is a power of 2?" I'm not looking for the optimal bit-twiddling solution
((n & -n) == n). I'm looking to see if they get the method signature right, if they think about boundary cases, if their algorithm is reasonable and they can explain its workings, and if they can improve on their first attempt.Bruce Eckel: I ask candidates to create an object model of a chicken. This eliminates any problems with uncertainties about the problem domain, because everyone knows what a chicken is. I think it also jars people away from the technical details of a computer. It tests to see if they are capable of thinking about the big picture.
Scott Meyers: I hate anything that asks me to design on the spot. That's asking to demonstrate a skill rarely required on the job in a high-stress environment, where it is difficult for a candidate to accurately prove their abilities. I think it's fundamentally an unfair thing to request of a candidate.
Matt Gerrans: I don't like when I'm asked to write a program that does X on a piece of paper. Don't ask the candidate to write a program on paper. That is a waste of time and sweat. People don't write software on paper, they do it with computers using auto-completion, macros, indexed API documentation, and context-sensitive help. They think about it, refactor it, and even rewrite it. If you want to see a person's work, ask them to write some small module or implement some interface before the interview and bring the code on a notebook PC or on hard copy. Then you can review it and discuss the design, coding style, and decisions that went into it. This will give you a much more realistic and useful assessment of a person's work and style.
Kevlin Henney: I like design dialog questions that don't have a single fixed answer. That way they have to ask me questions, and this sparks a discussion. It's good to have a whiteboard available in the room. A dialog lets the interviewer see how the interviewee works, whereas a question of fact is just that: it is great for TV quiz shows, but doesn't tell you how someone will work and approach things over time. A puzzle question requires knowing a trick, which is in essence something that is either known or unknown. I dislike puzzle questions, because they don't require dialog.
Josh Bloch: What constitutes a reasonable question depends a lot on the candidate's experience and maturity.
Dave Thomas: I look for people with curiosity. Present problems, not puzzles.
Look at Their Code
Josh Bloch suggested one technique we all seemed to like: Have the candidate bring a code portfolio to the interview. Look at the candidate's code and talk to them about it. Although we were concerned that some candidates may not have code they could legally bring to the interview, we figured most candidates could probably come up with something. It can't hurt at least to ask a candidate to bring to the interview a sample of code they had written in the past.
Josh Bloch: I want to see their code. You get to see what they pick. You learn what they value. You learn how they communicate.
Find Out What Books They Read
Several people indicated that they ask candidates about the programming books they read to see if a programmer is self-motivated or concerned about improving their own programming skills:
Matt Gerrans: I ask candidates, "What books have you read about programming?" If the book is beyond syntax, that's important.
Randy Stafford: I find out what books they read because it's important to me that they educate themselves of their own volition.
Ask About a People Problem
As important as technical ability, or perhaps more important, is personality. How well would the candidate fit the team? How well would they fit the work environment? People used various techniques to judge personality:
Randy Stafford: Good citizenship is probably more important than technical prowess, because if you have people with the right kind of attitude and demeanor, you can help them gain the technical knowledge and software development habits. But if you have people who lack humility and maturity, it can be extremely difficult to get them to cooperate in reaching a goal, no matter how bright they are or what they've accomplished in the past.
Chris Sells: I ask candidates, "Tell me about a problem you had with a boss or teammate. Tell me how you've dealt with a problem with a boss."
Jack Ganssle: I check references. Now, I know these people are the candidate's five best friends, and will not say anything negative. But I ask those references for names of people who know the candidate, and go to these others for insight. This way I spread the net beyond anything the candidate ever imagined.
Kevlin Henney: I try to imagine if I would go to a pub and talk non-tech with them—not if I like them, but whether I could get along with them. Are they pubbable? Could I talk to them in a non-office situation?
Dawn McGee: The most likable person is often not the best person.
Dave Thomas: I think every team of a certain size needs a professional pain in the ass, because teams get complacent, fixed in their ways. They need nudging out of their comfort zone once in a while, so they can look at problems from a different perspective. There are two kinds of pains in the ass: the obnoxious boor—to be avoided on all teams—and the person who never learned that grownups shouldn't ask "Why?" all the time. The latter is a treasure.
Get to Know Them
Perhaps the prominent theme of our discussion was that you need to try to get to know the candidate as best you can. Talk to the candidate in the interview. Try to get a feel for them. If possible, bring them in on a trial basis or for a probationary period. That would give you more time to get to know the candidate, and give the candidate more time to get to know you:
Chuck Allison: I talk to them. I get a feel for them. I always ask about what they've done. I have found that by discovering what a person is excited about technically, you can learn a lot of important things about them. In the past I've asked people to describe a project that was especially interesting to them, or that was challenging and successful. On occasion I've asked what they've done that they're the most proud of. This usually reveals the depth of one's understanding and mastery. It also gets them to turn on the fire hose verbally, and you can sit back and get most of the answers you need.
Randy Stafford: I look at past projects listed on their resume, and ask them to talk about those projects—how was the team organized, what the technologies and architectures were used, was the software successful in production, etc. In their answers I'm listening for what lessons they learned from those experiences, and whether those lessons match with lessons I've learned from my experiences and from professional literature. I get a glimpse into how they perceive themselves in relation to the world around them. Some come off as arrogant, some ignorant, some helpless. Others sound humble, intelligent, and motivated. I often ask them what software development literature they read. Continuous education is very important to me.
Angelika Langer: In Germany, hiring is like marrying someone. It's "until death do us part"—a marriage without the backdoor of a divorce, because you can't fire employees. The only chance for firing someone is during a three- to six-month probationary period, or when the company goes out of business.
The major filtering is done before the interview, based on the curriculum vitae (CV) and submitted papers, such as evaluations from former employers. (In Germany, employers must provide every employee with a written evaluation when they leave the company.) The interview itself is usually brief. The main tool in filtering is scrutinizing the CV and papers; 98 percent of all applicants are disqualified in this phase. The interview should confirm the impression you gain from the applicant's papers and allows you to sense their personality. The lucky winner then goes on a probationary period.
Probation definitely does not replace the filtering; it just keeps a last exit open until you really must commit.
Andy Hunt: We've hired people who interviewed well, but they were terrible at the job. If possible, hire them in for a trial period.
Dawn McGee: You could also bring candidates in for half a day, and have them do what they would be doing on the job.
Conclusion
To sum up the overlying themes from our hour-long discussion in Portland: You should look for talent and fit more than specific skill sets. Ask open-ended questions to initiate revealing dialog. Ask candidates to critique something. Ask them to design something. Investigate their past experience. Review their code. And through conversation and, if possible, a trial period, you should try to become familiar with the candidate's technical abilities, talents, and personality.
Do you have an opinion on the techniques mentioned in this article? Do you have a tool or technique you use to find good programmers? Please share your ideas in the News & Ideas Forum Topic: How to Interview a Programmer.
How Do You Interview a Programmer?
Source :http://interviewinfo.net/blogs/for_employers/archive/2006/11/14/224.aspx
My notes:
Hire the natural self-taught talent! Having a CompSci college degree only means that they wasted 4 years (or more) of their lives. Whereas the self-taught programmers were busy writing software during those 4 years. And, why not test the interviewees on something more pragmatic, like create a business object that handles the CRUDs for s simple 3 or 4 property entity (or test them on something else that would be common for your company to write).
