Shut the fuck up and write some code

グダグダ言わずにコードを書きたいブログ

2017年を振り返る

久々の更新ですが、大晦日なので今年を振り返ってみる。

※昨年の振り返り verytired.hateblo.jp

やったこと

NodeJSでAPI開発 / Knockout.jsでフロント開発

1月から4月まで関わってた案件。

※やっていたこと verytired.hateblo.jp

本来は長期的に参画する予定だったのが、計画通りに開発が進まなかったこともあり、4ヶ月で契約終了になる。

去年までやっていた某CA社の某生配信サービスの開発も働きやすくで良かったが、子供を生まれたことをもあり、将来性のありそうな話(うまくいったらそのサービスを独立させて会社を立ち上げるので、そこで働けるよ、というような内容)に乗った方が良いと思ってメインの案件を乗り換えてみたのが落とし穴だった。

でもまあ、仕事のやりにくさもあり、このまま続けるのもかなり悩ましかったので、ある意味無理矢理仕事をかえざる得ない状況になりラッキーだったのかもしれない。

react + typescript + webpackでのフロント開発(新規開発案件)

現在の案件です。上記案件後、某大手人材紹介会社に紹介してもらうようにお願いしたところ1週間もかからずに紹介してもらえて本当に救われる。奇しくも某CA社に舞い戻ることになったが、寄らば大樹の陰、仕事のやりやすさが身に沁みた。デザイナーがいなかったので自分でsketchでモックデザイン書いて、それを実装する一人開発ではあったが、特に大きな問題もなく、ひとまず最初のリリースまでやることが出来た。

反省点

うまい話は存在しない

知り合いの紹介だったので信用仕切って、あまり詳細を聞かずに案件を受けたのが間違いだった。どのような開発環境を用意してもらえるか、しっかりヒアリングしないといけない。どんな環境でも働けるIT土方だから大丈夫か、と自分を過信してたのもダメだった。もう快適な開発環境を用意してもらえないとダメだ。あとひとつの案件がコケても大丈夫なようにリスクマネジメントもしっかりやらないといけない。これば危ないぞ、と思った矢先にポシャったので、案件受ける前から考えてないとダメだ。育児に時間持って行かれてたのも大きく、対応が後手後手になったのも良くなかった。

ノーチャレンジな一年

新しいことはほとんどしなかった。クリエティブコーディングもやろうかと思ったが、楽しいけど、お金になりにくく将来性がなさ過ぎるので、既存フロント技術を学び直したり、本やブログの記事などを読んでた時間が長かった。育児もあって時間にあまり余裕がないので勉強会も行かなかった。

考え方の変化

アウトプットしなければいけないと思い続けてたが、誰に役に立つのかわからないTIPS記事を書いても、名声が上がるだけで、自分の技術力が上がるわけでもない。何より役立つ成果物生み出されるわけでもなく社会がより良くなるわけでもない。と考え始めたら、技術の話はあまりしたいなと思わなくなった。言葉でのアウトプットは有名欲というか、過剰な自分演出にしか思えない。そんな話を書いたり発表する時間があるなら、何かしらのプロダクトの開発をやったり、OSSにPR投げることに時間割いた方がよっぽど世の中の役立っている。ということを考えながら、この記事を書いている無意味さにやられている><。まあこれは自己反省なので・・・。

2018年 やりたいこと

キャリアプラン

子供も生まれ、仕事ポシャるピンチもあり、不安定さに色々滅入る時期があった。フリーランスやっている場合ではない。かと言って正社員になれるわけでもなく・・・そんなことを考えると眼前の仕事を必死に取り組むだけになってしまうのでもう少し余裕を持って働きたい。育児もあるので労働時間を減らしながら収入を安定させたい。

プライベートプロダクトを作る

今年一切できなかったこと。趣味のための開発ではなく、仕事に繋がる/繋げるための開発。これからもっと仕事も取りづらくなると思うので、何かしらやっていかなとなあとは考えてる。アプリなのかフロントなのかはまだ考えていない。

人の話を聞こう

今年は育児と仕事で時間とられて、新しい人に会ったり話聞きに行ったりはできなかった。名刺作ったけどほとんど減らなかった。 LinkedInから山のように怪しいエージェントからの「会いませんか?」メールが来るのが虚しい。業界広く歩かないと仕事にもありつけなさそうなので、来年はフットワーク軽くして動いていきたい。勉強会行ってみるかな。

まとめ

どうやって生き抜くか?それを強く実感し自分自身が変わった一年でした。来年も生き残りたい。子供のためにもどうにかしないと・・・フロントエンド開発/アプリ開発など何かありましたらお話伺いますので、2018年もよろしくお願いします。

フロントエンドに秩序を取り戻そうしている話

今月から新たな案件を引き受け始めたのですが、これが中々の地雷案件だったので、作業内容を今後のメモ的に残して置こうと思います。

問題

内容としてはページ内に埋め込んで使う汎用的なブログパーツ的なコンテンツの改修/開発なのですが、現状のソースを見るとかなりの惨状でありました。

  • jQuery + Knockout.js
  • documentファイルなし。ソースにコメント無し。何がどうなっているのか一見では掴めない・・・。
  • 基本コア機能とViewが激しく密になっている。あちらこちらで行われているDOM操作。
  • スクランナー使わずmakeでビルド(!)。
  • ファイル階層は1層のみ。jsとsassフォルダに乱雑に各種ファイルが突っ込まれているだけ。整理は全くなされていない。
  • SASS PCブラウザとスマートフォンでファイルが別れてるものの、共通ファイルがそれぞれのフォルダ用意されている(それ共通なの?)
  • SP用のソースなのになぜか-msやmozなどのprefixの指定がある。さらにはminifyされてないコンパイルされたCSS・・・。

ツッコミどころが満載で、今まで誰もツッコんでないのが不思議に思える現状。こうなっている原因は詳細はよくは聞いてないですが

  • 少人数開発による属人的な実装(ドキュメント無し/コメント無し)
  • フローとルール無き開発(開発ブランチをマスターにマージするという考えすらない)

あたりが原因かなとは思います。個人一人で開発し続けるなら良いですが、人を雇って実装を任せるにはあまりに稚拙で閉口・・・。

とりあえず改修してみる

もう怒りを通り越して悲しみしかないのですが、請けた仕事である以上やるしかないので出来るところから着手していきます。

スクランナーの導入

とにかくビルドを楽にしたいのでgulpによるビルド環境を用意。これでmakefileから開放される。watchによる自動ビルド&リロードも導入して真っ当なフロントの開発環境に。超絶便利になった!と思わせといて、これが普通ですから・・・。

ファイルの整理

Javascriptはかろうじてbrowserifyが導入されていたのでファイルの依存関係の問題はなかったので、コードリーディングしてファイルを分別。コメントを書き残しつつ整理する。以下のような分け方をしてみた。

  • classes 機能毎クラス
  • components Viewのためのクラス
  • utils 汎用関数

だいぶ機能が可視化されるようになった。

SASSは中身を精査しながら

  • common PC/SP共通スタイル
  • pc PC用
  • sp スマホ

に整理。これでファイル量が1/3くらいになった。csscombなど導入してファイルの中身も整形。さらにSASSのビルドにPostCSSをかますようにしてprefixの問題などを解消。グチャグチャだったスタイルもかなりスッキリした。

ES6に変換

今時ES5なんて書けないのでxto6を入れてjsをコンバート。ただxto6の変換はclassのコンストラクタの引数がうまく変換されないなど問題が所々あったので変換したソースをビルドして確認しつつ手動で修正。

ESLint

コードスタイルが場所によってバラバラなのも問題だったので、eslintを入れて一定のスタイルで実装出来るようにした。AirBnbベースにしてみたものの、xto6の変換があまり対応してなかったので結構な量を手動で修正。

まとめ

とりあえずフロントエンド開発環境としてはそれなりに真っ当なところまで整えることが出来た。ファイルもかなり整理されて、ストレスフルな状況からは脱した。けどスタートラインに立っただけとも言う。

今後

テスト導入

これは近々の課題。何を使うかまだ精査してないですが多分karma + mochaあたりに落ち着くと思う。

jQuery脱出

Knockout.jsが使われていながらもそれは一部で、7割くらいはjQueryによるDom操作。「今更Knockoutでもないよなー」と思ってるのでVirtualDom系の何かを使いたい。規模は小ー中規模なので、reactでもないかなと思いriot使い始めてみている。あと設計実装があまりに見通しが悪く今後付き合う気力もないので、riotcontrolを使った簡単なfluxっぽい設計に変更にしたい。

CI導入

そもそもCI使ってないのでアレだけど、自腹払ってでも使いたい。クソコードは絶対通さない強い意志を示したい。

バージョン管理

そもそも開発フローが完全に属人化されてしまっていて、PR無し&タグも切られてない、マスターと開発ブランチが大きく乖離していて、もはやマスターがマスターとしての機能がなされてない。少人数の開発だからってそんな状況はどうかしてるの、でGitFlow的な開発スタイルを徹底的にやる。

最後に

辛抱強くやるべきことを積み重ねるだけ。戦いは終わらない・・・。

参考

フロントエンドに秩序は戻ったか? // Speaker Deck

フロントエンドに秩序を取り戻す方法 // Speaker Deck

mozCamera Update

あけましておめでとうございます。今年はアウトプットの充足と営業活動も兼ねてちまちまとブログを書いていこうと思います。小ネタを乱発すると思いますが、お目汚しご勘弁を。

新年早々ですが、思い立って放置していたopenFrameworks iOSのサンプルアプリmozCameraをopenFrameworks iOS最新版v0.9.8でビルド出来るように対応させてみました。


mozCamera

github.com

v0.9.8で非対応/非推奨となった機能

前バージョンはv0.8.4でビルドできるようにしていましたが、v0.9.8に対応するに辺り、所々対応しました。

非対応

ofxiOSImagePicker

画像保存するのに使ってましたが使えなくなっていました。代わりにofSaveScreenで直接保存出来るようになっていたので代用。

ofVideoGrabber

width / heightが直接参照できなくなっていたのでgetWidth() / getHeight()メソッドで対応。

非推奨

ofSoundPlayer

loadSoundメソッドが非推奨。loadメソッドに差し替える。

ofRect

クラス自体非推奨。ofDrawRectangleに差し替える。

ofxiOSSetOrientation

クラス自体非推奨。ofSetOrientationに差し替える。

その他変更

main.mm

記述が大幅に変更。ofiOSWindowSettingsを使用する。

#include "ofApp.h"

int main() {
    
    //  here are the most commonly used iOS window settings.
    //------------------------------------------------------
    ofiOSWindowSettings settings;
    settings.enableRetina = false; // enables retina resolution if the device supports it.
    settings.enableDepth = false; // enables depth buffer for 3d drawing.
    settings.enableAntiAliasing = false; // enables anti-aliasing which smooths out graphics on the screen.
    settings.numOfAntiAliasingSamples = 0; // number of samples used for anti-aliasing.
    settings.enableHardwareOrientation = false; // enables native view orientation.
    settings.enableHardwareOrientationAnimation = false; // enables native orientation changes to be animated.
    settings.glesVersion = OFXIOS_RENDERER_ES1; // type of renderer to use, ES1, ES2, etc.
    
    ofCreateWindow(settings);
    
    return ofRunApp(new ofApp);
}

oF iOS、最後に触っていたのが二年前でした。 verytired.hateblo.jp そりゃ仕様変わるか。

Beyond Interaction[改訂第2版] -クリエイティブ・コーディングのためのopenFrameworks実践ガイド

Beyond Interaction[改訂第2版] -クリエイティブ・コーディングのためのopenFrameworks実践ガイド

そろそろ最新情報を取りまとめた方が良さそう。今年はもう少しマメに触りたいです。

2016年を振り返る

1年半ほど放置していた当ブログですが久々の更新です。前エントリに何かあったのかすっかり失念してますが(Swiftで何か作った気がしますが・・・察してください)・・・丁度年末なのでお仕事の振り返りをしたいと思います。基本的に個人語りな内容です。

ここ1年の業務実績

前置きとして2014-2015年は現在まだ鎮火していない渋谷ヒカリエ方面のD社にて社内派遣業的なポジションでフロントエンド/コーダー業に従事していました。社内プロジェクトの案件や、某Webサービスのサイト制作、業務終了直前までは某ソーシャルゲームのフロントエンド開発やらFlash制作に携わってました。

2015年10月くらいから渋谷道玄坂方面のC社のソーシャルゲームのフロントエンド案件に携わり始めたのですが、諸事情により2015年一杯でその案件とは契約終了。ただ社内の別の案件を紹介してもらい、2016年からは携わらせてもらってる某動画配信サービスのフロントエンド開発案件に関わることになり、2016年は通してこの案件に従事してました。

並行して、とあるアプリのAndroidアプリのKotlinでの開発やC++でのネイティブ部分の開発やったりしてました。これは大人の事情により途中でプロジェクトから抜けしまいましたが・・・。KotlinかわいいいよKotlin。あとC++もやっぱり楽しい。

得た経験

2015年までいた某D社は、基本的に「フロント関係にまつわるなんでも屋」で、1-2ヶ月単位でプロジェクトが変わり、タフさが求められる業務だったなと、今にして思いますが、まー、ジョイン早々にフロントエンド業務で入ったはずなのにFlashのバナーを作らされた時は口アングリでした。

そんな流れで顧みると、今年取り組んでいた案件は業務フロー、チームの雰囲気など新鮮に感じられるものでした。React+Fluxibleというナウなヤングに結構バカウケしそうな構成に加えてES6にTypeScriptも入ってくるという中々の悪魔合成で、それまでjQuery絶対どうにかするという開発しかやってなかった自分に刺激的な開発環境でした。React自体業務で使うのが初めてだったので、取っ付きこそ面倒でしたが分かってきたら面白かったですね。

仕事風景も朝10時に来てもオフィスには2,3人しかおらず、皆リモートワークを活用した環境で、うまくドライブさせていました。これが「モダンなWeb開発の現場やー」と彦摩呂のモノマネの練習の勤しんだとかしてないとか。リリース時こそ忙しかったですが、日本でもこんなに健全に開発出来る現場があることを社会に出て20年近く経って初めて知りました

これから

今の案件を長く続けることも考えましたが、現在の運用が比較的落ち着いているのと、今年第一子が生まれたこともあり、フリーランスとして活動していくには同じ状況に居続けるのは逆にリスクが高いと考え、卒業することにしました。アラフォーど真ん中の元Flashおじさんが混ざって大丈夫なのかとても心配でしたが、皆様優しい気持ちで見ていただけてありがたかったです。生まれて始めての途中で逃げ出すヤツが誰一人といない現場でした。

2017年もフロントエンド開発/アプリ開発/CreativeCoding..etcと幅広くIT土方/傭兵フリーランスとしてやって行きたい所存です。何かありましたらお声がけ宜しくお願いします。

近況

更新の間が空きましたが、辛うじて生きてます。季節はすっかり夏になりました。

春先までopenFrameworks触ってましたが、「これは面白いけど飯の種には全くならない」ことに気が付き、デモ制作は一旦停止(0.9が出たらまたやりたい)。今はcocos2d-xでのゲームアプリ開発とThree.jsを使ったデモ制作を進めてる最中。

f:id:very_tired:20150527222041p:plain:w320

http://verytired.github.io/three.js-game/app/index.html

完全に作りかけですが、githubでまるっと晒してるので一応リンク張っておきます。

ゲームロジックを組むのが開発の中心で、3D周りは完全にThree.js任せ。

Three.jsはWebGLへの理解が薄くとも使いやすいので、(やっぱり)今後のメインストリームになるのではないかと思う。 FITC2015で Mr.doobのトークを聴いたことも影響してますが。実際海外での使用事例も結構多いし、国内も増えつつある。

WebGL理解してない人間が使うのはどうなの?」という意見もあるけど、じゃあ何のためのライブラリなのか? jQueryと同じくらいの存在理由を問われてると思うので、Three.js中心の学習も有りなんじゃないかと。でもThree.js自体がまだまだ開発途中で仕様がコロコロ変わるので、基礎的なWebGLの知識はあったほうが良い。

今年後半〜来年移行はWebGLを使ったコンテンツがメインストリームになるんじゃないかと予想(もう既になってる?)。

バイトでやってるフロントエンド業務ではひたすらDOM操作をやってるわけですが、来年移行はCanvasがメインになるじゃないかなあ。っていうか、いつぞやのFlashブームのように、メインなってほしいものです。

Audio Reactive + Shader Effect by openFrameworks

以前にThree.jsで作ったものの模造品といいますか、全く同じ内容で、動画をshaderで加工しつつ、audioでリズム検出してリズムのタイミングで処理を切り替えるデモを作ったので、 Youtubeで公開してみた。

Audio Reactive + Shader Effect by openFrameworks - YouTube

www.youtube.com

難しいことは何もやっておらず先人が作ったaddonを活用して組み立てただけで、自分としては何もしてない><。自前で実装するより、あるものを有効活用させてもらった方が早い。ありがとうございます。

ソースはgithubにあげてありますのでご参考まで。

verytired/of-visualizer · GitHub

このくらいなら割とさっくり作れることがわかったので、次は自分でGLSL書いたり、 Interactrion/Visual programming周りを書いていけるようにしたいものです。

AtomからProcessingを実行するPackageを作ってみた

久々にProcessingを触り始めたところ、やっぱり標準エディタはカスタム出来ず使いづらいなと思い、Atomでの開発環境と整えることに。 もうSublimeの時代は終わったw

シンタックスハイライトのパッケージは既にあったのでそちらを利用。

Atomから直接実行したいなと思ってそのパッケージも入れてみるもエラーが出てインストールが出来ない・・・どうもバージョンが古いようだ。アップデートも全然対応してない模様・・・なので新しいバージョンでも動くように、パッケージを新たに作って移植してみた。ついでに公開もしてみました。

atom.io

processingのコマンドラインツールをインストールしてあればalt+cmd+bで実行可能。

atom結構いい感じなのでもう少し使い込んでみよう。