fluentdで集約したerror_logをslackに流すと捗る - UNIX的なアレ
nanapiでは社内のチャットツールに、Slackを導入しています。Slackの便利なところはintegration周りで、要するに他のツールとの連携が非常にし易いんですね。そういった、Chatを中心にした業務効率化を最近ではChatOpsと呼んだりします。 http://nanapi.co.jp/blog/2014/07/24/nanapi_chatops/ ChatOpsの重要な点はコンテキストを共有できる点ですよね。「○○ってエラーログが出てるよ」みたいな情報を直接誰かに伝えるのではなく、ログが出ているという状態をChatを経由して同じものを見ることで、説明が非常にラクになります。 ほかにもデプロイをHubot経由で指示したり、ステータス取得をしたりなど様々な使い方がありますがやはり重要なのは同じ画面を皆が見ているということですね。そういった点がChatOpsの大きなメリットとしてあ
CTO募集とかフルスタックエンジニア募集とか都合の良いこと言っちゃだめ - UNIX的なアレ
若干釣り気味のタイトルです。CTO募集すること自体は悪くないんだけど、その内容についていろいろ思うことがあったのでちょっと書いてみます。 やたら見かけるCTO募集 wantedlyとかみるとですね、とにかくCTO募集している会社が多いわけですよ。そりゃITな会社つくるとしたらCTOはいた方がいい。 でもね、多くの社長が話すCTO像って別にCTOを求めてる訳じゃないんですよね。要するに、なんでもできるエンジニアが欲しいというだけのパターンが多い。 とくに募集要件みてもピンと来ないんですよ。別にそれってCTOである必要ないでしょ？と思ってしまう。例えば、 アーキテクチャの設計ができて スマホアプリできて サーバサイド開発もできて インフラもひと通りできて マネージメントできて イケてる提案もしてくれる あと、言うことは聞いてね みたいなことを考えてる人が多い。すごく多い。まずね、いないよそんな
エンジニアナビ主催セミナーでnanapiのシステムについて話してきました - UNIX的なアレ
4/10に開催されたエンジニアナビ主催のイベントでnanapiのシステムについて話してきました。今回は珍しく、nanapiのワンマンライブ的な感じです。時間も40分ほどあったので何について話そうかなーといろいろと考えてました。 自分がインフラ出身なのでどうしてもその辺り中心にはなってしまいましたが、極力nanapiでの開発手法やフローなどについても話すように心がけました。イベント後のアンケートや質問などみても満足度が高かったようで良かったです。 質疑応答で答えられなかった内容 当日は付箋で質問をもらう形式だったのでたくさんの質問をいただくことができました。時間の関係で全部お答えすることができなかったので、もらった質疑応答に関してここでお答えします。近い質問は勝手にマージしちゃっています。 事業について Q: 一人でやっているときの技術的な問題はどんなもので、どう解決したか？ A: 小さな技
いかにしてベンチャーの社内ネットワークを構築するか - UNIX的なアレ
情シス担当者なんていない 現在、nanapiは社員数30名弱くらいの会社規模です。アルバイトさんを含めると70名くらいになりますが、そのうちエンジニアは私を含めて8名。このくらいの会社の規模だと、まだ情シス的な仕事を専門的にやるような人はいません。 当然、ネットワークの専門家もまだ弊社にはいないので必然的にエンジニアの誰かがこのあたりを担当することになります。ベンチャーにおいてだいたいの場合、こういった技術的な行き場の分からない仕事ってのはCTOがやるもんです。 しかし、情シス的な仕事って本当に難儀な仕事。動いてて当たり前、高速で当たり前、ちょっとでもネットワークが遅くなるものならその時点ですでに障害です。 外注するという選択肢もありますが、何かしら社内でネットワークのトラブルがあれば少なくともその瞬間はたぶん僕が対応するなり調査するなりすることになります。どうせそうなるのであれば、自分で
nanapi Ver5をリリースするときに使った社内リリースの仕組み - UNIX的なアレ
久々のエントリーです。先日、3周年ということでnanapiをリニューアルしました！今回は「メディアからプラットフォームへ」をコンセプトとし、大幅なリニューアルを実施しています。 リニューアルのコンセプトとかは、詳しくはこちらに書いてあります。 nanapiがVer5.0にバージョンアップしました : けんすう日記 社内リリースの重要さ UIやデザイン、細かい機能など制作側としてはすごく作り込んでいるわけですが、数週間1つのプロジェクトにコミットしているとなかなか客観的に見ることができなくなってきます。 そんな時は客観的な意見をもいたくなるものですが、その意見のもらい方がなかなか難しい。 弊社もサービスを立ち上げてから3年が経過しているわけで、従業員数もそれなりの人数になってきています。となると、開発環境やステージング環境を見てもらうにしても、面倒な手順がちょっとでもあるとなかなか難しかった
screenを初めて使うためのチュートリアル - Unix的なアレ
screenというものすごく便利なアプリケーションがあります。上記写真のように、1つのターミナル内で、仮想的に複数の端末を起動させることができるものです。 ただ慣れるまでは少々使い方がとっつきづらいという話も聞きますので、今回はscreenを基本的に使えるまでのチュートリアルを紹介したいと思います。 どんなことができるの？ 複数の仮想端末をあげるとどういったメリットがあるのでしょうか？実際に自分はscreenを使うまではターミナルを複数起動させ、Desktop上はターミナルだらけになっていました。 実際はそれでも問題は起きないのですが、個人的にはローカルPC側では極力起動しておくアプリケーションを少なくしたいと思っているため、screenを使うようになりました。 ただそれだけであればWindowsならPoderosa,MacならiTerm,GnomeならGnome端末があるのですが、scr
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
