Warning: This post describes how I modified a commercial power supply, this is dangerous! You have to know what you are doing or you will kill yourself. I’m not responsible for anything you do.Read full post
- Read full post
Here is another common helper function/type that I use frequently. I often find myself writing edit forms with knockout and it seems that I always want to have a cancel button on those edit forms. TrackableObservable tracks its original value so that you can call the reset and it will revert back to the original value. I have seen a few implementations of this type but they all seemed to wait for a “commit” action before changing the value, this means that if you are taking a dependency on that value for other parts of the from (think a checkbox that turns more UI on or off) you would need to call commit or depended on the “uncommited” value property. I choose to make mine an optimistic ”commit” and have the ability to revert. This makes the implementation simpler and also taking dependencies on the TrackableObservable easier. Let me know what you think.Read full post
If you have taken the time and care to get JSHint up and running in your builds thats awesome but you’ve probably noticed that in Visual Studio you can’t just double click the error message and go to the line number in the file. This is because the default formatters for JSHint do not output a in “Visual Studio aware format.” You can read more about this magic here. Bellow is an image that details the gist of what the format needs to be:
If you’d like to have this awesomeness then here you go just modify your runner script (Likely WSH) to include these formatters. Enjoy!Read full post
I recently gave a talk at the ALM Summit on Practical HTML5. If you are thinking about using this cool new hipster thing called HTML5 but you have to support downlevel browsers I highly recommend checking this talk out. Slides and Demos are posted right now and the video recording will be posted once the ALM Summit gets around to encoding it.
http://osbornm.com/Talks#ALMSummit2013Read full post
Today I would like announce that November 2nd, 2012 will be my last day at Microsoft. My journey at Microsoft started almost 4 and a half years ago, on June 1st, 2008 when I moved from Salt Lake City, Utah. I had recently finished college and was working at a small startup and needed a change so off to Microsoft I went. I started on the ASP.NET team as a Software Development Engineer in Test (SDET) and in February of 2011 I officially made the switch from SDET to Software Development Engineer (SDE). During my time at Microsoft I have worked on WebForms, MVC 2/3/4, WebPages 1/2, NuGet, and the HTML based Azure Management Portal. So basically a little bit of everything AAPT (Azure Application Platform Team) has to offer. Additionally, I have been lucky enough to get to travel and speak at several conferences, some of you may have even seen some of my talks. I am so grateful for the opportunities and experience that Microsoft has given to me over the last four and a half years. As for the new beginning that comes from this end, I have decided to take a position with a smaller / startup company (details to come with time). I will still continue, as much as possible, to contribute to NuGet as well as continue to blog (I know I haven’t for awhile) about Microsoft technologies and everything else tech based.
[ Update: Where am I going? ]
Over the last week, or so, I have got a lot of questions about where I was heading to. I personally felt a little wrong giving publicity to a different company when I hadn’t started working there or was still working at my previous company. Well that all ends today, I would like to announce that I will be starting at Tier 3 tomorrow morning (11/12). I look forward to getting to work with some of the industries best and brightest, learning Exponentially along the way.Read full post
Today I had the pleasure of giving a presentation at the //BUILD conference in Anaheim, CA. Given that this conference is all about Windows 8 I was one of the few non windows session at the conference. Bellow is the abstract from my talk entitled. For those of you that weren’t lucky enough to get to come to //BUILD there is good news! All the session will be recorded and posted online and that includes mine. You can find a my session session on Channel 9 (although it may take a day or so to get posted). If you want to download the demos and slides head of to my Talks page on my website and if you have questions please don’t hesitate to email me!
Recently I have been spending a fair amount of time working on the NuGet Documentation site (read more about it here). One of the improvements I wanted to make to it was to add useful error pages. You know more than the YSOD (yellow screen of death). One of the major issues for me was creating a useful and informative 404 page. I wanted the page to tell the user why they got there, offer suggestions about what page they may be looking for, and allow them to search the site. So I did the development work committed the changes and had the CI machine push to the server (in the case app harbor).
But I was still seeing the generic IIS sever errors! I did some searching on the internet and Twitter and found a helpful property of the response object.
By default IIS will see an response with an error status code (400-500) and will automatically change the content of the response to its default error page. What this property does it tell IIS not to do that if there is already content in the body of the page. Well that was easy, right? So I made the change and pushed it to the server, and navigated to a page that didn’t exist. Well the server still returned me the default 404 page, but on a 500 it would give me my custom error page. So what gives? Well here is the deal, the way routing works is that if ASP.NET cannot find a file that matches the requested URL the request is given back to IIS to handle. So in the case of a 404 ASP.NET can’t find the file so its given back to IIS who uses the default static file handler to serve the request. This would be slightly different if the route had matched but then say somewhere in our code we set the status to 404. In this case it would already be in the ASP.NET pipeline and ASP.NET would server the custom 404 page.
There are two ways to solve this problem. First is the easiest which is to open up IIS Manger and go to the “Error Pages” settings under IIS and change the 404 page there to use your custom 404 page.
This is fine if you can remote into the server or you’re not running in the cloud where multiple instances can be started. So how then do you make that work? Well lucky for us starting with IIS7 and later these settings can be added to your web.config file under the System.WebServer node.
So lets dig into what some of this code means and tell you about the tricky parts that you need to know. Before you can add a custom page you need to remove the entry for the status code as there can only be one entry per status code. The tricky bit here is knowing to set SubStatusCode to –1. This basically means all the possible sub statuses. If you like you could remove only the specific one you needed and set only the specific one. Also if you are playing around with the config you might find that there is a defaultPath attribute on the httpErrors node. This defines a “default” error page should an entry not be found in the list. The problem is that by default this is “locked” and cannot be set in an applications web.config and instead needs to be set at the machine level. Once you add these settings to your config you should be able to see your custom error page when you navigate to a page that does not exist. As a side note this just drives home the importance of IIS Express and why you should use it for development. This would have been discovered prior to pushing changes to the live server that way.Read full post
Introducing NuGet Docs: http://docs.nuget.org! NuGet Docs is a community driven documentation site that provides guides, walkthroughs, and information about anything and everything NuGet related. NuGet Docs is your new resource for learning and understanding how to use NuGet to the fullest. There is information about how to use NuGet to consume packages, information about how to create your own packages, and even information about how to contribute to NuGet along with much more. This is the first iteration of the site and the documentation that is contained on it. So we hope you understand it might be rough around the edges, but here is the good news its community driven so you can contribute your knowledge and understand to help make it better. More about how to do that later.
Let’s talk about the reason, goal, and focus behind NuGet Docs for a minute. Historically speaking open source software lacks good documentation. NuGet Docs is the NuGet team’s effort to make documentation a first class citizen. We want our documentation to be just as awesome as our product, because no matter how awesome NuGet is if no one can understand it, it’s nothing more than “the suck.” The focus of the site is really about providing the user with the information they need. We don’t want so much flashy chrome that it blinds the user from the information they are looking for. First and foremost the number one priority of the NuGet Docs site is the content! Another key aspect of NuGet Docs is that we designed it to be easy to create, update, and maintain the documentation. So let’s talk more about how we achieved that.
NuGet Docs is an ASP.NET WebPages application extended to support the use of markdown files (.markdown). What this means is that the core of the site is coded in ASP.NET WebPages while the documentation itself is written in markdown. For those of you unfamiliar with markdown it is basically a more human readable way to annotate a document so that HTML can be created from it. More information about Markdown can be found here. By using markdown we allow the authors of the documentation to have a better experience while still allowing rich visual content to be created. We also wanted it to be easy to create new content on the site. With that in mind all that is required to create a new page is add a markdown file and it will be added to the site and show up in the menus. There are some conventions that need to be followed but you can read more about that in the “Contributing to NuGet Documentation” page on NuGet Docs (I know, so meta).
So what are you waiting for? Head over to the NuGet Docs site and read up about anything and everything NuGet. When you’re done why not take the time to contribute your knowledge to collective (Star Trek reference) and write some documentation yourself? For those of you that do contribute to NuGet Docs we have a preview site (http://preview.docs.nuget.org) that all changes will be pushed to and then when a new version of NuGet is released we will port the preview site to the live site. This means that you can even help write documentation for features that are not in the current released version but are in CI builds. We know you love being on the bleeding edge. Also we appreciate hearing your feedback and hearing about bugs you encountered (hey, why aren’t you submitting patched for them?). You can provide those opinions and issue on the NuGet Docs CodePlex site.Read full post
subscribe via RSS