Building a website in 40 hours, Part 3

In part 1 of this ongoing series, we looked at how you lay a solid foundation for your project with planning. In part 2, we introduced the idea of thinking with tools. That is, during the design phase, expanding your developer creativity and ability by including known features from professional .NET developer tools in your web site design.

Building Software as a Team in TFS (with Sitefinity)

There are (generally) three types of software development:

1. Individual – it’s just you and your genius code
2. Small Team – You see them. They see you.
3. Big/Multi Team – You didn’t even realize your project had code that did that

The need for source control for each of these groups is present, but the motivations are very different. Individual developers often use source control as a simple way to remember what files they’re changing between releases and to have an insurance policy against local system failures or changes that require a rollback.

As soon as you are more than one person, though, source control becomes an essential productivity booster. So essential, in fact, that even for a 2 day website project, we relied heavily on source control.

But everything wasn’t smooth sailing.

Continue reading Building Software as a Team in TFS

Use source control when you need it

Especially for a fast project with a small team, sometimes its faster to work outside of source control. What? It’s true.

Here’s the deal: when you’re rapidly prototyping and building a website, it’s usually much faster to work on your small components in an isolated, focused ASP.NET website and then add your work to TFS once you’ve got your component working on its own.

This is very true for a solution with many projects, or a solution built on Sitefinity. You often don’t need the configuration hassle or build-time of the “big project” just to work on your own sliver of functionality. And since Sitefinity is based very “cleanly” on ASP.NET, you can just use a scratch ASP.NET website and “normal” ASCX user controls to quickly build and test something like a custom module before adding it to the master project. It can save you hours.

Here’s the workflow that we used for most of our Sitefinity development:

1. Each team member had their own copy of Sitefinity and OpenAccess ORM
   (IMPORTANT: Make sure each team member has the *same version* of whatever tools you’re working with. This will save headaches later.)
2. Each team member working on custom modules simply built and tested them in their own local environment. Most team members didn’t even use Sitefinity until they had a working UserControl in a “plain” ASP.NET website. Don’t introduce complexity until you have to.
3. As custom modules were completed, they were integrated in to the “main” Sitefinity website in TFS, which was a simple process of copying ASCX files, sometimes copying some DLLs (or external libraries), and updating the web.config.
4. As major updates were ready, we would FTP all changes to the staging web server.
5. Schema changes were handled in the dev environment by the OpenAccess build step (we used forward mapping for our custom objects). To deploy them to staging, we used RedGate tools.

Be careful with Web Sites in Source Control

We had one disaster with source control that cost us a few hours during WAM weekend. Sitefinity 3.7, as you may know, uses the Visual Studio Web Site “project” type. The Web Site project is based on the file system and technically does not have a “project” file. That makes Web Sites easy to work with on their own, but they are potentially problematic when other project file-base projects are added to a solution.

It so happened that part of our team had built a couple of class libraries. Not realizing that the default items in source control for a “web site” lacked a solution file, they added the class library projects to the website. This hosed our solution file.

After a few hours of trying to clean-up the mess, we had this realization:

Source control, when used correctly, saves your team time.
Source control, when used incorrectly, can destroy your team productivity with a single check-in.

Lesson? Be careful with web sites. If you can avoid website projects, do. Web Applications are much more reliable in Visual Studio. If you can’t avoid website projects, make sure you add your other projects correctly to the solution file.

One more Sitefinity Special Consideration

If time is short, don’t add the Sitefinity folder to TFS. It has literally thousands of files. Checking those files in and then subsequently checking them out is a time consuming process. It’s actually much faster to just give each member of your team the Sitefinity folder that they can add locally for testing code from TFS.

The Sitefinity folder should be a “static” resource. You shouldn’t generally need to change the files in that folder. Upload it once to your staging site and leave it.

Eventually, you’ll want to add the Sitefinity folder to your repository so that it’s easy for new team members to check-out and work with your code, but in time strapped events like Givecamp, you may be better off following this advice.

Work Items and better teams

In 40 hours, there isn’t much time for creating work items- we relied on a big whiteboard to cover that task. In the real world, though, a big whiteboard isn’t the best way to create and track work items. TFS provides work item support, but the default Visual Studio tools for working with these items remind you that VS is a coding tool.

Enter the Telerik Work Item Manager.

Work Item Manager is a tool from Telerik that helps you be as productive with managing your work items as JustCode is at making you productive with your code. And we offer it as a free tool for everyone! If you’re working with TFS and you haven’t checked WIM out, I’d really like to know why. It’s a great way to maximize the productivity of your team…when you have more than 2 days to work on a project.

Okay. Enough boilerplate conversation. On to some of the implementation details. In the next part, I’ll talk about how CSS frameworks save you tons of time and why you should be using one. We used one. Find out which one in part 4.

Building a website in 40 hours, Part 2

In part 1, we looked at how you lay a solid foundation for building a website on a very tight timeline. Planning, no matter how long you have to work, should not be “skimped” on.

Mapping requirements to deliverables with tools in mind

Requirements communicate what your client or charity want to be able to do with their website. As a web developer, you have a few choices for how you go about turning those requirements in to a schedule of work for your team. You can:

1. Build everything by hand, delivering only exactly what is defined in the requirements
2. Use tools and services to cover requirements where they make sense

When working with users to gather requirements, especially non-technical clients or users, you often need to listen past what they’re saying and try to think about how they will interact with your features when the project is done. For example, take this simple requirement:

“We want a contact form that people can use to send us an email.”

Sounds simple enough. How would you solve this requirement?

Continue reading Mapping Requirements to Deliverables with Tools

Many developers would barely stop to think before dropping a few textboxes on a page, wiring them up to a submit button, and then sending an email with the collected info. Meets the requirement, but is it enough? Is that what the evolved professional .NET developer should be delivering today?

Thinking with Tools

When you have a professional developer toolbox, you gain an entirely fresh perspective on what can be accomplished in a project with limited time. In our example above, a toolbox lets us say during the design phase:

The users want a contact form. Easy. We can not only deliver a contact form, we can deliver a form, with validation, that can be edited at any time using a simple, visual form-editing tool, that can even be reused for any other data collection purpose on the website.

In short, tools turn “No’s” in to “Yes’s” at not extra cost to your project.

Can we edit the forms on our website? Yes. (Embedded WuFoo forms)
Can we export all of our data to Excel, Word, and PDF? Yes. (Single property in RadGrid, RadEditor)
Can we crop, resize, and rotate our images? Yes. (Built-in RadEditor Image Manager)
Can we have a attractive charts for our data? Yes. (Charts for Silverlight in ASP.NET)
Can we have localized versions of all our pages? Yes (Built-in Sitefinity feature).
Can we have unicorns fly off the screen? Yes…err…no.

When you have tools you know how to use, and you understand the capabilities of those tools, you can deliver way more than expected to your clients. And since tools, like Telerik’s Premium Collection, make it easy for you, the developer, you can spend more time polishing the custom features tools don’t cover.

Designing with Tools

Now that you’re thinking with tools, you go a step further and design with tools. Instead of  designing in loose terms, you can plug-in specific tools with known capabilities and quickly get past basic scenarios. Features previously considered “extra effort,” are now “free” because they’re automatically provided by a tool. Or, at least, free to you.

Context menus.
Filtering, sorting, paging, grouping, hierarchy.
Client-side binding for desktop-like performance.
Rating controls with client-side APIs.
Word-like editing in the browser.
Scheduler with day, week, and month views and drag/drop support.
Captcha validation for forms.

Just as the wide availability of light fixtures, doors, windows, and home automation systems frees an architect to design a more impressive house, tools for .NET developers help you build better software.

Challenge

Next time you start designing a project, try thinking with the Telerik Premium Collection. Review the online demos now, get a sense for all the features built-in, and then watch during your design phase how many places you can quickly improve or enhance a feature with built-in tool features. It will feel like cheating, but it’s not.

Tools used during WAM

To build our charity’s website, we relied heavily on tools to provide superior experiences and to maximize the amount of control we could put in non-technical users’ hands. We wanted to make it possible for non-technical users to have the power to update almost any portion of the site after the project shipped- from email templates to the site header and footer.

Tools we ended-up using:

• Sitefinity
  This was the huge platform time saver. More than half of our team had never developed with Sitefinity before the 40 hour dev sprint began. Two of our team members had only casual experience with ASP.NET. We still delivered incredible results in 2 days, as did all other teams (there were more than 10) that used Sitefinity that weekend. Right out of the box we were able to give our users control over pages, content, templates, and permissions. And with a simple Module system, we quickly added custom business process support, support for customizing email templates, and many helpful page controls for performing tasks like embedding YouTube videos on a page.
• RadControls for ASP.NET AJAX
  The RadControls actually ship with Sitefinity, so it was natural to use these to extend our website. Built-in features like exporting to Excel and RadEditor’s Word-like content editing gave us quick wins in our project.
• OpenAccess ORM
  We wanted to be as productive working with our custom data as we were with our UI, so we used OpenAccess ORM for all our custom modules. Again, half of our team was new to this tool on day one, but working productively within hours.
• WuFoo
  Cool service that let’s non-technical users build and edit forms that can be embedded in a website. We used this service to empower our users to have unlimited control over forms in the future.
• Kimbia
  Our charity wanted to accept donations, and they didn’t want to use PayPal. Kimbia is like a specialized PayPal service focused exclusively on helping sites collect donations.

Now that we’ve finalized our requirements and completed our design, with tools helping us deliver on our ambitious 2 day goals, it’s time to start coding. In the next part, we’ll talk about building websites as a team in TFS.

Building a Website in 40 hours, Part 1

Welcome to the first part of a multi-part series on Telerik Watch describing the process for building an impressive website in 2 days. In this series, I am going to share tips and tricks, along with some real world stories, for building a high-quality, usable website that supports critical business processes in less than 48 hours (if you’re working on WAM Weekend Time).

The purpose of this series is two-fold:

1. If you’re going to participate in a Givecamp, this advice should help your Givecamp team deliver incredible results in the short 2-day period you have to work
2. If you’re just interested in comparing your website building process to someone else’s, this series may highlight ideas and approaches you’ve overlooked in the past

Along the way, I’ll highlight best practices for building standards-based websites, different tools and frameworks that “Team Telerik” used at We Are Microsoft 2010 to be successful, and, of course, how the Telerik tools helped us do weeks worth of work in two days.

Let’s begin…

Continue reading Building a Website if 40 hours

Pre-planning

If you’re going to participate in a Givecamp, or meet with a client for that matter, you need to do some pre-planning. You need to do some research about the people you are about to serve and try to understand their motivations, their expectations, and- critical for web development- where they’re coming from with their existing website.

The goal of pre-planning: create a list of intelligent questions.

If you can have a focused list of questions prepared for your first meeting with your charity (or client), they will have infinitely more trust in your ability to deliver high quality results. It’s like a job interview. A good interview may get you the job, but a great interview will get you the job and a signing bonus.

Requirements

There is very little I can offer on the subject of effectively gathering requirements that has not already been archived somewhere on the web. What I can say is that even in the environment of a Givecamp (or any other time constrained project), detailed requirements gathering is critical. Make sure you spend time getting answers to your pre-planning questions and really try to understand the key goals of your client’s project. Charity or not, failure at this step makes everything that follows much harder.

How much time should you spend on requirements at a Givecamp?

This will obviously vary by team and charity, but Team Telerik did not start touching code until nearly 10:00 PM on day one. We spent a solid 4 to 5 hours meeting with our charity, discussing our objectives, and mapping out our requirements for the weekend. When all was done and said, we had a huge whiteboard that defined our key deliverables, and that served as our road map for the weekend. It also served as the informal contract between our team and our charity for what would be delivered by the end of the weekend.

From our high-level objectives, we started mapping out the specific features and actions that our website would need to support. We also started to identify the tasks that would require extra research or the features that would “Nice to Haves,” but maybe not feasible in 40 hours.

Time to start coding? Nope. Not yet.

Work Smarter, Not Harder.

Now that your requirements are clearly defined, you need to start planning for the execution. Some developers would suggest that means you’re at the point where you start writing tests or code, but if you’re a “work smarter, not harder” developer, that means you want to fully evaluate the tools, services, and frameworks that already exist and that can help you do more in less time.

A great developer does not write every line of code in an application by hand. A great developer knows how to find and use great tools, only writing code where it creates unique value for the project.

With that in mind, stay tuned for part 2: Mapping requirements to deliverables with tools in mind.

WAM 2010 Wrap-up

It's been over a week since I posted the "wrap-up" thoughts from Day One of our 48-hour WAM weekend. So I think it's time I provide some follow-up "event wrap-up" thoughts and comments. First, let me say that I had every intention of blogging more during the event. But after 40 hours of head-down programming and a few hours of sleep, the mental clarity to blog drifted away. Hopefully you kept-up with the action on the Telerik Facebook page where I posted some exclusive video updates. One update in-particular captures the hazy sensation of developing on a lot of junk food and little sleep! Team Telerik did an incredible job, though. I set an ambitious set of goals for 48-hours of requirements gathering/planning/design/implementation, and the team rose to the challenge. It helped that our charity, We Help Ourselves (new website will be live very soon), also had ambitious requirements. In a single weekend, we delivered a platform that empowers their non-technical staff members to completely control the WHO website- from page content to email templates- while simultaneously automating two of their most critical business processes. Like I said: ambitious. We owe much of our success to the Sitefinity platform and OpenAccess. These tools gave us the head-start we needed to focus on development instead of infrastructure. In fact, Sitefinity powered many of the weekend's charity website re-builds. No fewer than 10 teams (out of 20) used Sitefinity, and all seemed to achieve high degrees of success. I think there were even a few teams so discouraged by their first CMS platform choice that they switched to Sitefinity half-way though the weekend. That means they built their sites in just 24 hours! Needless to say, it was an exhausting event, but well worth the effort. I will be blogging over the next few weeks in more detail about the process we used to achieve success in 48 hours, which will hopefully produce some guidance that will help you be successful on your next project- which you hopefully have more time to complete! Want to try your hand at this event and give back to your local community? Look for a Give Camp near you (only Dallas- the original- uses the We Are Microsoft name) and get involved. If you use Sitefinity, let us know so we can feature your story and results!

WAM Update: Close of "day" one

We Are Microsoft is underway and "day" one is drawing to a close. It's 6:30 AM local time now, and we've been going hard since 3:00 PM yesterday. We're excited by our progress and the advantage that Sitefinity has given our project, but we know much work remains if we are to satisfy all of the goals of our charity. Just to keep you, dear well-rested reader, up to speed, here's the last 16 hours in summary:

• About 2 hours spent covering WAM "basics" in the previously blogged kick-off meeting
• We then spent a solid 2 hours talking with our charity (WHO) and refining their requirements
• Over a 45 minute dinner break (of cold pizza), we turned the refined requirements in to an action plan
• We reunited with our charity to present our plan of action, cover last minute details, and then it was off to the races. Time: 9:30 PM.
• From 9:30 PM to what is now closer to 7:00 AM, we've been doing everything from designing CSS to building HTML to building custom Sitefinity user controls and modules to integrating 3rd party services (like Kimbia, a new service our charity introduced us to that helps with accepting donations)

And that's day/night/morning one! Well, other than the blogging and videos, of course. There are already 3 or 4 exclusive videos on the Telerik Facebook page from WAM, and many more will come before the weekend is done. Check 'em out and stay tuned for more updates.

Charity Weekend Kick-off

Team Telerik is in Dallas and getting ready to kick-off a weekend of intense charity and web development. As I type, the kick-off meeting is underway and more than 75 developers are being prepped for what lies ahead. In a few short minutes, teams will break, meet with their charities, and start the 48-hour push to the 2:00 PM Sunday delivery.

Team Telerik is here serving double triple duty:

• We're training the many teams using Sitefinity CMS
• We're capturing lots of video for Telerik TV and Facebook
• We're building a site for a charity!

Our 5-person team will be blogging throughout this process, capturing the process of building a website from beginning to end with Telerik's tools. We'll publish these posts over the next week so you can learn from (and critique) our process.

And remember: we'll be capturing special video content exclusively for our Telerik Facebook page! If you're not a Telerik Facebook Fan, this weekend is a great time to become one so you can enjoy our extra content.

That's all for now. I'm off to find some caffeine and start the development clock.

[P.S. Most of us are on Twitter, too. Follow my weekend updates @toddanglin.]

We Are Microsoft Charity Wrap-up

I just got back from the We Are Microsoft Charity Challenge Weekend- or WAM Weekend for short- and I'm happy to report it was a huge success! There were almost 20 teams of developers building sites for charities in the Dallas area, and it was great to see everyone work so hard over the weekend to produce some incredible sites. Many of the teams used Telerik's Sitefinity CMS to give their charities even more functionality and to save a ton of development time, and based on the training Gabe Sumner and I did on Saturday, the charities are very impressed! One team also used the Telerik RadControls for Silverlight to add rich gauges to their charity's site. Along the way, Gabe and I sat down with the event's "video bloggers" to talk a bit about the weekend and Telerik's involvement. You can check out the embeded video above or watch the original directly on Facebook. All-in-all, it was a great event for the .NET community that will have a huge impact on the charities that were involved. Hopefully this type of event will spread throughout the .NET community in 2009, giving you the opportunity to use your developer "skills" for a good cause, too.

P.S. As soon as I have a full list of the sites built with Sitefinity, I'll post an update on Telerik Watch so you can see the end results of the weekend's work.

Join Telerik at WAM Charity Weekend

One of the great things about being at Telerik- and the part of .NET community in general- is the pervasive sprit of charity and the desire to give back to the community at large. As programmers, we may not be able to donate our time to build a house, but we sure are good at building software. The We Are Microsoft (or WAM) Charity Challenge Weekend picks-up on that idea and hosts a 3-day "challenge" where .NET developers join teams to build websites for charities in the Dallas, Texas area. Telerik was a proud sponsor of this event in its inaugural year, and we are again sponsoring this charity event in 2009.

But beyond sponsorship, Telerik is also making the Sitefinity CMS platform freely available to volunteer developers to help jumpstart their charity web sites. The ability for these developers to pick-up, learn, and extend Sitefinity during the 72 hour competition is a true testament to Sitefinity's "natural" fit with an ASP.NET developer's skills. To help developers maximize the platform this year, Sitefinity Evangelist Gabe Sumner and I will be traveling to Dallas to help train both the volunteer developers using Sitefinity and the end users from the charities that will be inheriting the site at the end of the competition.

If you're in the Dallas area this weekend, stop by and see the charitable side of the .NET community. In fact, if you hurry, I'm sure you can still volunteer to help out. Either way, Telerik is proud to sponsor this event and we look forward to seeing charities benefit from what the volunteer developers can do with Sitefinity!