こんにちは、平形です。

今年の６月から週に２回リモートワークをおこなっております。

今日はそのことについて書きます。

エンジニアという生き物

僕はソフトウェアエンジニアです。

エンジニアという生き方の関係上、どうしても仕事が長引いたり、勉強する事がいっぱいあったりします。

仕事以外の時間を有効に使って技術や英語の勉強をしたり本を読んだりして将来の自分に投資するのもとても重要な事です。

なぜか？？

エンジニア(特にソフトウェア開発者)が他の職種と違っている点は、安定していない。という事です。

僕の考えでは敢えて安定を目指さない事が大事だと思っています。というのも、自分の置かれている環境、役割、市場など、すべてが安定していないんです。技術は日進月歩で進化しています。自分も常に脱皮し続けていかなければいけません。どこにも安定なんてものはないんです。

だから諦めて自分が変化し続ければいいんです。

子供の誕生

今年の５月に待望の子供が生まれました。

以前は自分が父親になる実感なんて全く湧かなかったんですが、それは子供が生まれた瞬間に吹き飛びました。

赤ちゃんの産声を聞いた時、なんとも今まで感じた事のない不思議な高揚感に覆われました。

毎日、朝起きた時、ご飯を食べている時、仕事から帰ってきた時、夜寝る時と子供の事が気になって仕方がありません。

子供の笑顔が見られるだけで疲れたり、悩みだったりが一気に吹き飛びます。

とても幸せを感じています。

子供と仕事

僕は寝る時間を削っても自己の成長の為に使う時間を常に最優先していました。

それが家族を守る為だと思ってたからです。

というのも既に書いている通り、エンジニアは安定しない職種です。いつ仕事がなくなるかわかりません。

自分が前に進めていないと感じるととても不安になります。

ただそれは子供が生まれる前の話です。

子供が生まれてすぐの時はとても困惑しました。

今まで使っていた時間がどんどんなくなっていくからです。

そして考えたのは子供と過ごす時間を削ってまでして仕事を優先するべきなのか？自分の時間を優先するべきなのか？それは違う！という答えが出ました。

お金を稼ぐ事が全てではないんです。お金の事は子供にとってはもしかしたらどうでもいいことかもしれません。

人生のクオリティを考えるようになりました。それは自分ではなく家族のです。

そういう考えに至ったのは父親という立場が自分の役割リストに追加されたからです。

とはいえ、仕事の質を落とす事は避けなければいけません。

時間の使い方を変えるのです。そしてより密度の濃い時間にするのです。

限られた時間の中で育児、仕事、勉強、遊びそれぞれを全力でやるのです。

リモートワークをおこなって変わった事

集中して仕事ができるようになった

一緒に働いている仲間が近くにいればいつでも気軽に声をかけられる雰囲気があります。

声をかけられた方も急ぎの仕事じゃなければ聞き入れます。しかしリモートの場合だと顔が見えない以上そんなに簡単にはいきません。

エンジニアは仕事に集中しなければいけない時間があります。

コーディング作業の途中で割り込まれたりすると、頭の中がリセットされるんです。

頭の中で組み立てていたロジックがバラバラになります。

リモートワークにより自分だけの時間が確保しやすくなったので30分、1時間と集中して一気に仕事をやっつける事ができます。

集中する時間が増える事はプロダクティビティに大いに貢献しています。

十分な睡眠時間が確保できるようになった

エンジニアにとって睡眠時間はとても大事なものです。

それは頭をフルに使う職業だからです。

発想力がとても重要です。

なので睡眠時間を削って仕事をしたりすると、新鮮な発想ができなくなり悪循環になる場合もあります。

これは非常に重要なことです。

リモートワークにより通勤時間が短縮され、以前より睡眠時間を確保できるようになりました。

寝る事も大事な仕事です。

こんにちは、平形です。

先日8/24、弊社で4回目の外部向けの勉強会を開催しましたので、その様子をご報告させていただきます。

今回はAWS関連のトピックを私、平形と同じく弊社エンジニアの赤川がお届けしました。

今回４回目となる勉強会も盛り上がりを増してきた事もあり、弊社代表の中村が自ら挨拶を買って出てくれました。

今回もたくさんの方々にご参加いただき、大変嬉しく思っています。

内容

今回は、

• AWSを使っているならOpsWorksでDevOpsしよう！ by 平形
• AWS運用アレコレ by 赤川

の２本立てです。

イベントページはこちらのconnpassページにて

弊社では、AWS, GCP, AzureなどクラウドリソースをMSP事業、自社サービスで積極的に活用しております。今回はその中からAWSについてお話ししました。

今回の勉強会のもう一つの特徴は、スピーカーの２人とも今年第一子が誕生した新生育児パパという事です。育児と仕事の両立をして日々業務に精を出しています。

株式会社ISAOは、そんなイクメンエンジニアを応援しています！

AWSを使っているならOpsWorksでDevOpsしよう！ by 平形

AWSのデプロイサービスの一つOpsWorksについて実際の業務で得た知見を発表しました。

AWS運用アレコレ by 赤川

AWSの障害対応など日々1,000台単位のEC2の運用を行なっている中から得られた運用のコツなどを発表しました。

懇親会の様子

秋葉原名物の万世のハンバーグサンドです。

大変美味しく頂きました。

今回も多彩な領域のエンジニアの方々とお話しでき、有意義な交流会となりました。

こんにちは。デベロッパーの平形です。

はじめに

この記事ではVagrantの使い方を解説します。 なお、この記事は連載の続きになりますので、まだご覧になっていない方は、以下の記事を初めに読む事をおすすめします。 DevOps時代のアジャイルでスケーラブルな開発環境をVagrant,GitHub,Travis,Chef,OpsWorksで構築する

Vagrantとは？

Vagrant（ベイグラント）は、FLOSSの仮想開発環境構築ソフトウェア[1]。VirtualBoxをはじめとする仮想化ソフトウェアやChef（英語版）やSalt（英語版）、Puppetといった構成管理ソフトウェアのラッパーとみなすこともできる。 Vagrantを用いると、構成情報を記述した設定ファイルを元に、仮想環境の構築から設定までを自動的に行うことができる[2]。当初はVirtualBoxをターゲットとしていたが、1.1以降のバージョンではVMwareなどの他の仮想化ソフトウェアやAmazon EC2のようなサーバー環境も対象とできるようになった[3]。Vagrant自身はRubyで作成されているが、PHPやPython、Java、C#、JavaScriptといった、他のプログラミング言語の開発においても用いることができる[4][5]。 引用元：wiki

なぜVagrantなの？

まず現状の課題からお話します。 こんな事ってありませんか？

• 開発者のPCのOSがバラバラで環境構築の手順書作るのめんどくさい。
• てかWindowsの事なんか考えたくもないよ。
• ハンズオンの時にみんなの環境が違うから、みんな挙動が違って嫌になる。

Vagrantを使うとこんな事ができます。

• コードによる仮想マシンのOS指定、ネットワーク設定、利用するシステムリソースの指定。
• Chefなどの構成管理ツールを利用して環境構築する事ができる。

以下のメリットがあります。

• 複数の開発者に共通の開発環境を配布できる。
• 仮想マシンの設定が１つのファイルで管理する事ができるので、認識しやすい。
• WindowsでもMacでもLinuxでも共通の開発環境を提供できる。

vagrant使うのって面倒だと思いますか？ めちゃくちゃ簡単です！ まだ使ったことない人は、とりあえずインストールしてください！

インストール

VirtualBox

VagrantではVirtualBoxなどの仮想化ソフトウェアを使って仮想マシンを立ち上げる事になります。 今回はVirtualBoxを利用します。

ここからダウンロードしてインストール。

Vagrant

ここからダウンロードしてインストール。

クイックスタート

OSはubuntu 12.04(32bit)にします。

まず作業場所のディレクトリを作ります。

$ mkdir vagrant_test
$ cd vagrant_test

次にVagrant用の設定ファイルを作成します。

$ vim Vagrantfile

以下をVagrantfileに貼り付けてください。

# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure("2") do |config|
  config.vm.box = "hashicorp/precise32"
end

仮想マシンを起動します。

どうも。久しぶりです。 デベロッパーの平形です。

このブログに訪れたすべてのエンジニアの方々。 そして、エンジニア以外の方々。

とても感謝致します。 初めに言っておきますが、この記事ではコード、コマンドラインの一切は登場しません。

はじめに

私が今回お送りする内容は本当にスケーラブルな環境の構築、運用を手助けする事ができます。 連載記事で複数回に渡ってお届けしますが、この連載を読み終えそして実践していただければ、あなたは既にスケーラブルな環境で作業を行っている事でしょう。

この連載記事では、順番に必要なツールのインストール、使い方をハンズオン形式でお送りします。 実際に手を動かして実感していただく事がとても意味がある事だと思っています。 この回では、コード、コマンドラインは一切登場しません。次回以降にどんどん出てきます。 その前に**「伝えたい事があるんだ。君の事が好きだから」by小田和正**と叫ばせてください。

この記事は以下の方には不向きです。

• 俺は一生一人で生きていくんだ！と1日1回はトイレで意気込んでいる人。
• 後先の事なんか考えたくない。俺は今を生きているんだ！と週に３回は言っている人。

これらに該当する方。お疲れ様でした。出口はこちらです。

この記事は以下に該当する方に是非読んでいただきたいです。

• 開発者、インフラ担当者の方。
• これから新しいプロジェクトを立ち上げるんだけど、構成どうしようか悩んでる方。
• サーバーの台数が多くなったらどうしよう。と悩んでいる方。
• 開発要員が急に増えたらどうしよう。と悩んでる方。
• DevOpsとかスケーラブルな環境とかに興味があって、でも今ひとつ踏み出せない方。
• 上記を実践してみようとしたけど、挫折してしまった方。
• 開発環境で動いているコードがなぜか公開環境で動かなくて家に帰れない方。
• 本番反映が怖くて会社に行きたくない方。
• サーバーが落ちる事が不安で夜も眠れない方。
• 将来の事を考えると不安で不安で仕方なく、「とにかくもう、学校や家には帰りたくない〜。」by尾崎豊と口ずさんでしまう方。

それでは、夢の扉を開きましょう。

レガシーな開発と運用

• 開発環境、公開環境の構築は、構築手順書を元に手動でインストールしている。
• 公開環境のサーバー増設は１台ずつ手動でキッティングしている。
• パッチの適用、バージョンアップは手動で１台ずつ手順書を元に実行している。
• バージョン管理はしないで各自、修正ファイルをFTPでファイルをアップロードしている。

これらをヒューマンエラーなく、ストレスなく運用できるのはスーパーマンです。 そして、開発、運用メンバー全員が自分と同じスーパーマンでなければいけません。 凡人の僕には無理です。

現代の開発と運用

現代のもの凄い勢いで変化するサービス要求に耐えるには、様々なものを効率化しなければいけません。
素早くリリースしてユーザの反応を見ては仕様を変更してすぐに反映しまたリリースする。といった事も必要です。
近頃、開発運用の自動化は様々なメディアの記事で取り上げられ、賑わっています。 しかし、実際にどこまで自動化ができているのでしょうか？

• バージョン管理
• 環境構築
• セキュリティパッチの適用
• バージョンアップ
• オートスケール
• 自動テスト
• 自動デプロイ
• 開発環境の配布

なかなか全部はできないですよね？ でもやったほうが絶対に幸せになれます。

開発の平形です。

今日は、GitHubでpush時にAWS OpsWorksで自動デプロイする方法をお教えします。

OpsWorksはAWSで提供されているデプロイのサービスです。

＊OpsWorksについては、こちらのサイトが詳しいです。

この話は、OpsWorksにスタックとレイヤとインスタンスが存在する前提です。

OpsWorks自体、最近触ったばかりですが、
デプロイがすごく簡単にできるという事はよくわかりました。

でも、欲張りな僕は、もっと自動化できないのかな？と思ったのです。

普段、ソースはGitHubでバージョン管理しているので、
GitHubにpushしたら同時にデプロイできないのかな？と。

そしたら、ビックリするほど簡単に実現できました。

GitHub側で設定が可能です。
アプリケーションのリポジトリのページの「Settings」

「Service Hooks」

AWS OpsWorks

以下の項目は全て必須なので、全部入力します。

ここで、OpsWorks側の情報が必要になります。

まずは、Stack Idですが、一見これがわかるところが、AWS Managed Consoleの画面上にはありません。
手っ取り早くこれを確認する方法はStackの画面のURLをみる事です。

次にApp Idですが、同じくOpsWorksの画面で、「Apps」=>「アプリケーション名」をクリック

OpsWorks IDがApp Idです。

こんにちは。
開発の平形です。

初投稿になります。

Gitでcloneした後に、何かが足りなくてうまく動かない事がよくあります。

そして気づくのです。

あ、submoduleをクローンしてねーじゃん！
※submoduleについてはこちらの記事が参考になります。

このパターン何回目だよ！
と自分が嫌になってしまいます。

そしていつも、

git clone git://github.com/foo/bar.git
git cd bar
git submodule update --init --recursive

といったお決まり作業をする訳です。
でもついつい忘れてしまうんですよね。

で、調べてみるとちゃんとあるんですね。

git clone --recursive git://github.com/foo/bar.git

これで、クローンと同時にサブモジュールもクローンされます。
通常のクローンと使い分ける必要も特にないので、これからはこれを使っていこうと思います。

読んでいただいてありがとうございました。

まだまだ、寒い日が続いておりますが、お体にご自愛くださいませ。

参考にしたページ

http://stackoverflow.com/questions/3796927/how-to-git-clone-including-submodules