出力を入力へ

プログラミングに関する自分が考えた事を中心にまとめます

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 ❷』公開レビューのお知らせ を知り,参加させてもらうことにしました.

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

自分のスペック

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

レビューした感想

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

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

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

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

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

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

その他

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

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

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

参加記録 GCJ Qualification Round 2018

システムが一新したGCJ. サーバエラーが相次いだようだけど自分は影響なかった.

ただし,コンパイルエラー(提出クラス名の修正ミス)とか 入出力形式ミスがあったので気を付けたい.

ABC small解けた時点でどれか1つはlarge通るだろうと Dは問題文読むだけで解かなかった.

Saving The Universe Again

Cを右に,Sを左にもってくればいい. 特に右側のCほどダメージが大きいので 後ろからCSの順序となっている位置を持ってきて 交換することを繰り返せばいい.

最初にSの数を数えて最小ダメージを算出し, IMPOSSIBLEかどうか判定したけど必要なかった. Pが30文字以下,Dは109以下なので intだけでよかったけど,本当にそうか悩んでしまった. 最初から思考停止でlong使えばよかったかも?

本当に後ろのCSを交換することが最善か 自信がなくていろいろ検討した(結局確証は得られなかった)のと, 出力形式にコロン(':')を入れていなくてエラーとなったことに気付けなくて 数時間を消費してしまった.

Trouble Sort

手元で実験して奇数番目同士または偶数番目同士でしか 交換が生じないことに気付けた. 先に偶奇でそれぞれ別にソートして 最後に合わせたときにソートされているか判定すればいい.

配列を分割・統合する処理を実装するのに 手間取ったので実装力が足りない.

Go, Gopher!

問題文を理解するのに手間取った. Aが20/200で固定なのにサンプルでは3とか11だったり, テストツールが上手く動かせなかったり.

先に処理する領域を決定し, 領域をはみでないように座標を選択するとよい.

正方形に近くなるような領域を処理するようにしたけど, 折り返し処理が面倒な上に無駄も多くなるので どちらかの一辺は3マスでよかった. 領域が限られているので一辺が3だと足りなくなると思い込んでいたけど 考えなくても自明だった.

参加記録 Codeforces Educational Round 41

久しぶりのCodeforces & 初のEducational. よく知らないままにとりあえず参加.

ABC解いて1619th, Rank 1402でRatings 1408 -> 1419 (+11). 久しぶりの海外コンテストかつEducationalの形式を知らない中で参加した割にはまあ満足. ただし,コンテスト終わり際になってDの方針が決まるものの, 提出できないで終わったのが悔しい.

A: Tetris

最初はまったく問題文が理解できずに時間が経つ. 問題文のテトリスという単語からやっと意図を理解して解いた.

問題を理解してからはすぐに解けた.

B: Lecture Sleep

どこで起こすとスコアが最大になるか,しゃくとり法で探索するだけ. 比較的すぐに解くことができた. (しゃくとり法というアルゴリズム名自体は忘れていた).

C: Chessboard

分割された各パネルの左上を黒or白にするコストを計算し, その組合せが最小となるように選べばいい.

解いている最中から気になってはいたけど, 黒にするコストと白にするコストの両方を計算する必要はなかった. このせいで無駄に複雑にしてしまった.

また,コストの総和が最小となる組合せの選び方を どうすればいいかわからず謎実装してしまった.

D: Pair Of Lines

最初は方針が立たなかった. よく考えれば3点が直線に並んでいれば直線は確定なのだから 最初の5点から1つの直線を決めて,直線にのらない点はもう1つの直線候補として保存, 以降はどちらの直線にものらなくなった時点で不可とすればいいだけだと気付く.

方針を決定した時点で残り時間があまりなく,実装しきれなかったのが悔しいところ. 実装方針もよくなかったし,実装にオーバーフローによる不具合もあったのでダメダメだった.

E: Tufurama

一目シンプルで簡単に解けそうだと思ったけど方針がたたなかった.

Wavelet Matrixというアルゴリズムを利用する問題らしい(参考). 要復習.

参加記録 AGC022

とりあえずAを解くことを目標にして,実際にAを解けたのでとりあえずは満足.

526th 851 -> 947

Bを解けるようになることも課題だけど, Aをもっと早く解けるようになることが優先かな.

A - Diverse Word

サンプルを見て,単語長で処理が違うことに気付く.

与えられた単語長が26未満であれば,未使用の文字のうち最小のものを最後に追記すればよい. 単語長が26であれば,後ろから見て辞書順で次の単語になるように文字を置き換えるかチェックすればよい.

より早く解けるようになるためには, 入力例4を参考にさっさと手元でシミュレーションして実装方法を検証すればよかった. String/charの変換処理とか,substringの使い方とか, 実装方法の確認に時間を掛けないようにするべきだった.

B - GCD Sequence

なんとなく解けそうで方針が立たなかった.

gcd(a, S-a) = gcd(a, S) であることはすぐに気付くも,そこから先が進まず. 要素を素数にする?みたいなアイデアを出すもそこから進まず.

Sを6の倍数とする案はまったく出てこなかった. 手元のシミュレーション不足だろうか. Nが小さいときを別扱いすることも思いつかなかった.

C - Remainder Game

まったくどうすればいいかわからず,早々にギブアップ.

Redmine4(Rails5)プラグイン開発ハンズオン無料セミナーに参加しました

Redmine4(Rails5)プラグイン開発ハンズオン無料セミナーに参加しました

Redmine4を見据えた,プラグイン開発ハンズオンに参加しました.

主催のアジャイルウェアさん,会場提供のテクマトリックスさん ありがとうございました.

agileware.connpass.com

参加者

ほとんどの人が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対応に必要な変更

ActiveSupport::Reloader

Rails4ではActionDispatch::Reloaderとして実装されていましたが Rails5でActiveSupport::Reloaderとクラスが変更になっています.

Module:prepend

Rails4ではalias_method_chainを利用していましたが, Rails5からは非推奨となり,prependを利用する必要があるそうです.

その他

redminerailsの再読み込みの相性があまりよくないらしく, 開発中においてプラグインを書き換えても自動で反映されず サーバ再起動が必要になったり,ならなかったりすることがあるそうです.