261

IT系のカンファレンスに参加した話など

Droidkaigi公式アプリにコントリビュートした

正直easyタグなので書くほどか?という感じなんだけど、 書くほどだよ!

Droidkaigiは1回目から参加して公式アプリが2回目から?作られて、githubで公開されていたのでいつかコントリビュートしたい!と思っていたけど、毎回なぜかビルドが通らないし 通ってもissueが難しくて手を出せていなかった。 それが今回はeasyのタグ付きとは言えコントリビュートできたので大変うれしい。3年越しだ。

今回はeasyタグだったが、次はeasyがついていないissueに挑戦したい。 というか、挑戦したけどassingして間に合わなかったら?とか考えて手を上げないまま実装してPR出そうかと思ったらassingされててやめたってのが2,3あった。 今思えばエイヤで手を上げるべきだった・・・ (週末なら時間とれるけどいいですかって聞いているひととかいたし) Droidkaigiまであと少しなのであとはソース読んだり、どのセッションを見るか考えて過ごすとします。

生産性を上げるための施策を考えた

とある弊社の生産性向上について考えたこと。 結果は推して知るべし

 生産性向上についての施策

  • SESをやめて受託メインにする
    • SESは生産性をあげるメリットがない
  • 給料の残業代見込みをやめる  - 残業するのも良しとしてしまう文化になる
  • 残業代が10時間未満ならボーナス

    • 残業するのは効率が悪くなる最大の要因
      • スケジュールを作成しても、残業すればなんとかなると考える
        • これでは生産性があがるわけがない
    • 参考
    • 部内の最長残業時間が30時間未満を達成すると1万円
    • 部内の平均残業時間が10時間未満であれば2万円が加算
    • 最大で月5万円の計算
      • 半年に一回ボーナスの度にまとめて支給
      • 勤務時間の不正申告:過多/少問わず、本人及びその管理者が罰則の対象
  • 低スペックPCを購入しない(最低メモリ16G〜

  • マルチモニター必須
    • (低解像度のモニターは利用しない、フルHDレベルが望ましい

自己組織化した組織を目指す

  • 自己組織化することで各自の最良の判断ができるようになるとおもう。そうでないなら上長などの存在が足を引っ張るとおもう・・・

有給

  • 入社初日から20日取れるようにする
    • これはよその会社の優秀な人材に来てもらえるように   - 他社がやらないことを提案してみた

退職者の引き止めをやめる

  • なんでも採用にコストが掛かってるからやめるように説得するそう。。。
    • 給料が上がるような説得はしないらしい。
    • これはやめてほしい
    • つまり、やめる人材があそこは嫌な会社だという印象を持つ
    • 別の会社に入ったあとあそこは酷いなどと言われる
      • 優秀な人が来なくなるようになる

技術力の向上

  • 自社製のライブラリの作成、もしくはOSSへコントリビュートすることを推奨する
    • 社外の人にも目につくようにすることで、会社の価値をあげて優秀な人材に来てもらいやすくなる。
    • 優秀な人材が多いほうが生産性をあげられるため

新卒さんに本をプレゼントするときに考えたこと

2018卒の新人と一緒に仕事していて、クリスマスプレゼントってことで技術書をあげました。

彼は技術とかに興味を持っていてアプリを作ったりサービスを作ったりハッカソンに参加したりしていてアプリレイヤーについては自分でどんどん学ぶから、それ以外のことで彼が巡り合わないような本を選んでみました。

この本はIotとか始めようとか電子工作始めようってひとにはおすすめしたい本。 手取り足取り教えてくれるわけじゃないんだけど、逆にそれがいい。 電子工作でもプログラミングでも手を動かして何がどうなっているのかを自分で理解するのが一番楽しいとおもうので。

www.amazon.co.jp

CICD TestNightに行ってきた

CICD TestNightに参加した

CICDのハマりポイントとかあるあるとかを聞けることを期待して参加したが、今回はbitriseはいいぞ!という回だった。 CTOが来日してbitriseでこんなこともあんなこともできて、どれもOSSで作っているとのこと。 それと日本のコミュニティを大事にする〜のような話をしていた。多分(翻訳イヤホンは借りられなかったけど大体そのようなはず・・・)

あとはLT大会で、iOSのビルド自動化は手組みは辛いからサービスを使うべき、とか自動化することはたとえbuildだけでも履歴、再現性の意味がある。といった発表があった。

今の案件で自動化は buildしか利用できなさそうで意味あるかなと思っていただけにこの言葉を聞けたのは良かった。 できれば発表であったチャットボットみたいなものを利用したい

技術書典5にいってきた。次は本だしてみたい

最後のほうにちょろっと参加しただけだったけど面白かった。 見たことのない情報に触れられるのがこういうところへ参加する意義だと思う。自作キーボードにちっちゃいハンドスピナーつけてたりとか、法律の話とか ただ、欲しかったメルカリの本は売り切れてた

なので次は自分も本を出したい。紙でなくてもいいみたいなので PDFで。

内容はurlにアドレスを入力してenterキーを押してからbrowserに表示するまでの道筋

実際わかっていないのでは?と思って とりあえず書く内容の概要をざっと書き出してみた

  • ブラウザの url入力フィールドにurlを入力し、 enterを押す!
  • エンターの信号がキーボードからusbをとおして
  • ドライバがenterの値に変換
  • enterの入力がOSからchromeに伝わる(よくわかってなさすぎ)
  • url入力フィールドに入力があることを検知?
  • 入力文字を取得
  • 入力文字をパースする
  • プロトコルを判定(https, httpで判断?)
  • ipなのか文字(なんていうんだっけ->domain名)を判定
  • urlをdnsに問い合わせ
  • 問い合わせまでになにすんだろわからん
    • dnsって下からだっけ?
    • dnsに答えが帰るまで問い合わせ
    • dnsってツリー?
  • パケット作成、ドメイン名を乗せる
  • 名前解決したらipaddressを保持
  • dnsからipに変換し、 ipをパケットに分割
    • ethに送るまでってだれが担当する?OS? Driver?
  • ethを通ってサーバにリクエストを投げる
  • 帰ってきたレスポンスをうける
  • ボディを取得
  • ボディのパース
  • htmlをchromeのパーサに渡す
  • chromeでパーサからごにょる
  • chromeのレンダから出力

まったくわかってないことがわかったので まずはreal world httpを読んでみよう

想定している環境 OS linux ブラウザ chrome

Backlogの運用で行ったこと

Backlogでなるべく課題は担当者が管理してまわせるように しようと思った際に決めたこと

  • WBSに沿って課題を設定する
  • 担当者は設定したら基本的に変更しない
  • レビュワーを決めたらWikiに書いておく
  • 状態遷移の条件を決めたらWikiに書いておく
  • 仕様はWikiに書いておく
  • 子課題の設定は親課題担当者に任せる
  • 状態の変更は課題の担当者に任せる
  • gitのリポジトリは開発用、sandbox, stubを用意した

解説

WBSに沿って課題を設定する

ベースとなる課題はWBSに沿って作成し、 細かい課題は子課題として設定する方針にした。

担当者は設定したら基本的に変更しない

レビューするときにレビュワーを担当者に変更するというようなことはしない  あとは回答してほしいひとに担当者を変更するとかもしない。  ああいうことはチャットツールとか使ってやったほうが  早いと思わないのだろうか・・・・

レビュワーを決めたらWikiに書いておく

 忘れてしまうので

状態遷移の条件を決めたらWikiに書いておく

レビュー依頼したら処理済みに変更するなど  忘れてしまうので

仕様はWikiに書いておく

 忘れてしまうので  wordやらで管理は嫌なのでwikiに書くようにした  課題と紐づけたりできると便利なのになぁ 出来るらしい   https://backlog.com/ja/help/usersguide/markdown/userguide1760/#

子課題の設定は親課題担当者に任せる

 基本的な方針

 そうすることでリーダーが管理しなくて良くなる  

状態の変更は課題の担当者に任せる

 基本的な方針で、

 そうすることでリーダーが管理しなくて良くなる

gitのリポジトリは開発用、sandbox, stubを用意した

 開発用はいいとして、sandboxでアーキテクチャの検討や、gitに慣れていない人用  などの遊び場として用意した  stubはstubを用意する場所がほしかったくらいの理由