smsohan

• Learn Command Line Tools: grep, ps, awk, wc, tail, head, less, sed, sort, etc.
• Learn Docker and Docker compose basics.
• Learn Ruby: Programming Ruby, CodeSchool
• Learn Rails: Rails Guides, Michael Hartl Rails tutorial
• Learn Rspec
• Learn Capybara
• Learn OWASP top 10
• Learn Rails and Security
• Learn CoffeeScript
• Learn BackboneJS

smsohan

[{
  "class": 2019,
  "passed": 300,
  "failed": 20,
  "dropped": 190  
}]

smsohan

Opal Yundt
Ms. Odie Bogan
Justus Effertz
Mrs. Quinn Thompson
Lorine Hills
Krista Metz
Kameron Bashirian
Miss Micheal Ortiz
Tiffany Streich IV
Rylee Green

smsohan

{
  "hello": "world"
}

smsohan

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".

smsohan

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.

smsohan

We couldn’t find that file to show.

smsohan

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.

smsohan

1. Nutritionix
2. WordPress
3. Drupal.org -> example based

smsohan

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