はつか日記

徒然なる日々に思うことを呟きます

技育祭参加レポート

どうもねづすけです。 名前がはつかやらねづすけやらブレますが、今後はねづすけで統一していきます。

さて、私は2020年7月4日から2日間に渡り開催された技育祭に参加してきました。 ウルトラスーパーデラックスなスピーカーの皆様にまんまと釣られてしまいましたが、釣られて大正解！ とても楽しいものとなりました。

最初に注意ですが、このレポートではそれぞれのトークを細かく紹介するスタイルは取りません。 アーカイブが一部残るようですし、他の方もレポートをあげると思いますので、詳しい話が知りたいよ！と言う方はそちらをご覧ください。 今回はこの技育祭で聞いた話について、私がどう感じたかをお話できればなと思います。

話を聞いて思ったこと

早速、本題について話して行こうと思います。 いろいろな方の話を聞いて1つ思ったのは、それぞれの話にある程度共通点がある、ということです。 強い人が似たことを言うのならば、それはおおよそ真理だと判断していいのではないでしょうか？ 大まかにまとめますと、以下のようなものになります。

  1. 意思決定を下すのは結局自分
  2. とりあえず手を動かせ
  3. 視野を広く持つ

これらについて、1つ1つ説明していこうと思います。

意思決定を下すのは結局自分

このことは、マスク・ド・アナライズさんやDMMの松本さんが直接的に言及していました。

「Q:どんな職場がおすすめですか？　A:自分で見つけろぉーー！」 by マスク・ド・アナライズ

「趣味と仕事のバランスは自分との対話で決める」by 松本さん

当たり前っちゃ当たり前、でもつい自分の中に人に甘えたい気持ちが芽生えてしまうんですよね。 しかし、それではダメだと今回の技育祭ではっきりと叩きつけられました。 確かに、他人が自分より自分について理解しているなんてあり得ないので、自分で決めるしかないんですよね。 そこに正解なんて存在せず、仮に趣味の方が大事だ！とそちらを優先したとしても間違いではありません。 ただし、そう決めたとしてもなるべくトレードオフを最適化するように密度をあげるようにした方がいいと仰っていました。 少し文脈は違いますが、Yahoo!の林さんも似たようなことを述べていました。

「技術的決断は自分が率先して決める。責任を負うことになるが、自分が主導権を握れる。」

主導権を握れば自分で仕事を生み出していく感覚を味わえるとの言葉に、はっと気づかされました。 自分の人生の主導権ぐらいは自分で握っておきたいものです。

とりあえず手を動かせ

手を動かすことの定義を広く捉え、ブログを書くことや毎日コードを読む・書くと言ったことも含めれば、 このことはほとんど全ての人が言っていたのではないでしょうか？ これも当たり前っちゃ当たり前。 しかし、できていないのが現実ですから、内省不可避です。 「何を作ったらいいのかわからん！」と言う問いには（おそらく）VOYAGE GROUPの小賀さんが答えていました。 （他の人の言葉だったらごめんなさい）

「開発していて気になったところや学校の課題を深掘りしてみる」

なんとなく、学校の課題と就活で使う成果は別物だと考える自分がいたため、目から鱗が落ちた気がしました。 一方で、肩をはりすぎるとダメだと小賀さんや宮原さんが仰っていました。 楽しく続けられるところをキープしていきたいですね。 ちなみにこの部分のことを小賀さんは「コンフォートゾーンの少し外側」と表現していました。 背伸びしたら届くぐらいのところをずっと続けることがモチベを長続きさせるポイントだそうです。

視野を広く持つ

これは特にマスク・ド・アナライズさんの話で印象に残っています。 この方は様々なIT系の職（外資系、スタートアップ、SI、事業会社…）のメリットとデメリットをリアルな体験談とともに 話してくださいました。 なかなかブラックな話も聞けて楽しかったです。 この講演を聞いて思ったことは、どんな職場にもメリットとデメリットがあり、 何が合うのかは人それぞれ。 最も自分のやりたいことと誤差の少ない場所を探すために、とにかく調べまくる必要があるということです。 どこか自分の中にイケてる会社に就職したいと言う考えがありましたが、 もう少し視野を広く持って考えるべきなのだと思いました。

その他には、DMMの松本さんは色々なことに挑戦してみて、手探りで自分の目標に近づいていく、と仰っていました。 そのためにも、ある一分野だけをずっとやるのではなく、たまに別の分野をやってみると新たな発見があるのかもしれません。

これからの行動改革宣言

そろそろ長くなってきたので、締めとしてこれからこのように行動を変えていくぞ！と宣言しておきます。 （宣言しないと甘えが出そう） そこ！くさいって言わない！

  • ブログなどで情報発信を行う
    • そのために、Notionを使って自分のページを公開しました。普段からメモがわりに使っているアプリなので、軽い気持ちで続けられるのではないか作戦です。
  • とことん楽しむ
    • 長く続けられるように、また、この業界が嫌にならないように楽しみながら技術研鑽をやって行こうと思います。
  • 効率をあげる努力をする
    • 技術研鑽や趣味をより充実させるために、作業効率をあげる努力をしようと思います。

最後に、今回の技育祭はとても楽しいものでした。 このレポートで紹介したのは、ほんの一部だけです。 しかも、どれも当然やん！と言われそうな内容です。 しかし、私が実際できていないことは事実ですし、何しろ様々な経験を積んできた人から発せられるその言葉はとても重く、説得力に溢れていました。 当たり前のことからコツコツと続けて、いずれは発表する側になれたらいいななんて思いつつ、このレポートは締めさせていただきます。 長文駄文、お付き合いいただきありがとうございます。 面白いと思った方はいいね・共有をしていただけるとねづすけが泣いて飛び跳ねます。 改めて、ありがとうございました！

UI設計をするときに考えること

とりあえず、現在（6月3日）時点での思考メモ。
アプリのUI設計をするときに考えることをつらつら書いていきます。

ユーザシナリオを考える

  • 誰が使うのかを考える
  • ユーザがアプリを開くときの理由を考える
  • そのとき本当にユーザがしたいことは何か

その時、なるべく具体的に書く。
案外、「開く時の理由≠本当にユーザがしたいこと」だったりする。
（いい例えは思いつかなかったので、思いついたら追記する）

おそらく、膨大に出てくると思うから、頻度であったり重要性で優先順位をつける。
例えば、SNSアプリで「一番最初に誰かを友達登録する」という事象は、そのアプリを使う中で一回しかないけど、使いにくさを感じてアンインストールされてしまう可能性を考えると、優先順位はかなり高い。

サイトマップを作る

さっき考えたユーザシナリオを元に、より優先順位の高い機能は少ないタップ数で、目的の機能に到達できるようにする。
しかし、正直これは後の工程で100％こっちの方がいいとなるので、あまり気合を入れて作り込む必要はない。
一方で、何も考えなしに作ると、やり直しになる可能性があるので考えられることはなるべく解決しておくべきかもしれない。

ワイヤーを引く

サイトマップをもとに、簡単に画面を作っていく。
ただし、基本的にモノクロで、色は使わない。
押せるところは角丸四角で囲う、画像は背景にグレーを載せる、といったマイルールを一貫しておくとミスはない。
最初にそのページに置きたいボタンや情報をすべて書いておくのが吉（忘れる可能性があるので）。
ここで、必要な部品を書き忘れると、最もやり直しコストの高いデザイン段階に影響が出てくる。
ここでもユーザシナリオを強く意識する。
部品を置くメリットとデメリットを考えながら取捨選択する。
わからなくなったら、似たようなことをしているアプリをめっちゃ探して、なんでそのアプリはこうしたのかを研究する。
正直ここがめっちゃ辛い。
自分だけで考えても、バイアスのかかったUIになっちゃうので、人に見てもらうことが重要。
まぁ答えはないので、思い切って決めちゃう度胸も必要。
データで補強された根拠があればなおよし。

デザイン

今回はパス。また書くかも。書かないかも。

[git]一つ前に作業していたブランチに戻りたい

git

便利なtipsを発見したのでメモ

あるブランチで作業している最中に、リベースするためにmasterにcheckout&pullした後、また作業していたブランチに戻りたい時がたまにある。

わざわざ"git checkout 作業ブランチ名"と打たなくても次のコマンドを打てば良い

 

git checkout -

 

lisingが日本語でエラーが起きる！

tex

状況

linstingsとjlistingをそれぞれインストールしたあと、ソースコードを入れようとするとなぜかエラーが…

! Improper alphabetic constant.
<to be read again>
\@empty
l.37   󿿿ア
            󿿿イ󿿿ウ󿿿エ󿿿オ
?

アルファベットじゃないよ！って

ちゃんと\usepackageにもlistingsもjlistingも書いてるのに…

と詰まっていました

解決策

usepackageにも順番が必要なんですね

\usepackage{jlisting}
\usepackage{listings}

の順番でpackageをインポートしたら通りました…

単純な場所でのエラーだったので気付きにくかったです

TexLive2018で自前パッケージをインストールする(Mac)

tex Mac TeXLive2018

何をしたいのか

題名の通りサイトから直接ダウンロードしてきたり、自前で作ったstyファイルをどこからでも参照できるようインストールしたい。

結論

/Users/<i>username</i>/Library/texmf/tex/latexフォルダの中にインストールしたいstyファイルを入れる。
(.../latex/packagename/package.styという形にしても構わない)

もしフォルダがなければ作成する。（僕はtexmfフォルダ以下を作成した）

その後

sudo mktexlsr

をかける。

そして

kpsewhich xxx.sty(インストールした.styファイル)

を叩いて、先ほど置いた場所のパスが出てこればインストール成功

解説

texはパッケージがどこにあるのかというのを管理するためにls-Rというファイルを使う。

そこには、どこになんというパッケージが置かれてあるのかということが記録されてある。

しかし、予めどこに置くかというのは決まっていて、/Users/kousuke/Library/texmf/tex/latexはその一つであるらしい。

そこにファイルをおいたあと、mktexlsr(make tex ls-R)を叩くことでls-Rが更新され、どこからでもそのパッケージを参照することができる。

疑問

あらかじめ置く場所ってなんらかの方法で調べられるんだろう

参考

Installing Packages - LaTeX - LibGuides at University of Akron

AbemaTV DEVEROPER Conference2018に行ってきた

お断り

本番中PCを持って行くことを完全に失念していたため、書いていることはメモ書きレベル&穴だらけです。
後日abemaTVさんの方からパワポ資料と発表動画がだされるそうなので、ちゃんとした内容が知りたい方はそちらをご覧ください。

1st "AbemaTVのエンジニア組織論と今後の技術戦略"

  • abamaTVの今昔
  • ユーザは右肩上がり
  • 企業としても右肩上がり
    • エンジニア1000人越え
    • ヒューマンマネージネントが大変
    • なんかのシステム名を言っていたけど忘れた(後日のスライドで確認) 　- エンジニアを7段階ぐらいにレベル分け
      • 報酬レンジに反映
    • 各自目標を立て誰もが見れる状態に
      • 実力が上の人や同期の目標を見てモチベに

2nd "「72時間ホンネテレビ」の負荷対策とその裏側""

  • とりあえずインフラエンジニアすごい
  • 亀田興毅に勝ったら1000万円で大きなサーバダウン
  • 年末特番に向けて負荷対策が必要
  • しかし1ヶ月前になって「72時間ホンネテレビ」があることが判明
  • 時間的リソースがなくなる
  • とりあえずリクエストが発生している部分を徹底的に洗い出す
    • CDNがうまく活用できていない
    • コメント・プレイリストのリクエストが異常に多かった
  • akamai(CDNサービス)
  • できるだけオリジンにたどり着くリクエストを減らす
  • その結果リクエストは大きく削減
  • 72時間ホンネテレビは無事成功

3rd"AbemaTVのアーキテクチャの変遷"

ここは専門用語の洪水でよく覚えていません。すみません...

  • 撮影から視聴まで大量のプロセス
  • SPOT配信やリアルタイム配信にも対応
  • そのときそのときで最善のアーキテクチャを選択

4th "AbemaTVのオリジン監視システム「Procyon」"

  • オリジンの異常を検知するシステムが必要
  • 独自で制作
  • 拡張が容易であることがマスト
  • 本システム側で細かなモジュールから設定を組み上げられる
  • それを受けてProcyon内でmanagerがそれぞれのモジュールを実行
  • 返ってきたエラーの最悪値(green,yellow,red)をそのサービスの状態として記録
  • 通知機能とログ機能も

5th "Kubernetes Jobによるバッチシステムのリソース最適化"

  • 動画をたくさんの形式に変換する必要がある
  • エンコーディングに時間を割きたくない
  • そのために並列処理を導入する
  • 4つぐらいの技術を比較していたが、詳しい名前は忘れてしまった
  • 技術1
    • キューとタスクを入れるサーバ(特別な名前があったけど思い出せない)がいくつか
    • タスクをキューに入れると手が空いたサーバから処理していく
    • メリットは拡張がしやすいこと、デメリットが思い出せない～～～
  • 技術2
    • 何かのサービスだった気がする…
    • タスクそれぞれに最小値と最大値を割り当てる
    • それによってリソースを柔軟に組み合わせて実行することができる
    • しかし最大値を超えてしまうとタスクから追い出されるリスクがある
    • そうなると一からやり直し。それは避けたい
  • 技術3
    • キューのラインを増やした方式
    • 重いタスクをするキューと軽いタスクをするキューで分けて処理する。
    • 技術2のような追い出されるリスクがなくてすむ
    • 複雑怪奇になりやすい
  • 技術4(採用)
    • Kubernetesを使う方法
    • Jobと呼ばれる単位で処理を行う
    • 難しいのは並列処理の次のタスクに進むにあたって、その処理がすべて終わったと確認すること
    • Jobの管理をするJobを作って対処

6th "AbemaTVにおける推薦システム"

  • 推薦システムはAbema videoで活躍
  • 膨大な件数の中から短時間で高精度のランキングが得たい
  • 粗いアルゴリズムと高精度なアルゴリズムを組み合わせる
  • まず粗いアルゴリズムでユーザの好みに合致しそうなものをざっとランキング
  • 次に高精度なアルゴリズムでリランキング
  • これから更に高精度にしていきたい

7th "通信節約モードの品質確定プロセス"

  • 従来の通信量を50%に抑えた通信節約モード
  • abemaTV初期の横画面しかなかったところから縦画面にも対応させようとしたところで企画がスタート
  • 時間的要素(音声サンプルレート、フレームレートなど)は変えられない
  • 変えるなら画素数
  • ただし品質は維持したい
  • 様々な画素数×様々な端末×複数の検査項目と大量の項目でどこがベストかを探っていく
  • 明らかに品質が変わる部分を発見
  • そこが通信節約モードで用いるもの

Final "世界の動画技術動向を見据えたAbemaTVの向かう先"

  • エモイタイトル
  • 動画配信の最新技術をキャッチアップしてくるエバンジェリスト
  • 自分達はまだまだ後発
  • 困ったことは世界に補ってもらおう
  • 世界各地のカンファレンスに参加
  • 欧米での地上波放送からデジタル配信に移る動き
  • それを牽引する標準規格団体
  • 揺れ動く次期デファクトスタンダード規格(規格名は忘れてしまいました…)
  • まだabemaTVは基礎を固める段階

まとめ

実は外部カンファレンスというモノはこれがほぼ初めてだったのですが、PCを持って行けばよかったという自責の念にとんでもなく苛まれています。
記事を見ても分かるように結構穴が出来てしまいました...
後日スライドと発表動画が公開されるそうなのでそれを待つしかないですね！
しかしPCを持って行かなかったからと言って得られたモノがなかったわけではありません。
むしろ数え切れないほどあったと想います。
普段あんまり関わることのないインフラエンジニアの世界、長年世間を支えてきたテレビの品質に負けぬようなプロダクトを作る工夫と努力、
そして何よりabemaTVの人を始め沢山の人と出会いお話できたのはとてつもない成果だと思います。
こういう機会を設けてくださったabemaTVの皆さん、本当にありがとうございました！とても楽しかったです！！
またこういうイベントがあったら行きたいなぁ…
何かいいイベント知ってたら教えてください！

初心者のためのgit

git 初心者向け

 

 とあるプロジェクトをするためにgitのコマンドの説明をする必要があったためまとめてみました。

おおまかに

そもそもgitというのはファイルの変更を保存するためのアプリケーションです。

まず仕組みとしてはリモートとローカルに分かれています。

  • リモート：オンラインで保存する場所。ほかの人も見れる。
  • ローカル：自分のパソコンの中。ほかの人見れない。

また開発者はブランチなるものを使って開発します。

ブランチとは履歴の流れを分岐して記録していくためのものです。

ブランチとは【ブランチ】 | サルでもわかるGit入門 〜バージョン管理を使いこなそう〜 | どこでもプロジェクト管理バックログ

そんでもっておおまかには4つのコマンド+αさえ覚えればgitを使えると思っています。

  • checkout：ブランチを変更するコマンド
  • add：変更を記録する・しないを選択するコマンド。
  • commit：変更を記録するコマンド。
  • push：変更をリモートにあげるコマンド。
  • +α：後で説明します。

基本的にファイル変更→add→commit→pushという順に実行していけばなんとかなると思っています。

今回はそれらを使用頻度順に並べて紹介していきたいと思います。

★★★必須コマンド

checkout

ブランチを変更するコマンド。

具体的な使い方としては

git checkout [行きたいブランチ名]

とか

git checkout -b [新しく作るブランチ名]

後者のコマンドは新しくブランチを作る＆そのブランチに移動するという合わせ技です。

そのほかにもブランチ名の代わりにファイル名を付けると、そのファイルを最終コミット時まで戻すことができます。（これは取扱注意コマンド）

add

ファイルの変更を記録するで～というのを宣言するコマンド。

使い方としては

git add [ファイル名]

とか

git add -p

とか。

後者はすごい便利で変更があった場所を個別にあげるかあげないかきいてくれる。

これについてはちょっと面白いのでまた別にブログをあげようかなと思ってます。

これさえ覚えとけ！といっても過言じゃない。

逆にだめな使い方としては

git add -A

とか。

これは変更を全部記録するっていうコマンドで、バグも動作が不安なとこも全部ごったまぜで入れてしまうから禁忌。タブー。

commit

addで宣言したファイルの変更を記録するコマンド。主な使い方としては

git commit -m "[メッセージ]"

です。

メッセージは必須ですよ！

慣れてきたらamendオプションで一つ前にコミットした分について追加し忘れたファイルをコミットするとかコミットメッセージ書き換えるとかできます。

push

commitで作ったファイルの変更の記録をリモートにあげるコマンド。

これはミスるとなかなかややこしくなるのでやや取り扱い注意。

fオプションで強制的に変更したりできるけど、こんなのしかたないとき以外絶対使っちゃだめよ（使わざるを得ないときはいくつかあります。）

主な使い方はこんな感じ。

git push origin [ブランチ名]

★★☆時々使うコマンド

clone

一番最初にしか使わないコマンド。

git clone [リポジトリのURL]

status

現在の状態(変更があったファイルとか未プッシュのコミットがあるなど)を知るためのコマンド

git status

remote add

フォークしたリポジトリの変更を知る時などに使います。

フォークをしたリポジトリというのは本家のリポジトリとは別物になってしまいます。

なのでこのコマンドでその変更内容を知れるようにします。

以下は本家リポジトリとupstreamという名前で登録しているコマンド。

git remote add upstream [本家リポジトリのURL]

reset

間違えてaddしてしまったファイルとかを取り下げるコマンド。

他にもこのコミットまで戻したい！とかいろんな隠蔽ができるコマンド。

ミスると努力の結晶が消えてしまって取り消せなくなることもあるのでやや取り扱い注意。

git reset [取り下げたいファイル名]

branch

ブランチを確認するコマンド。

使用頻度は高めだけど覚える数を最低限にするために星二つ。

以下のコマンドでローカルにあるブランチを参照でき、aオプションではリモートも合わせてすべてのブランチを参照できる。

git branch

pull

リモートの変更を反映させるコマンド。

git pull origin [ブランチ名]

で、変更が取り込める。

取り扱いには注意。

merge

別のブランチの変更を取り込むコマンド。

ちょっと危険なので取り扱いは注意。

git merge [取り込みたいブランチ]

log

地味に重要コマンド。

resetでこのコミットまで戻したい！というときとかにコミット番号というものを知るために使ったりする。

git log

★☆☆覚えていれば便利なコマンド

列挙していくので細かい使い方は気になったときに調べてください。

diff

差分を確認する。

rebase

mergeとは違う変更取り込みコマンド。

詳しいことは割愛しますが、mergeより履歴がキレイに取り込めます。

その分少し手順は複雑です。

また間違えたとき修正が難しいので賛否両論あったり

fetch

リモートの変更状況が知りたいけれど、ローカルには反映したくないなぁって時に使います。

stash

作業中に別のブランチに変更したいときなど、作業状況を保存しておきたい時に使う。

最後に

色々駆け足でおおかたのコマンド説明をしました。

ただここ書いたものは最低限の最低限だと思ってください。

ちょっと難しいけどすごい便利なコマンドとかたくさんあります。

この記事でgitの勉強の踏み台になればいいなと思います。

P.S. たぶんmergeとかrebaseとかfetch、pullの違いがよく伝わっていないと思うのでもしかしたらまた記事を書くかもしれません。