Rizwan's Blog -Developer's hangout!

Matthew Good Band - Weapon .mp3 Found at bee mp3 search engine

Some of the Windows Forms developers I've spoken to have said that one thing they want to learn is how to dynamically create controls in WPF and Silverlight. In this post I'll show you several different ways to create controls at runtime using Silverlight 4 and WPF 4. First, we'll start with how to create controls in XAML. From there, we'll move to dynamically-loaded XAML before we take a look at using the CLR object equivalents.   Creating Controls at Design Time in XAML Creating controls using the design surface and/or XAML editor is definitely the easiest way to create your UI. You can use Expression Blend or Visual Studio, depending upon how creative you want to be. If you want a more dynamic layout, you can hide and show panels at runtime. Here's an example layout: <Grid Margin= "10" > <Grid.ColumnDefinitions> <ColumnDefinition Width= "100" /> <ColumnDefinition Width= "*" />

Tomb stoning is  the process of saving the data and state of your application when it’s terminated such that it can resume where it left off when it is started back up again. There are many cases where you application may be suddenly terminated on the phone. Examples include incoming phone calls or activation of the camera on the device. Tomb stoning is an essential feature that almost every application should support to avoid customer frustration with your application. Tomb stoning an application is fairly straightforward. Every application on the phone has its own permanent storage space on the device that is referred to as isolated storage. Classes for isolated storage can be found in under the System.IO.IsolatedStorage namespace. You can use these classes to store and reload the state and data for your application. In your App.xaml file, the events you should monitor for are the following: Application_Launching – Code to execute when the application is launching. This code

When you start programming, you get disillusioned quickly. No longer is the computer the allinfallible perfect machine – "do as I mean, not as I say" becomes a frequent cry. At night, when the blasted hobgoblins finally go to bed, you lie there and ruminate on the errors you made that day, and they're worse than any horror movie. So when the editor of PC Plus asked me to write this article, I reacted with both fear and knowing obedience. I was confident that I could dash this off in a couple of hours and nip down to the pub without the usual resultant night terrors. The problem with such a request is, well, which language are we talking about? I can't just trot out the top 10 mistakes you could make in C#, Delphi, JavaScript or whatever – somehow my top ten list has to encompass every language. Suddenly, the task seemed more difficult. The hobgoblins started cackling in my head. Nevertheless, here goes… 1. Writing for the compiler, not for people W

Everybody should be excited about the next big thing. And why not? It’s very, extremely big. Even bigger than anything that came before. No, really, it’s that freakin’ HUGE. If you don’t want to get left behind, you’ve got to hop on this right away. Of course, you will need to be fast and smart and work late nights, but it will be worth it. You can’t go halfway on a thing like this. It’s all or nothing, baby! I’m here to tell you what this big thing is. But first, let’s take a quick look at past big things so that we can see why this one is so much bigger. A Short History of Big Things We live in interesting times. Conventional wisdom says that it takes about 20 years for new technology to take its full effect. These days, innovation cycles are much shorter, so we’re getting new stuff before we really know what to do with the old. Many economists believe that these time lags account for the productivity paradox (i.e. it’s notoriously difficult to measure what we r

Remy Zero - Save Me [Smallville Theme] .mp3 Found at bee mp3 search engine

Database developers are people too — you make mistakes just like everyone else. The problem is, users are the ones who pay for those mistakes when they have to work with slow, clunky applications. If you’re part of your company’s IT team, a mistake could cost you your job. If you’re a freelance developer, a bad database usually means a lost client — and even more lost business, if word gets around. Here are some common design pitfalls to watch out for. 1: The data’s unimportant; it’s the architecture that matters It doesn’t matter if your code sings, if you don’t know the data. You want the two to work in harmony and that means spending some time with the people who use and manipulate all that data. This is probably the most important rule: Before you do anything, you absolutely must get intimate with the data. Without that firsthand knowledge, you might make errors in judgment that have far-reaching consequences — like dragging the whole application to a complete halt. A nonchal

How many developers think they're good programmers? We're not. We're all fairly bad at what we do. We can't remember all the methods our code needs to call, so we use autocompleting IDEs to remind us. And the languages we've spent years, in some cases decades, learning? We can't even type the syntax properly, so we have compilers that check and correct it for us. Don't even get me started on the correctness of the logic in the code... I'm looking at a chart that shows failure rates for software projects. "Small" projects (about a year for 8 people) have a 46% success rate. That's almost half. Any longer project just plummets down to a 2% rate for projects costing 10 million or more. In other words, our projects nearly always fail. We constantly write code that breaks existing features. We add features in ways that won't scale. We create features nobody wants. In short, as an industry, we all stink. You can fight this. You can su

Guns n' Roses - Slash - Godfather Theme .mp3 Found at bee mp3 search engine

I just attended Test-Driven Development presentation which represents everything that is wrong about the way Agile advocates are trying to evangelize their practices.  I don’t have anything against the presenter in particular, but it’s really time for Agilists to rethink the way they communicate with the real world. Here are a few comments on his presentation. One of the first slides that deeply troubled me claimed the following: Tests are (executable) specs. If it’s not testable, it’s useless. First of all, tests are not specs.  Not even close.  Somebody in the audience was quick to give a counter-example to this absurd claim by using a numeric example ("how do you specify an exponentiation function with a test?") but my objection to this claim is much broader than that.  Relying on tests as a design specification is lazy and unprofessional because you are only testing a very small portion of the solution space of your application (and of course, your tests ca