2019-10-19

Useful commands after installing a brand new system

Firewall settings for ICMP (i.e. response to PING requests)



ENABLE via NEW COMMAND
netsh advfirewall firewall add rule name="ICMPv4" protocol=icmpv4 dir=in action=allow
( REF: http://support.microsoft.com/kb/947709 )

ENABLE via OLD COMMAND
netsh firewall set icmpsetting 8
netsh advfirewall firewall set icmpsetting 8
( REF: http://www.petri.co.il/enable-ping-windows-2008-server.htm )

ENABLE via GUI
Start > Administrative Tools > Windows Firewall with Advanced Security




Generic Local Area Networks v2019.10.0
192.168.0.0/255.255.0.0, 10.0.0.0/255.0.0.0

2019-10-18

Ex-Employee tells about the Microsoft Windows internal testing process [Bookmarks, +TLDR, +FR]

"Why does Microsoft Windows 10 have so many bugs? Ex-Employee tells you why!"
-- by  Barnacules Nerdgasm
"https://www.youtube.com/watch?v=S9kn8_oztsA"





Link and preview to video "Why does Microsoft Windows 10 have so many bugs? Ex-Employee tells you why!" by Barnacules Nerdgasm


TL;DR (FR-version) :
  1. 1/ Ils ont licensié un département entier de testeurs quand ils ont fusionné leurs multiples systèmes d'exploitation : Desktop , Phone, etc.
  2. 2/ Ils ne testent plus du hardware réel; tout est virtualisé (i.e. les problèmes spécifiques au matériel ne sont pas révélés)
  3. 3/ Ils se reposent beaucoup sur le _Windows Insider Program_ et la télémétrie pour avoir des remontée de bugs avant de déployer les mises-à-jour "au plus grand nombre" (mais ce mécanisme a des limitations : les utilisateur du _Windows Insider Program_ ne remontent pas toujours les problèmes, les _mini-dumps_ ne sont pas toujours suffisants pour identifier la source d'un problème, les problèmes sont résolus à tâtons, et dans les pire cas, complètement ratés et les correctifs causent davantage de régressions).

TL;DR (EN-version):
  1. 1/ They did a massive lay-off and got rid of a whole testing departement when they merged their multiple Operating System teams : Desktop, Phone, etc.
  2. 2/ They don't test real hardware anymore; tests are run in virtual machines (ie. hardware-related corner cases are not tested)
  3. 3/ They rely a lot on the _Windows Insider Program_ and telemetry before rolling-out updates to "most people" (but this process has limitations : _Windows Insider Program_ users don't always report bugs, _mini-dumps_ aren't always enough for tracking down a bug, some problèmes are solved by groping and, in the worst cases, even missed entirely and attempts to fix a problème cause further regressions).

2019-10-17

Missing a persistent SCITE_USERHOME environment variable ?

This blog post is a work in progress... I haven't yet fully understood what is wrong with my SciTE install. Although the missing SCITE_USERHOME environment variable is a good lead...

Utilities look for an env variable called SCITE_USERHOME and when that is missing will assume a portable installation of SciTE:

REG_SZ

cmd /c "setx SCITE_USERHOME ^"%UserProfile%^" & pause"

REG_EXPAND_SZ

cmd /c "REG ADD HKCU\Environment /v SCITE_USERHOME /t REG_EXPAND_SZ /d ^%UserProfile^% & pause"

Additional information


Missing a persistent environment variable ?


Registry hives and paths

  • User Variables: HKEY_CURRENT_USER\Environment
  • System Variables: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment

Introduction to .ignore files syntax and capabilities



------------------

You'll mostly have to look up the documentation of the .ignore files syntax if you want to master this tool and find the right tradeoff/middleground between being specific and being generic about what files you ignore in your project.

------------------

In general, you can either 1/ be specific or 2/ use wildcards or 3/ use negation patterns. For instance you could say ignore all "bin" directories, except a particular one:

```
/**/bin
!/Golum/MyPrecious/bin
```

Notice the exclamation mark at the begining of the second line: it's a negation. It means: DO NOT IGNORE.
=> Those two lines combined, will ignore all "bin" directories, wherever they are in the tree ( double asterix = means any subdirectory ) except that one particular one, named on the next line and prefixed with an exclamation mark.


------------------

But saying this I'm only scratching the surface of the power of the .ignore files, you need to look at the doc to know more. (eg. you can have a generic .ignore file at the root of the solution and, for specific cases, other .ignore file(s) in subdirector.y.ies somewhere too)

------------------

Last but not least, if you're confident with .ignore file, you can even invoke destructive commands such as "clean" and delete everything that is not under source control ( ie. that is ignored )... which is basically a prequel to REBUILD ALL.

```
# WARNING: cleans absolutely everything that is not under source control
    git clean -nfdx # << To preview what would be deleted... -n = NoAction = --dry-run
    git clean -fdx # << The actual cleanup.
```

----------------

"tfignore file - Google Search"
"https://www.google.com/search?q=tfignore+file"


For Fox

"Visual Studio 2015 TFS .tfignore file - Stack Overflow"
"https://stackoverflow.com/questions/36768954/visual-studio-2015-tfs-tfignore-file"


For Seb

Excluding Files From Team Foundation Version Control Using .tfignore Files - Applied Information Sciences
https://www.appliedis.com/excluding-files-from-team-foundation-version-control-using-tfignore-files/


For everybody

"GitHub - sirkirby/tfignore: A Collection of .tfignore Templates"
"https://github.com/sirkirby/tfignore"

"GitHub - github/gitignore: A collection of useful .gitignore templates"
"https://github.com/github/gitignore"



2019-10-16

The trend for an "Opt-out"-style philosophy for source control

The old "Opt-in"-style for source control

I remember, when using Microsoft's Team Foundation System and Visual Studio, you'd have two ways to add a file to source control:

  • either Visual Studio would take care of that for you when your file was part of a Solution
  • or you would have to manually browse the "Source Control Explorer" and add you new files


Preview of the Visual Studio's Source Control Explorer Graphical User Interface


A preview of how to explicitely add files to source control in Visual Studio




Things have changed

As far as source control goes, everybody is moving to "opt-out"-style policies, instead of "opt-in"-style ones, ( get used to it :stuck_out_tongue_winking_eye:  , 'cause it's actually much safer and nicer in the long run... even if there is an "up-front" price to pay -- ie. setting up your ".ignore" file)

Now, everything is under source control by default, unless you specify otherwise. This is nice because you typically don't get things happening behind your back without you knowing or forgetting (files added, changed or deleted).

Configuring what is ignored

When using the Git version control system, the critical files for specifying what is not meant to be kept under source control are the famous ".gitignore" files.

Visual Studio and Team Foundation System have a very similar concept, except the file is called ".tfignore".



2019-10-14

Talks about WASM and WASI [Bookmarks]

For those who are curious or who want to follow up about WASM and WASI, I recommend two recent videos to help understand it all. But first, some opinion about the topic.

Twitter message

This is an insightful Twitter message from Solomon Hykes is the Founder, Chief Technology Officer and Chief Architect of Docker and the creator of the Docker open source initiative.


Preview of the Twitter message from Solomon Hykes



Video 1/2

"Rust, WebAssembly, and the future of Serverless by Steve Klabnik"
https://www.youtube.com/watch?v=CMB6AlE1QuI

Preview of the YouTube screen about Rust, WebAssembly, and the future of Serverless by Steve Klabnik



Video 2/2

"Bringing WebAssembly outside the web with WASI by Lin Clark"

Preview of the YouTube screen about Bringing WebAssembly outside the web with WASI by Lin Clark



2019-10-13

Picasa photo viewer nostalgia

Picasa 3, the (discontinued) Photo Editor and Viewer was such a great piece of software... There are some replacements (eg. can think of XNView for instance for viewing, and many more for editing...) but none come close to how user friendly Picasa was.

So for those, like me, who want to run this fantastic thing, even if it hasn't been updated in a long time, but still works like a charm, I have an old copy of the installer I am sharing here:

Picasa 3.9
picasa39-setup.exe, 13,0 MB in size

I bet you can also find it on FileHippo.com, or some other archiving – file sharing service. But here it is anyway. Enjoy! ;-)





If using a deprecated software is not something for you but that you still need to browse high volumes of images scattered in directories, a quick and easy fallback back solution (even if it's not as nice) might be XnView:

choco install -y xnview




2019-10-03

Using Chocolatey to install your favorite software


This is a follow-up to one of my previous posts:
Chocolatey is like a package manager, but for Windows; a bit like the famous `apt-get` or `aptitude` for some GNU/Linux distros (...) I have created a curated list of my favorite ones; the ones I would install right away on a new computer, whether it is for work or even for home computing.

Therefore, to run any of the commands listed below, you will first need to install Chocolatey itself, which can be easily done with a simple command, so make sure you first check this post:

Install both Chocolatey and OpenSSH with SSHD in one Copy-Paste in Powershell







SUBSEQUENT CALLS


After completion, you may invoke commands such as:

choco install -y vcredist2015
choco install -y --ignore-checksums linkshellextension

choco install -y 7zip
choco install -y git --version 2.21.0

choco install -y openvpn

choco install -y keepass
choco install -y notepadplusplus

choco install -y firefox
choco install -y googlechrome

choco install -y cherrytree --version 0.38.8
choco install -y guidgen-console
choco install -y lightshot
choco install -y synctrayzor
choco install -y winmerge

# java runtime environment
choco install -y jre8

# autoit minimum version: 3.3.8.1
# (autoit 3.3.6.1 not available via chocolatey)
choco install -y autoit --version 3.3.14.5

# scite4autoit3 minimum version: 3.5.4
# (scite4autoit3 3.2.0 not available via chocolatey)
choco install -y scite4autoit3 --version 19.102.1901.001






UNUSED


# git-lfs is already included in the main Git installer
# (this is true as of early 2019)
choco install -y git-lfs

# syncthing is already part of synctrayzor
choco install -y syncthing

# veracrypt competes with BitLocker on Windows, which works fine
choco install -y veracrypt

# As of May 2019, git-credential-manager-for-windows
does not seem to be automatically added to the path!
# However this might not be a big deal since it seems
# to have been included into the main Git installer.
choco install -y git-credential-manager-for-windows

# the winbtrfs driver does not work for me
# (but that has nothing to do with Chocolatey)
choco install -y winbtrfs






DEFECTS


# As of 2019-05-10, choco installs older v18.2.1 of smartgit,
# which causes problems because we are forced to upgrade as
# soon as it is installed
choco install -y smartgit






OTHER COMMANDS: "CHOCO SEARCH"




If you want to check if an application is included to the Chocolatey distribution service, or if you want to know its exact name, you may use the "choco search" command.







OTHER COMMANDS: "CINST"






An even faster way to call for an installation of a piece of software is to use "cinst" instead of "choco install".

Also, according to the help instructions, it should be possible to specify multiple application after the "choco install/cinst" command.

So we can therefore condense the previous list of calls into on single command (although I wrote on multiple lines and escaped using the backtick character, we should be able to copy-paste it just like that):

Optional:
choco feature enable -n allowGlobalConfirmation;   


Default base install v1.0.1910.0:
cinst -y tightvnc; `
 `
cinst -y keepass; `
cinst -y firefox; `
cinst -y notepadplusplus; `
 `
cinst -y lightshot; `
cinst -y --version 0.38.8 cherrytree; `
 `
cinst -y 7zip; `
cinst -y vcredist2015; `
cinst -y --ignore-checksums linkshellextension; `
cinst -y googlechrome; `
 `
cinst -y git; `
cinst -y jre8; `
cinst -y openvpn; `
cinst -y winmerge; `
cinst -y guidgen-console; `
cinst -y --version 3.3.14.5 autoit; `
cinst -y --version 19.102.1901.001 scite4autoit3; `
 `
cinst -y synctrayzor; `
 `
;


REMARK #1: Some (generic) lists may include an install instruction multiple times, usually at the beginning or the end of the script, this is on purpose. Lists like this can have multiple purposes and can be partially copy-pasted if we're only interested in a subset of the list. And running the same install request multiple time will only cause it to be ignored (unless the "--force" parameter was used, which is not the case).


REMARK #2: Also some pieces of software require very specific configuration, such as a VNC server, and we're better off running them separately, or at the very beginning and letting the rest of the automated install to carry on...
- tightvnc


REMARK #3: Some software may not be suitable for being installed on the system disk if it deals with data located on an independent disk of a virtual machine, in which case it's advised to use a portable application which you would install manually:

- synctrayzor


REMARK #4: I personally use my favorite (and most important) software in the form of portable programs, which I update myself, in which case it has to be removed from the default list:

- notepadplusplus, keepass, firefox


Other, ready to paste, multi-line commands such as the one above, can be found at this address:
Choco-based unassisted installs



2019-07-05

Testing Types Ontology v1.0.1907.1

Please find below a checklist I've created to describe different testing strategies.



1/ The hidden rationale behind the word "testing"


 • Testing vs. Checking
◇ [ ] "Testing" is explorative, probing and learning oriented.
◇ [ ] "Checking" is confirmative (verification and validation of what we already know). The outcome of a check is simply a pass or fail result; the outcome doesn't require human interpretation. Hence checking should be the first target for automation.

REMARK: We can see that speaking of “UnitTests” is actually not the best thing we came up with. We should rather be saying “UnitChecks”. But never mind.


2/ High level characteristics


• Interfaces
◇ [ ] GUI (Requires a dedicated Desktop Session)
◇ [ ] CLI-style (Tests can be run in parallel within a single User Session)
◇ [ ] or Hybrid CLI+GUI (Makes extensive use of CLI and access to the Desktop resource is leveraged through locking or distribution)

• Scopes
◇ [ ] Unit Test (Method testing, Mock testing)
◇ [ ] Component Tests (e.g. API Tests)
◇ [ ] System Tests (e.g. Integration Tests, Coded UI Tests)

• Areas of Concern
◇ [ ] Functional
◇ [ ] Acceptance
◇ [ ] Security
◇ [ ] Performance
▪ [ ] Load Testing: measure quantitative load.
▪ [ ] Stress Testing: check behavior under exceptional circumstances.

• Backends
◇ [ ] None (i.e. the tests generate their own data from scratch, dynamically),
◇ [ ] Snapshot-driven (w/ Upgrade of existing on-site data)
◇ [ ] Import-driven (e.g. using an import feature to perform testing on legacy or fresh data)
◇ [ ] or Hybrid

• Mechanics
◇ [ ] Data-driven (the same scenario is repeated over and over again, each time with different data)
◇ [ ] Scenario-based (each test requires a dedicated piece of software, typically a script)
◇ [ ] Exploratory (e.g. Bug Bounty, Hallway Testing, Usability Testing, Monkey Testing)

• Dependencies
◇ [ ] Application (depends on another process)
◇ [ ] Input Data (depends on flat files or streams of data)
◇ [ ] or Hybrid

• Privileges
◇ [ ] Local Administrator (eg. The tests requires write access to Program Files)
◇ [ ] Custom Local (eg. The tests access protected local resources)
◇ [ ] Any Local Standard User (Accesses a limited range of resources, attached drives, or only C:\Users\[UserName] directories.)


3/ Practical categories


• Operating
◇ [ ] Revert-based (each session starts from a well-known state, typically a virtual server snapshot)
◇ [ ] or Rolling (when nothing goes wrong, the testing server may have an ever increasing uptime)

 • Scheduling
◇ [ ] Triggered (e.g. Continuous Integration)
◇ [ ] Scheduled (e.g. Regular/Nightly)
◇ [ ] OnDemand (more suitable for very heavy, long and expensive tests – e.g. Load testing, Security testing, etc.)

• Reporting
◇ [ ] Fully Automated (PASS/FAIL)
◇ [ ] Computer Assisted (WARNINGS)
◇ [ ] Manual (Analytical)


4/ Volatile categories



The categories below are fairly volatile: the tests may move to a different category as the system-under-test grows older.

• Branches
◇ [ ] Internal/Staging
◇ [ ] Release

• Stages
◇ [ ] Development Tests (No backend/legacy data)
◇ [ ] Non-Regression Tests (Snapshot or Import-driven, see 'Backends' above.)



2019-07-04

Diffy and Thrift [Bookmarks]

Hey, I came across an interesting piece of technology, I don't have time to experiment with it immediately (and fully understand how we could make use of it), but I wanted to share this with you right away, in case any of this rings a bell to something that might apply to things you are working on:


1. Diffy


First, there is this thing called Diffy (developed by Twitter), which tackles some problems I am actually familiar with, in terms of Non-Regression Testing:

"Diffy: Testing services without writing tests"
https://blog.twitter.com/engineering/en_us/a/2015/diffy-testing-services-without-writing-tests.html

Diffy finds potential bugs in your service by running instances of your new and old code side by side. It behaves as a proxy and multicasts whatever requests it receives to each of the running instances. It then compares the responses, and reports any regressions that surface from these comparisons.

The premise for Diffy is that if two implementations of the service return “similar” responses for a sufficiently large and diverse set of requests, then the two implementations can be treated as equivalent and the newer implementation is regression-free.


Illustration from Twitter's blog:




2. Apache Thrift


Second, when you look at how Twitter is implementing WebServices, they go through something called Thrift (developed by Facebook and "given" to the Apache Software Foundation)... I've looked up how this could interoperate with IIS, and it appears that can be used through IIS Handlers:

"Apache Thrift - Home"
https://thrift.apache.org/


"Thrift over HTTP with IIS | codealoc"
https://codealoc.wordpress.com/2012/04/06/thrift-over-http-with-iis/

The Apache Thrift software framework, for scalable cross-language services development, combines a software stack with a code generation engine to build services that work efficiently and seamlessly between C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, JavaScript, Node.js, Smalltalk, OCaml and Delphi and other languages. 

The Thrift .Net library includes an HttpHandler THttpHandler which implements the IHttpHandler interface for hosting handlers within IIS. Documentation of how to use the handler is very sparse. Below are instructions of how to create a Thrift service using THttpHandler.


Preview of a sample IIS config:





Summary


Both Diffy and Thrift are interesting since they tackle problems I am familiar with:
  • Diffy addresses the problem of comparing past and present versions of software while removing the random/noisy content from the output.
  • Thrifts addresses the problem of generating client plumbing code for "talking" to webservices. There is so much difference between server and client code, that writing them in the same language doesn't actually help the slightest bit.



Anyway, just wanted to say that's something we should look into, and understand, for when we design testing strategies...