- Posted by Ian Suttle on October 5, 2008
- Filed under General
I've heard of Hulu, but until now I hadn't checked it out. This TV season started a few weeks ago and I've already had DVR mishaps with the Terminator: The Sarah Connor Chronicles and Heroes series and I needed a way to get caught up. Hulu allowed me to search for the episodes I've missed, queue them up, and play them in full screen... my hero.
- Posted by Ian Suttle on September 28, 2008
- Filed under General
Including charts in your applications often adds value and polish. If you don't have a charting package in your tool belt choosing one can be both confusing and expensive.
If you're in this boat check out Google Charts, which offers free charting with lots of options. And by "free", I mean free... but Google does ask you let them know if you'll be cranking out more than 250,000 charts a day. For you Web 2.0 and cloud junkies this option fits the bill perfectly.
The API is just a combination of URL querystring parameters. Here's a basic example:
This URL: http://chart.apis.google.com/chart?chs=300x100&chd=t:40,40,10,10&cht=p3&chl=Java|.NET|PHP|Ruby+on+Rails
Generates this chart:
Here we add blue as the base color by adding '&chco=0000ff':
http://chart.apis.google.com/chart?chs=300x100&chd=t:40,40,10,10&cht=p3&chl=Java|.NET|PHP|Ruby+on+Rails&chco=0000ff
You can vary the individual colors, chart types, dimensions, etc. Flexible, fast, and free.
- Posted by Ian Suttle on August 9, 2008
- Filed under Agile | Process
Welcome to part three in our ongoing quest to bring an effective agile development process to IGN Entertainment.
Early on I recognized one piece of criteria critical to us succeeding in bringing Scrum to IGN - everyone had to buy in. This is a change for us and as has been drilled into our noggins for years, most people don't like change. The idea isn't to change for the sake of change of course, but to continually improve our team, processes, communication, and company. I'm sure most people can buy in to that one so we had to show how the change being proposed would accomplish these goals. We're still in adoption phase (it's been about three weeks) but feel it's going really well. Here's how we got to today:
Early Warning
We notified the product and engineering (us) groups we were looking to make some changes to improve how our groups worked together. We committed to introducing the process and let them know we were going to need their help. It wasn't the intent but this got their mouths drooling a bit for new ways to improve. I received numerous emails asking when we were going to "discuss the new process." Slow down people we're workin' on it!
Introduction to Scrum
We held Scrum introduction meetings with multiple product groups to discuss Scrum including key terms, roles, and the flow. We also thought it'd be good to run through a mock sprint but in hindsight that was a bit redundant with the rest of the introduction. We also created a Scrum cheat sheet to hand out so people could leave with some reference material. Lastly we opened the floor for questions. We certainly didn't have all of the answers but expressed our commitment to work through them together.
Working Together
Scrum has distinct roles and criteria to fulfill each piece of its process. The product owner must populate a product backlog and prioritize their items. A sprint planning meeting is held to review the product backlog and assign sprint backlog items with estimates. A daily scrum is held to ask the famous three questions of "what did you do yesterday," "what will you do today," and "is anything blocking you". It goes on and can seem like a lot to rookies like us.
The fact is in the beginning nobody knows how to actually execute on these things so we dove in head first. We were committed to giving this a real go and working together to answer questions and solve problems. We helped create the product backlog, provided access to tools for reviewing and prioritizing, ran the sprint planning meetings, and took the role of getting the answers to whatever needed to be answered. Learning, team building, and communicating at their best.
Delivering the Goods
A new process with magical results and innovative ways of getting things done doesn't mean squat if you don't deliver on your commitments. At the end of our first sprint we did what we promised in a variety of ways. The product group knew exactly what to expect from us, communication was improved through sprint planning and daily scrum meetings, and the work got done. In fact the work got done earlier than expected and we started taking more items before the sprint was over! I guess our estimates were too conservative but better that than too aggressive.
Delivering on your commitments builds trust in both the process and the people.
Marching Ahead
Formally holding a sprint retrospective meeting is another piece of the Scrum process. We did this after our first sprint which revealed a number of things, the most important being to account for everything you have to do using sprint backlog items: coding, code reviews, documentation, deployments, unit testing, meetings, testing, documentation, etc. If it needs to be done, add it!
I'm looking forward to continuing our rollout of Scrum and other agile-esque methods. Each day we invest reveals more clarity and benefits of the processes which is great because day one it didn't all make complete sense :).
Have you worked with Scrum and came across pros or cons you hadn't even considered?
- Posted by Ian Suttle on July 31, 2008
- Filed under General
Here at IGN Entertainment we're almost always looking for smart and curious software engineers to join our teams. Whether you're a .NET (C#), Java, or C++ programmer we'd like to hear from you. We prefer a bit of experience and a degree, but if you're one of those natural whiz kids continue reading.
Why might you want to work at IGN? I'm biased of course, but we're absolutely awesome ;). We work on a variety of applications including ecommerce, media, file distribution... we cater to heavy spikes of demand (our page loads are measured in millions to hundreds of millions per month)... we're not afraid of new technology... the gaming industry is always changing... flexible schedules, casual dress, competitive pay, good benefits, blah blah blah.
If you're not repulsed but such awesomeness feel free to contact me!
- Posted by Ian Suttle on June 17, 2008
- Filed under General
Go ahead and try to go to www.GetFirefox.com. I dare you. Insane things will happen like the server won't respond because it's being overloaded. Okay, maybe that's not crazy or insane given the popularity of Firefox, new releases, and open source community backing.
Fileplanet.com has the file available here: http://www.fileplanet.com/187938/180000/fileinfo/Mozilla-FireFox-3.0
- Posted by ian suttle on June 14, 2008
- Filed under Agile | Process | Unit Testing
Here Ye! Here Ye!
Welcome to post number two in our ongoing journey to bring an effective agile development process to IGN Entertainment.
There are a few staple tools and practices I feel are essential to an effective agile development process. Some may argue the direct correlation of these to agile development is incorrect... it's perspective.
Source Control
Love it or hate it source control is a biggie. There are a variety of source control systems available to meet the needs of most organizations. A few popular choices include Subversion, Visual SourceSafe, CVS, Team Foundation Server, and Perforce.
I recommend figuring out your source control feature requirements before choosing your flavor. Try a few before committing. Not all of them do branching, merging, changesets, etc, in the same fashion, and once you implement one it's likely not convenient to migrate to another.
Define your source control structure and processes for the team. Should code be organized by library type such as web apps, windows service, class libraries... or should it be organized by subject such as Direct2Drive, Fileplanet, etc? When should you branch vs. label? How do you version your software? If you forgo being organized up front you will pay the price later. For those of you who choose the hard way, it provides you the unique opportunity to write about lessons you've learned later on ;).
Unit Testing
I've been a part of the development community for about ten years now and if there's anything I've picked up on over the past couple of years unit testing is a contender for the most valuable. For those of you who are rookies on the topic or still haven't quite figured out what the hype's about, listen up. Unit testing provides you a certain level of confidence in your code both when you write the code and when you change your code.
Consider a monitor watching a website. Some monitors will watch the site and ensure expected behavior occurs given specific criteria. In this way a unit test is a lot like that monitor. You set up a very specific well-controlled scenario for a unit of your code (see method) and fail the check if the result isn't as expected. Each time you change your code you can rerun your ever-growing library of unit tests and be assured your tests continue to succeed. If a test is busted ya screwed something up. Oh, and as an added benefit, your class design changes to be more modular. That's just a little something extra.
Unit tests frameworks come in a variety of shiny colors. For .NET development NUnit is probably the most used. You can also check out XUnit and MbUnit. Lastly, Microsoft has developed their own framework which they've integrated in to VS2008. Feel free to argue your points but I'm not a fan of the MS Unit Test framework... there's too much auto-generated code for me. The point of unit testing is to know and control your environment. Code generation tastes bad.
TestDriven.Net is a cool add-on to Visual Studio so you can run your NUnit tests (I've not tried with another framework) and get your results in the Output window. It also comes bundled with NCover for code coverage analysis. Really useful.
Drink the kool-aid... it's yummy.
Continuous Integration
Continuous Integration in its most basic form is having your code built often on a scheduled or triggered basis. This is cool because you can know earlier than later if someone's changes are breaking the build (don't be that guy!). The alternative is having a broken build and when you have more than one person working on the code all participants are effected once they have the latest version. That's a waste of time for everyone and is frustrating to say the least. Continuous Integration doesn't prevent this problem but instead is an early warning system. Now add on automated deployments to an environment such as user acceptance testing and there's constantly a fresh view of the application without an engineering making it happen. That's cool.
My team is not using a Continuous Integration solution yet so more to come on this, but if interested, we're checking out Team Foundation Build and JetBrain's TeamCity.
How's This Related to Agile Development?
Admittedly you can run an agile development shop without any of these tools. These things I've discussed are just that... tools, not process. So how are these tools related to agile development? Everything I've discussed works really well with the iterative, always changing nature of agile practices. I'd hate to take on this process unprepared. Give me my armor, sword, and a horse before sending me off in to battle.
- Posted by ian suttle on June 13, 2008
- Filed under Process | Agile
Here at IGN Entertainment we're making an effort to follow an agile software development path. It's a bit of a new world for us. I'll admit we've described our development process to date as "agile/waterfall" or "quasi agile", neither of which are ultimately efficient. We've been digging into agile techniques for a couple of years and simply hadn't made the commitment. The longer we wait the more clear it is we need to make the move.
Our agile flavor of choice is the all-popular Scrum technique. I'm digging the predictability of feature delivery by defining the sprint backlog up front, having a known schedule for a sprint, open communication and transparency through sprint planning meetings and daily scrums, etc.
I'll continue to post info on our experience as we progress.
- Posted by ian suttle on May 14, 2008
- Filed under .NET 3.5 | .Net Framework | ASP.Net | C# 3.0
If you're like me you've often pondered why controls like CheckBoxList don't provide a way to get a collection of selected items. You've always had the option to iterate the Items collection and evaluate the Selected property, but why should that have to be done over and over again? I want a quick way to get the selected items from a CheckBoxList, ListBox, DropDownList, and RadioButtonList; all items which inherit from ListControl.
The excellent creation of extension methods makes it simple to get the selected items from a ListControl.
using System.Collections.Generic;
using System.Web.UI.WebControls;
namespace ListControlExtensions
{
public static class ListExtensions
{
public static List<ListItem> SelectedItems(this ListControl list)
{
List<ListItem> items = new List<ListItem>();
foreach (ListItem item in list.Items)
{
if (item.Selected)
{
items.Add(item);
}
}
return items;
}
}
}
Have you found an alternative to getting the selected items from a ListControl without looping through the Items collection?
.aspx&bgcolor=0099FF&cfgcolor=FFFFFF&cbgcolor=3300CC)
- Posted by ian suttle on May 7, 2008
- Filed under BlogEngine.Net
If you're a blogger you've probably heard of Windows Live Writer. If you're not, please enjoy some of the other posts on my blog :).
Windows Live Writer has been raved over on many a blog. I didn't think it'd work with BlogEngine.Net since it's not listed but alas I was wrong (again).
First impressions require two thumbs up. Writer knows about my blog, how to log in to it, how to edit and publish posts and page, knows my tags, knows my categories, and more. Very impressive.
I must say this couldn't have been so awesome without the BlogEngine.Net team implementing the communication points.
