2017-12-04

IntelliJ IDEAハンズオンセミナーに参加してきました!

はじめに

こんにちは。 今年も JetBrains Advent Calendarに参加させていただきました。
日付ギリギリですが、12/3の枠で投稿させていただきます。
とか言いつつ、表題の通りIntelliJ IDEAハンズオンセミナーの簡単なレポートになります。
ぶっちゃけ、控えめに言って、とても良いセミナーでした...。
昨年の記事でなんとなくお分かりかもしれませんが、わたしはあまりショートカットは使っていなかったので、このセミナーを受けて『えー、こんなに色々できるんですね!!』と(態度は控えめですが)衝撃を受けたのでございます。

セミナーの流れ

今回は、サムライズム様本社での受講となりました。参加者はわたし含めて6名。
その中には、初めてお目にかかった寺田さん(!)がいらっしゃいました。(寺田さんからは差し入れのシュークリームをいただきました、ありがとうございました!!)
内容としては、長時間ではなく2時間程度で、こんな流れでした。
  • 講師&サムライズム様について
  • JetBrains社について
  • ライセンスについて
  • JetBrainsファミリー(製品)について
  • チーム向け製品(サーバ製品)について
  • IntelliJ IDEAでのハンズオン
  • まとめ
以下、上記のトピックについていくつかをピックアップして、簡単なレポとさせていただきます。


サムライズム様について

講師のサムライズム様代表の山本さまは、デブサミを通して、過去にも何回かお話を伺う機会をいただいております。
(勝手なスケッチ付きのレポはこちらです)
現在はJetBrains社製品以外にも、Atlassian社のツール、GitHubその他の開発者向けのツールも扱われているそうです。どれも何らかの形でお世話になっていますね...。

チーム向け製品について

ハンズオンで実際にIDEAを利用する前に、JetBrains社の製品、とくにチーム向け製品]についてご紹介をいただいたのですが、このあたりあまり知らなかったので、特に「聞いて良かった!」と思えた内容の一つでした。
実際に画面を見てご紹介いただいたのは、TeamCity, Upsource, YouTrackです。
TeamCityはビルド・デプロイに使うツールで、Jenkinsに近いもの。
YouTrackは課題管理ツールの位置付けで、JetBrains製品への要望やバグレポートにも使われています。
Upsourceはコードレビュー用のツールです。
今のわたしの現場では、CIはWercker, CircleCI / 課題管理はJIRAもしくはGitHubのissue / コードレビューはGitHubのプルリクエスト上で行なっているので、実のところ『このへんは縁がなさそう...』と思っていたのですが、とくにUpsourceにはとても惹かれるところがありました。
特徴的なところは、以下の通り。
  • リポジトリはGitHub, コードレビューだけUpsourceという使い方ができる
  • Upsource側でコードにコメントをつけたりコード中の他のメソッドをクリックすると、利用されている側のメソッドのコードポップアップされる
    • ありがちな、「ここで使われてるメソッドはどんなコードだっけ...」と言って別画面を開いて探して行く作業をしなくても、ポップアップで表示してくれる!
  • UpsourceとIntelliJはプラグインで連携されて、Upsource上のコメントがIDE側でチェックできる
  • レビューを受ける側は、わざわざSlack通知を見てブラウザを開いて...といったことをしなくても、IDEの中だけでレビュー内容の確認や返答、修正ができる
  • Upsourceでのコメントは、GitHub側にも連携・反映される


特に、引用しているメソッドをたどらないといけない場合の手間が省ける、というのが一番魅力的でした。
Javaに特化しているのか、それとも他の言語でも同じように辿れるのか、ちょっと試したくなりました。
リポジトリブラウザとしての機能もとても優れていて、Web上でIntelliJの検索機能を利用しているような感覚に近い気がしました。
(オープンソースのプロジェクトで使えるというのが、とてもよさそげです!)
製品自体は少人数でなら無償、warファイルの形式で配布ですぐに起動して試せるそうなので、だいぶ心が惹かれました。

IntelliJ IDEAでのハンズオン

Java初心者 or 未経験でも大丈夫そう!

『Upsourceすごいー!』とワクワクしたところで30分ほど経過し、IntelliJを使っての実際のハンズオンになりました。
受講者にはA4の「代表的なショートカット一覧」が配布され、このショートカットを使いつつ、Javaでfizzbuzzの簡単なプログラムを書いていきましょう、という流れでした。
『Javaで...』ということで、かなりの不安を覚えたわたし。
まあ、IntelliJを使う方なら、Javaのお仕事の方が多いでしょうから、もっともな言語だとは思います。
ただ、わたしは10数年前に仕事でへなちょこながら書いたことがあったのですが、それ以来全く書いていない!
(今は他の言語でお仕事してますが、それでも満足に書けたもんでもない...)
「大丈夫か?生きて帰れるのか??前に出てきて黒板に書いて見なさい!とか言われて、恥ずかしい思いをしちゃうんだろうか??」とか慌ててしまったのですが、そこはさすが山本さん&IntelliJ。
おそらくJavaを触ったことがない方でも大丈夫な進行となりました。
むしろ、「IntelliJがあれば、書けるようになっちゃうんじゃないかしら??」とすら思えてきたのでした...。

簡単なプロジェクトから

まずはプロジェクト作成から開始。
EclipseやNetBeansも同じようなものかと思いますが、最初におすすめのキーマップの設定、JDKの設定、プラグインの追加を行いました。
このあたりは、『IntelliJ IDEAハンズオン』の書籍とも同じですが、実際に山本さんがショートカットを使って流れるように操作して行く様子を見ると、すごいなと思いますね^^;
同じことをほぼマウスでしかやれていなかったので...。

JavaのプロジェクトでもHTML

プロジェクトができたので、じゃあJavaのコード...?
と、その前に、プロジェクトのツリーやエディタ画面、メニュー利用に慣れるために、まずはHTMLページの作成とライブプレビュー機能を使ってのチェックを行う流れとなりました。
こちらはWebStormでも、その他のIDEシリーズでも共通です。
スケッチ付きのレポでも、HTML編集とライブプレビューのデモは見せていただいておりましたが、今回は手元のショートカット一覧を見ながら、わたしも実際にコーディング。
特にEmmetを使って、CSSセレクタの形式で指定したHTMLを、一発で置換してくれることにも驚き!
IntelliJの機能というよりは、Emmetのサポートが付いているというのが正解ですが、こういうイベントのタイミングで便利な機能を学習できるというのも良いですね...。
おかげさまでChromeでのライブプレビューも問題なく進みました。

テンプレート炸裂! 知らなくても大丈夫!

さて、いよいよJavaのコードを書く番に。
わたしのうしろには、Javaエバンジェリストのてらださんがいらっしゃいます...。

『うわぁフルスクラッチ無理無理...』とこわばっておりましたが、そこは空気を読んでくださったのか、ほとんど「ライブテンプレート」の機能を使って穴埋めしていくだけで fizzbuzz のプログラムを書くことができました。

IDEってすごい...と思った瞬間です。


実際のところは、mainの関数を記述する、変数を宣言する、1〜100までのfor文を作る、if文で場合分けする、出力するといったあたりを書ければいいのですが、ほとんどがライブテンプレードを使って書くことができました。

たとえば、こんな感じ。
  • psvn + tab で、public static void main
  • sout + tab で System.out.println 
  • fori + tab で for (int i = 0; i < ; i++)  

さらに、テンプレートで差し込むコードでは、変数名や値を変更することができます。
実際に設定画面で確認すると、かなりたくさんのテンプレートがありますし、わたしのよく使うDB向けに、SQLのテンプレートもありました...。
(rubyプラグインを入れていれば、ruby用のテンプレートも追加されます)

#『 begin; commit; // rollback; 』のブロックもテンプレート化しておくと良いかもしれない...。

デバッグもしてみよう!

拍子抜けするくらいサックリとJavaのコードが出来上がってしまったので、次は実行&デバッグです。
こちらもショートカットで特に問題なく実行と出力を確認できました。

ショートカットは別として、デバッグはRubyのコードを書く際によく使っていたのですが、今回初めて知ったのが、ブレークポイントも条件指定した時だけブレークできたり、Chrononの機能が使える、ということでした。

Chrononは、デバッグの際の変数の移り変わりを記録しておき、ステップインで前に進むだけではなく、擬似的に前に戻って処理を確認んできるという機能です。
これも実際にハンズオンで動かすことができて非常に良かったことの1つでした。

バージョン管理機能のここがいい!

ひきつづき、バージョン管理についても、あまり使っていなかったのでとても参考になったものの1つです。
ふだんはなんだか敷居が高くて、ついついコミットやpushといった作業はSourcetreeを別に立ち上げて利用しておりました...。

ですが、このVCSの機能もショートカットをガンガン使えること、コンフリクトした際にGUIで競合を解決しやすい点を目の当たりにすると、『これは使わねば!』という気になりました。
コミットログもちゃんと日本語も通りますし^^;

Kotlinも書いてみよう!

ここまででも十分お腹いっぱいでしたが、Kotlinについてもご紹介いただきました。
シンプルな例ではありますが、Kotlinで書いたクラスをJava側から利用したり、Kotlinの文法がわからなくてもIntelliJ側で変換してくれる、といった内容で各自機能を試すことができました。





まとめとか感想とか

以上、かいつまんでのハンズオントレーニングについて書かせていただきました。
なんだかんだでJavaをすっかり忘れていたわたしでも、今回の参加で『IntelliJがあれば、もしかしてJava書けるようになっちゃうんじゃないかしら??』とすら思えてきました。

それほど、ショートカット、補完、ビルド・デバッグをいい感じにしてくれるツールだというのを実感した次第です。
古式ゆかしくターミナルを起動して、「javac xxxx.java, java xxxx」と言った感じでコンパイルして実行といったことは、一度も出てきませんでした。
ですから、もし機会がありましたら、Javaを使っていない場合でもハンズオンへの参加はおすすめです!

また、企業への出張トレーニングも可能とのことでした。

IntelliJ IDEAハンズオン


IntelliJ、ここ3年くらい使っていながら、知らなくて損(?)していたことが多く、お恥ずかしい限りではあります。

駆け足でのハンズオンでしたが、こうしてレポート用の記事を書くために、ハンズオンでやったことを書籍とメモを見ながら復習...となりましたし、あらためて色々できるんだなあと感じた次第です。

来年はもう少し効率Up、他の言語もうまく学んでいけるようにしたいです!

2017-11-21

Rails Girls Tokyo 8th 参加ログ

10/7に、Rails Girls Tokyo 8thに参加してきました。

ただし、今回は参加と言ってもGirl (ワークショップの受講者)でもなく、コーチでもなく、スタッフの一人として参加しています。Railsは間接的なものを含めれば意外とお付き合いは長いのですが、ちゃんとやりだしたのは割と最近なだけに、コーチもまず無理^^;

そのため、どんなことをするのか、スポンサーとしてはどんな協力ができるのかを拝見したくて参加いたしました。
私自身は実質たくさんのことはできず、少しのお手伝いではありましたが、いろいろと学びがあったので、メモ絵とともに簡単に記録に残しておきます。

スタッフの作業


前職でも、数自体は一桁ではありますが、会議室を夕方以降や土日にIT系の勉強会用に貸し出しすることがあり、その際のホスト側スタッフとして参加者をお迎えすることが何回かありました。
(この記事を書いている時点で、私は長かった新卒からの職場を辞めて、転職しています。過去記事に、前職で開催したイベントのお手伝いなんかも少し触れています)

今回はクックパッドさまにお邪魔する形でしたが、『どんな風にイベントを進めるのかとか?、お客様をアテンドするのはどういう方法か?、50〜60人くらいのIT系の方をお招きする場合は設備大丈夫かな?』とか、そんなあたりを観察していました。

スタッフでの参加なので、トレーニングを受ける「Girl」ではなかったこともあり、著名なコーチ陣のお話をじっくり伺うことはできませんでしたが、それでもケータリングやグッズ、進行などはとても参考になりました。

イベントの中でとても良かったのが、スタッフの方が作ってくださった、『インスタ風フレーム』と、ハッシュタグのプレート。
これ、イベントの小道具としても、すごくイイですね!
参加者みんなで楽しめるので、参加者の方が顔出しOKであれば使うのはとても良さそうな気がしました。




大活躍の小道具:ハッシュタグ

オーガナイザー @emorimaさんのPC / 過去のRails Girlsのステッカーが!!

Girl (受講者)はどんな方たち?


必ずしもIT系にお勤めの方ばかりではないです。それから、ちょっと前に話題になりましたが、若い未婚の女性ばかりでもないです。
  • カスタマーサポートをされている女性
    • 『隣で毎日「デプロイ」っていう言葉が聞こえてバタバタしてるんですが、どんなことしてるか知りたくて...』とのことでした。

  • 児童心理学か教育系を専攻していたが子育てに専念中、現在第二子妊娠中の方
    • 子供が大きくなったらまたお仕事をしたい、技術を持ちたい
  • IT系なんだけれどバックオフィス系で仕事をされてて、お子さんが大学生の
  • Scratchをやっていたんだけど、最近それで物足りなくなってきた中学生
  • 学校で給食スタッフをしている方
  • 人事系で仕事をしている方
  • Webデザインをメインにされている方
  • 文系の大学生の方
  • 新聞記者の方(保育園問題、プログラミング教育を追いかけている方)

注目は中学生でしょうか.....!お母様が付き添いでいらっしゃっていました。

募集に集まった人数は60名ほどで、抽選の結果の20名が今回のGirlとして参加されました。

スポンサーになると何ができる? /  協賛金はどう使われている?


もし職場がスポンサーとして支援していただけるなら、個人的には嬉しいなあ...と思っていましたが、実際どのように協力に充てられるのか把握しておきたかったので、この視点からも様子を伺いました。

もちろん、会場提供するのも立派なスポンサーとしての役割になります。
前職で勉強会用に会議室を貸し出ししてたのも、「自分たちの会社のプレゼンスを高めることにもつながるよね!」という有志の想いからでした。(さらに、自分の興味ある勉強会を引き込んじゃいたい、という各自の思惑もありましたが)

クックパッドさまの会場。
学校の図書館で見かけた郷土料理のお料理の本が!!
スポンサーは一口2万円からとのことで、実際それがどう使われているのかな?みたいなところは以下の通りです。
  • オーガナイザー、コーチ、スタッフのTシャツ代(ただし、TMIXさまがスポンサーになられていて、そこからTシャツが提供されていました)
  • 参加者全員のお弁当、飲み物代
  • ワークショップ終了後の懇親会のケータリング代
  • 記念のお土産のお菓子代(今回はクッキー)
  • ワークショップ用の備品(ペン、スケッチブック、名札など)
  • 学生さんを選んで RubyKaigi参加の支援をする 
    • 数名を選んで、交通費とか宿泊代の支援
他にもサイトの運営やイベントの装飾などなどに利用されていると思います。

お土産のアイシングクッキー、可愛すぎ....
お弁当。おこわもおかずも数種類あってとても美味しかった!!

一方、スポンサーの特典としては、こんなあたりです。
  • 各自の会社紹介用のシールやパンフレットを一緒に置いてもらえる
  • ライトニングトークで会社紹介ができる
  • 公式サイトに企業ロゴと紹介文を載せてもらえる

この点ですが、公式サイトに「スポンサー」としてロゴを載せてもらえたり、TwitterなどのSNSで紹介されるのは、エンジニア採用にとってはとても良いPRになると思っております^^;

それから、実はコーチやスタッフはRuby (Rails) を始めとした名のある方が揃われるので、これからRailsを極めていこうとするGirls (受講者)の方だけでなく、コーチ同士、ちょっとした第一線のエンジニアの交流の場になっている印象もありました。

実際に、スポンサー企業では人事の方がいらしてお話をされてましたし、コーチ兼各自の会社のLTをされる皆さんも、自社サービスのPR+Join US!(一緒に働きませんか?)というお話も見受けられました。



#ワークショップ後のLTにはコミッタの松田さんがいらっしゃってたり、ジョーカーさんがコーチしてたりで、本当に豪華なメンバーが多かったです!



参加しての感想・まとめ


上記の内容、メモ的なものは、職場に持ち帰って一応共有いたしました。
スポンサーとしてどんなことができるかがうまく伝わって、今後のRails Girlsへの支援につながればいいなあと思っております。

もちろん、個人での参加でも学ぶところは非常に多く、特にお子さんをお持ちの方やジョブチェンジを考えている方の参加の背景を伺うことができたのが、とても大きかったと思います。

上記のメモに書きましたが、チュートリアルを実施する上での環境構築に関しても、Mac / Windows両方の場合があるのでその辺りを考慮したり、もしくは開発環境自体クラウド(今回はCloud9)を使うといった工夫があったりで、どんどん取り組みやすくなっているのも肌で感じたりしました。


今回いただいたステッカー。
1枚だけのお母さんOctcatを遠慮なくいただいてしまいました、すみません.....

今回参加して、ふた回りくらい若い世代の方の学ぶ姿を拝見できたのは、お母さんとしてもとても刺激になりました。
たぶん、ここで参加された方、ここから育つ方々が、私の子ども世代が大きくなったときに、先輩として活躍されているんだろうなと思うと、ちょっとばかり胸も熱くなったりするのでした。

最後に


今回参加したきっかけの1つ、たぶん一番わたしにとって大事なことを載せておきます。



みなさまほんとうにありがとうございました!

2017-11-13

『いちばんやさしいPythonの教本』を読みました。


最近は自分用の本を買うよりも、『それなら子どもの本を...』と思ってしまい、ついつい書籍を買いそびれています。
以前よりもインターネットで情報が参照できるということもあって、ますますそういう感じになってしまっております...。(お恥ずかしい)

そんな中、久しぶりに書籍を買ってみました。
今回はこちら、『いちばんやさしいPythonの教本』です。



実は、このブログの過去記事に少し書いてあるのですが、わたしはPloneというpython製のCMSを一時期利用、運用しておりました。
初めて使ったのは、もう10年以上前でしょうか...。
たしかWindowsサーバにWindows 32bit版のpythonのインストーラーを使ってセットアップしたような気がします。

個人的には好きなCMSだったのですが、プログラムがメインではなく情報システム部門でその他のシステムと並行してお守りをしている感じだったので、pythonのコードはよくわからず、時々出てくるエラーに頭を悩ませていたりしました....。

扱っているデータベースがちょっと特殊でRDBのようにSQLでデータを確認できるタイプではなかったのも起因していて、なんだかんだで運用しつつpythonへの苦手意識は無くなりませんでした...。


さて、今はメインの業務ではpythonを使っていないのですが、今年の秋に本屋さんで目にして、『もしかしたら恐怖心が和らぐかも...』と思って購入することにしました。

もちろん、その他にもpythonの本がここ最近ぐっと増えた気がしていますし、「もしかしたら自分の子どもたちは学校でpython使ったりするかもしれない」と思ったのも理由です。

rubyはなんとか現在取り組んでいるので、お母さん的にはpythonもちょっとは説明できるようにしておきたいという気持ちが動いたのでした。

まず読んでみて、最初はインストールのところからの丁寧な解説。
WindowsやUnix系のコマンドを知らなくても、ターミナルの使い方やディレクトリの操作といったシェルの操作、OSについての基礎など、プログラムを動かすに当たって必要な前提知識に関しても説明があります。

このあたりはさすがにさーっと読み進めていましたが、実はpython3系はあんまり明確に意識して使ったこともなかったり、モジュールのお作法がこうだったというのを知らなかったりで、『ううむ、10年前にこれがあったら...』という思いで後半読んでおりました。

実際に簡単なプログラムを作ってみて、その上でvenvも今回初めて使ったのですが、「なるほどー」という感じで env/ の下を眺めてみたりしました。

これからまた少しずつ学び直そうと思います!


(※Ploneを使っていた際に、著者のおひとりの鈴木さんの記事を非常に良く参考にさせていただいておりましたので、間接的に実は大変お世話になっています...。ありがとうございました...。)

* * *
追記:面白かったところ / 改めて知ったところ:

  • python2とpython3の違い、サポートに関する情報が載っていました
    • python2系は2020年...
  • Hello, world! ではなくbotを作ってみようというのが面白いです!
  • moduleのインポート、利用するメソッドの指定、namespace、ファイルの配置場所について
  • venv初めて試してみました
    • env/ の下に切り替え用のスクリプトが配置される点とか、実際にやってみたら「ほー」という感じ
  • Webアプリケーションのフレームワーク、とくにBottleは知らなかった!
  • コミュニティ活動に参加の呼びかけが巻末に載っている点
    • 女性向けのコミュニティについても紹介されていた
  • Gitやバージョン管理については触れられていませんでした
    • 意外に新鮮な気がしました!




2017-10-14

OWT2017JP / OWASP World Tour 2017 in Tokyo に参加してきました!

とても久しぶりのBlog投稿になります...。

9/30 (土) に、OWASP World Tour 2017 in Tokyo に参加してきました。

こちらのイベントは、たまたま職場の同僚に教えていただきました。
参加可能な人数が100人以上での募集ということと、ちょうど社内でセキュリティに関するちょっとした勉強会の担当をしていたので、家族に協力を得て参加申し込みをいたしました。

実は、申込み時点では枠がいっぱいだったのですが、あとから東工大以外にサテライト会場が複数提供となり、幸いにもサイボウズ様のサテライト会場にてお話しを伺うことができました。

* * * 

 さて、このイベントに参加...と言いつつ、実はOWASP、OWASP Japanがいったいどんな活動をしているのか、全く知りませんでした。(大変お恥ずかしい...)
同僚経由で「アプリケーションセキュリティに関するトレーニング」を受けることができるということだけが目に留まっての申込みでした。

なんだかんだで当日になりまして、サイボウズ様本社のある日本橋へ到着。

各会場の様子や、スピーカーの皆様の詳細な資料は、こちらのOWASP Japanのブログをご覧ください。

実際にイベントが始まり、ここ2、3年はイベント中は実況っぽいTweetをするタイプだったのですが、お話が進むにつれて「メモすることに集中しよう!」という路線に切り替えました。それくらいじっくり聴きたいお話だと思い直したわけです...。

実はセキュリティに関しては過去仕事でご縁があったのですが、部署が変わったりで離れておりまして、セキュリティ関連ではまずはJPCERTやIPAという認識はあったのですが、OWASPのことは知りませんでした。

今回、オープニングと最初の上野さまのお話で、OWASPがどういうことを行なっている組織なのか、ということを知りました。

以下は日本の公式ブログからの引用です。

OWASPとは、Webをはじめとするソフトウェアのセキュリティ環境の現状、またセキュアなソフトウェア開発を促進する技術・プロセスに関する情報共有と普及啓発を目的としたプロフェッショナルの集まる、オープンソース・ソフトウェアコミュニティです。
日本での活動開始は2011年。
このブログを書いているのは、イベントから二週間以上経過した時点です。
イベントのことを振り返ったり、ブログや資料を拝見しながら、書き起こしているところです。

OWASP Japanの活動の資料は、https://speakerdeck.com/owaspjapan (SpeakerDeck) にたくさん公開されています。
また、OWASP Night といった、Webセキュリティに関心がある方向けの勉強会を定期的に開催されているそうです。
以下も、公式サイトからの引用です。

OWASP Japanは、OWASP Night/Meetingとして、セミナーや持ち込みのライトニングトークの形で行われる、Webセキュリティに関心のある方が集う、楽しくカジュアルな勉強会を開催しています。スキル、役職、業種、国籍、性別、年齢関係なく、遠慮なくお越しください。およそ、三ヶ月に一度の頻度で、このミーティングを開催しています。

あまりまとまっていませんが、以下、9/30のイベントに関して、セッション順のメモを載せておきます。もし目にとめてくだって、何かの参考になれば幸いです。


 OWASPの歩き方 / 上野さん(OWASP Japan Chapter Leader) のセッションからのメモ

『岡田さん上野さんのご挨拶 & オープニングセッションから。非常にたくさんのプロジェクトが動いていますが、非営利。だからこそボランティアの力が必要で、教育啓蒙に加えOWASPのプレゼンスをアピールする機会は大切』



ここではじめて詳しくOWASPを知りました...。(ごめんなさい!)

そして、OWASP ZAPに代表されるツールは活動の一部であり、セキュリティ啓蒙やセキュアコーディングのためのガイドラインやサンプルコード、アセスメントのためのドキュメントの公開なども主な活動であることを知りました。




OWASP Top10を用いた脆弱性対応 / 安藤さま(株式会社オージス総研)のセッションからのメモ

『午前中印象に残ったところ、ちょっとだけ抜き出し。(ほかにも色々とおお!な所あります) ヤギさんも試したい。』

安藤様のセッションでは、OWASP Top10の具体的な紹介と、脆弱性を突いた事例として、SQL Injectionのデモを実施されていました。

また、セキュアコーディングについては、以下ような点をお話されていました。
  • WAF (Web Application Firewall) だけでは防ぎ切れない
  • 脆弱性の多くはプログラミングエラー、実装の工程で入り込んでしまったもの
  • 実装段階でも脆弱性検査を取り込んでいくのが大事
  • 開発者のスキルに依存するコードレビューや目視のチェックだけでは限界がある
  • 静的解析ツール(例:Synopsys社のCovert) やOWASP ZAPも使っていこう
  • 開発者が個々にセキュリティ対策を実施するだけでなく、全体としてレベルUPが大事
  • コストもかかるが損失が発生した場合の影響も考え、全体のトレードオフで、何をどれだけ守るのかを明確にすること



最小権限の具体的な実現方法 / 長山さん(株式会社神戸デジタル・ラボ)のセッションからのメモ

『午後2つめ長山様。色々あるけど大事な点。権限は守りたい情報、脅威になる情報が何かといった点から考えてる。必要な時は期間も絞る。画面だけ制御してて実はデータが取れちゃうなんてことが無いように。 (裏メニュー注文の図はわたしの理解から書いてみた)』


お話の主題は、『最小限の権限管理』について。
まず初めに、『自分の情報は誰に見られても問題ないよといった、オープンマインドな人もいるけれど、「見られたくない人もいる」ということをも考えること』と仰っていました。たしかに...。

上記の図以外でも色々とメモさせていただきましたので、覚えている限りで添えておきます。

  • 権限については、ツールでは「脆弱性」を見つけにくい
  • リクエストに対するレスポンスが想定しているものと違っていても、それが正しいのか誤りなのかはツールでは分からない(上位権限の情報が混ざっていたりとか)
  • 脆弱性としては見つけにくいが故に、リリース後に一般ユーザが特権ユーザのみに提供されるべき情報が見えてしまうのが発覚することがある
こういった権限まわりの脆弱性(というか権限チェックの考慮漏れ)に対して、OWASPで提唱しているのは以下の点。

  • 全てのリクエストはアクセス制御のチェックを通るべき
  • デフォルトは拒否(Deny from All) で、必要なもののみ追加で許可していく方針
  • 最小限・最短期間での権限設定
  • アクセス制御はプログラムにハードコードしない
  • 信用できない外部データを使わない(exp. xxx?role=admin みたいなリクエストパラメータで権限を切り替えるような実装はしない)
さらに、権限で守りたいものは「画面」ではなく「データ」なので、「データ」を中心にアクセス権限を考えていくことが大切とおっしゃっていました。

実装に関しては、自前で作り込むのは大変で漏れがあったりするので、既存のフレームワークをうまく利用するほうが良いとのことでした。

また、実装後、権限設定が適切かどうかのテストに関しては、より仕様を理解しているのでアプリケーションの開発者がテストを書く方が良いとのことでした。

この点に関しては、テスト作成の工数やドキュメント作成(権限表作成)の工数がかかるので、うまくソースコードのコメントや命名規約を使って自動でドキュメントが生成できるようにすると良いですよ、ともおっしゃっていました。



開発者・運用担当者に向けた、OWASP ZAPを用いた脆弱性診断手法 / 亀田さん(OWASP ZAP Evangelist、SCSK株式会社)のセッションからのメモ

『午後の亀田さんのZAPのお話。一気に自動テストでなく、細かくデバッグ用途でも使えそう。プロ目線でどういう診断すればいいかのノウハウも詰まったツールなので、これから学習する方にもとてもいい教材。日本語化頑張ってます!


亀田さまはOWASP ZAPのエバンジェリストとして、時間いっぱいにその機能を紹介してくださいました。

セキュリティ診断のツールとしてでなく、開発者側にとってもプロキシで通信をキャプチャし、デバッグするためのツールとしても有効とおっしゃっていました。



OWASP BWAを用いた学生および職員向けトレーニング / 松浦さん(東京工業大学)のセッションからのメモ

『午後の東工大、松浦先生のOWASP BWAを使った学生、職員向け演習のお話。噺家さんみたいにお話が面白かったですし、BWAそのもの以外に、どんなふうに教え導いていくかという点が語られていたのも惹きつけられました。』


松浦さまのお話は、OWASP Broken Web Applicationを使ったセキュリティ演習について。
大学職員や学生も、講義する教官側も、環境構築やデモアプリの構築といった点に時間を作ことなく、本来やりたい作業に集中しつつ演習ができるようにとOWASP BWAを利用されているとのことでした。

とてもお話が面白くテンポも良く、しかも学生を「教え導く」流れも非常によく考えられており、このセッションに関するTweetでは、同様のつぶやきが多かったように思います。


開発プロジェクトの現状を把握するOWASP SAMMの活用 / 伊藤さん(サイボウズ株式会社)のセッションからのメモ

『午後5コマ目の伊藤さん、OWASP SAMMのお話。その場ではメモで精一杯だったので、家でスライドやサイト見て書き起こしてます。これから大きくなろうとしてる企業にも、IT統制ガバナンス取り組まないといけない際の評価基準、ルール決めに使えそう。』

伊藤さまは、OWASP SAMMについてお話されました。
OWASP SAMMは、「より成熟したセキュア開発を支援するためのドキュメント&成熟度を定量化・可視化するためのツール」で、OWASPのフラッグシップのプロジェクトの1つです。

定量化・可視化については、地道にアプリケーション・サービスに関わるほぼ全てのロールの方々に地道にヒアリングを重ね、現状から3段階の数値評価に落とし込み、SAMMで定義した式に応じて成熟度を算出するというものでした。
このため、「まずはヒアリング計画が大事ですよ」とおっしゃっていたのが印象的でした。



クロージング:  シフトレフトへの道 / 岡田さん(OWASP Japan Chapter Leader)のセッションからのメモ

“ l joined World Tour 2017 Japan, and deeply impressed by these activities. So post my sketch to share and thank this valuable event. "



クロージングセッションは岡田さまから。
今回のOWASP Japanのトレーニングはどういう背景で実施されたのかといったところから、"SHIFT LEFT” という言葉に乗せて「次の工程に進む前にフィードバックや確認を挟むことの大切さ」をお話されていました。
さらに、各セッションのふりかえり、各サテライト会場の紹介を行なって下さいました。

とても想いの込もったお話が聞けて、本当に参加してよかったと感じました。

* * *

以上、あまり細かいテクニカルな内容までは書き留めたりできなかったのですが、少しでもイベントの雰囲気を掴んでいただけたり、参加者の皆様の振り返りにつながれば幸いです。

2015-02-16

Atlassianユーザ会 20150130 参加レポ

20150130 に、Atlassianユーザグループのイベントに参加してきました。わたしとしては、2回目の参加になります。
実は、今回は自社のConfluenceメンテナンスの後に、そのままアタフタと参加で疲れ気味だったので、メモやTweetはできず、座って聞く側中心になってしまいました。
レポート内容は少なめで申し訳ないですが、記録としてアップします...。

2014-11-08

Atlassianユーザ会 20141029 レポート

20141029 に、Atlassianユーザグループのイベントに参加してきました。

平日夜間はなかなか時間が取れず、この手の外部の勉強会は年1回か2回なんですが、今回家人の協力を得て、はじめての参加となりました。メイントピックはConfluence。しかも、数年単位で会社全体で運用しているYahooさまの事例ということで、まさに自分の欲している情報です。

大変有意義なイベントでしたので、ひさしぶりにBlogに残します。

2014-02-19

デブサミ2014 14-D-4 / 長沢さんのセッションを聞いてきました!

デブサミ歴数年、過去にも長沢さんのお話は聞く機会がありましたが、長沢さんのセッションのBlogを書くのは始めてになります。

セッション資料

お話を伺った理由


デブサミに限らず、色々なところで長沢さんのスライドや講演を目にする機会がありまして、その『エバンジェリスト』としての姿勢にはとっても引きつけられるようになり、まあ、いわゆる『ファン』になってしまいました。(追っかけまではしていませんが)

それから、呟きや講演に出てくる仮面ライダーネタも、子持ちの奥様には共感したり笑えたりするものが多く、これもポイントが高いのでした。

さて、昨年末。そんな長沢さんが、Microsoftから離れるという、衝撃の情報が流れました。
えええー?フリーになるんですか?世界を渡り歩いちゃうんですか??』と思ったものの、年明けすぐに、さらに衝撃が。
Atlassianに入社とのことで、もう、ホントにびっくりしました!

情シス部門のわたしは、デブサミに通っていなければ多分知らなかった会社です。
しかし、デブサミやチケットシステム関連の話題、JenkinsのWikiなどを通し、そのユニークさや製品は知っておりましたので、これはインパクトが大きかったです。

コーヒースポンサー席をGET!


当日は雪になってしまい、わたしも仕事が詰んであったのでだいぶ迷ったのですが、やっぱりライブでの講演は聞きたい!...ということで、午後から雅叙園へ。

もちろんお席はいっぱいになっていましたが、おかげさまでコーヒースポンサー席で落ち着いてお話を伺うことができました。(ちょっと遅かったら、スポンサー席も埋まってたかもしれません)

エバンジェリスト、登壇!


準備中の長沢さん。指に黒曜石が装着されているのも、来場者は見逃していませんw

デブサミ恒例の、学校のチャイムのような音が鳴り響き、いよいよエバンジェリスト登壇となりました。

その際、なにやら『ソフトウェア開発ツール』『プロジェクト管理』『アジャイル開発』と書かれたボードを手にしていたのですが、それをポイッと捨ててしまわれました(^^;

特定のツールのお話をするのではなく『開発の現場の環境』についてのお話ということで、ボードを投げ捨てたようです。奇抜な格好はされてませんが、インパクト大!
ライブならではの楽しさですね。



実は、『キャー!ながさわさーん!』と書いた紙を隠し持っていたのですが、それを掲げるのは恥ずかしくってできませんでした…。

以下、お話の内容


では、真面目にお話の内容を記録してみます。(長沢さんの意図していることと外れていたら、スミマセン!)割とTweetしていたので、そちらのまとめ的な内容になります。

序盤 / お話の内容、アトラシアンについて


まずは安定の仮面ライダーの話題からw
『平成ライダー対昭和ライダー 仮面ライダー大戦 feat.スーパー戦隊』の公開前のファンの投票結果で、上映内容が決定するという、一般ユーザ参加型の企画を紹介。(公開は3月29日です!みなさん投票してみましょう!)

このライダーの例は、『今まで映画のストーリー作りに関わってこれなかったユーザも、ソフトウェアの力で参加できるようになっている』ということの例として取り上げたそうです。(※このアイスブレイクは、スライドには含まれていません。ファンサービス!)

そして、ユーザを巻き込み、あらたなビジネスへのチャレンジを可能にするのがソフトウェアの力、そしてそこで一番活躍できるのが開発者である、と述べられていました。

続いて、アトラシアン日本オフィスについてのお話です。
こちらも、『社員にとって、リラックスしつつ生産性を高めるために配慮した』故のオフィスだということでした。
Atlassian自体が、環境を大事にしている会社なんですね

本題1.  開発現場の資質がものすごく問われる時代


では、本題。
まずは開発だけでなく、ビジネスを生むための環境そのものが複雑化し、辛い時代になっているよ、というお話。

  • 価値を迅速に提供し続けることが求められる。ある意味つらい時代。
  • 開発現場だけが気持ちよくてもだめ。ユーザさんにもそう思ってもらいたい。
  • コード書く段階で、ユーザさんのことをつねに意識することが必要。
  • 自分たちの作ったものが、ちゃんと届いているか?ユーザの望むものなのか?フィードバックを迅速に受けて、開発に取り込むことができるのか?を、つねに把握する必要がある。
  • 開発現場の資質がものすごく問われる時代。

本題2. バランスが大事


開発の手法で取り上げられている、プロセスやツール。でも、それ単体であったり、偏っていたりしてはダメ、という’お話。
  • 継続的デリバリーの重要性。分かりやすい言葉で言うと、心技体。
  • 心技体のバランスが大事。あるプラクティスをやりたい、アジャイルをやりたい、ツールをやりたいから、ではダメ。
  • これからは、このバランスを意識することが大事。
  • 一人スーパーマンがいればいい、ではなくて現場がスーパーになることが大事。
  • 現場がうまく行けば、BMLのサイクルがうまくまわるはず。
  • 実際に、デブサミでお話をしているような会社は、それが上手くいっているからこそ。
  • 今の時代は、いろんなデバイスを通じた形で、末端のユーザにサービスを届け、ビジネスに繋げる必要がある。
  • それゆえ、開発を取り巻く状況は、複雑で難しくなっている。

本題3. 実測駆動型の開発を


型にはまったビジネスモデルが見通せないからこそ、実測駆動型の開発を目指しましょう、というお話。


  • 建築は非常に成熟しているので、最初にきちんと設計し、作っていくことが可能。
  • ソフトウェアはどう?ビジネスモデルやテクノロジーが変わっているので、最初にきちんと定義したものを当てはめるのは難しくなっている。
  • パッケージだけでは対応できないケースが増えている。
  • 実測駆動な開発、やりながら状況を見て、その時にベストなものを選択しながら進めて行くやり方は、今のソフトウェア開発に合っている。
  • ソフトウェア開発は試行錯誤しながらより良いものを作る、というスタイルのほうが合っている。
  • 複雑さが増している故に、知らない技術に取り組まないといけなくなってくる。
  • 時間をかけてちゃだめ。小さいながらも、ビジネスにインパクトのあるものをいち早く作るのが大事。
  • ソフトウェアを作るのではなく、『ビジネスを作る』と考えて作っていこう。

本題4.   現場をつなぎ、最高の能力を発揮できる環境を


実測しつつ、各自のパフォーマンスを最高にするために、環境を整えることが大事、というお話。

  • ユーザにサービスを届け、ビジネスを作るサイクルを維持するためには、現場間の分断があってはダメ。
  • 他部署だから関係ない、ではダメ。同じビジョンに向かって、しっかりとつながっていないといけない。
  • 統制ではなく、チーム、各自が真のパフォーマンスを発揮できる環境を整えてあげる事が大事。
  • 一人一人の資質やパフォーマンスが重要になってくるので、それを最大限に発揮できるように、現場環境を見直しましょう。

本題5.  変わるために必要なもの


ここでは、自分一人だけ変わってもダメ、全員が変わって行くためには何が必要か、というお話。変わるために、先に出て来た『環境の大切さ』をより強く裏付けるようなお話です。



  • 最高のパフォーマンスを発揮するためには、下記の3つが必要。
  • 1. モチベーション。
  • 2. 目的意識。
  • 3. より良いと思われるものがあれば、それにチャレンジし、取り入れる勇気
  • しかも、自分だけじゃなくて、みんながそう思う事が大事。
  • ただし、チャレンジする/変わるというのは時間がかかる。
  • 大人が変わるのはたいへん。子どもは3ヶ月、大学生なら半年、でも大人だったら一年はかかる。
  • 自分は変わることができても、全員変わるまで待ってたらダメ、モチベーションも落ちる。
  • 周りが、『自分も変わりたい!』と思えるようなリズム、環境を作る。環境ができれば、あとは、その人その人が、みんな自律的に変わっていける。

本題6.  協調を意識すること


協調していくことの大切さのお話。この協調のためにも、やはり環境の重要性につながってきます。
  • 『確証バイアス』という言葉がある。
  • 自分にとって都合のいいこと、過去やった上手くいったものには流されてしまう傾向がある。(成功体験がある故に)
  • 1人でやってると、この確証バイアスがかかる。新しいものではなく、実績のあるものに偏りがち。
  • しかし、複数の人と協調してやりとりをしていくことで、自分だけの考えにとらわれず、一般化した答えを出せるようになる。
  • これを繰り返すことによって、応用力が高まってくる
  • これは、DevOpsのやり方にもつながる。
  • 協調を意識して行くと、現場にとって良い環境ができてくるようになる。


本題7.  これからのツールは?


ツールについてのお話。いわゆる開発ツール自体は、現場に閉じるならば完成された域に達している。これからは、現場間を円滑につなげるツールが必要になる、というお話。
  • 今後10年、ツールに期待することは?
  • 現場/行程/作業/ロールに特化し閉じたツールはもう成熟してる。それは当たり前になっている。
  • これからは、フィードバックのループが円滑に回るように、作業間の移行、受け渡しを円滑にするためのツールが必要になる。
  • 粒度、関心ごと、表現方法、見る人が違う。意識しないと行けないゴールは一緒だけど、ロールが違えば見方も、見たいものも違ってくる。
  • それぞれの立場で、それぞれが注目し、大事にしたいものを、ストーリーやゴールが途切れることなく見る事ができるのが重要。
  • アイディアを生み出し(企画)、やることを決めて実施し(開発/タスクの実行)、成果をデリバリー し、ユーザからのフィードバック という流れ(ストーリー)が、つながるようにする。

本題8.  Atlassianの製品では?


では、Atlassianの製品では、どうやってストーリを繋げていけるか、のデモでした。



  • Atlassianの製品で言うなら、企画者にはConfluence、開発者にはJIRAが舞台。
  • 企画者は文章をじっくり練りたい。一方、開発者は文書は見ない傾向があるので、タスクとして決まったことを見て、タスクをこなして行きたい。
  • 誰が、どの視点でも、全体をとらえることができるのが大事。
  • Atlassianでは、それぞれのツール自体、もちろん機能は十分であるが、さらに『連携』しやすいように、できている。
  • これが、製品を通してLook / Feelも統一させている理由でもある。

まとめ:Atlassian / エバンジェリストの目指すもの


ここまでで、思いっきり『全部Atlassian製品で良いんじゃない!』とまで思わせるのはさすが!

  • Atlassianはソフトウェアを通しイノベーションを起こすための『ドライバー』になる会社です。
  • エバンジェリストとして、みなさんの創造と破壊のための活動を支援して行きます。前職(MS)からのエバンジェリストとしての姿勢は変わっていません。

以上、長くなってしまいましたが、長沢さんのセッションのレポートでした。

どなたかもTweetしていたのですが、長沢さんの目指すものは、本当に前職からブレていないし、お話も専門用語を使わず誰にでも分かりやすい内容になっています。

期待に違わず、はしばしに仮面ライダー用語が出現したり、ライブならではの表現/お話を聞く事ができて、本当に楽しめたセッションでした。

長沢さん、お話ありがとうございました!


* * *

わたしは、わりとCMSやチケットシステムに関わって来ていたのですが、その中でも、

 『メールもファイルサーバもあるんだし、情報共有のためのWikiやツールなんて、お金をかけるものじゃないでしょ。そのへんに転がっているものを使えばいいんじゃないの?サーバのリソースもそんなに要らないでしょ』

と言った感じで、情報共有の仕組みにはあまり価値がないというニュアンスのことを言われたことがありました(^^;

でも、コミュニケーション、他部門との連携や情報共有が『根性』でやれる時代ではなくなってきている気がします...。会社が大きくなればなるほど。
数字で効果を見える化できないと、なかなかまだ予算が取れなかったりするのも事実ではありますが、ちょっと前と違って、情報共有/連携のための基盤の導入には、追い風が吹いているような気もします。