以前にサブプロジェクトを View Customize Plugin を利用して 表形式に表示する 記事を書いた が 実はサブプロジェクトはソートされていなかった．
デフォルトではサブプロジェクトの作成順に表示されるが， サブプロジェクト名に応じてソートされた方が便利． 実際に，他に利用してもらっている方からもそういう意図のコメントがあった．
あらためて考えてみると，ソートの仕組みを導入すること自体は楽に実装できるが， どのようにソートするかは難しいことに気が付いた． 例えばアルファベットの大文字・小文字の取り扱いや漢字を含む場合など．
あまり複雑なソートを導入するにしても どのようにソートするかは難しいので， 雑に文字列比較で実装することにした．
Deep Learningまわりは勉強しないといけないよな， と考えていた矢先に 『ゼロから作るDeep Learning ❷』公開レビューのお知らせ を知り，参加させてもらうことにしました．
業務では技術ドキュメントのレビューを行う機会は多いものの， 市販される前の書籍をレビューしたことはなく， 貴重な経験を体験させて頂くことができました．
前書から読むかいきなりレビューに参加するか迷っていたけど， ニューラルネットやPythonを理解していれば前書のを読んでいなくても 読み進められるようにする，と書いてあったので参加を決意することに． 実際，自分の様に前書の評判を知って本書から読む人もいるだろうと思ったので．
1章に記載の復習でキャッチアップできたので 前書を読んでいないくても内容を理解できたのでよかった． ところどころ前書で説明済みなのか 説明のない表現等があったところが多少困った(指摘した)．
自然言語処理には苦手意識を持っていたので 読み切れるか心配していたけど，そこは問題なかった． 基本的な内容の説明はもちろん，最新の研究ではどこまで(どうやって) 上手くいっているのか示していた． これにより，本書の技術的な位置付けを上手く示していたので， 本書の先まで簡単に見通せたのはすばらしいと思った．
一番レビューを進める中で大変だったのが，Dropbox上のpdfによる制約だった． 章ごとにファイルが分割されていたので，ファイル間の検索ができず， 前に出てきたかな？と思ったときに探すことが大変だった． また，同一ファイル内の検索もきちんとできているか怪しいところも．環境問題？ 実際にレビューする際は，覚えていなければ説明済であっても気にせずコメントするようにした．
また，どういった点についてレビューすればいいのか迷った． 社内文書であれば，最終的なイメージは想像できる/ある程度決まっているので指摘しやすいが， オライリー本は多数読んだことはあっても前書は読んでいなかったので 好みで記載方法が分かれるところは指摘しない方がいいかも，とも考えていた． とはいえ，他の人も結構好き勝手にコメントしているようだったので， 気にせずコメントすることに．
ちょうどその頃， 技術書のレビューの経験則 というブログ記事を見付けて内容を参考にした． 特に，「ミクロな指摘より、マクロな指摘を」という指摘にはなるほどと思い， それ以降はできるだけマクロな指摘をするように気を付けたけど， 残念ながら実践できたかどうかは難しいところ． やはり，レビューを出す際にどういった点について レビューして欲しいか要望を出してくれると参加しやすいなと思った．
ただ，公開レビューということで，他の人がどのような視点で読んでいるのか参考にできたのは 普段技術書を読むのとは別の面白さがあった． 最近は輪講とかしないけど，文字に残すと(残そうとすると)輪講とは違った 意見が残るのでこれはこれで面白いかも． もちろんレビューという形で文字に残すと通常の感想とは違うのだけど．
ゼロから作るDeep Learning2は2018/6/25に発売予定とのこと． もう一度読むか悩ましいけど，どう直っているか気になるし， 謝辞に名前を入れてくれるということなので記念に買うかも．
ゼロから作るDeep Learning ? ―自然言語処理編
システムが一新したGCJ． サーバエラーが相次いだようだけど自分は影響なかった．
ただし，コンパイルエラー(提出クラス名の修正ミス)とか 入出力形式ミスがあったので気を付けたい．
ABC small解けた時点でどれか1つはlarge通るだろうと Dは問題文読むだけで解かなかった．
Cを右に，Sを左にもってくればいい． 特に右側のCほどダメージが大きいので 後ろからCSの順序となっている位置を持ってきて 交換することを繰り返せばいい．
最初にSの数を数えて最小ダメージを算出し， IMPOSSIBLEかどうか判定したけど必要なかった． Pが30文字以下，Dは109以下なので intだけでよかったけど，本当にそうか悩んでしまった． 最初から思考停止でlong使えばよかったかも？
本当に後ろのCSを交換することが最善か 自信がなくていろいろ検討した(結局確証は得られなかった)のと， 出力形式にコロン(':')を入れていなくてエラーとなったことに気付けなくて 数時間を消費してしまった．
手元で実験して奇数番目同士または偶数番目同士でしか 交換が生じないことに気付けた． 先に偶奇でそれぞれ別にソートして 最後に合わせたときにソートされているか判定すればいい．
配列を分割・統合する処理を実装するのに 手間取ったので実装力が足りない．
問題文を理解するのに手間取った． Aが20/200で固定なのにサンプルでは3とか11だったり， テストツールが上手く動かせなかったり．
先に処理する領域を決定し， 領域をはみでないように座標を選択するとよい．
正方形に近くなるような領域を処理するようにしたけど， 折り返し処理が面倒な上に無駄も多くなるので どちらかの一辺は3マスでよかった． 領域が限られているので一辺が3だと足りなくなると思い込んでいたけど 考えなくても自明だった．
久しぶりのCodeforces & 初のEducational． よく知らないままにとりあえず参加．
ABC解いて1619th, Rank 1402でRatings 1408 -> 1419 (+11). 久しぶりの海外コンテストかつEducationalの形式を知らない中で参加した割にはまあ満足． ただし，コンテスト終わり際になってDの方針が決まるものの， 提出できないで終わったのが悔しい．
最初はまったく問題文が理解できずに時間が経つ． 問題文のテトリスという単語からやっと意図を理解して解いた．
問題を理解してからはすぐに解けた．
どこで起こすとスコアが最大になるか，しゃくとり法で探索するだけ． 比較的すぐに解くことができた． (しゃくとり法というアルゴリズム名自体は忘れていた)．
分割された各パネルの左上を黒or白にするコストを計算し， その組合せが最小となるように選べばいい．
解いている最中から気になってはいたけど， 黒にするコストと白にするコストの両方を計算する必要はなかった． このせいで無駄に複雑にしてしまった．
また，コストの総和が最小となる組合せの選び方を どうすればいいかわからず謎実装してしまった．
最初は方針が立たなかった． よく考えれば3点が直線に並んでいれば直線は確定なのだから 最初の5点から1つの直線を決めて，直線にのらない点はもう1つの直線候補として保存， 以降はどちらの直線にものらなくなった時点で不可とすればいいだけだと気付く．
方針を決定した時点で残り時間があまりなく，実装しきれなかったのが悔しいところ． 実装方針もよくなかったし，実装にオーバーフローによる不具合もあったのでダメダメだった．
一目シンプルで簡単に解けそうだと思ったけど方針がたたなかった．
とりあえずAを解くことを目標にして，実際にAを解けたのでとりあえずは満足．
526th 851 -> 947
Bを解けるようになることも課題だけど， Aをもっと早く解けるようになることが優先かな．
サンプルを見て，単語長で処理が違うことに気付く．
与えられた単語長が26未満であれば，未使用の文字のうち最小のものを最後に追記すればよい． 単語長が26であれば，後ろから見て辞書順で次の単語になるように文字を置き換えるかチェックすればよい．
より早く解けるようになるためには， 入力例4を参考にさっさと手元でシミュレーションして実装方法を検証すればよかった． String/charの変換処理とか，substringの使い方とか， 実装方法の確認に時間を掛けないようにするべきだった．
なんとなく解けそうで方針が立たなかった．
gcd(a, S-a) = gcd(a, S) であることはすぐに気付くも，そこから先が進まず． 要素を素数にする？みたいなアイデアを出すもそこから進まず．
Sを6の倍数とする案はまったく出てこなかった． 手元のシミュレーション不足だろうか． Nが小さいときを別扱いすることも思いつかなかった．
まったくどうすればいいかわからず，早々にギブアップ．
Redmine4を見据えた，プラグイン開発ハンズオンに参加しました．
主催のアジャイルウェアさん，会場提供のテクマトリックスさん ありがとうございました．
ほとんどの人がPlugin開発経験なし， Ruby(Rails)も普段バリバリ書いている人はいない という感じでした．
自分も2-3個のRailsアプリを書いたことがあるだけでほとんど知見なし， Rails5についても情報収集はあまり行っていない (開発経験もない)というスキルでの参加です．
connpassにアップロードされた資料の通りです． Cloud9上でRedmineの最新版(trunk)を動作させ， サンプルのプラグインとして チケットに「いいね」ができる いいねプラグイン を写経しました． また，途中途中で講師の方から注意点や 実際のプラグイン開発の知見を説明してもらいました．
redmine公式wikiにもプラグイン開発のチュートリアルは 掲載されています． しかし最終更新が2014年で，Redmine 2系を対象としており， メンテされていません． 自分も以前プラグイン作成を検討した際に 情報の古さから断念しました．
加えて，チュートリアル中では
rails generate redmine_plugin
コマンドにてプラグインの雛形を生成して
作成するように支持がありますが，
このツールのメンテがあまり行われておらず
アジャイルウェアさんでもこのツールは利用していないとのこと．
このためプラグイン開発は手作業でファイルやディレクトリを作成して進めました． しかし，Rails開発に慣れていないこともあって 多くの参加者でミス・不具合が発生(自分も何度かミスしました)． 正直なところ，このツールは必要だと思ったのですが 慣れてくるとどうでもよくなるのでしょうか．
プラグインHook
Redmineにはプラグイン向けに 処理を差し込めるポイントが準備されています． Hookリストはこちら.
ただし，このHookは数が十分ではなく， 大抵のプラグイン開発で必要なHookが足りない状況におちいるとのこと． このため，ベースとなるHookポイントにテンプレートの元となる記述を書き込み， 後からJavaScriptで書き換えるのがよいそうです．
プラグイン開発パターン
issue_patch
既存のクラスに機能を追加する(モンキーパッチを当てる)仕組み． ここではIssueに対するパッチで，iine_countersテーブルへの 参照を追加しています． 他にも本プラグインではuser_patchを利用しています．
query column
Issue一覧のカラムを追加する方法です． available_columnsに追加することで実現できます．
Rail5対応に必要な変更
Rails4ではActionDispatch::Reloaderとして実装されていましたが Rails5でActiveSupport::Reloaderとクラスが変更になっています．
Rails4ではalias_method_chainを利用していましたが， Rails5からは非推奨となり，prependを利用する必要があるそうです．
その他
redmineとrailsの再読み込みの相性があまりよくないらしく， 開発中においてプラグインを書き換えても自動で反映されず サーバ再起動が必要になったり，ならなかったりすることがあるそうです．
手軽にブログを投稿できるようにするために emacsで作成・ポストできる環境を構築する． hatena-blog-mode はまさにこれを実現するためのelispなのでこれを利用する．
デフォルトではHOMEに作成され, 投稿が完了すると(投稿しなくても) 編集後にファイルを削除する． hatena-blog-backup-dir を指定することで 編集後にファイルを保存してくれる．
現在はローカルファイルの管理にhowmを利用しており， これは home-dir/YYYY/mm/ にファイルを作成する． これと統合して同一ディレクトリに作成するようにしたい．
またはhowmでファイルを管理してもいい(こちらの方がいい？)．
デフォルトでは hatena-new-entry.md となりこれをカスタマイズすることはできない． バックアップファイルは YYYY-mm-dd-HH-MM-SS フォーマット． これをhowmと同一の YYYY-mm-dd-HHMMSS フォーマットに変更(統一)したい．
ただし，現状ではローカルにて作成途中のファイルを管理することを想定していない様子．
デフォルトでは投稿時( hatena-blog-post 実行時)に タイトルやカテゴリ，ドラフト等を指定できる． これをfront matterのように ファイル内で指定できるとさらに便利．
とりあえず作成してみたけど上手くいかない． 先に自分の.emacsの整理が必要かも．
