Tag Archives: work

Coding is Creativity

31 Friday Aug 2012

Posted by in On Technology

≈ 1 Comment

Tags

,

I was having a discussion about great literature the other day, and something that was said struck me as very applicable to software development.

“How did he build an entire world out of what was in his head?”

We were talking about Tolkien, and were both impressed with the breadth of material he created.  Sure, he wrote the Hobbit and the Lord of the Rings.  But supporting that was the creation of a couple of languages, most notably Elvish, and books of foundation legends.

The same could be said of music and art.  How does someone take what they see in their mind, and bring it forth into the world for others to enjoy?

I like to consider myself a writer, and since I have a book published at Amazon, and have even received a small check from its sale, I guess that makes me a published writer.  I am also a software developer, and have created applications for personal use, sale, and at the direction of clients.  You may think that on the surface, the two have nothing in common.  However, I have found that they are very closely related.

The Idea

Both a great story and a great application begin with an idea. The idea phase is exhilarating and freeing. There are no boundaries, no road blocks and no constraints.  Your imagination runs wild over what you could make and what you could do with it.

The Implementation

Once the idea is decided upon, a story and an application take planning.  There are some writers, and some coders, that can hop right into the details.  I’ve read a book on Stephen King’s writing process, and he’s fortunate enough to be able to watch the story unfold as he writes.  For me, I write like I code. I plan it out.

That’s the first step in implementation. Then I start coding the large portions of the application or outlining the different plot devices and characters. It’s in this phase that I see the full scope of what I envisioned, and start to give myself constraints such as time, cost, or word count.  Working with constraints inspires more creativity.  How can I finish this in a weekend?  How can I keep it under 100,000 words?  The constraint drives good design.

The Details

When writing, the difficult detail for me is creating believable dialogue. I can write fight scenes all day, but crafting discussion between characters is not easy.  In code, it’s often all of the small items, like the UI for the user signup screen, the retrieve password code, or making sure all the possible iterations of interaction are covered and tested.  It’s where the project is no longer fun every day, and the only way through is to roll up your sleeves and to keep moving forward.

The Payoff

Once my website is live, my application is released, or my story is in front of readers, the feeling is the same.  Relief that it is done, pride that my idea came to life, and concern that others will treat it with the same love and care that I did while building it.

Writing great code is an art, and one that is beginning to receive the recognition it deserves alongside literature, music, and art.

Advertisements

Scheduling is a breeze (Thanks to LiquidPlanner)

24 Friday Aug 2012

Posted by in On Technology

≈ Leave a comment

Tags

, ,

Back in February, we were buried under a mountain of work.  It’s not a bad problem to have, but it sure made for quite the logistical nightmare.  It was not easy to schedule dozens of projects for dozens of team members and still make sure we hit our deadlines.

I wrote about the problem at that time, and a small sliver of hope that had appeared on the horizon. That sliver of hope is called LiquidPlanner.

lp

We have been using LiquidPlanner since February, and it has significantly streamlined our process.  Instead of juggling a calendar for each team member in Google Calendar, we just assign tasks to a team member, put a low and high estimate for how long it should take, and let LiquidPlanner handle scheduling the project.  It’s easy!  The whole team participates in project management now because they can see all of the tasks assigned to them and how it affects the schedule.

Instead of using Basecamp to handle messages, to-dos and file management, LiquidPlanner handles that too. Tasks are central to LiquidPlanner because they drive the schedule. It also allows us to comment on tasks, add messages, and work with clients.

As an added bonus, we can track our time against a task.  So, we’ve eliminated our home grown time tracking system and instead track time directly in LiquidPlanner.

LiquidPlanner is not all rainbows and unicorns.  There are a few things that were nicer in our previous systems, or could use some improvement.

  • The upcoming schedule is not as easy to read as Google Calendar.  They do a great job handling a LOT of data, but it takes time to get used to.
  • Communication is not as nice as it was in Basecamp. The biggest issue is not being able to tie files directly to a comment. 
  • If I assign a restricted member to a task in a project they don’t have access to, they should automatically be added to the project.  Too often we have tasks that people can’t see.
  • Pricing is per user, so it can get pricey.

But in the end, not having to use 3 different systems, and scheduling that is WAY easier makes LiquidPlanner a no-brainer for us.

If you have lots of projects that need to be schedule across many different resources, and you are tired of using MS Project, or cobbling together multiple systems to try and create something useful, give LiquidPlanner a try!

Aaron Brander is the VP of Technology for MINDSCAPE at Hanon McKendry.

Code Collaboration or (Subversion isn’t always Subversive)

11 Wednesday Jul 2012

Posted by in On Technology

≈ Leave a comment

Tags

,

Have you ever attempted to work on a Microsoft Word document with friends?  You created the document, emailed it to six friends, and suddenly found yourself struggling to merge all of the different changes that came back to you.

It’s a nightmare.

If so, first off, it’s time to leave the Office and move to Google Drive.  It’s a great way to collaborate online, in real time, on documents and spreadsheets.  I use it when I write stories and blog posts in my spare time, and for all of my work documents too.

This post, however, is not about how to plan your vacation with six friends by using Google Drive.  This post is about how multiple programmers can work on the same project at the same time.  In its simplest form, it is two programmers sharing one content file, much like working with a friend to edit a Microsoft Word document.

At its most difficult, it is multiple teams of front and back end coders working on thousands of files in a project.  Do you want to be the person to merge all of those files by hand as changes are made?  Nope, neither do I.

That’s where subversion comes in.  No, not subversion, the attempt to overthrow structures of authority.  The subversion I am talking about is a software versioning and control system.

We did not always use subversion at Mindscape. Originally, we used the FTP server functionality that came with Dreamweaver.  It allowed us to check out a file from the server.  If someone else tried to checkout and work with the file as well, they were told that it was in use.

It was alright when there was three of us. Sure, sometimes a person would ignore the lock and work would get lost. Or someone would forget to check a file in before going on vacation, and we had to wait for them to get back and unlock it.

As the team grew, those mistakes happened too often. That’s where subversion came in.

A very trimmed down explanation of subversion would be that there is a machine that controls the repository that all the files come from.  Users can get files from the repository.  On their machine, a subversion client keeps track of changes made to those files.

When the user checks the files back in, the server compares the changes to the what it has. If there have been no changes since the user started working, it just applies the changes. If someone else made a change first, the server will attempt to merge the changes together.  Mostly it works great, but sometimes it cannot merge it for you. In that case, the users are notified and have to manually merge the changes.

At Mindscape, we use a software service called Springloops to manage our repositories. It was easier to set that up then to learn how to administrate our own server. It has the added benefit of being able to deploy sets of changes to our development and production servers. It’s actually been a great tool for us.

On our computers, many of us use Tortoise, a free subversion client that keeps track of file changes locally. It’s easy and integrates directly into Windows.

Utilizing subversion, we are able to have multiple people working on a project at the same time. We can use the logs to go back through and see each change that happened, when it happened, and who made the change. It’s a great way to see who built a feature, and just as nice to figure out who to blame for a bug!

It certainly beats emailing files back and forth and trying to have a person manage merging them together.

Aaron Brander is the VP of Technology for MINDSCAPE at Hanon McKendry.

The Internet is Down (or How did we ever live without it?)

29 Tuesday May 2012

Posted by in On Technology

≈ Leave a comment

Tags

,

The internet is down in the office.  My productivity just came to a screeching halt.

The code I was writing in Visual Studio? Turns out I was connected to our development server’s database, so I can’t test my code without the Internet.

Check my email and work on that? I work in Gmail all day, and don’t have a way to access it offline.  Without the internet, I don’t have any email.

Ask a co-worker if they have Internet? Not feasible.  Google Chat is down when the Internet is out, so no instant messaging.  Use my voice to ask?  That’s just barbaric. Instead I’ll take off my headphones, I can’t reach Pandora anyway, and stare at the expensive brick in front of me.

Check Facebook or ESPN while I wait for the Internet to come back… oh wait. That’s on the internet too.  I’d watch some TV while I wait, but I stream that through Hulu and Netflix.

No work, no email, no music, no diversions.  What’s left? When did our lives become so dependent on the Internet?  I’d go outside, but without weatherchannel.com, how will I know what it’s like out there? Should I risk life and limb and step outside unprepared? I think not.

I thought I’d write this blog, but I use Google Docs and those need online access too. It took some brainstorming, but I realized that I had Microsoft Word on my computer still and that I could type this blog up there. Whew, something I could accomplish.

I guess I could have used pen and paper, but I’m not even sure where I could find it!

Oh, wait.  The internet is back! Sweet. Now I can post this blog and get back to work!

Aaron Brander is the VP of Technology for MINDSCAPE at Hanon McKendry.

Request.URL–what’s that property?

24 Thursday May 2012

Posted by in On Technology

≈ Leave a comment

Tags

, ,

Request.URL can be used in .NET to get the value that the web browser used to access a page. However, there are many different properties to choose from, and sometimes it is difficult to know which property to use.

I tired of guessing at the correct value and decided to write a small bit of code to display all of the properties so I could find the correct value faster next time.

Here’s what my code looks like:

Imports System.Reflection

Partial Class Tests_requestURL
    Inherits System.Web.UI.Page

    Protected Sub Page_Load(sender As Object, e As System.EventArgs) Handles Me.Load
        Dim info() As PropertyInfo = Request.Url.GetType().GetProperties()
        For Each a As PropertyInfo In info
            If a.CanRead Then
                Me.ltlValues.Text &= String.Format("{0}: {1}<br><br>", a.Name, a.GetValue(Request.Url, Nothing))
            End If

        Next
    End Sub
End Class

The code uses a bit of reflection and I am sure can be helpful for figuring out the properties of any other object.

For this url:

http://train.mindscapesolutions.com/tests/requesturl.aspx?query1=test&query2=test

The output is:

AbsolutePath: /tests/requesturl.aspx
AbsoluteUri: http://train.mindscapesolutions.com/tests/requesturl.aspx?query1=2&query2=3
Authority: train.mindscapesolutions.com
Host: train.mindscapesolutions.com
HostNameType: Dns
IsDefaultPort: True
IsFile: False
IsLoopback: False
IsUnc: False
LocalPath: /tests/requesturl.aspx
PathAndQuery: /tests/requesturl.aspx?query1=2&query2=3
Port: 80
Query: ?query1=2&query2=3
Fragment:
Scheme: http
OriginalString: http://train.mindscapesolutions.com:80/tests/requesturl.aspx?query1=2&query2=3
DnsSafeHost: train.mindscapesolutions.com
IsAbsoluteUri: True
Segments: System.String[]
UserEscaped: False
UserInfo:

Java, JavaScript and jQuery (Or What’s With All the J’s?)

13 Friday Apr 2012

Posted by in On Technology

≈ Leave a comment

Tags

, ,

Technology is full of confusing terms, and building websites is no different. As a developer or as a person in need of a website, you will no doubt encounter a number of acronyms and words that you either don’t understand, don’t want to understand, or that just plain make you want to cry a little bit out of sheer frustration.

DNS? PHP? .NET? IIS? Apache? Joomla? Drupal? CMS? IE? FF?

The list grows longer and your attention span grows shorter. I’ll not bore you with all of the acronyms now, I’ll just save that for another post. Instead, I want to shed a small ray of sunshine upon a dark corner of confusion.

What’s the difference between Java, JavaScript and jQuery?

Java

Let’s start with what Java is not. Java is not coffee; you won’t find it at Starbucks.

Java is not a populous island nation in the Indian Ocean; at least, not the Java we are talking about.

Java is a programming language developed in 1995 for Sun Microsystems. Its main purpose is to be able to run on all different types of operating systems. In other words, a program written in Java can run on a Microsoft computer and an Apple computer. All you need is to download the Java run-time to your computer and you can run any Java applications.

Java can be used on the Web, but I haven’t seen an example of a site using Java in a long time. If someone is telling you they’ll build your website using Java, they probably mean JavaScript.

JavaScript

JavaScript is not Java, just like tea is not coffee and Bermuda is not the same as Java the nation. Beyond some superficial similarities in syntax (the words and symbols used to write the code), Java and JavaScript are quite different.

JavaScript is built to run on the Web. How it executes and how well it performs is dependent on the type of browser you are using (Check out this website to help you determine: What is a browser?).

JavaScript was decried, denigrated and dismissed by many programmers for years, including myself. The relatively recent rise of “fancy” websites that update quickly without reloading a page (Ajax or asynchronous JavaScript execution) has brought JavaScript into prominence, and has even made an old hater like me at least acknowledge its importance.

If a salesperson is talking to you about using JavaScript to build something on your website, they are probably talking about implementing some sort of “fancy” interface feature to make the site more appealing to your visitors.

jQuery

Finally, we come to jQuery. jQuery has nothing to do with questions. In fact, it answers a lot more questions than it raises. jQuery is a library of functions that uses JavaScript. It is like using the phone instead of sending a telegram. It is like sending a text instead of using the phone. It is like using GPS navigation instead of an old, paper map.

jQuery is what made it palatable and fun to start using JavaScript again. It is the most popular JavaScript library in use today, and if you are building a site you should be using it. If you are having a site built, when the sales person talks about JavaScript, it is almost certain that the developer will be utilizing jQuery to make it happen.

So there you have it. Java, JavaScript, and jQuery, now clear as mud for you!

What is a Technical Design (Or Why You Need a Blueprint)

30 Friday Mar 2012

Posted by in On Technology

≈ 1 Comment

Tags

, ,

Have you ever had a house built, or an addition added to your house? Did it go like this?

*****

“Good day, Mr. Architectman, I would like you to build a home for me,” Chris VonClient said.

“I would be happy to help, Chris. How big do you want the house to be?” Andy Architectman responded, tilting his head to the right so that he could hear Chris better.

“I was thinking we needed three bedrooms and two bathrooms. So I don’t know, two thousand square feet?” Chris was not really sure what he wanted, but he had a vague picture in his mind.

“Two thousand square feet, eh? Hmm. Yes. I can see it now. That’s enough for a big kitchen, vaulted ceilings, a den in the basement, a living room upstairs. Wait, you do want a basement, right?”

“Oh, that’s a great idea, Mr. Architectman. A basement is just what we need!” Chris was excited. He could see the house better already.

“Alright then. We can get started next week. How’s $150,000 sound and we’ll be done by September?” Andy was quite sure he knew exactly what Chris wanted.

“Perfect! Thanks Mr. Architectman!”

*****

I am hopeful that when you had your home built, it did not go this way. Somewhere in this process, Mr. Architectman built out a full blueprint for the project, perhaps even with visual aids like a 3D rendering of the home so you could walk through it.

Unfortunately, too many software projects are treated like the short story above. With a few descriptive words about the project, the developer is off and running and the client is left to wait for the project to be done.

Honestly, we have done projects this way at MINDSCAPE in the past. It was a long time ago, but still it happened. It was fairly standard practice in the software industry. There are two main ways to protect against this.

The first way is something called agile development. You can go ahead and look that up on Google if you would like, but basically it means that we work directly with the client through all phases of the project. The client asks for something small and we will deliver in a week or two. That thing is then evaluated, changed as necessary and we start work on thing two. It’s a great way to make sure the client gets what they want; but it has two downsides:

1) It is time intensive for the client. We’ll need your ear and your mind a lot of the time during development. That could be a month to a year of work, and not many clients have that time.

2) We don’t know how much it will cost because we are working collaboratively on it. That means we end up charging for all of the time we put into the project. Not many clients are willing to engage in that agreement.

So, we have taken the idea of agile development and married it to a more traditional process. Once we get to development, we make sure the client receives regular updates of what we are building and they will get to play with the software as we work. We do this by breaking up a large development into multiple milestones.

But to get to development, we first have to build the blueprint, and that’s where technical design comes in. There are three benefits to the technical design.

1) The client and the developer can look at words and pictures and sometimes even partially functional prototypes to make sure we see the same ideas.

2) The developer has a better understanding of what the client wants and how long it will take to build.

3) The client can take the technical design and have it quoted by other development companies. Sure, we’d like to have their business, but the technical design ends with a solid deliverable that will give other development shops a solid way to understand the project quickly.

So what does a technical design include? Much of it will depend upon the scope and complexity of the project, but it will always include one or more of the following:

Feature List

This is present in even the simplest design documents. It lists out the features that are needed with a description of what the feature does.

Wireframes

Often, we’ll pair the feature list with a visual representation of what each page may look like. This is not intended to be a final design, but rather a way to communicate how the feature will flow and look on the page. We often use a program called Balsamiq to help this process. Here is what a Balsamiq mockup looks like.

Prototypes

Sometimes, it is necessary to model interactions or complex use cases in a more dynamic way. In this instance we will build out a prototype. This allows the client to play with the proposed solution instead of just reading about it or seeing a picture. This is helpful when there is a lot of animation or fancy user interaction with the application. It is not the final solution, as it will not have any data or logic tied to it, but it is helpful for showing what the application should do.

No two technical designs are ever the same as we tailor it to the client, the project and the scope of work to be completed. However, the technical design should make the requirements clear to the developer and the client, should allow the developers to create a reasonable estimate of work and give the clients a deliverable that they can shop to other developers.

And it’s just a good idea to build a house with a blueprint and not an ambiguous conversation.

The Devil is in the Details

26 Monday Apr 2010

Posted by in On Technology

≈ 2 Comments

Tags

, ,

I am a programmer and a project manager.  The company I work for builds websites. In my experience, 95% of the job is pretty easy. That is not to say that anyone can do it – I know there are things during the website process that I cannot pull off.

Front end HTML is difficult for me.

Sales – You can keep that for yourself.

Design?  That one is nigh impossible unless you also think purple and green go well together.

There are members of our team that handles those tasks very well.  I, in turn, find it a far better fit to program business logic, design databases, and organize the team to complete their tasks.  Over the last several years when I have been the Project Manager at Mindscape, we have been able to standardize and create processes for just about every aspect of the website creation process. We have become more efficient and less prone to mistakes.  We strive to get better every day so we can deliver the best project possible.  But there is one area that refuses to be completely processed away.

The Devil is in the Details

The Devil is in the DetailsI love details, to the point where there are times where I cannot see the forest for the trees and I have to remind myself to step back and take a longer look at where we are going.  Even with a love of details, it is difficult to keep track of the thousands of details that come up even on a small project.

To help in the task, we use a product called Basecamp from 37 Signals.  We have templated ToDo lists that we add to each project.  Doing so gives us a firm foundation to work from, and helps us know what major items need to be accomplished for each task.

And with those major items, we are rolling along right now.  We get through 95% of any project without difficulty.  It is that last 5% that presents problems. The small details that may not be visible for a while but can come back to bite you if no one is aware of them.

Most of our clients do not work on the web for a living. They have an idea of what they want to do, but no firm grasp on how that is to be accomplished.  We have to take care of the details they know they want, while also taking care of the details that they have no idea they need. These details can come up in any part of the website process, and it is our responsibility to look for them.

It can happen in sales – We’ve seen similar situations to what our client is asking for, so we know what we can do for a client that will work well and the client has not considered.  It is up to the sales team to identify these details and present them to the client.

It can happen when doing a website strategy for a client – Identifying something the client isn’t currently doing can have a huge impact on their business.

It can happen in design – Pulling together the items the client asked for, and still creating a site that looks great and accomplishes everything and more is a difficult art.

It happens in HTML and programming – The client doesn’t have an idea what goes on here. But watching out for every possibility, and making sure it always works no matter what happens, is the cross we must bear.

It happens in support – taking the time to figure out what’s going on and explain the issue clearly to clients is key. It is even better when we can anticipate the problem or go above what is being asked.

During any of those stages, a thousand details come up that need to be recorded and remembered in order to pull off the impressive things we do.  Basecamp ToDos is the tool we use to track this. When something comes up that must be remembered or done by someone else, we put it in Basecamp and make sure it is assigned to someone.  The assignment feature in Basecamp is a lifesaver.  Our team can filter out all the tasks that are assigned to them and see the day it needs to be done by.

Everything works great, as long as each team member keeps an eye out for the details. Did that link get connected? Did we assign a Google Analytics account? Did we remember to put in the call to action the client wanted on the home page?  Wasn’t that form supposed to have two address fields?

Often, when a team member completes their portion of a task, it still is not complete. It needs to be sent to another person on the project. Again, Basecamp ToDo’s come in handy.  The first team member adds in a comment, and then reassigns the task to the next one in line.

The process works great when everyone is on the lookout for those devilish details.  It can be a hard thing to anticipate every request, the hidden things each request represents, and still remember to link up every page, replace all of the insidious Lorem Ipsum that can find its way into the site during testing, and make sure the pixels line up the right way in Firefox, Chrome, Safari, IE 8, IE 7 and that horrible monster – IE 6.

If you don’t use it already, I suggest you try out Basecamp. It’s a flexible way to manage projects.

How do you manage the details?  I’d love to hear your views on it.

Vegas, Baby! – Microsoft Developer Conference

19 Monday Apr 2010

Posted by in On Technology

≈ Leave a comment

Tags

, ,

Vegas, baby! I had the opportunity to attend the Microsoft Visual Studio 2010 and ASP.NET 4.0 Launch conference in Las Vegas from April 12-14, 2010 (http://www.devconnections.com/shows/SP2010ASP/default.asp?s=142).  I thought I’d post a few technical and travel notes from the conference for those of you (and I imagine that’s most of you) who couldn’t make it.  Let’s do a Clint Eastwood theme for this blog: The Good, The Bad, and The Ugly

Work Stuff

The Good

  • The Keynote address on the first day was held in the Grand Ballroom at the Bellagio. It’s a huge room and there were a lot of people in attendance to see what was going on with Visual Studio and ASP.NET 4.0. Here are a few quick items from my notes:
    • VS has a lot of new improvements for efficiency like intellisense for jQuery, code visualization features to get a sense of a project and dependencies from a high level, improved debugging and profiling help
    • A bug assignment process that lets a tester record their process, and the developer to debug the exact process the tester went through
    • Some new controls including a chart control
    • Windows 7 Phone, MVC, and Sharepoint are more closely integrated with Webforms and Winforms. If you can program in those technologies, you can do it in other the other .NET technologies
  • Later the first day there was a great “What’s New” class.
    • Viewstate optimization: Now you can turn View State on and off by control to reduce the overall size of Viewstate on a page.
    • Client Ids – no more weird, VS named controls. Now you can determine what you want the IDs to be.  Great for new applications, but may prove difficult to update your existing controls
    • .NET controls now generate standards based, css friendly HTML. That’s a big difference from the table based junk that used to be generated by controls such as the list and grid view.
    • URL routing is supported out of the box.  We’ve built our own custom FileNotFound based URL routing already. I’m not sure if it would be worth the hassle to rewrite the entire platform, but it may make some file or product specific URL handling easier on our webTRAIN platform.
    • HTML Encoding shortcut. Replace <%= with <%: and everything within the brackets will be HTML encoded automatically.
    • Built in Charting controls. Sweet! This was released as a separate component in 2008, so some of you may know it already. Now it is a standard part of Visual Studio. (http://www.4guysfromrolla.com/articles/072209-1.aspx)
    • Editing box – an easy way to edit multiple rows at the same time. (http://msdn.microsoft.com/en-us/library/dd465268.aspx)
    • Navigate To – no more copying a function name and then using the Find command on the entire project to see where it is in use. Now you can use the Navigate To feature to display all methods and events in the project. Just start typing and the list will auto update. Click on a result to go to the correct spot in the code. Nice!
    • Ajax 4.0 and jQuery are now more tightly integrated. When you create a new project in Visual Studio, it will import in the jQuery library so you can get started right away.  It also includes baked in intellisense for jQuery. The jQuery is actually interpreted on the fly and the intellisense adjusted to the appropriate context.
  • Having very little jQuery experience myself, I learned a lot of jQuery basics at the seminar. I don’t think I’m scared of it anymore! I think it’s time to start dabbling in it and see what I can do.
  • The Bellagio is amazing!  (http://www.bellagio.com/)
  • The Geekfest that Microsoft hosted at the Jet nightclub was pretty amazing.  Check the travel report later this week for more information on it.

    The Bad

    • There were a lot of jQuery and Ajax sessions on the schedule, and Jason and I were keen to take in them all. However, after the first day, they all started to be the same. We were hoping that they would get more in depth; in fact, one of the Visual Studio tracks had a multi-session desktop course that looked like it went pretty deep.  That wasn’t the case with Ajax. Jason, a seasoned jQuery user and early adapter of VS 2010, learned a few things, but mostly the sessions served to give him more confidence that he was doing things the right way.
    • We needed a backup plan and didn’t have one.  We kept trying more and more Ajax and jQuery courses and finding that most of the material was repeated.  At one session, a presenter told us we may as well leave if we had taken a particular course earlier in the day.  We checked our notes, saw that we had been said course, and headed to lunch early. A deeper coding experience would have been nice. It looked like it worked that way on the schedule.

    The Ugly

    • It only happened once, but there was a presenter that was so poorly prepared and such a bad speaker that we actually left the course early. I didn’t like having power point slides read to me in college, and it turns out I still don’t like that.  Luckily (or unluckily, depending on how you want to view it), the same material was covered in the next session we went to.
    • The last day of the conference was very light on content that we were interested in. It made for a very long day.

    So what did we learn?  Visual Studio 2010 and .NET 4.0 have a lot of great tools that we are looking forward to using. We also learned that we can’t expect deep content next time we go, and so we should be prepared to go to sessions that don’t necessarily have anything to do with what we are working on currently. In retrospect, we should have gone to more MVC and Silverlight sessions instead of stubbornly wishing for more Ajax and jQuery information that just wasn’t forthcoming.

    Look for the travel portion of this blog later this week.