A blog about all things .Net, with a c# perspective. Tips, tricks and discussions about development issues.
Multithreading in Winforms:
A .Net UI Rule of thumb: Keep your user interface in the same thread (this is the default windows behaviour) If you are creating a form in a seperate thread then you are probably doing a time-consuming task and don't want to hold up the user interface while this task completes.
If this is the case then rather put the task in a separate thread. Use an asynchronous delegate to initiate a callback from the thread when it completes execution. This allows your user interface to keep responding to the user until the thread completes and notifies the application. It's like sending something off to go do work and not worrying about it until it comes back with the finished product.
Topics: Asynchronous delegates, multi-threading.
How to display an image from a Database
Someone asked me how they would display an image from a database. This means they've saved the raw image data into an Sql database as type Image, and want to retrieve it for display. In this example the code will send it to the output stream of an ASP.Net application.
string sql = "SELECT thumbnail FROM tb_Products WHERE ProductID = " + ProductID;
SqlCommand command = new SqlCommand();
command.CommandType = CommandType.Text;
command.CommandText = sql;
command.Connection = yourConnectionObject;
// Get the raw image data
SqlDataAdapter adapter = new SqlDataAdapter(command);
DataTable resultDt = new DataTable();
byte imageData = (byte)resultDt.Rows["thumbnail"];
// Send it to the caller
MemoryStream memStream = new MemoryStream(imageData);
Game Development in .Net
Sheesh, I thought I knew a lot about development until I started doing a little browsing around Game dev. There is so much to this topic and it's a whole new style of development. Sometimes I think these guys hold the mecca of software development in their hands. They define their own development environment and literally create the tools they need to roll out the next mega game.
Whereas us plebs that are involved in application development are all following the tried and trusted development model. Front-end -> Business Logic -> Persistent Storage. Sure, the technologies are cool, but the actual implementation and development of such solutions doesn't invoke that much excitement. Think about it - all development is boring except those that create worlds that us plebs can immerse ourselves in.
A pretty bold statement, but sometimes one must think about the reasons we're here developing code. Application developers make systems that other people can use. Game developers make worlds that people can play in.
If you want to find out more about game development in general, check out these sites
Check out Microsoft's Directx homepage:
The Mobile Device Revolution
Something huge is about to hit the world of personal device interaction: Mobile computing machines. Almost every human on the planet that makes use of domestic technologies such as telephones and email also has a cellular phone. The percentage of these devices able to install and run applications is increasing astronomically. Pretty soon all devices will have a minimum feature set that allows them to run applications. Suddenly the possibilities are _massive_.
Using application abstraction systems such as J2ME
and the new Qualcomm BREW
platform the deployment of broad market applications suddenly becomes a reality. J2ME is in the lead with platform development, and has strong backing from mobile phone manufacturers such as Nokia and Motorola. Sun have used a subset of the standard java libraries to create a minature set of very useful classes. The development possibilities range from applications through to games through to internet messaging.
Bloggers, the future of app development is in the mobile device. It offers on-demand service, anytime and anywhere the user pleases. It also fits into the user's schedule, he can manage two tasks at once (one on his phone and another via some other interface, such as ordering coffee at the same time). The user will soon see that his mobile phone offers him much more flexibility and freedom. An example is the evolution of the laptop; they have become smaller and lighter to accomodate the user's need for convenience. He does not want his movements to be hampered by his computer.
What this space!
Skk Skk 8)
Distributed Systems in .Net
Do you want to write a distributed system using .Net? There are several new .Net generic technologies you can choose from, the most popular options being: Remoting and Web Services. If you want to find out more about distributed .net development then get hold of a book called Distributed .Net Programming in C#
, at Amazon
Tom Barnaby does a really good job of giving you a foundation in distributed development, and lays it down in 5 concise laws:
Only distribute processing if you need to - there are many performance and reliability disadvantages)
Localize related concerns.
Types that are used a lot together should be localized to the same server.
Use Chunky rather than Chatty interfaces.
Have many methods that allow you to do many very specific operations, rather than entering into a conversation with the remote server.
Program against an Interface.
The age-old principle, use the interface as a contract between the service supplier and the service consumer.
Make method calls stateless and not stateful.
Do not persist state between method calls. If you must, persist the state to a database of some sort, but don't store it in temporary memory.
Overloaded Methods lead to Ambiguity
What is the purpose of overloading a method? On the surface it's a way to have a "configurable" method, a method that can have bunch of different options that will make the outcome different in some way. But looking a little deeper will reveal that each "option" that you can choose (translated, each overload that you can invoke) is actually a whole new method, and performs a slightly different task to its associates. This is the same as taking a term and giving it more than one meaning, depending on the context. In natural English this is possible because context forms such an integral part of our communication. In development however (i.e. unnatural languages? :P ) context is not so deterministic and grave mistakes can be made.
The bottom line is that if you are going to overload a method, rather create two methods and do some partial name matching to make the relationship obvious. For example, take a method like ButtonFactory.CreateNewButton(string name)
and it's overload ButtonFactory.CreateNewButton(string name, bool hasBlueBackground)
. This should translate to ButtonFactory.CreateNewButton(string name)
and ButtonFactory.CreateNewButtonWithBlueBackground(string name, bool hasBlueBackground)
Special cases for overloading come when you are going to have five or six related methods, then method names can become a bit long. Other than that, overloading should be avoided to encourage unambiguous code.
Remember, if you've coded it with an ambiguous meaning, then you probably aren't 100% sure of the method's purpose. Don't expect that because you don't fully understand it that someone else will.
Skk Skk :)
Microsoft Inductive User Interface
Microsoft proposes a new way to create a user interface. A good example is Microsoft Money. Read the Microsoft specification
IUI is a well-needed step to creating the all-powerful all-useable interface. Let's face it, designing a UI is simply difficult. And the more complex your application's features, the exponentially more difficult it is to design a user interface.
Or is it? My feeling is that developers of interfaces trade "Screen Complexity" vs "User Understanding". It is true to say that any incredibly complex task (given that we are thinking about process-orientated interaction) can be broken down into minute tasks, and each step can be guided by the interface.
The next challenge is how one caters for the novice and the advanced user. The goal is to have both users being as productive as possible. It's no good having an "Advanced Mode" where all complexity is revealed. The percentage of people who would use this does not warrant its development.
The keys to speeding up productivity across the board is Navigation and related-task positioning. If your UI does not navigate smoothly (this includes long mouse cursor moves, like having a "Done" at the bottom right hand corner of the form) it will be like driving a car with a flat tyre: The ride is uncomfortable no matter how fast you go.
Positioning related tasks should be done in relation to their relevance to the current task and the complexity of the path they will take the user on. In other words, make the obvious next step jump out at the user more than, say, a step that takes the current task's data and cross-references it with parent data.
IUI is a good route forward, and it draws user interfaces closer to being integrated with the person driving the computer. The User Interface is now adapting to the user, and not the other way round.
Skk Skk :P
Building Multiple Projects in VS.Net
The default behaviour when building a solution with multiple projects in Visual Studio.Net is to take you from the Output window to the Task List window. This is especially annoying when you have two projects, both have errors, but you've only compiled one of them. The Task List will display errors from both projects.
The quickest way to prevent this: In VS.Net go Tools->Options->Environment->Projects and Solutions
Untick the option Show Task List window if build finishes with errors
When you next build, look at your errors in the output window. Clicking on one will display the full text at the bottom of the IDE. Double-clicking will take you to the error in your source.
Ssk Ssk >)
Testing gets it's own system
Our department recently invested in Fogbugz http://www.fogcreek.com/FogBUGZ/
from a company called Fog Creek software (remember Joel Spolsky?)
The real power of the system arrived in the empty shell called my head today as I was discussing a list of bugs with my colleague. We were talking about bug number 188.
What the heck does bug number 188 mean to you? It is simply this: A bug that was discovered in one of my applications was uncovered, reported on, commented on, all under one label: 188
A bug tracking tool offers a way to capture software bugs into a database (better named "Master List") so that they can be easily tracked, updated and eventually closed. There are several bug trackers out there, some free and some license-based. It all depends on your needs and available resources.
Bugs are something nobody wants to know about (maybe it's a developer pride issue), but they are there and they need to be handled correctly. I see bug trackers as harnesses for bugs.
FogBugz is my tool of choice, because it keeps things generic and simple, and has quick navigation features, so you can jump to bugs easily.
Another one to try is BugZilla BugZilla
Skk Skk ;)
Moving to Dynamic Development Teams
Just one thing: I hate long-winded splurb, so now I'm gonna try something short and sweet.
Dynamic teams are better than static teams.
A collection of people gathered under a common project, only for the life of the project.
A collection of people that form part of a static heirachy, grouped under a very general purpose (such as "Back Office")
Dynamic teams pull resources together for a specific task. The task will require certain resources, which are commissioned at the start. At the end of the project, the resources are released and available for the next task. Static teams attempt to fit tasks to a set of resources.
For maximum efficiency in a company, the task (project) should determine the resources, and not the other way round.
Clincher: Damn this is a neat way to state an argument!
Skk Skk! >)
Why do I need to occasionaly restart IIS?
Think about this: All .Net web applications / services run under a process. The process does not know about the application until someone requests it in some way. Once requested, the worker process (w3wp.exe in 2003, aspnet_wp.exe in 2000 and XP) loads the matching application libraries into an application domain.
Sometimes you will notice that when debugging a .net application the debugger seems to "lose it". The reason is that the new libraries have not been loaded by the application, and it's still holding debug references to the old code. So you get yellow debug lines on whitespace in your VS editor (wierd!)
The worker process will occasionally be able to load the libraries into a new application space and trash the old application space, and send all requests to this newly instantiated application space. The result is that everything works after your rebuild. If it fails, then you need to kill your worker process so that a new instance will load on the next request of the application/service, so that it will be forced to reload the libraries.
It's a really nasty way to restart/reload your application, but it's due to the nature of the co-op between IIS, the worker process and your application.
Skk Skk 8)