読者です 読者をやめる 読者になる 読者になる

Shut the fuck up and write some code

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

クソプロジェクト案件と向き合う・その後

クソプロジェクト案件と向き合う - Shut the fuck up and write some code

前回の続きです。

課題の対応

  • コードを書くよりもドキュメントを書くことに集中する
  • Readableなコードを書くことを最重要とする。

上記二点を守るように実装するコード書きつつコメント周りを充実させていった。これにより自分自身の理解度も深まったと思う。 しかしそれでも元々のコードが持つ実装意図がつかめないし、そもそもDBのテーブルが何を表し、そのデータは何の使われているのか、理由も意図も分からないのは変わらない。コードを動かしつつ、出力結果を見てひたすら判断する作業を続ける。ドキュメントやソースに実装意図のコメントがあればこの作業もだいぶ軽減されるはずなのだが・・・一番キツイのはある程度動作するように実装して仕様の理解も深くないので「この実装で問題ないでしょうか」とレビューを依頼したところ「正しく動いてるかどうか自分で判断しろ」と返されたことだ。いや自分の判断が間違ってないかを確認してもらいたくてレビューをお願いしているのだが・・・。私は「あなた」ではないから、正しいかの判断は100%のレベルでは出来ない。こんなブーメランが返ってくるとは想像つかなかった。

  • スケジュール

前回から仕事の進捗状況を観察するに、自分のスケジュール管理がされないということは、こちらもそれほどスケジュールに関して意識しなくても良いということらしい、という点に気づく。

観察

このプロジェクトが成功することは望ましいが、冷静に判断するに、ここから大きくステップアップする状況は現場にいる人間からは想像するのは難しい。プロダクトの質も決して高いものが担保されているとも思えないし、いま開発している人間が誰かがいなくなる可能性を全く想定していない時点で、短期的な計画プランだろうなと想像しやすい。

クライアントが求める立場であることが自分の仕事だし、上記の問題は声高ではないが進言してはいるものの改善されないので、自分の判断が決して正しいものと決められるものではないでしょうか、おそらく自分の意見は求められてないところなんだろうなと思う。一言で言えば「こっちの思うような動き方をしてもらえればそれで良い。それ以上もそれ以下も求めてない。」

結論

クライアントの関係がWIN-WINであるために、こんなプロジェクトの中で自分はどう立ち振る舞うべきか。「 プロジェクトの成功率を高めるのではなくクライアントの満足度を高める」という点に着地するのだと思う。プロジェクトの動きを観察するに、どう見てもプロジェクトの成功を目指した動きはしていない。そもそも、このプロジェクトもまた上にクライアントがいる。そして彼らの動きは自分から全くブラックボックスだ。彼らの言葉は自分の耳には届かないが、彼らの言葉でこのプロジェクトは回っているのは確かだ。そして、その大クライアントの満足度を高めることが目的となっている時点で、自分は手の打ちようがないのである。目の前の敵を倒しても、もっと大きな敵がいる。

生き残るために

自分個人のQoLを高める施策に走る。

  • 自分自身の工数削減
  • ナレッジを貯める

この2つを徹底的に掘り下げていくことだろう。とにかく時間をかけない。自分の時間を切り売りはしない。

そして少なからずとも今の仕事で得た知見を他にどう活かすかを考える。正直活かせるようなものではないが、コードを書く量を増やして経験値として積み重ねる。


一番の課題がこのプロジェクトを途中でドロップアウトするが終わる前に次の案件を見つけることだ。年齢的にも本当に大変だ。この戦いが終わっても、戦いはまだ続く。

クソプロジェクト案件と向き合う

Programming 雑記

はじめに

今関わってる案件にかなり大きな問題があり、正直逃げ出そうと思ったが、この案件の状況を良くしていくことがスキルアップに繋がるとも考えられるので、少しずつ改善していくための考えをまとめて行きたい。コーディングのHACKを書くことも重要なのでしょうが、こうした人的な取り組みもHACKとしてやっていければと思う。

現状の問題点

チーム周り

チーム人数が少ない

現状3人ほどの開発体制。開発工数をまかなえる人数ではあるが、人数が少ないことによるチームビルディングの浸透性の無さが問題。一応担当分掌は別れているがリーダー自ら開発している。それほど密なコミュニケーションしていない。進捗報告など一切無し。他の担当の人が何を作ってるのか深く理解していない。

スケジュール管理がほぼなされていない

リーダーから短期でこなすタスクが上から降ってくるのでそれをこなしていく開発スタイル(自分は日雇い労働開発スタイルと呼んでいる)。ガントチャート的なものもなく中長期的な開発計画は口頭では説明されるが明示化はされてない。プログジェクトとして一体どのフェーズで進んでいるのかわからないし、リリースのための状況(α版を作っているのか?ベータ版を作っているのか?も良くわからない)も把握出来ない。突然今日から社内テストだと言われることもある。

コード周り

README、ドキュメントと言ったものがほぼ無い

特殊な用語なども多くコード一読しただけでは分からない。オリエンテーションはされているが、資料が存在しないので復習することもままならない。

コードに一切コメントが書かれていない

ドキュメントもなくコメントもないので、メソッド名から推測しながら処理内容を読もうとするが、メソッド名と実際の処理内容が異なる箇所もあるので、メソッド名通り受けようとすると間違える

対応

現状、チームで開発しようという体制になってないのでまず、第三者がジョインしてもスムーズに開発環境に入れる環境を作ることが最優先だと考えている。自分もその人間だが、今の状況はかなりストレスフルであり、まずは1次情報を見つけ出すことをで時間をとられコードを書くことに集中できない。自分のパフォーマンスを上げるための作業を最優先してみる。

コードを書くよりもドキュメントを書くことに集中する

まともなコードを書くことは状況的に難しいのでまずは情報収集した結果をとりまとめていく。git add README.mdするところから始める。

Readableなコードを書くことを最重要とする。

第三者が見てもすぐ理解出来るコードを書くことを最優先する。極端な話、実処理コードよりもコメントが多いソースにする。無駄な処理が多いとか言われてもパフォーマンス・チューニングのタイミングに入るまで指摘は無視する。

チームビルディング

スケジュールの明示化と進捗管理を最低限やるのは至極当たり前の話で、情報が別のところに集まっていれば各種ツールでガントチャートを作るなど自分でスケジュール管理などしてしまうのだが、如何せんすべての情報をリーダーが握っており、ヒアリングしても明快な回答ももらえないので、現状ではチームでスケジュールを管理するのが難しい。そもそも小さい会社なので上層部に訴えるなどの強権発動ことも出来ないし、個人を説得するしか方法が無い。

スケジュール管理は諦めて日雇い労働開発スタイルに勤しむしかない現状。いつ開発が終わるのか不明瞭だし、まともに休みも取れるのかわからない。旅行を行くのはかなり難しいと思ってる。

現時点では良い策がないので、先の個人開発環境周りの整備をやっていこうと思う。

最後に

今関わってる案件は、いつぞやのNode.jsの分裂みたいなことが起こってもおかしくないOSSコミュニティに近いものがあるかもしれない。個人の集まりではなくチーム/プロジェクトに寄り添う動き方が出来るようにならなければ、成功しないだろうな。と傭兵歴4年のおじさんは思うのであった。IT傭兵はクライアントのために動きますが、負けが見えてる戦争には加担したくないのです。

PDCA回しつつ、一ヶ月くらい経ったらまた続きを書きたい。

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

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

Javascript

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

問題

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

  • 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

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

新年早々ですが、思い立って放置していた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土方/傭兵フリーランスとしてやって行きたい所存です。何かありましたらお声がけ宜しくお願いします。

広告を非表示にする

近況

Three.js

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

春先まで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

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周りを書いていけるようにしたいものです。