Anonymous Methods in C# are Your Friend Tue, May 20. 2008
A previous post warned of some of the dangers of using Anonymous methods in C#. Yes, it's true you can get yourself into serious trouble with these C# treats. But as you play with them some more, you can actually see that they are much more fun and less scary than you might first think.
One of the first things you need to realize when anonymous methods are created is that they capture / hijack variables that are used in that anonymous method from the scope that they were originally in. So yes, modifying the variable from a particular scope is going to change its value for everyone else within that same scope as well, regardless of which block it is executed from. This is very different from the Java way of doing things (as I understand) where a variable that is accessed from an inner class must be declared as final, read-only, uninteresting. That's not to say that you can't do the same thing in Java, but one dimensional arrays are such a pain. I digress.
One of the first things you need to realize when anonymous methods are created is that they capture / hijack variables that are used in that anonymous method from the scope that they were originally in. So yes, modifying the variable from a particular scope is going to change its value for everyone else within that same scope as well, regardless of which block it is executed from. This is very different from the Java way of doing things (as I understand) where a variable that is accessed from an inner class must be declared as final, read-only, uninteresting. That's not to say that you can't do the same thing in Java, but one dimensional arrays are such a pain. I digress.
Continue reading "Anonymous Methods in C# are Your Friend" »
How to Change keyboard Language in Windows Tue, Jan 15. 2008
I just wanted to share a bit of useful information with the masses of XP users out there. I have been testing out some new languages for PC Doctor, so I have all of the possible language packs installed, some keyboards enabled, and I even let the language bar stay open every once in a while. Usually I'm pretty diligent about keeping the keyboard in English though, considering I don't know how to type the languages I'm testing.
Today I wasn't paying attention and I locked my computer, like ya do, when I walked away for a minute. When I came back, I typed my password in and hit "OK", like ya do. Incorrect Password. I just figured that my fat fingers were flyin' too fast and I might have messed up. Incorrect Password. Maybe caps lock, shift key, num lock, something wasn't working right. Incorrect Password. Okay, so my password is right, let's check the domain... Wait a minute, why am I typing in Hebrew!?!
As fate would have it, clicking on the "extended" options button, let me know that my domain was correct, but I had been typing likely gibberish into the password field. In case you were wondering, asterisks look the same in Hebrew as they do in English and quite a few other languages. So what I expected: whenever a blue box with a language code in it is displayed, you can click on the box and a drop down will let you pick the language you want to type in. Blue box does nothing.
So now only can I not change the language, I can't log in to figure out how to change the language to log in to... Well, you get the point. So I got onto my fellow developer's machine and did a quick little search and found the following page:
How to change keyboard language in Windows
On it, there's a very obscure shortcut to change keyboard languages: ALT-SHIFT. I never would have thought pressing two modifier keys would have an effect. So there you go, if you ever find stuck at a login box and the only choice you have is to type in Korean and your password is in Russian, hit ALT-SHIFT a few times and you should see the "blue box" rotate among the enabled input languages.
Note: If you don't already have multiple languages set up / installed, the shortcut doesn't work.
Today I wasn't paying attention and I locked my computer, like ya do, when I walked away for a minute. When I came back, I typed my password in and hit "OK", like ya do. Incorrect Password. I just figured that my fat fingers were flyin' too fast and I might have messed up. Incorrect Password. Maybe caps lock, shift key, num lock, something wasn't working right. Incorrect Password. Okay, so my password is right, let's check the domain... Wait a minute, why am I typing in Hebrew!?!
As fate would have it, clicking on the "extended" options button, let me know that my domain was correct, but I had been typing likely gibberish into the password field. In case you were wondering, asterisks look the same in Hebrew as they do in English and quite a few other languages. So what I expected: whenever a blue box with a language code in it is displayed, you can click on the box and a drop down will let you pick the language you want to type in. Blue box does nothing.
So now only can I not change the language, I can't log in to figure out how to change the language to log in to... Well, you get the point. So I got onto my fellow developer's machine and did a quick little search and found the following page:
How to change keyboard language in Windows
On it, there's a very obscure shortcut to change keyboard languages: ALT-SHIFT. I never would have thought pressing two modifier keys would have an effect. So there you go, if you ever find stuck at a login box and the only choice you have is to type in Korean and your password is in Russian, hit ALT-SHIFT a few times and you should see the "blue box" rotate among the enabled input languages.
Note: If you don't already have multiple languages set up / installed, the shortcut doesn't work.
"Found Cake" Fri, Nov 9. 2007
There have been many ways to describe a common office phenomenon. Some call it a gift, others litter, but I think most apt is "Found Cake." To understand this definition, please refer to the following web comic.
Penny Arcade - It Looks Delicious
Now, coming across "found cake" on the street is one thing. I'm not sure how interested I would be in picking up that treat. In an office though, it's a treat. No one knows exactly where it comes from, they only know they got there just in time.
In fact if I'm not mistaken, there's an economic theory that the utility derived from "found cake" is inversely proportional to the amount left after you have taken your piece. In layman's terms, if you're the last person to get a piece, you ultimately end up enjoying it the most. I find this is true regardless of the size of the piece you do end up getting. Mostly because if you get the last piece, you also get the implied right to gloat to others about your feat. It's just polite.
I wonder if any "found cake" studies have been performed. I bet you they'll find that the first slice is the largest and the last slice lasts the longest. Maybe that's what we were just subjected to, a "Found Cake Study." I think in either case, it is a win / win. Free cake in the name of science. Keep the found cake coming.
Penny Arcade - It Looks Delicious
Now, coming across "found cake" on the street is one thing. I'm not sure how interested I would be in picking up that treat. In an office though, it's a treat. No one knows exactly where it comes from, they only know they got there just in time.
In fact if I'm not mistaken, there's an economic theory that the utility derived from "found cake" is inversely proportional to the amount left after you have taken your piece. In layman's terms, if you're the last person to get a piece, you ultimately end up enjoying it the most. I find this is true regardless of the size of the piece you do end up getting. Mostly because if you get the last piece, you also get the implied right to gloat to others about your feat. It's just polite.
I wonder if any "found cake" studies have been performed. I bet you they'll find that the first slice is the largest and the last slice lasts the longest. Maybe that's what we were just subjected to, a "Found Cake Study." I think in either case, it is a win / win. Free cake in the name of science. Keep the found cake coming.
This Code is Your Code, This Code is my Code Fri, Aug 31. 2007
Upon running my daily blogging circuit, I came across this article that really hit home with me and I feel compelled to share. Go ahead and read it, and if you'd like, read my comments on it.
http://blogs.msdn.com/oldnewthing/archive/2007/08/21/4486197.aspx
http://blogs.msdn.com/oldnewthing/archive/2007/08/21/4486197.aspx
Continue reading "This Code is Your Code, This Code is my Code" »
C++ Code Spell Checker Wed, Aug 15. 2007
I'm not sure that this is in great demand. Assuming you have a compiler worth its salt, then you'll know if you spell a variable name incorrectly or swapped a couple of letters in a function call. But imagine if you did indeed have a code spell checker, how would you implement it?
Cruise Control Tue, Jul 10. 2007
Cruisecontrol is an example of a continuous integration tool. In theory, these are amazingly useful development tools. The idea is to have a tool with the sole job of getting the newest code, compile it, test it, and give some results. This way whenever a change is made, within a short amount of time, we know if it broke something else, even if it wasn't intended to. This is great for those Windows developers stomping all over the Linux guys, or the Asapi guys breaking the UI, again.
The way Cruisecontrol is currently shipped, it is ideal for one machine, one project, one repository. Unfortunately when you have 10 different targets you want to run, differentiate between build failed and tests failed, compile on different machines, architectures, and operating systems... etc. This is where Cruisecontrol starts to slow down. It's still top notch, and modifying it is a cinch, but all these modifications can add up.
So far Cruisecontrol here consists of 4 machines, 2 Windows build machines, 1 Linux build machine, and a Windows web server. The build machines are all accessing an existing Perforce repository, and they FTP the necessary results to the web server for display. So far, this is out of the box behavior. Cruisecontrol can automatically check Perforce for changes, sync the local client, and there are build in FTP classes for sending logs and build status files.
Trying to get Cruisecontrol to play nice with existing build and test products was the first challenge. When running the build system from the command line, alot of output is generated, and almost none of the useful stuff is distinguishable. Cruisecontrol does the nice thing and parses all of the warnings and errors out of the logs for you. The build scripts used had a lot of unnecessary warning level messages, so the first step was to change those to info level messages. Next, the web interface was just poor looking. I mean, it's great to have it out of the box, but everything just ran together. So with a little added style and a few changes to the xslts, the errors and warnings all stood out by target, file, everything.
Next were the tests. Needless to say, of course we don't use JUnit here, the default test suite that Cruisecontrol supports. So the test results aren't going to match up. Luckily there was another xslt that transformed our results into JUnit style xml. Not all of the data was Cruisecontrol expects was present, and Cruisecontrol obviously had a bunch of contingency cases built in when they designed their xslts to get the test results web ready. Since our company uses our results, I scrapped the Cruisecontrol xslts and wrote a simple transform that does the trick. If anything new comes up, which I doubt, I'll worry about that then.
Now we need to deal with our 45+ minute build times. It would be nice to know what part of the build we are on, just as a general estimate on how much further we need to go. It's also nice to know if maybe the build crashed and needs to be restarted. There is a very handy plugin already provided that overrides the default ant logger. All it does is override the "target started" event to append the target name to the build status file. This way whenever a target is started, we can see the time and name of that target on the project web screen. Well, we could if this was uploaded to the web server.
Like I mentioned, our configuration is unique in its needs with separate build machines from web servers. The remote web server can't (yet) use the build machine's JMX console to manage the builds. It also can't read the minds of the build machines to know of there has been any updates. The build machines have to send everything to the web server in order for it to post the results.
Cruisecontrol was nice because it offered FTP support for the built in reporting functionality, but this doesn't automatically extend to the upgraded logger mentioned above. It's also another pickle because technically the FTP classes extend to be Cruisecontrol plugins, but the logger is an Ant plugin. This is where Frankenstein becomes my good friend. I took a direct copy of the logger extended class and called it an FTP class. There already existed an "AbstractFTPClass" in Cruisecontrol. Only problem is my one class couldn't extend from the logger class AND the ftp class, too bad. So I ended up having to write a GenericFTPClass that fakes all of the parts that are needed. Put a generic into my new logger class, and we're golden. I'm downplaying all that of course, but you get the idea.
Next is to possibly add some features to the new FTP class to slow down the transfers a bit. On every new target, there is an FTP send. I can imagine this traffic skyrocketing with multiple builds, etc. So maybe adding an "updatenum" or "updatetime" that will specify a number of updates or seconds before FTPing. The next thing is to also get this better incorporated into the web interface. Our typical build has well over 300 targets before it's done, more if running tests. Having all of these displayed at once is WAY too vertical.
Lastly, there's the cool things that other houses do with CITs. Whenever a build breaks here, (almost) everyone gets an e-mail if they are on the changelist for that broken build. If you're unfortunate enough to have submitted something after it broke, you're getting an e-mail too. Soon everyone, every change, until a change fixes the build. I've seen online different lights that can be triggered, alarms, etc. Lava lamps even that not only tell you the status of the build, but how long it's been there. We've even talked about hooking up a text reader that will periodically announce the names of the people on the changelist and politely remind them to fix the build.
Hopefully this little (really?) blurb helps everyone understand how useful these continuous integration tools (cit) are.
The way Cruisecontrol is currently shipped, it is ideal for one machine, one project, one repository. Unfortunately when you have 10 different targets you want to run, differentiate between build failed and tests failed, compile on different machines, architectures, and operating systems... etc. This is where Cruisecontrol starts to slow down. It's still top notch, and modifying it is a cinch, but all these modifications can add up.
So far Cruisecontrol here consists of 4 machines, 2 Windows build machines, 1 Linux build machine, and a Windows web server. The build machines are all accessing an existing Perforce repository, and they FTP the necessary results to the web server for display. So far, this is out of the box behavior. Cruisecontrol can automatically check Perforce for changes, sync the local client, and there are build in FTP classes for sending logs and build status files.
Trying to get Cruisecontrol to play nice with existing build and test products was the first challenge. When running the build system from the command line, alot of output is generated, and almost none of the useful stuff is distinguishable. Cruisecontrol does the nice thing and parses all of the warnings and errors out of the logs for you. The build scripts used had a lot of unnecessary warning level messages, so the first step was to change those to info level messages. Next, the web interface was just poor looking. I mean, it's great to have it out of the box, but everything just ran together. So with a little added style and a few changes to the xslts, the errors and warnings all stood out by target, file, everything.
Next were the tests. Needless to say, of course we don't use JUnit here, the default test suite that Cruisecontrol supports. So the test results aren't going to match up. Luckily there was another xslt that transformed our results into JUnit style xml. Not all of the data was Cruisecontrol expects was present, and Cruisecontrol obviously had a bunch of contingency cases built in when they designed their xslts to get the test results web ready. Since our company uses our results, I scrapped the Cruisecontrol xslts and wrote a simple transform that does the trick. If anything new comes up, which I doubt, I'll worry about that then.
Now we need to deal with our 45+ minute build times. It would be nice to know what part of the build we are on, just as a general estimate on how much further we need to go. It's also nice to know if maybe the build crashed and needs to be restarted. There is a very handy plugin already provided that overrides the default ant logger. All it does is override the "target started" event to append the target name to the build status file. This way whenever a target is started, we can see the time and name of that target on the project web screen. Well, we could if this was uploaded to the web server.
Like I mentioned, our configuration is unique in its needs with separate build machines from web servers. The remote web server can't (yet) use the build machine's JMX console to manage the builds. It also can't read the minds of the build machines to know of there has been any updates. The build machines have to send everything to the web server in order for it to post the results.
Cruisecontrol was nice because it offered FTP support for the built in reporting functionality, but this doesn't automatically extend to the upgraded logger mentioned above. It's also another pickle because technically the FTP classes extend to be Cruisecontrol plugins, but the logger is an Ant plugin. This is where Frankenstein becomes my good friend. I took a direct copy of the logger extended class and called it an FTP class. There already existed an "AbstractFTPClass" in Cruisecontrol. Only problem is my one class couldn't extend from the logger class AND the ftp class, too bad. So I ended up having to write a GenericFTPClass that fakes all of the parts that are needed. Put a generic into my new logger class, and we're golden. I'm downplaying all that of course, but you get the idea.
Next is to possibly add some features to the new FTP class to slow down the transfers a bit. On every new target, there is an FTP send. I can imagine this traffic skyrocketing with multiple builds, etc. So maybe adding an "updatenum" or "updatetime" that will specify a number of updates or seconds before FTPing. The next thing is to also get this better incorporated into the web interface. Our typical build has well over 300 targets before it's done, more if running tests. Having all of these displayed at once is WAY too vertical.
Lastly, there's the cool things that other houses do with CITs. Whenever a build breaks here, (almost) everyone gets an e-mail if they are on the changelist for that broken build. If you're unfortunate enough to have submitted something after it broke, you're getting an e-mail too. Soon everyone, every change, until a change fixes the build. I've seen online different lights that can be triggered, alarms, etc. Lava lamps even that not only tell you the status of the build, but how long it's been there. We've even talked about hooking up a text reader that will periodically announce the names of the people on the changelist and politely remind them to fix the build.
Hopefully this little (really?) blurb helps everyone understand how useful these continuous integration tools (cit) are.
« previous page
(Page 1 of 1, totaling 6 entries)
next page »
Quicksearch
Polls
Which phone is for you?
Archives
Archives
Archives
Blog Administration
Information
Resources
Categories
Authors
© 2010 PC-Doctor, Inc. | About this site | Contact | RSS | Back to top
Design by Andreas Viklund | Serendipity Template by Carl