| #!/bin/sh | |
| # | |
| # This script will make WinMerge your default tool for diff and merge. | |
| # It must run inside git bash (on Windows) | |
| # | |
| # If your WinMerge is in other place then this one, please edit | |
| WINMERGE_SCRIPT="winmerge-merge.sh" |
As pointed out by @johntyree in the comments, using git reflog is easier and more reliable. Thanks for the suggestion!
$ git reflog
1ed7510 HEAD@{1}: checkout: moving from develop to 1ed7510
3970d09 HEAD@{2}: checkout: moving from b-fix-build to develop
1ed7510 HEAD@{3}: commit: got everything working the way I want
70b3696 HEAD@{4}: commit: upgrade rails, do some refactoring
| @echo off | |
| if _%1_==__ goto USAGE | |
| openssl req -x509 -nodes -days 365 -newkey rsa:1024 -keyout mycert.pem -out mycert.pem -subj "/CN=My Cert Name" | |
| openssl pkcs12 -export -out mycert.pfx -inkey mycert.pem -in mycert.pem -passout pass:%1 | |
| openssl x509 -inform pem -in mycert.pem -outform der -out mycert.cer | |
| openssl pkcs12 -in mycert.pfx -nodes -passin pass:%1 | openssl x509 -noout -fingerprint | |
| openssl x509 -in mycert.pem -noout -fingerprint |
I've been wanting to do a serious project in Go. One thing holding me back has been a my working environment. As a huge PyCharm user, I was hoping the Go IDE plugin for IntelliJ IDEA would fit my needs. However, it never felt quite right. After a previous experiment a few years ago using Vim, I knew how powerful it could be if I put in the time to make it so. Luckily there are plugins for almost anything you need to do with Go or what you would expect form and IDE. While this is no where near comprehensive, it will get you writing code, building and testing with the power you would expect from Vim.
I'm assuming you're coming with a clean slate. For me this was OSX so I used MacVim. There is nothing in my config files that assumes this is the case.
| All need the Microsoft.Diagnostics.Tracing.TraceEvent nuget package | |
| Shows how you can both produce some simple ETW events (these are not written to the eventlog) | |
| A couple of ways to consume said events. | |
| 1. using standard tooling like perfview, xperf, etc. | |
| 2. create your own EventListener class as demonstrated by ProducerAndSimpleListener, which allows you to do pretty much anything | |
| 3. listen in realtime as done in RealTimeListener | |
| 4. Others do similar things I believe like tx.windows |
| #Requires -RunAsAdministrator | |
| #Requires -Version 5.0 | |
| # requires Windows 10 | |
| Get-EtwTraceProvider | Select-Object SessionName, Guid | sort SessionName | |
| # as Markdown | |
| <# | |
| #Requires -RunAsAdministrator | |
| $result = Get-EtwTraceProvider | sort SessionName | |
| $result | %{"|Name|GUID|";"|----|----|";}{"|$($_.SessionName)|$($_.Guid)|"} | |
| #> |
| # | |
| # Learn About Docker Networks | |
| # github/tripdubroot | |
| # Docker version 1.12.0-rc2 | |
| # build 906eacd | |
| # experimental | |
| # | |
| # https://docs.docker.com/engine/userguide/networking/dockernetworks/#docker-embedded-dns-server | |
| # https://docs.docker.com/engine/userguide/networking/configure-dns/ | |
| # https://github.com/docker/libnetwork/blob/ed311d050fda7821f2e7c53a7e08a0205923aef5/resolver.go |
Between June 24-25, the nodes in Tectonic clusters running on Azure automatically updated the OS from Container Linux 1353.8.0 to 1409.2.0. After this upgrade, the nodes began to experience increased latency and failure rate in requests. Interestingly, we found that the size of the HTTP request played a role in determining the success of requests to services running on the Kubernetes cluster. We found that setting the client's interface's MTU to 1370 made all requests succeed; incrementing the MTU to 1371 caused the failure of large HTTP requests to resurface. Additionally, enabling TCP MTU probing on the clients ensured all requests would succeed, albeit with increased latency. In order to identify the minimum set of circumstances needed to reproduce the issue, I ran several tests involving different network topologies.
