PDC09 is over and now the real work begins as we all take up ASP.NET 4.0, try and do what we saw in the sessions and cry when it doesn’t build. They try again… For those of us who didn’t get to Los Angeles but want at least some of that experience, all the session videos for PDC are now available. Tim Heuer has made a great list and feed for all the Silverlight 4 videos. Here’s what we got for ASP.NET 4.0 with some choice data-related sessions added too.

• Evolving ADO.NET Entity Framework in .NET 4 and Beyond
  (Shyam Pather, Chris Anderson) (PPT - LoRes - HiRes)
• ADO.NET Data Services: What’s new with the RESTful data services framework
  (Pablo Castro) (PPT – LoRes – HiRes)
• Microsoft ASP.NET Futures
  (Jonathan Carter, Scott Hunter) (PPT – LoRes – HiRes)
• ASP.NET MVC 2: The New Stuff
  (Stephen Walther) (LoRes - HiRes)
• Microsoft AJAX Library, jQuery, and Microsoft Visual Studio 2010
  (Stephen Walther) (LoRes – HiRes)
• Microsoft Visual Studio 2010 & MS Deploy
  (Vishal R. Joshi) (PPT – LoRes - HiRes)
• Microsoft ASP.NET 4 Core Runtime for Web Developers
  (Stefan Schackow) (PPT – LoRes – HiRes)
• What’s New in Microsoft ASP.NET 4 Web Forms and Dynamic Data
  (Scott Hunter) (PPT – LoRes - HiRes)
• ASP.NET MVC 2: Ninjas Still on Fire Black Belt Tips
  (Scott Hanselman) (LoRes - HiRes)

And don’t forget to browse through the Day 2 Keynote stuff presented by Scott Guthrie and Scott Hanselman either. Of interest elsewhere, the “M” data team have found a home in SQL Server and data realms and can do interesting stuff with it now. Additionally an interesting Live Labs session trying to find new ways to present and explore information on the web.

• Microsoft Project Code Name “M”: The Data and Modeling Language
  (Don Box, Jeff Pinkston) (LoRes – HiRes)
• Building Data-Driven Applications Using "Quadrant" and "M"
  (Chris Sells, Doug Purdy) (PPT – LoRes - HiRes)
• A New Approach to Exploring Information on the Web
  (Gary Flake) (PPT – LoRes – HiRes)

On Monday I gave a presentation at my local user group and I know I can do better. I know this every time I do it. Here’s my post mortem then on what went well and what didn't.

• Have Enough Material
  Make sure you know how long your session is and have enough material for it. Keep an eye on the clock as you go through the session so you can speed up or add a bit more material as required. If you over-run, know where you can stop early and skip to the conclusion.
• Take Backups of Everything
  If you're doing demos, be prepared in case the demo gods are angry and decide to throw you a curveball. Save a copy of your code as it needs to be at the start of the demo and as it should look at the end of the demo. Then take separate copies on a USB stick as well in case your laptop dies on you. If you're using VS snippets take a back up of those as well. After connecting to the projector last night, my copy of VS decided I had never run it before and reset itself. Oh that I had taken a backup of those settings and snippets.
• Projectors are not your friend
• If possible, find out in advance what resolution the projector being used prefers and try running your presentation and demos in that resolution. Last night's projector gave a 4:3 image while my display is 16:9 resulting in a rather squashed look on my mirrored display in favour of the attendees having the better picture.
• Make sure your demos can be shown without too much scrolling in the resolution you'll be using
• Also check in advance what connections the projector uses. The user group should be able to cover it, but it never hurts to be prepared with your own cables.
• Get There Early And Get Comfortable
• Make sure you are comfortable with your setup before you start. Get there early, set up and run through a quick demo to make sure nothing untoward has happened in transit.
• Don't be surprised if something does go wrong in a demo, but know in advance how to get out of it if something untoward should happen. Know that you can get yourself back on track (you did take backups of your demo code didn't you?)
• Pack a USB keyboard light in case, like me last night, you find yourself trying to type purely by the light of your display.
• Be Positive
  Don't be too negative unless that's part and parcel of your presentation.
• Don’t Let The floor Lead You
  Know your subject well enough to field questions from the floor but don't be afraid to ask your interrogator to come and talk after the session if the answer would hold up your talk or digresses from it, else you’ll over-run.

I hope you find these points useful when you have a go and present a session yourself.

Note to self, there are some good tutorials and 101s out there which should help a lot in a few areas. Make time to get through

• Eric White's Functional Programming tutorial. Back it up with the Project Euler series.
• Rob Conery's MVC Storefront series
• Chris Mills' Web Standards Curriculum because foundations are important
• Mike Taulty's Silverlight 2 series

I'm looking for a good one on Ruby and on Javascript as well. Anyone got anything good? The new Wrox First wiki on Javascript frameworks looks good, but it does cost.

[Update: Aug 1]

• Douglas Crockford has a good javascript tutorial.
• A good Ruby tutorial begins here.

Clay Shirky gave a great keynote speech at the Web 2.0 conference this week, a video of which you can see below. Clay has also provided a slightly edited transcription of the speech on his own blog.

A common thread going round the blogosphere questions what is required to become a better developer. One blogger reckons it’s to read a book a week for 26 weeks and do a little catch up learning. He’ll certainly be better read than before, but better as a developer? Well, maybe. There might be a few other things that will help too.

• Ensure your foundations. Know the basics really well. If your core HTML, C#, PHP etc is always at your fingertips, it’ll leave you time to concentrate on the trickier things. That includes using your IDE, its plugins and your source control system.
• Keep the well thumbed copies of your core reference books to hand.
• Target what interests you. No point trying to work on managed DirectX if you want to be a web developer. Choose an area in your chosen field you don’t know \ aren’t comfortable with and work on that. Set manageable milestones to where you want to get to.
• Read beyond the official documentation. Blogs and books are good, but try and be selective or you’ll never be able to...
• Write code regularly. Writing code is like riding a bike. You don’t really forget how. Writing good code however is like doing a wheelie on a bike. You have to practice to manage it and then keep practicing to sustain it. Discipline yourself to do this.
• Try explaining what you’ve learnt to others. That you’ve managed to achieve a milestone on your way to becoming a better developer doesn’t matter if you don’t know how you got there. Make it clear in your own head by writing down what you’ve learnt or explaining it over lunch to someone else. If you can’t do this, you need to work through it again. Remember, secure your foundations before going to the next step.
• Enjoy it. If you’re not enjoying it, it’s not going to help. It’s easier to learn when you’re happy and having fun than when you’re alone and miserable. The whole Head First series of books uses that as one of its tenets. If work isn’t a fun place to be, do it at home. Joining an open source project might well be a good way to proceed here. Working with an enthusiastic bunch of like-minded people on a project you’re genuinely interested in is a great experience.
• Look at and learn from other people’s code. Preferably their good code. A lot of people learnt HTML by simply viewing the source code of a page they liked in their browser. Online source code repositories mean that you can now do the same in many languages. Sites like koders.com now offer search engines targeting only these repositories so it’s also easier to find the code you want in the first place.
• Learn from other developers mistakes. Don’t sit in silence. Don’t code alone. When you get stuck, ask your co-workers, your open source team mates, your peers on coding forums and your friends how to solve the problem. 99% of the time, the problem is not a new one and someone will have come across it before.
• Know yourself. If you’re a morning person, don’t try and force yourself to work in the evening. If you’re disorganized, write some lists, figure out how to get things done and get going.