June 3rd, 2013 5:05 PM ∙ Dibbs ∙ 3 Comments
Thankfully with the help of FiddlerCore, this was not that difficult of a problem to solve. I took some inspiration from LiveReload and wrote a WPF wrapper around FiddlerCore which I lovingly call Imposter.
Imposter allows you to create a profile that contains a couple of basic settings including a base URL or URL fragment to match requests on and a working directory from which local files will be proxied for remotely requested resources.
Another great feature is that Imposter can be set to automatically refresh any HTML page that is able to be proxied whenever a file in your working directory changes!
Let’s use some scenarios to clarify the behavior. Say your settings are:
Here’s what Imposter will do in the following scenarios:
- Browser requests file: http://awesome/index.html
- Imposter looks for C:\source\awesome.web\index.html and if found, serves that file to the browser instead of the remotely hosted file.
- Browser requests file: http://awesome/js/index.js
- Imposter looks for C:\source\awesome.web\js\index.js and if found, serves that file to the browser instead of the remotely hosted file.
- Browser requests file: http://notsoawesome/
- Imposter ignores the request.
So you can see that Imposter has a fairly simple set of rules that it follows by default. I just today added in another profile setting for overriding the default “match this path and file name” rule so that you can serve up files that may not match the default rule. The ability to override the default behavior is especially handy for when your directory structure doesn’t match your deployment structure, or if you want to serve up an unminified file temporarily for debugging purposes.
The only real gotcha is that since Imposter uses FiddlerCore, you can’t run Fiddler at the same time. I see this as a minor problem though and one where the positives greatly outweigh the negatives.
If you want to check out the tool, feel free to grab it or its source code over at http://github.com/gotdibbs/Imposter and feel free to comment or provide feature suggestions!
, General Technology
, MSCRM 2011
, CRM 2011
, Dynamics CRM
May 24th, 2013 9:30 AM ∙ Dibbs ∙ Leave a Comment
Inspired by grunt-qunit-serverless and its approach to running QUnit tests in grunt without the overhead of running connect, I setup my own implementation which combines pieces from grunt-qunit-serverless and grunt-contrib-qunit to create a minimalist approach to testing with QUnit from Grunt.
The main goal I had was to make it simpler to setup when converting an existing suite of manual QUnit tests to an automated Grunt-based environment. In doing so I wanted to keep console output to a minimum. Honestly, all I really care to see is that either everything passed, or that these specific tests failed. This way you don’t have to comb through the logs to find which errors you had and can spend more time fixing them.
Feel free to check it out here: http://npmjs.org/package/grunt-qunit-minimalist or on GitHub at https://github.com/gotdibbs/grunt-qunit-minimalist.
Please drop a comment if you have any feature suggestions, or, make a pull request!
May 2nd, 2013 5:52 PM ∙ Dibbs ∙ Leave a Comment
I recently found myself getting pretty annoyed when working from home. Why? When I needed to go join a Lync meeting, I’d have to copy the URL from Outlook on my remote desktop session, paste it into a new IE window on my home computer and then wait for it to close IE and open the Lync meeting. Suffice it to say, it was complicated and annoying. Did I mention annoying?
After a bit of meddling around in the Lync SDK, I scrapped that idea and instead hooked the app straight up to Exchange Web Services. From here it was actually pretty darn simple to flesh out.
The end result is this beautiful application below. The instructions for installation and usage are included on the GitHub page for the project, which is located here: https://github.com/gotdibbs/Meetings/. Feel free to download, modify, or redistribute at will – but let me know if you have any feedback!
February 5th, 2013 2:13 PM ∙ Dibbs ∙ Leave a Comment
I am reposting my Sonoma Partners blog post from today, hope you find it useful!
We made sure our elements were absolutely positioned and that they had the right CSS with “display: block” and everything, but nothing worked. Nothing, that is, until we switched our IFrame tag from this:
…and all of a sudden, everything works as intended! A simple self-closing IFrame tag was the culprit. The problem here is that technically self-closing tags in HTML are illegal. HTML is not XML and that is where its easy to get mixed up. If you’ve worked with XHTML long enough, you use them regularly.
So technically if you’re still using those in your regular HTML and not XHTML web work, then that is also invalid HTML although the browser is fixing the issue for you and making assumptions about what you meant.
Hope this helps!
January 28th, 2013 9:13 PM ∙ Dibbs ∙ Leave a Comment
I encountered an odd issue the other day where I was seeing a random horizontal rule element at the top of a page I was working on when no data was loaded to my ListViews. There was really only one place this extraneous element could’ve been coming from, and it was my list item template (WinJS.Binding.Template control). For some reason the template itself was being rendered on the page and not just hidden until it is used for the ListView itself.
I couldn’t find any documentation on this readily, but I did find a couple other people setting display to none inline on the template div element like so:
<div id="itemTemplate" data-win-control="WinJS.Binding.Template" style="display: none;">
While this does appear to fix the issue at hand, it’s not very pretty as we’re always trying to keep our CSS out of our HTML files, right? The solution here is a simple CSS rule inserted into your default.css stylesheet:
This will handle all of our templates and we won’t have to ever think about it again! Much better fix, but I’m still not sure why we need to do that in the first place.