It’s a new year, and I’m grateful to have started things off at a conference like CodeMash to sharpen the saw and re-energize. Similar to previous blog posts, I’d like to share some highlights from the sessions I attended. The single biggest takeaway from each session is also bolded for you tl;dr lovers. 😉

Same disclaimer as always: Please keep in mind this is only my paraphrasing or lessons learned from each talk, and may not be even remotely accurate of what the speaker was trying to convey. We all hear what we want to hear.. 😉

When onboarding, provide a mentor who will willingly answer questions and is easily available

CodeMash 2019 Summary

I had a fantastic time at CodeMash and so much of the content was extremely relevant to where I’m at today. I want to express my gratitude to the speakers, organizers and everyone involved in making CodeMash an amazing experience.. as well as my employer Viral Launch who made it possible for me to go even when there’s always pressing priorities in the office.

I was fortunate enough to be back at Indy.Code() for year 2 and try out the workshops as well this time around. Similar to before, I wanted to share some highlights from the sessions I attended. 🙂 I also bolded the biggest takeaway from each session, in case you want to skim even faster.

Please keep in mind this is only my paraphrasing or lessons learned from each talk, and may not be even remotely accurate of what the speaker was trying to convey. We all hear what we want to hear.. 😉

If at the end of an 8hr day your code was printed out and you had to re-enter it, on average ~30 minutes

We are knowledge workers, not typists.

Relying on the group to think about non-trivial problems can actually reduce one of the biggest slow downs in development – the hours when you get stuck on a problem and can’t immediately see through it by yourself.

When mobbing, get each person to the keyboard every hour

Patience is critical, the primary goal isn’t maximum throughput but common knowledge of the solution

Indy.Code() 2018 Summary

I really enjoyed the conference again this year and am very grateful to have something pretty awesome so close to home. A LOUD thank you to the organizers, speakers, sponsors, staff and everyone who participated in Indy.Code().. as well as to my employer Viral Launch for letting most of the team and I take the time out to sharpen the saw and refresh the passion for development. 🙂

I was lucky enough to hear about and get to attend the inaugural Indy.Code() conference last week. It was fantastic, with a lot of really relevant content, well prepared speakers, motivated attendees and well organized to boot. It sounds like they’re planning on another go-around next year already.. and I highly recommend you check it out if you can!

Similar to before, I’d like to share some highlights from the sessions I attended. 🙂 I also bolded the biggest takeaway from each session, in case you want to skim even faster.

Please keep in mind this is only my paraphrasing or lessons learned from each talk, and may not be even remotely accurate of what the speaker was trying to convey. We all hear what we want to hear.. 😉

Reused switch keyword instead of the more popular match keyword to avoid backwards compatibility break with existing programs that use the word ‘match’ as a variable (yep I’ve got a few of those in CodeMaid)

F# pattern matching is first class, C# is more of a bolt-on that isn’t as fleshed out

Classic FizzBuzz can be solved using C# 7 tuples and when clauses on case statements.

Indy.Code() 2017 Summary

I was really impressed with this conference and want to say a big thank you to the organizers, speakers, sponsors, staff and everyone who participated.. well done and thanks for a great time! I hope to see you next year. 🙂

It’s the start of a new year which means it’s CodeMash season and I’d like to share some highlights from the sessions I attended. 🙂 I also bolded the biggest takeaway from each session, in case you want to skim even faster.

Please keep in mind this is only my paraphrasing or lessons learned from each talk, and may not be even remotely accurate of what the speaker was trying to convey. We all hear what we want to hear.. 😉

There’s an off chance you may forget to add a PartitionKey property value to all records before migration. DocumentDB will allow you to create documents without a PartitionKey, but querying for them is a little more tricky.

Art recognizes value in the process of creation, and in the thing that is created in itself – not just in the utility of what the creation does which is how we generally evaluate code

Code can be art, with or without great utility

All of the worst things in coding (estimation, status meetings, micro management) can be jettisoned so the best things in coding (creation from nothing, imagination) can flourish when making something useless

Happiness and laughter are worth creating, so useless things may not be actually useless at all

Summary

If you haven’t been to CodeMash, you should check it out. There’s a great community, great content and a very modest cost. My sincere appreciation and gratitude to all of the speakers, organizers and everyone who helps participate to make it all possible. 🙂

The WPF TreeView is very powerful, but out of the box it doesn’t support selecting multiple items at once. By multiple selection I mean holding down the control key or shift key to select a set of items, similar to behavior available in other controls such as Windows Explorer.

To support enhancements like dragging and dropping multiple items at once to CodeMaid‘s Spade tool window, we wanted this capability to multi select. There’s several different solutions out there, and in particular our implementation is largely based on the great work of Cristoph Gattnar available here.

Christoph’s solution utilizes attached properties. Our solution converted this to a behavior and added support for arrow keys and the space bar for more keyboard navigation scenarios.

Here’s a little example of it working in action:

Multi-Select

The living code can be found within CodeMaid’s open source repository here.

We made it back to Kalamazoo X this year for another day of soft skills, and I have to say it was even better the second time around. 🙂

Similar to the CodeMash post a couple months ago, here’s my set of bullet point take-away’s from each of the sessions. They may be taken out of context, and are absolutely tainted with my perspective and interpretation – but hopefully they encourage you to catch these talks at other conferences. Every one of the speakers had a great message and is worth taking the time to hear.

Note: You can also get excerpts from each of the talks at the conference site here and see a lot of chatter on Twitter at #kalx15

As I’m starting to dabble with Gulp, it is wonderful to see support for it already well underway within Visual Studio. Kudos to Microsoft/Mads Kristensen for embracing a community solution and making it compatible with the IDE we love. There’s a lot of wonderful articles out there by Scott Hanselman, John Papa, Dave Paquette and others talking about what these tools are and how to get them up and running in Visual Studio. I’m not going to recap any of it here as it’s already been well stated. 🙂

What I didn’t find out there was how do I take Gulp the rest of the way out to a production server? Specifically, how can I get Gulp to run via MSbuild on a TFS2013 CI build server, and then make sure that output can be picked up and deployed via Web Deploy? Works on my machine is great, but I <3 my CI and automated deployments. Here’s what I learned that can take us the rest of the way to Works in my build and deployment pipeline.

Note: With the solution below, you don’t need to have the Task Runner Explorer extension by Mads Kristensen as referenced in the articles – but it can still be pretty helpful for visualizing output or ad hoc runs.

Phase 1: Conquer the universe

Pre-build events (spoiler: too soon)

The commands are pretty straight-forward. We make sure we’re in the project directory on the build server, we call npm install to pull down our dependencies, and then we call out to Gulp. This looks great, and it seems to work locally.. sometimes.

Wait, sometimes?

In my case I’m utilizing TypeScript. What’s happening is that on a rebuild (or clean build), TypeScript has removed all the JavaScript files (or they haven’t been built yet) and there’s nothing for Gulp to find. On a second build, Gulp finds the old JavaScript output and then it works. Two compile passes isn’t going to fly.

Alright, pre-build events are out – let’s wait until after the build so we know all the TypeScript->JavaScript compilation is complete.

Post-build events (spoiler: too late)

Same setup, we’ll just try it a little later.

Now our Gulp output is getting generated (yay!).. but it happens too late to be picked up by Web Deploy which actually occurs prior to post-build (boo!).

So pre-build is too soon, and post-build is too late. It’s time to turn to custom targets in our .csproj file. Trust me, it sounds scarier than it really is – we’re devs, we’ve got this. 😉

Extending our .csproj with custom targets (just right)

Manually edit your .csproj file and at the bottom (must be after all Import lines) we’re going to add some new content.

What we have done here is specify a PropertyGroup to extend the existing CompileDependsOn target to add our own custom target called ‘GulpBuild’. On our target, we can specify other targets that need to happen first – such as CompileTypeScript. Now we know that TypeScript compilation will happen first, and we’re in the pipeline long before deployment occurs. For more details, check out this article on MSDN or Sayed Ibrahim Hashimi’s wonderful book on MSBuild.

What about triggering a gulp cleanup script when we clean our solution in Visual Studio? It’s a very similar extension:

Fantastic. At this point, we’re now able to run Gulp both locally within Visual Studio as well as part of our build process!

Hooking into Web Deploy

So what’s left? Well, by default Web Deploy isn’t going to pick up any of our output from the Gulp pipeline since it isn’t a part of the project. So we need to explicitly point it at our build output. There’s a couple helpful articles that talk about the approach in more detail on ASP.net and by Sam Stephens.

This is a bit harder to read, but in essence again we are extending existing targets with our own custom target. That target is collecting any files that exist in a ‘build’ folder (you can replace the 2 occurrences of ‘build’ with ‘dist’ or whatever folder convention you use), and synchronizing them across into the deployment package with the same folder structure.

Bringing it all together

Combining those pieces we’ve now got a project setup that will run Gulp both locally and on the build server, is compatible with TypeScript generating JavaScript, and is compatible with Web Deploy. If you’re raising your arms in triumph here.. thanks for joining me. 😉

Bonus round – conditional gulp

<Exec Command="gulp build --mode $(ConfigurationName)" />

You may have noticed I snuck something else in the final version – passing the build configuration into Gulp as a command line argument called mode. Using tools like yargs and gulpif you can then tailor your Gulp pipeline (e.g. not running uglify in ‘Debug’ mode). If you want more details please post a comment.

Other approaches

After posting this article, I ran into two other approaches solving the same problem in slightly different ways. All three of our posts have been in March, so clearly this is the month for automating builds. 😉 Here’s links to those alternative ways:

Summary

By utilizing custom targets in our .csproj file, we’re able to utilize npm and Gulp consistently both on our local Visual Studio instance and on our TFS build server. We can also make sure our generated build output is picked up by Web Deploy and lands on our servers.

Thanks again to all the referenced authors and articles for guiding me to this solution. No promises this is the only way (or even a good way) to do it, but it works for me and hopefully gives you some ideas too. 🙂 Please chime in on the comments any thoughts, questions or improvements!

I was fortunate enough to get to attend CodeMash once again this year and wanted to share some of the great information I picked up. These bullets are highlights from my notes and may be (i.e. definitely are) tainted with my own opinions/perspectives. So if you dislike/disagree with anything, don’t judge the speaker blame the messenger. 😉

Metaprogramming is a broad subject, but specifically talked a lot about code generation via T4 and Roslyn

Five principles to metaprogramming – you control the results, metadata is distinct and flexible, metaprogramming should be the easiest way to get it done, human crafted code is sacred, resulting code is the highest quality

Good metaprogramming characteristics are very similar to code principles (e.g. DRY, SoC)