はてなブックマーク

答え リモートサーバーに実行プログラムを送り込む仕組みだから。 そのプログラム=モジュールが主にpythonで書かれているから。(*) EFFICIENT ARCHITECTURE Ansible works by connecting to your nodes and pushing out small programs, called "Ansible modules" to them. How Ansible Works | Ansible.com 試してみよう ansible コマンドを実行 ansible 2.6.1 config file = /Users/yuma/.ansible.cfg configured module search path = [u'/Users/yuma/.ansible/plugins/modules', u'/usr/share/ansibl

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

{ "version": "0.2.0", "configurations": [ { "name": "Debug", "type": "go", "request": "launch", "mode": "debug", "remotePath": "", "program": "${workspaceRoot}/some_package/cmd/name", "env": { "GOPATH": "/Users/yinaura/go", }, "args": ["yuma","--last_name=inaura"], "showLog": true } ] }

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Approveとは (…を)よいと認める、(…に)賛成する、(…を)(正式に)承認する、認可する 使い方 PRを見て「この変更でOK」って思ったら、Approveを選んでレビューを送ろう。 ( ちなみにレビューコメント0個でも Approve を送れる ) 一覧 PR ではこんな風に、Approveを付けた人が分かる。 レビュアーの誰がPRを承認していて、誰がしていないのかが分かりやすい。 Request Changes 「この状態ではPRは通せない」「修正が必要だ」と思ったら Request Changes を選んでレビューを送ろう。 Comment 承認も非承認もしない場合は、 Comment を選んでレビューを送ろう。 「Approve とか Request changesとか、運用的に使わない」って場合は、この Comment だけでOKだ。 取り消し いったん Approve /

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

現チームの構成 アジャイル開発をしている。少人数のチーム。 業務で扱う範囲が非常に広い。 ここでは教わる側を「ビギナー」。 教える側の代表を「メンター」と呼ぶことにする。 デイリーセッション (ミニ朝会) を開くようにした チームでは毎日、ホワイトボード前で朝会をおこなっている。 これは立ちながらの短時間のミーティングで、各メンバーがそれぞれ、自分の進めるストーリーを話したり、実装の相談をしたりする時間だ。 この朝会のすぐ後に、メンターとビギナーで、毎日必ずセッションを開くようにした。 ビギナーが分からないこと、気になることや、逆にメンターが気になっている点などを、何でも話し合って、質疑応答する時間だ。 (僕たちはこれを「ミニ朝会」と呼んでいる) やり方 ビギナーが何か、朝会で気になることがあれば、メンターに質問する。メンターがそれに答える。(後述するが、このやり方はその後改善した) 毎回

この例では channel.history を参照できる方法を紹介する。 App の作成 https://api.slack.com/apps から App を作成する App に チャンネルへのアクセス権を付与する OAuth & Permissions > Permission Scopes で利用可能なスコープを追加する。 ここでは Access user’s public channels. ( channels.history ) を選ぶ。 チームに App をインストールする App用のトークンが発行されるので控えておく 注意: ここでは例として載せるが、通常はトークンは公開してはいけない Web API でアクセスする テスターを使うと、簡単に Web API 用のURLが発行できる。 トークンを変更する このテスターで生成されるURLは**「あなたのSlackアカウント」*

$ gem search ^bundler$ --all *** REMOTE GEMS *** bundler (1.14.6, 1.14.5, 1.14.4, 1.14.3, 1.14.2, 1.14.1, 1.14.0, 1.13.7, 1.13.6, 1.13.5, 1.13.4, 1.13.3, 1.13.2, 1.13.1, 1.13.0, 1.12.6, 1.12.5, 1.12.4, 1.12.3, 1.12.2, 1.12.1, 1.12.0, 1.11.2, 1.11.1, 1.11.0, 1.10.6, 1.10.5, 1.10.4, 1.10.3, 1.10.2, 1.10.1, 1.10.0, 1.9.10, 1.9.9, 1.9.8, 1.9.7, 1.9.6, 1.9.5, 1.9.4, 1.9.3, 1.9.2, 1.9.1, 1.9.0, 1.8.9, 1

describe "ABC" do it { is_expected.to start_with 'A' } it { is_expected.to end_with 'C' } it { is_expected.not_to start_with 'X' } it { is_expected.not_to end_with 'Z' } # 確かに正規表現よりドキュメンタブルではある it { is_expected.to match /^A/ } it { is_expected.to match /B$/ } it { is_expected.not_to match /^X/ } it { is_expected.not_to match /Z$/ } end

「英語はエンジニアに必須」とは言っても、周りを見渡して、英語の文献を読んでいる人はあまりいない。 僕はエンジニアとしてのレベルはまだまだ低いが、英語で技術書を読むことにチャレンジしている。 その理由をご紹介する。 理由1. 一粒で二度美味しい 我々日本人はすでに「日本語」には熟達している。 今後どんなに日本語を読んでも「日本語力」そのものを大きく引き上げることは難しい。 ゲームで言うと「スキル名: 日本語」にはポイントを最大まで割り振ってしまっている状態だ。 だが英語で技術書を読むと「英語力」と「技術的知識」の両方に、ポイントを一挙に割り振ることができる。 つまり長期的に考えた時の費用対効果がきわめて高いだろう、ということが考えられるのだ。 英語で技術書を読み始めると、しばらくは日本語で読むよりも理解度がかなり落ちるだろうが、そこはトレードオフとして受け入れる。 これは短期的成果をとるか、

Docker側の用意 Docker イメージの作成 この例では、次の条件でイメージを作る。 pythonが使える ( Ansble の実行環境ため ) sshで直接接続ができる ssh ユーザー: root ssh パスワード: screencast FROM ubuntu:16.04 RUN apt-get update && apt-get install -y openssh-server RUN mkdir /var/run/sshd RUN echo 'root:screencast' | chpasswd RUN sed -i 's/PermitRootLogin prohibit-password/PermitRootLogin yes/' /etc/ssh/sshd_config # SSH login fix. Otherwise user is kicked off a

Travis CI for Complete Beginners - Travis CI より 動作確認用のレポジトリをForkする https://github.com/plaindocs/travis-broken-example で Fork ボタンを押すだけ ( * Forkは好きなレポジトリを自分のレポジトリとして、まるまるコピー出来る機能) ForkしたレポジトリをCloneする 手元に持ってくる $ git clone git@github.com:YOUR_USER_NAME/travis-broken-example.git $ cd travis-broken-example

goroutineによる非同期処理で、 100要素の配列を作る 配列の中身を1個ずつスライスに追加していく (元の配列と、中身の同じスライスが生成されるはず) スライスの要素数と中身を出力する というプログラムを作ってみる。 最初のコード var wg sync.WaitGroup var numbers = [100]int{} // 100要素ある配列 copiedNumbers := []int{} // 空のスライス for i := range numbers { wg.Add(1) // 非同期処理のカウンタをインクリメント go func() { // 非同期処理の記述 copiedNumbers = append(copiedNumbers, i) wg.Done() // 非同期処理のカウンタをデクリメント }() } wg.Wait() // 非同期処理が終わるのを待つ

How to OSの種類次第でインストール方法が変わる。 root ユーザーで 以下のどれか を実行すれば、だいたいイケるはず。 Ubuntu系

ステータスの更新 /status [絵文字] [メッセージ(省略可)] と入力する。 結果 ステータスが変わる。 ステータスのキャンセル /status と打つだけでOK。 結果 チャットメンバー募集 何か質問、悩み事、相談などあればLINEオープンチャットもご利用ください。 Twitter

Qiita歴1年の @YumaInaura です。 僕も最初は、Qiitaに記事を書くのはやや抵抗がありましたが。 だけど1年書いてみたら、良いことしかありませんでした。 なので今迷ってるなら「とりあえず書いちゃおうぜ」ってことをお伝えします。 こわかったこと 僕が Qiita に記事を書く前に悩んでいたこと。抵抗を感じていたことは次の通り。 1. リアクション 記事を書いてもまったく反響がなかったらどうしよう。すごく虚しくなりそうだ。 2. クオリティ ネットでよく話題になっている記事のような「ちゃんとしたまとめ」を書かなければいけないんじゃないだろうか。 ほんのちょっとした記事をかくのは恥ずかしいことなんじゃないだろうか。 それを考えると、ひとつ記事を書くにも労力がかかりそうで気が重い。 3. ミス もし間違った情報を発信してしまったらどうしよう。 迷惑をかけるんじゃないだろうか。 4

# ID が同じだと true Book.new(id: 1) == Book.new(id: 1) => true # ID が違うと false Book.new(id: 1) == Book.new(id: 2) => false # ID が同じで title が違っても true Book.new(id: 1, title: 'サピエンス全史') == Book.new(id: 1, title: 'チョコレートの世界史') => true

string="--ABC--" regexp="-(A)(B)(C)-" if [[ $string =~ $regexp ]] then echo ${BASH_REMATCH[0]} # => -ABC- echo ${BASH_REMATCH[1]} # => A echo ${BASH_REMATCH[2]} # => B echo ${BASH_REMATCH[3]} # => C fi 説明 $BASH_REMATCH[0] には、キャプチャとは関係なく、マッチした文字列全体が入る。 $BASH_REMATCH[1] 以降には、キャプチャした順番で、マッチした文字列が入る。 ちなみに 正規表現部分を直書きするとダメで、いちど変数に収める必要があるっぽい。 string="--ABC--" if [[ $string =~ "-(A)(B)(C)-" ]] then echo

最近自宅で、寝ながらノートブックを触るようになった。 そしてめちゃくちゃ自宅で過ごすスタイルが変わった。 図解 こんな感じ。 枕を二個使って頭の高さを調整する。 足をぐっと折り曲げて、太ももをノート置き場にする。 腰の骨でノートの下を支えるイメージ。 悩み エンジニアながら、自宅に帰ると、なかなかPCを開く気になれないことが悩みだった。 なぜなら肩は凝るし、なんだか気分が乗らなくて、他のことをやりたくなってしまう。 なので仕事の勉強は主に「技術書を読むこと」だった。 ちゃんと自宅でもPCを触れるようになりたいと思って、「正座しながら」「マッサージチェアに乗りながら」「普通に椅子に座りながら」など、いろいろなバリエーションでノートを触ったり、モニタの角度を調整したり、バランスボールに乗ってみたり、いろいろ試してみたが、どれもフィットしなかった。 会社にあるほど良い椅子もデスクもないし、座りな

ごく基本的なことだが、今までよく考えずに使っていた。 source コマンドというと、「.bash_profile を変更した後に使うもの」ぐらいのイメージしかなかった。 謎 「なぜひと手間かけさせるのか」「プロフィールファイルを変更した時に、環境設定も自動更新してくれたら良いのに」と思っていた。 だが source コマンドは実は、環境をリロードするためのものではない。 ファイルに書かれた内容を 忠実にコマンドとして実行していくものなのだ。 $ source と $ bash の違い では $ bash でファイルを実行するのとは何が違うのか。 $ bash [file] はシェルスクリプト内の 「裏側=閉じられた環境」 でコマンドを実行する。 $ source [file] は 「表側=開いた環境」 で、コマンドを実行する。 動作が変わる例 たとえば「変数に代入するだけ」の単純なスクリ

と書けば、何度やっても怒られない。 実際にはエラーを無視するのではなく「既にディレクトリが存在する場合は何もしない」という動作らしい。 Help $ man mkdir | cat MKDIR(1) BSD General Commands Manual MKDIR(1) NAME mkdir -- make directories SYNOPSIS mkdir [-pv] [-m mode] directory_name ... ... -p Create intermediate directories as required. If this option is not specified, the full path prefix of each operand must already exist. On the other hand, with this option spec