Saturday, June 25, 2011

Top 10 Things Ten Years of Professional Software Development Has Taught Me

http://www.taylor.se/blog/2007/03/22/top-ten-things-ten-years-of-professional-software-development-has-taught-me/

I was reading this top ten list yesterday, and I thought I can problably come up with my own list of things no-one told me before I started developing software for money. This is my list.
  1. Object orientation is much harder than you thinkMaybe 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. Ten 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 communicationAnd 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 noWhen 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 importantThe 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 problemI 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 upChris 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 machineIt'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 teachersA 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 softwareNo 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 assholesMost 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.

Friday, June 24, 2011

If a programming language was a boat

http://mendel.soup.io/post/138357929/If-a-programming-language-was-a-boat



Java

Java is a cargo ship. It’s very bulky. It’s very enterprise~y. Though it can also carry a lot of weight. Will carry a project, but not very fun to drive.
Java programming language as a cargo ship
Original photo by cfarivar


PHP

PHP is a bamboo raft. A series of hacks held together by string. Still keeps afloat though.
PHP programming language as a raft
Original photo by permanently scatterbrained


C

C is a nuclear submarine. The instructions are probably in a foreign language, but all of the hardware itself is optimized for performance.
C programming language as a nuclear submarine
Original photo by Ryan C. McGinley


HTML

HTML isn’t really a
programming language
boat.
HTML is not a boat
Original photo by ascendeddaniel


Uploading Excel Data to the Bing Spatial Data Services

http://www.bing.com/community/site_blogs/b/maps/archive/2011/06/21/dev-tip-of-the-week-uploading-excel-data-to-the-bing-spatial-data-services.aspx

Thursday, June 23, 2011

How to add an event into user control in ASP.NET WebForms?


Reason: Put two user controls in same page, you want call one function in B while one thing happens in A.

Three steps to do that: Define, Raise and Book event. 

Define event in A:
    public delegate void AfterOneTask ();
    public event AfterOneTask AfterOneTaskHandler;

Raise event in A:
    protected void Submit_Click(object sender, EventArgs e)
    {
       ….
        if (this. AfterOneTaskHandler!= null) AfterOneTaskHandler();
       }
Book event in B:
    protected void Page_Init(object sender, EventArgs e)
    {
        this.ctlA.AfterOneTaskHandler +=new UserControlA.AfterOneTask(controlb.method1);
    }

What is 8-second rule

 A June 2001 Zona Research report entitled "The Need for Speed II" found that the average web user will wait about eight seconds for a page to download, but that current average download time across backbone connection on most web sites is almost ten seconds.[4]
The 8-second rule is an old (by Internet standards) way of measuring the adequate response time of a webserver through different bandwidth connections. It specified that if the load-time of a web page exceeds eight seconds, users are unlikely to wait, or "stick around", for its completion. In order to increase the "stickiness" of a website, faster ways to deliver the content to the user needed to be devised. These included stripping away unnecessary HTML code and using fewer images.[5]
It is generally believed that this rule no longer applies, since a much higher percentage of Internet users now have broadband available, making almost every website load up much faster, in some cases in less than a second. However, the rule has remained as a rough unit to measure the performance of a webserver.

http://en.wikipedia.org/wiki/Network_performance#8-second_rule