Fiddler + EXE + localhost server

(a friend was asking about this one, so here's a repost / rewrite of a previous blog from 2014-12-03, back when Visual Studio 2012 was state of the art)

Capturing fiddler traffic between a local EXE and a web server running on localhost turned out to be a little more difficult than I originally imagined. I tried to set my server to localhost or 127.0.0.1 while my local EXE had a proxy through fiddler (localhost:8888), but some/most/many/mine web requests appear to skip proxies when going to a local address.

To get this done:

1. Run fiddler (Download Fiddler Web Debugging Tool for Free by Telerik), make sure "File / Capture Traffic" is checked.
2. Make sure fiddler's filters show traffic to localhost.fiddler
   
   I also like to Hide if URL contains /arterySignalR, which is a special endpoint that IIS express/Visual Studio will use on localhost for debugging. It can generate a lot of noise in fiddler.
   
   See below for a screen cap of my fiddler filter settings.
3. Start your web server on localhost
4. Reconfigure your EXE's target server to point to http://localhost.fiddler:>PORT< 
   This will be EXE specific.
   (note, >PORT< depends on the server you're running and what port it binds to)
5. Start your EXE
6. Make sure your EXE's proxy is pointing to localhost:8888, so all traffic goes through fiddler.

Visual Studio 2012, IIS Express, and Fiddler - Fiddler Web Debugger - Site Home - MSDN Blogs turned out to be really useful here

Here's my current fiddler filter settings

semver

 https://semver.org/

how i work

My dear,
Find what you love and let it kill you.
Let it drain you of your all. Let it cling onto your back and weigh you down into eventual nothingness.
Let it kill you and let it devour your remains.
For all things will kill you, both slowly and fastly, but it’s much better to be killed by a lover.
~ Falsely yours

- Bukowski

The rules:

1. everything is absurd.
2. going from 0 to 1 is hard. going from 1 to 2 is easy.
3. Complaining is a synonym for volunteering.
4. in this discipline, there is no magic.
5. better to beg forgiveness than ask for permission.
6. eat your own dog food.
7. develop out loud.

Chrome and Tab Groups: Where the heck am I?

Task Context Switching 

If you're like me (and why wouldn't you be? come on!) you've got a lot of tabs open in Google Chrome. Like, an unsettling amount - enough to make your memory paging system go "Hol' up". 

I like to organize my browser so I have separate Chrome windows that represent a task context. 

For example, currently I have separate Chrome windows dedicated to: 

1. A code change associated with a work ticket around some performance improvements. I have a spreadsheet on there for tracking timing changes, a few tabs for some associated research, and a few tabs for watching our metrics system.
2. Articles I want to read unassociated with any active work tickets. I park "this looks interesting and I want to get to it soon™" articles there.
3. A presentation that I'm working on, with a tab for the actual presentation and another tab for some survey results from anonymous questions I'm asking.
4. Et cetera, et cetera, et cetera

This system works well for me, but it can provide some tough context switches, when I go from Task A to Task B, I have to hunt through my current 11 (yes 11!) Chrome windows to find the right context, so I can work on my task.

what follows is an ACTUAL screen shot. Feel my pain.

Context switching means looking at each window in turn, and trying to figure out what task context that window is dedicated to by tab titles. Easy to do once, but omg, try doing it dozens of times a day.

I want to make this process easier, so context switches require less effort.

All Hail Chrome Tab Groups

Chrome Tab Groups are a relatively new feature where you can take one or more tabs and associate them with a label. It's pretty easy to use, with a right mouse click and a little bit of typing. The linked blog is the best introduction and guide.

When I create a new Chrome window with a set of tabs, I will associate the leftmost tab with a Tab Group and give it a short name so I understand the context quickly.

For instance:

You probably don't know what wi2524860 (dms load means, but I do. When I want to work on that task, I can quickly loop through my Chrome windows, and, by keeping my eye on the upper left corner, find the right window to bring into focus.

Bonus Points

Windows 7 introduced a great application shortcut key feature, where the Windows Logo key + a number will switch to that number program pinned to the taskbar. 

If you're like me and have Chrome pinned as task 1, you can hold down the Windows Logo key and repeatedly press 1 to cycle through your windows, looking for the correct task using the tab group label.

Anybody that's been in a meeting with me (may the Lord have mercy on your soul), has probably noticed me doing this at the beginning of a meeting, where I will say "no, no, no, no, yes" as I find the right window. I'm sorry you had to listen to that, but here we are.

Conclusion

Anyway, it's a minor efficiency thing, but whatever we can do to save those precious, precious seconds. Thanks.

Little Metrics: Providing Observability in our Projects

Everybody reading this should be familiar with the concept of taking your temperature. When you don't feel well, you (or Mom or Dad) pop a thermometer into your mouth, wait a few seconds, and then take a look. If you're above 98.6° F (37° C, 310.15 K, ...), you may have an infection. Note: I'm not a Doctor (but I play one on this blog).

Recording your temperature is a "little metric" around making a quick judgement around your health, and it's effortless to collect. Well, possibly not effortless for parents of toddlers (I remember those dark days), but you get the idea.

Like taking your body's temperature, we should be able to find and record some effortless "little metrics" around our software projects to make judgements about their health. This is especially true around any project that is:

• taking more than some tiny number of iterations. 
• split up into many tasks.
• worked on by multiple developers.

We demand observability (one of the core -ilities) for the execution of our software, using logging libraries and monitoring services. We should also demand observability on the health of our development efforts, and present that observability in a way that everybody, from individual contributors to C-suite executives, can easily understand.

I'm deliberately wishy-washy about when to apply "little metrics". You'll know where you need it.

My "little metrics rules":

1. The little metrics collected should be an easy concept for everybody to understand.
   
   A common example is number of work items (tickets) total for a project, number that are closed, and number that are active. Collecting these metrics requires everybody to be good work item citizens and follow the rules on work sizing and not reopening closed work.
   
   Other good examples of little metrics are cost, performance (how fast to do the thing(s)), and scalability (how many things are supported simultaneously before the system goes pear shaped).
2. The little metrics should be small in number.
   
   If you start collecting and reporting 10 numbers for a project, my eyes are going to start glazing over and thinking about potato chips before you're done. 3-5 numbers sound good.
3. Collection of the little metrics should be effortless.
   
   Clicking two urls is good. Clicking one is double plus good.
   
   The urls should show results in less than 5s. Any more, and you've lost my attention.
4. Collection of the little metrics should use your source of truth.
   
   Think about where your source of truth is for tracking the work to be done. Use that. Any use of a denormalized copy of that data (like in an external spreadsheet) will be outdated as soon as you hit File > Save.
5. Collection of the little metrics should be done in a ceremonial fashion.
   
   While it's great to collect these metrics via robot, incorporate their collection in your meetings, so that everybody can witness them getting collected. Playing music with their collection is optional.
   
   Collect and show their graphing over time (the next step) to everybody in your ceremonies simultaneously, and take a short amount of time to speak to what they mean.
6. The little metrics should be recorded and graphed over time.
   
   Work tracking systems are great at showing the current state of things. What you want to see is how project health is progressing over time. Every stakeholder, from individual contributor to executive, should be able to easily see these graphs, and understand what they mean.
   
   If you can record these metrics and graph them over time in your work tracking system, great. If you need to copy them into a spreadsheet, that's fine too. As you're capturing the health state at a point in time, you don't risk outdated data listed in rule 4 above, because changes to the future state don't affect what is happening right now.
   
   In the example of total, closed, and active, it's very interesting to see a graph like this.
   
   
   
   but you can slice it or dice it however you want: percentages, lines towards 0 (project completion), break out active work as a separate graph, etc. Whatever is most useful to the stakeholders to gauge the "temperature" of a project.
   
   If total work is growing over time, then the project isn't properly scoped yet (not a pejorative - growth is bound to happen, as the unknown unknowns become known). If closed work stays flat over time, then you can see if you've got enough resources on the project. There's a ton more to be written here, and way out of scope for this blog post.
7. The little metrics should NOT BE WEAPONIZED.
   
   I'm 100% serious here. This observability on the state of our projects should be collected and presented in a judgement free manner. This is using data to determine project health. Projects that need love and attention should get love and attention to get them back on track.

I see a lot of metrics in my day to day that can be hard to digest what they really mean - think "can't see the forest for the trees". I'm a firm believer that having a system like these 7 rules in place around project observability will help tremendously in building a shared understanding project health, which further fosters a collaborative development culture.

How I work

In no order, and in a list that will be augmented over time, here's some best practices that I've developed for work. This is tech heavy.

YMMV. No animals were harmed in the creation of this list.

1. If you are bored doing a thing, go do a different thing.
2. Microsoft OneNote is your friend. It should be always open on every computer you use and you should be effortless with its usage.
1. Assign a Windows HotKey to OneNote. Windows+7 (lucky number) gets me there on every computer I own.
2. Create a diary tab. Every day gets a diary page in that tab, which will have cruddy notes about what you're working on. 
3. Do NOT curate your diary entires. Write it and walk away. Curation is a suckers game here and you will lose; The idea is just to write something down as you're doing it.
4. Create a contacts tab. That's where you list who you know & what they do.
5. Create a TODO tab. This contains checkbox lists of parked things that YOU and YOU ALONE are working on. Check the boxes as the jobs get done. It should be effortless to add a TODO.
6. My TODO tab has 2 pages, one for personal TODO and one for subjects I need to discuss with my supervisor that do not require immediate attention.
7. Create an interview tab for notes during interviews, duh.
8. Other tabs for more significant projects that you're working on, pages in those tabs. 
9. OneNote is designed to be a hot garbage mess of your thoughts. It's ok.
3. Tasks that require collaboration or more ceremony should be thoughtfully put into whatever task tracking system you use. We use Azure DevOps. Others do not.
4. While trite, "Be the change you wish to see". Seriously. Complaining = volunteering to own a problem.
5. Everything is absurd.
6. Make a good playlist for getting stuff done. Here is mine.
7. Allocate an hour of time a week to go over your backlog of work. Block it on your calendar and don't let anybody schedule over it. This is time for you to go over any personal or group tasks and curate them - is it really active? is the language precise about what needs to be done? We're not writing Tolstoy, but collaborative tasks should be written in a way that all stakeholders can understand them.
8. Going from 0 to 1 is hard. Going from 1 to 2 is easy. Better to get something written and iterate towards better than wait until the initial delivery is perfect.
9. Do you work out loud and model good behavior for those around you.
10. In computer programming, there is no magic. Everything happens deterministically for a reason. That reason can be highly complex, but is not magic.
11. Eat your own dog food. Use the tools you create, so you can make them better.  
12. "Make the space better for me having been there". Every time I edit a file to make a change, I see if there's other work that I can do that would be safe but make the file a little bit better - better comments, more tests, etc. See safe refactoring rules.  
13. Everybody's time is precious. Remember your "pleases" and "thank you's". Politeness is a sign of a well functioning social order.  

On Prioritization: Your Team Structure Articulates Your Goals

Of the three legged stool that defines the controllable outputs of development of a software system

• Features
• Performance
• Stability

it's self evident that everything comes at a cost; you have to employ prioritization to determine what gets the most focus.

More time spent on features equals less time spent on performance and stability, and vice-versa.

Imagine having a development team that has 1,000 hours of capacity. How do you split the time? 333 1/3 hours per output? Are you feature driven: 600 hours spent on features, 350 on performance and 50 on stability?

Everything is a choice.

Note, I'm specifically avoiding what might be called Engineering as a controlled output. Mostly, customers don't directly notice Engineering - they can't tell if my interfaces are clean, if I'm employing a single responsibility principle, or my code is a spaghetti mess of variables named x1, x2, x3, ... x999 looking like it was produced by a poorly written minifier.

Certainly Engineering is indirectly noticed, as poorly Engineered software requires more resources to add Features, is less likely to be Stable, etc. That frequently manifests over the software system's lifetime.

So, we have our software system, and we've made our choices about who is working on what, and for how much time.

Easy peasy, right?

Maybe. Maybe not. There are other inputs to this problem. 

Regardless of the time allocation, how have you segmented your development teams? 

If your teams are aligned around a Feature, they're going to have a Feature mindset. They will communicate with other teammates about Feature implmentation. Regardless of direction around resource allocation, Features will be artifically weighted.

I'm being delibarately provocotive here. Many of us, myself included, are used to teams with Feature segmentation. For developing a software system of any complexity, it just makes sense - separate into feature based bounded contexts, and throw a team on each context.

I challenge myself to not default to that muscle memory way of team creation, and to be considerate to organizational structure when laying out goals.