【勉強会メモ】Osaka Mix Leap Study #21 - Server Side Kotlin
- 日時：2018/08/09(木) 18:30 〜 21:00
- 場所：ヤフー株式会社 大阪グランフロントオフィス
KotlinといえばAndroidの開発言語というイメージが定着しつつありますが、実際には今回のLTでも話がありましたがマルチプラットフォームに対応した言語です。サーバサイドKotlinの話は時々聞きはしますが、どうなんだろう？ということで興味を持って参加しました。
実際にはDBアクセスまわりなど、サーバサイドを全面的に置き換えるにはまだ課題がありそうですが、ヤフーさんのように既に部分的にKotlinへの置き換えが進んでいる事例は思ったよりありそうだと感じました。イメージ的にはAndroidアプリ開発者がサーバサイドもKotlinで書きたいというモチベーションで導入しているのかと思っていましたが、PHPからKotlinへの置き換えというケースは少し意外でした。しかし現地の他の人からも少し話を聞いてみると言語仕様的にPHPからKotlinはそれほどハードルが高くないとのこと。確かにKotlinの型推論などはPHPerからするとJavaよりとっつきやすいものなのかもしれません。
今回、遅れて参加したりいろいろあってメモが雑ですがご容赦ください。
Kotlinのサーバサイド事情を俯瞰する
@ngsw_taro さん
Ktor（KotlinのWebフレームワーク）
Exposed（DBアクセスライブラリ）
Koin（KotlinのDIライブラリ）
- Kotlin x Spring
- Web Fluxに着目
※メモ
- Reactorのコルーチン
zipとかのAPIを覚える必要ない
※メモ
3. Spring Fu
- Kotlin向けマイクロフレームワーク
- GraalVMのAOTを狙っている？
まとめ
- Spring Bootは王道
- コルーチンのおかげでReactorをしらなくてもOK
- Spring Fuは開発途上
- 気になるのはDBアクセス周り
- （実際のプロジェクトではExposeはまだ使いにくい）
サーバーサイドKotlinとSpring5の Kotlin support
@bulbulpaul さん
Yahoo!カレンダーの技術ポートフォリオ@Server Side
なんでKotlin？
- 制約と規律
- Null Safe
- sealed class
- 高い利便性
- 巨人の肩に乗れる
- Javaのエコシステムを使える
⇒開発が楽しい！
利用技術
- Javaライブラリ
- Athenz（認証／認可）（米Yahoo製）
- Pulsar（MQ）
- Hystrix（サーキットブレーカー）
- Kotlin対応ライブラリ
- SpringBoot（Fw）
- Moshi（Json）
ライブラリのKotlin対応
- サポートされていないからKotlinが動かないことはない
- Kotlinらしいコードで書けるための処理対応
- 場合によってはJavaとの境界でNull Safeが守られない
GsonではNullSafeの定義をしてもNullが入ることがある
Spring Boot
- Spring Fu
- Spring Initializr
- Spring Boot v2
Kotlin Support
- idikomatic Kotlin code
- Annotations
- RouterFunctions
- Bean definition DSL
Kotlinらしいコードが書ける
- Extension functions
- Reified type parameters
- Javaのコンパイルで消えてしまうジェネリクスの型をinline展開して処理中に参照する
- Class
で受け取る処理が多いので細々としたところの記載がKotlinらしく書ける
まとめ
- SpringBootはKotlinの特性を邪魔せずに書ける
- Kotlinはサーバサイドでも十分活用できる
- Javaのライブラリも問題なく使える
LT
KHipster ~JHipsterで始めるKotlin Web プログラミング~
@s_kozake さん
JavaのScaffoldツール（例えばSpringBoot＋Angularの環境のようなアプリの雛形を自動生成してくれる）JHipstet の紹介と、それのKotlin版であるKHipsterの紹介。
KHipsterはまだ開発中（現在 v0.5.0 ）なのでデフォルト設定を変更すると動かないので注意が必要とのこと。
multi platform kotlin
Multiplatform Projects - Kotlin Programming Language
Kotlinのマルチプラットフォームについて
マルチプラットフォームのサービスのドメイン層をDDDで設計してKotlinで実装するための考え方について本家サイトに公開されている解説を元にまとめた内容の発表。
- 環境構築が大変
- gradleとwebpack連携など
javaタヒねとさけんでた
Kotlinのコードの書きやすさ、見やすさについて。
Arrayの使い方でJavaだと for(int i = 0; i < list.size(); i++){ } のような煩雑な書き方をしないといけない。Kotlinは快適という話。
【勉強会メモ】総関西サイバーセキュリティＬＴ大会（第10回）
- 日時：2018/08/08(水) 19:00 〜 21:00
- 場所：MOTEX大阪本社
セキュリティ現場の表話、裏話
富士通セキュリティマイスター かやまこうせつ さま
- LTのメッセージ
- 縁の下のエンジニアのいいとこ探して応援できる社会へ何かできないか
- 葛藤
- セキュリティを全面に押し出したかっこいいところや、危険を煽る内容がクローズアップされすぎていないか
1. ランサムウェア Wanna Cry
- うっかり払ってしまいそうな身代金
- 現場「あのコンピューターもつながってたの？」
- バスの掲示板の裏で動いているPCなどもファイル共有設定されていた
裏：つながる時代を顕在化させたWannaCry
2. 人材育成
- セキュリティ人材育成の取り組み
- 現場は人材育成しているつもりはない
裏：人材育成は場づくりから
- フィールド領域
- 現場の人
- エキスパート領域
- セキュリティアナリスト
- ハイマスター領域
- シニアセキュリティ
ハイマスターが下から現場を支えるようにする
3. サイバーレンジ
裏：サイバーレンジは場の一つ
- サイバーレンジを買うだけでなくそれをどうやって扱うか
人を中心とした設計
- タレントは自分の範囲でしか仕事をしない
- ナレッジをどうやって集めるか
- 貯める場所を用意しないと散在
※メモ
4. 公衆無線LAN
利害関係者を洗い出して議論するのが大事だ。法整備という話も出てくるかもしれない
裏：そんなん言ったかなぁ
- 利害関係者を集める
- 緩和するための法整備もしてはどうか
5. 国産プラットフォーム
- 日本vs海外
- 減点vs加点
- 障害対応vsいいね
- ムエンゴvs谷町衆
- 粗相無いようにvsチャレンジ
第一部まとめ
縁の下のエンジニアの裏の頑張りを拾い続けます
第2部 セキュリティ競技 Hardening 100 Value x Value に参加してきた
内幕はそんなきれいじゃない
13時半までリモートデスクトップが繋がらなかった
⇒判断に徹する
オチ：RemoteDesktopツールのバージョンが違う
- 技術者と同じ目線で会話できるマネージメント層
- 技術わかる、縁の下のエンジニアの裏まで理解してあげられるマネ大事
- たましいは現場に宿る
締め
- 現場ではいろんな人がいろんな視点で頑張っている
- できて当たり前じゃない
- だからそんなエンジニアを応援したい
トークセッション セキュリティ競技の意義
Yahoo太田さま・富士通かやまさま・tktkのSeraphさま
以下のテーマについてトーク。詳細は割愛。
CTF
キャプチャー・ザ・フラッグ
CTFの例
- SECCON 2018
- CTF for GIRLS
- 高専向けCTF
- DEFCON
※メモ
Hardeneing
情報危機管理コンテスト
CYDER
CYDER | ナショナルサイバートレーニングセンター | NICT-情報通信研究機構
アルティメットサイバーセキュリティクイズ
関西の産官学による情報セキュリティ人材育成の取組（案）
藤田さん
関西で情報セキュリティを取り組んでいる人にもっと光を当てたい
- 政府方針
- 戦略マネジメント層の育成・定着
- サイバーセキュリティ戦略⇒東京の話
地域でこそ、この問題は深刻
- 地域で情報セキュリティセンスをもった人材の裾野を広げることが重要
具体的取組
- リソース足りないならみんなで補完しようというカタチづくり
- 学校や企業では教えてくれない、原理・原則講座シリーズ
- 情報セキュリティ人材へのスポットライト当て
今秋スタート予定。完全ボトムアップ。
IT知識ゼロの組織がマルウェアに感染した話
村上さん（京都産業大学2回生）
- 委員会の会議の場でPCが壊れた
- 明らかにランサムにやられてそう
対策
- ネット切断、電源切断
- 通常の業務と同じように直属の先輩⇒学校に報告
解決しなかった
- 幹部→学生部→情報センター→PC対策
- 学生部で立ち消え
- 曖昧な報告
CSIRTがマスト
- インシデント対応は通常の組織構造では対応が送れたり適切に行えない危険
- 組織にとらわれない動ける人
- インシデント対応ができる人
- 上の人や関わったことのない人たちでもビビらず対応しないといけない
裁判のIT化に立ち向かう
伊藤さん（弁護士）
日本の裁判所の文化
- Fax、印鑑
- 事件管理システムはClose環境で使いにくい
IT化
- 3つのe
- e-提出
- e-法廷
- e-事件管理
ハードル
- 法律マターか最高裁判所マターか
- Web会議による審議→裁判の公開？
- 日本は本人訴訟が多い
- IT化対応できない人は紙？
- セキュリティが問題になる
便利になった先に何があるか
- 判決のデータベース化
- ビックデータ活用
- 利便性とセキュリティ
セキュリティと利便性のあるシステム作れる方
- 最高裁が求めています
- 実装をしている皆様の声が必要
クレジットカードを不正利用された話
MORITAさん
タイムライン
- 10月にカード会社から電話
- アメリカにいる？
- 8月に言った
被害
blackhatの出張
- セキュリティのエンジニアがセキュリリティの出張でセキュリティの被害に…
決済に必要な要素
- クレカ番号
- 有効期限
- セキュリティコード
店員がバックヤードでカード情報取得
対策
- セキュリティシール（開封防止シール）
- セキュリティコードを隠す
まとめ
- ITセキュリティも大事だがまず物理セキュリテイ
- 内部犯行も考慮したセキュリティ脅威分析は必須
- 大手クレカ会社のサービスの信頼性
マッスルタワーに挑んでみた
chocopurinさん
Micro Hardening
ドラゴンボールに例えると
参加動機
- 技術的な刺激
- 本家Hardeningはスケジュール合わず
当日
- 岡山大学
- 参加者12名
まとめ振り返り
- 45分の短い時間だがいろんな分野の攻撃がくるのでインターバル時の疲労感
- 回を重ねるごとに対策ができているのを実感できる
- 事前資料はよく読む
- システム運用は知っておく
【勉強会メモ】re:Union 2018 Osaka
- 日時：2018-08-05（日）10:00 - 19:00
- 場所：エムオーテックス新大阪ビル
大阪北部地震で中止になったAWS Summit 2018 Osakaで予定されていたセッションを再構成した、JAWS-UG主催の仕切り直しイベントです。残念ながら全てのセッションに参加することはできませんでしたが参加したセッションだけメモを残しておきます。
個人的にはLift-and-Shiftの事例から始まり未来のエンジニアにまで言及されていた部分が刺さりました。あとはNintendo SwitchもガッツリAWSを使っているんだなぁというのも改めて時代を感じました。
SUMMIT TOKYO re:cap〜基幹システムの移行とクラウドネイティブ構築、それぞれの事例のお客様をお迎えして〜
亀田 治伸様(アマゾン ウェブ サービス ジャパン株式会社)
Summit Tokyoで発表された東京リージョン対応サービス
- AWS EFS
- 分散型ファイルシステム
- SageMaker
- AWS Fargate
- コンテナ環境の管理
- サーバサイドの細かい設定をする場合はECS
- QuickSight
- BIサービス
- ダッシュボード機能
- 現時点ではTabrouのような高度なBIツールを置き換えるようなものではない
大阪リージョン
Day1 Keynoteサマリー
- リージョン間の通信はインターネットに出ることがあったがinternalな通信ができるようになった
- Cloud Journey
- 12年間の知見蓄積とフレームワーク化
- Lift-and-Shift
- システムのクラウド移行
- いきなりコスト削減を目指さない
- 将来の最適化＆進化
Cloud + Community ⇒ 情シス2.0
友岡 賢二様 (フジテック株式会社)
The End of Corporate Computing
- 電気の発電機を持つ人は今やほとんどいない
- データセンターを持っているのは発電機をもっているようなもの
伝統的手法での企業データセンター
- 自社でつくるとめちゃくちゃ大変でコストかかる
固定リソースの限界
- 好きな時に好きなだけ立ち上げてあとで消せる
- Pay per use
- 拡張性・伸縮性
調達コスト
- 構築に最低6ヶ月ぐらいかかる
フジテックの情シス（88 servers）事例
- 初期費用
-95%
- 運用費用
-42%
- サーバレス
- 19,600円／年
- Lambdaにしたら100円／年
クラウドジャーニー
- Lift & Shift
- Re-Sizing & COst Optimization
- Serverless
Enterprise IT's Challenges
E-JAWS-UG
- 120企業
- コミュニティにエンジニアを放流しよう
Lift-and-Shift
- システムの維持コスト最適化
- 生産性の向上
AWS Well-Architected
- クラウドの正しい設計概念
TCO計算ツール
- Cloud Economics（投資効果算定支援）
AWS Support
- お客様をサポートするチーム
- Trusted Advisor
クラウドネイティブ
- クラウドで新規構築
高橋 真知様(株式会社 Stroly)
位置情報サービス - ターゲットやテーマを決めたマップ - 看板や紙で配布→もらっても位置がわからない→Webサービス化 - アナログ地図は世界中にバラバラ→位置情報と地図を連動させる
誰でも地図を一括登録
- アプリではないのですぐに利用できる
京都市の事例
- 260箇所の地図看板にQRコード設置
- 誰がどの看板を見たかもわかる
参考
www.slideshare.net
クラウドネイティブなアプリケーション開発
- 仮説立案⇒開発⇒検証⇒くりかえし
AWS loft tokyo（目黒）
- 2018年10月
- コワーキングスペースのような場所
- AWSアカウントがあれば無償で入れる
- S3でデータを捨てる必要がなくなる
- 蓄積されたデータは分析されビジネス強化に使われる
- データ分析⇒ビジネス設計⇒製品・サービス設計⇒提供開始⇒くりかえし
- 機械学習がサイクルを加速させる
BUILD ON
参考： AWS BUILD ON
参考
AWS Summit Tokyo 2018 資料・動画一覧 - ｜AWS
Lift-and-Shift による失敗しない AWS 移行のやり方
大石 良様(株式会社サーバーワークス)
AWSパートナー
- Premier
- 上位0.3%
どうやってクラウドに移行するか
Lift-and-Shift
- 既存のサーバーやシステムをで移行
- クラウドらしいサービスを活用してビジネスのデジタル化を推進
いきなりキラキラに移行しようとするとやけどする
- 運用手順変更
- 合意形成、手順作成、組織変更などが必要
- AWSのアップデートの速さ
- やっている途中で新しいサービスが出たりするとやる気を失う
AWSの隠れたメリット
- ネットワーク移行しやすい
- 仮想マシンが移行しやすい
- アプリケーションが移行しやすい
関西（西日本）の移行事例
- ネットワーク移行事例
- 仮想マシンの移行
- アプリケーションの移行
災害はいつくるかわからない
川村 暢様(株式会社NTTスマイルエナジー)
Lift-and-Shit戦略を実行した実例
AWSを使おうと思ったきっかけ
- 最初はプライベートクラウド
- NTTグループのサービスでスモールスタート
- ビジネスのスピード感にインフラが追いつかなくなった
- センサーIoT→センサー数が数万に急増
- ライセンス料がかかる
- ⇒AWSを使おう
AWSを使ってみた感想
- コスト面
- 環境を簡単につくれる
- あとで増減できる
- いったん作ってみて出せる
- エンジニアのモチベーションが上がった
Lift-and-Shiftをやってみてどのように評価されているか
- 少なくとも数年単位のスケジュールでやっていたものが5ヶ月でできた
- ほとんどインフラを知らないメンバーが2,3週間で仮想サーバの移行ができた
今後の展望
キラキラ系を目指す
金融機関の事例
- Lift
- 分散系サーバ、Webサイトの移行
- Shit
- セキュリティ対策としてログを分析
- FAQのAlexa対応
Cloud Automator
- AWS運用を自動化
新しいアーキテクチャへの移行支援
人材価値の変化
- エンジニアの価値が相対的に増大
- 若者層の価値が相対的に増大
不足する人材
- 優秀なエンジニア
- 若手人材
企業の変化
何を自社で行い何を外部に委託するか→AWSをIT基盤にする
※参考
Nintendo Switch (TM) 向けプッシュ通知システム「NPNS」
渡邉 大洋様 (任天堂株式会社)
※資料
Nintendo Switch （TM） 向けプッシュ通知システム「NPNS」
NPNS
- プッシュ通知システム
- Nintendo Push Notfication Service
- 常時接続を使用
NPNS利用例
- フレンドのオンライン通知
- Nintendo みまもりSwitchでの設定変更
- ゲームDL後に完了メッセージ
性能要件など
- スケーラビリティ：1億台に備える
- 可用率：AWSリージョン規模の障害未満は可動
- 遅延：数秒（正常時）、数分（異常時）
- インフラ費用：適切な範囲に抑える
構成要素
※下2つはREST API
XMPP Cluster採用技術
- ejabberd
- Erlangで書かれたOSS
- クラス構成のXMPPサーバ
- 大規模な利用実績が多い
- RDS for MySQL
- 高負荷時のレプリ遅延が少ない
- ElastiCache for Redis
Consumer/Provider採用技術
- RoR
- 社内での開発・運用実績から
- Amazon Aurora
- RDS for MySQLから乗り換え
- 柔軟なスケール
その他
インフラ設計
クラウド選定
- AwsをIaaSとして利用
- 社内実績
- メンバーの経験・スキル
- マネージド・サービス
- 配置
- シングルリージョン
- ネットワーク安定性、リソースの利用効率向上
- Multi-AZ
XMPPのロードバランス
- ELBは不採用
- Classic Load Balancer
- 常時接続に使えない
- Application Load Balancer
- プロトコルが合わない
- Network Load Balancer
- 検証次期とリリース次期があわない
- Classic Load Balancer
- 直結＋DNSラウンドロビン
- Route53に全ノードのAレコードを登録
- ConsulがRoute53のレコードを更新
- ディスカバリは用意しない
- 外部向けI/Fは増やさない
技術詳細
クラスタ維持
ejabberdを2方向から死活監視
- Consul
- すぐ反応
- Auto Scaling
- 慎重に様子見
デプロイ
ドリップ処理
- スムーズな切り替え
- 接続を少しずつBlue→Greenに移動
- 常時接続では接続処理が最も高負荷
- 再接続タイミングを分散させたい
- 切断期間は短くしたい
- やっかいな点
- デプロイが長時間化→今は約2時間
- インスタンス費用がその間2倍に
ドリップ処理の自動化
- Auto Scaling→Lifecycle Hook→CloudWatch Events→Run Command→EC2 Instance
省メモリ化
- インフラ費用を抑えたい
- ejabberdを省メモリ化
- OpenSSLのメモリ削減＆開放
- hibernate前にリソースを開放
- r3.largeで1台あたり72万接続
- ejabberdを省メモリ化
- ところが
- CPUもメモリも秋があるために接続数が増えない
- Security Groupの制限を回避
- セッションの上限にあたっていた
- Security Groupを無効に
- 限界まで設定可能に
- セキュリティ 外部アクセスはNetwork ACLsで制限
TCP切断対策
- 途中経路でのいy増切断を防ぐ
- 無通信期間にKeepAlive（L4,L7）
- 最適感覚を本番環境で実験
- TCP KeepAlive(L4)
- アプリケーション KeepAlive (L7)
- データを入れたパケットを定期的に送信
- 送信間隔：クラスタ間で対照実験
- 送信無し→65秒間隔
- 切断を50%削減
ふりかえり
12月の同時接続数増大→通知送信数は削減できている 規模
- 約700万同時接続
- 約2万通・秒
- 約l200億通／月
AWSの異常 - 発生した異常 - 局所的なネットワーク異常 - RDS I/O遅延 - EBS遅延 - EC2インスタンス異常停止 - NPNSサービスへの影響 - AZ冗長等によりサービスは正常稼働を維持
Erlangでの運用
良かった点 - 安定性 - VM,クラスタ、プロセス監視ツリー - メモリ効率 - 並列性 - hot code loading
ejabberd改造内容
- 並列性、安定性、対象外制
- 省メモリ化
- 独自機能
まとめ
- 必要要件を達成
- AWS起因のサービス停止は無かった
- サービス規模は順調い成長
今後の展望
【読書メモ】ライト、ついてますか
- 作者: ドナルド・C・ゴース,G.M.ワインバーグ,木村泉
- 出版社/メーカー: 共立出版
- 発売日: 1987/10/25
- メディア: 単行本
- 購入: 53人 クリック: 509回
- この商品を含むブログ (188件) を見る
副題に「問題発見の人間学」とある通り、問題に向き合い、解決に向けて思考を巡らせるための考え方を人間学の側面からやや辛辣なユーモアを交えながら解説している。
初版は1987年の古典的名著だが、出版年は意識して読むほうが良い。Amazonのレビューにもいくつかコメントを見かけたが、まず翻訳がわかりづらい。また、エレベーターや計算機という言葉は現代のそれとはやや違うものとして書かれているので注意が必要。これらは出版された年代を考えれば仕方ない面もある。それを考慮して読めば、問題解決に向けた普遍的な考え方や思考の巡らし方について著者が述べる本質的な部分を読み取ることができて問題解決力を養うためのヒントが得られるはずである。
何が問題か？
新築タワービルのエレベーターが遅いというエピソード。エレベーターが遅いのが表面的な問題ではあるが、ビル入居しているオフィスの従業員、オフィスの経営者、ビルのオーナーなど、立場によって問題の本質は異なる。
- 「何がまずいか」をどう決めるか？
- まずいのは何か？
- そのために、何ができるか？
問題とは、望まれた事柄と認識された事柄の間の相違である
望まれた事柄か認識された事柄かのどちらかを変えて相違をなくすことで問題はなくなる。
問題は何なのか？
ある11件の資産の入札プロジェクトのエピソード。それぞれの資産には様々な条件があって、入札に関わる4社がそれぞれ価格をつけると400万通りになり、その組み合わせの中から最も最適なものを選ばなければならない。
解法を問題の定義と取り違えるな。ことにその解法が自分の解法であるときには注意
複雑な問題を解くことが問題の定義ではないということ。
正しい問題定義が得られたという確信は決して得られない。だがその確信を得ようとする努力は、決してやめてはいけない
「究極の解答」は存在しないが、「問題は何か？」を問い続けることが重要。
問題は本当のところ何か？
すべての解答は次の問題の出所
ある問題を解くために状態を変えると別の問題を発生させることになる。 問題の転嫁 によってより小さな問題に状態を変えることができるが、たいていの場合は新しい問題が無意識的に作り出される。
新しい視点は必ず新しい不適合を作り出す
解決策を実施する前にこの視点を持っておく。不適合とは「その解決策とつき合わなければならない人間とうまく合わないような解決策」のこと。問題の当事者ではない「設計家」はたくさんの不適合を作り出してしまう。
同じ言葉を同じように理解しているという保証は決してない
行間を読んで自分たちの都合の良い解釈をしたり、単語の使い方1つで全く異なる意味に取れてしまい大きな損失を出すこともある。言葉を表面的なものから意味のあるものにするためには「言葉遊び」や「辞書方式」のような「社会的過程」が必要である。
それは誰の問題か？
他人が自分の問題を自分で完全に解けるときに、それを解いてやろうとするな
自分たちの問題は自分たちが一番理解しているので自分で解くほうが良い。
もしある人物が問題に関係があって、しかもその問題を抱えていないなら、何かをやってそれをその人物の問題にしてしまおう
反対に自分たちでどうしようもない問題であれば、「私の問題」を「われわれの問題」に変えてみる。学生の増加によって大学の駐車場が不足してしまったので、専用の駐車場を持つ学長も問題に巻き込んでしまおうというエピソードで語られている。ただし、立場や考え方が違うとうまくいかないことも多い。
変化のために自分をせめてみよう、たとえほんの一瞬でも
自分自身の考え方を変えてみることで問題が簡単に解決することもある。
もし人々の頭の中のライトがついているなら、ちょっと思い出させてやる方がごちゃごちゃ言うより有効なのだ
書籍のタイトルにもなっている車のライトの問題が出てくる。設計者や技師は何もかも自分が面倒を見なければならないと考えて問題を複雑にしてしまう。実際には「ライト、ついていますか？」と言ってやるだけで十分な問題だったりする。
それはどこからきたか？
問題の出所はもっともしばしばわれわれ自身の中にある
入国手続き中に書類のコピーが一部紛失していることが発覚し、役人側が紛失した可能性も否定できないにもかかわらず、官僚主義的に書類の不備として扱われそうになるというエピソード。
自然に起きた問題は2つの理由で最悪なものである。
- どうしようもないという気持ちに陥りがち
- 自然は我々に対して無関心で動機をもたないゆえに手に負えない問題を引き起こす
この問題はどこからきたのか？
という問いかけをすることで
問題を「自然」の領域から引き出して、建設的な思考と解決への行動、という領域に移すことができる。
著者らの経験によれば、問題が実は問題解決者自身に起因する割合は53.27%に及ぶ
「この問題はどこからきたのか？」を問いかけたとき、問題は「どこでもないところから来ている」可能性がある。正確にいえばそれは「その問題自体からきた問題」である。このようなどこでもないところから来ている問題を解決するためには、問題を出所に送り返す。
試験のような問題は背後に設計者がいて、むずかしいように設計されており、その問題解決はパズル解決となる。このような問題にどっぷりと浸かった者にとっては、自明な解答のほうが混乱させる場合がある。
われわれはそれをほんとうに解きたいか？
われわれはたいていの場合、何か問題を抱えていると感じている。
問題というのは人が望むところと、物事がどうなっているように見えるかとの差である
自分が問題を抱えていると知っているかどうかは感じかたの問題だが、何が問題かを知ることは別のことだ。何が問題かをわかっていれば解決するのは易しいが、分かっていると思っていても間違いのことがある。他人のために問題を解いてやるときは、たとえ計算機を駆使して問題を解いたとしても、その答えを知るまでそもそも何が問題かをわかっていないものだと認識しておくべきである。
ちょっと見たところと違って人々は、くれといったものをだしてやるまでは何がほしかったか知らぬものである
何がほしいか完全に知っていたとしても、問題はそれで終わりにはならない。時には問題のことを忘れてしまうのが最善の場合もある。
あとから調べてみれば本当に問題を解いてほしかった人はそんなにいないものだ
どんな問題であれ、本気で問題に手を付けようとする前に必ず発してみなければならない問いが
私はそれを本当に解きたいか？
である。解答が得られてみたらそれはちっともほしいものではなかったということもある。例えば問題解決者は、問題が解けたために失業するかもしれない。
魚、水を見ず
人は 順応する ものなので、問題について考える時、順応した物事は考慮から除外されやすい。問題解決者は他の関係者が無意識にその中で泳いでいる「水」をはじめから見ようと努力しなければならない。その水は問題が解けたとき、砂に変容するかもしれない。
まず汝自らに対して真実なれ。
問題解決は決して道徳的に中立の活動ではない。そのため問題解決者は問題を解く前から解答に至るまで、道徳的側面について考えてみる必要がある。
参考
【勉強会メモ】関西Node学園 3時限目
- 日時：2018/08/03 (金) 19:00 〜 21:30
- 場所：LINE KYOTOオフィス
今回も多種多様なテーマでどの発表もためになる内容でした。個人的にはpuppeteer、Serverless Frameworkあたりは気になってはいたものの手が出せていない領域だったので、具体的な活用方法が聞けたのはとても良かったです。
LINEの京都オフィスに初めて行ってきましたが、地下組織のアジトみたいなかっこいい雰囲気でした。
node-canvasでアニメーションGifをつくって遊ぶぞ！
kawasako3 さん
www.slideshare.net
- ガチャ演出みたいのがあるといい
- トークに時間軸のあるコンテンツをカジュアルに送りたい
ライブラリ
アニメーションを作る基本
- 最初に目標値を決める
- どのくらいの長さにするか決める
- フレーム毎に描画する
- 変化に緩急をつける
LINE Messaging API で動かす
⇒GifアニメーションがBOTから送れない
⇒mp4で作る
学び
- Photo movie 的なこともできそう
- ただし事前生成じゃないと厳しいかも
- Messaging APIではGifアニメは使えない
サンプル
N-APIとPromise
C++ Addons
C++連携
- 速度がほしい
- jsではできないOSの機能を呼び出したい
- 全てをjsで書きたい
実際に書いてみると全然わからん
- V8理解していないとよくわからない概念が多い
- V8に依存している
- v8バージョンアップのたびにビルドが必要
N-APIの登場
- わかりやすい
- 型がシンプル
- V8に依存しない
- 他のjsエンジンでも動く
- V8バージョンアップの旅にビルドしなくてもいい
- 10.0.0からstableになった
サンプル
N-API と Promise
何がしたいか
- 諸事情でLZW圧縮の亜種をnodeで扱う
- jsで組んでみるも遅い
- child_processも遅い
⇒N-APIで組んでみたが問題発生
基本的に同期的
- イベントループの中で実行
- 重い処理はイベントループを止める
async_work を使って非同期にする
- ExecuteCallback
- 非同期で実行
- イベントループの外で実行
- ここで重い処理
- イベントループの外なので
napi_hoge()関数を呼ぶと落ちる
- CompleteCallback
- Excuteが終わるとイベントループのキューで実行
- イベントループの中で実行
- jsにcallbackしたり戻り値を作る
非同期にするうえでの注意点
- C++上で変数のポインタを持っていてもjsの参照カウンタは増えません
- 自分で参照カウンタを増やしておく
N-APIのPromiseはそんなに難しくないので割愛
参考
LINEで馬券を購入する
@sbntaminif さん
馬券ネット購入サービス
※参考
LINEで馬券を買ってみたい
- 馬券を購入するアプリを作りたい
※日本語はところどころ間違いがあるので英語のほうがおすすめ
Headless Chromeとは
puppeteer
Chromeを自動で動かして馬券購入まで
しかしこのMacでしか使えない⇒このAPIをサーバで動かせるようにしたい
Lambdaで実行
AWS管理コンソールからしか使えない⇒API Gatewayから呼び出す
- タイムアウトが2分⇒メモリの制限？うまく動かない
- LambdaからLambdaをコール
どこからでもAPIを呼び出せる⇒ネットワーク経由ならAPIで馬券を購入可能
LINEでAPIを呼び出す⇒LINE Messaging APIを使う
⇒買えるようになったが送信のみ
応答メッセージ機能
- メッセージを送ったら1回だけ返却
- パラメータの中のユーザーIDを使う
- 自由にユーザーに送信するPush APIは有料
実践編
puppeteerでつまづいたこと
- 範囲外の要素クリック
- 画面外の要素のクリックが発火しない
- 画面を大きくする
waitの使い分け
- waitFor
- 指定した時間まで待つ
- waitForNavigation
- 引数なし
- waifForSelector
- セレクタで指定した要素の表示を待つ
アピール編
Hedless Chromeの魅力
Warning
- 常識的にやりすぎない範囲で
動画で強く話されていること
- この話はテスト自動化の話ではありません
- 自動化することができる
- 普段の作業を自動化する
これこそエンジニアリング⇒自動化やっていこう
AWS Serverless Express 入門
AWS Lambdaを使ってExpressを一瞬で公開する方法
@nkgrnkgr さん
テーマ：AWS Serverless Express
そもそもServerlessとは？
Serverless Platform
AWS Lambda
- pros
- cons
- 初回起動にやや時間がかかる
- デプロイできるファイルサイズが50MB
- 1リクエストあたりの最大実行時間が300秒
AWS Serverless Express
- LambdaとAPI Gatewayの上にExpressを使用してサーバレスアプリケーションとREST APIを実行できるAWS公式ライブラリ
- Express のMiddlewareに追加するだけでLambdaで実行可能になる
How to Use
npm installするだけawsServerlessExpress.proxyをかます
LambdaへのデプロイはServerless Frameworkを利用
npm installでインストール- serverless.ymlで設定
参考
ライブコーディング（省略）
