Not so long time ago I released an application on my mobile broadband blog called Mobile Broadband Logging Monitor. It’s purpose is to help non-techincal users diagnose and discover if they’re affected by the heavy logging problems, that some of the big mobile broadband connections softwares suffer from.

The following story is about the creation of this piece of relatively simple software, and I’d like to share some of the thought I’ve had while making it.

First, a small question. What’s the difference between the applications shown in the pictures below?

 

Ok, I was cheating for theatrical effect. The pictures are the same. Read more, and you’ll know why I asked.

The story of the software begins with the issues about mobile broadband connection clients logging way too much information. I had made plenty of blog postings on what the issues were and how to solve them, but I wanted to make a diagnostic tool for everyone to use so that they could see if they were affected or not.

So, having thought for a while creating this software for a while and while feeling inspired, I sat down and started coding. I had no formal specification for the software, as I usually have on my job, but of course, I had some goals. The software had to be able to diagnose several different types of mobile broadband software, in various versions, and display their file activity to the user. It furthermore had to display some simple statistical information, the activity pr. minute and forecasted activity pr. hour and work day.

I didn’t take long before have the famous “working protype”. Yes, I could start the app, and it would be able to diagnose HUAWEI Mobile Partner and two versions of Birdstep Techonolgy’s EasyConnect. Golden!

Now, from a feature perspective I was done. The first version of the application had these features:

* Start button – starts the monitoring of the mobile software.
* Stop button – stops the monitoring.
* If the software in question has a fix described in the blog, show a link to that blog post.
* If it is the first time the user start the aplication, show a thank-you-for-downloading web page.
* If user clicks links to blog or feedback page, show the pages accordingly.

I put the software online and people started downloading.

But from other perspectives than the (admittingly vague) requirements, I wasn’t done at all. I had created an application below the norm in many ways if this had this been in a professional context (in my opinion). The application had one window and all the logic of the application was contained in the code behind of that window. This meant lack of testibility (well, there was no testibility at all!). Also, I had ideas for adding more features and even exposing the core application logic (finding and monitoring the software) as an API for others to use.

I decided to take on refactoring the application big time, without adding any new features to the application. The goals for the application were:

* Make most of the application logic covered by non-integration unit tests.
* Following the above, to have the part of the application which interacts with the “runtime” and/or external systems made as “thin” as possible, making it very easy to code these interactions and also ensure that they behave correctly in unit tests.
* Compose the application with components, that have clear purposes and one concern pr. component only.
* To open up for injectibility and IOC, hopefully to make use of Castle Windsor or the like in the future.
* Open up for making the application Open Source and thus expose the inner workings of the application (people might be hesitant to download arbitrary software from blogs, I know I would)

The goals for me personally was:

* To make it “right”. No bullshit.
* To make use of the many inputs I’ve had over the years, once and for all, making the software a sort of mini experiment of how it could be done in a professional situation.
* To be able to add new features in a structured way instead of the trial-and-error way that the software invited to in its current implementation.
* Not necessarily use the last tools or frameworks, but at least use sensible implemenation patterns what would make structured change easy.

Oh yes, big goals in small scale! :o)

The following are the stages of refactoring I went through with the application. If you don’t want the bloody details, I suggest you skip the description of these stages, and go directly to the “You had a question, Mr. Ostengaard?” section.

Stage 0
This was the working prototype that I started out with. I uploaded the software to Microsoft’s Codeplex. You can browse the code here.

Stage 1
In this stage I seperated a lot of the applications logic into components (ie. objects) with well defined purposes. The application only had one really structured part so far, which was about what mobile software the application supported. I could add new types of software pretty easy, even in the first edition. The rest of the application, however, was all code behind spaghetti voodoo. I started to identify the concerns of the code. You know, identifying these things in retrospect is not an easy task. I took a lot of time, and you start to see how entangled things really are when you code like this: Functionality for seaching for the software, starting / ending monitoring, UI state management, reading from configuration, handling events from directory watcher, collecting simple statistics and cross-thread UI updates. There’s was a little of everything, not much, but enough to make the identification of concerns pretty fun ;o)

I ended up creating some components and introduced interfaces for each of these, and every component got their dependencies injected (I chose the constructor strategy). You can browse the code of this stage here.

Stage 2
At this stage, efter going through the refactoring of business logic, I turned my focus on the UI. I had most of the business logic of the application seperated from the UI logic now. Not all, but almost. There was still some things, such as reading from the configuration, opening web pages and such in the UI code behind. But I was really really thirsty for more. I wanted to have the UI logic testible through unit tests in a non-integrated way too. I wanted full control over everything that the application did, at least as far as possible.

Now, when I had my own company I was involved in developing a Windows Forms application. At that time, I used a simple MVC framework to create views and sub-views and their corresponding controllers. The implementation had its forces and its drawbacks. But since then, I hadn’t done anything so structured in Windows Forms, and therefore I had some inherit mistrust for the strategy of that tiem. No need to not learn from the past, right? ;o) So, after having poked around for a while and tested some strategies, and honestly being a bit confused about which strategy to use, I ended up with the MVP pattern. Many thanks to input from Steve Bohlen on that, you have a beer waiting in Copenhagen.

But here’s an interesting thing: When you have the ambition to cover as much logic as possible in non-integrated unit tests, transforming traditional UI logic into testible code is quite an eye opener. You have to ask yourself what a dependency really is? In the case of UI logic, it’s can be the many things that you usually just take for granted in a quick-and-dirty Windows Forms application: Reading configuration files, displaying MessageBox (and child windows) and in this case also opening web pages. These simple things now became obstacles for my unit testing goals and something had to be done about them. I therefore made components to handle these things, disregarding the sense of overkill at the time. This would, hoverever, when creating unit tests, turn out to be a very good idea: Everything was injectible, everything was mockable.

You can browse the code of this stage here.

On a side note, the same is true for UI logic in .Net web applications. Traditional code behind is not very testible, so if you want to have that control over your software, similar strategies has to be taken into use.

Stage 3
At this point there were still some things in the business logic that were not covered by unit tests, especially the parts handling statistics. And to make that testable I had to control the applications sense of time. Just as writing “new SomeComponent();” is avoided in the name of injectibility and testibility, so is writing “DateTime.Now;”. If you use DateTime.Now in your code you have code that is less testable because your code is dependant on a very fluent component, namely the system time of the computer. How would you for example test a time-based statistics component when you cannot control time? It is possible in some ways, but if you want solid results and the test to run in short time, you’ll have a challange. Would you choose to have your unit tests run in real-time? That’s way too counter productive – these non-integration unit test has to be blazingly fast and give quick feedback to the developer - and because of this, time has to be encapsulated as well and made injectible. The IDateTimeContainer was introduced which contains the method GetNow() returning nothing more but DateTime.Now.

In this stage a new project was included in the solution. Until now the business logic had been contained in the same project as the UI, but with 100% seperation. Now I moved the logic into its own project (API), to ensure this seperation fully and also to make the core logic available without any relation to the UI.

You can browse the code of this stage here.

Final product
After going through all these stages I still had an application with no new features. But it was much better structured and had the qualities that I wanted: thoroughly tested through unit tests, and open for structured and controlled change. 

New versions
After this rearrangement of code I have relesed a new edition of the software. Change was adding a new child window to the mani window. The child window and its related presenter, and even the changes in the presenter for the main window, was added with ease. It was really a joy doing that in a controlled invironment.

You had a question, Mr. Ostengaard?
Now, the headline of this blog post asked “What’s the lesson of this story?" I ask because I actually want your input on what part of this whole story you think is the actual success story. I can think of some viewpoints, maybe you can think of others.

* One viewpoint could be that creating a “working prototype”, like I basically did here, is fair enough, as long as you have enough dicipline to throw the original code away or a least invest a proper amount of time restructuring it before adding new features. 

* Another viewpoint could be that things has to be thoroughly analyzed and components identified (whatever that means) before going into development. That would mean getting many of the benefits from unit tests and structured change from the early beginning. But it also means that the customer has to pay more up front and wait longer before gettign return on investment. (I’m not going to go into numbers here.)

* A third viewpoint could be not to focus so much on unit testing and other forms of control and feedback at all, and just fulfill the requirements and have testers assert that the requirements have been fulfilled. When the application get past these tests, the release is considered a success.

I ask the question above and put forward these three examples of viewpoints, because I am surrounded with people who carries (roughly) one of these three viewpoints and discussions often about this often occur. Some will say that the early release is the way for success (early business value), others will say the pre-study and analysis must be done, and others simply don’t have a clue about structured and quality-oriented application production (or simply don’t have it as a business goal).

The first viewpoint is good for early business value, I agree, but the problem with this strategy is that the application is born with a quite large techincal debt. But I have never heard about a customer (or software consultant house for that matter), who would pay for 4-10 times as much time as it took to create the original version to (re-)make it into a structured application and this without gaining basically any new features for that money. Have you? And if that doesn’t happen, all you have done is lured yourself and taken the first step in following the third viewpoint, where technical debt is not considered bad. But to me, the third strategy can never be the way to go. It will end up in a system, that carries so many problems, that change in the end will be seen as evil. Change will be avoided. It’s on a death march...

I hope that you can see, that I am, in most cases, a proponent of the second viewpoint. I can live with the first viewpoint, if actions are taken to rearrange the software. Unfortunately I do believe that many people start out by going with the first strategy, then skipping/postponing the restructuring, only to later find themselves trapped far into to third strategy with almost no possibility of returning.

And if you still wonder about the pictures, the difference between the two applications lies in the quality of the implementation and openness to change in the future. One sucks, one doesn’t.

Tell me something from your part of the world… :-)

Here's my groups (Björn, Patrik and me) source code from the Behaviour Driven Design session. It might not mean a lot for people who didn't attend, but we figured we'd put it out anyways.

Download here: BDDWorkshop.zip (14,62 kb)

It has been a long time since I’ve been so much in the nerdy mood as today. I’ve been coding Microsoft Word (read: writing documentation) for almost 3 months now, so when I got a hint about the alt.net Öresund event today I knew that I had to attend and defy any of my normal Sunday traditions. No sleepy Sunday. No long brunch with Lydia. No café latte on some easy going café. Instead, it was all about getting dirty with code, brewed coffee and and Coca Cola. The meetup style was relaxed and open, and we got through, among other things, Behaviour Driven Design / Unit testing (with pair programming), the Command / Query pattern and SharpArchitecture. The event had sponsored lunch (thank you Microsoft Sweden!) and after-nerding beer (thank you Know It!).

Here are a few pictures from the event:

I like Scrum. I like small releases. I like iterative processes. I like breaking things down into smaller things, that in the end are quite easy to estimate. I like the fact the planning poker pushes us to talk about assumptions and therefore makes us design before we code, instead of design while we code. I've worked in agile processes before Scrum became famous (to me ;-)), just because it felt good in my belly, and that's often all I need to be able to do my work well.

But, there are some things about Scrum that sometimes makes me feel eerie:

First, Scrum is too much a buzzword
Scrum is sometimes more a buzzword than something that is practically used. That's indicated to me when I talk to software developers I know here and there. "We sold the projects as Scrum [because it's the buzz], we call it Scrum [because it's the buzz], but it's really not... [sad look in eye, because Scrum is the buzz]". The project team might struggle to keep Scrum in their project, but because it's not implemented correctly (due to lack of real commitment from management / customer), they end up with a lesser process. In the end the product will suffer.

Second, Pro-Scrum people seems to think that Scrum is the only process in which you can conduct quality software development
I've talked with pro-Scrum people who tried to explain the advantages of Scrum to me. Sort of preaching to the choir, I'd say. However, when I explained about the project setup I was once working in, and that the customer didn't have the agility in their organization and a technical setup that could support the Scrum process, they adviced me to try to sell it in anyways. Ok ok, fair enough and a good idea, I thought. A couple of weeks later, they went on about it again, and I tried to explain again, that the customer couldn't and didn't have it in his priorities to change into Scrum-projects. But it didn't really sink in to these pro-Scrum people - I could see, that they really didn't buy in (or listen) to my arguments. I just got "But it's the best, you've got to! You've got to!", followed by that crazy/orgasmic look in their eyes, that gives me the chills rather than the hots. To me, a process shouldn't become a religion and blur your mind from choosing a process, that really fits the setup. Bop bop... 

Third, no one's realizing that Scrum is often not applicable
Let's say that both management and customers want to commit to Scrum. To have a "true" Scrum project there are some prerequisites, that needs to be fulfilled. First, you need to have a Scrum master and a team that knows and can see the advantages in doing Scrum. Everyone in the producing team must sign up for it, and it's not enough to have the titles in place(!). No, it's not. But even if the project team do recognize the benefits, realize that you just don't have a Scrum project, if the customer doesn't want og cannot sign up for Scrum. Or maybe they can, but don't have the capacity in their organization to support the Scrum Customer-role and to keep up with the short cycles and many releases that Scrum introduces. It's a fair insight. If so, it's not really Scrum. Don't think that you can survive by letting your project manager fake the customer role and do "pseudo-Scrum", while the real customer continues to take showers in the "waterfall" process. It will lead to a shaky incompatible process or maybe no process at all.

Forth, people do pseudo-Scrum anyways
Please, don't.

Let me hear your comments ... :-)

Although my 5 week vacation in Spain was primarily about studying Spanish, I did have some extra time to read some books on other subjects. Some were fictional, such as the intense Manhattan is my beat by Jeffery Deaver, the funny Gold by Dan Rhodes and the more philosophical Baade-Og Mandag. Others were non-fictional, such as Great Service: A Framework for Action by Leonard L. Berry and Moments of Truth by Jan Carlzon.

It is the last two books in this line up that is the driving force behind this posting, because they contain so many interesting messages that are very close to my heart. They are all about customer service. They are about how to create it, how to think it and how to ... well, live it - as a company and as an employee in such a company.

Customer service found a place in my heart when I got a job at a Shell gas station in 1995. I went through internal training on customer service (I still have the material that was handed to us) and was put in a position where the gas station was my responsibility during my evening shifts. Many of my young colleagues considered the owner of the gas station quite strict (and yes, he was a little paranoid, but wouldn't anyone be that, if you have had experience with previous employees stealing from your shop?). However, that aside, he also had many positive opinions on how we looked (with regards to the uniforms) and how we conducted service to our customers. This experience did, in retrospect, open my eyes on customer service, and I must say  I found it quite fun to help an old lady replace a front light on her car, even though such service wasn't in my job description.

Lately, focus on customer service has taken a nudge up for me. I think it is an reaction to several things, but mostly, I think, because I don't quite agree to the way things typically are carried out in the software development and consulting industry. Management of IT businesses tends to have a very strong focus on short term profit, to the point where it sometimes hinders the employees in doing things the right way. What the "right way" is, however, is also a subject for discussion.

Producing the "right way"
In the software industry we have processes, roles and frameworks for basically every dimension of software development, maintenance and management. We have project management, software development processes and patterns, test processes, delivery processes, processes for handling change and more. We have roles such as project manager, architect, developer, tester and sales people. We have requirement documents, solution description documents and systems to handle bug reports. We don't even have to rely on guessing, analyzing or ask the customers what they want - we create a Service Level Agreement that contains the details on when, where and what kind of service, the customer can expect from the supplier during a defined period. With all these elements why do I then believe that something is missing in the picture?

The thing is that all of the above exists to ensure that the software is developed in time and with right quality, and gives everyone involved in the production a structured way to produce it. But sometimes, to me, it feels like the processes chosen and roles used aren't quite made to handle the different needs that customers may have. Some customers may have to react to changing markets or be involved in political questions, which forces them behave in ways that might not be compatible with existing processes in the software industry. And when this happens, interesting things tend to surface. Here are a couple of examples:

• When a need rises from the customer to have employees from the supplier to stand by during night time (for what ever reason), the reaction can be "We cannot (or need not) do that, because it's not in the Service Level Agreement".
• When a customer needs to introduce some changes and it happens during the "wrong" period of the development process, developers, project managers and the like will often tend to work against such a change, because it's "not the way to do it" (what "the way" means depends where in the process the request for change occurs).

I too believe that there's a right way to create software for a customer. But it's not by rigidly clinging to processes that are not compatible with the customers needs, and getting all annoyed and irritated when the customer is not behaving in a way that supports the process. To me, this is where customer service and mindedness could come in and save the day in more than one way...

The focus on short term profits
During the years I have seen plenty of good ideas go nowhere, often because of managements intense focus on getting the most out of all employees, that is, making them have as many billable hours as possible. Some of the ideas could have resulted in for example rise in speed of development or quality of the products to benefit the customer and gain competitive advantage for the company in general. However, because these ideas demanded research and / or investment (that is, no billable hours), they were put on hold or prioritized so low, nothing ever happened. I have seen the same thing happen to knowledge sharing meetings and other non billable activities.

Of course the numbers need to stay black. But, to put it very simple, you have to give a little to get a little. That is a universal fact. But I think there's more to it that just blaming management of having focus on short-term gains. I cannot recollect ever having heard of any IT company, where middle management and its employees were measured on anything else than short-term numbers. And as long as this is the case, initiatives for better performance, quality, customer satisfaction and loyalty will suffer in one degree or another.

Change
Changing the view from production orientation (that is, the chosen processes, roles and frameworks) and short-term profits to customer orientation (what do the customers want and how do excel in giving it do them?), and implementing this kind of thinking company wide (which is crucial, no matter if everyone has direct customer contact or not), can have a lot of benefits:

• Instead of letting processes, roles and frameworks dominate, the company should think customer needs first and tailor the processes to it. Because focus is now on customer satisfaction instead of violation of rules and procedures, there's really no "wrong" customer behavior contradicting process. Sure, there will be conflicting interests, but how to solve them should be apparent: whatever it takes to keep the customer happy!
• The customer first approach also enables front line servers (project managers, test managers, sales force) to serve the customer even more. If the customer needs change or something else that might have been in contradiction with earlier applied processes, then everyone must now accept the need as customer satisfaction is now the main focus.
• Putting customer service first will enable the employees to have a genuine interest in the customers and their needs, and make it possible for them to proactively handle any concerns the customers may have. Strong customer loyalty will rise from this.
• Focus in top management must change to include customer satisfaction and loyalty as success factors. This will open up for middle management to invest in initiatives with long-term goals such as long-term profit, customer loyalty and competitive advantage.

To summarize, I think there is a degree of unhealthy focus on production orientation and margins in the IT consulting industry and not enough on customer service orientation. While processes, roles and frameworks are crucial for making good and reliable software, they should not dominate over customer service and satisfaction - the customers are vital for the existence for an IT company.

What do you think? Does customer service orientation have a place in IT companies? Or does it simply conflict so much with the "right way" to create software, that customer service orientation in an IT company close to impossible?

Christer

When hosting a server application on several tiers, with several servers representing each tier, being up to date on the content of event logs can be quite a task. And when errors occur, you're forced to look through all error logs to track the path of the errors, which can be a very time consuming. The task of trying to figure out what happened and why can is also a frustrating task, because you have to put a picture together while gathering infomation by browsing through servers.

That is, unless you're using something like GFI Events Manager. You place it on your servers, and it transfers all their log information to a central database, where you can browse and query the data. It makes it easy for developers to see information, that would normally only be available for the hosting department.

Check it out here: http://www.gfi.com/eventsmanager/

Have you ever had that feeling that your office environment is somehow working against you instead of for you? Where people perhaps are devided by physical barriers such as many small offices, making it a tedious task to get an answer for a question or a signature for a document?

Or maybe you have had that feeling that some departments or teams in your company are just working supersmooth while others never seem to be able to reach the same level of progress - and you find it hard to figure out what exactly the problem is and how to express it?

Maybe you have also experienced that tasks have a tendency to be appointed to the same busy and maybe even stressed co-workers over and over, even though co-workers with less to do might seem like a better choice?

I first heard about Lean some years ago, however, I never got to sit down and learn about it until now. Physical office environment, takt and pitch, work balancing and kaizen are just some of the many Lean subjects and terms explained in "Value Stream Management for the Lean Office" by Tapping and Shuker, a hands-on book about using Toyota's Lean methodology in the office environment. It is 171 pages, fairly paced, written in an easy language, and covers the basics of Lean in an office context.

Although benchmarking, working in well-defined roles and processes in the value stream might have a negative sound to it, I would not hesitate to recommend to experiment with optimization through Lean Value Stream Management. It seems to me that many people in "creative" jobs have a tendency to see workflow analysis and the introduction of best practices as a threat to the way they work.

But working structured is by no means incompatible with working creatively. The prime motivator for Lean optimization is identification and elimination of waste. It's a big opportunity to eliminate tediuos and maybe even unnecessary tasks and ineffective processes that take up time that could be spent being creative. Tapping and Shuker introduces the Seven Deadly Wastes and their toxic effects. From my own experience, I totally agree to the effects, and that they can have a very negative effect on a company. Too much of it, and you'll end up with an underperforming company with customers taking their business elsewhere and / or employees leaving the company. So just get started! :-)

I think that Lean thinking could be a natural extension to existing project models and software development methologies. I searched the Internet and even found a white paper dicussing it in the context of software development.

Note: If you're using Microsoft Office Visio 2007 you'll find that is supports Lean State Map diagrams.

During the Banedanmark HTS project, the new announcement system described in my previous post, we experienced a relatively large overhead when the Window Forms .net client called our web services.

After searching the Internet I found this posting on via google groups, Web service calls seem too slow, in which the original poster (OP) experiences the same kind of overhead. In his last posting, the OP elaborates on the difference in overhead between anonymous web service calls and NTLM authenticated web service calls, and concludes that Windows Integrated authentication is the bottleneck.

The solution, as described in the last posting, is that you can set HttpWebClientProtocol.UnsafeAuthenticatedConnectionSharing to true. You will gain performance and still have NTLM authentication, however, beceause of the reuse of server connections, you might expose security holes. So check out the links in the last posting and get familiar with the downsides before you start using it.

Cheers.

I was talking to Jesper a couple of days ago, and he suggested that I should write a little background information for some of the Internet resources in my previous post. Even though I consider the resources quite useful as they are, I agree that a little context information would be good for better understanding the value of the link and also for discussional purposes. So please, if you have any input, throw me a comment, ok? :)

In this posting I will elaborate a little on the SOA: The Subscriber-Publisher Model, Introduction and Implementation resource.

First a little background info on the HTS solution, the new announcement system at Banedanmark (who owns the Danish railway infrastructure).

The HTS solution consists of 3 tiers*: the HTS smart client tier (Windows Forms .Net, this is the end user interface), the HTS (high level business logic of the HTS system exposed in an asp.net web service), the HTS Core server (low level logic, that delivers the announcement to the speaker hardware, contained in a windows service, exposed in an asp.net web service via remoting).

Now, the end users works in the HTS smart client in so called workspaces. Each workspace contains a pre defined amount of announcement resources that the user can create new announcements to. The workspace also contains two lists, one for showing scheduled announcements the next 24 hours on the resources, and a list showing processed announcements 25 hours back in time.

Now, as users can work in the same workspace on seperate computers at the same time, and because the HTS server and Core server continuously processes the scheduled announcements, the lists in the workspaces must to be updated to show the state of the system correctly. There are basically two ways to do this, pull or push. Pulling in this context means that the HTS client initiates the update of the lists at certain time intervals and polls for content from the HTS server. Push in this context would be an update of the lists initiated by the HTS server. 

Pull is easier to implement compared to push in this context, and pull was the chosen strategy for the HTS solution. However, ease does not come without a price. There's no doubt that the pull strategy is by no means as scalable as the push strategy. The pull strategy generates a lot of traffic and load to the server, even though no change may have happened on the server and the server therefore has nothing new to show to the user. However, the amount of users was known at design time, and therefore we could calculate on the server load.

However, in a different scenario with a lot more users (or workspaces), a push strategy should be considered. The server could serve many more users and still easily compete with the pull strategy in terms of traffic and load, since there's no or little communication between clients and server when there's no change to show. Only when a change happens are the subscribing clients (or maybe even just a subset of them, depending on how complex your implementation is) notified with new data.

Now, there's many differenct ways of implementing the push strategy, and the link above is one way to do it (however, the solution described was not used for Banedanmark HTS). I have also seen articles and discussions on how to do it with either .Net remoting and MSMQ. In a discussion about a .Net remoting implemention, someone cautioned of two things: Alleged instability of .Net remoting (that is, there's a relatively large chance that the message never reaches the client) and that the notification is synchronous (which can mean that a stalling client can kill the notification round or at least cause a serious delay). On the other hand MSMQ can be used to make an asynchronous notification, where the server puts the message into a MSMQ queue on the client. The client then polls the local MSMQ queue for changes. This is good because the server can deliver to one client and directly continue to the next, no matter if the first client was ready or even responsive. However, when doing this with MSMQ, remember a good rule of thumb: Deliver remote, poll local.

Anyways, even though the above just scratches the surface of how to implement push, it should be clear that push is a little more complex and demands more effort than pull. The advantages should be clear, though...

(As a side note for anyone at Banedanmark, who might be reading this: The communication part in the HTS client is properly wrapped, and is internaly based on events. So, the transition from pull to push, from HTS client perspective, should be a minor change, should you consider changing it. Impact on the HTS server however depends on the chosen technology.)

That's it for now. I hope this background info on the link gave a little insight. Please do leave a comment on subject, content or form... :)

Christer

A lot of coffee was consumed during Banedanmark HTS :)

 

* I'm leaving out the speaker hardware tier and data persistance tier here for simplicity.

As in any project, we ran into development issues while working the new announcement system for Banedanmark (Danish Rails). While I was searching the Net for input or answers on these issues, I thought it might be a good idea to gather all the resources I would find and share them when the project was done.

The list of links below are some of the resources used, an unsorted list of links ranging from direct access to structured FAQs to deep links directly into usenet conversations on several different subjects. However unstructured the list below may be (and it is, I know ;)), I hope to make it just a little bit easier for someone out there, having similar issues, to find some answers. 

Enjoy!

Java/.NET Interoperability with the Microsoft.com Web Service

SOA: The Subscriber-Publisher Model, Introduction and Implementation

exCentrics .net resources world

Google groups: ContextMenuStrip in DataGridView

Google groups: Mnemonic and Accelerator Issue

Accelerator keys broken in Winforms

Event Accessors

Chilkat Software

Mick Dohertys DotNet Tips - TabControl

Google groups: DataGridRowView.ContextMenuStrip

Google groups: Index -1 does not have a value - DataGridView

Google groups: Coding an application to be single instance?

Google groups: Scrollbar events

Icon experience

.NET WinForms Lesson: Where is my "Scroll" event? (now a broken link, sorry)


An Office 2003-like popup notifier

Google groups: Multiple Monitor Troubles

FAQ for click once

Iconits

Registry edits for Windows XP "Tweaks and tips"

Using ApplicationDeployment to manually update ClickOnce applications

Visual Studio Content Installer Schema Reference 

Practical Multithreading for Client Apps

WinForms UI Thread Invokes: An In-Depth Review of Invoke/BeginInvoke/InvokeRequred

How to Move Shell Folders (and contents)

What's up with BeginInvoke?

How to access serial and parallel ports by using Visual Basic .NET

I/O Ports Uncensored - 1 - Controlling LEDs (Light Emiting Diodes) with Parallel Port