2010/01/25

Codemash retrospective

So I’ve been posting all these posts about the sessions from Codemash, but that’s not all that I learned during my time there.  So I thought I’d do an “outside the session” retrospective.

  • No matter how well the facility prepares, 700+ geeks are going to kill the network.  It may have been the wireless access points, but no matter the case people quickly became used to near dial-up speeds again because of so much traffic.
  • I really need to realize I know more about some topics than I think I do.  I went to a couple sessions that looked like they should be higher level and more technical, but ended up focusing on the 150-level type of coding.
  • Great presenters follow the “what am I going to tell you, tell you, what did I just tell you” pattern for presenting.  They also are aware of their time constraints and will make sure to allocate enough time for Q&A, or provide a way to contact them for follow up.
  • Developers have the odd behavior of always sitting near the back of the room.  Some of it makes sense when the power source is in the back or the projector screen is so huge that it would cause neck problems by sitting up front.  This really makes no sense because of technical issues like the mic not working make it easier to hear the presenter.  (ironically, I’m sitting in the back row while I’m writing this up.)
  • A developer conference being held in Sandusky, OH in the middle of January definitely doesn’t sound like a bright idea, but it’s obviously a great conference.  It sold out in about a month.  Maybe it’s the waterpark that’s attached to the hotel.  Speaking of which…
  • I now understand the draw of sitting in a hot tub outside in freezing cold weather.  The hot tubs in the Kalahari waterpark all have an outside area and the feeling of sitting out there was amazing.  That almost made me want to skip some extra sessions to head out to them.
  • Enter The Haggis is an awesome band.  Edge Case Software paid for the band to come out to the conference and perform at the after party after the first day  of the actual conference (day 2 if you attended the Pre-compiler).  You can never go wrong with a band that has a bagpipe in it.
  • Conference sessions are only valuable to you for the first few years of learning a new technology.  Either make use of Open Spaces (provided the conference has it), or network with others.  Open Spaces is great because if there’s something you want to talk about, get it posted on the open space board.  Maybe a time slot has no valuable conference session to you, so check out what’s going on with Open Spaces.  You can learn quite a bit more that way, or meet people you normally wouldn’t.  In my case I caught Jeremy Miller giving a presentation on Storyteller and his goal with it.  And for networking, I got several contacts for the Madison .NET User Group to hopefully get some more prizes coming in.
  • Speaking of Jeremy Miller, I have to admit I’m now wondering why he’s considered such a big deal.  Sure he has done some great things in the open source field, but his presentation skills are kind of lacking.  He has a lot of great ideas, but he takes forever to present them.  I now understand where his monolithic, thousands of words type of blog posts stem from.  Seriously, you’re talking to technical people who are children of the Internet.  Our attention spans aren’t that long.  Keep it moving and vary it up a bit.
  • You can (usually) quickly tell how old some of the pictures are for those that use actual images of themselves on Twitter.  Those that have a somewhat recent picture made it easy to recognize them.  Although it does give you that surreal, “Where the hell do I know you from” feeling when you are sitting right next to the person but can’t place a name with a face.
  • Vendors that use twitter to give away prizes at the conference can be very annoying.  In the case of Pillar, they had a retweet message about being entered to win a Kindle.  The problem is that people just kept retweeting it, even beyond when the conference is going on.  Seriously annoying as all it did was spam the #codemash hashtag.  Telerik took a better approach in that only those that attended the session knew what specific @’s and #’s to put in a message to be entered for a prize.

Overall an outstanding conference.  Definitely looking forward to attending next year, although I think I may actually spend more time in sessions on languages I don’t normally use everyday.

2010/01/18

The Problem of Developers and the English Language

This is more of a rant on development rather than useful code, but hopefully it helps provoke some thought.  And while I may be targeting the English language in this post, I believe the other languages run into this issue just as much.

The very first post I made on this blog was a quote from the book "1984" about a pared down language because (a) it surprised me that everybody focuses on the Big Brother aspect of the story rather than the redefined communication, (b) an explicit language where each word can only mean one thing makes a lot of sense, and (c) having words that are meant to be a scale (good, better, best) actually having the same initial word in them (good, plusgood, doubleplusgood) is more in line with the Latin roots of the English language.  Think back to when you were first starting to understand all the oddities that make up the English language.  I before E except after C. To pluralize a word, add an S; except if it ends in these letters, then do this instead.  There’s a lot of rules to the language that don’t make  a lot of sense.  Although I’m pretty sure Ph.D. bearing learned people can give me the reasoning, the general answer to why it must be done this way is “Because that’s how it’s always been done”.  Outstanding.  Way to think outside the box.

When you're gathering requirements for a problem, how often do the developers interpret a different meaning than what the end users actually meant?  Like referring to the "home page" of a site as the first page a logged in user sees versus the first page that every user sees.  When the manager is talking about the project, are they talking about the entirety of building the software, the Microsoft Project file, the Visual Studio project file, or some other meaning to them entirely.  It gets even worse when a word is used that has a completely different meaning in another language (which at least one project has run into).  Assuming you're programming only in the English language, you have somewhere in the range of 475,000 to 600,000 words to work with.  Not only that, but more words are added to the collegiate dictionaries every year.  And then there are words that are commonly used that don't even exist in a standard dictionary.  So why must we overload the same words over and over again?  Stop being lazy and calling every application that serves out data or hosts another application a "service".  Give it a unique name.

Microsoft’s been getting taking flack about overly descriptive (but entirely accurate) developer product names.  Sure it’s easier to simply say “Astoria”, “Geneva”, or “Longhorn”, but unless you’ve heard of them before you have no clue what they’re actually for.  Now hearing “ADO.NET Data Services”, “Claims-based Identity Management”, or “Windows Vista”, you actually have some idea what’s being talked about without having to spend a lot of time digging into what the product actually is (albeit, not a much better idea in the case of Geneva…).  Sure we need to account for being able to talk about things abstractly in some cases, but we should be able to categorize whatever we’re talking about in a similar way that biologists categorize plants and animals.  IIS is a type of web server, which is a type of server, which is a type of computer, etc. StructureMap is a type of IoC containter, which is a .NET piece of software, which is a development tool.  Although there’s a lot of overlap when describing software, it seems like there could be an easier way to describe and categorize specific software.

If you really think about it, each and every word only exists because a group of people have agreed on a general meaning for it.  Words like "blog" and "podcast" were created to sum up new trends in technology that had not been defined at the time.  All it takes is for somebody to come up with a word and others to start using it for it to catch on.  In much the same way Scott Hanselman wants to have a word that says “I’m a technical person and know what I’m talking about”, I’m think I’ll start using Newspeak terminology to better describe parts of the software I write. 

2010/01/15

Codemash: Analyzing and Improving ASP.NET Application Performance

This was presented by James Avery.  Talks about his experience with all the different sites he’s run, including TekPub.  Overall it wasn’t an extremely informative session, but still picked up a couple things worthwhile.

  • Tricks really aren’t helpful. 
  • Don’t pre-optimize.  Build it and then measure it.
  • If you don’t want to corrupt the code base, spike it out and then measure it.
  • A great process involves Measuring, Modifying, and Measuring again.  This gives you benchmarks to verify.
  • Caching is essentially cheating.
  • Used a tool called Pylot.  It’s been written in Python.  XML based test runner to retrieve data.  It’s an extremely simplistic program.
    • If you want to know if Pylot does X, the answer is “No”.  Well, mostly.
    • Use this when nothing else is running against the system.
  • Another tool is Ants Profiler (costs money).  Or dotTrace.  Either tool for profiling your code.
    • Use in conjunction with SQL Profiler to see all the calls.
    • The reason to combine with SQL Profiler is for when you find code that’s called a lot of times and is slow, check the SQL calls that are happening repeatedly.
  • Another tool is Fiddler or other network monitoring tools.
  • Can make use of DataLoadOptions in Linq-To-SQL and the LoadWith<> method to specify tables that should be eager-loaded.  It won’t always work as Linq-to-SQL sometimes will ignore the recommendation.

Codemash: Credit Crunch Code

Paying Back the Technical Debt

Presented by Gary Short.  The talk was about the shortcuts we have to make when coding and how we can start making up for them.  It’s great learning something from a guy who has a strong Scottish accent.  He is has an outstanding ability to present though.

  • Ward Cunningham was the one who coined the term “technical debt” in 1992
    • Came up with the term as he was doing work for a financial institution, so it was very similar to borrowing money.
    • With financial debt, it can be like “virtual debt” in that you’re aren’t earning as much money as you could on the money that incurred the debt.
  • By incurring the technical debt, you can cause the product to be shipped late (causing a bad brand name), a loss of market share, or loss of excitement to work on the product.
  • Just as financial debt isn’t all bad, technical debt isn’t all bad.
    • If you need to hit a milestone by a certain time to get the company buy in, it’s fine as long as you pay it back
  • The only safe amount of technical debt in a codebase is 0.  But that’s like saying a codebase has 0 bugs.
    • Really just need to get it to a point where you don’t notice the issue, even if it’s really there.
  • You don’t want to have a logarithmic graph describing the technical debt.  You want a saw tooth graph describing it.  So every couple months take some time to pay it down.
  • It’s difficult to calculate the technical debt.  He has a nice, complicated formula that factors in things like employee costs, hardware costs, software licenses and software brand costs.
  • Waterfall methodology is an anti-pattern
    • Because you’re making all decisions up front, the costs go up as the project goes further.  Since you can’t change, it’s an insane amount of cost.
    • Because the subject matter expert has to go through a learning curve (no matter what they know), there’s going to be things that aren’t known up front.
  • Agile isn’t necessarily the fix to the Waterfall anti-pattern
    • Try to incorporate elements of Agile into Waterfall so that the cost isn’t so high
  • Not-Invented Here anti-pattern
    • Development teams spend time developing software which is not core to the problem they are trying solve.
    • Bunch of reasons why not to use a 3rd party product.
    • By having a developer working on a component that they find is harder than initially thought and buy the 3rd party product, they’ve incurred major technical debt.
    • Buy the components if it truly will save time.
    • Use open source if you can.
    • If these don’t work, then work your own
  • Objects that are in code together stay together anti-pattern
    • The classic car example.  Car’s have no behaviors because it’s an inanimate object.  Actors perform behaviors on the object.
    • It’s technical debt because it’s a simpler object graph.  We repay it later because of the cost of adding functionality.
    • Because adding functionality becomes so hard, it damages the brand.
    • It’s not horrible because it allows you to quickly get to market.  Just realize the cost it will incur.  Decide if the debt is worth it.
  • Sensitive Tests anti-pattern
    • tests that are sensitive to context/interface/database
    • make sure tests are as isolated at possible.
  • How to spot technical debt
    • technical debt is pretty much invisible.
    • Take the astronomer approach to finding technical debt in the way that they find planets that can support human life.
    • Using things like the burndown graph to find when issues are coming up.
      • The average productivity should stay pretty consistent
      • If it’s going down, then technical debt is accumulating because it’s harder to add features
      • the number of tests per feature should be pretty similar.
      • if it’s increasing per feature, it’s showing how difficult adding the new features are becoming.
      • if the average team morale is decreasing, it is a good sign things are becoming worse and becoming harder.  Measure this by having the team members rate their happiness on a 1-5 scale anonymously.
  • Technical debt is a silent killer
  • http://c2.com/cgi/wiki?WardExplainsDebtMetaphor
  • http://www.martinfowler.com/bliki/TechnicalDebt.html

On a side note.  Andy Hunt’s keynote over lunch was outstanding.  He talked about the mother of all bugs: the human mind.  It essentially covered all the psychological defects that exist in the human mind.

Codemash: 0-60 With Fluent NHibernate

This was presented by Hudson Akridge.  He contributes to Fluent NHibernate.

  • Automapping
    • the classes need to be public (classes were A and B)
    • all properties need to be virtual
    • in the configuration

      Fluently.Configure()
      .Database(SQLiteConfiguration.Standard.InMemory())
      .Mappings(mapping => mapping.AutoMappings.Add(AutoMap.AssemblyOf<A>().Where(x=>x.Namespace == “…”))
      .ExportTo(Directory.GetCurrentDirectory()))
      .BuildConfiguration();
  • Fluent Mapping
    • Needs a parameterless constructor
    • Nested Expression Exposition
    • Nested Mapping
    • Reveal using string based names
  • www.fluentnhibernate.org
  • http://github.com/jagregory/fluent-nhibernate

The talk was given to the Chicago ALT.NET group back in July 2009.  You can catch the video here: http://chicagoalt.net/event/July2009Meeting060withFluentNHibernate.

Codemash: Software Design & Testability

This session was presented by Jeremy Miller

  • Testability & Design is not about mock objects/interfaces.  It’s about finding/removing/preventing defects.  Better partitioning or responsibilities.  Boils down to “Divide & Conquer”.
  • “I don’t code, I ship software”
    • Take advice from Mary Poppendieck about optimizing the whole of the project, not just the code.
  • Good Code vs. Bad Code
    • The quality of the code has a dramatic impact on how productive the developer can be.
  • Interesting quote from Michael Feathers: “I don’t care how good you think your design is.  If I can’t walk in and write a test for an arbitrary method of your in five minutes…”
  • First causes of good design
    • Feedback, Cycle Times, Batch Size
    • Orthogonality
      • Being able to focus on features independent of other features.
    • Reversibility
      • The ability to change a decision that’s been made about the code.
    • Understandability
      • Is the code readable and can be followed easily?
  • Writing Automated Tests
    • Set the system into a known state using known inputs
    • It has measurable outcomes
      • State based tests.  I.E. Calling a method to write a file results in a file actually being written.
      • Interaction based tests. I.E. Verifying that a method is actually called.
  • What makes tests better
    • Repeatable
      • Running the same test over and over always has the same result
    • Runs Fast
      • If you can’t run the test quickly, you won’t run them that often.
    • Easy to write
    • Easy to understand
      • If you can’t quickly and easily glance at the unit test to verify what the test is aimed at, it’s not easy to understand
  • Systems that are hard to test
    • invoicing rules engine
    • rules defined in an xml file
    • invoice data read from stored procedures
    • no seams in the application to break it apart.
  • How do I test
    • WorkflowProcessor
      • Basic workflow logic
      • State persisted to the database
      • Sent emails at various times
  • Things that are hard to test
    • The database
    • Active Directory
    • Web Services
    • Messaging
    • Windows Services
    • Remoting
    • SCF
    • WPF/WinForms
    • System.Web Namespace
    • External System
    • Chatty APIs
  • “Isolate the ugly stuff.  That essentially comes down to anything written by Microsoft”
  • Test small before testing big
    • Verifying that the pieces actually fit together
      • Start working on the pieces you know how they work.
      • It’s just the small pieces you’re working on, not the entire system as a whole.
    • Code from the bottom up…
      • start with the small pieces
    • …or from the top down
      • Use mock objects to flush out API and how things will fit together.
  • Talked about Dependency Injection (with a rather strange bias towards StructureMap. Gee…wonder why…).
  • Keep a short tail
    • Can you pull it off a shelf and work with it without pulling down/in extra classes.
    • Isolate the Churn
      • Isolate when there’s a lot of change.

2010/01/14

Codemash: T4 Code Generation with Visual Studio 2008

Presented by Steve Andrews.

  • What is it?
    • Was originally a DSL for creating code based on your model.
  • Demo
    • Need a template directive
      <#@ template language=”C#v3.5” #>
    • Output directive
      <#@ output extension=”csv” #>
      one,two,thee
      four,five,six
    • Expression blocks
      <#= DateTime.Now.ToString() #>
    • Statement blocks
      <# for (int i = 1; i < 6; i++) { #>
      <# } #>
    • Class feature blocks
      <# HelloWorld(); #>
      <#+
      private void HelloWorld()
      {
      }
      #>
    • Include directive
      <#@ include file=”_IncludedFile.tt” #>

      remove the custom tool for the included file if you don’t want it to run.
    • Assembly include directive
      <#@ assembly name=”System.Xml” #>
      <#= new System.Xml.XmlDocument().ToString() #>
    • Import directive
      <#@ assembly name=”System.Xml” #>
      <#@ import namespace=”System.Xml” #>
      <#= new XmlDocument().ToString() #>
  • T4 Toolbox
    • Can generate multiple outputs per template
    • Since the generator has to create a file by default with the same name, use it as a log of the output.
    • Can create classes within the template that can extend Generator
    • Can extend templates as well.
  • Custom Directive Processor
    • Need to put create some registry keys for the custom directives
  • Custom host for running T4.
  • Debugging T4
    • Registry setting that you have to change from 10 to 2 if using above .NET 3.0

Have to say that I thought I knew quite a bit about T4, but really a great presentation overall.

Codemash: Powershell: Ten things you need to know

Presented by Matthew Hester and Aaron Lerch.  It’s interesting because much of the audience really hasn’t seemed to have even touched Powershell.

  • What is it?
    • Rich script environment
    • Bulk operations
    • Interactive environment
  • The Active Directory Administrative Center that ships with Windows 2008 R2 is all Powershell driven.
  • When to use it
    • consistent, repeatable tasks
    • talking with Active Directory, registry, WMI and others natively
    • to create aliases to create commands that you’re used to.
  • Make use of commandlet (a verb-noun syntax) and the parameters (the name-argument pair).
  • Making use of the pipeline
  • Talked about the Powershell ISE that comes with version 2.
  • Useful commands:
    • get-module –listavailable
    • help “command” –examples/-detailed/-full
  • Providers
    • Get-PSProvider
    • Custom
      • DriveCmdletProvider
      • ItemCmdletProvider
      • ContainterCmdletProvider
    • The ShouldProcess capability means it handles the –whatif flag
  • Use PSCmdlet when creating your customizing commandlets.
    • System.Management.Automation is the assembly to reference
  • PSHost for hosting the powershell run space.
  • The Windows Troubleshooting Pack is built on Powershell.

 

On a side note, this was after lunch, where Hank Janssen gave a keynote on PHP and Microsoft.  Pretty interesting stuff.  It’s great to hear about the efforts that Microsoft does with the open source projects that are out there.  Although he didn’t really plan on some of his demos being that horrible with the crowd killing the internet connection.

Codemash: Building maintainable ASP.NET MVC

This was presented by Chris Patterson from RelayHealth.  He’s an active open source developer, so that’s probably why his name sounds so familiar to me.  He’s also a Visual C# MVP.

  • Since much of the audience are not ASP.NET MVC programmers, he covered a lot of the basics.
  • Talked about some of the MvcContrib/ASP.NET MVC 2 features.
  • Controller should be the only thing that talks to the Domain Model.  The Controller, View Model, and View all have an idea of each other.
  • View Models should only have data.  No behaviors.  It should be a flattened structure.

Overall the presentation was aimed at those who’ve never looked at the framework before.  Maybe if I hadn’t already done a project using this technology before it would be worthwhile to me.  But overall it wasn’t quite what the session abstract stated.  So that means it’s time to kick in the law of two feet and go find a session that I’ll actually learn something.

Codemash: Agile Iteration 0

This was presented by Ken Sipe from Perficient.  It basically covered how to get Agile accepted into a business, starting out with the first iteration and what it all includes.  Overall the presentation was great, but he was a little scatter brained in actually presenting it.  It didn’t flow very well as it felt he was jumping back and forth quite a bit.

  • Talked about waterfall development being the standard way companies generally tackle development.
  • Iterative process’s biggest usefulness is the feedback.  But companies don’t like it because they can’t plan long, long-term goals of when things will be delivered.  Since priorities can be shifted around, knowing what will be delivered is nearly impossible.
    • Talked about college experience when finding out you have a paper due in 3-6 months.  Most people finish it the night before/week before/weekend before.  When the instructor requires certain aspects of it at given points throughout the course, it’s an iterative approach.  You get feedback from the instructor earlier and can make the paper that much better.
    • Similar approach with the NASA Apollo missions.
  • Finding the iterative length is really about what feels right for the company.  Longer iterations means less feedback.  Shorter iterations means not being able to get things done.
  • Iterative delivery helps develops trust between the development staff and the business.  Building the trust is essentially actually doing what you say you’re going to do.
  • Agile is not evolutionary, no documentation, no architecture, cowboy development.
  • Pair programming is extreme of code reviews.
  • Programming engages the logical side of the brain.  Taking a break causes it to disengage and lets the creative side tackle the problem.  Pair programming allows a full brain to tackle a problem.
  • Pair programming is actually about 1.5 develops worth of work, not just 1.
  • “Bus Number” – the number of people on the project that need to be hit by a bus before the project can’t continue forward because expertise is gone.
  • Agile at the micro view:
    • Initial opening meeting
      • *everybody* is there to make sure everybody’s on the same vision of the project.
      • Agree on acceptance criteria
      • Agree on the priority
      • Break down into groups to figure out what some resources already exist or come up with estimates
    • Opening meeting
      • Should be attended by Developers, DBA, User/BA, Architects, QA
      • Using a BA or having limited contact with the user, generally a failing point is not meeting the acceptance criteria.
      • Assign tasks.
    • Standup Meetings
      • Can be sabotages by the Project Manager because they’re trying to get and provide too much information.
      • Only pigs are allowed to talk.  Chickens don’t talk.
    • Closing meeting
      • What was accepted by the user?
      • What is the velocity?
      • What architecturally significant  has changed?
      • It is a quality check of general
      • Were the estimates accurate?
      • Is the team performing as expected?
      • Is QA catching bugs that weren’t functional bugs?
      • Are functional bugs making to QA? Are the unit tests not being that effective?
  • Agile at the macro view:
    • Starting is the hardest part.  Having a mentor who’s been through it is the greatest point
    • Pre-iteration 0
      • Project inception
      • Stake holder level
        • Business opportunity/concerns
      • Collection of stories
      • Estimating ROI and project justifications
      • Building up team/resources
        • co-ownership of code
        • prepared to steal tasks
        • pairing capable
        • expected velocity.  Adjust story alignment and release plan.
        • Team phases:
          • forming
            • excitement/optimism
          • storming
            • resisting task, disunity
          • norming
            • constructive criticism
          • performing
            • self directed
      • iteration sizing
      • initial list of risks
      • release plan
    • iteration 0
      • 2 store development approaches
        • Majority of the stories upfront with the major understanding that you will likely discover more
        • sone stories upfront to prime with the intent that you’ll have a trailing analyst
        • Either approach needs an Analyst, BA or PM to keep feeding stories into the next iteration.
      • Automate as many things as possible.  Not just in software, but bringing on new people to the team.  Take out as much manual work to a simple button click/one command line.
      • Perform some spikes to learn about the new tools for the project
      • Build system/continuous integration is a necessity.
      • Set up reporting: burn down charts
      • Get a story reposity/wiki going
      • The general standards, annotations, and upfront patterns (MVC, presentation model, logging in all aspects…)
    • feature slip are those features that don’t get completed in an iteration, but were meant to be part of it.  Similar to RUP’s time slip.
    • If you have humans doing regression testing, you will fail.
    • Talked about different options in working with QA in the iterations.  Will post pictures later.

Codemash Keynote: Mary Poppendieck – Five Habits of Successful Lean Development

What a way to kick off the actual part of the Codemash conference with a keynote from one of the major voices of the Lean development segment.  None other than Mary Poppendieck.  Some of the points of her talk:

  • Key tenants of Lean:
    • Eliminate Waste
    • Focus on Learning
    • Build Quality In
    • Defer Commitment
    • Deliver Fast
    • Respect People
    • Keep On Improving
    • Optimize the Whole
      • Think about the entire process, not just the software
  • The 5 Habits
    • Purpose
      • Many developers are only doing their job because somebody told them to do it.  Sure coding it fun, but do they really know why they’re doing it?
      • Keep the development staff near the customers to focus on what the end users actually NEED vs keeping them completely separate and all the requirements are tossed over the wall where the developed software is most likely never used.
      • Essentially just get the developers involved in the business to better understand what the needs of the business are.
      • Possibly have the developers actually do the job that they’re developing the software for to understand the pain points.  e.g. call center software.
      • If nobody’s requesting new software features, it means nobody’s using the software.  It doesn’t mean the software is feature complete.
      • That’s why open source software seems to be so easily programmed.  Those programming it are those that use it because they need to use it.  They know where the pain points are.
    • Passion
      • Developers like getting passionate about their work.  If they’re not passionate about their purpose at the company, they tend to get passionate about the minutia of development tasks.
      • Cost Center Disease – focus on cost reduction instead of delivering value.
        • Typical places this is found: IT departments, government organizations, some consulting firms
        • The problems include not being able to focus on giving better customer outcomes, no real engagement with customers.
      • Example of a passion – the Launchpad developers back when it was a for-pay development package.  Even though it was for-pay, it was very open source style based.
      • Typically if you are very passionate about something (like programming) it’s hard to make a living at it because you enjoy it too much.
    • Persistence
      • There’s no substitute for being careful and doing really good work.
      • The most accomplished people need around ten years of “deliberate practice” before becoming world-class.  This is also known as the ten-year rule.
      • Identify a specific skill that needs improvement.
      • Devise (or learn from a teacher) a focused exercise – designed to improve the skill.
      • Practice repeatedly.
      • Obtain immediate feedback – adjust accordingly.
      • Focus on pushing the limits – expect repeated failures
      • Practice regularly & intensely – perhaps 3 hours a day.
      • Open source development is a good way to learn – you generally have a teacher, are challenged, get immediate feedback, and dedication to the project.
      • Improvement kata
        • Visualize perfection – visualize what the ideal world is
        • Have a first hand grasp of the situation – understand how you can improve the situation
        • Realize that there’s a huge gap between the first 2 steps – find the minor steps inbetween the 2 points
        • understand obstacles that come up between the minor steps and overcome them.
      • Dijkstra’s Challenge
        • If you want more effective programmers, you will discover that they should not waste their time debugging – they should not introduce bugs to start with.
        • Find as many bugs early so the “code freeze” phase can be brought down to less than 10% of the release cycle.  Typical is around 30% of the cycle, sometimes 50%.
    • Pride
      • Story about a philosopher asking 3 stone cutters what they were doing.  “I’m cutting stones”, “I’m earning a living”, and “I’m building a cathedral”.
      • Move responsibility and decision-making to lowest possible level. 
        • “If you’re a manager, your job is to be lazy.  Have those lower than you helping drive decisions”
      • Litmus test for those with pride: how do people handle their frustration with their job? Do nothing, complain about it but overall do nothing, or find a way to fix it.
    • Profit
      • The examples given are large companies, consistently profitable, they dominate their industry and for a long time.  The front-line people are highly valued, expected to make local decisions and effectively engaged in delivering superior customer outcomes.
  • Talked about Tandberg’s successful implementation of Lean
    • Talked with really individual, front-line workers
    • The workers knew by heart the 1-line pitch of company for what the company’s purpose was.
    • The workers also knew exactly why they were doing their job.  They were passionate about what they did because they knew why they’re job was in place.
    • http://www.pvv.org/~oma/SoftwareDevelopmentAtTandberg_March2009.pdf

Overall really great information presented.  If you ever have the chance to listen to Mary give a presentation, don’t miss out.

2010/01/13

Codemash Pre-compiler: Software Craftsmanship

This was presented by Steve Smith (@ardalis | Codeproject.com) and Brendan Enrick (@brendoneus | NimblePros.com).

  • What is It?
    • Software Craftsmanship Manifesto ()
  • Why practice?
    • Basically it’s like Microsoft Certification tests; memorize the techniques so that when it’s time to solve a problem, you have a number of techniques you know like the back of your hand rather than having to look it up each time.
    • Using Kata’s helps for improving your “muscle” memory when it comes to tackling similar problems.
    • If you’ve already explored the problem domain using one approach (strictly OO using .NET 2.0 way), you should already have the unit tests that, in theory, can be used when you rework them in the underlying logic (using LINQ).

Kata’s practiced:

  • Bowling game (as Uncle Bob has tackled the kata).
    • the TDD approach that Uncle Bob took to tackle the problem
    • Took an approach with Mike Letterle that might have been a little more complicated than it needed to be, but was a good exercise in thinking it through.
  • A grocery shopping register.
    • having to account for discounts like “Buy N and get the N+1th free” and “Buy N for $M”.
  • FizzBuzz

Overall it was a cool session, but more for talking with developers outside my normal circle and getting a different point of view in how to architect the code.  It was great taking a TDD approach to tackling these kata’s though.  Especially pairing with a Java developer on the Grocery store kata.  Kind of wish I would have gone to a different session to actually learn more content as I’m thinking I’ll probably end up in the coding room one of the days to pair with people just to learn more from them and to actually be able to do some pair programming as it’s such a foreign concept every place I’ve worked.  It’s amazing how much it helps to be able to think through the implications of a certain architecture before ever actually laying out the code.  Although if you have two developers that over think the  problem it can lead to issues.  Amazingly I was able to no do that at all today and instead focused on “this is what’s being asked for, so let’s actually deliver that”.

Codemash Pre-compiler: Software Engineering Fundamentals Workshop: OOP, SOLID, and More

It’s that time for Codemash again.  So I’ll be doing some stream of conscious type blog posts again.  If others find this information kind of interesting I’ll expand on it some more, but mostly it’s for my own recollection.  The first session I attended during the pre-compiler was “Software Engineering Fundamentals Workshop: OOP, SOLID, and More” presented by Jon Kruger.  He kindly has the slides up at http://jonkruger.com/solid/OOP-SOLID-CodeMash.pptx.  Some of the points of his presentation:

* Started out talking about OOP.  Good analogy between Legos and code.  Glued together Lego pieces are like tightly coupled code.

* “Just because you are using an OO language does not mean that you are doing object-oriented programming.”

* “Avoid Not-Invented-Here syndrome”.  Promote reuse of objects, not just methods. And not via copy-and-paste.

* Great example of Encapsulation –> home electrical wiring.  You have abstraction/interface on top of abstraction/interface on top of abstraction/interface.  You only need to know what’s under the hood if you really HAVE to, otherwise go with the easiest interface.

* Object-orient programming is about behavior, not just fields.  Encapsulation is about hiding the fields and the only interaction is via behaviors.

* Rethink about object Inheritence by using composition.  It helps break down large methods.  It’s like going to a grocery store to choose what food is available to you vs. being a farmer and tied to what food you grow.

* Easier programming does not mean you shouldn’t learn new techniques/programming languages/etc.  It’s sometimes FAR easier to learn something new to help you out overall.

* The SOLID talk is very similar to what I presented to the ALL.NET group awhile back, but focused more on “Don’t do something that you really don’t need to do because it doesn’t fit your situation” and “Think before you implement.”

I have to give kudos to Jon for integrating the pairing session into the session.  It was a great opportunity to take an existing (crappy) application and refactor it using the techniques he had just presented.  I paired with Curtis Mitchell which was a great time, despite the fact we didn’t get a chance to dig too far into actually fix much of the code.

2010/01/11

Best Macro to use in Visual Studio

I wrote this little macro awhile back, and after getting burned by yet another accidental hit of the F1 key and waiting the agonizing amount of time before the Help came up, I realized it's time to get this macro out there so I can "install" it wherever I'm at. Since whenever I’m looking up documentation on a .NET class I copy the class name, go to Google, and generally the answer is within the first couple links. So why not automate that.

To add it to your Visual Studio macros, bring up the Macro Explorer panel (View –> Other Windows –> Macro Explorer; or Alt + F8). Edit a module and add sub to the module you want to.



Public Sub SearchWord()
Dim objDocument As EnvDTE.Document = DTE.ActiveDocument
Dim sSearchText As String

Dim currentSelection As TextSelection = objDocument.Selection

If currentSelection.Text <> "" Then
sSearchText = currentSelection.Text
Else
Dim objTextDocument As EnvDTE.TextDocument
Dim objTextSelection As EnvDTE.TextSelection
Dim lineNumber As Integer
Dim colNumber As Integer

' Get the text document
objTextDocument = CType(objDocument.Object, EnvDTE.TextDocument)
objTextSelection = objTextDocument.Selection
colNumber = objTextSelection.ActivePoint.DisplayColumn
lineNumber = objTextSelection.ActivePoint.Line

objTextSelection.WordLeft(False, 1)
objTextSelection.WordRight(True, 1)

sSearchText = objTextSelection.Text
objTextSelection.MoveToDisplayColumn(lineNumber, colNumber)
End If

System.Diagnostics.Process.Start("http://www.google.com/search?q=" + sSearchText)
End Sub


Save the module and you can close out of the Macro editor. Now back in Visual Studio, open up the keyboard options (Tools –> Options –> Environment –> Keyboard). Remove the existing F1 binding by searching for “Help.F1Help” in the “Show commands containing” textbox and clicking the Remove button to unbind it. Now search for the macro you just created. Press the F1 key in the “Press shortcut keys” textbox and click “Assign”.



Now whenever you hit F1 it will highlight the current word and search for it in Google in your default browser. Pretty simple stuff!


EDIT (2010-01-18): Based on feedback I updated the macro to not change the selected text if there's already something selected, and won't leave an item selected if you didn't have something selected already.

2010/01/07

Speeding up podcasts within iTunes

What started out as a simple Superuser question became a long trek to find a solution.  The only answer at the time pointed me to do batch processing through Audacity, but I was trying to avoid automating the GUI as much as possible.  Although I know how to make use of AutoIT and AutoHotKey to automate a GUI application, it’s not the approach I wanted to take with this.  The machine I sync my iPod and iTunes with I use quite a bit so I don’t want to have miscellaneous windows popping up on me and worrying about my current activity accidentally overriding what the script is doing.  Yes, using the iTunes COM SDK causes iTunes to open up if it isn’t already, but I’m okay with that since I keep iTunes open most of the time to update my podcasts so it doesn’t affect me very much.

So all that being said, as you probably guessed since I actually posted this, I came up with a solution that doesn’t involve AutoIT/AutoHotKey.  Doing a little digging I found an alternative to Audacity (which only operates through a GUI) called SOX (which is command line driven).  In a similar vein that Audacity suffers, they can’t distribute compiled applications that work with MP3’s because of the wonderful licensing of the format.  Thankfully SOX is open source, and others have already dealt with this issue, so I’ll make use of their outstanding work.  If you really want to do the work yourself, take a look at the steps on this Code Project article.  I attempted the steps, but ran into a number of issues when trying to compile everything myself.  It may have been my very rusty C++ skills, but who knows.  So instead, the author of that article published the output of the steps and that’s what I downloaded and made use of (the sox.zip link).  It is a number of versions behind the current version of SOX, but for my needs it’s fine.  To follow what I’ve done, download that file as well, and put it somewhere on your machine.

The next step was creating a Powershell script to get all the podcast tracks that iTunes has downloaded and modify them.  Not sure why, but this appears only only work in Powershell v2, so I accomplished that using the following script (note the line pointing to where Sox.exe exists), which I called “”SpeedUpPodcastsIniTunes.ps1”:

 

# Comment that will be applied to all podcast files that will be updated.
$modificationComment = "::Modified By Powershell Script::"

# Location where sox.exe exists on your machine.
$soxFile = "C:\Path\To\Sox.exe"

# The file types to modify. Make sure that Sox.exe can handle the file types
$extension = ".mp3"

# This is a list of all the podcasts that should have every file modified. This is an
# opt-in process for each podcast. The podcast names are case sensitive.
# Format should be like the following:
# ... = "Podcast 1", "Podcast 2", "Podcast 3", ...
#$podcastsToAffect = ".NET Rocks!", "RunAs Radio", "The Thirsty Developer - Podcast"
$podcastsToAffect = "The Thirsty Developer - Podcast",
".NET Rocks!",
"RunAs Radio",
"Hanselminutes",
"Herding Code"

# The tempo speed is how fast to speed up the podcast. A value of 1.0 is the same speed
# it's currently at. 1.5 is 150% faster, so the overall length would be 66% of what it
# currently is.
$tempoSpeed = "1.5"


$itunes = new-object -com itunes.application
if($itunes -ne $null)
{
Write-Host "iTunes is running..."
# Sources.Kind == 1 (ITSourceKindLibrary)
$itunesLibrary = $itunes.Sources | Where-Object { $_.Kind -eq 1 }
Write-Host "Retrieving Podcasts"
$podcastsPlaylist = $itunesLibrary.Playlists | Select-Object $_ | Where-Object { [string]::Compare($_.Name, "podcasts", $True) -eq 0 }
# Tracks.Kind == 1 (ITTrackKindFile)
Write-Host "Filtering Podcasts"
$downloadedTracks = $podcastsPlaylist.Tracks | Where-Object { ($_.Kind -eq 1) -and ($_.Podcast -eq $True) -and ($podcastsToAffect -contains $_.Album) } | Select-Object $_ | Where-Object { (([string]::IsNullOrEmpty($_.Lyrics) -eq $True) -or ($_.Lyrics.Contains($modificationComment) -ne $true)) -and ([System.IO.Path]::GetExtension($_.Location) -eq $extension) }

Write-Host "Processing..."
$downloadedTracks | ForEach-Object {
if($_ -ne $null){
$trackLocation = $_.Location;
$currentLyrics = [string]::Empty
if([string]::IsNullOrEmpty($_.Lyrics) -ne $True){
$currentLyrics = $_.Lyrics
}

$tempFile = [System.IO.Path]::GetTempFileName()
# GetTempFileName() actually creates the file, which we don't need
[System.IO.File]::Delete($tempFile)
# Need to give the temp file an appropriate extension because Sox.exe requires it.
$tempFile = $tempFile + $extension

Write-Host Converting `( $_.Name`)
& $soxFile $trackLocation $tempFile tempo $tempoSpeed
Write-Host Done!

# Need to delete the current file because Move() doesn't let you overwrite the file.
[System.IO.File]::Delete($trackLocation)
[System.IO.File]::Move($tempFile, $trackLocation)

# Update the Lyrics for tracking the files that have been changed.
$currentLyrics = $currentLyrics + "`r`n" + $modificationComment
$_.Lyrics = $currentLyrics

$_.UpdateInfoFromFile()
}
}

# clean up memory
[void][System.Runtime.InteropServices.Marshal]::ReleaseComObject([System.__ComObject]$iTunes)
}


You’ll notice that I’m making use of the Lyrics section of the podcast to track if it’s been modified by this script before.  I initially was using the Comments, but apparently some of the podcasts actually fill in that information and there’s a limit of 256 characters on the field.  My first trial runs ended up with a few “Cannot change the Comment” errors being thrown by the COM interop because of that limitation.  So far I haven’t run into an issue with the Lyrics section.



The final step is setting up a scheduled task to run this script on a schedule.  For the command on the scheduled task itself, it looks like this:



C:\Windows\system32\windowspowershell\v1.0\powershell.exe –NoProfile –NonInteractive “C:\Utils\Scripts\SpeedUpPodcastsIniTunes.ps1”



And the Start In directory is set to `C:\Windows\system32\windowspowershell\v1.0`.



So far it seems to fit my need pretty well.  It does have a noticeable lag when it’s filtering the podcasts, but not too bad.



NOTE: The first time you run this, it’s advisable to delete all but the most recent track for a podcast.  It does take several minutes to convert the files, so even a handful of them can take a good deal of time.