最近、業務と趣味の副産物で、一日に1~2個のnpmモジュールを作っている。基本的にGithubで公開している。 node界でそういうことをしているのは主に substack (James Halliday) 氏だ。 趣味と仕事の横断 自分は基本的に、仕事で使うテクノロジーと趣味で使うテクノロジーを合わせていることが多い。会社ではツールを作っていても家では同じテクノロジースタックでゲーム作ってたりする。 最近だと mizchi-sandbox/ar2 がそれに該当する 会社のコード、自分はあんまり家に帰ってまで触りたいという気持ちがあんまりないんだけど、どうせ家でもコード書いてて、業務中のコードを切り出してOSS化してあると家で触るモチベーションになって便利。 趣味でノウハウが溜めて、業務にフィードバックするというループに載せることで、26歳としてもそこまで高くない社会人としての自覚をコーデ
ここでプレーできる。Chrome/Firefox以外はしらん。 http://mizchi-sandbox.github.io/ar2/ gyazoのフレームレートが低いけど、実際には60FPS出てるはず。 リポジトリはここ mizchi-sandbox/ar2 · GitHub 昔作ってた mizchi/actrogue · GitHub と似たようなのを、物理エンジンのっけてReactとSVGで再現したら楽なんじゃないか、という発想で作り始めた。ReactとSVGのパフォーマンス面での技術検証でもある。 なにこれ 物理エンジンを60FPSで回してSVGに形状をマッピングしてReactで差分描画する。 この方式の利点は、SVGで簡単な形状を手書きしながら高速にプロトタイピングでき、描画速度も最低限確保できる点にある。弾幕を生成すると大量のオブジェクトが飛び交うので、下手に人間がチューニン
追記2 Sun Nov 23 2014 17:12:29 GMT+0900 (JST) 書いた時点でいくつか事実誤認があったようで、このまま変に拡散するよりも本文を取り消させていただきます。情報が非常に限られた状態での思い込みで記事を書いてしまい、ご迷惑おかけしました。指摘してくださったはてブの皆様ありがとうございます。 今現在、この件についてなんらかの意見を持ってはいません。変に消すと誤解を生むので、記事自体は残しておきます。 追記1 Sun Nov 23 2014 15:28:27 GMT+0900 (JST) 全然追ってなかったけどブコメで2chの書き込みの件把握しました 自分も多少そうだったんだけど、政治とか意識高い系の学生団体とかがウヨウヨしてるキャンパスにプログラム多少書ける人間として通ったりしていると、君すごいね～とおだてられてああいうことに巻き込まれる確率高くなるんだけど、
これ @mizchi がIncrementsにJoinしました - Qiita Blog 特に転職したとは一言も報告してなかったけど、先月末でQuipperを退職し、二週間ほどのモンハン廃人を経て、先週からQiitaを運用しているIncrementsで働いている。 自分が使ってるサービスのドッグフーディングが出来て、将来性があって、大きすぎずに自分の手が届く範囲にやり甲斐があり、JavaScriptエンジニアとして自分にとっての技術的課題がたくさんありそうなIncrementsに行くことにした。 一週間ぐらい働いて、やっと慣れてきて、デプロイももう何度かやったし、Githubのstatsみると一週間で25000行ぐらい書き換えてユーザーの手元に届いてるっぽいんだけど、これは最初に取り組んだのが外部アセットを連結して圧縮したりこねくり回したりしたりするという作業で、作業量以上に行数に出ている
HTML5 花火大会 - jsdo.it - Share JavaScript, HTML5 and CSS jsdoitのやつ、自分でもやりたかったので、パーティクル制御書いてみた。連打すると花火が飛ぶ (最初の一発がはてなブログの初期化とぶつかって重い…) (Firefoxで動いてないのは後で直す) ライブラリ化した mizchi/hanabi bower install hanabi で入る。 使い方も簡単 window.addEventListener('load', function(){ var hanabi = new Hanabi({x: 100, y: 100}); hanabi.fire() }); 打ち上げたい座標をいれてfire 花火大会に行く予定はないです
迷ったらシンプルな方— 片手間以上 (@mizchi) 2014, 7月 19 僕は主にUIを作るエンジニアなのだけど、以下の話題について。 時間をかけて、つまらないものを作りたいか？ - futoase.hatenablog.com ニコニコ動画はSynvieプロジェクトが原型 - はてな村定点観測所 UIの有効性を証明する仮説とその検証において、ほとんどの場合において次の二つが根源的な問題となる。 だいたいのものはシンプルな方が勝つ 人間はシンプルではない 二点間の距離を求める三平方の定理は、(ディスプレイが歪んでいない限り)簡潔でシンプルだが、二点のボタンを順番に押すときのマウスの軌道、そのあいだのユーザーのメンタルモデルの変化は、まったくもってシンプルではない。 人間はシンプルなものの価値を認めたがらない、というバイアスがある。金を産まないといけないソフトウェア開発の現場は、コアフ
最近、というか昨日からTypedCoffeeScriptの開発再開してAST 気分が盛り上がってるので、簡単なチュートリアルでも。 この記事でやること ASTの取得 ASTの生成 JavaScript の出力 やらないこと 構文解析 準備 適当にプロジェクト作ります。 $ mkdir tinyaltjs $ cd tinyaltjs $ npm init # 色々聞かれるけどEnter 連打で良い $ npm install escodegen esprima prettyjson --save esprima はJavaScript のコードをASTに変換。 escodegen は AST から JavaScript を生成。どっちもConstellationさん製 escodegenはConstellationさん製で、彼はesprimaにもコミットしてます。この界隈に来ると基本的に彼
@mizchi / Quipper 自己紹介 @mizchi- 竹馬 光太郎 ソフトウェアエンジニア / Quipper まず名古屋方面へ 自分について よく燃えるブログ うるさいTwitter 経歴 2008 大学入学(文系) 2012.3~ Aiming ゲームエンジニア(フルタイム) 2013.9~ Quipper ソフトウェアエンジニアに中途転職 2014.3 学部6年生で大学卒業 来年度から業界3年目の新卒？？？？ それはさておき 大学時代にやってたこと 最低出席日数を確保し、 サークルへも入らず、 バイトもせず、 家にこもってTwitter 家にこもってゲーム 家にこもってプログラミング独学 ↑ これの話する 当時(2008年)のTwitter ほとんどエンジニア みんなリテラシー高い(非エンジニアもすごい) なんか楽しそうだしプログラミングやってみるか 大学以前のプログラミン
あるいは、何を書かざるべきか。 自分の中でブログを書く基準は二つある。 Twitterであらぶって気づいたら140字超えてた場合 酒飲むなどして意識が高まった時に本音が出てあれはこーだろーとうんうんと同意がとれた場合 最近は肩の力抜いて書こうとしていて、無闇にホッテントリ狙わずに下手なレトリック使って読者を歓待したりもせず、脱力して書こうとしてる。ひとでくんのブログに影響されたのが大きいけど、僕はあんなに綺麗な澄んだテキストが書けない。素直な技術記事以外は、濁りきった汚泥みたいなテキストになる。 ただ、こういう言い方はあれだけど、はてブ砲の為の、二段階ロケットの一段階目としての程度の固定読者がついたブログなので、何をどれぐらい書けば何時に何ブクマぐらい行くか、だいたいわかる。そうなると分かった瞬間、それ用に書きなおす。指標としてそれなりにブクマこだわってるけど、別にはてな民だけに書いてるつ
最近、この話題について経営者目線の話が多かったので、エンジニアのスキル獲得戦略とその最大化という観点から話をする。 まず目下のウェブエンジニアとして一番の課題は、「35歳定年説をどう乗り切るか」、ということだろう。もちろん、みんな35歳定年説なんてのが、まやかしであるとはわかっている。若い業界だったウェブ業界も成立してからだいぶ経ち、結果として平均年齢が押し上げられ、自然と35歳以上のエンジニアも増えてきた。 問題は、人月という概念によって、できる人間とそうでない人間の区別がされていないことだ。ウェブエンジニアとしての悲哀や業界の歪みはここにあると思う。下手に謙遜したりして話をややこしくする前に言ってしまうと、自分をできる側の人間として話をする。 生産性を測る確固としたメトリクスがないのも事実だと思うが、すくなくとも熟達した人間と未経験者がおなじ1人月というのは、到底ありえない話だと思う。
ロンドンへの飛行機(11時間)で暇だったから書いた文章。 自分でゼロからすべてのコードを書けるときはテストファーストでいいけど、アンドキュメントな実験的なライブラリを利用する際や、巨大なプロジェクトの一部としてコードを書く際は、テストファーストよりもとにかくコードを書きまくって挙動の変化を確かめるほうが有用な時がある。 まあ多分どっかでこういうのはハウツー化してあるんだろうけど、自分ルールが固まってきたので、メモっておく。 目的を設定する トップダウンに読むには、コスパが悪いことが多い。とにかく「アレする」「コレする」という目的を定義して、そのためにその周辺領域からボトムアップに読むことにしよう。 エンドポイントを追う 巨大なプロジェクトに放り込まれた最初の段階では、エンジニアは本当に無力だ。 最初にやることは、自分が処理を挟むべき位置を見つけることだろう。 まずはファイル名や関数名を読ん
自分がほしい機能がひと通り、大雑把に実装が終わった。とはいえ、推論が壊れるケース、壊れないケースは自分しか認識できていなさそうなため、自分で直す気力がある人以外が触れるのは推奨しない。 まだコードが汚く、コンフリクト考えずに大雑把に書きなおしているので、あまりPRしたりされたりするのは想定していない。今リファクタリングに取り組むところなので、それが終わったらオナシャスみたいな感じはある。 明日から仕事でロンドンに行くのだけど、暇な時間はやはりこれに取り組んでいると思う。 ロードマップ 仮としてv0.5とv1.0というのを設定する https://github.com/mizchi/TypedCoffeeScript/issues?milestone=1&state=open v0.5 ホビーユースが可能な品質 あと幾つかの機能追加で達成可能 switch文、 and or ? などの論理演
今リリース前にしてはタスクがあんまりないのでブログ書いてみる。 Quipperに入社してから一ヶ月半ほど経過した。それで感じたことをあれこれ書いてみようと思う。 あんまり熱心に書くと前の会社に入ったばかりのことを思い出して恥ずかしくなったりするので、ほどほどにする。 エンジニア文化の共有 会社に入ってまず最初にやることは、エンジニアが文化を共有することだと思う。 どんなマインドかは、僕より Quipper のスピード感 - @kyanny's blog とかを読んだ方が伝わるはず。 QuipperはOSS文化というかRuby文化的なものを強く志向している感じがあって、そこらへん馴染みやすかった。 入社してからやったこと まず前提として、ベンチャーなので整った教育制度などはない。(そもそも自分も研修など期待していない)。 エンジニアとしての文化を共有しているから、最初からすぐ仕事に入れた。具
[注意] まだまだ全然使いものにならないよ！ プロジェクト名をリネームした mizchi/TypedCoffeeScript https://github.com/mizchi/TypedCoffeeScript 構造体と関数リテラルを追加した。今は次のコードが通る。 struct Point { x :: Number y :: Number } p :: Point = {x: 3, y: 3} f :: Number -> Number = (n :: Number) :: Number -> n * n console.log f 4 f の関数型のところはわざと冗長に書いている。正直、型アノテーションを通すパーサが書けただけで推論は全然完璧ではない。 宣言済みのプロパティに代入しようとした瞬間だけバリデーションしている。関数型も返り値が一致しないと代入できないようにはなってる。引
たぶん僕は人類の怠惰を極めたようなcoffee-scriptの文法が好きすぎるのだけど、その結果型を書けるcoffee-scriptを作り始めてしまった。 Fork元はCoffeeScriptRedux mizchi/CoffeeScriptRedux https://github.com/mizchi/CoffeeScriptRedux/tree/type とりあえず今の版だと次のコードが通る。 目標 x :: Number = 3 y :: String = "hello" z :: Boolean = false # z :: String = 4 #=> Error # y = x #=> Error a :: Any = 3 a = 'fadfa' b = 'a' fn :: Function = -> x = 3 n = -> i = '' f2 :: Function = (
小学生の時、自分が女の子殴ったとかそんな理由で学級会開かれて(実際は意図せず箒の柄があたっただけなんだけど)、バカらしくなって自分では仏頂面決め込んだつもりでいたら、ニヤニヤしてんなふざけんな！って言われて教師に思いっきりぶん殴られたことある— 性格は糞 (@mizchi) 2013, 10月 9 意図せず箒の柄があたったのを被害妄想で殴られたと思ってしまういじめられがちな女子と、意図せず当たったという主張が認められない程度には教師に信頼されてない生徒だったので、学級会悲惨だった— 性格は糞 (@mizchi) 2013, 10月 9 素行が悪いのは事実だったけど仏頂面のつもりが笑ってるつもりに見えるのはだいぶ面倒アレだなと思ったけどたぶん25になっても何か考えてる時は常にニヤニヤしてるらしいので全く直ってない— 性格は糞 (@mizchi) 2013, 10月 9 教師に対する不信、小6
2chまとめみたいなタイトルにしてみた。(してみたかった) HTML5のアーキテクチャと初期化とキャッシュの考え方が、「ウェブエンジニア」は本当に出来てない。 とくにソシャゲをウェブビューに貼ってスマホ対応しました系。本当にダメ。 じゃあどうするか？基本的に「初期化」の考え方を直せばどうにかなる。 (この記事はBackboneを使うときに考えてることだけど、他でも一緒だと思う) 前提 シングルページアプリケーション セマンティクスやSEOは考慮しない 基本哲学 共通モデルの初期化を徹底的に行う サーバーにリクエストを投げるのは最小限 クライアントでサーバーモデルのキャッシュを作り、更新が期待されるまで再取得しない 理由 いくらDOMの最適化したところでUXに影響が大きいのはサーバーリクエスト(200~2000ms)で、プログラミング段階で辛さがあつまるのは非同期処理の部分。 プログラマとし
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く