Powershell: Add an extension to every file in a directory

It's been awhile since I've posted up a Powershell script.  Powershell really is great, and I really don't use it enough.  I should start using it all the time for any ridiculous thing I can think of just so I can polish up my skills so when that once in a blue moon, "holy crap! do something complicated quick!" situation comes up I'll be ready...

This time I downloaded a bunch of mp3s that were on Google docs.  Google docs is awesome, it lets you select a bunch of files, and download them all.  Then it zips them up so you can download them all together.  Unfortunately, when I unzipped them, they didn't have a file extension...

dir | % { mv $_.FullName ( $_.Name + ".mp3" ) }

That command gets every file in the directory ( dir ), sends them to the next command ( | ), which loops over them one at a time ( %, is short hand for foreach-object ), then executes the move command ( mv ) with the file's full name as the first argument ( $_.FullName, $_ is magically set to the current loop item ), and the file's name with .mp3 tacked onto the end as the second argument ( $_.Name + ".mp3" ).  The parentheses tell it to evaluate the expression and pass the result as the second argument.

Beautifully simple.

Need to figure out what properties are available on the objects you get from the dir command?

dir | get-member

Need to figure out what the value of one of those properties will actually be?

dir | % { $_.FullName }

Gotta love Powershell!

Simplicity vs. Adaptability

When dealing with code, and code architecture and design, there are lots of factors which have to be weighed to determine what the best way to go is.  The popularity of Ruby on Rails in the blogosphere and the conference circuit has begun to shift the conversation about these factors a bit.  When we were focused on Java and .NET we spent lots of time talking about The Gang of Four, Fowler, SOLID, and SOA.  These days we seem to be talking more about BDD, "simplicity", terseness, and productivity.

I think this is a good thing, but I also think it's because we have finally realized that we are writing a whole new class of applications now.  Back in the day, people were focused on BIG and COMPLICATED applications for banking and shipping and other complicated industries.  We are still doing that kind of work today of course, but we've added a whole new class of application that didn't exist before: small and simple web applications.  These websites are actual applications, not just brochure sites, so they have logic and models and all the rest.  But their domain tends to be small, and the rules tend to be much simpler.

It seems like what we've learned as an industry is that all the patterns and practices that have been developed for dealing with large and complicated systems aren't necessarily needed for smaller web applications.  But many of these things have become so ingrained in the way that we think and the way we approach problems that it can be a rather jarring shift to throw them out.

Ultimately this comes down to a question of Simplicity vs. Adaptability.
Simplicity: straight forward, few layers
Adaptability: Guards against change, includes more abstraction

Are These Really Opposing Characteristics?
The best possible design would be one that is both simple and adaptable, but usually simplicity and adaptability are opposing characteristics.  This is because to make something adaptable, you tend to have to build in more layers and more abstraction, and that necessarily makes it more complicated.

For example, the Active Record pattern is simpler than the Data Mapper pattern.  But the Data Mapper pattern isolates your models from changes in the database and vice versa, as well as removing all persistence knowledge from the models themselves.

There is a fun catch-22 here though.  If your abstractions can serve as effective methaphors, you can begin to ignore the complexity the abstraction hides from you.  This allows you to think about the system in a much simpler way, even though the details of it are very complex.  But its debatable whether we would call a system like this "simple."  For example, websites written with Ruby on Rails tend to be simple, but I would not describe Rails itself as simple.

Simplicity is exemplified by DHH, creator of Ruby on Rails
Adaptability is exemplified by Jeremy D Miller, creator of FubuMVC

Just look at the difference in their tag lines:
"Ruby on Rails is an open-source web framework that's optimized for programmer happiness and sustainable productivity."
FubuMVC: "Compositional, compile safe, convention-based configuration for complex web applications."

The focus of these two projects is clearly different, and its hard to argue with either one.  Both can be used to create "simple" web applications.  But Rails is very focused on a certain subset of simple web apps, where Fubu is more interested in being adaptable in order to allow you to tailor it to your needs.

There is a trade-off here.  And which trade is right for your project is one of the most important decisions you have to make.  As I wrote recently, the factors you have to consider in this trade-off frequently aren't even technical!  So we really need to understand how diverse our industry has become, and we need to understand the context in which these things are being discussed.

More Engagement

Are you engaged at work?  I don't mean like, engaged to be married.  I mean are you ENGAGED?

If not, why not?  Are you not paid well?  Do you not like the work?  Do you not like your coworkers?  Do you not like the management?  Do you not like your boss?  Are you bored?  Is the organization keeping you from doing your best work?  Do you feel unproductive?  Do you feel unable to contribute?  Do you feel micromanaged?  Why?

Maybe this guy can help explain it:


Maybe your organization's attempts to motivate you are actually, though accidentally, de-motivating you!  Isn't it ironic?  So what should they be doing?  What do you need to be engaged at work?  To be at your best, to be your most productive, to be happy?

According to Dan Pink, its as simple as 3 words:  Autonomy, Mastery, and Purpose.  This observation lines up so nicely with the observations in First, Break All The Rules too!  But the problem with these observations is that they are only observations.  They provide really useful information, but don't help your boss figure out how he should act day to day.

That's actually one of the main reasons why I think First, Break All The Rules is such an excellent book, and so much better than any other book on "management" I've ever read.  There simply is no cookie cutter, one size fits all, set of steps you can follow to create an environment in which everyone is engaged.

Now, if you're the boss you can start putting your understanding of Autonomy, Mastery, and Purpose to work right now.  But if you are not the boss, what good is this to you?  If you have some "direct reports," you can apply these ideas with them within your own projects.  At least that's a start.  But if you don't have "direct reports," then it looks like knowing this stuff isn't going to help you at all!

I remember the first time I read Peopleware...  On the one hand I absolutely loved it.  But on the other, it was just depressing.  And I believe that my company would actually rank very highly compared to other companies on these factors.  But it didn't matter, it was depressing!  That's because this kind of stuff seems too far out of the control or influence of a lowly programmer.  What impact can one person have on things like culture?  Or the autonomy granted to employees?  Or the purpose behind the work?  Or big-M vs. little-m methodologies?

I think the answer to these questions is, quite frankly, that on your own you can have very little impact.  BUT!  I believe a group of like minded people, with common goals, patience, and a dash of determination can get together within any organization and make a huge difference.  Those people can become engaged in the struggle to be engaged at work!  And, as cheesy as it may be, any group of people starts with just one person.  To be successful at this you have to have a broad idea of where you're heading. If all you want to do is be like 37 Signals, you're out of luck.  But if you can embrace the real kernel of truth in all the observations found in so many places these days (including what the guys from 37s are saying), and tailor that to your organization's unique goals, strategy, and personality...  Then you will be able to make your company, or your division, or even just your team one that all your friends will be jealous of.  And everyone will end up doing better work because of it.

So if you're not engaged at work, stop looking up!  Stop waiting for someone else to change!  Get out there and get started making a difference today.  Even if just a small one.  Be prepared to lose a lot of battles, but don't let one set back prevent you from continuing to work at it.  Because it is worth working at.  And you don't have to get 100% of the way there.  You don't have to end up with a ROWE to be engaged at work.  That's because lots of little improvements will add up.  And could maybe even start a steam rolling effect.

The key is to recognize that it's worth striving for, that you don't have to keep looking up waiting for someone else to make the changes, and that its ultimately a community effort.

Software Craftsmanship

Growing and Fostering Software Craftsmanship from Cory Foy on Vimeo.

"Software Craftsmanship" is kinda sorta like the next "Agile."  As a "movement" its not really very interesting.  But if you ignore the proselytism you discover that the message is both simple and appealing.  Cory Foy does an excellent job of communicating that in this presentation.  So much so that I wanted to share it.

Movements tend to fall short because they fail to convey the context of the problems they have been created to solve.  Cory does a great job of providing the background of what the typical problems in software engineering are and follows through with clear, but broad, ideas to fix them.  This isn't a talk about unit testing, TDD, pair programming, or any other specific techniques.  Instead its a talk about the nature of the problem and what the solutions should look like and how you could begin to move in the right direction.

In short this is an inspirational talk.  Watch it!  I think you'll enjoy it.