sotayamashita

{
  "devDependencies": {
    "husky": "^1.2.0",
    "lint-staged": "^8.1.0"
  },
  "husky": {
    "hooks": {
      "pre-commit": "lint-staged"
    }
  },

sotayamashita

files:
  "/opt/elasticbeanstalk/hooks/appdeploy/post/50_restart_shoryuken":
    mode: "000777"
    content: |
      EB_SCRIPT_DIR=$(/opt/elasticbeanstalk/bin/get-config container -k script_dir)
      EB_SUPPORT_DIR=$(/opt/elasticbeanstalk/bin/get-config container -k support_dir)
      . $EB_SUPPORT_DIR/envvars
      . $EB_SCRIPT_DIR/use-app-ruby.sh

      mkdir -p /var/app/support/pids

sotayamashita

1. Install Robot Framework
2. Install SeleniumLibrary

sotayamashita

This is a curated list of awesome conferences mostly related (but not limited) to the software testing. I've made this list to better keep track of the conferences.

2019

sotayamashita

Question

function func() {                
  if (true) {                    
    var message1 = "hello world" 
    let message2 = "good night"  
  }                              
  console.info(message1)         
  console.info(message2)         

sotayamashita

Before digging deep, we need to clear problems for community localization:

1. NO way to know the diff between a source and localized one
2. NO a localization workflow

1. NO way to know the diff between a source and localized one

-> I hope it can be solved with Crowdin.

2. NO a localization workflow

sotayamashita

docker exec -it $(docker ps -a | grep <CONTAINER NAME> | awk '{print $1}') psql -d <DATABASE NAME> -U postgres

sotayamashita

Documentation-Driven Development

The philosophy behind Documentation-Driven Development is a simple: from the perspective of a user, if a feature is not documented, then it doesn't exist, and if a feature is documented incorrectly, then it's broken.

• Document the feature first. Figure out how you're going to describe the feature to users; if it's not documented, it doesn't exist. Documentation is the best way to define a feature in a user's eyes.
• Whenever possible, documentation should be reviewed by users (community or Spark Elite) before any development begins.
• Once documentation has been written, development should commence, and test-driven development is preferred.
• Unit tests should be written that test the features as described by the documentation. If the functionality ever comes out of alignment with the documentation, tests should fail.
• When a feature is being modified, it should be modified documentation-first.
• When documentation is modified, so should be the tests.

sotayamashita

Strikethrough

sotayamashita

{
	"emojis": [
		{"emoji": "👩‍👩‍👧‍👧", "name": "family_mothers_two_girls", "shortname": "", "unicode": "", "html": "👩‍👩‍👧‍👧", "category": "p", "order": ""},
		{"emoji": "👩‍👩‍👧‍👦", "name": "family_mothers_children", "shortname": "", "unicode": "", "html": "👩‍👩‍👧‍👦", "category": "p", "order": ""},
		{"emoji": "👩‍👩‍👦‍👦", "name": "family_mothers_two_boys", "shortname": "", "unicode": "", "html": "👩‍👩‍👦‍👦", "category": "p", "order": ""},
		{"emoji": "👨‍👩‍👧‍👧", "name": "family_two_girls", "shortname": "", "unicode": "", "html": "👨‍👩‍👧‍👧", "category": "p", "order": ""},
		{"emoji": "👨‍👩‍👧‍👦", "name": "family_children", "shortname": "", "unicode": "", "html": "👨‍👩‍👧‍👦", "category": "p", "order": ""},
		{"emoji": "👨‍👩‍👦‍👦", "name": "family_two_biys", "shortname": "", "unicode": "", "html": "👨&zw