【勉強会メモ】京都Devかふぇ#2 〜WWDC & Google IO総復習会〜
- 日時：2018/06/15(金) 19:00 〜 21:30
- 場所：フリュー株式会社会議室（京都タワーホテル4階）
WWDC総復習
@dacchan さん
iOS
iOS11
- 1週間以内に半分のユーザーがアップデート
- 現在iOS11⇒81%
- 顧客満足度95%
iOS12
- 対応デバイス⇒iOS11サポートされていた全て
- iPohone 5s以上
- iPad 第5世代以上
- iPod touch 6G
- パフォーマンス向上
- アプリ起動40%
- データ共有速度2倍
標準アプリの改善
AR Kit
Photo
- 検索機能強化
- ワード検索
- 撮影場所
- イベント
- For You
- 思い出の写真、おすすめエフェクト
- どのユーザーとシェアすべきか
Siri
- Shortcutsと連携
- 登録済フレーズで起動
- おすすめ機能の向上
- おすすめ内容をロックスクリーンに通知
Shortcuts
- iOS12からの新機能
- Siriと連携して使用
- 登録済のフレーズ
- 例）帰宅というタスクを設定
- 帰宅というフレーズで起動
デザインの刷新
- News
- Stock
- Voice memo -Apple Books
Do Not Distrub
- おやすみモード
- 通知OFFの時間指定、場所指定
Notifications
- プッシュ通知のグルーピング
Screen Time
- レポート機能
- 1日、1週間のデバイスの使用状況
- App Limits
- 1日の使用最大時間を設定
- こどもの端末の使用状況も確認可能
- Downtime
- App Limitを使って子供の端末を使用制限
Messages
- Animojiが進化
- 舌の動きを検知
- Messagsに添付可能
- カメラ機能の強化
- Animojiなどがカメラの中で使える
Face time
- 最大32人まで同じグループで使える
- Messageと連携可能
watchOS
watch OS 5
macOS Mojave
- ダークモード搭載
- Stackモード
Navigation Architecture Component
@kwmt27 さん
↓でレポート済み
Navigation Editor はXcodeのStoryboardのように人が読めないXMLにはならないというのは魅力的。
Google I/O Overview
@AkihiroTokai さん
AI
- Google Duplex
- 電話を自動でしてくれる
- Smart Compose
- 自動でメールを書いてくれる
- Google Photo
- モノクロの写真に色をつける
- Waymo
- 自動運転の車が雨や雪の日にもノイズを除去
I/O Experience
Code Lab
- Chrome BookやPixelの環境でハンズオン
- 4つステッカーを集めると来年のチケットが当たる
Sandboxes
- 展示会
- AR使った卓球
- Android Things
Ofiice Hour& Apps Review
- Googleの人に話を聴ける
Meetup
- コミュニティの集まり
今回のテーマ：Make good things together
LT
iOS12におけるUITextContentType
@m_orishi さん
iOS12から2つのタイプが追加
.oneTimeCode
- 2ファクタ認証などで利用
- SMSに認証コードが届いてそれを入力させる
- パスワード入力時のテキストキーボードでパスワードをサジェスト
- タップすれば自動入力
- Code is ...などのメッセージを自動んで認識
.newPassword
- セキュリティ強度の高いパスワードを自動生成
- パスワード入力フォームがあるとパスワードをサジェスト
- パスワード生成ルール
- 生成ルールの文字列をつくるWebツールあり
- Password Rules Validation Tool - Apple Developer
- Storyboardからも設定できる
注意
- userNameとnewPasswordは同じ画面
- システムキーボードを利用する
Safariでも
- input passwordに設定することで可能
Google Codelabsをやってみた
@furusin_oriver さん
codelabs.developers.google.com
AppIndexingを試す
- 学ぶ内容の説明
- 用意するものの説明
- Firebase Consoleにプロジェクトを作る方法まで説明してくれる
良い点／悪い点
- 画面イメージが要所要所に貼ってくれていてわかりやすい
- ベストプラクティスの説明
- 画面の右上にあと何分で終わるか書いてある
- TODOがサンプルにコメントあり
- コードが間違っていることがある
感想
- めっちゃいい
- すごい細かい
- 公式のバージョンが上がっていることがある
Navigationもやってみた
- 言語はKotlinだった
- Javaと思ったらKotlinの事があるので注意
lang-jaを点けると日本語版もある
【勉強会メモ】Osaka Mix Leap Study #16 - Android Jetpack 勉強会
- 日時：2018/06/14(木) 19:00 〜 21:30
- 場所：ヤフー株式会社 大阪グランフロントオフィス
AndroidJetpack概要＆旧AACの紹介
中谷 克紀 (GDG神戸)さん
- 開発速度を上げましょう
- ボイラープレートを減らしましょう
- アプリを高品質にしましょう
Jetpack一覧
パッケージ名の変更
- androidxのパッケージ名に変更
LiveData
- Lifecycleを考慮してデータ反映
- Activityと同じ生存期間のため画面回転などで破棄される
ViewModel
- Activityより長い生存期間
- LiveDataとViewModelを組み合わせると回転を気にしなくて良くなる
- ViewModelでViewやContextを参照しない
- 低メモリ状態で破棄されることはありうる
Room
LiveData+ViewModel+Room
- LiveData：ライフサイクルを意識せずにUIに反映
- ViewModel：画面の回転時の処理を気にせずに実装
- Room：データベースへ簡単にアクセス
まとめ
- 自分のやりたい作業に集中できる
- Googleが提供するライブラリなので最新バージョンへの追従も早いはず
- バックポートも提供できるはず
Navigation Architecture Component
河本 泰孝(株式会社tech vein(テックベイン))さん
www.slideshare.net
Navigationとは
- 画面遷移の実装をシンプルにするライブラリ
- 現在1.0.0 alpha02
Navigationで何が嬉しいのか？
⇒今まで何が大変だったことをシンプルにする
- Fragment管理が複雑
- DeepLinkが複雑
- データの受け渡しが型安全でない
- 画面遷移のテストは大変
Navigation Graph
- ある画面から別の画面に遷移するのを視覚的に表現
- 画面のことをDestinationと呼ぶ
- FlagmentとActivity
Navigation Editor
- Android Studio 3.2が必要
- 新しいリソースタイプ
navigationを作成 - 適当な名前でxmlを作成
navigation-ui
- ハンバーガーメニューから開いて切り替えみたいな処理がいらない
データの受け渡し方
- Bundleオジェクトを使う
- Sefe Arge Gradleプラグインを使う
- 型安全にデータ受け渡し
DeepLink
- プッシュ通知やURLスキームから画面遷移が容易になる
今後追加されそうな機能
- startActivityForResultがサポート？
- DialogFragmentへの遷移
- 複数のアクティビティ間でUpボタンのサポート
- Shared Elementサポート
Deep Dive into Slice
森 洋之 (ヤフー株式会社)さん
Sliceについて
- テンプレート化されたUI
- ある程度形のきまった統一感のあるUI
- インタラクティブ
- アップデート可能
- テンプレートの追加などが可能
Sliceの仕組み
- SliceProviderを作る（ContentProviderを継承）
- URIをもとにSliceを要求
- UIを構造化されたデータで表現
実装方法
- Android Studio 3.2のメニューから一発
- SliceProviderを継承
- マニフェストに追加
どこで使われるか？
- Google Search
- 検索時に自分のアプリのSliceを表示してくれる
by App Name
by General Terms
3rd party to 3rd party
- アプリ間で連携
- 例）Yahooメールの内容をYahooアプリ内に表示
- サードパーティに開放するかは未定
Sliceめいたものをつくるなら
ContentProviderClient | Android Developers
まとめ
いつも聞いてビール飲んで帰るだけというのも申し訳ないので今回はLTにチャレンジしてみた。
先日参加したGoogle I/Oの報告会でも紹介されたML Kitを使ってみたレポートです。
【勉強会メモ】総関西サイバーセキュリティＬＴ大会（第9回）
- 日時：2018/06/13(水) 19:00 〜 21:00
- 場所：CTC大阪オフィス
遅刻したため2つ目のセッションからの参加です。
漏洩からみる法律問題
個人情報漏洩
- 外部犯
- 内部犯
- 社員のうっかり
外部犯
- 犯人だれ？⇒犯人が誰かわからない限りLawは動けない
- 法的責任のためには犯人追求が不可欠
- 最終的に刑務所に入れる人は誰かを特定しないといけない
わかりやすい責任追及にいく⇒ 会社
なぜやられた？なぜ防ぐことができなかった？？
セキュリティ対策
- 明示的にセキュリティ対策不足による損害賠償請求が認められたことはいまのところなさそう
- 常識的なセキュリティ対策については目次的に備えていることが前提と解されるおそれがある
義務
- 設計段階での構築義務
- 運用段階でのメンテナンス義務
- モニタリング義務
ランニングコストも踏まえたサイト運営をしないと危ない
内部犯
- 犯人の特定は外部犯よりは容易
- 情報窃盗した人がお金を持っていることはあまりない
お金が無かった場合⇒使用者責任（ 会社 ）
ある事業のために他人を使用する者は、被用者がその事業の執行について第三者に加えた損害を賠償する責任を負う。
外形標準説…外から見たら会社が命令を出したように見られることがある
「事業の範囲」とは本来の事業の範囲に限らず、密接な関連性を有するなど客観的・外形的に使用者の支配領域下にあればよい（外形標準説）と解釈されている。
内部のうっかり
従業員の過失⇒何をすべきだったのか？⇒セキュリティポリシーは重要
- 従業員の過失が認定できたとして⇒ 使用者責任
- 従業員の過失が認定できないとき
- 防ごうと思えば防げた？⇒ 会社 の責任
まとめ
会社に請求がくる可能性がある
どのくらい悪い？
何が考慮されている？
- 情報の種類
- 故意の漏洩か過失か
- 漏洩の態様や意図
純粋被害者的立場の会社はどうなるか？
- 会社は損害賠償のリスク
- 継続的な取り組みが法的に求められている
- 損害額は大きい方で未知数
経営陣のセキュリティに対する理解が必須
→ エンジニアとリーガルマネジメントの地位を上げていこう
経営陣は無傷？
→株主からの責任追及
以降はLT
脆弱性に備えよ
玉邑さん
- 課題：脆弱性の対応
- 2017年：14,700件
脆弱性は待ってくれない
- 影響調査
- 遮断対応
→一刻を争う
解決策1：影響調査を自動化
- 構成情報だけでは網羅できない
- 結局全台を優先度付で調査
zabbixのホストインベントリ
- 主要ソフトウェアのバージョン情報をリアルタイムに取得
Zabbix API
- 全サーバのソフトウェア一覧をCSVで取得
人海戦術→ポチッと
解決策2：すぐに気づく
- JVN
- JPCERT CC
- NISC
IFTTTでRSSの更新情報を連携
- RSSの内容をSlackなどに投稿
⇒すぐ調査へ
まとめ
- エンジニアにセキュリティは必須スキル
- 脆弱性に備えて準備しておく（調査の自動化
- セキュリティに対して情報感度を磨く
L3装置のセキュリティ〜まさかのバグ編〜
@MeiNogizaka さん
検証中に発見したセキュリティ機能に関係するバグを紹介
ACCESS CONTROL LIST BUG
⇒なぜかプロトコル番号の下位6bitしか参照しない
⇒パケットの共連れが可能
- 次回以降のNW装置検証で実施しなければいけない項目が増えた
- 検証大事
セキュリティと教育
NakaHiroさん
2020年からプログラミング教育開始
教育現場でのセキュリティ事故の事例
子供向けの書籍
診断員ちゃんは伝えられたい！
川東さん
診断サイトの情報
- 診断のプロでも診断対象サイトの全てを知っているわけではない
- そのWebサイトに存在するユーザーの種類を全部教えてほしい
事前チェックシートで確認
⇒一般会員と有料会員で閲覧できるコンテンツの範囲が違う
- 診断員もお客様も目指すところは同じはず
- お互い歩みより安全なWebサイトにしたい！
ULTIMATE CYBER SECURITY QUIZ
池田総裁
アルティメットサイバーセキュリティクイズ2018
3部制
- 予選
- ○×クイズ
- 200人から8人へ
- 準決勝
- 記述式クイズ
- 8人から3人
- 決勝
- 早押しクイズ
- 3人から1人へ
景品
- 入賞景品あり
- 参加賞あり
記念公演
- スペシャルゲストを予定
【勉強会メモ】スクラム道関西 第106回オープン・ジャム
- 日時：2018/06/06(水) 19:00 〜 21:00
- 場所：株式会社タンバリン
この勉強会はスクラムをやっている（やりたい）人がお互いにテーマを持ち寄ってみんなで議論する場です。毎回様々な話を聞かせてもらえてとても勉強になります。なお、以降にまとめたメモは、私自身のメモとしてその場で出てきた様々な意見をもとに個人の解釈でアレンジしてまとめているため、実際の議論の趣旨や発言の意図とは異なるものがあるかもしれません。
スクラム導入の効果について
- スクラムがうまく回せている状態とはどういう状態かを考えてみる
- なぜスクラムを採用しているのか（したいのか）の問いでもある
- 何を改善させるためにスクラムを選択したかによって、どんな計測をしてその効果を測るかが異なる
- すでにスクラムを始めているチームの場合、スクラムマスターはそれ（スクラムを採用している背景）を知るために努力するべき
※家に帰ってネット上で事例を追いかけてみるとQiita Teamがスクラムを取り入れるにあたって期待した効果とその状況についての記事を見つけた。
この事例ではチーム状況の可視化とチームの一体感を期待してスクラムを導入している。
スクラムは楽しいのか
- スクラムの定義には人を幸福にするような要素はない
- 近年はアジャイル界隈全般で幸福を扱う傾向がある
- Management 3.0 などの影響によるイメージはある
- Modern Agileでは4つの基本原則の中で「人々を最高に輝かせる」という定義がある
- スクラムのフレームワークの特性が楽しみにつながる可能性
- 短期間で改善サイクルを回せる
- プロダクトにコミットすることが求められることによる意識向上
- WFのような計画主義的なプロセスで決められたことだけ集中してやりたい人もいるので楽しいかどうかは人それぞれ
※事後メモ：よく言われるメリット・デメリット
- 近年では大学などでもスクラムを取り入れて学生に開発の楽しさを教える事例が増えている
www.slideshare.net
www.slideshare.net
※事後メモ：スクラム自体が楽しいかどうかはわからないが楽しくする要素やプラクティスを採用できるフレームワークであるとは思う。
スプリントレビューのやりかた
- ステークホルダーだけでなく直接関係ない社員も含めて50人くらい集めてやる事例（⇒見てみたい）
- いろんな人からフィードバックを得られるメリットが大きい
- インタビュー形式で質問者を指名したら参加者が減った
- POへの報告会のような形式になりがち（スクラムガイドの定義によるとPOに対してレビューするものではない）
- ステークホルダの発言力が強いとPOが前向きにレビューに参加できなくなる場合がある
- POとの関係性は重要
※スクラムガイドの「スプリントレビュー」
スプリントレビューとは、スプリントの終了時にインクリメントの検査と、必要であればプロダクトバックログの適応を行うものである。スプリントレビューでは、スクラムチームとステークホルダーがスプリントの成果をレビューする。（中略） インクリメントを提示することで、フィードバックや協力を引き出すことを目的とする。
https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf
※永瀬さんの資料がとても参考になる
www.slideshare.net
【読書メモ】スクラム現場ガイド - スクラムを始めてみたけどうまくいかない時に読む本-
スクラム現場ガイド -スクラムを始めてみたけどうまくいかない時に読む本-
- 作者: Mitch Lacey,安井力,近藤寛喜,原田騎郎
- 出版社/メーカー: マイナビ出版
- 発売日: 2016/02/27
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (2件) を見る
本書は副題の通りスクラムを始めたあと、習得していくうえでの困難に立ち向かっていくためのヒントを得るために読む本だと言える。著者によるとプロジェクトを始めてから6ヶ月〜18ヶ月の企業が対象らしい。スクラムを始めるとよく起こる問題を題材とした架空の物語とその解説を章ごとに扱い、全30章で構成されている。スクラムを経験していれば物語と扱うテーマはだいたい理解できるが、スクラムを始める前に読むには少しハードルが高いかもしれない。第1部は「準備」となっているが、スクラム未経験者の準備という意味ではなくスクラム経験者が新たに取り組むプロジェクトの準備という意味で捉えるのが良さそう。
ある程度スクラム開発を経験していれば章のタイトルを見るだけで扱うテーマが想像できるものばかりなので、実際に始めてみてから疑問や課題を感じた章から読んでみるのが手軽で効果的な活用方法だと思われる。一方で、各章の後半の解説部分は経験豊富な著者の実体験がベースとなっており、現場で活用できるデータや理論が紹介されているため、課題の有る無しに関わらず全章を読んでおいても損はない。
- 1章 スクラム:シンプルだが簡単ではない
- 第1部 準備
- 第2部 現場の基本
- 第3部 救急処置
- 第4部 上級サバイバルテクニック
個人的ピックアップテーマ
以降は個人的に参考になった章を5つピックアップしてまとめておく。
ベロシティの測定
マネージャやビジネスサイドに対してチームがいつまでにどのくらいできそうかを説明するためにどうやってベロシティの予測を立てるか？
大きく3つのやりかたがある。
- 過去のデータを使う
- わからないなりに見積もる
- 様子を見る
過去に一緒に働いたことがあるチームなら過去のデータが使いやすい。過去のデータを使う場合は以下のような変数に注意を払う必要がある。
- チームと構成の新しさの度合い
- 政治的な環境
- プロジェクトの大きさや複雑度
- プロダクトオーナーと顧客
チームが異なればこれらの変数が全く異なるので過去のデータから予測がしにくい。
わからないなりに見積もる場合はPBIを見積もってチームのキャパシティからベロシティを予測する。より現実的な見積りが出せる状態になったらここで出した見積りは捨てる。
様子を見る場合は、数スプリント実施してみて平均を出して予測する。数スプリントも待たずに予測したい場合は『アジャイルな見積りと計画づくり』で紹介されているマイク・コーンの係数表を使う。
アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~
- 作者: Mike Cohn,マイクコーン,安井力,角谷信太郎
- 出版社/メーカー: 毎日コミュニケーションズ
- 発売日: 2009/01/29
- メディア: 単行本（ソフトカバー）
- 購入: 74人 クリック: 764回
- この商品を含むブログ (226件) を見る
※参考
どのようなやりかたで見積もるにしても、見積りは自信度に応じた幅をもたせ、ステークホルダーには見積りが概算であることと自信の度合いを正直に伝える。実際にスプリントを走らせたらベロシティを測定しデータを集めて見積りなおす。古いデータは捨てて新しいデータで置き換える。
ストーリーやタスクを分割する
適切な大きさのストーリーやタスクを書けるかどうかがスクラムの成否を左右する。
ユーザーストーリーは3つに区分できる。
- エピック：壮大な物語
- テーマ：エピックに含まれる中心的なアイデア
- ストーリー：テーマの中の1つのイベント
- タスク：ストーリーを実現するために必要なアクション
ストーリーをプロダクトバックログに載せる目安は
ユーザーがやりたいと思うアクションの最小のもの、あるいはビジネス価値がある最小の機能
ストーリーやタスクの大きさが適切か判断する一番の方法は質問すること。
- ストーリーは明確か？
- 見積りに仮定を置いている場合は注意。質問して分割する。
- ストーリーはどのくらい詳細か？
- テスト可能か？
- 小さいか？
- 自分自身でできるくらいストーリーを理解しているか？
サステインドエンジニアリングとスクラム
サステインドエンジニアリング（保守開発）の2つの手法
- 時間割当モデル
- スプリントに使う時間と保守に使う時間を決める
- 保守の知見をスプリントの開発に活かせる
- 既存システムの変更を開発にも取り込める
- 作業の切り替えコストが高くなる。小さな問題がたくさん発生すると影響が大きい。
- 割当時間で対処できない問題が発生するリスクがある
- 既存システムで問題がたくさん発生するとベロシティが安定せず予測がたてづらい
- 専任チームモデル
- 保守の専任チームをつくる
- 新メンバーが既存システムについて学ぶトレーニングになる
- 新しい問題にすぐに着手できる
- エキスパート化できる
- 保守開発のリリースを頻繁にできる
- 仕事が単調になりがち
- メンバーが保守開発にモチベーションを持てないかもしれない
専任チームの場合、メンバーをローテーションすることがスキルの偏りやメンバーのモチベーションに対処する手段となりうる。時間割当モデルの場合は、TDDなどを新規開発だけでなく既存システムの改善などにも取り入れる。
新しいチームメンバー
新しいメンバー が加入することによってチームは形成期や混乱期に戻るリスクがある。
※参考：タックマンモデル
スキルと価値観に注目して人選し、学びにフォーカスしてチームで以下のような試験問題を準備する。繰り返し試験を行い学習してもらう。
巨大なバックログの見積りと優先順位付け
何から手を付けて良いかわからないほど巨大なバックログを整理するための「巨大な壁」と呼ばれる手法。ストーリーポイントの議論は後回しにしてストーリーの大きさと優先順位を同時に検討する。
- 巨大な壁の左を最小、右を最大としてチームでストーリーを相対的に見積もる
- 見積りサイズの論理的な区切り（例えば3ptか5ptかの区切り）をチームで決めて線を引く
- ステークホルダは下を低、上を高としてストーリーの相対的な優先順位を決める
- 見積りサイズの線を超えない範囲で上下に並べる
- 巨大な壁を4分割してストーリーをプロダクトバックログに並べ替える
事前に目的と全体のルール、タイムスケジュールを説明する。議論が脱線して時間がかかりすぎないように場をコントロールする。議論が白熱して決まらないストーリーはパーキングロットに置いておき、別枠で議論する。巨大な壁はあくまでスタート地点であり、変更を前提にして考えてもらう。
