So I've recently started to dig into the WPF bits of VS 2008 and decided to start with a small sample app. Unlike most people that like to do the Hello World type apps, I prefer to practice on something that has actual utility in my business so I decided to build a leaderboard for our sales call center. I'm going to go over how I accomplished this and hopefully help people get as excited as I am about WPF. Excited is the proper word too, I've been reading Chris Anderson's book and it's been a great resource for explaining the hows and whys of the WPF architecture and frankly I am thrilled. Microsoft has really taken a great step forward with helping designers and developers work together with VS 2008 and Expressions. As you'll see in this sample, even with my limited graphical ability I'm able to do some interesting things with WPF.
So what I want to accomplish is to place a tab control on my form (so we can add new tabs for different views later), and we'll call it "sales". The markup for this is pretty simple:
1: <StackPanel>
2: <Label Name="lblHeader" Content="Leader Board"/>
3: <TabControl>
4: <TabItem Header="Sales">
5: <Grid>
6:
7: </Grid>
8: </TabItem>
9: </TabControl>
10: </StackPanel>
Next, inside the grid tag of the tab control, we're going to define a ListView control with a gridview, which will give us a grid-like appearance out of the box. I'm going to put the name of the sales person, the number of calls they took, the number of sales they made, and their conversion rate (sales/calls). The first pass looks like this:
1: <ListView Name="lstSalesLeaders">
2: <ListView.View>
3: <GridView>
4: <GridView.Columns>
5: <GridViewColumn Width="125" Header="Name" DisplayMemberBinding="{Binding Path=Name}" /> 6: <GridViewColumn Header="Calls" DisplayMemberBinding="{Binding Path=NumberOfCalls}" /> 7: <GridViewColumn Header="Sales" DisplayMemberBinding="{Binding Path=NumberOfSales}" /> 8: <GridViewColumn Header="Conv" DisplayMemberBinding="{Binding Path=ConversionRate}" /> 9: </GridView.Columns>
10: </GridView>
11: </ListView.View>
12: </ListView>
Notice the usage of the DisplayMemberBinding property. WPF syntax likes to use the curly braces for bindings. Path simply points to a property, data table column, etc on the collection I'm going to bind the listview to. Now I tend to prefer working with Generic lists of objects rather than data tables, so I'm going to create a salesview class to hold the data I want:
1: class SalesView
2: { 3: public SalesView(string name, Int32 number_of_calls, Int32 number_of_sales)
4: { 5: Name = name;
6: NumberOfCalls = number_of_calls;
7: NumberOfSales = number_of_sales;
8: }
9:
10: public string Name { get; set; } 11: public Int32 NumberOfCalls { get; set; } 12: public Int32 NumberOfSales { get; set; } 13:
14: public string ConversionRate
15: { 16: get { return (NumberOfCalls == 0) ? "0.00%" : string.Format("{0:p}", Convert.ToDouble(NumberOfSales) / Convert.ToDouble(NumberOfCalls)); } 17: }
18: }
Now that this is complete, let's go ahead and bind the list in code. We'll just create a few dummy objects at this point and then assign the resulting collection to the ItemsSource property of the list:
1: public Test()
2: { 3: InitializeComponent();
4: BindLeaderBoard();
5: }
6:
7: private void BindLeaderBoard()
8: { 9: List<SalesView> sales = new List<SalesView>();
10:
11: sales.Add(new SalesView("Salesperson 1", 10, 7)); 12: sales.Add(new SalesView("Salesperson 2", 10, 4)); 13: sales.Add(new SalesView("Salesperson 3", 10, 5)); 14:
15: lstSales.ItemsSource = sales;
16: }
So when we run this, we see we have a pretty plan looking grid, all black and white, very boring. I'd like to spice it up a bit. Let's say that every salesperson has a conversion goal of 45% sales and we want to change the forecolor of the grid row to be green if they meet or exceed the goal and red if they are below the goal. WPF offers us some fun ways to style items in the way of data triggers. The only problem I see with data triggers is that they don't seem to take a range, so we will add a boolean property to our SalesView class called IsMeetingConversionGoal. Then all we need to do in our xaml is define a style tag in our listview and two data triggers, one for IsMeetingConversionGoal is true and one for false, the result looks like this:
1: <ListView.ItemContainerStyle>
2: <Style TargetType="{x:Type ListViewItem}"> 3: <Style.Triggers>
4: <DataTrigger
5: Binding="{Binding IsMeetingConversionGoal}" 6: Value="True">
7: <Setter Property="Foreground" Value="Green" />
8: </DataTrigger>
9: <DataTrigger
10: Binding="{Binding IsMeetingConversionGoal}" 11: Value="False">
12: <Setter Property="Foreground" Value="Red" />
13: </DataTrigger>
14: </Style.Triggers>
15: </Style>
16: </ListView.ItemContainerStyle>
So now if we run the project, salesperson 2 is now red and the others are green! Notice the use of the binding syntax yet again and the setter property. You can set anything you want so you can get quite fancy with your displays pretty easily. We're not through yet however! Besides the data trigger, you can also trigger off a wide list of properties to update styles. Lets get fancy and create a gradiant color fill on the row when we mouse over it. WPF makes this task simple:
1: <Trigger Property="IsMouseOver" Value="true">
2: <Setter Property="Foreground" Value="DarkBlue" />
3: <Setter Property="Background">
4: <Setter.Value>
5: <LinearGradientBrush EndPoint="0.5,1" StartPoint="0.5,0">
6: <GradientStop Color="#FFFFC704" Offset="0.986"/>
7: <GradientStop Color="#FFF4E057" Offset="0.5"/>
8: <GradientStop Color="#FFF4E057" Offset="0.51"/>
9: </LinearGradientBrush>
10: </Setter.Value>
11: </Setter>
12: </Trigger>
Run the project again, mouse over, and now you have a nice highlighted background with a gradiant. I chose the gradiant just to show off that we're not bound to solid colors or importing gradiant background images like I always had to deal with in the web world. If you want to know more about brushes and gradiants, ask a designer, I'm not your man.
For my grand finale, I'm going to show you how to refresh this list every 60 seconds. Of course this won't do much in the current project since we're not binding to a database, but the point to drive home is that the old Timer class doesn't play nice with WPF. To handle timed events in WPF, you should use the new DispatcherTimer class located in System.Windows.Threading. This class is really useful and easy to use as I'll demonstrate below:
1: private DispatcherTimer leaderboard_refresh_timer;
2:
3: public Test()
4: { 5: InitializeComponent();
6: BindLeaderBoard();
7: InitializeTimer();
8: }
9:
10: private void InitializeTimer()
11: { 12: leaderboard_refresh_timer = new DispatcherTimer(DispatcherPriority.Normal);
13: leaderboard_refresh_timer.Interval = TimeSpan.FromSeconds(60);
14: leaderboard_refresh_timer.Tick += new EventHandler(dispatcherTimer_Tick);
15:
16: //Starts the downloading of the images
17: leaderboard_refresh_timer.Start();
18: }
19:
20: private void dispatcherTimer_Tick(object sender, EventArgs e)
21: { 22: BindLeaderBoard();
23: }
24:
25:
26: private void BindLeaderBoard()
27: { 28: List<SalesView> sales = new List<SalesView>();
29:
30: sales.Add(new SalesView(10, "Salesperson 1", 10, 7, 0));
31: sales.Add(new SalesView(10, "Salesperson 2", 10, 4, 0));
32: sales.Add(new SalesView(10, "Salesperson 3", 10, 5, 0));
33:
34: lstSales.ItemsSource = sales;
35: lblHeader.Content = "Leader Board (Last Update: " + DateTime.Now.ToShortTimeString() + ")";
36: }
So what we accomplished was initializing the DispatcherTimer, set the interval to 60 seconds and bound up the tick event. Now the data doesn't change, so I decided to update the header label's content with a time stamp so you can see that the timer is in fact working and calling the bind method for the leader board. So if we were connected to a live data source it would refresh the data accordingly.
I hope that this slightly more advanced "hello world" of WPF catches your imagination about the power and utility of the new framework. I'm quite excited to start writing applications in it.
posted @
Saturday, March 01, 2008 9:33 AM |
Feedback (0)
Pretty simple. You don't.
Programming superstars are such that the companies they work for would never willingly release them if they could help it. So they're not usually looking for work. These superstars have the respect of their peers and usually have a presence in the community. If they change jobs, it is usually through a referral system.
You want to find superstars, expand your social network.
posted @
Wednesday, February 27, 2008 7:51 PM |
Feedback (2)
Recently, I created a blog post on developer interview questions I ask as weed out questions. I'm back on this topic because Jeff Atwood blogged on it recently and I figured I should follow up on my own experiences.
All in all, I phone screened 17 candidates for the software developer positions that were open. Here are the results:
3 candidates answered most the questions and passed the fizzbuzz coding test in person. One was senior, one was midlevel, and one was fresh out of college.
3 candidates did reasonably well on the questions, but failed the fizzbuzz test completely.
1 candidate answered most the questions, but when presented with fizzbuzz they created a solution, but didn't follow the instructions given (went from 0 to 100 instead of 1 to 100).
10 candidates failed the phone screen being unable to describe basic OO principles.
So basically we had a 76% outright failure rate. I was still trying to decide if that's acceptable or if my interview process is too difficult but then looking at Steve Yegge's post, maybe it's not difficult enough. I was quite happy to see though that on the question set that the questions I came up with were pretty similar to his. I'm definitely going to borrow some of his other simple code questions though too so I don't have to rely on FizzBuzz all the time.
posted @
Thursday, January 24, 2008 10:14 AM |
Feedback (1)
Some of you movie buffs will get where the title of this post is going, so I'll refrain from filling in the blank. :)
I got kind of jazzed up this morning when I was going through my blog feeds and I saw a post from my buddy Ray which is becoming far too common in my opinion. I've been keeping my finger on this undercurrent of backlash against mortal developers for quite some time now, and its growth in popularity in the community is becoming quite disturbing to me. Now let me just preface this that it isn't an attack on Ray, who I consider a friend, but I really need to address the idea he is putting out.
Is there too much money to be made in software development? No. Of course not. We live in a free market where developer talent is difficult to find and the tasks required by developers are not easily filled by off the shelf or low skilled solutions. The pay is simply a reflection of the basic supply vs demand in the market place.
Assumption #1 that is made in the opinion is that the high compensation is at odds with the desire to learn and grow your skills. If anything, I would assert that money is not a good indicator in IT of motivation. The concept that many developers will give away their time and skills for free to open source projects etc suggests that compensation while important, is not a primary piece of the puzzle. When compensation gets much higher in a particular field than others, what it does is bring people into the field who may have other aptitudes, but enough aptitude to survive in our field.
Assumption #2 is that having these non-elite developers in the field is a bad thing. It certainly is not. These are the people that drive companies like Microsoft to make tools that are easier for everyone to use and make common tasks more simple. The problem with people in our community here is that being better than average skilled tends to make you a control freak, and I see a lot of backlash against simplification tools because you lose granular control. Making software development easier lowers costs, improves reliability, and allows development talent to focus more wholly on the problem to be solved than the mundane details. I drag and drop all the time when I'm prototyping, if I didn't have the simple tools to do these tasks, it would be much more costly to do proof of concepts and a lot of ideas would end up being rejected out of hand.
Assumption #3 is that every software project being worked on is considered core and critical to a business and deserves highly skilled developer talent thrown at it. The reality is that all businesses are operating with limited time and resources, and must allocate those resources for the best overall gain. Many software projects start out as "nice to haves" but aren't critical to the business. The business throws these to the low bidder in order to try out a concept, and if it works and becomes critical to the business they want to pull focus on it. Then they bring in the big guns who proceed to sit around and bitch about the architecture, quality of code, whatever instead of realizing that businesses and people do not deliberately attempt to create bad software, but sometimes unimportant software evolves into something more. As a manager I've had this decision cross my desk many times, and it's not an easy one to make. Do I take my superstar developers off the money making projects to work on a proof of concept for the marketing department or do I toss the smaller unimportant project to cheaper, lower skilled talent and see if it takes off? Generally the best use of my resources is the latter.
Assumption #4 is that skilled people like Ray even want to do the work that the "mediocre" developers are doing. I know coming up the chain in my career I avoided maintenance projects like the plague. I hated doing maintenance and loved doing new architecture and development. You couldn't have paid me enough to maintain an existing application because it was so damn boring! I also tend to prefer business applications and logic as opposed to other types of software. Could I work on a product like Vista? Probably, but I don't want to, I don't have any interest in it. Does anyone think Scott Guthrie would leave his role at Microsoft to be a maintenance coder on 15 yr old bank software? Someone has to do it though.
Assumption #5 is that being mediocre is a choice. People are different, we have different aptitudes, different intelligence, different social aspects. Not everyone can be productive in every environment, not everyone learns at the same rate, and not everyone has the same max potential. Does that mean these people have no place in the field? These arguments usually make me think of what would happen to a company if every 3 years they went through the performance reviews and fired the bottom 80%. Sure you'd only have the top 20% working at your company, but you'd probably be overwhelmed by the amount of work to be done.
I think the community needs to take a deep breath and realize there is value in developers of all skill levels and tasks which are best suited for them. They also need to realize that the project you are working on may not have been, is currently, or ever will be considered key to their client's strategy, and thus simply may not be all that important to get perfect. Lastly, let us all realize that the 80/20 rule on skilled people isn't a symptom of IT, it's a symptom of the world you live in. We can't all be valedictorian, nor should we need to be.
posted @
Wednesday, January 23, 2008 1:21 PM |
Feedback (3)
When building a team, as I am now, I think it's very important to manage the culture of the team so that it can be as productive as possible. Over the years, having experienced different types of teams in various cultures I have mentally put together a list of attitudes and ideas that I think are beneficial to a development team. I figured I'd share them here. I'm going to call it my development creedo.
----------------------------------------------------------------------------------------------
I <your name> am a developer.
I understand that the reason I exist is to serve the needs of the users. I will take user requirements seriously and be passionate about customer service. I will not show disdain for the customer who does not understand what I do and will always attempt to cross the bridge from the technical world to the user's world to better understand them. By gaining the user's understanding I can build the user's trust, and with trust I can gain a valued partner in the development process.
I understand that every member of the IT staff is important to achieving my goals. Database administrators protect my data and help ensure it is performant. Network administrators make sure my backups are secure and that I have the access, software, and working systems I need to perform my job. I will not form a silo of developers and resist having an "us vs them" mentality. I will support the non development members of my team as I would any other peer or customer.
I understand that every developer on my team is my peer. As a peer, they will have my respect and I will have their respect. With a trusting and respecting relationship, I will not fear to ask questions, raise concerns, or otherwise assist my peers in creating high quality code. I see intellectual conflict as a healthy and natural function of teams to arrive at the best course of action for a task. When conflict has concluded and a direction has been decided by the team, I will wholeheartedly support the approach taken even if my suggestion was not the "winner".
I understand that ego in all its forms is destructive and harmful to the team. I will remember that the team owns the code, not the individual. While I should feel pride in my individual accomplishments, I will always remember to credit the support of my team for my achievements, and I will never jealously guard my code and techniques from my peers. I will encourage my peers to review and understand my code and welcome their constructive criticisms. I realize that all code can be improved and will take constructive criticism as a chance for intellectual debate and a learning experience instead of as a personal slight.
I understand that my field is constantly growing and changing. I will create opportunities to explore new concepts and be open to new ideas. I will not latch on to particular patterns or development practices that I am comfortable with and use them in inappropriate situations. When I use particular patterns and practices I will carefully weigh the benefits and drawbacks of the patterns and make decisions that are the best for the team. While I enjoy learning new things, I will resist using tools and development practices just because they are new or cool, but only when they add real value to the code.
I understand that even though I am the first to write this code, I will not be the last to maintain it. I will strive to keep my code readable, well documented, and have as little complexity as possible. I will not assume that since I am aware of a particular tool or development pattern that other developers are. I will carefully document the usages and justifications for using a pattern or tool so that those who come behind me can understand better what I was trying to accomplish. I will never make my code difficult or obscure in an attempt to build "job security" or prove how smart I am.
posted @
Monday, January 07, 2008 10:41 AM |
Feedback (6)
Working once again on hiring developer talent I am again amazed at the number of candidates who come my way who have little or no understanding of object oriented fundamentals. As many of us end up doing interviewing even when we're not managers I figured I'd share some of the questions on my technical .NET developer interview that I expect any developer with experience to get right. Feel free to suggest more questions and critique the ones I have!
-
Describe inheritence, give examples of when you would use it.
-
Describe what an interface is, how is its usage different from inheritance?
-
There are many ways of working with multiple related items in code, such as an array. Name some of the other options and how they are used.
-
What is the difference between a value type and a reference type?
-
What is serialization? How do you implement it in .NET?
-
If you were going to read a text file from the disk, how would you go about it?
-
In .NET, you can modify class and method access with modifiers like public and private, what are some others and what impact do they have?
-
Describe as many objects as you can that are used with ADO .NET
When I design a question set, I try to avoid pure definition questions in favor of open ended questions. Basically I'm trying to get the candidate to go into an essay style dialogue and just tell me as much as they know in a given category. I find it is harder for people to fake knowledge with such open ended questions, and unlike your yes/no pure definition style questions I think the above requires them to actually have used and be aware of the concepts. Pure definition questions can be memorized and don't really show true understanding. Open-ended ones tend to give the candidate enough freedom to show their knowledge or lack of depth.
I generally don't expect everyone to get all the questions right. If your'e junior level I'd expect 30-50%, mid-level 50-80%, and a senior/lead should be able to answer them all without difficulty.
posted @
Monday, December 31, 2007 10:21 AM |
Feedback (7)
Just a small announcement. After two years I am leaving my position as Application Development Manager at Hartville to pursue a new opportunity as Director of Technology Services for a company located in Hudson, OH. This is a big promotion for me as I will now be managing a cross-functional team instead of just developers and I am quite excited to be there. I will likely be doing some blog posts this week and next about my adventures in hiring in the current market.
Hartville is a great company with great people working for it, but the chance to advance my career and build my own team was irresistable.
posted @
Monday, December 31, 2007 10:17 AM |
Feedback (0)
Over the holiday, it's important in our tech world to keep a good perspective on the little things in our developer jobs that make our lives a whole lot easier and are relatively underappreciated:
-
Relational Databases- Can you imagine the pain of trying to keep your data valid without automatic relational enforcements? If you're like me and have had to fix systems that didn't use proper constraints, you know what i'm talking about.
-
Garbage Collection, Transactions, and other things that make me not have to worry (so much) about cleaning up after myself, leaving me to focus on the business value code.
-
Compiler time type checking- nuff said.
-
Interfaces and Inheritance- Remember having to write procedural code and throwing gotos all over the place as well as duplicating code? I do!
-
Source Control- Nuff said
-
The blogosphere- Yes you, all of my bretheren in the blogosphere. Your documentation and sample code is so much better than what you can get in most books and white pages/msdn.
posted @
Wednesday, November 21, 2007 12:06 PM |
Feedback (9)
The more I look into the LINQ features of the Framework, the more excited I get. In particular, LINQ to XML has an incredible amount of productivity when working with XML documents.
"But Eric, " I hear you say, "we can work with XML with existing framework items."
Yes and No.
The problem myself and others are faced with when working with XML is the sheer amount of choices. You have to learn when to use the XML DOM, XPATH, XSLT, and the various other means of manipulating XML. They all have their tradeoffs and benefits but they are all very different to work with. Not that this is insurmountable, if you work with XML often, it's not going to be a problem for you. But if you are like me, and spend most of your time on internal apps with a database, you don't really use XML all that much, so when the need actually arises you find yourself swimming in documentation and trying to figure out the best way to do what needs to be done. By providing LINQ to XML anyone who understands LINQ should be able to quickly jump in and manipulate XML, which I think is absolutely huge.
Interestingly enough, I like the VB version of LINQ better than the C#. I'd like to put a short code sample here to show why. The VB and C# for creating an employee XML node is roughly the same. By using the XElement LINQ object, I can chain down the xml node and fill in all the values I want, like so:
Dim employee As New XElement("employee", _
New XElement("name", "Eric Wise"), _
New XElement("department", "Information Technology"), _
New XElement("title", "Application Development Manager"), _
)
Very easy both to write and read compared to some other solutions. However, there's an even neater way in VB .NET. You can actually use literal xml. Check this out:
Dim xml As XElement = <employee>
<name>Eric Wise</name>
<department>Information Technology</department>
<title>Application Development Manager</title>
</employee>
Is that not, the coolest, most readable XML generation you've ever seen?! Programatically you can replace my string literals with variables using your traditional ASP Script tags <%= %>. This is an incredibly powerful method of generating maintainable XML code.
I hope this gets everyone excited about LINQ to XML!
posted @
Tuesday, November 13, 2007 5:53 AM |
Feedback (7)
Frankly, I haven't seen much use of the struct in the coding libraries I've come across, yet every time I encounter a technical interview, the struct vs class question always seems to come up as a gotcha question. So for my inaugeral post on the Runtime I would like to quickly point out the difference between these two concepts, and why you may actually want to use a struct instead of a class in your application.
It's all about the memory
The most fundamental difference between a class an a struct is that a class is a reference type and a struct is a value type. Being a value type means that when a struct is created, it is placed on the stack, while a class is placed on the heap. Performance-wise, we like things to go on the stack, because the stack is immediately cleaned up when the variables in it go out of scope (ie at the end of the method) whereas the heap requires the Garbage Collector to perform its cleanup. Realistically though, the .NET framework is optimized such that the performance of one versus the other is likely not going to be a concern for the vast majority of applications (see other authors tirades on not optimizing until you absolutely must). Also, stack memory is more limited in size than heap memory, but again, realistically this is not a problem you are likely to encounter.
So how else are they different?
For one, you can not create a parameterless constructors! You must have parameters in your constructors because initializing in the declaration of the field throws an exception in .NET. Thus if you were to write:
-
{
-
public int MyInt = 5; // Illegal
-
}
You would get a compiler error. Instead, a proper struct would look something like this:
-
{
-
public int MyInt;
-
public int MyInt2;
-
-
public MyStruct(int a, int b)
-
{
-
MyInt = a;
-
MyInt2 = b;
-
}
-
}
Of course, you can initialize a static field.
A scenario that might jump up to bite you as a developer is if you forget that structs when passed to a method are passed by value. If you are used to tossing classes around by reference, changing their data, and having the original object in the caller be updated, you're in for a surprise as the changes you make within the method will be discarded on exit. You can of course, fix this by using the ref parameter to the method, after you finish cleaning up all the data you corrupted by your omission. :)
Is there any wierdness I should be aware of?
Actually yes. While you can't inherit a struct class, you actually can implement an interface in a struct class. This is where the whole memory dynamic changes. If you cast a struct as its interface type (which you'll likely do, since that's the point of using interfaces after all) then it will be boxed and thrown on the heap. This would all be well and good, but the wierdness comes in when you realize that any changes to the boxed copy only effect the boxed copy. So unlike other reference types that you would expect updates to flow through, this particular scenario will not. So basically if you made a statement like ((MyInterface)MyStruct).DoSomething(); then on the very next line of code checked MyStruct for changes, they wouldn't be there, since the interface call would be boxed, modified, then lost since you didn't explicitly unbox it.
In Conclusion
I rarely use structs in my own code mostly because I've never been faced with a situation where it was compelling. It is good to know that they exist, however, and the value type/reference type and stack/heap knowledge of how the .NET Framework works is great information to know not only for those gotcha interview questions, but in day to day troubleshooting.
posted @
Sunday, November 11, 2007 6:17 AM |
Feedback (3)