はてなの金次郎

Pythonエンジニアです。

はじめてのSSH用ユーザー追加

はじめに

SSH用のLinuユーザの作成の作業依頼を初めて担当することになったため、その作業内容と目的についてまとめます。Linuxユーザの作成は定期的かつ頻繁に発生する作業であるためしっかりと理解しておく必要があります。

Linuxのユーザ作成

なにをするのか

なぜするのか

  • 例えば、新入社員のためのユーザ作成や新しく加わるデベロッパ用のユーザ作成など、アプリケーションやシステムの開発・運用のためには欠かせない作業です。

サーバ側

ユーザ追加

$ useradd -m username
$ passwd username

ランダムなパスワードを設定し、後で本人に設定し直してもらう

権限変更

$ cd /home/username
$ mkdir .ssh
$ chmod 700 .ssh
$ touch .ssh/authorized_keys
$ chmod 600 .ssh/authorized_keys

sudo権限付与

$ gpasswd -a username sudo

所有権の確認

$ ls -la /home/username/.ssh
$ ls -la /home/username/.ssh/authorized_keys

所有者 username 、グループ group であることを確認する。
所有者、グループが異なっていた場合は正しく設定し直す。

$ chown username:group .ssh
$ chown username:group .ssh/authorized_keys

クライアント側

鍵の作成

$ cd ~
$ mkdir .ssh
$ cd .ssh
$ ssh-keygen -t rsa

configファイルの作成

~/.ssh/config

## 踏み台サーバ
Host <<Domain>>
     User <<username>>
     Hostname <<IP Adress>>

## 接続先サーバ
Host <<Domain>>
     User <<username>>
     Hostname <<IP Adress>>
     ProxyCommand ssh <<踏み台サーバのDomain>> nc %h %p

tech.recruit-mp.co.jp

公開鍵の登録

$ vi ~/.ssh/authorized_keys

authorized_keys に公開鍵をペーストする。

サーバ接続確認

$ ssh-add ~/.ssh/id_rsa
$ ssh -A app1.production-jp.gu-mania.vpc

参考記事

eng-entrance.com

eng-entrance.com

Alexa Salon #1 に参加してきました。

感想

dev.classmethod.jp

Alexa Salonに参加してきました。スキル開発をするにあたって色々勉強させていただきました。じゃんけん大会負けてしまいましたが、本も読んでみたいです。

はじめてのAlexaスキル開発 [音声認識アプリ開発の基礎知識を身に付ける! ]

はじめてのAlexaスキル開発 [音声認識アプリ開発の基礎知識を身に付ける! ]

SINさんのブログとてもわかりやすかったのでおすすめです。

dev.classmethod.jp

基礎から学ぶVUIの勘所

自己紹介

VUIとは

会話における法則

  • Voice Communication
  • メラビアンの法則(視覚情報:58%、聴覚情報:38%、言語情報:7%)
    • 言語情報は10%未満
    • Echoは20~30%で戦う必要がある

VUI設計で気をつけること

  • NUDGE
    • 行動経済学用語
    • ユーザーが相手の自然かつ無意識に意図通りの行動を起こすように環境を整え促すこと

留意点

  • 選択肢を例示する
  • はい/いいえで答えられるように促す
  • 一息で言い切れる長さ
    • ユーザーが鬱陶しいと思わないように
    • 書き言葉をそのまま使っては行けない
    • 録音して長いと思ったところは切る
  • 「〜ですか?」:は等価、「〜ですね?」は強調
    • はいと言ってほしい時など

GRAPH BASE UI vs FRAME BASE UI

  • VUIではFRAME UIが良い

MULTI-TERN

  • ユーザーがたくさん話しすぎるのはだめ
  • ピンポンの会話にする

VUI設計の作り方

  • 目的を決める  - なにをしたいか  - そのためにUX的に音声でどう体験してほしいか。  - どこまでVUIにするか。  - VUI以外との連携は。  - ユースケースを想像する。毎日使うのか、必要な時に使うのか。
  • キャラクター設定
    • ペルソナを作り、発話に一貫性を持たせる
    • ユーザーとの距離感
    • Alexaの立ち位置
  • ハッピーパス
    • ストレートな対話を作り、これを軸に
  • INTENT/SLOTの設計
    • State-Intent-Slotのスコープを決める
    • Intentはなるべくシンプルにまとめる
  • UI図
    • ハッピーパスを肉付けする
    • 重要なSlotと必須ではないSlotを区別しておく
    • Slotの最中に別Intentに飛ぶケースを想像しておく
    • 結構修正するので具体的な発話を書かない
  • UTTERANCE表の作成
    • 規模によっては以外と重要
    • 被ってないか確認
  • シノニム/バリエーション
    • ひたすら想像力
    • 5種類をランダムに
    • 頻度によってメッセージを帰る
  • エラーハンドリング
    • キャラクラー設定を元に判断する
    • 謝りすぎない
    • 疑問形で終わる
    • エラー回数によって選択肢を明示する
    • ストップへの誘導

まとめ

  • VUIはAlexa開発のキモ
  • 図を書くまえの準備がクオリティを上げる

Alexa-SDKについて

www.slideshare.net

自己紹介

  • 平内真一さん
  • アプリケーションエンジニア
  • ブログを業務時間に書いていい

Alexa SDK

  • 煩わしい作業をSDKに押し付けて、開発者はロジックに集中できてウハウハ
  • リクエスト・レスポンスJSONの抽象化
  • データの保存
  • 処理のルーティング(ハンドラ登録)
  • ステート(状態)

バージョン1と2

  • 4/18以前
  • はじめてのAlexaスキル開発
  • Lambdaのテンプレート

バージョン2

  • ハンドラの実装法穂が変わった
  • データ永続化の記述が明確になった
  • コア機能のみの利用可能
  • Node8対応(async/await)
  • DynamoDB以外も利用可能
  • AlexaサービスAPIのラッパー提供
  • Java + Node.js

https://dev.classmethod.jp/cloud/alexa-sdk

変更点

  • tell, askの廃止 --> ResponseBuilder
  • ステートの廃止
  • ハンドラのインターフェース canHandle
  • データ永続化の要領
  • 例外時の処理

最後に

  • Ver1の方が簡単に描ける
  • Ver1に未来はあるのか・・・?
  • これから取り掛かるならVer2でいいかも
  • 個人的には、Ver2押し
    • データ永続化が明確
    • canHandleも慣れると悪くない
    • Alexa APIへのアクセスが超簡単
    • async / await 最高
    • TypeScriptで書ける

大質問大会

Q.対話モデル・対話フロー設計時のオススメの方法があれば教えてください。

Q.開発方法、事例、活用ポイントについて

  • Cloud9
  • alexa-conversation テスト

Q.ニーズが高いスキルはどのようなスキルか

  • Amazon的には子供向けスキル
  • USでもキッズ向けが人気
  • キャラクターの声がなんかしてくれる

Q.広告ポリシー

  • 子供向けは広告だめ

Q.勝手に喋り出す機能はないのか?

  • プッシュ通知機能はある

Q.バックエンドに機械学習を絡めることはできるか

  • あったら面白そう

DBテーブル設計入門に参加してきました

感想

supporterzcolab.com

サポーターズCoLabの「DBテーブル設計入門」に参加してきました。

DB設計ムズイ。

データの種類によってテーブルを分割したり、ミドルウェアを変更したりと考慮するべき点が多いなと改めて感じました。 アンチパターンは存在するが、正解があってないような世界だと思うので、勉強し続けることと良質な経験を重ねることが大事なのかなという所感です。

ゲームアプリのDBテーブル設計を実例にどのような設計にするべきなのかということを学べました。

スライド

共有はありませんでした。

メモ書き

自己紹介

  • 梶川 琢馬さん
  • サーバーサイドエンジニア3年目

DBテーブル設計の重要性

  • データの蓄積や検索を楽にする
  • データはシステムより長く残り続ける
  • 後から変更しづらい
    • 影響範囲が広いため
    • メンテナンスがしづらいため

DBテーブル設計の流れ

  • 論理(概念)設計:人間のための設計
    • ビジネス要件をデータモデルとして表現する
    • エンティティやリレーションの定義
    • 正規化
  • 物理設計:システムのための設計
    • セキュリティやパフォーマンスを考慮
    • 水平/垂直分割、Master/Slave構成
    • 正規化を崩す
    • ミドルウェアを変更する

オンラインゲーム

  • ユーザ数が多い
  • リリース後に継続して改修

データの分類

  • マスタ
    • 一度登録すると頻繁に更新されないデータ
  • トランザクション
    • 頻繁に更新されるデータ
  • サマリ
    • 集計結果を保存する。主に分析用。
  • キャッシュ
    • 頻繁に参照されるデータの置き場所。
  • ログ

テクニック

  • 1対1テーブル
  • クラス継承
    • 単一デーブル継承(STI
    • テーブル構造を変更しやすい
    • SQL原則から外れる
    • クラステーブル継承(CTI
    • 後からテーブル構造を変更しにくい
    • SQL原則にのっとった方法
    • 具象クラス継承(CCI
    • 全体から検索しにくい

qiita.com

  • ビジネス要件を把握する
  • チームメンバーと議論する
    • 既存のテーブル設計について
    • コードレビューよりも早めにテーブル設計レビューを依頼する

データ特性に応じたミドルウェア選択

おすすめ書籍

SQLアンチパターン

SQLアンチパターン

  • 現場で役立つシステム設計の原則

SRE がよく利用するソフトウェアの理解と分類講座に参加しました

感想

supporterzcolab.com

サポータズCoLabの「SRE がよく利用するソフトウェアの理解と分類講座」に参加しました。

SREエンジニアとして働くためには並大抵ならぬ努力がいることを感じざるを得ませんでした。

一方で、SREエンジニアとしての働き方にかなり興味を持ったのも確かです。

「自動化」「制御してやったという達成感」

SREエンジニアとしてのモチベーションを尋ねたときの回答です。

それを聞いたとき、はじめて自分が書いたCIのymlが期待通りの挙動をしてくれたときに幸福感を感じたことを思い出しました。

コードをゴリゴリ書くことが1番の楽しみでしたが、なるほどそういう働き方もあるなという気づきをいただきました。

「一番困っていることから手をつけるのが良い」

オススメの勉強方法です。まずは課題を見つけるところから少しずついらいろな技術に精通していけたらと思います。

裏の勉強会がかなり盛り上がっていたようですがこちらの勉強会に参加してよかったです。

帰宅後、それぞれのサービスをググって概要だけでも眺めてみましたがかなり全体像がつかめた気がします。

今回紹介していただいたサービスだけでも

な、なな、なんと

43個

ありました。(驚)

全てに精通する必要はないですが、どういったツールなのか、どういう違いがあるのかくらいは理解しておきたいですね。

speakerdeck.com

以下、メモ書きです。

メモ書き

自己紹介

  • 北野勝久さん
  • スタディストSREチームリーダー

困っていたこと

  • コード管理されておらずブラックボックス化したインフラ
  • 障害が発生してもモニタリング・管理が貧弱で状況がすぐに掴めない
  • 何からやったらいいかわからないし周辺技術もたくさんある

ひらすら勉強

  • 効率最悪
  • 時間の無駄

これを知ってれば

  • SREの全体像をみれていれば...
  • 闇雲に走る必要はなかった

SRE?

  • Google
  • システム管理者, DevOpsとは何が違うのか
  • ソフトウェアエンジニアが、システム運用をしたらどうなるか?という観点で再定義されたシステム管理者の役割
  • class SRE inplements DevOps
    • それ以外の役割も担う
    • それ以外の役割は各社で異なり厳密な定義はない

youtu.be

話す範囲

  • 話さないこと
    • ベーススキルセット
  • 話すこと
    • SREの責務範囲の枠組み
    • ツール(AWSメイン)

Infrastructure as Code

Monitoring

Log

  • ログの転送ツール(フィルタリングや加工も可能)

ChatOps

  • Slackなどのチャットツールからコマンドなどを入力することで何かしらの作業を行う

CI/CD

Development Environment

Infrastructure Automation

  • イベント駆動アーキテクチャでインフラ操作自動化することを意図して記載
  • 「○○が起きたら、XXXが起動し、△△する」というXXXの部分

Security

Data

Incident Management

まとめ

  • 全体像を把握し、それぞれのツールの役割を理解するのが良い

QA

  • オススメの勉強方法や書籍
    • SRE book for FREE in English
      • Googleと自分たちの違いを理解する
      • 分散処理が世界で最も強い会社
      • 自分の会社とGoogleとの差分だけ認識して学習する
      • 書いてあることを全て実現するのは無理だし意味がない

www.publickey1.jp

GKEで学ぶKubernetes入門に参加してきました

はじめに

supporterzcolab.com

サポーターズCoLabの 「GKEで学ぶKubernetes入門」に参加してきました。講師は株式会社カブク の 吉海さんという方でした。

スライド

speakerdeck.com

入門Kubernetesに参加してきました

はじめに

supporterzcolab.com

サポーターズCoLabの『入門Kubernetes』に参加してきました。

GKEのチュートリアルをやったことがあるのと、GKE入門の勉強会に参加したことがあるくらいで、k8sはまだまだ理解不足だったので今回の勉強会に参加しました。

とてもわかりやすかったです! Dockerの前提知識があれば誰でも聞ける内容だったと思います。

「こういう課題があったからこういうサービスや概念が生まれた」

のようにサービスや概念の紹介だけではなく、「どういった課題を解決するため」という技術が生まれた背景やデファクトスタンダードになった理由とともにストリー仕立てに構成されていたため非常に飲み込みやすかったです。

また、プレゼンの仕方も勉強させいただきました。ライブコーディングはたまに見ますが、ホワイトボードを使う講義は初めてだったので新鮮でした。

要所要所で笑いを誘うテクニックも含め、聴講者を集中させる技術を自分も磨きたいです。

ホワイトボードとQAの部分のみですが以下メモ書きです。

bit.ly

自己紹介

  • 片岡航平さん(@p__oka)
  • 株式会社ワクテカCTO
  • FITRA, FITRA Workout (DMM英会話のFitness版)

Dockerとは

  • コンテナ型仮想化環境
  • プロセスを隔離させる

Kubernetes

Case Study

  • Railsアプリケーション
  • Railsのプロセスを常に4つ起動することを保証したい
    • deployment
      • imageとプロセス数を定義する
      • オートスケールも可能(4~10)
      • RollingUpdateStrategy
  • ロードバランシングを適切に設定することが難しい
    • Service
    • Service間での通信(マイクロサービス)
    • 外部からのアクセスがない場合は必要ない
  • どうやって外部に公開するか
    • ingress
      • Service との連携する
      • 一つのドメインで異なる Service に通信できる
      • できるが推奨されていない
  • 環境変数の管理
    • ConfigMap
    • ハードコードしかできない?大きな問題
    • imageを置換する
    • CIでsedしまくる
    • Kubernetes Helm

コンテナランタイマー

  • gVisor
  • Dockerは影響力を失いつつある
    • 抽象レイヤーがないという脆弱性がある

クラスタ

Dockerコンテナを実行するために用意された実行環境

ノード

物理(仮想)マシン

ロギング

  • GCPの場合は意識せずstackdriverにたまる
    • stackdriverは監視もできる
  • アプリケーションのログは全て標準出力にだす
  • DataDogはKubernetes完全対応
  • サイドカー(requestヘッダにrequestIDを入れる)

Istio(イスティオ)

  • Envoy を入れるなら Istio ごと入れるとよい

speakerdeck.com

Red Hat Openshift

  • 本番環境適用に向けた多様な機能

「独学プログラマー」から学んだこと。

独学プログラマー Python言語の基本から仕事のやり方まで

独学プログラマー Python言語の基本から仕事のやり方まで

概要

  • 著作: 「独学プログラマー
  • 著者: コーリー・アルソフ
  • 監訳: 清水川 貴之
  • 著者経歴:
    米クレムソン大学で政治学を専攻、卒業後にシリコンバレーに住みながら独学でプログラミングを身に付ける。一年後にeBayのソフトウェア・エンジニアとして就職。その後、シリコンバレーにて複数のスタートアップに参画し、主にフルスタック・エンジニアとして活躍。

要約

Pythonプログラマーとして働くために必要な知識や学習の仕方、身につけておくべきプログラミングの原則や考え方などを網羅的にまとめています。また、ネクストステップとして様々な参考文献や書籍が紹介されています。

面白かった章とその理由

第23章 プログラミングのベストプラクティス

プログラミングの原則を学べる章です。

例えば、DRYや直交性など、誰もが従うべき原則を知ることができます。しかし、実際には原則から逸れたコードを意外と見かけることが多いような気がします。

今回ここで知れたことは大きな収穫ですが、知っているだけではなかなか実現することは難しいと思うので、この原則を実現しているコードにたくさん触れていきたいですね。

コードレビューの際にも、ここで紹介されている原則の視点でレビューしてみるとよりよくできるアイディアを提示しやすくなりました。

とても勉強になりましたし多くの人に知っていただきたいので、以下、紹介されていたプログラミングのベストプラクティスを引用させていただきます。

  • コードを書くのは最後の手段
  • DRY
  • 直交性
  • どのデータも1カ所で定義しよう
  • 1つの関数には1つのことだけをさせよう
  • 時間がかかりすぎるなら、たぶん何か間違えている
  • 最初に良い方法で実装しよう
  • 慣例に従おう(PythonであればPEP8)
  • 強力なIDEを使おう(PythonであればPyCharm)
  • 素晴らしいプログラマーはロギングする
  • テストされていないコードは壊れているコードである
  • できるだけ多くコードレビューをしよう
  • 常にセキュリティについて考え、学びましょう

以上のような原則を身に付けることで保守・運用がしやすいソフトウェアを構築することができます。

理解できなかった章とその理由

すべての章が初学者にとってわかりやすく構成されています。また、これから独学で頑張ってみようというモチベーションを掻き立てるのもうまいです。例えば、以下の記事が紹介されています。

スタック・オーバーフローが2015年に調査したところ、
アンケート回答者の48%がコンピューターサイエンスの学位を持っていませんでした。

www.infoworld.com

私が普段働いている環境は優秀な方が多く、出身校や学部もまた同様です。中には小学生、中学生からプログラミングを始めたという人もいます。

私は理工学部でしたが、コンピューターサイエンスを専攻していたわけでもありませんし、プログラミングを始めたのも大学4年生です。そもそものスタートとして出遅れているなという引け目がありました。

しかし、この記事によると全くの未経験者から始めたという方が半分もいるということです。この数値だけでも勇気をもらいました。また、スタートした時期は関係なく、スタートしてからどれだけ頑張れるかが重要だと思わせてくれました。

仕事に活かせそうな知識、活かせそうな状況と活かし方

  • プログラミングのベストプラクティスを身に付ける
  • OSSにコントリビュートする
  • ランサーズ、クラウドワークスに登録する

レポート作成方法

@ledsun blog「新人エンジニアにレポートを書かせて技術書の読み方を伝える。」という記事で紹介されているレポート作成方法を使わせていただきました。

ブクログ始めました

https://booklog.jp/users/jumpyoshi