Skip to content

Instantly share code, notes, and snippets.

View Cisco AMP Dev On-boarding Checklist.md
View test_data.json
[{
"class": 2019,
"passed": 300,
"failed": 20,
"dropped": 190
}]
View 1000_names.txt
Opal Yundt
Ms. Odie Bogan
Justus Effertz
Mrs. Quinn Thompson
Lorine Hills
Krista Metz
Kameron Bashirian
Miss Micheal Ortiz
Tiffany Streich IV
Rylee Green
View innovation.txt
Why are you not innovating?
Sorry about the title. Some backstory on it though: over a watercooler conversation
with Alain by the coffeemaker robot, I was discussing the boring topic of "problem
solving" and he suggested I did a "lunch and learn". Which I later realized was may be
his way of telling "just shut the fuck off".
Now, about "lunch, and learn" - the first part is motivating to most animals like us.
However, when you mix "learn" with "lunch", the latter can easily spoil the charm of the former.
Specially, if the topic is as boring as "problem solving".
View PC Vangant.md

The goal is to reduce the overhead of a portal developer and QA working on PC. Vagrant is a great start in that direction. I suggest the following changes:

  1. Everything in git must be in Vagrant. .env is the only place where we should see local changes. No overrides for any other file.
  2. Files must sync between the host and the vm automatically. This applies to deleted files as well.
  3. Must work in dev and test mode so tests can be run easily.
  4. Env vars for paths must be set on login so that custom PC specific variables are preconfigured. e.g. LD_LIBRARY_PATH, PKG_CONFIG_PATH.
  5. By default, the portal in vagrant needs to run in development mode instead of production.
  6. On-demand QA deploy is needed so that QA can quickly verify dev fixes without having to wait for a periodic deploy.
  7. Automated clock sync between the VM and host machine so that Cookies don't expire because the VM has a time lag.
We couldn’t find that file to show.
View Evaluation.md

The pending evaluation related to SpyREST can be one/more of the following:

  1. Tool Evaluation
  2. Evaluate if REST API developers are more productive and accurate using SpyREST vs. alternatives.
  3. Evaluate if REST API client developers can peform API tasks faster when using SpyREST documentation vs. alternatives.
  4. Concept Evaluation - I want to know if API client developers are more productive when API documentation includes usage examples in addition to the API structure.
  5. Accuracy of existing docs I want to show that x% of API documentation is outdated. SpyREST can help by keeping it auto-updated.
View REST APIs.md
View SEIP
A Case Study of Automated Example Driven REST API Documentation at Cisco using SpyREST
Abtstract
what is the problem? -> REST API documentation
why case study? -> to see how it can be used in practice
what was done -> used in a commercial setting
how does it help -> how it could be used in other place, and implications for the design of automated documentation tool
Introduction
Why we need automated REST API Documentation