Posts

ConoHa-CLIの進捗報告。 まだちゃんと全てを切り出せたわけではないが、 現状 ログイン処理の外出し 時刻の比較 ログインの再実行 ログイン処理の外出し ログインコマンドは出来上がった。 ConoHaのAPIへ接続し、TokenIdを持ち帰り~/.config/conoha.tomlに吐き出せるようになった。 しかし、このTokenIdはわずか1日しか有効期限がない上、APIの殆どはTokenIdを求めてくる。 現状の作りでは日付を跨ぐ度にTokenIdの有効期限が切れていますエラーを食らい、 その度にログインコマンドを打ち込む作業が待っている。 ログイン処理を抽象化して取り出す必要がある。 早速プロジェクトルートにutilというディレクトリを作成した。 (ベストプラクティスはまだ良くわかっていないが、公開して有識者の目に止まればPRでも貰えるだろう) Go言語でエラーを書くときに気をつけること - taknb2nchのメモ Go言語でパッケージの修飾名が重複した場合の対応方法 - taknb2nchのメモ 時刻の比較 まずは時刻。 トークン時刻が期限切れか否かを確かめる方法がよく分からない。 Time同士の比較はないのか？ 一度Unixタイムに変換して数値同士で比較するように修正した。 Package time Go言語で時刻を - そこはかとなく書くよん。 逆引きGolang (日付と時刻) How to convert ISO 8601 time in golang? ログインの再実行 トークンが古ければもう一度ログインを試みて取得しなおすように修正。 Golangだと処理的になってしまうなぁ……色々とださいがまぁまぁええわ。 動くの大事。 最低限体裁を整えたので一度完了として次へ Next… Mac以外のHomedirectoryも取得出来るようにしたい Golang で filepath.Abs に ~(ホームディレクトリ) を指定した時にカレントワーキングディレクトリが先頭についてしまう package homedir

今日のConoHa-CLIの進捗報告。 ConoHa-CLIの報告だと、上司はこのはちゃんになるのだろうか？ 現状 標準入力からの値取得 ConoHaのAPIを叩いてログイン(トークンID取得) トークン情報を引き出す TOMLファイルを更新 標準入力からの値取得 現在loginコマンドを実装中。 オプションでID、Password、テナントIDを入力させる作りにはしたが、 入力項目が足りない場合は標準入力から煽って入力させる作りを目指した。 参考サイト: flag パッケージ - golang.jp Go 言語で標準入力から読み込む競技プログラミングのアレ — 改訂第二版 早速参考サイトを元に実装を行う。 優先順位の要件は下記。 コマンドライン引数-tからの入力値 $HOME/.conohaの設定項目 標準入力と標準出力で入力させる まずはcmd/root.goでcobraとviperの設定を行う func init() { cobra.OnInitialize(initConfig) RootCmd.AddCommand(versionCmd) } func initConfig() { viper.AddConfigPath("$HOME") viper.SetConfigName(".conoha") viper.SetConfigType("toml") viper.ReadInConfig() } 次にcmd/login.goで各種値を取得するように設定を行う。 func init() { rootcmd.addcommand(logincmd) logincmd.flags().stringp("tenantid", "t", "", "port to run application server on") viper.bindpflag("auth.tenantid", logincmd.flags().lookup("tenantid")) } var loginCmd = &cobra.Command{ Use: "login", Short: "Calculator of addition.

Go言語でConoHa-CLIを作成しているので、 少しずつ進捗報告をしていきたい。 現状 Glideを導入 cobra / viperを導入 TOMLを導入 構造体の外出しでハマる Glideを導入 Glideはパッケージ管理ソフト。 先日参加したGoビギナーズLT大会！ 「最近、Go言語始めました」の会 #4というイベントで、 Go言語のパッケージ管理はGlideを使うのが筋が良いと聞いて導入を決意。 参考サイト: Goビギナーズ - よくある3つの質問 - mom0tomo go getはローカルマシンに落としてしまうのでパッケージ管理というレベルじゃねーぞ状態だったが、 Glodeではプロジェクトルートに設定ファイル、vendorディレクトリに依存ライブラリが次々と担ぎ込まれ、 npmとほぼ同じ使用感で使う事が出来た。 ただ、LT大会を聞いている限り、Glideを使って入れたらハマったので結局go getでやりました。 使い方教えてという悲痛な声だらけだったので、酷いハマリポイントがあるんだろうなぁ（白目 cobra / viperを導入 cobraはCLI用のライブラリ。 Node.jsに於けるCommander.jsみたいなもん。 Commander.jsはサブコマンドの実装で大ハマリしたが、cobraはわりと素直な動作だしドキュメントが充実してて書きやすい。 お供はviper、蛇繋がりか。 こちらはJSON、YAML、TOML等の設定ファイルをよしなに展開してくれる。 また、cobraとの共存も見越しており、オプション設定にフックしてよしなに上書きすることも可能。 なにそれ便利過ぎィ！ ただし、環境変数や複数の設定ファイル読み込み、オプションのオーバーライド等の兼ね合いから、 ファイルへの書き込みはサポートしていない模様。 (なんかファイルに書き出したいという要望がプルリクに上がってて、マージされてるっぽいんだけど、masterにはないもよう) ファイルへ吐き出す場合は、別途何かしらのライブラリを用意してきて勝手に出力するしかない。 ただまぁ、viperから最新の値を抜き出して上書き出来るから全くのゼロスタートというわけではないかな。 TOMLを導入 TOMLとはGitHubの人が提唱している設定ファイル。 IniとJSONの良いとこ取りといった感じ、インデント無しで配列やオブジェクトを宣言出来るため、ネスト地獄が起こらないのが主張。 最初はYAMLで書いてたのだが、どうもTOMLの方が便利そうなのでそちらを利用することに。 構造体の外出しでハマる コンフィグファイルまわりは外出ししようとプロジェクトルートにはconfというディレクトリを作成して外出し。 どうしたものか、conf.auth = xxxがundefinedですとコンパイル通さなくなった。 しかしここはさすがのQiitaクオリティ、同じネタでハマった人を発見して無事解決。 参考サイト: Goの構造体をpackageに外出ししてハマッたこと

再就職が決まった。

今回の就職活動に利用した 履歴書・職務経歴書をアップデートするのにGitに乗り換えた話。

Browserify を利用する vorbis-encoder-js をリリースしたので、 履歴とハマリポイント等を備忘録として書き残していく。 既存のライブラリでは何が足りなかったのか higuma/ogg-vorbis-encoder-js - GitHub Garciat/libvorbis.js - GitHub 上記どちらのライブラリでも AudioBuffer から Ogg Vorbis 形式の音楽ファイルを生成し、DLさせる所までは実現した。 しかし、元々想定される用途が Web Audio API を利用して、マイクからの音声データをDLする所がゴールだったようで、 タグ情報を埋め込む事考えられておらず、任意のタグ情報が埋め込めない。 また、モダンなプロジェクトなら Browserify や webpack の事は考慮に入れると思うのだが、そうでもないらしく微妙に使い勝手が悪い。 最初のコミットが1年も2年も前なので仕方ない側面もある。 そういった経緯から要望を満たすライブラリが無かったので、 GitHub で公開されている既存プロジェクトのソースコードを参考に作る事にした。 要件 Node.js での利用を想定する JavaScript での利用は Browserify を利用する 任意のタグ情報を設定出来ること ビルド環境の構築は頑張らない ログ libvorbis のビルド libvorbis はC言語で書かれているので、JavaScriptに変換するために Emscripten を経由する必要がある。 もともとC言語で書かれたライブラリを任意の言語に変換して使おうという要望は LLVM というプロジェクトで実現されており、 Emscripten は LLVM が生成した中間コードを JavaScript に変換する機能に特化している。 従って、あれやらそれやらのインストールが必要で、 いつまで経ってもコンパイルが通る環境が作れない！ 参考リンク：emscriptenで遊んでみた - kashiの日記 結局 Emscripten に特化したコンテナは Docker Hub で公開されていたので利用することにした。

音楽ファイルにはアーティスト情報等のメタ情報を埋め込んでいる事が多い。 ゲーム音楽のループBGM絡みで勉強することになったのでそのまとめ。 ファイルにメタ情報を埋め込む そもそもファイル内にメタ情報を埋め込むという発想はWAV形式やAIFF形式の時代から既に採用されていたようだ。 これらのファイルフォーマットはコンテナ形式で動作するため、コーデックとセットで動かす事は可能。 しかしリニアPCMをそのままぶち込むものとして認識されてしまった事で、ファイルサイズばかり無駄にデカイ使えない形式として認識されてしまったようだ。 1993年にMP3(MPEG-1 Audio Layer-3)が登場。 MD(ATRAC)に迫る圧縮率を叩き出し、PCの音楽ファイルフォーマットはこれ一色になった。 更にiPodが2001年に登場、アメリカそして日本でも爆発的に普及した。 MP3ではアーティスト情報等を管理したいという要望が生まれた。 1996年に独自実装していた「Studio3」というソフトウェアに乗っかる形でID3という形で仕様が決定された。 そういった意味では、アーティスト情報をファイルに埋め込む文化はMP3が起源といえるだろう。 参考リンク: 【音源管理の精髄】　WAVでリッピングするとタグはどうなる？　【ネットワークオーディオTips】 WAV - Wikipedia WAV ファイルフォーマット - 前田稔(Maeda Minoru)のプログラム入門 その103「WAVの構造と現状」 - BB Watch AIFF - Wikipedia MP3 - Wikipedia ID3タグ - Wikipedia オーディオ符号化とその応用 - これまでの25年と今後の展望 - ミニディスク - Wikipedia ATRAC - Wikipedia iPod - Wikipedia Ogg のメタ情報に関して Ogg VorbisではVorbisCommentという規格が使用されている。 Ogg Flacと構造は殆ど同じだと思うので、Flacの解説サイトのリンクも抜粋。 参考リンク: Vorbis - Wikipedia VorbisComment - xiph.org Flacファイルのメタデータ(タグ)構造 - 白旗製作所 おまけ：LOOPSTART、LOOPLENGTHに関して Ogg VorbisではコメントにLOOPSTART、LOOPLENGTHという値を格納すると、 一部プレイヤーではループ再生を行ってくれる。

JavaScriptでOggのエンコードがしたいので調査した結果の備忘録。 結論から言えば下記のようなプロジェクトが既にあるらしいので、順番に試していく予定 higuma/ogg-vorbis-encoder-js - GitHub Garciat/libvorbis.js - GitHub brion/ogv.js - GitHub 基礎調査 ogg javascriptでぐぐったら解決。 そのものズバリな記事がヒットした。 ogv.jsがすごい - necotech blog JavaScriptでOgg VorbisとかWebMとかをデコードするライブラリ Emscriptenを使って、Cのライブラリ(liboggzとかlibtheoraとか)をJavaScriptのコードにコンパイルしてる どうやらOggのライブラリはC言語で作られているようでJavaScriptにコンパイルし直せばブラウザ上でデコード/エンコードが出来るというわけか。 （クロスプラットフォームにするなら当然か） Emscriptenに関してもちょっと調べてみた Emscriptenとは EmscriptenでC言語をJavaScriptに変換する - Qiita Emscriptenとは EmscriptenはC/C++言語からLLVMを生成し、それをJavaScriptに変換するコンパイラのことです。 C言語の標準ライブラリやPOSIXの一部もサポートし、OpenGL ES2.0も使えるそうです。 Write once, run anywhereって奴か。 プロジェクトに関して Emscriptenなる便利なコンパイラが存在するのであれば、さぞかしプロジェクトは沢山ありそうだ。 その通りなようで、GitHubでプロジェクトが色々とヒットした。 higuma/ogg-vorbis-encoder-js - GitHub Garciat/libvorbis.js - GitHub brion/ogv.js - GitHub ざっと読んだ限り、higuma氏のプロジェクトが一番簡潔で使いやすそうな気がした。 楽曲のタイトルやアーティスト情報、LOOPSTART等のタグ情報を入れて行きたいので、組み合わせ次第といったところか。 実際に動かしてみる必要がありそうだ。

手持ちのゲーム音楽ファイルをひたすらループさせるWebアプリを作った。 loop-bgm GitHubのloop-bgm 以下はなんで作りたかったのか、 どんな技術を用いたり勉強したかったのか、 今後どういう風に作り込んでいくか等をつらつらと書き並べていく。 そもそも何故作りたかったのか BGMのループ再生 - 高見知英のかいはつにっし(β) しかし、それでも集中を阻むもの。 それは「普通のサウンドトラックの曲データは、ゲーム内BGMのように、ループ再生ができない」ということ。 いくら戦闘曲とはいえ1ループはそれほど長くなく、だいたい1分ちょっとで終わってしまいます。 サウンドトラックのデータは、大体2～3ループぶん収録されてますが、それでも2，3分で終わり。 この曲の切れ目の無音期間と、再度イントロから始まってしまう感覚が、どうしても集中力を削いでしまいます。 まさにこれ。 一回フェードアウトして音楽が途切れ、イントロが大音量で流れ始めるあれで集中力の8割は持って行かれるのだ。 職場のメンバーにいくら力説しても全く理解が得られなかったが、探せば同じ事考えてる人間は結構居るものだ。 一度HTML5のAudioのcurrentTimeをいじるという手法で作っていたのだが、 退職と同時にクリーンインストールしたことでそのHTMLファイルやスクリプトが全部削除。 まぁいいや、もう一回作り直そうとなった次第。 どんな技術を採用したり、習得したかったのか 既に一度作っているというのもあり、 LiveScript様のパワーを借りれば1日程度でこしらえる事は可能なのだが、折角なので勉強になる事がしたかった。 従って、要件は以下の3つ AltJS、静的サイトジェネレータのベストプラクティスの模索 波形データを可視化してループ時間を設定したかった React でページ構築をしたかった AltJS、静的サイトジェネレータのベストプラクティスの模索 今時素のHTML、CSS、JSを駆使してWebサイトを作るなんてありえない。 前職はLiveScriptを用いて開発していたのだが、 Gulpにどっぷり浸かる生活、あの毎回gulp watchのコンパイルに成功したのを見届けないとブラウザーのF5を叩けないとかありえんだろ。 というで、職場全体では新プロジェクトは色々改良を重ねていたが、自分が先陣でプロジェクトを立ち上げるという訳でもなかった為、他人の作ったシステムを文句を言いながら利用する立場であった為、使い勝手や設計にいまいちしっくり来ていなかった。 HTML: Pug (いつもの) JavaScript: LiveScript (いつもの) CSS: Stylus (いつもの) どうしたかに関してはloop-bgm/bin/serve.lsを参照。 要するにExpressでローカル用のWebサーバーを構築して、 localhost:3000/index.htmlにアクセスが飛んできたら、 assets/templates/index.pugを探しに行って、ファイルが存在したら都度コンパイルして返すような仕組みを作った。 ちょっとでもファイルがなかったりするとエラーが出まくるが気にしない。 ローカル開発環境でしか使わないからね。 前の職場では本番環境用のスクリプトにこのような構造があり、環境変数やif文でゴリ押しする仕組みだったのが気に入らなかった。 波形データを可視化してループ時間を設定したかった AnalyserNode - WEB SOUNDER Web Audio APIにおいて, サウンドの視覚化のために定義されているのが, AnalyserNodeクラスです.

仕事で使っていたMacbook Proを使用しなくなったので、 クリーンインストールして持って帰っていたのだが、 仕事が忙しくてさっぱり触れてなかったので再インストールした。 ソフトの導入 テンプレ iTerm2: 必須ターミナル Alfred2: クリップボード履歴用 Flexiglass: ウィンドウのりサイズ Homebrew まずは何も考えずにXcodeをインストールする。 HomebrewはC++のバイナリを持ってきてMac内でコンパイルする仕組みだからXcodeがどうしても必要。 Xcodeの認証を済ませてHomebrewをインストール。 $ /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)" Git バージョンが新しいとなんとなく嬉しいので導入。 ちゃんと新しくなってるな、よしよし。 $ brew install git $ git --version git version 2.12.0 fish shell Fish使いなので導入 ついでにログインシェルを書き換える $ brew install fish $ which fish /usr/local/bin/fish $ sudo echo "/usr/local/bin/fish" >> /etc $ chsh -s /usr/local/bin/fish 永続化メモ # PATHの永続化 $ set -U fish_user_paths $HOME/.

今週は「納品」をなくせばうまくいくという書籍を購入。 これにはエンジニアがエンジニアを続けていくに従って立ちふさがる問題と向き合っており、 自分にとって腑に落ちる箇所が何箇所もあった。 自分の働いてきた環境 SIerの開発現場では一定以上の技術力は評価されない。 その理由は人月で、会社としては上級者3人で3人月の単価をもらうよりも、初心者10人で10人月の単価をもらう方が儲かる。 この辺は一般的に言われているウォーターフローの駄目な所。 そうして初心者だらけになった開発現場は地獄だ。 レビュー無しでは何も進まない職場、検討中のまま放置され続ける仕様、無能な自分・同僚、帰りにくい空気、言われたこと以上は出来ない環境。 これでは子供の頃から聞かされて育った赤の国の風景ではないか。 国全体が搾取してミサイルの1本でもこしらえるか、経営者が搾取して贅沢するかの違いでしかない。 しかも当然のように納期は厳守、どんな人間が担当すればこんな環境で良いシステムが構築出来るのだろう。 当然のように燃え上がるプロジェクト、火消し舞台は凄腕…でも給料は俺ら初心者と殆ど変わらない。 何故この火消しが出来る凄腕のプログラマは薄給なのだろうか、違約金を回避出来る救世主なのに…上層部は自然現象とでも思っているのだろうか。 それはさておき、憧れて入ったSEという業界は地獄だった。 なんでこんな辛い想いをし続けながら、人の仕事を奪っているのだろうと何度も自問自答した。 この本を手に取ったきっかけ この本は発売(発刊?)された時に一度話題になった書籍で、 当時の自分にはどうしても夢物語としか思えずスルーした。 現在の職場ではWebアプリをGulpやAngularJS等の(当時の)最新フロントエンド技術を使って開発していくスタイルになり、Web系のWindowsとの相性の悪さからMacbookに乗り換えた。 MacbookはiTermという出来の良いターミナルエミュレータとHomebrewというパッケージ管理ソフトが存在する。 CLIがより身近になり、コマンドを組み合わせる事を思いつき、自分で新しいCLIツールを作りという風に簡単にステップアップしていける環境が整っている。 その結果、驚くべき事に飛躍的にエンジニアとしての能力や速度が向上した。 CLI環境を触る時間が増え、タイピング速度が向上し、CLIツールを作るようになり、それが雪だるまのように積み重なっていった。 そして、少しの自信が付いた先日、知り合いがソニックガーデンに務める事になった事を聞いて、この本の存在を思い出した。 35歳定年説 35歳定年説で検索すると、やはりというべきか、エンジニアなんかやっていないで上流工程に進めという論調が目につく。 違うのはオブラートの厚さと溶けにくさだけだ。 経験として33歳になった今が一番プログラマとしての腕は高いと感じていて、 この職場に入社した2年前の自分と比較して、当初の自分3人分と今の自分1人だったら後者のほうが余程マシである。 もちろん賃金が3倍になるわけではない。 この差を実感していながら35歳定年説を唱えている人の上流工程に進め云々は的外れと言わざるをえない。 同じ頭脳労働の格闘技である将棋界ではアラフィフの羽生名人が1冠から3冠に返り咲いているし、議員も40台は若造扱いだ。 腑に落ちた箇所 属人性の排除に関しては薄々無駄だろうと思っていたが確証が無かった。 この本でもバッサリ切り捨てているのを読んで、 脳裏に属人性の排除の結果結局初心者だらけになって後々エンジニアに泣きつく構図が思い浮かんだ。 まとめ 特に自分としては35歳定年説の論調により、 30を過ぎて伸び続けるエンジニアの将来は社会的に受け入れられていない現状とのギャップに苦労している人は多いのではないかと感じる。 その時にこの本に出会えた事はとてもうれしいことだ。 長くエンジニアを続けていく為の手法として挙げられている採用方法やギルド制度も参考になった。 しかしこの納品のない受託開発はきっとまだまだ模索段階、次の書籍でより洗練された著者の意見が聞けるだろう。 念のため調べてみると、「リモートチームでうまくいく」という書籍が既に発売済みとのこと。 こちらもまた書店によって購入したい。