This is a cool website: http://www.techinterview.org/
It lists a bunch of logic puzzles that you'd likely see in a tech interview. Nice way to start the morning.
This is a cool website: http://www.techinterview.org/
It lists a bunch of logic puzzles that you'd likely see in a tech interview. Nice way to start the morning.
I had talked about how to trigger an event from a UserControl.
This ability has many benefits, such as with refactoring. For example, suppose a UserControl is hosted on many different pages, and each page requires that the control have slightly different validation that incorporates values from the host page. One way to do this is to have the UserControl call a validation method on the host page.
Here's a code snippet you can download that shows how to have a UC call a method on its parent. The idea is to add an event member to the control, and hook it up with a delegate. (I had initially seen this technique from an article on MSDN several years ago).
This specific example has four files:
The UserControl contains an event "UpdateDate" and the host page adds a method to handle the event: RecordNav1_UpdateData.
RecordNav1.UpdateData += new AspxDemo_Events_RecorNav.UpdateDataEventHandler(RecordNav1_UpdateData);
You can download the presentation and code samples here.
Here's the abstract:
.Net 2.0 introduces MSBuild – Microsoft’s new build engine with a process-oriented scripting language. While MSBuild is marketed for compilation and build processes, it is really a full-fledged automation language. It includes structured control flow, variables, refactorability, error handling, logging, and powerful extensibility. You can easily integrate MSBuild into your own enterprise processes and start adding value right away.
If you have the time, these processes are very cheap yet effective. People who don't have the time pay for extra products to make these processes go faster (a powerful dishwasher, chemical cleaning products, or clothes dryer). It's the old cliche - time is money. Software development is the same way. Being able to just kick off a background process that does work for you can be a great way to increase productivity. It's like being able to do two things at once, such as integrating your code (continuous build on a build server) and doing local development, or running a local pre-checkin script to verify for unit test errors and reading a design doc.
It gets especially cool if you have access to other machines (or virtual machines), and you can kick off more than two things at once - like having a database integration test run on Machine X, performance tests run on Machine Y, Static Code Analysis / Unit Test coverage run on Machine Z, all while catching up on email.
All this really requires is the desire to multi-task, and the hardware to do it. Given that a computer is much cheaper than a developer, if one is multi-tasking properly, it could be well worth the investment
This Wednesday (Nov 15) I'll be presenting at the Chicago .Net User's Group on MSBuild: A Process Automation Language. Pizza starts at 6:30pm, the presentation at 7:00.
.Net 2.0 introduces MSBuild – Microsoft’s new build engine with a process-oriented scripting language. While MSBuild is marketed for compilation and build processes, it is really a full-fledged automation language. It includes structured control flow, variables, refactorability, error handling, logging, and powerful extensibility. You can easily integrate MSBuild into your own enterprise processes and start adding value right away.
It should be a good time.
When .Net 2.0 came out, it had a slew of powerful new features that made many things easier. Some people have asked: "Does .Net 2.0 make us all dumber?" The thinking is that .Net 2.0's new power spoils us, much like calculators spoil many of today's kids from no longer being able to do basic arithmetic.
My answer is no - .Net 2.0 does not make us all dumber, for at least three reasons:
There will always be a spectrum of smart, average, and below-average developers. As the technology continually grows, I think the trend isn't that the whole spectrum is getting dumber, but rather that it's getting more polarized. For example, .Net drastically lowered the entry-level for web programming (so less-smart people could start becoming web developers), but it also let you do more (so power users could do more).
There is an interesting conflict between skill vs. humility:
So, the problem is that a smart person helps the team, but smart people usually have egos, which hurt the team. It prompts the question, would you rather have a coworker that is an egotistical star, or a humble average? (Of course everyone wants the best of both worlds, but life affords very few of those).
I see pros and cons to all the options on the spectrum. If you're doing a highly-complex feature, you may need the skills of the egotistical star, and may just need to tolerate the ego that goes along with it. If you're doing more commodity-type work, the humble average guy could be sufficient.
Personally, I'd like a balance, but find teamwork to trump ego. Because in enterprise architecture, you're always on teams with other people, and getting along with those people makes a world of difference. I'd rather be 10% late, and appreciate the team, then 10% early and hate the job.
I also find it's easier to learn from humbler people because they're more willing to share ideas, don't take criticism personally, and put the good of the project ahead of their personal ambitions.
Questions that I'd ask when trying to pick a person for a team: