MANABIYA -teratail DEVELOPER DAYS- 2日目に参加してきました

勉強会メモ
IoT / キャリア / フロントエンド / JavaScript

昨日に引き続き参加してきました。 MANABIYA -teratail DEVELOPER DAYS- 2日目 のメモ取りの記録です。

↓ちなみに昨日のメモです

参加したセッション

  • IoT: エンジニアのIoTへの関わり方
  • 基調講演: エンジニアのための自分経営戦略
  • 生存戦略: 技術顧問/テクニカルアドバイザーとしての生存戦略
  • Web: CrossSession

色々セッション聞いての雑感

  • IoT開発におけるセキュリティ意識は業界的にまだまだ未熟な印象
  • 自分経営戦略に関して(西尾さんのセッションめっっっっっっっちゃ面白かった)
    • 自分がリソースを投資して得たいと思うものはなんなのだろうか。自分はどういう価値観で行動しているかに自覚的になろう。
    • 「まずは与える側になろう」
      • 自分が与えることができるものには何があるだろうか？洗い出しておこうと思う。
  • 「技術顧問」って目指してなるものではないよね、という話に関して
    • 自分の考えとして1つの会社に依存して生きるのが危険というものがある。それではどういうワークスタイルになるだろうと考えた時、近年の技術顧問ブームが頭にありなんとなくそういう仕事でも稼いでいく感じになるのかなと考えていたのだが、よく考えてみると、確かに自分からなりたいと思ってなるものとはちょっと違うような気がした。
  • Webフロントエンドって改めてしんどい世界だなと(小並感)

以下、聴講メモです。 (ちなみに、「生存戦略: 技術顧問/テクニカルアドバイザーとしての生存戦略」については「パネラーの方々が気兼ねなくしゃべれるようにSNS拡散等はお控えください」とのことだったので公開せずに眠らせておきます)

IoT: エンジニアのIoTへの関わり方

  • 登壇者
    • GMOインターネット 新里さん @hirotakaster
  • IoTってなに
    • 色々繋がる
    • 利用形態
      • データの見える化(温度とか、湿度とか)
      • 動作制御(ロボットアームの制御とか、光・モーター制御とか)
      • フィードバック・自動最適化(スマートスピーカー・防犯・見守り等)
    • 接続形態は？
      • 直接接続(ネットから直接)
      • ゲートウェイ(Bluetooth,LPWA等)
  • 学ぶ、作る環境
    • Web系とハードは世界が異なるが、IoTサービスの開発にあたっては両方のノウハウが必要
    • まずは触ったり・使ったりしてみるところから始めよう
      • Arduino UNO,ESP32とか
        • 基本はC/C++での開発
      • Raspberry Pi
        • ネット系開発者がよく利用するLinuxで開発できる
      • mbed(micro:bit nucleo)
        • 基本はC/C++での開発
      • その他使うもの
        • 各種電子工作用品類
    • Web系と比べると
      • 端末やパーツ等現物への初期投資が必要
      • Web系ノウハウがあまり生きない
      • パーツ多い
      • デバッグつらい
    • アプリリリースまで
      • iOSのアプリのリリースの際には、審査に現物等の追加の資料の準備が必要
    • 生存戦略的な話をすると、Web系とハード系両方の知識持っているとだいぶ強いと思う
  • MQTTなるもの
    • IBMが公開したPub/Subのプロトコル
    • IoT文脈ではよく出てくる
    • TLSを使っていてもMQTT Brokerの怖い話
      • Security脆弱な使い方をしている人が多い
        • 某組織が流しているデータ見えているぞ！
        • 他にも海外のフライト航路データが垂れ流しになっている例も…。
        • エジプトのスマートホームのデータが見れちゃってたり。
      • セキュリティ意識はしっかり！！！

基調講演: エンジニアのための自分経営戦略

  • 登壇者
    • サイボウズ・ラボ 西尾さん
      • ビープラウド技術顧問
      • 未踏 の理事
      • コーディングを支える技術著者
  • ただのエンジニアだった西尾さんは7年前に経営学の知識を社会人大学院生として学んだのが大きなきっかけで様々な仕事を手掛けるように
  • 最初の一歩を踏み出すための話が今日のコンテンツ
  • 新しいドメインを学んだほうがいいとはいってもどうすればいいのか、ハードルが高い
    • きこりのたとえ
      • のこぎりを動かし続けるのではなく、長期的な効果を考えてのこぎりを研いだらよい
    • とはいっても、将来実を結ぶか分からないものに対する不安感
      • そこで、うまくいかなかったときの損失が最小になるように動こう(損失額x時間の最小化)
  • 経営戦略
    • 限られたリソースを何に配分するかを決めていかなければいけない
    • 今回の話は法人の経営戦略ではなく、個人の経営戦略
  • エンジニアのための自分経営戦略
    • 列挙を見たら、「これで全部か」を疑う
  • リソース配分の末に何をしたいのか
    • 「何を得たいか」は経営者(自分自身)が決める
    • 収益、競争力、従業員(自分)満足度
    • 何を求める？
      • あなたは少なくともこの講演で知識に得ることに価値を感じている。そのような投資戦略を取っている。
      • 他に、自分がどのような価値感を元に判断をしているかに自覚的になろう。
      • ちなみに、知識獲得に投資するという判断は筋が良い
        • お金は使うとなくなるが、知識は使ってもなくならない
  • 知識獲得戦略
    • 3タイプ
      • 教えてもらう
        • (学校的なもの、教師に負荷が集中)
      • 自分で行動する
        • 行動の結果どうなったかのフィードバックを得て学ぶ
          • PDCA,リーンスタートアップ、プログラム書いて実行的な
      • 知識交換のネットワークを作る
        • お互いが教え合う
        • 知識が少ない人からでも学ぶことができる
        • これが成立するのは、知識領域がオーバーラップしていない場合
        • 「狭き門から入れ」大勢が学んでいるものに投資しても競争優位につながりにくい
        • 社外に知識交換できる相手を作ろう
          • 勉強会は十分ではない
          • 提案
            • 小さい非公式グループを作りあなたが発信者になる
  • 小さい非公式グループを作る
    • 大きいグループだと、お互いの状況理解がしづらく、知識交換コストが高い
    • 小さいグループを作るための有効な方法は、ゲートを置く(入ってくる人を限定する)
      • フリーライダーの発生を防ぐ
  • 自分でグループを作る
    • 誰かが作ったグループが、自分が入ることができる状態である可能性は小さい
  • まずは与える側に回ろう
  • 複数のグループに所属しよう
    • 自分が知識が流れるパイプになれる
    • 仲介による価値の創出
  • 「専門性をもつのがよい」といわれるが
    • ググっても入手できない情報を持っていさえすればOK
    • それであればまだハードル下がる
    • ただ、いずれググれる情報になっていくので、追いつかれないように自分の中に情報をインプットし続けなければいけない
  • 思い出しトリガー

生存戦略: 技術顧問/テクニカルアドバイザーとしての生存戦略

(「パネラーの方々が気兼ねなくしゃべれるようにSNS拡散等はお控えください」とのことだったので公開せずに眠らせておきます)

Web: CrossSession

  • 登壇者
    • モデレータ
      • リクルートテクノロジーズ 古川さん @yosuke_furukawa
    • パネラー
      • メルカリ 泉水さん @1000ch
      • Kaizen Platform 稲富さん @laco2net
      • CUUSOO SYSTEM 川口さん @kazu_pon
  • 仕事でどんな感じのアプリケーション作ってますか的な
    • 川口さん 本当はフルSPA作りたいが、実際は部分的なSPAになっている
    • 泉水さん
      • SSR + SPA
      • フルでSPAしてる
    • 稲富さん
      • SSRはしてない。AngularでフルSPAしてる
  • Router
    • Reactの公式Routerがバージョンごとに変わりすぎてツライ
    • Vue,Angularの公式のRouterライブラリにはそこまでのツラミはない
  • SPA苦労話
    • backしたときにスクロール位置が回帰しない問題
      • note.muとかで見られる問題
      • Vue使ってたらうまくやってくれる
    • Service Workerのキャッシュがパージされてなくてアプリケーションの旧バージョンが見られていた問題
      • Service Workerが更新された場合の処理はブラウザが標準対応してほしいところ
    • 状態管理
      • JSの状態とページの状態の同期が戻る進むで崩れたり
    • input type=“file” が確認画面から戻られた時になくなる問題
      • 事前にサーバサイドにアップロードさせるとかしておかないと、クライアントサイドだけでは対応できない
  • JS疲弊の実感ある？
    • OSSメンテナの観点からすると、バンドルツールで新しいものが出てきたときの対応がしんどい。parcel,FuseBox,…(稲富さん)
      • Vue.jsは今はflowtype,TypeScript両方使えるが、中身に関してはflowtype。だが、メンテナ充実なのはTypeScript
    • FirefoxでShadowDOM速く実装されてほしい(稲富さん)
    • (Custom Elementsの文脈で)FirefoxのためにPolyfill入れるみたいな感じになってる
    • webpack嫌だなあ(泉水さん)
    • CSS in JSが一般的になっているが、それにはあまりしっくりきてない(泉水さん)
    • ツールに振り回されすぎ問題(古川さん)
      • storybooks,react-docgenとflowtypeのかみ合わせの動作が追い切れない(古川さん)
  • 今後のWeb標準で期待したいことはありますか
    • WebAssembly(川口さん)
    • DOMChangeList(稲富さん)
      • 現状は自分でDOMまわりを再実装している感があるので大変。
    • VircualDOMがやっていることを標準でやってほしい(泉水さん)
  • 締め
    • 今後のAngular
      • SPAとしてのAngularは完成しているので、いかに軽量化するか
      • SPA以外のところでのユースケースを増やす
    • 今後のVue
      • Webの複雑なものを簡単に実現できることをミッションとして今後もやっていく
    • 今後のWeb標準
      • Service Worker,Web Components,Web Paymentsの普及が進んで欲しい
    • 古川さん
      • それぞれのフレームワークでの開発の方法論が揃ってきたので、今後は如何にそれを使ってサービスを差別化できるかどうか
      • パフォーマンスとかWeb標準に強い人を育てていけるかどうかが鍵