This is a bash script, as an example, on how to do click-testing GUI based on finding components based on how they look.
- opencv
- scrot
- findimage
- xdotool
default['sshd']['sshd_config']['AuthenticationMethods'] = 'publickey,keyboard-interactive:pam' | |
default['sshd']['sshd_config']['ChallengeResponseAuthentication'] = 'yes' | |
default['sshd']['sshd_config']['PasswordAuthentication'] = 'no' |
This is a bash script, as an example, on how to do click-testing GUI based on finding components based on how they look.
General key themes:
Hiring is really hard. You’re not just hiring a “Rails Engineer” or a “Python Programmer” you’re hiring someone who can help you change the world. Tell them why! Talk about the hard problems you’re solving. 2/3 of these talks give ideas and insight into hiring from sourcing to actual interview processes.
Rewriting systems is hard. People think they are going to replace their broken down horse and buggie with a bullet train and this often ends up in disaster. Successful rewrites require an incremental approach that takes months/years and often runs way over schedule. 2/3 of these talks go over how to handle rewrites not only from a high level technical perspective but a cultural/management perspective as well.
#!/bin/sh | |
BOTOFILE=${HOME}/.boto | |
### Helpers | |
helper_profile_name() { | |
printf $(basename $1) | cut -d. -f3 | |
} | |
### List all the configuration files we have for boto |
The documentation for Gerrit when it comes to formatting comments is quite lacking. Here is short list created by trial and error and looking at the source code in: | |
./gerrit-gwtexpui/src/main/java/com/google/gwtexpui/safehtml/client/SafeHtml.java | |
Lists: | |
* List item 1 | |
* List item 2 | |
- List item 1 | |
- List item 2 |
#!/usr/bin/env python | |
"""Determine if the instances in an autoscaling group are InService in its ELBs | |
attached to that group. | |
""" | |
import sys | |
import boto.ec2.elb | |
import boto.ec2.autoscale | |
import argparse |
--- | |
- hosts: all | |
gather_facts: false | |
name: CVE-2014-6271 bash vulnerability fix | |
tasks: | |
- name: check bash fix | |
command: env x='() { :;}; echo vulnerable' bash -c "echo this is a test" | |
register: command_result | |
changed_when: False |
--- | |
- hosts: all | |
user: root | |
sudo: true | |
tasks: | |
- name: update apt | |
command: apt-get update | |
- name: update bash |
I started using FreeNAS in August 2013. It is fantastic piece of software and I have been really impressed by the upgrades just in the few months I've been using it. It looks like they recently went to a plugin system as of version 9 to make installing software easier for end users. I've ran into several issues related to plugins and user + group permissions so I decided to just use the available FreeBSD port system. After fiddling for a few days (now turned into months) I believe I have created something helpful for the community and anyone interested in picking up the port system. The sandbox nature of FreeNAS's jail system is especially helpful for playing around without having any consequence on your core system.
Here are straight-forward instructions to setting up a bunch of different software on FreeNAS. If you make a terrible error, just throw up another plugin sandbox and repeat.
I've recently shifted from a straight engineering job to a job with a "dev/ops" title. What I have discovered in operations land depresses me. The shoemaker's children are going unshod. Operations software is terrible.
What's driving me craziest right now is my monitoring system.
What I have right now is Nagios.