Source blog: Rambling on Software
Controllers are OK in ReactJS
The React community seems to eschew the use of 'controllers' within a React application. In fact, there is a tendency towards positioning React/Flux as an entirely new paradigm. As much as I am extrememly happy to be able to use React to build web apps, those of us old enough to have built desk-top applications are familiar with the notion of an immediate-mode UI (see blog post from James Long where he talks about retained vs immediate mode UI development). After having been involved in prototyping an application in React for a few weeks, it still feels to me as though there is a place for controllers in this universe.
The Library vs Frameworks Debate is Over
And nobody won. Its just that there isn't much of a difference any longer. One of the significant factors that differentiated a library from a framework was control flow. You called a library, it did something for you, and then gave you back a result. A framework, on the other hand, would call into your code when the framework decided it was necessary. And all the mechanism that was making that decision about when to call your code was 'hidden', making it harder to reason about your application as a whole. So there were a lot of arguments about whether frameworks were evil, etc.
Thinking and Software Development
Those of us who have been developing software for more years than we might care to admit, are sometimes inclined to fret about the skills that junion programmers lack -- particularly those fresh out of university or college. And as is typical with software developers, if you have N of them in the room, you'll have at least N+1 opinions about just what skills are most important and the least well prepared for by our educational institutions. Naturally I have my own opinions and I'd like to argue about why they're important not just for a computer science education, but any type of education.
Weird Latency in Request Handling and Session State
I just spent a couple of hours working with another developer on a weird request latency problem in certain ASP.NET requests. We've got an aspx page with a number of images that are themselves fetched via an aspx page (because they are being pulled out of the DB). When looking at the timeline for these requests in Chrome, most of them would complete quite quickly (less than 200 ms) but typically there were 2 that took much longer; one usually around 1 sec, and then other usually around 500 ms. We already had logging in place that was measuring the time from BeginRequest() to EndRequest(), and the logs showed a consistent processing time for all of the image requests, even the two that were taking much longer to get back the browser.
Weird Latency in Request Handling and Session State
I just spent a couple of hours working with another developer on a weird request latency problem in certain ASP.NET requests. We've got an aspx page with a number of images that are themselves fetched via an aspx page (because they are being pulled out of the DB). When looking at the timeline for these requests in Chrome, most of them would complete quite quickly (less than 200 ms) but typically there were 2 that took much longer; one usually around 1 sec, and then other usually around 500 ms. We already had logging in place that was measuring the time from BeginRequest() to EndRequest(), and the logs showed a consistent processing time for all of the image requests, even the two that were taking much longer to get back the browser.
Weird Latency in Request Handling and Session State
I just spent a couple of hours working with another developer on a weird request latency problem in certain ASP.NET requests. We've got an aspx page with a number of images that are themselves fetched via an aspx page (because they are being pulled out of the DB). When looking at the timeline for these requests in Chrome, most of them would complete quite quickly (less than 200 ms) but typically there were 2 that took much longer; one usually around 1 sec, and then other usually around 500 ms. We already had logging in place that was measuring the time from BeginRequest() to EndRequest(), and the logs showed a consistent processing time for all of the image requests, even the two that were taking much longer to get back the browser.
Confessions of a Static Typing Bigot
I've been a strong typing bigot most of my (programming) life. Pehaps not too suprising for a guy whose favourite saying is "Every thing has it's place, and every place has it's thing." But, like some self-righteous character on a bad TV show whose comeuppance is thoroughly telegraphed, late at night I would sneak off, open up my text editor, and do some JavaScript programming. Sure, I felt guilty, but it was fun, and it didn't seem quite so much like work. But its not like I was ready to abandon strong typing either. There truly were situations in which is seemed helpful not only to me, but to the developers I worked with as well.
Confessions of a Static Typing Bigot
I've been a strong typing bigot most of my (programming) life. Pehaps not too suprising for a guy whose favourite saying is "Every thing has it's place, and every place has it's thing." But, like some self-righteous character on a bad TV show whose comeuppance is thoroughly telegraphed, late at night I would sneak off, open up my text editor, and do some JavaScript programming. Sure, I felt guilty, but it was fun, and it didn't seem quite so much like work. But its not like I was ready to abandon strong typing either. There truly were situations in which is seemed helpful not only to me, but to the developers I worked with as well.
Confessions of a Static Typing Bigot
I've been a strong typing bigot most of my (programming) life. Pehaps not too suprising for a guy whose favourite saying is "Every thing has it's place, and every place has it's thing." But, like some self-righteous character on a bad TV show whose comeuppance is thoroughly telegraphed, late at night I would sneak off, open up my text editor, and do some JavaScript programming. Sure, I felt guilty, but it was fun, and it didn't seem quite so much like work. But its not like I was ready to abandon strong typing either. There truly were situations in which is seemed helpful not only to me, but to the developers I worked with as well.
A Rose by Any Other Name...
Actually, in coding names do matter. A few months back we moved our application from one hosting provider to another and everything worked except OpenID authentication. In fact, we had both applications running simultaneously and talking to the same OpenID provider, and one worked and the other didn't. We were actually getting an error message that indicated a packet had been rejected due to a problem with a "nonce". Here's a definition from Wikipedia: nonce is an arbitrary number used only once to sign a cryptographic communication. That pretty much matches my notion of what a nonce is as well.
A Rose by Any Other Name...
Actually, in coding names do matter. A few months back we moved our application from one hosting provider to another and everything worked except OpenID authentication. In fact, we had both applications running simultaneously and talking to the same OpenID provider, and one worked and the other didn't. We were actually getting an error message that indicated a packet had been rejected due to a problem with a "nonce". Here's a definition from Wikipedia: nonce is an arbitrary number used only once to sign a cryptographic communication. That pretty much matches my notion of what a nonce is as well.
A Rose by Any Other Name...
Actually, in coding names do matter. A few months back we moved our application from one hosting provider to another and everything worked except OpenID authentication. In fact, we had both applications running simultaneously and talking to the same OpenID provider, and one worked and the other didn't. We were actually getting an error message that indicated a packet had been rejected due to a problem with a "nonce". Here's a definition from Wikipedia: nonce is an arbitrary number used only once to sign a cryptographic communication. That pretty much matches my notion of what a nonce is as well.
Reusable Domain Controls in MS MVC
Most of the example code for MVC that I have seen out there isn't well-suited to creating re-usable UI components -- in particular components that are application specific, but may want to be used in multiple contexts within the applications. For example, a component that displays a list of customers might be used on a number of different pages within the application. But it is possible to build re-usable components of this sort, you just have to follow a few rules which help ensure that the component is not coupled to the page that it resides on. So, the rules are: View models should always include a field for the ID of the target element Always use RenderPartial() - Links need to be rendered with Ajax.ActionLink() Forms need to be rendered with Ajax.BeginForm() Forms/Links need ...
Reusable Domain Controls in MS MVC
Most of the example code for MVC that I have seen out there isn't well-suited to creating re-usable UI components -- in particular components that are application specific, but may want to be used in multiple contexts within the applications. For example, a component that displays a list of customers might be used on a number of different pages within the application. But it is possible to build re-usable components of this sort, you just have to follow a few rules which help ensure that the component is not coupled to the page that it resides on. So, the rules are: View models should always include a field for the ID of the target element Always use RenderPartial() - Links need to be rendered with Ajax.ActionLink() Forms need to be rendered with Ajax.BeginForm() Forms/Links need ...
Reusable Domain Controls in MS MVC
Most of the example code for MVC that I have seen out there isn't well-suited to creating re-usable UI components -- in particular components that are application specific, but may want to be used in multiple contexts within the applications. For example, a component that displays a list of customers might be used on a number of different pages within the application. But it is possible to build re-usable components of this sort, you just have to follow a few rules which help ensure that the component is not coupled to the page that it resides on. So, the rules are: View models should always include a field for the ID of the target element Always use RenderPartial() - Links need to be rendered with Ajax.ActionLink() Forms need to be rendered with Ajax.BeginForm() Forms/Links need ...
MVC 3 and DependencyResolver - The Ecstasy and the Agony
I started building my first MVC 3 the other day and came across the DependencyResolver mechanism for incorporating 3rd party inversion of control containers. How I rejoiced! I've been using Castle/Windsor for quite some time and have a nice set of capabilities built on top of its interceptor feature. So, I pull in my utility library, grab a Windsor-specific implementation of IDependencyResolver off the net, and start setting up my constructors for injection. I run my sample app, and it all hangs together. My controllers are being instantiated through Windsor and I'm happily making use of my utilities for tracing, logging, timing, etc.
MVC 3 and DependencyResolver - The Ecstasy and the Agony
I started building my first MVC 3 the other day and came across the DependencyResolver mechanism for incorporating 3rd party inversion of control containers. How I rejoiced! I've been using Castle/Windsor for quite some time and have a nice set of capabilities built on top of its interceptor feature. So, I pull in my utility library, grab a Windsor-specific implementation of IDependencyResolver off the net, and start setting up my constructors for injection. I run my sample app, and it all hangs together. My controllers are being instantiated through Windsor and I'm happily making use of my utilities for tracing, logging, timing, etc.
MVC 3 and DependencyResolver - The Ecstasy and the Agony
I started building my first MVC 3 the other day and came across the DependencyResolver mechanism for incorporating 3rd party inversion of control containers. How I rejoiced! I've been using Castle/Windsor for quite some time and have a nice set of capabilities built on top of its interceptor feature. So, I pull in my utility library, grab a Windsor-specific implementation of IDependencyResolver off the net, and start setting up my constructors for injection. I run my sample app, and it all hangs together. My controllers are being instantiated through Windsor and I'm happily making use of my utilities for tracing, logging, timing, etc.
Cook! Where's my dll?
I've been working on a little sample project in DevStudio to check out NuGet. Writing the code, using NuGet, and getting things to build all went fine. But when I went to run the code, it failed. Because I had set the project up as a Windows service, debugging was not entirely straightforward -- all I had were some stack traces in the event log. The service had died because of an an exception: Castle.MicroKernel.SubSystems.Conversion.ConverterException. The stack trace indicated that the exception was occurring during the process of getting logging initialized. After a bit more poking around I realized that there was a DLL missing from the bin folder of the project: Castle.Services.Logging.Log4netIntegration.dll.
Cook! Where's my dll?
I've been working on a little sample project in DevStudio to check out NuGet. Writing the code, using NuGet, and getting things to build all went fine. But when I went to run the code, it failed. Because I had set the project up as a Windows service, debugging was not entirely straightforward -- all I had were some stack traces in the event log. The service had died because of an an exception: Castle.MicroKernel.SubSystems.Conversion.ConverterException. The stack trace indicated that the exception was occurring during the process of getting logging initialized. After a bit more poking around I realized that there was a DLL missing from the bin folder of the project: Castle.Services.Logging.Log4netIntegration.dll.
Cook! Where's my dll?
I've been working on a little sample project in DevStudio to check out NuGet. Writing the code, using NuGet, and getting things to build all went fine. But when I went to run the code, it failed. Because I had set the project up as a Windows service, debugging was not entirely straightforward -- all I had were some stack traces in the event log. The service had died because of an an exception: Castle.MicroKernel.SubSystems.Conversion.ConverterException. The stack trace indicated that the exception was occurring during the process of getting logging initialized. After a bit more poking around I realized that there was a DLL missing from the bin folder of the project: Castle.Services.Logging.Log4netIntegration.dll.
Pools of ACID
There's been a lot of interest recently over alternatives to the tradition DB-based application, things like NoSQL and BASE. A lot of the dicsussions that I've heard about these systems seem to imply that these approaches are drop-in replacements for the older technology, which is not true. Both these, and various other alternative appoaches to working with persistent data, provide different semantics from a SQL DB coupled with transactions. In particular, transactions make it look like your working with a single-threaded system. In the context of a specific transaction, data isn't going to change underneath of you. Furthermore, you know that you won't be exposed to data which is in an inconsistent state, like a reference to a non-existent row in another table.
Pools of ACID
There's been a lot of interest recently over alternatives to the tradition DB-based application, things like NoSQL and BASE. A lot of the dicsussions that I've heard about these systems seem to imply that these approaches are drop-in replacements for the older technology, which is not true. Both these, and various other alternative appoaches to working with persistent data, provide different semantics from a SQL DB coupled with transactions. In particular, transactions make it look like your working with a single-threaded system. In the context of a specific transaction, data isn't going to change underneath of you. Furthermore, you know that you won't be exposed to data which is in an inconsistent state, like a reference to a non-existent row in another table.
Pools of ACID
There's been a lot of interest recently over alternatives to the tradition DB-based application, things like NoSQL and BASE. A lot of the dicsussions that I've heard about these systems seem to imply that these approaches are drop-in replacements for the older technology, which is not true. Both these, and various other alternative appoaches to working with persistent data, provide different semantics from a SQL DB coupled with transactions. In particular, transactions make it look like your working with a single-threaded system. In the context of a specific transaction, data isn't going to change underneath of you. Furthermore, you know that you won't be exposed to data which is in an inconsistent state, like a reference to a non-existent row in another table.
What's Really Hard?
In a CTO roundtable hosted by ACM Queue (http://queue.acm.org/detail.cfm?id=1551646) Lew Tucker said: "An important shift has been to use basic HTTP, in the form of REST (representational state transfer) APIs, as an easier-to-use SOA framework. Everything that made services hard before, such as CORBA, IDL, etc., went away when we said, “Let’s do it all over HTTP." What is really hard about "services" is not the infrastructure that you use to build them. Building distributed systems invovles challenges that are not faced when building monolithic applications: accounting explicitly for the effects of latency variations in latency and bandwidth that affect performance network partitions that makes some, but not all parts of the system, unavailable race conditions and attendant issues in consistency, like those which occur in mutlithreaded programming Any single one of ...
What's Really Hard?
In a CTO roundtable hosted by ACM Queue (http://queue.acm.org/detail.cfm?id=1551646) Lew Tucker said: "An important shift has been to use basic HTTP, in the form of REST (representational state transfer) APIs, as an easier-to-use SOA framework. Everything that made services hard before, such as CORBA, IDL, etc., went away when we said, “Let’s do it all over HTTP." What is really hard about "services" is not the infrastructure that you use to build them. Building distributed systems invovles challenges that are not faced when building monolithic applications: accounting explicitly for the effects of latency variations in latency and bandwidth that affect performance network partitions that makes some, but not all parts of the system, unavailable race conditions and attendant issues in consistency, like those which occur in mutlithreaded programming Any single one of ...
What's Really Hard?
In a CTO roundtable hosted by ACM Queue (http://queue.acm.org/detail.cfm?id=1551646) Lew Tucker said: "An important shift has been to use basic HTTP, in the form of REST (representational state transfer) APIs, as an easier-to-use SOA framework. Everything that made services hard before, such as CORBA, IDL, etc., went away when we said, “Let’s do it all over HTTP." What is really hard about "services" is not the infrastructure that you use to build them. Building distributed systems invovles challenges that are not faced when building monolithic applications: accounting explicitly for the effects of latency variations in latency and bandwidth that affect performance network partitions that makes some, but not all parts of the system, unavailable race conditions and attendant issues in consistency, like those which occur in mutlithreaded programming Any single one of ...
RESTful Lies (Part 2)
I've been continuing to make my way through a book on REST, and come across the following, in which the author is arguing that one of the advantages of REST is that it reduces the burden of API design: "... the advantage of the uniform interface of REST ... is that it frees us from having to create a new interface every time a new service is created." I think that the author is conflating the design of different levels of the system. This is perhaps not surprising because he points out elsewhere that while SOAP is designed to run over a variety of different trnasport protocols, REST is intimately associated with HTTP.
RESTful Lies (Part 2)
I've been continuing to make my way through a book on REST, and come across the following, in which the author is arguing that one of the advantages of REST is that it reduces the burden of API design: "... the advantage of the uniform interface of REST ... is that it frees us from having to create a new interface every time a new service is created." I think that the author is conflating the design of different levels of the system. This is perhaps not surprising because he points out elsewhere that while SOAP is designed to run over a variety of different trnasport protocols, REST is intimately associated with HTTP.
RESTful Lies (Part 2)
I've been continuing to make my way through a book on REST, and come across the following, in which the author is arguing that one of the advantages of REST is that it reduces the burden of API design: "... the advantage of the uniform interface of REST ... is that it frees us from having to create a new interface every time a new service is created." I think that the author is conflating the design of different levels of the system. This is perhaps not surprising because he points out elsewhere that while SOAP is designed to run over a variety of different trnasport protocols, REST is intimately associated with HTTP.
RESTful Lies
I'm reading a book about REST at the moment. I'm finding it quite interesting, but like so many issues in software development, there is a tendency to hyperbole. Take the following quote for example: This is because SOAP always uses POST, which can't be cached at any level. This is, almost obviously, false. This is nothing in any of the protocol specifications which prevent a SOAP client from caching the response to a SOAP request using an application specific protocol. So, SOAP can in fact be cached at the application level. Being charitable, I can suppose that the author did not intend to lie.
RESTful Lies
I'm reading a book about REST at the moment. I'm finding it quite interesting, but like so many issues in software development, there is a tendency to hyperbole. Take the following quote for example: This is because SOAP always uses POST, which can't be cached at any level. This is, almost obviously, false. This is nothing in any of the protocol specifications which prevent a SOAP client from caching the response to a SOAP request using an application specific protocol. So, SOAP can in fact be cached at the application level. Being charitable, I can suppose that the author did not intend to lie.
RESTful Lies
I'm reading a book about REST at the moment. I'm finding it quite interesting, but like so many issues in software development, there is a tendency to hyperbole. Take the following quote for example: This is because SOAP always uses POST, which can't be cached at any level. This is, almost obviously, false. This is nothing in any of the protocol specifications which prevent a SOAP client from caching the response to a SOAP request using an application specific protocol. So, SOAP can in fact be cached at the application level. Being charitable, I can suppose that the author did not intend to lie.
Caching Bites Me Again
I'm on a roll. Two weird caching problems in the space of a week. This one started off looking like a scary security bug. During testing, our QA department observed the following sequence of events: Log into the system as user U1. View page P1 Log out Log into the system as user U2. View page that re-directs to P1. At this point, they were indeed on page P1, but it was showing the data from user U1. My first suspicion was that somehow browser cookies were not being cleared and we somehow managing to pick up the sessions cookies from the initial login.
Caching Bites Me Again
I'm on a roll. Two weird caching problems in the space of a week. This one started off looking like a scary security bug. During testing, our QA department observed the following sequence of events: Log into the system as user U1. View page P1 Log out Log into the system as user U2. View page that re-directs to P1. At this point, they were indeed on page P1, but it was showing the data from user U1. My first suspicion was that somehow browser cookies were not being cleared and we somehow managing to pick up the sessions cookies from the initial login.
Caching Bites Me Again
I'm on a roll. Two weird caching problems in the space of a week. This one started off looking like a scary security bug. During testing, our QA department observed the following sequence of events: Log into the system as user U1. View page P1 Log out Log into the system as user U2. View page that re-directs to P1. At this point, they were indeed on page P1, but it was showing the data from user U1. My first suspicion was that somehow browser cookies were not being cleared and we somehow managing to pick up the sessions cookies from the initial login.
Doing Caching Badly
I had my first real encounter with ASP.NET caching the other day and it was not a happy one. We're doing QA on a new release of one of our applications and one of the bugs was turning out to be difficult to reproduce. The bug was caused by quickly clicking twice on an ASP.NET control. In some cases, this would result in a null object exception. The null object in question was a user control (.ascx file) also included on the page. During debugging we observed that the control was fine on the first request, but was sometimes null on the second request.
Doing Caching Badly
I had my first real encounter with ASP.NET caching the other day and it was not a happy one. We're doing QA on a new release of one of our applications and one of the bugs was turning out to be difficult to reproduce. The bug was caused by quickly clicking twice on an ASP.NET control. In some cases, this would result in a null object exception. The null object in question was a user control (.ascx file) also included on the page. During debugging we observed that the control was fine on the first request, but was sometimes null on the second request.
Doing Caching Badly
I had my first real encounter with ASP.NET caching the other day and it was not a happy one. We're doing QA on a new release of one of our applications and one of the bugs was turning out to be difficult to reproduce. The bug was caused by quickly clicking twice on an ASP.NET control. In some cases, this would result in a null object exception. The null object in question was a user control (.ascx file) also included on the page. During debugging we observed that the control was fine on the first request, but was sometimes null on the second request.
Clarity in Software
I've been wondering about what makes good code recently, or to phrase it another way, what are the basic principles that you can follow that will generally keep you pointed in the right direction. I've come up with two that really stand out for me: correctness and clarity. The former is obvious, but can be turned around into something more useful -- that is, you can't code something until you've defined what it means for it to be correct. So there is a need for well-specified requirements and even perhaps a motivation for techniques such a test-driven development (TDD). I can't say that I've gotten to the point of doign TDD myself, but I can't imagine working on a project without a solid set of unit tests and the continuous integration tools to ensure that they are run whenever the code changes.
Clarity in Software
I've been wondering about what makes good code recently, or to phrase it another way, what are the basic principles that you can follow that will generally keep you pointed in the right direction. I've come up with two that really stand out for me: correctness and clarity. The former is obvious, but can be turned around into something more useful -- that is, you can't code something until you've defined what it means for it to be correct. So there is a need for well-specified requirements and even perhaps a motivation for techniques such a test-driven development (TDD). I can't say that I've gotten to the point of doign TDD myself, but I can't imagine working on a project without a solid set of unit tests and the continuous integration tools to ensure that they are run whenever the code changes.
Clarity in Software
I've been wondering about what makes good code recently, or to phrase it another way, what are the basic principles that you can follow that will generally keep you pointed in the right direction. I've come up with two that really stand out for me: correctness and clarity. The former is obvious, but can be turned around into something more useful -- that is, you can't code something until you've defined what it means for it to be correct. So there is a need for well-specified requirements and even perhaps a motivation for techniques such a test-driven development (TDD). I can't say that I've gotten to the point of doign TDD myself, but I can't imagine working on a project without a solid set of unit tests and the continuous integration tools to ensure that they are run whenever the code changes.
Addicted to Interfaces
I've read a lot recently about the advantages that people perceive in using dynamic languages. I understand some of the enthusiasm -- in fact, JavaScript is my language of choice for building little utilities both at work and home. But the idea of actually using a dynamic language for a major project at work gives me the willies. Since many people are using dyanmic languages for significant projects, I started wondering whether this was an unjustified predjudice on my part. I needed to get beyond simple fear and figure out what it was that really made a difference to me. In the end, there was one feature of strongly typed languages that stood out for me -- and is significant enough that I am still inclined to avoid using dynamic languages in large projects.
Addicted to Interfaces
I've read a lot recently about the advantages that people perceive in using dynamic languages. I understand some of the enthusiasm -- in fact, JavaScript is my language of choice for building little utilities both at work and home. But the idea of actually using a dynamic language for a major project at work gives me the willies. Since many people are using dyanmic languages for significant projects, I started wondering whether this was an unjustified predjudice on my part. I needed to get beyond simple fear and figure out what it was that really made a difference to me. In the end, there was one feature of strongly typed languages that stood out for me -- and is significant enough that I am still inclined to avoid using dynamic languages in large projects.
ORM's and Lock (Part 2)
Back in January I wrote about some of my initial experiences with ORM's and deadlocks. By explicitly marking each transaction as being either read or write we were able to solve a large number of deadlocks that cropped up in our initial testing. In fact, that tactic was good enough to take the system live. Even with people accessing the system on a regular basis we did not see any deadlocks. This lulled me into a false sense of security that I wouldn't have to think about deadlocks any more. In hindsight I can't imagine why I thought this -- self-delusion rears its ugly head again.
ORM's and Locking (Part 2)
Back in January I wrote about some of my initial experiences with ORM's and deadlocks. By explicitly marking each transaction as being either read or write we were able to solve a large number of deadlocks that cropped up in our initial testing. In fact, that tactic was good enough to take the system live. Even with people accessing the system on a regular basis we did not see any deadlocks. This lulled me into a false sense of security that I wouldn't have to think about deadlocks any more. In hindsight I can't imagine why I thought this -- self-delusion rears its ugly head again.
ORM's and Locking
An interesting deadlock situation came up in our application recently. We use NHibernate for our ORM and our database is SQL Server. Within the application we've constructed some utility classes for NHibernate so that there is a standard pattern for finding, accessing, and modifying persisten objects. A key part of this is our UnitOfWork class that wraps up an NHibernate session and transaction. All access to persistent objects occurs in the context of a UnitOfWork. When a UnitOfWork is completed it either commits its changes back to the DB or they are aborted. Initially, the typical pattern for carrying out some changes to a persistent object (or set of objects) looked like: using (new UnitOfWork()) { Person p = PersonFactory.FindById(personId); p.Salary += 10; } By default, the UnitOfWork commits at the end, so that the change to the Salary property would end up being ...
Flash 10 Broke My Software
We recently ran into a bug in which our Flash application failed when running on Flash 10, but worked fine on Flash 9. The failure turned out to be a security exception that was thrown when we tried to open a file browser. At first the problem seemed to be non-deterministic. There was one routine where we were opening up the file browser -- to upload a file to our server, and sometimes we would get the exception and sometimes not. It turned out the problem was not non-deterministic. Whether we got the exception depended on the precise code path by which we arrived at the point where we tried to open the file browser.
Trying to be Agile
Sometimes when I describe the development processes that I like, people will say "It sounds like you've adopted agile." This makes me cringe and I usually try to go to some lengths to say that I am most definitely not using agile processes. But the truth is there are many things about agile that I like and find useful: continuous integration, short feature-centered development cycles, maintaining an up to date set of feature requests, a focus on unit testing, etc. But I just can't come to terms with the label agile. As I was reading an article on agile development practices the other day, I realized why this was.
Understanding Types
There's no better way to start a flame war (well at least among the geek crowd) than to boldy assert than untyped languages are unusable for any real software development, or on the flip side to assert that typed languages simply place useless barriers in the way of good programmers. But most of us simply take type systems (or the lack thereof) for granted, and types are often looked at in curious ways. For example, I've met C++ programmers who look at templates not so much as a typing mechanism, but as a clever way to get the compiler to generate the code they want with a minimum of actual C++ written.
Read the entire post on Rambling on Software
Physician Heal Thyself
Two days of debugging hell have brought home the point once again of the importance of knowing the fundamentals. We've recently been working on a project that involved a number of different components: a SQL database, SharePoint, and an ASP.NET application. There are several points of contact between these components, and the particular one that was causing grief in this case was a web service call from the ASP.NET application into SharePoint's native web service API. The system had been working on our development boxes, but when we uploaded it to our hosting provider we got errors on the web service calls into SharePoint.
Service Contracts and Global Constaints
We ran into an interesting problem with one of our web service interfaces at work today. We had recently added code to enforce some business logic constraints, and this was causing some requests to fail that, from the perspective of the UI, should have been legal. The problem was a mismatch between the granularity of our service contract and the granularity of the constraints. The constraints that we had added were ones that applied to collections of objects. An example of this type of constraint is that a collection of nodes in a graph cannot have any cycles. The interesting thing about this sort of constraint is that you cannot determine if the constraint is being violated by looking at a single node.
Microsoft Volta
I read through a lot of Microsoft's material on Volta the other day. I sense the turning of the karmic wheel of software development. They note on their blog that Volta "enables developers to postpone architectural decisions about distribution." Well, having spent 3 or 4 years deeply involved with building infrastructures on top of CORBA, I can safely assert that this is exactly one of the goals that we had in building those infrastructures, and I think it is safe to say that it was one of the primary goals behind CORBA itself. In fact, the whole point of location transparency was just that: to completely isolate code from decisions about where objects actually reside.