事業開発部の塩谷 (@kwappa) です。 クラスメソッドの関連会社であるアノテーション株式会社の研修として依頼を受け、チームと心理的安全性、それに礼節というテーマで話をしてきました。 スライド 概要 ここしばらく重点的に書いたり喋ったりしている、心理的安全性とその土台となる礼節がテーマです。昨年のDevelopers.IO Tokyo 2019でのセッション『3つの「Re」〜ソフトウェアの信頼性を高めるためにぼくたちができること〜』 をベースに、発表時間が少し長くなったので各要素の解説を丁寧にしつつ、全体の流れを整理しています。 また、エンジニアに特化した部分をはがすことも意識しています。チームで仕事をするのはエンジニアに限ったことではないですし、昨年末からOpsチームのスクラムマスターをやっていることも影響しています。ともすると「仕事 = コードを書く」という意識に傾きがちな自分への

ウィスキー、シガー、パイプをこよなく愛する大栗です。 先日、産業技術大学院大学で開催されているInfoTalkに参加して、チャットワークのCTOである山本さんの話を伺ったのでレポートします。 ChatWork、再実装の決断と裏側 チャットワークについて CharWork社について 日本は東京、大阪にオフィスがあり、アメリカのロサンゼルスにもオフィスがあります。 アメリカへCEOの山本さん（CTO山本さんのお兄さんです）が移住されています。 チャットワークとは チャットワークとはクラウド型ビジネスチャットツール。 導入企業は7万7千社を突破している！ チャットワークの規模 2015年8月の規模は以下のとおりです。 チャットワークの開発体制 CTOの元にWeb開発、基板開発部、アプリケーション開発部、CTO室という体制になっています。 チャットワークの歴史 2011年にリリースしてから3年・・

自分がプログラムを書き始めた頃、どんな環境で他のプログラマーが仕事をしているのか分からなかったのですが、昼休みのWebサーフィン中に以下の記事を見つけました。 新入学生/新社会人応援企画: 第3回 あるWebプログラマーの作業環境――豪傑の三種の神器 はてなの伊藤直也さんが新人プログラマー向けに自身の環境を紹介している内容ですごく参考になりました。 そこで紹介しているソフトウェアは次の三つでした。 Emacs Zsh Screen それぞれ使いこなすようになるには大変でしたが、馴れてからはこれらのソフトウェアにものすごく助けられています(まだ使いこなせていない機能も沢山あります)。 この記事は2007年に書かれていて今はインストール方法やパッケージ管理など少し状況が変わっているので、そのあたりをここで書いていこうかと思います（インストール方法はMac環境のみ書いています、事前にHomebr

プライベートサブネットの特徴 プライベート（プロテクト）サブネットは、NATインスタンスを介さなければインターネットと通信が出来ません。これは不正ログインなどから守るという点では大きなメリットですが、運用を行う上ではデメリットを抱えます。セキュリティ面と運用面のバランスを取る必要があります。 この時、インスタンスからインターネットへの外向きの通信と、SSHログインなどインターネットからの内向きの通信になります。 インターネットへの外向き通信とNATインスタンス インターネットとの通信を一切必要としない場合を除き、プライベートサブネットではNATインスタンスが必要となります。NATインスタンスはmicroインスタンスで十分です。しかし、NATインスタンスを起動していればそれだけ費用が増え、構成が複雑になります。 また、yumやgemといったパッケージインストーラはインターネット通信が前提です

皆様、こんばんは清田です。 最近、勉強会等で耳にするようになってきたsketch3をプロジェクト内使用してみる機会があったのでご紹介します。 iOSエンジニア・UI/UXデザイナー勉強会のセッションでも紹介されたり、いろいろな企業でも採用され始めているとのことです。 実際 sketch3 の存在を知ってはいたのですが、実際に案件内で使用してみて結構いい感じでした！ sketch3とは sketch3公式サイト sketch3はオランダののアムステルダムのBohemian Coding社が開発しているとのこと 現在はMac専用のツールみたいです、Window版をリリースしなさそうな予感。。。 価格は8月29日現在で¥7,800円で、App Storeから購入ができます。 たまに半額セールをしている時があるみたいなので、そのタイミングが狙いめですね。 また無料で14日間使えるのフリートライアル

先日、日本Javaユーザグループ（JJUG）主催のJJUG CCC 2013 Fallで、「ユニットテスト改善ガイド」というタイトルで登壇してきました。自分の経験を元に、ユニットテストをチームや組織へ導入する時に起こりえる問題とその解決のヒントに関するセッションです。本エントリーではそのセッションの内容を再構成して公開します。 はじめに 近年のシステム開発では、ユニットテストや継続的インテグレーション（以下、CI）の導入は必要不可欠と考えられています。とはいえ、どんな組織（チーム）でも簡単に導入できているわけではありません。特に、大きな組織や古くからの慣習を残している組織では導入したくとも中々進まないと感じているところが多いのではないでしょうか？。 私は、これまでに多くの開発現場でユニットテストやCIの導入について推進してきました。成功したケースもあれば失敗したケースもあります。そして、失

渡辺です。さる方面からテスト系のエントリーがまだか…と催促されたので、ユニットテストについて少し考えてみたいと思います。 最近、TwitterのTLをチェックしていると、JUnitを利用しているにも関わらず違和感のあるTweetや、原因をJUnitにして本来解決すべき問題から目をそらしているようなTweetを多く見かけます。そこで、JUnitをによるユニットテストに関するありがちな勘違いをまとめてみました。 なお、JUnitの部分は、RSpecでもNUnitでも適当に置き換えて読んでも構いません。 1.JUnitを使うことが目的という勘違い JUnitを利用すること自体を目的にしたところで何も得る事はありません。 ありがちな話ですが、「納品物としてJUnitのテストコード（または実行結果）を求められている」ことが理由でJUnitを利用しているならば、それは足かせでしかない可能性があります。