nik codes

New Contributor? Jump In!

Coming together is a beginning; keeping together is progress; working together is success. – Henry Ford

As Ford said many years ago, “working together is success”. In the two years I’ve been heavily involved with open source software, I’ve been lucky enough to see lots of success. Unfortunately, I’ve seen even more stalled beginnings and stunted progress, and I’ve been wanting to try to do something about it. So earlier this week I tweeted an idea I’ve had for a couple of months now:

The idea for a standardized issue label for open source projects came from the two pieces of feedback I consistently hear from would-be contributors:

  1. I’m not sure where to start with contributing to project X.
  2. I’ll try to pick off a bug on the backlog as soon as I’ve acquainted myself enough with the codebase to provide value.

Of course, what really ends up happening is that the would-be contributor gets bogged down in ramp up and orientation activities and seldom hits their stride in actually providing value back to the project. More often than not, we don’t get to work together. We don’t succeed.

The Pitch

Even though there are general guidelines for getting started with open source projects (such as submitting a detailed bug report, enhancing the documentation or answering a question on Stackoverflow), and GitHub specifically supports contributor guidelines on all projects, I still find developers having problems diving into new OSS projects. The challenge is, fixing bugs usually requires intimate knowledge of the project’s code base and expected behavior, and implementing an entirely new feature may require more time and effort than the contributor has to give.

Thus, enter the “jump in” issue tag/label. The “jump In” label is meant to help developers new to a given open source project provide value back to the project quickly and to help them get acquainted with the community and code base.

Jump in items would typically:

  • Take no longer than a few nights worth of work to implement.
  • Be relatively standalone, not requiring tight integration with other in development backlog items.
  • Be well described with pointers to help the implementer.

They are not:

  • Items that the “core team” does not want to implement themselves.
  • Items that are specifically set aside for junior/novice developers.
  • Used as a hazing activity for “rookies”.
  • Designed to be fizzbuzz tests.

There was quite a conversation around what the actual label to use would be. Kelly Sommers had a great suggestion with “New? Try This!” which ultimately was decided against due to its use of punctuation and the compatibility problems those characters could cause with some tooling. Many others suggested various labels, from the funny to the insensitive, and even pointed out two instances of “prior art”.

Scriptcs leverages a “you take it” label to identify items that make sense for new contributors. I found “you take it” to be a bit unwelcoming and passive/aggressive. I personally read it as “We the core team don’t want to do this, so you take it”. I know the guys behind that project don’t mean it that way – but lacking any context that it how I perceived it.

The other instance was KDE, which has been using a “Junior Jobs” label for almost 10 years. I found that to be completely inspiring. Several similar labels were suggested for this effort during the online brainstorming session, but were dismissed due to their connotation of work suitable for junior/inexperienced developers. While I’d love to adopt a preexisting “standard”, my fear of the junior designation conflicts with my desire to make all developers feel welcome to our community; so I’ve decided to go a different way.

So is “jump In” perfect? Most assuredly not, but it is a great starting place. It is action oriented, self descriptive, and had plenty of fans on Twitter. Of course the more its usage spreads across OSS projects the easier it will be for new contributors to show up and understand where they can and should jump in.

We’ve already got a jump in list going for Glimpse and we’ll be updating our CONTRIBUTING.MD to point to it, as well as our documentation, as great ways for newcomers to get involved.

The Call To Action

Label a few issues for your OSS project and link to the list here in the comments.

See a project you’d like to help out with but aren’t sure how? Ask the maintainers if they could provide a jump in list.

I’d love to see this spread into wide adoption, and for OSS projects of all sizes to find success in working with contributors and never again experience stalled beginnings or stunted progress.

Seriously Open, Definitely Required

More and more it feels like the tide for .NET based open source projects is beginning to change and mature.

It’s been awhile since the Outercurve Foundation was created, providing a home for great open source projects like NuGet, MVC Contrib and xUnit. The foundation isn’t perfect, but it is a big step in the right direction.

More recently, MonkeySquare was created to evangelize cross  platform and open-source development in .NET. Dale Ragan and the team at MonkeySquare also put on a great open source conference called MonkeySpace which is coming up at the end of July in Chicago.

So we’ve got foundations, evangelism groups, conferences – and now, a podcast!

logo

Seriously Open is a podcast about open source in the .NET ecosystem hosted by Nick Berardi, and Justin Rusbatch who do a great job extending the conversation beyond the typical OSS fare, delving into interesting topics such as project structure, project guidelines and the social interactions that make a project succeed (or fail).

They’ve published two episodes so far and I’ve thoroughly enjoyed them both. (To be fair, I was on the second episode along with my good buddy Anthony van der Hoorn talking about our experience with Glimpse, but we were completely honored to be their first guests!)

If you are a .NET developer looking to shake things up, an OSS contributor, user or project maintainer than Seriously open is definitely required listening.

Understanding AppDomain Unloads & Old Lessons, Learned Anew

I spent the better part of two days pulling my hair out about a bug report claiming a website that opened an OleDbConnection to Microsoft Access would break Glimpse, my open source project.

I couldn’t believe it. Glimpse knows nothing about OleDb or Access, but alas, the bug was reported and I was able to reproduce it.

With reproduction in hand, I quickly figured out what was really happening. Opening the connection to Access caused the current AppDomain to unload, which in turn tore down Glimpse’s internal data stores resulting in the undesired behavior.

But why was the AppDomain being unloaded? I know tons of applications out there, running on little web servers underneath people’s cubicle desks, leverage Access as a data backend. Surely they don’t recycle the AppDomain after every database connection, do they?

Turns out, this problem would have been very easy to solve if I hadn’t oversimplified ASP.NET’s behavior in my head. I’ve known for a long time that changing a site’s web.config causes the AppDomain to recycle, but that’s only a partial truth now-a-days. With the help of a post by Tess Ferrandez I found souring the internet, I learned that as of ASP.NET 2.0 the file system watcher watches much more than just web.config for changes – including everything in the bin and its subdirectories. (I found out about several other reasons why an AppDomain might recycle from her excellent post too.)

Once I correctly understood modern ASP.NET’s behavior, I realized that connecting to the .MDB Access file in my bin directory was causing the file system watcher to kick off an application domain unload. Awesome! I moved the database out of the bin and the problem was solved.

Of course, after wasting more than a day of tinkering with this, I thought “There must be a way to figure this out without Google’ing high and wide”.

Turns out, there is! Unfortunately it’s not very obvious and requires some private reflection. Scott Gu covers the technique in a blog post from late 2005, before I was even involved in .NET.

The (simplified!) code, which you’d place in the AppDomain.DomainUnload event handler, looks like this:

var httpRuntimeType = typeof(HttpRuntime);             

var httpRuntime = httpRuntimeType.InvokeMember(
    "_theRuntime", 
    BindingFlags.NonPublic | BindingFlags.Static | BindingFlags.GetField, 
    null, null, null) as HttpRuntime;             

var shutDownMessage = httpRuntimeType.InvokeMember(
    "_shutDownMessage", 
    BindingFlags.NonPublic | BindingFlags.Instance | BindingFlags.GetField, 
    null, httpRuntime, null) as string;

The shutDownMessage will be a string describing the exact reason why the AppDomain is being recycled – which is great to log and saves lots of guess work.

Now that I know this technique, I have now begun logging all AppDomain recycles within Glimpse’s internal log in an effort to aid diagnosis of future problems like this.

It’s amazing just how easy it is to take for granted the mountain of code we build on top of everyday. This year I’m really going to try and not gloss over the lessons learned by those who came before us – just a mere 8 years ago.

NYC Code Camp Presentations

This weekend I attended and presented at the 7th (mostly) annual Code Camp NYC.

It was a great event put on my a host of wonderful volunteers, speakers and sponsors. (Full disclosure: my employer, Red Gate, was one of the sponsors.)

In my first session, Glimpse: Taking a look inside your server, I basically re-presented the presentation Anthony and I gave at aspConf. You can find the video of that talk on Channel 9.

For my second session I presented new talk based on some of the things I’ve been learning at Red Gate. The talk, called Performance Profiling 101, was really well attended, with a few rows of people sitting on the floor!

photo

We handed out copies of Jean-Philippe Gouigoux’s excellent book Practical Performance Profiling: Improving the efficiency of .NET code to all who attended. (The book is also available as a free PDF download.) I highly recommend reading this book if you are at all interested in performance and performance profiling

The slides from the presentation are posted online, however, the resource hyperlinks at the end of the deck are not retained by SpeakerDeck. I’ve reported a bug/feature request to SpeakerDeck, but until that is resolved I’ve included the resources here:

hpwsefwsdetuhnmm

New Job

“Choose a job you love, and you will never have to work a day in your life”.

It’s no secret that my love of web development has materialized into Glimpse, the project I started a little over a year ago with Anthony Van der Hoorn. I’ve had an amazing ride with Glimpse; becoming an ASP Insider, getting to meet many of my dev heroes and working with fantastic contributors from all around the world.

About a month ago that ride took a new and unexpected turn. An opportunity to work full time with the open source community on our little project arose from a seemingly unexpected source: Red Gate.

Red Gate

I was taken surprised by Red Gate’s proposal and spent several weeks with Anthony and Red Gate’s top brass discussing our philosophies of open development, open source, ASP.NET, the web development community, software development practices and yes, even Reflector. As the discussions progressed I became more and more convinced that Red Gate genuinely believed in our vision of Glimpse, our model of development, and most importantly, the community that we were serving. Given that, I decided to take a new job with Red Gate – getting to focus a much larger portion of my time on the things I love: Glimpse and the web development community.

There are a lot more details about what this means for Glimpse on the Glimpse blog, so I won’t rehash that here, but in summary it’s all positive. From a personal perspective, I will remain in New York City, and, in addition to spending a majority of my time working on Glimpse, I have also been given the opportunity to interact with the community. This basically means that part of my new position requires writing blog posts, speaking at user groups/meetups, working with open source and attending conferences like Monospace in October.

This is all new and very exciting to me. Keep an eye on this blog and my twitter feed for updates as things progress.

NYC ALT.NET: Building Win8 Metro Apps with JS & HTML

At the July meeting of the New York ALT.NET Meetup, Microsoft developer evangelist Rachel Appel presented a session on building Windows 8 Metro style applications with JavaScript and HTML. Here are my notes from that presentation.218420_980

  • In a room of ~40 developers, all said they felt comfortable with JavaScript, but only one or two considered themselves to have any design skills.
  • The presentation started with a quick demo of Windows 8 running on Rachel’s tablet. It was all pretty standard stuff if you’ve seen Windows 8. If you haven’t – head straight over to the Building Windows 8 blog and read up right away!
  • To build Windows 8 apps, you have to have Visual Studio 2012 running on Windows 8 itself. Visual Studio 2012 does work on Windows 7, you just can’t create Windows 8 Metro apps with that configuration.
  • Out of the box, Visual Studio 2012 has several JavaScript based Metro templates that have lots of build in features, including some layout and styling along with the usual library references.
  • There does not appear to be a built in UI pattern like MVC or MVVM. I assume that libraries that help structure code, like backbone.js or knockout.js, will be popular.
  • There is a concept of “pages” (not HTML pages) built into the template. These were not covered in depth – I need to research this more.
  • I was happy to see the ECMAScript5’s “use strict” directive in use in the template code.
  • No additional work is needed to get basic touch gestures working when using the JavaScript controls.
  • Running (IE:F5 Debugging) an application from Visual Studio causes the application to open up in full screen mode. This makes break point debugging very painful with lots of Alt+Tab window switching.
  • A simulator (not emulator) can be used to ease this pain. The simulator is basically a remote desktop connection, back into your own machine, which shows the application running along with tooling to do things like rotate the device orientation and simulate touch events/gestures.
  • Once an application is deployed to the app store, and downloaded by a user, it is placed in an obscure Program Files directory. If a user finds the application, they would be able to view the source JavaScript. If this is a concern, Id recommend using a JavaScript obfuscator like UglifyJS.
  • Visual Studio will show you the JavaScript source for the core libraries, but it will warn and stop you from changing said source. Since JavaScript is dynamic, you could replace a method implementation at runtime.
  • Visual Studio tries to guide developers into properly implementing the Metro UX guidelines. A full set of documentation and resources can be found in the Windows Dev Center.
  • Interesting point made about the reduced relevancy for HTTP caching/CDN’s in HTML based Metro apps since a majority or resources (sans data/JSON) will be included in the bundle.
  • Metro style JavaScript applications run in IE10 under the covers – no surprise there.
  • Html “controls” use standard elements (IE: divs) with data-* attributes.
  • Application manifest file (XML) contains tons of settings, but there is a nice editor for the file that hides away the XML and makes editing “easy”.
  • Access to device API’s (camera, geolocation, etc) must be approved by user, similar to Facebook’s permission model.
  • Background tasks are supported.
  • Applications can have many entry points like a tile click or a search result.
  • Side loading of applications is handled by Visual Studio.
  • Tiles can be short (square) or wide (rectangle), live or “dead” – users choose and developers should accommodate those preferences.

All in all, it was a very informative session. It was video recorded, so I’ll update this post as soon as the video is posted online.

Front End Web Developer Podcasts

I’ve always been a “jack of all trades” web developer. For most of my projects I’ve owned everything from the client side HTML/CSS/JavaScript to the server side processing/database/service calls.

I find it very easy to focus on the server side, especially in the .NET community, with all the great things to play with in ASP.NET MVC, NuGet packages, SQL Server improvements, etc. Recently, however, I’ve really been enjoying getting back into client side development. The browser vendors are moving at a very rapid pace, continuously adding functionality and expanding the capabilities of what can be done on the client.

With so much acceleration in the browser space, I’ve found a few podcasts particularly helpful and informative:

shoptalk

ShopTalk

Great coverage of CSS, HTML and industry happenings with Dave Rupert and Chris Coyier of CSS Tricks fame.

 

nbs

Non-Breaking Space

Interview style show with the best and brightest minds on the web.

My favorite episode thus far was their interview of Paul Irish, a member of the Chrome Developer Relations team.

webAhead

The Web Ahead

The Web Ahead has the longest running time of this list, but because of that they often get into slightly deeper, more nuanced conversation.

 

Of course, I still listen to Hanselminutes and Herding Code, but they don’t typically cover front end dev.

What front end podcasts do you recommend?

The Saga of Readme Files and NuGet

When we released Glimpse back in April of 2011, we included a readme.txt in our NuGet package providing brief documentation and instructions to help users understand how to get started with Glimpse.

Problem was, nobody read it.

Even worse, nobody knew it was there.

nuget powershell

So at the end of June 2011 we added a little NuGet and PowerShell magic to our package that would open up the readme file for the user in Visual Studio upon package installation by adding a tools/install.ps1 file:

param($installPath, $toolsPath, $package, $project) 
$path = [System.IO.Path] 
$readmefile = $path::Combine($installPath, "path\to\your.file") 
$DTE.ItemOperations.OpenFile($readmefile) 

This simple script has been working well for us over many releases and thousands of downloads, but I’ve always felt that this functionality should be built into NuGet itself. Apparently I’m not the only one that feels this way, as there has been a feature request on CodePlex for this since October 2010 asking for this very thing. (The comments on this thread are a good read. Full disclosure, I am a participant on it.)

Fast forward to last week, when Drew Miller tweeted:

This is great news, as now NuGet will essentially do what I’ve always hoped it would: open readme.txt files automatically. The new feature, coming in NuGet 1.7, builds upon NuGet’s convention over configuration roots by opening a file named readme.txt placed in the root of the package. This will facilitate simple readme.txt discoverability problems like we had with Glimpse – which is wonderful and should cover most use cases.

For more advanced scenarios (IE: opening other file types, opening files from other locations, opening multiples files, supporting older versions of NuGet, etc) feel free to use the PowerShell script above.

Please note, NuGet 1.7 is not yet released and does not currently have a published release date.

Integrating SpecFlow and xUnit

This post is all about getting SpecFlow, my favorite .NET BDD framework, and xUnit, my favorite .NET unit testing framework, playing along nicely together.

NuGet itself does most of the heavy lifting here, but there are a couple of gotchya’s along the way. First, the easy stuff:

  1. Create a standard Class Library project in Visual Studio.
  2. Using NuGet, add the packages SpecFlow, xunit and xunit.extensions with either the Package Manager Console or Manage NuGet Packages dialog.consoledialog xunit.extensions is required for some of the more advanced Gherkin syntax scenarios.
  3. With this in place, SpecFlow will still generate nUnit tests. To configure it to use xUnit tests, create an app.config file in Class Library project with the following content:
    <?xml version="1.0" encoding="utf-8"?>
    <configuration>
      <configSections>
        <section name="specFlow" 
    type="TechTalk.SpecFlow.Configuration.ConfigurationSectionHandler, TechTalk.SpecFlow" /> </configSections> <specFlow> <unitTestProvider name="xUnit" /> </specFlow> </configuration>

That’s it, SpecFlow will now generate xUnit tests which should compile perfectly.

I’ve wrapped all of these steps together into a NuGet package, tentatively titled SpecFlow.xUnit, and contributed it to the SpecFlow project on GitHub. They have just accepted my pull request, so hopefully we’ll see a one click package to integrate these two great libraries on NuGet.org very soon!

Of course, the real beauty of SpecFlow is its Visual Studio integration, which you can install from the Visual Studio Extension Manager. It provides item templates and step debugging on Gherkin .feature files.

vsspec

I have a few issues with the way that Visual Studio’s Extension Manager works, but that’s another post and has nothing to do with SpecFlow.

Meta in your head

UPDATED: After some Twitter conversation with @Phil_Wheeler, @brianblakely and the @h5bp team, Brian has added info about the X-UA-Compatible meta tag go the HTML5 Boilerplate Head Options page. If you are not familiar with the HTML5 Boilerplate project, you should definitely check it out.

The <meta> tag is one of the most commonly used tags within the <head> element of many web pages. <meta> tags are used to convey all types of metadata about a given page to the browser or a search engine spider, including:

  • Search engine keywords and descriptions
  • IE9 Jump List definitions
  • Mobile browser icons
  • Facebook application data, and LOTS more…

    The Internet Explorer team recently announced that the “metro” version of IE10 would begin to support a new <meta> tag for sites that require the use of browser plug-in’s like Adobe Flash and Microsoft Silverlight:

    <meta http-equiv="X-UA-Compatible" content="requiresActiveX=true" />

    The X-UA-Compatible <meta> tag forces IE10 to pop up a dialog asking the user if they would like to open the current page in the “desktop” version of IE10, which does support browser plug-ins. The dialog looks like this:

    metroIE10

    There are so many useful <meta> tags that it’s hard to keep track of their name’s, values and purposes. Luckily, there is a pretty good resource to help out with that:

    Brian Blakely has a great Gist that he calls “Helpful things to keep in your <head/>” which does a good job of documenting many of the most popular <meta> tags. I’ve forked his Gist and added the X-UA-Compatible tag. Unfortunately, GitHub doesn’t allow for pull requests on Gist’s, so I’ve asked Brian to include X-UA-Compatible in his Gist via a comment.

    I think that it would be helpful to turn Brian’s Gist into a full fledged <meta> tag database, which could also include useful <link> tags, such as those used for OpenID delegation. I’ll add the idea to my personal backlog – unless you, dear reader, want to take that on. Winking smile

  • Post Navigation

    Follow

    Get every new post delivered to your Inbox.