techbash

TechBash 2016 is a brand new developer conference taking place on September 28-30, 2016. I’m one of the organizers along with a small group of friends from the developer community. TechBash will feature great presentations for you by a variety of awesome speakers from around the country. Our venue, the Kalahari Resort is really cool. It is a brand new Resort, Conference Center, and 100,000 sq. ft. indoor water park! TechBash is located in the Pocono Mountains in PA. That means it’s not only a beautiful setting but it’s close to many people living in the northeastern US. It’s less than a 2 hour drive from New York City, Philadelphia, and northern NJ. And this location is still within reasonable driving distance of many other cities in the northeast!

Our goal is to inspire our attendees to build great things. At TechBash, we are building an environment that is designed for attendees to get the most out of the event. In the many sessions at TechBash you will learn all sorts of new things. But we know that a lot of great things happen outside of the talks as well. That is why we will have a great attendee lounge that will have plenty of space for you to hang out and talk with old friends and new. It will provide a great place for speakers and attendees to have follow up talks after sessions. There will be snacks and coffee. And it will also include our Hack Lab and our vendors as well. The Hack Lab is a space for our attendees, speakers and sponsors to collaborate, brain storm, hack and even demo the results!

TechBash is a community driven, non profit event (although not a charity) organized by the TechBash Foundation.

If you are already hooked, just register (registration info is below)! And please read on if you need a bit more convincing…

Content is Key!

Our goal is to be technology/platform agnostic. We know that nowadays, developers are interested in all kinds of stuff and there is a lot to learn for us all. Having said that, the agenda is weighted towards Microsoft Technology.So while we have content on ASP.Net (including Core), Azure, Xamarin, Visual Studio, C# and more, we also have talks about JavaScript, Docker, Go, Design Patterns, Web Security, OSS, Agile, and more. For all of the latest details, check out the session list. Keep in mind, as with any event, the schedule is subject to change.

Location, Location, Location

imageAs I said above, TechBash is pretty close for many people in the northeastern US. Sure, those of you from NYC to Philly are all set with a simple 2 hour drive. But if you are from DC to Boston to Pittsburg and beyond, this location is a reasonable drive for a 3 day event! Here are some drive times (according to Google Maps – your times may vary Smile). No air travel required!

City Drive Time City Drive Time City Drive Time
NYC 1:48 Philadelphia 1:53 Harrisburg, PA 1:59
Toms River, NJ 2:19 Syracuse, NY 2:28 Albany, NY 2:58
New Haven, Ct 2:49 Baltimore, MD 3:14 Wash. DC 4:01
Providence, RI 4:24 Buffalo, NY 4:43 Boston, MA 4:48
Pittsburgh, PA 4:51

 

Destination: Fun

Ok, so you are headed out for a 3 day tech conference. That doesn’t mean you can’t have some fun too! We’ll fry your brain all day long with tons of great content that you can take back to the office and put to good use. But in the evenings, why not enjoy the 100,000 square foot indoor water park? TechBash is hosted at the brand new Kalahari Resort and Convention Center. Yeah, it’s a state of the art conference center and great hotel. But they have restaurants, a Spa, an arcade, indoor mini-golf, hiking and more. Oh, did I mention the 100,000 square foot indoor water park?

waterparkwaterpark2waterpark3

 

Is this a family event?

Yes and no. We know that other similar conferences have kids’ tracks and family content. Plus, there is the water park. While the venue is certainly family friendly, TechBash won’t have any family content in year one but it is part of our long term plan. Let’s get through one year with content for the “big kids” only. But if you want to bring your family, please do so! We are sure they will have fun!

Sponsorship Opportunities Available

We’d love to work with your company as a partner to help make TechBash 2016 even better. Check out our website and our prospectus for more info and then contact me to get things started.

Want to help out while you are at TechBash?

Yeah, we’ll need some help running this event. If you want to help out, sign up, there is a simple form on the bottom of the website.

The most important part: Registration

Registration is easy, there are two simple steps:

  1. Click here to purchase a conference ticket on EventBrite.
  2. Book a room at the Kalahari. Just call 1-855-356-9208 and mention TechBash to get the best rate.

Thanks for reading. I’ll post more information about TechBash soon.

I had a great time on Friday 3/20 presenting “End To End Development with Schwammy’s Favorite Patterns and Practices”. Thanks to everyone who came out and sat in a packed room for a full day. And even though we had a pretty large spring snow storm, I’m pretty sure everyone stuck around for the whole day. I hope you all made it home safely.

In this talk I covered a lot of content. If you need to follow up with me on any of these topics, feel free to contact me directly or comment on this post.

Thanks for the great feedback you all provided. The response was very positive. There were a few good suggestions and I’ll definitely be taking them into account when we plan a repeat of this presentation.

Here are the files I promised. I hope the solutions all work out for everyone. Please let me know if there are any problems.

By the way… one last tip… I used one of the VS Extensions that I talked about, VSCommands, to create the zip files for download. VS Commands has a feature allowing you to right click in Solution Explorer and Zip up the solution. It will automatically remove source code bindings, ignore bin directories, and more. Very cool.

Note that the sql scripts for the ELMAH database are in the solution in the App_Readme folder.

If you haven’t heard already, there are two new user groups starting up in the Philadelphia Area. Both are hosted on meetup.

ALM

The first is Philly Application Lifecycle Management User Group. The group’s first meeting is Thursday 2/27, 6pm at the Microsoft MTC in Malvern. The topic is “Getting the Most from Team Foundation Server 2013. And the speaker is… ME! I hope you’ll come out and help get this new group started. Here is a summary of the talk:

TFS is a powerful tool for many things including Work Item Tracking, Source Control and more. But what can you do when the standard templates just don’t fit your needs? Every team is different. Did you know that it is actually pretty easy to customize many parts of TFS to fit your team’s process? I’ve recently upgraded an entire IT department’s source control and work item tracking from TFS 2008 to TFS 2013. During the process I customized many facets of TFS. In this talk, I’ll share what I learned along the way. When we are done, you’ll be set to start getting the most from TFS.

Xamarin

The second new group is the Philly Area Xamarin Group. Their first meeting is Tuesday March 11. Looks like the first one is a meet and greet at Field House in Philadelphia. That sounds like fun.

I’m in the process of migrating our TFS Instances to 2013. During my research I’d seen demos with the “Features” feature. In TFS 2013, there is now a Work Item Type named Feature which is meant to be a parent to several Product Backlog Items. I was able to easily create features but I also knew there is supposed to be a Features Backlog. On my TFS cloud instance it works fine but there was no sign of the Features backlog on the web interface for my On Premise instance of TFS 2013. The screenshot shows what I was hoping to find. Continue below to find out how to enable it.

image

It turns out that getting this to show up was really quite simple but not exactly intuitive. Features needs to be enabled as part of the Access Levels portion of TFS.

On the top right side of the TFS web app, click the “gear” to go to the control panel.

image

You may see this menu. If not, skip the next step! If you do, just click the Control Panel link to go to the main control panel page.

image

Hopefully you will see a menu like this:

image

From here, click on “Access Levels” and you’ll see something like this:

image

 

You will see that there are 3 choices for access levels. We’ve got “Standard” set as the default. I’m not positive we’ll keep it this way and every team should decide for themselves what they want to do about the default. However, you must have “Full” Access to see the “Features” backlog. So add some users to that level or set it as the default. Once you do, users with Full Access will see the Features Backlog (similar to the first screenshot in this post).

I’m not exactly sure why the access levels are set up like this. I’m new to TFS2013 so it may be possible to set this visibility in other ways. But it seems odd that enabling the Features backlog is tied to other features like “Team Rooms” and “Test Case Management”. Those are great features but I am not sure why they are all lumped together.

One lesson I have learned over the years is not to take any unnecessary risks during production deployments. I hope that by sharing this wisdom I can help others, but I have the sad feeling that this one of those lessons that people need to learn the hard way. Unfortunately it is too tempting to “just go for it” sometimes. If it works, consider yourself lucky. When it fails (and sooner or later it will) you will regret your cowboy ways. I hope you will read on, there are some great ways to mitigate the risk of deployments.

Most of the problems that occur during deployments are caused by simple human error. Nothing serious, just plain old forgetfulness! In my experience, deployment issues usually arise because someone just forgets to do something. The thing that gets forgotten could be anything from a database script that gets missed, a forgotten view, an overlooked setting, or a .config file omission. And I don’t mean that this happens because someone is a bad developer. It’s just human nature. We are not perfect and can’t possibly remember everything.

There is no foolproof solution for perfect deployments. However, by following these tips you can greatly increase your likelihood of success. Of course, any of these practices will help but for best results, combine them all.

Deploy as often as possible

The best way to make sure nothing gets missed is to deploy often. Time is your enemy, the longer you wait, the more likely you are to forget something. During the development process we do so many things to make our applications work properly in our development environment. Sometimes we use a lot of trial and error too. As time goes on we can’t possibly remember all of the steps we have taken along the way. Following an agile process with short sprints is a great way to achieve short deployment cycles. Agile or not, try to deploy when features are complete and at major milestones. You don’t need to actually deploy to production. Use the same deployment process for all your environments. If you can’t deploy to production (there are lots of reasons for this), create a staging environment and treat it like production.

Take notes

Even if you deploy often, don’t rely simply on your memory. Take a lot of notes along the way during development and during your deployments to other environments such as test, staging, etc. Develop a good system so that your notes are there when you need them, not buried and forgotten in a notebook somewhere. I like OneNote for stuff like this.

Have a solid plan

Don’t wing it. Have a good, standard plan and stick to it. The more you follow the plan, the more likely you are to succeed.

Use a good code base

Of course, you only deploy code that you know works correctly, right? Once you know it works, don’t leave anything to chance. One of the best ways to do this is to deploy the same code to all your environments. Avoid going back to your source repository and recompiling. So many things can go wrong once you do. After you deploy to your test environment and everything has been verified, you should use the exact same files (.dlls, script files, whatever) and deploy them to prod (or your other environments). Of course you will be probably need to make configuration changes, that is often unavoidable.

Watch your timing

Find a time that works good for you and your team. Different businesses will have varying constraints on when they can do production deployments so you will of course need to work within those parameters. But I definitely have my preferences for when I would choose to deploy. I like to deploy first thing in the morning when I am fresh and thinking clearly. If something goes wrong, I have a lot of time to fix it. Also, I’ll have access to other people/resources for help if needed. If I deploy at the end of the day and something goes wrong I’ll be stuck working at night to fix it. That is bad because a) I’ll be getting tired and might not think clearly, b) I won’t have people around to help and c) I won’t get to have dinner with my kids. I also like to deploy midweek. Monday mornings are bad because over the weekend I have forgotten things already! Monday is a great day to put final preparations on a big deployment. Fridays are bad too. Because if things go wrong, I could be stuck trying to fix things over the weekend!

Automate your process

I don’t trust myself or my memory much. The best way I can protect myself from me is to automate my deployments. Once things are scripted, automated and tested, I have greatly increased my chances for success. Most of the other tips I have listed are fairly easy to implement, but putting together an automated deployment can be a big project all in itself! Depending upon your project, automated deployments can be quite complicated and there is a lot to learn in this department. There are lots of great build and automation tools out there to help such as MSBuild, NAnt, TeamCity, Hudson, CruiseControl, etc. I’ve used a bunch of different tools over the years and now I am using Team Foundation Server 2012. I’ve found it to be the easiest and fastest of all to set up for my web project deployments.

Practice your deployments

Practice makes perfect, right? Unfortunately with deployments, just when you get your process working smoothly there will be some big change that will require you to modify the process anyway. But practice will definitely increase your chance for success. I even practice my automated deployments, that is the reason to have a staging/faux-prod environment. And practicing really comes in handy when it comes to database changes. It’s great to have a staging environment set up just for the purpose of practicing deployments. To practice, get your staging environment set up to match your production environment including .dlls, html and script files, databases and other resources. Then run through your deployment process on staging. Once complete, test your application to make sure everything works. If something went wrong in the deployment, don’t patch it. The best thing to do is roll back the entire staging system, tweak your process and run it again. You do this as many times as needed until you get everything right. Then you are ready to repeat your steps in your production environment. Of course, the more you automate, the less likely errors will be. But don’t assume that just because you have an automated system you don’t need to practice too.

Start soon

Lastly, do not wait to implement this process. Many developers wait, thinking that they’ve got a long development cycle and won’t be deploying to prod for a long time, maybe months down the road. When I start a new project I begin working on the build/deployment automation right away. I also make sure there are tasks created for this process. Making this an official deliverable buys me time for this work which can definitely be time consuming. And if you don’t get this work done early, you might not get to it at all. When a project is almost complete and the delivery date approaches, you will never find time to get your process in place. You will then be stuck with an error prone deployment that not only keeps you worried but will likely cause you to work on weekends fixing deployment issues.

 

A solid deployment process takes a lot of planning and work. Of course, if you have ever been on the wrong side of a bad deployment you know that all the planning is worth the extra effort! Good luck.