Latest Posts
While I was at TechEd in Barcelona last week, I had a chance to sit down with Mark Dunn from .NET Rocks and talk a little bit about ASP.NET MVC and jQuery. They've recorded the interview. You can watch it here
I've found that many of the things Jeff Atwood posts about, most of us think about. The difference is that some are so blatantly obvious that you would never even consider blogging about it. But each to his own.
However, there are some things that just blow my mind. His latest post about programmers are typists first is one of them. Let me first say that I'm a firm advocate of annihilating the mouse from a developer's toolbox. Ok, that might be a little extreme, but point being, you are more productive if you learn keyboard shortcuts and don't have to reach out so much for the mouse. However, I wouldn't say that developers are cats first, then programmers.
Initially one could understand Jeff's title as expressing that being a fast typist is important. If that were the statement, to a certain degree I would concur, and I say to a certain point because at least on my team, we don't measure productivity in terms of keys pressed per minute.
So Jeff comments:
We are typists first, and programmers second. It's very difficult for me to take another programmer seriously when I see them using the hunt and peck typing techniques. Like Steve, I've seen this far too often.
Well let's think about that for a moment. If you're not a professional typist or never taken courses, the only way to improve is through practice. As a developer, the more you write code, the more you practice your typing skills. People also tend to say that you really can't be a pen and pencil architect unless you've got your hands dirty with code, and that I do believe. So to a certain point, the previous statement makes sense, but I don't think it's black and white thing.
He continues to say:
Steve and I believe there is nothing more fundamental in programming than the ability to efficiently express yourself through typing. Note that I said "efficiently" not "perfectly". This is about reasonable competency at a core programming discipline.
What has the rate of keys per minute (KPM) got to do with efficient expressiveness of code?Efficiency can be an indication of how expressive or clear your code is, or how fast it executes where speed matters, not how fast you type it into a text file. I would say efficiency is more about coding if statements correctly or using LINQ where it makes sense.
This next comment blows my mind:
What I'm trying to say is this: speed matters. When you're a fast, efficient typist, you spend less time between thinking that thought and expressing it in code. Which means, if you're me at least, that you might actually get some of your ideas committed to screen before you completely lose your train of thought. Again.
I really don't have much to say about this other than it's utter nonsense. In fact he tries to justify it somewhat in the next paragraph:
Yes, you should think about what you're doing, obviously. Don't just type random gibberish as fast as you can on the screen, unless you're a Perl programmer. But all other things being equal -- and they never are -- the touch typist will have an advantage.
Advantage over what? Over thinking faster? Over beating the next guy on the team on expressing his thoughts?
I'm also a self-taught typist, and I've learnt through practice, spending years writing code. My wife is a great typist also. She didn't take courses either, she's worked with computers for many years. She suck at programming, but she's great at Office. Get the point? You become a good typist by practicing and using a computer. The more you use it, the better you become. You don't need to take a course on typing before learning how to program.
I was installing SQL Server 2008 today (x64 bit version) and after the initial checks it does, I got an error about MediaInfo.xml file missing. Looking in the folder where it had unpacked the files, effectively I couldn't find a reference to it. After a very hard session of extensive research, I found that others had run into similar issues. Some of the suggested solutions were to re-install .NET 3.5 SP1. Others said to re-install the complete .NET framework. One guy had re-installed his entire OS and still had issues.
Clearly not being the path I wanted to go down, I decided to try and install the 32 bit version to see if it was a problem with the 64 bit. This one seemed to go ahead with the install. Looking at the decompressed files, I saw that the missing files were there on the 32 bit. I then cancelled the install and ran the 64 bit one again. After decompressing the files, the missing files were also there. I thought maybe I had a bad run and let it continue. However once it did all the checks and I hit Continue, suddenly half of the files were deleted from the folder. So it seems that at some point the installer was deleting the files.
So instead of running the installer bootstrap, I decompressed the files and ran the setup manually. And it worked. So if you get a errors on missing files, decompress the package and run the setup.exe manually and it should work ok.
I'll be doing a talk in Belgium next month at the Visual Studio User Group, where I'll be covering topics such as Separation of Concerns, Single Responsibility, Interface Segregation, Dependency Injection and Inversion of Control, along with examples of IoC containers. There's limited space (90) and already 55 signed up, so if you're in or around the neighbourhood, got nothing better to do than here my brag, come along. I think they are organizing a geek dinner afterwards so it should be fun. Although the talk will be in C#, the important things to grasp are the concepts, not the language, be it Visual Basic, Delphi or whatever else (obviously it needs to be a OO language).
Everyone knows that unless you're writing about Harry Potter, it's hard to get rich from a book, and even more so a technical one. I wrote the book on WCF mostly as an adventure, being my first in Spanish and sole author. I decided sometime ago that I wanted to give all proceeds from my cut to a charity. After getting in touch with a number of them requesting information (let's just say I don't trust 100% all charities), and never getting a reply back from any, I decided to look for something close by. I'd heard about Juanma from a friend of mine (Guillermo Som) and we've been actively helping (Málaga .NET User Group as well as all other user groups around Spain) by organizing events, raffling prizes, etc. Juanma has an illness called Leukodystrophy also known as Alexander's Syndrome and the family is trying to raise funds to further investigations to find a cure.
Therefore, all proceeds from the author's cut will be destined directly to this cause. Krasis Press, the publisher is aware of this already and everything will be handled directly by them. So if you speak Spanish and need a book on WCF, know that you're also contributing to a good cause by buying a copy. If you don't, but feel you still want to help Juanma, please visit their web site: www.ayudajuanma.es
Here's my presentation from my TechEd talk on ASP.NET MVC. I'll be uploading the demos as soon as I get them cleaned up. Any questions, you know how to reach me.
It's been quite a week, certainly as far as things that interest me go:
- A much under-rated app - here's the low-down on the new Calculator in Windows 7. Now, don't mock, it's actually rather good!
- A load of posts on Azure (no surprise there!):
- ASP.NET MVC on Azure. It's all good stuff - I'm current using the AspProviders that this article talks about, but in conjunction with WCF REST rather than ASP.NET MVC. They work real well, except for one little detail around getting HTTP 401 errors returned back to the client. More on that in a later post...
- Links to useful sites in the Azure community.
- How to retrieve the logs from your Azure services. This will be essential if you're doing anything more than trivial stuff! I'm guessing (hoping!) that at some point features like log viewing will be available through the developer portal.
- A good intro to the Table Services part of Azure
- M has been getting a whole pile of traffic this week. Here are the good bits:
- A neat M grammar for modeling user stories. Even if you're not interested in M, it's worth reading since there is great value in this approach to gathering requirements.
- Generating code using M and T4. This is really in depth - I think it's fair to say that the language that he generates code from is of limited us, but the approach would be applicable to any DSL that you care to put together.
- Writing WPF using M. Of course, it's only a toy language, but it sure is cool.
- Consuming MGrammar output from C#. Suspect this is how most of us will use it for some time.
- The complexity in language design, and how M doesn't really change that. This link is the response - be sure to click the Frans Bourma link to see the original point (although be prepared to have your Compiler Design course from college come back and haunt you!)
- MrEPL. Lots of stuff is starting to do the old REPL thing again, brings back happy memories of BBC BASIC :)
You may be thinking 'here he goes again'. Not content with associating testing to the CIA the other week, he is now trying to create a tenuous link to Toyota. Bear with me though. There is a very real link between Toyota and software testing and that link is quality. In fact, any part of the software development lifecycle or any department within the development cycle can learn from Toyota. It is simply a case of process improvement.
People who know me, know that I love cars. More specifically that I love Japanese cars and even more specifically Toyotas. The reasons are simple, some models are quick, insane fun, frugal, comfortable and more importantly, reliable. Don’t just take my word for it the JD Power survey (a customer satisfaction survey) has placed Toyota (and luxury arm, Lexus) in the top 5 for the last 6 years.
The JD Power results for 2007.
So we have established Toyota have an enviable reputation for quality. We also know that software testing is about driving quality and reliability in to the software process and the product under test. There are many ways the two are linked together but the one I am going to concentrate on is Kaizen.
Kaizen is the Japanese term which literally means “continuous improvement” or "Good Change”. It is a methodology, a mind set even, that instills quality in to every single aspect of the workplace.
Toyota have taken Kaizen and made it a fundamental policy within its company which has resulted in them being famous for quality and reliability.
Every employee at Toyota has a say in how their area/department is run with quality and efficiency being the core goal. Anything at all that will improve efficiency and quality is implemented – no matter how small it is. It is not unheard of for the conveyor belts at Toyota’s Nagoya factory to be stopped as someone has spotted something which could be a potential quality issue. A process is then performed to work out how to solve the potential quality issue before the belts are resumed and work can continue. The end product is a car (and build process) that has an enviable reputation for quality.
Broadening the picture shows that almost every single Japanese car manufacturer has amazing quality levels and this is because in Japan, Kaizen is part of the culture.
Kaizen is what we in the IT industry often call "process improvement". Process improvement is something all companies should be doing to stay ahead in a competitive industry and to improve efficiency in general. Improving quality in the build, the documentation, the review process, the tools we all use daily, communication and anything else that can affect the way we work is essential.
Using Wikipedia's description of Kaizen we can clearly see that this fits nicely with how process improvement should work.
- standardize an operation
- measure the standardized operation
- gauge measurements against requirements
- innovate to meet requirements and increase productivity
- standardize the new, improved operations
- continue cycle ad infinitum.
It seems so simple but it is something many companies and individuals fail to grasp and implement. In order to improve there must be something to measure. In order to measure you must know what it is you are wanting to improve.
Most software testers have a thing for metrics and stats. They know deep down that metrics should be taken with a pinch of salt and that on face value, they are often not the 'whole' picture of the facts, but gathered over time they show a valuable measurement that can be used for improvement. Defects per build, defects per functional area, test case pass failure rates etc all show information regarding efficiency and quality.
A high number of defects per functional area may show that the specification needs improving or that there is a misinterpretation of implementation between development and test. It may just show that this area is very complicated and needs more resource, maybe even more detailed planning. Whatever the interpretation of the stats there are always areas for potential improvement.
Even the regular processes that people may take for granted could yield some areas of improvement, like daily stand-ups and team meetings right through to creating build environment and test stacks. There is always something that can be standardized, measured and then improved upon. Test case writing and detail levels are a classic example.
Often the first hurdle to overcome is the empowerment of employees to have their say and to feel confident in putting forward suggestions for improvement. End of project reviews, end of iteration reviews and general feedback forums are essential to getting a balanced view point. Making sure people feel comfortable giving feedback which at times can often be negative, is a crucial step forward.
However, Kaizen and process improvement can be taken too far. Companies that often pride themselves on a relaxed, none bureaucratic environment can soon lose this with too much process improvement. With process improvement often comes endless forms, communication documents, processes, rules and regulations. The key is finding the right balance, getting it just right so that quality and efficiency go up, but the work environment remains as you wish.
If Kaizen can be held responsible for high quality and reliable cars then process improvement can surely lead to high quality and reliable software and a software company having that reputation can’t be a bad thing.
http://www.gembapantarei.com/2006/08/kaizen_in_software_development_start_by_seeing_the_7_wastes.html
http://en.wikipedia.org/wiki/Toyota_Production_System
http://en.wikipedia.org/wiki/Big_Three_automobile_manufacturers
http://newyorkcto.blogspot.com/2007/06/kaizen-meeting-in-agile.html
http://www.oracle.com/technology/pub/articles/dev2arch/2008/05/kaizen-bpm-agile.html
A colleague ran into a very interesting issue whilst working on his teams release build script. He was trying to get the custom built version number setup before a clean of the old source had taken place (so the version number could become the build number). To achieve this he was calling a sub script that (for use by a different target) setup a list of all the AssemblyInfo.cs files that needed to be updated with the version number. Later on in the build (after the clean / get) he reran this same script (for a different target) to write the version numbers into the AssembyInfo file. At this point the script would fail as one of the files wasn't there (a remnant of a previous packaging process). Much head scratching ensued as we tried to figure out how the heck an item list in a different script, invoked with MSBuild was populated from the first time it ran...
A theory was constructed that something was being cached, or data was moving in a way we didn't expect. Either the MSBuild task held onto scripts, or the item list was passed back to the calling script. The later theory was quickly discounted, which just left us with the MSBuild task caching script instances.
After a bit of digging around in the Microsoft.Build.Tasks assembly I managed to reach down into where it was actually executing MSBuild... not (as I'd thought) by spinning up a seperate process, but by calling back into it's own build engine. Fair enough, saves having to start a new process (although it explained some unusual file locking we'd seen as well). Further digging into the build engine found the following:
1: Project project = null;
2: Project existingProject = null;
3: Project project3 = (Project) this.projectsLoadedByHost[info.FullName];
4: if (project3 != null)
5: {
6: existingProject = project3;
7: if (project3.GlobalProperties.IsEquivalent(globalProperties))
8: {
9: project = project3;
10: }
11: }
Scripts are held firstly by the name of the script, and secondly BY THE PROPERTIES THEY ARE PASSED...
So recalling the same script with a different target but the same properties doesn't invoke a new instance of the script. No, the old one is reused and since Items are populated only when the script is first invoked the list of AssemblyInfo.cs files was as it was BEFORE the clean / get, not (as we wanted) afterwards.
In this instance the simple fix was to add an extra property to each of the two calls to ensure that the property lists were different ... and voila! Problem solved.
I wanted a way of limiting the number of clients that could call a long running and memory intensive web method which exported or imported several thousand lines of data into my database ....so a colleague of mine suggested semaphores. I implemented a singleton class which looked like code snippet B. It all seemed honkey dorey only that we found it turned out to be a pointless use of semaphores.
Semaphores add value when there was a requirement to queue up threads so that if there were 10 threads trying to access the service via a semaphore which allowed only 3 threads, the other threads will be queued up and will wait until the executing threads completed.
Using this singleton semaphore class to limit the number of clients that could call my long running and memory intensive web method was not fully taking advantage of the queuing ability of semaphores. I was monitoring the count of threads and throwing an exception when the limit I set was reached - which is why I said it was pointless.
One other issue with using semaphores for this purpose is that if the IIS application pool was limited to say 10 threads, and 10 users attempted to call my slow running web method call, the threads will be queued which means that if an 11th thread which wanted to make a really fast web method call tried to make its request, it will get a thread aborted exception because the number of threads allowed for the app pool has been exceeded.
So .......what I did instead was to implement a really simple web services gateway which implemented IDisposable so that when called within a using, the count was incremented and on Disposal of the instance, the count is decremented. I created a static instance of it within my web service and just used it when I needed to. It works like a treat and is dead easy to implement. See code snippet A_1 and code snippet A_2.
================ CODE SNIPPET A_1 =========================
1: private static WebServicesGateway webServicesGateway = new WebServicesGateway(["noOfThreadsPermittedForWebCall"]);
2:
3: [WebMethod]
4: public byte[] RunMyLongRunningMemoryIntesiveMethod()
5: {
6: using (webServicesGateway.GatewayRequest())
7: {
8:
9: //do something
10:
11: }
12: }
================ CODE SNIPPET A_2 =========================
1: using System;
2: using System.Data;
3: using System.Configuration;
4: using System.Web;
5: using System.Web.Security;
6: using System.Web.UI;
7: using System.Web.UI.HtmlControls;
8: using System.Web.UI.WebControls;
9: using System.Web.UI.WebControls.WebParts;
10:
11: namespace Server
12: {
13: /// <summary>
14: ///
15: /// </summary>
16: public class WebServicesGateway
17: {
18: private int maxThreadCount = 3;
19: private static int currentThreadCount;
20: private static Gateway gateway;
21: private object instanceLock = new object();
22:
23: public WebServicesGateway(int threadCount)
24: {
25: maxThreadCount = threadCount;
26: gateway = new Gateway(this);
27: }
28:
29: private void DecrementCount()
30: {
31: lock (instanceLock)
32: {
33: currentThreadCount--;
34: }
35: }
36:
37: public IDisposable GatewayRequest()
38: {
39: lock (instanceLock)
40: {
41: if (currentThreadCount >= maxThreadCount)
42: {
43: throw new WebServicesGatewayLimitException("Gateway has reached its limit");
44: }
45: currentThreadCount++;
46: }
47: return gateway;
48: }
49:
50: private class Gateway : IDisposable
51: {
52: WebServicesGateway webServicesGateway;
53:
54: public Gateway(WebServicesGateway webServicesGateway)
55: {
56: this.webServicesGateway = webServicesGateway;
57: }
58:
59: public void Dispose()
60: {
61: this.webServicesGateway.DecrementCount();
62: }
63: }
64: }
65:
66: public class WebServicesGatewayLimitException : Exception
67: {
68: private static readonly log4net.ILog log = log4net.LogManager.GetLogger(System.Reflection.MethodBase.GetCurrentMethod().DeclaringType);
69:
70: public WebServicesGatewayLimitException(string message)
71: : base(message)
72: {
73: log.Error(message);
74: }
75: public WebServicesGatewayLimitException(string message, Exception exception)
76: : base(message, exception)
77: {
78: log.Error(message, exception);
79: }
80: }
81: }
82:
================ CODE SNIPPET B =========================
1: using System;
2: using System.Data;
3: using System.Configuration;
4: using System.Web;
5: using System.Threading;
6: using System.Web.Security;
7: using System.Web.UI;
8: using System.Web.UI.HtmlControls;
9: using System.Web.UI.WebControls;
10: using System.Web.UI.WebControls.WebParts;
11: namespace Server
12: {
13: /// <summary>
14: ///
15: /// </summary>
16: public class WebMethodCallLimiter : IDisposable
17: {
18: static WebMethodCallLimiter instance = null;
19: static readonly object instanceLock = new object();
20: private static Semaphore semaphore = null;
21: private static int currentThreadCount = 0;
22: private static int maxThreadCount = 3;
23:
24: private WebMethodCallLimiter()
25: {
26: semaphore = new Semaphore(0, maxThreadCount);
27: }
28: public void Pool()
29: {
30: if (currentThreadCount >= maxThreadCount)
31: {
32: throw new SemaphoreReachedLimitException("Semaphore has reached its limit");
33: }
34:
35: lock (instanceLock)
36: {
37: currentThreadCount++;
38: }
39: semaphore.WaitOne();
40: }
41:
42: public void Dispose()
43: {
44: currentThreadCount--;
45: semaphore.Release();
46: }
47:
48: public static WebMethodCallLimiter Instance
49: {
50: get
51: {
52: lock (instanceLock)
53: {
54: if (instance == null)
55: {
56: instance = new WebMethodCallLimiter();
57: }
58: return instance;
59: }
60: }
61: }
62:
63: }
64: public class SemaphoreReachedLimitException : Exception
65: {
66: private static readonly log4net.ILog log = log4net.LogManager.GetLogger(System.Reflection.MethodBase.GetCurrentMethod().DeclaringType);
67: public SemaphoreReachedLimitException(string message)
68: : base(message)
69: {
70: log.Error(message);
71: }
72: public SemaphoreReachedLimitException(string message, Exception exception)
73: : base(message, exception)
74: {
75: log.Error(message, exception);
76: }
77: }
78:
79: }
This should have been sent last Friday, but other stuff got the better of me. Anyhow, here's last weeks "interesting stuff":
- The reason why we have iterations: Early Pain
- An example of a simple TODO language implemented in Mg. For those use to parsers, BNFs etc, this will be an easy read. For those that haven't come across such things, it's a nice introduction.
- How SanDisk's ExtremeFFS works. Bets on how long it is before Joe gets one :)
- A nice summary of PDC. Thanks, John - saves me writing it!
- Access to the ETW APIs from .Net using NTrace. Not used it yet, but suspect this is worth keeping an eye on.
- A new TFS Power Tools release. Surprised that Obama got quite so much press coverage considering that this came out the same week.
- Code Contracts in C# (well, any .Net language in fact). It's due out with .Net 4.0, but it also looks like it works with VS2008. Getting into the habit of declaring the intent of your code in this way can only be a good thing - it helps out with documentation, static analysis, runtime checks and gives Pex something to get its teeth into.
- A good reality check on some of the hype going on about Oslo right now.
- Hadi is twittering. Hell has also frozen over.
- For those of you with a media center and an iPhone / iPod touch, this is cool. I've been running it for a week or so (before this review came out), and although at $6 it's one of the most expensive iPhone apps I've bought, it's a load cheaper than the wireless mouse / keyboard that I would have bought otherwise.
- Should we put comments in our code? Neal Ford has shares his views here - not sure I entirely agree with him, but I do respect his opinion and it's hard to refute his reasoning. Some of the comments are pretty decent, so it's worth reading the whole page.
If you're doing multiple demos that somehow involve CSS, make sure you rename the default Site.css file ASP.NET MVC creates for you. Otherwise, during a presso you'll go crazy trying to figure out why half of your demos aren't rendering correctly. In other words, make sure each demo has it's unique CSS filename so you don't run into browser cache "issues".
WPF converters provide a way to apply custom logic to a binding. In this article, we will make use of WPF converters to demonstrate its usefulness. Our sample application is a firewall controller which lets us switch on and off the firewall by clicking a button, changing the ellipse colour accordingly.
Let's start by creating a new WPF Application project. Then we will create a simple Firewall class. The code is pretty straightforward:
public class Firewall : INotifyPropertyCha