参加記録 ABC104

最近のABCは難し過ぎる． ABしか解けなかったけど，これでレート上がるんだから皆解けなかったのだろう．

AB解いて300(10:38), 576th 956 -> 990(+34), パフォーマンス1214

B - AcCepted

正規表現で解けるかな，なんてことは一切考えず愚直に実装した．

'A', 'C'の文字が含まれている位置の確認はともかく， それ以外の文字が小文字であることの確認処理の実装があまり上手くなかった． 'A', 'C'が含まれていることを確認済なので，全文字列の大文字数をカウントする想定実装がシンプルだが 'C'の位置候補でループ処理することしか考えていなかったので 文字列全体のループを別途作る？とか考えていた．

結局提出したのは，'C'の位置だけ記録して，元の文字列全体を小文字化した上で 'A','C'だけ大文字に変換して元の文字列と一致するか確認する方法． 実装直後に想像以上に汚い実装になったので悩んだけれど 結果は正しそうなのでさっさと提出してしまった．

C - All Green

解説の「中途半端に解く配点は1種類以下であり、それ以外の配点は完全に解くかまったく解かない」が全てだと思う． これに気付けなかったので全探索を諦めてしまったし，最後DPで解こうか悩んだ上で実装できなかった． 考えてみれば上記方針はあたりまえなのでこれは気付きたかった．

実装面ではビット操作による全探索に苦手意識があるのと， 完全に解く問題が与えられた上で，残りスコアを中途半端に解く場合に何問解けばいいかを

int need = (G - s + s1 - 1) / s1;

とコンテスト中にさらっと実装するのは無理だったかな，と感じた． どちらもわかっていれば大した事ではないのでしっかりと復習しておく．

D - We Love ABC

方針はCより簡単だった． DPを利用すること，処理した文字列の位置と処理状況を利用すること は比較的早く気付けたが，その後の実装が上手くいかなかった．

解説のように漸化式を上手く構築できればいいけど， 今回のような少し複雑な式になると，まだまだ解けそうにない． このあたりの感覚はもっと多くのDPを解いて慣れるしかないのかと考えてる．

RocketChatの実装を調べたけどわからなかった

前回の続き．

結局FlowRouterの利用設定がおかしいだろうことはわかったけど， 原因は特定できなかった．

おそらく原因は packages/rocketchat-libにあって， 一次的にはgetRouteLinkが返すリンクがおかしい． ただし，getPermaLinkや directoryのリンクであるonTableItemClickのように出力がおかしいものだけでなく， chatNowLinkや roomDataのように正常に動作するものもあるので getRouteLinkがおかしいわけではなく， FlowRouterに設定されたルーティング情報がおかしいのだろう．

各種チャンネルはdefaultRoomTypes.jsで定義されているが， この実装であるaddはおそらく正常に動作している． 他の正常に動作するルーティングを定義するrouter.jsと 比べても特におかしいところはない．

むしろこのルーティングのactionであるopenRoomの 実装がおかしいのではないかとは考えたが，これが何をしているかよくわからず， また特段おかしいところも見付けられなかった．

正直なところ，慣れないフロントエンド，初めてのmeteorで 上手く不具合修正できる気がしない． 今後どのようにデバッグすればいいのだろうか．

meteorチュートリアルを試してRocket.Chatの実装を調べてみた

普段利用しているSlackクローンのRocket.Chatについて， 結構前から動作に影響の大きな不具合が出ていたので頑張ってIssue報告してみた． これ自体は意図は伝わったのか，他にも同様の不具合を報告してくれる人が何人も現れ， これで対処してもらえると思いきや，報告から2ヶ月たっても修正されそうな雰囲気なし．

このままでは非常に使い勝手が悪いので， 自分で修正してみることを視野に検討してみた． とはいえ，フロントエンドはまったくわからないので どこから手を付ければいいのか悩ましいところ． いろいろと調べていたら， Rocket.Chatを実装する meteorフレームワークには 複数のチュートリアルがあることが判明． RocketChatのソースコードを読んでもわからないことばかりだし， かといってJavaScriptから勉強していたのでは時間が掛かり過ぎるので フレームワークの動作からおさえることに．

チュートリアル内容

3種類のチュートリアルのうち，最も基本的なReactなTODOアプリを実装してみた． meteorフレームワーク自体はなんとなく理解できたが， 途中まったく動作せずいろいろと確認してみた結果， チュートリアル内容に誤りがあることが判明． また，同様の不具合としてテストを追加実装しても実行されない様子．

Rocket.Chat実装調査

meteorフレームワークの動作がなんとなく理解できたので それではRocket.Chatの実装も調べてみようと思いきや 当然実際のアプリはより複雑で理解できず．

特にチュートリアルにはなかったディレクトリやインスタンス？が多数登場し どのような仕組みでロードされているのかわからないという， チュートリアルを試した成果がまったくない状況に． 諦めようか悩んでいたところ，やっとファイルを読込む順序や各種ディレクトリの意図を説明する ドキュメントを発見． これを読むことでやっとRocket.Chatの動作がなんとなくわかるようになった．

Issueへの対応

それじゃあ不具合修正も簡単に対処できるかというと，そちらは全く進捗なし． 不具合の原因がmeteorのルーティングまわりを制御する FlowRouterまわりにあることは理解できたが， FlowRouterがおかしいのか，Rocket.ChatにおけるFlowRouterの制御がおかしいのかは切り分けできず．

いろいろと調査しているうちに，時間切れになったので3連休中の調査は一旦終了． ECMAScript2015やnpmまわりの理解も追い付いていないのでまだまだ時間は掛かりそう． このペースで調査を進めて不具合修正できるのが先か，他の人が修正してくれるのが先か．

参加記録 ARC100

記念すべき第100回にて大敗北してしまった．

0完で1001 -> 956. 安定してCD解けるようになりたいと思っていたけど Cが解けないのはきびしい．

C - Linear Approximation

bの候補は b = A_i - i を満たす最小のbと最大のbの間のいずれか => bの候補は最大10⁹通りになるので当然TLE

bの候補は b = A_i - i となる最大N個のうちのいずれか，かつ中央値付近？ => 一部でWAが発生(実は悲しさの値のオーバーフロー)

となって，候補はN通りではない？と疑問を持ち始めて悩んでいるうちに モチベーションがどんどん低下していく最悪な事態．

• 最初からA_i - iと考えておけば問題をシンプルにできたので考察が簡単に進めることができたかもしれない
• bの候補は考察を基に高々N通りであると判断できておくべきだった
• そもそも最初の提出がTLEの事を何も考えていなさすぎて酷い
• intのオーバーフローに気を付けることは競技プログラミングの初歩の初歩
• 解が中央値であることは考察以前に知識として持っておくべき頻出問題だ
• コンテストの100分くらい集中力を持続させろ

と，反省点が多過ぎる．

Ubuntu 18.04リリース記念オフラインミーティングに参加しました

UbuntuをメインOSとして利用している割には今までオフラインミーティングに 参加できていませんでしたが，ついに参加することができました．

主催のグリーさま，運営のUbuntu Japanese Teamのみなさま ありがとうございました．

UbuntuでRAW画像を取り扱う

カメラで撮影した画像をUbuntuで取り扱う注意点など． このあたりに苦労するのは自分でなんでもしなくてはいけない Ubuntu(Linux)ならではの問題だなと． 話には出ていなかったけど，Windowsならカメラ側の サポートで問題なく処理できるのだろうか．

Ubuntuで対応できるかを踏まえて道具(カメラ)を選定する という視点は一般的ではないけど Linuxを利用する上では重要なので頭の片隅に残しておきたい．

Ubuntuの同人誌をUbuntuで書く

最近流行り？のドキュメント作成にソフトウェア開発ツールを利用する話． このあたりは自分も会社で導入してみたけど， 消費リソースの関係でフォントを選定するという話は 出費がシビアな同人ならではだなと感じた．

実は「うぶんちゅ！ まがじん ざっぱ〜ん♪ 」については 知らなかったので，頂いた本に加えて バックナンバーについても確認してみようと思う．

Wineの話 (タイトル忘れた)

Wineについてや，Wineで動くアプリや動かないアプリ， Wineの使い方などについて． Wineの苦労話をこれでもかという程解説してもらった．

自分はWineは早々に諦めていたので 久しぶりにWineの濃い話を聞いた． 残念ながら自分でも挑戦してみようという気にはならず．

Ubuntu Weekly Recipeのフィードバックの話 (タイトル忘れた)

Ubuntu Weekly Recipeの記事にフィードバックを返そう， OpenNebulaについてやったことを話すよ，という内容． CentOSでやってselinuxにひっかかったり， OpenNebulaのストレージまわりで苦労した話とかは 自分も経験しているのであるあるだな，と思いながら聞いてた．

たぶんこのイベントの中で一番はっとさせられた． 学んだことをアウトプットすることが大切だとは理解していたけど そこに発表者へのフィードバックという意識はあまりなかった． せっかく発表してくれた人のためにも きちんと感想等を述べることは非常に有意義なことだと思うので これからはできるだけ忘れずにフィードバックできるようにしたい．

リリースノートの解説 (発表タイトルあった？)

突如行われた？リリースノートの解説． リリースノートを読むだけでは知りえない リリースノート作成の裏話や， 各項目についてつっこみを入れる話など， まさにリリース記念ミーティングならではであった．

イベント全体

イベント詳細のページでイベント開始時刻が記載されていない， タイムテーブルが大雑把など，かなりゆるふわなイベントを 想像していたけど，想像以上でした．

開始早々お酒とからあげが振る舞われたり， 各種アナウンスがジョークにあふれていたりと 楽しくイベントが進行しました．

またじゃんけん大会(残念ながら勝ち残れませんでした)や 参加者全員サービスプレゼントなど， 思わぬお土産も頂きました． ありがとうございました．

Redmineのサブプロジェクトをソートして表形式に表示する

以前にサブプロジェクトを View Customize Plugin を利用して 表形式に表示する 記事を書いた が 実はサブプロジェクトはソートされていなかった．

デフォルトではサブプロジェクトの作成順に表示されるが， サブプロジェクト名に応じてソートされた方が便利． 実際に，他に利用してもらっている方からもそういう意図のコメントがあった．

あらためて考えてみると，ソートの仕組みを導入すること自体は楽に実装できるが， どのようにソートするかは難しいことに気が付いた． 例えばアルファベットの大文字・小文字の取り扱いや漢字を含む場合など．

あまり複雑なソートを導入するにしても どのようにソートするかは難しいので， 雑に文字列比較で実装することにした．

redmine 'view customize plugin' script to show sub ...

ゼロから作るDeep Learning2の公開レビューに参加しました

Deep Learningまわりは勉強しないといけないよな， と考えていた矢先に 『ゼロから作るDeep Learning ❷』公開レビューのお知らせ を知り，参加させてもらうことにしました．

業務では技術ドキュメントのレビューを行う機会は多いものの， 市販される前の書籍をレビューしたことはなく， 貴重な経験を体験させて頂くことができました．

自分のスペック

• 前書「ゼロから作るDeep Learning」は読んでいない
• 機械学習は学生時代に専攻するも，現在は取り組んでいない
• Deep Learningは素人(ニューラルネットを学生時代に勉強した程度)
• Pythonはなんとか書ける

前書から読むかいきなりレビューに参加するか迷っていたけど， ニューラルネットやPythonを理解していれば前書のを読んでいなくても 読み進められるようにする，と書いてあったので参加を決意することに． 実際，自分の様に前書の評判を知って本書から読む人もいるだろうと思ったので．

レビューした感想

1章に記載の復習でキャッチアップできたので 前書を読んでいないくても内容を理解できたのでよかった． ところどころ前書で説明済みなのか 説明のない表現等があったところが多少困った(指摘した)．

自然言語処理には苦手意識を持っていたので 読み切れるか心配していたけど，そこは問題なかった． 基本的な内容の説明はもちろん，最新の研究ではどこまで(どうやって) 上手くいっているのか示していた． これにより，本書の技術的な位置付けを上手く示していたので， 本書の先まで簡単に見通せたのはすばらしいと思った．

一番レビューを進める中で大変だったのが，Dropbox上のpdfによる制約だった． 章ごとにファイルが分割されていたので，ファイル間の検索ができず， 前に出てきたかな？と思ったときに探すことが大変だった． また，同一ファイル内の検索もきちんとできているか怪しいところも．環境問題？ 実際にレビューする際は，覚えていなければ説明済であっても気にせずコメントするようにした．

また，どういった点についてレビューすればいいのか迷った． 社内文書であれば，最終的なイメージは想像できる/ある程度決まっているので指摘しやすいが， オライリー本は多数読んだことはあっても前書は読んでいなかったので 好みで記載方法が分かれるところは指摘しない方がいいかも，とも考えていた． とはいえ，他の人も結構好き勝手にコメントしているようだったので， 気にせずコメントすることに．

ちょうどその頃， 技術書のレビューの経験則 というブログ記事を見付けて内容を参考にした． 特に，「ミクロな指摘より、マクロな指摘を」という指摘にはなるほどと思い， それ以降はできるだけマクロな指摘をするように気を付けたけど， 残念ながら実践できたかどうかは難しいところ． やはり，レビューを出す際にどういった点について レビューして欲しいか要望を出してくれると参加しやすいなと思った．

ただ，公開レビューということで，他の人がどのような視点で読んでいるのか参考にできたのは 普段技術書を読むのとは別の面白さがあった． 最近は輪講とかしないけど，文字に残すと(残そうとすると)輪講とは違った 意見が残るのでこれはこれで面白いかも． もちろんレビューという形で文字に残すと通常の感想とは違うのだけど．

その他

ゼロから作るDeep Learning2は2018/6/25に発売予定とのこと． もう一度読むか悩ましいけど，どう直っているか気になるし， 謝辞に名前を入れてくれるということなので記念に買うかも．

ゼロから作るDeep Learning ? ―自然言語処理編