LEMONADE THINGS (@nishino_chekhov)

主に技術関連のレポート、作成資料の配置など

自己紹介ページ：活動リスト

◆登壇（企業主催イベント）

  • IBM THINK 2018（米ラスベガス：2018/3/19 - 2018/3/22（現地時間））

    ※資料非公開

 


◆登壇（コミュニティ主催イベント）
◆企業向け講演
◆執筆

◆その他公開資料

 

2018/5/17 Java Day Tokyo 2018 登壇記録

2018/5/17に行われたJava Day Tokyo 2018に登壇しました。
記録として簡単に記載します。 

Java Day Tokyo 2018概要

www.oracle.co.jp

セッション名

  • [BN-3] 50分で最新技術学習の基礎を身に付ける
    ～ 最近よく聞くキーワードの解説で、初心者もイチから学べる業界トレンド ～

 

資料

www.slideshare.net

 

所感

  • 最も遅い時間帯（17時～）でのセッションとなりましたが、おかげさまで満員に。やはり平日日中、Oracleオフィシャルイベントだけあって、初心者向けコンテンツは人気があることを再確認

  • オフィシャルイベントと言えど空気はあたたかく、アイスブレイクとして狙った掴みも受け、そのままよい流れに

  • 終わった後は複数の方が列をなして質問に来て下さり、口々によい感想をいただけました。Oracle社からのFBもいただきましたが、満足したという声が多数あったとのこと。かなり早口のセッションとなりましたが、内容が伝わったようで何より

登壇の様子

 f:id:nishino_chekhov:20180528190812j:plain

f:id:nishino_chekhov:20180528191057j:plain

f:id:nishino_chekhov:20180528191212j:plain

f:id:nishino_chekhov:20180528191258j:plain

SNSでの感想

↓写真と一連のツイートでまとめてくださった方も。感謝！

 

まとめ

おかげさまで達成感のある登壇となりました。

参加くださった方々、ツイートしてくださった方々ありがとうございました。

今後も楽しいコンテンツを提供できるよう精進します。

 

2018/4/27 日本GlassFishユーザー会 登壇資料

先日の日本GlassFishユーザー会（GlassFish Users Group Japan）の勉強会に登壇させていただきました。

 

glassfish.doorkeeper.jp

 

登壇テーマ

以下2点です。

  • 3月に登壇したIBM Think（米ラスベガス）の講演内容の簡単な紹介
  • そのイベントで対面によるMtgの場を設けていただいた Ian Robinsonたちとの質疑応答内容のまとめ

 

登壇資料

www.slideshare.net

 

大変よい機会をいただきました。

懇親会でも色々なJava界の有名人の方々と交流させていただけました。

来て下さった皆様と事務局の皆様に感謝！

2018/1/10 DCI Tokyo 1 参加レポート（memo）

 注：だいぶ苦労して整理しましたが、抽象的でややこしい内容なのは、そういうものとしてご容赦ください。

カンファレンス内容

dcitokyo.connpass.com

 

セッションテーマ

  • 書籍「Lean Architecture」の著者James CoplienによるLean Architectureの解説

 

ハッシュタグ

#dcitokyo

 

以下、セッション内容メモ

f:id:nishino_chekhov:20180111210942j:plain

前提①：FormとStructureの違いについて。

Formとは抽象的なものであり、Structureはもっと具体的なもの。
現実のもので例えてみよう。

【椅子の例】

  • ここに椅子がある。椅子とはFormである。
  • あそこにも違う形の別の椅子がある。Formは同じ。しかし形が違うので、Structureは違う。
  • こちらにあるソファはどうか。これは椅子とは違うのでFormも異なる。

【ボトルの例】

  • ここにガラスのボトルがある。
  • これを作るときは型を作り、そこにガラスを流し込んで作っただろう。
  • 同じ型に溶かしたチョコレートを入れたり、ゴールドを入れても物を作ることができる。
  • これは、同じFormで別のStructureを作るという意味になる。

【椅子とソファ】

  • 椅子とソファはなぜ違うと認識できるのだろうか。
  • 認識した後に説明はつけられるだろう。例えば、椅子はソファに比べてカチッとしているとか。
  • つまり、説明がなくても、頭ではもともと理解していることである。

【前提①をシステム開発に照らし合わせると】

  • 設計のときは単にListを使う、としていたとする。
  • 実装のときに初めて、そのListの中の値がIndexで並んでいるのか、シンボリックネームで並んでいるのかなどを意識することがある。
  • 設計のときはその辺を気にしない。それがFormである。
  • 実装のときに気にした要素、それがStructureである。


前提②：FormとFunction

【椅子と段差】

  • Formは違うけどFunctionが同じものがある。
  • 例えばここにある段差。ここに腰かけることができる。
  • じゃあこれは椅子か？違う。
  • これが、Formは違うけどFunctionが同じであるということ。

 【前提②をシステム開発に照らし合わせると】

  • 同じアルゴリズムの実装でも、異なるアイデンティティを持つプログラムを書くことがあるだろう。
  • それが、Formは違うがFunctionが同じということ。
  • 何が違うのか、を考えることが大事。

 

前提①と②に関する警鐘

【最初は頭を空に】

  • システム開発において、最初からプログラム言語やオブジェクト指向を意識した設計をすべきではない。
  • そういう要素に対しては頭を空にして考えるべき。全てを椅子であるとして見てはならない。
  • 設計を進める上で、同じ部分を見出し、Commonality（共通性）を設定していくことが大事。

【JavaやC++の問題】

  • Structure（構造）のCommonality、Behavior（動作）のCommonality、どちらも存在する。
  • JavaやC++はどちらも同じように実装に落とし込める。
  • それは言語仕様としてよくないことだと思う。

※そもそもC++はオブジェクト指向言語ではなくマルチパラダイムプログラミング言語として作られている。その点は誤解すべきでない

【銀行の送金トランザクションを例にした説明】

A～Cのステップで説明。

  • 送金トランザクションで使われるオブジェクト、ひとつひとつにIDを持っている。
  • (A)このIDを印刷してみよう。f:id:nishino_chekhov:20180111205650j:plain
  • ID（数値）の羅列が続くだろう（注：写真、見えますでしょうか。ランダムな数値の羅列）
  • これでひとつひとつのオブジェクトが何をしているか、読みとれる人はいる？わたしにはわからない。
  • (B)じゃあ、オブジェクトIDのかわりに、クラス名を印刷するものとしてみよう。f:id:nishino_chekhov:20180111205758j:plain
  • 少しパターンが見えてきた。でもまだ完ぺきではない。
  • (C)それでは、Roleの名前を印刷してみよう。

    f:id:nishino_chekhov:20180111210002j:plain

  • これなら、その処理が何をしているかが見えた。
  • これがこのFunctionのFormである。
  • FunctionもFormを持っており、そしてそれはRoleの中にあるのだ。

【Javaの問題】

  • 例えばJavaには多態性というものがある。それを用いると強力なプログラムをかけるが、これはどうやって理解し、テストできるのだ。
  • こんなのはGoTo文と同じようなもの。
  • こういうのがあるから人間が理解するのが大変になるのである。

注：つまり、BehaviorのCommonalityをそのまま実装に落とし込めてしまう悪しき例として話しているのだと思われる

【DCIとは】

  • FunctionのForm、つまりRoleをプログラミング言語がネイティブにサポートする。そんな言語がDCIである（今はまだないけど、想像してほしい）。

【送金トランザクションの例をまとめてみる】

以下、自分なりの整理。

  • つまり、前提②で書いたように、Behavior（動作）においては、振る舞いは同じだけどアイデンティティが違う実装が存在しうる。
  • ではそのBehavior（動作）のアイデンティティとは何かというと、Role（＝FunctionにとってのForm）であると。
  • そしてそのRoleを定義することが今のプログラミング言語はできない。
  • それにより、段差を椅子として使っている（アイデンティティが違うのに、振る舞いが同じだから共通化している）ような処理が生みだされてしまうという問題がある。
  • Roleを定義できればその問題がプログラミング言語の中でも解消できる（設計時には言語化しなくても誰もが知っている「椅子とは何か」の定義が、実装の中でも表現できる）。
  • それがDCIだ。

という話だと理解。


※以降、第二部含め非常に良い話が続いたものの、
　これ以上はうまくまとめられないので、ここで〆ます。

 

所感

  • 本編はほぼ英語で、かつ抽象的・難解な内容であったため、理解に苦労したものの、率直に言ってめっちゃくちゃ面白かったです。
  • 勉強会は、実際の製品に関する説明や、実装などに関する話もよいのですが、こういう理論に関する話が一番好きだなと実感しました。
  • 多態性を使いまくったソースを追いにくいのは自分の能力が低いからと思ってしまいがちですが、ここまで思い切り Disrespect してもらえると大変心強いです 笑
  • 書籍 Lean Architecture の和訳がないのが残念でなりません。出たら朝まで読み続けるであろう自信がついたくらい、強い興味がわきました。（英文で読めるほどの自信はないけど...）

 

現場は30分も延長するほどの大盛り上がり。

大変エキサイトできる貴重な勉強会でした。

運営、登壇者の方々ありがとうございました。 

 

追記（2018/2/7）

公式のサマリ記事出ました。

当ブログのレポートにも触れて下さっています！

（後半の「今回のセッションの参加ブログ」のリンク部分）

PHP Mentors -> DCI Tokyo 1 - Lean Architecture by James Coplien - が開催されました（前編）

2017/12/12 JAWS-UG コンテナ支部#10 参加レポート（memo）

AWS Kubernetes Docker Report Conference Serverless cloud

参加イベント

jawsug-container.connpass.com

 

セッション①

  • re:Invent recap - アマゾン ウェブ サービス ジャパン株式会社 シニアソリューションアーキテクト 西谷 圭介さん

f:id:nishino_chekhov:20180107133154j:plain

内容メモ

 「AWS Fargate」

  •  ECSのインスタンスを管理したくない、アプリ開発に専念したいという声から生まれたサービス
  • 使うことにより管理するインスタンスがなくなる、タスクネイティブなAPI（クラスタ自体はシステムの境界として残ってはいる）
  • タスクに割り当てたリソースにのみコストが発生する課金。CPUとメモリの使用ごとに秒単位で課金
  • Fargateのユースケース①：マイクロサービス。開発者がインフラ、つまりデプロイ要件などを考えなくてよいので向いている
  • Fargateのユースケース②：バッチジョブ。ずっとあげっぱなしで実行するわけでもなく、事前にキャパシティを準備しておく必要もない
  • Fargateのユースケース③：マイグレーション。オンプレからクラウドへ、コンテナ化して移行する際、移行対象であるコンテナそのものによりフォーカスできるだろう
  • 同一クラスタ内でEC2とFargateを混在させられるので、どちらを採用するか選択できる
  • AWS Lambdaとの使い分け。同じようなモデルに感じるが、実際は細かいところが違う。イベントドリブンとかミリ単位のコンピュート、ランタイム管理したくない場合はLambda。それ以外はFargate。そしてLambdaは5分という時間制限があるので、それより長いシングルバッチなどはFargateの方がよいだろう。

「Amazon EKS」

  • 「Kubernetes、使っている人どれくらいいますか？（会場ほとんど手を挙げず）え、皆さんどうやってコンテナ使ってるの？ECSですか？（会場頷く）ありがとうございます（笑）」
  • Kubernetes、ここ12ヶ月くらい、世間を席巻していると思う。Amazonも重要だと思っている
  • でも使うのが結構面倒。そこでAmazon EKS。
  • 既存のKubernetesのノウハウをそのまま使える。プラグインやツールもそのまま。
  • AWSはCNCFにも加入（プラチナメンバー）。Kubernetesプロジェクトにも積極的に貢献していく。

 

セッション①感想

最新情報の収集以外で大きな収穫は2点。

  • LambdaとFargateの使い分けについて言及されていたこと。LambdaがFaaSに特化させるべくあえて時間制限などをかけているので、もう少し従来のアプリ向けのサービスとして使うためにFargateが活用できる、というところだろうか。
  • AWSの勉強会なので、Kubernetesユーザーがほとんどおらず、ECSを活用しているという事実にはなるほどと感じた。ネットの情報だけだと、この世のコンテナオーケストレーションはKubernetesだけ押さえておけばよいというような気持ちになってしまうが、コミュニティによって違うんだよねと。

 

その他、興味深いセッションもありましたが工数の都合上省略！

運営、講演者の皆さまありがとうございました。

 

2017/11/22 html5j Webプラットフォーム部 第18回勉強会 レポート（memo）

Conference Report techplay accessibility html5jplat

イベント詳細

html5j-webplat.connpass.com

※動画、スライド掲載あり

ハッシュタグ

#html5jplat

 

 

セッション①

  • なにからはじめたらいいかわからない人のための、これからはじめる『ウェブアクセシビリティ』 （山本和泉）

 

f:id:nishino_chekhov:20171231203822j:plain

 

アクセシビリティとは？

  • アクセシビリティとは「Access＋Ability」、つまり「アクセス＋できること」
  • ティム・バーナーズ＝リー （WWWを作った人）の言葉「誰でもアクセスできるというのはWebに不可欠な特徴である」
  • そもそもコンテンツ以前にアクセスできないとダメ。どうしようもない 

アクセシビリティの公開

  • Yahoo!、DoCoMo、Casio、Panasonic、どこの公式サイトにもアクセシビリティについてのページがあり、その内容を公開している
  • 記載されているのは、例えば構造と表示スタイルについて。ページ冒頭に見出しをつけていますとか、文字サイズは必要に応じて閲覧者が変更できるようにしているとか（メタタグとかで固定させているサイトもあるけど、それはユーザが変更できなくなっちゃうから、アクセシブルじゃないよね）
  • ほかにも、キーボード操作だけで閲覧できるようにしていることとか、音や映像が勝手に再生されないようにしている、なんてことも載っている
  • 色弱などのハンディキャップのある方でも閲覧できるようにすることがWebにとって必要なこと 。サイトというサービスの評価をもらう上で不可欠

これだけはおさえろ！ウェブアクセシビリティ１０

  • １）ページの内容がわかるページタイトルをつける（<title>タグ）
  • ２）見出しやリストなど文章構造をマークアップする
  • ３）構造をセクショニングする
  • ４）リンクテキストはリンク先がわかる文言にする
  • ５）情報を伝えている画像に代替テキストを入れる
  • ６）文字色と背景色のコントラストを確保する
  • ７）キーボードだけでも操作できるようにする
  • ８）音声や映像を自動再生させない
  • ９）再生ボタンとストップボタンをつける
  • １０）見た目はCSSで調整する 

読むべき書籍・サイト、フォローすべきアカウント

 

 

セッション②

  • 多様なユーザーニーズに応えるフロントエンドデザインパターン〜エッセンス編（freee 株式会社 伊原力也）

f:id:nishino_chekhov:20171231212036j:plain

 

”オレンジ本”について

  • 「インクルーシブHTML+CSS & JavaScript 多様なユーザーニーズに応えるフロントエンドデザインパターン」（通称”オレンジ本”）の監訳を担当
  • アクセシブルの話って、「これはやっちゃだめ」って話が多い。この本は「こう実装するとアクセシブルだよ」という話をメインで載せている
  • 今日はそのエッセンスとして、入力フォームをテーマとして取り上げる。

入力フォームのアクセシビリティ

  • ウェブをインタラクティブにしているのはリンクとフォーム
  • フォームは「入力欄とラベル」「エラー表示」の二つで構成される。今日のテーマはこの二つ

入力欄とラベルのポイント

  • １）入力項目とラベルを明示的に関連付ける
  • ２）見た目でも入力項目とラベルの対応を明確に
  • ３）何が起きるか明白なラベルにする
  • ４）プレースホルダをラベル代わりにしない
  • ５）必須と任意を明示する
  • ６）入力条件は先に提示する

ポイントピックアップ「１）入力項目とラベルを明示的に関連付ける」

  • まず、ラベルがないとその項目が何かわからない。じゃあ、関連付けってなんでしょう？
  • それは、<label for = "password">パスワード</label>のように、ラベル側はfor=で属性とし、入力側は<input id ="password">として紐付けるということ
  • そうすると、スクリーンリーダーというソフトのユーザーが助かる
  • 先の例では、パスワードの入力欄にカーソルがフォーカスしたときに、その属性を読み上げ文の中に入れて読んでくれる（「パスワードエディット、保護つき」などのように） 。これがないと、ラベルにはフォーカスしないので何の入力欄か知りようがなくなる
  • じゃあラベルが読めない場合だけのために設定するのか？そうではない。関連付けられていると、ラベルをクリックした際に対応するテキストボックスにカーソルがフォーカスしてくれたりする。ブラウザの機能で。そういう利点もある

その他のポイント抜粋（２～６）

  • プレースホルダ（注：[メールアドレス]のようなイメージで、カーソルをあてる前に、入力欄の中に項目名称を表示させておく手法。カーソルをあてると消える）をラベル代わりに使うサイトが多いが、これは避けるべき。カーソルをあてると何の項目かわからなくなるので、じわじわといらいらしてくる
  • 必須項目の表現に「*」を表示する例はよくあるが、普通に「必須」と書いたほうがアクセシビリティは向上するだろう。

エラー表示のアクセシビリティ

  • １）エラーはフォーム内に出す
  • ２）エラー状態が伝わるようにする
  • ３）エラー個所を明確にする
  • ４）エラーの修正を助けるメッセージを出す
  • ５）リアルタイム検証は慎重に使う

１～５のポイント抜粋

  • １）エラーが別画面に出て、戻るとエラー内容が書いていない。という仕様だと内容を覚えておかなきゃならないので困る
  • ２）Submitした後進まないけど、エラーだということに気づけない。上のほうにスクロールすると書いてあってわかるとか、そういうのは困る。触っていた場所のそば（送信ボタンの直上など）に出すべき。エラー個所に勝手に移動するようなデザインについては、わかりづらいとしてこの本（オレンジ本）の著者は非推奨としている
  • ３）および４）「赤色の箇所のみ変更してください」赤が見えない人もいる。「不正な入力です」どうすればいいのか。よい例は「パスワードは６文字以上で入力してください」など
  • ５）入力しながらチェックするような作りだと、入力中に正の条件を満たすまでずっとエラーだと表示されていたりする。「わかってるよ」となってしまう可能性もあるので、ケースバイケースだと理解しよう

 

総評

  •  アクセシビリティについて全く予備知識なく参加したのですが、普段の業務アプリケーション開発の中では意識しない非常に細部の使い勝手向上について話が聞けて、大変勉強になりました
  • アクセシビリティをやるためにサイバーエージェントに転職した人の話なんかも例に出されていて、そのスキルで結構食えるというのはなかなか興味深い。縁の下の力持ち的な開発を好む人にも活躍の舞台があるってのはいいよね
  • 本文では省略しましたが、アクセシビリティをやることで「ハンディキャップのない一般人にとってもわかりやすいサイトになる」「広く開かれたWebの世界で売り上げ向上などの利益つながる効果もある」といった利点についても触れられました。つまり、利益追求に対する純粋な活動の一環である、というメッセージを受け取れた（それこそが開発において最も健全な動機であると思います）のもよかったです

 

全く知らない分野について知ることで、また一歩総合力が身についた実感があります。運営、登壇者の皆さまありがとうございました。

 

2017/12/27 JJUG ナイトセミナー: 年送りビール＆LT大会（登壇時の資料公開＋感想）

先日行われたJJUGのLT大会に登壇しました。

使用した資料の配置と、ちょっとした感想など。

 

◆イベント概要

jjug.doorkeeper.jp

 

 

◆登壇資料はこちら

www.slideshare.net

 

◆登壇の感想

今回のはきっちり時間を計って何度も練習し、５分間キンキンに詰めたLT（一度やってみたかった）。実践してみた感想としては以下の通り。

・ストレートなネタを入れてみたのも実験。全体的に笑いをもらえて安心しました（参加者の皆さま、暖かい空気作りありがとうございます）

・会の後いろんな方に声をかけていただけてありがたかったです。これこそが登壇の最大の利点かもしれない

・意外とTechPlayなどをご存知ない方もいたので、情報共有としても悪くない題材選択だったかも

・聴講者の方々の顔を見ながら話す内容やペースの調整ができないので、やっぱりキンキンに詰めるよりも多少バッファはあったほうがよさそう。そうすると伝えられる量は減るので、そこは取捨するしかないか。この辺の手法はもう少し場数を踏んで、試行錯誤していきたい

 

とにかくJJUGのLT会は例外なく空気が暖かく、やりやすいので初LTの方にもおすすめです。

 

貴重な機会をくださったJJUGの皆さま、聞いてくださった参加者の皆さま、ありがとうございました。