削除済 - mizchi's blog
スターエンジニアはキラーアプリを生み出すのか？ - mizchi's blog
日本Web技術界隈著名人の残念さ具合 - thinkchangの日々日誌 は内容自体はどうしようもないのだけど、テーマ自体は自分も日頃悩んでいたものなので書き出してみる。あ、そういえば行方不明のmalaさんは一昨日のハッカソンで振り向いたらいたんで大丈夫です。 キラーアプリの出現と技術的イノベーションに相関あるかと言われたらあるとは思うけど枯れた技術の水平思考的な余地も十分あるんでキラーアプリが必ずしも技術的なイノベーションを果たしている必要はない。ただし技術優位がない場合は企画レベルで制限かかるので、それを許容するかどうかという話— 賢さを上げて法で殴る (@mizchi) 2015, 8月 24 技術的イノベーションによって可能になったサービスはたくさんあって、たとえばデータベースを使った動的なウェブサービス、2000年前ごろにPerl CGIが現実的な速度で動くようになってから増えた
Flux設計論 - mizchi's blog
scala.jsの実用が真面目にペイされる環境を考えると、jsとscalaのアダプタ部分を考える俺と、scalaレベルで何ができて何ができてないか考える俺が二人いればプロダクションで成立しそう— ガソリンの味 (@mizchi) 2015, 4月 28 Scala.jsが生きる場所、たとえば次のプロジェクトはウェブ版シムシティを作ることですって言われたら、ドメイン部分がピュアでかつ複雑になるのでScala.jsを選択するのはありだと思う— ガソリンの味 (@mizchi) 2015, 4月 28 ドメインがピュアでかつ複雑、基本的にatljsが活かせる部分なので、人によってはpurescript選んでもよいわけだし— ガソリンの味 (@mizchi) 2015, 4月 28 アダプタの書き方が altjs => js か js => altjsかで運用勘が結構変わる— ガソリンの味 (@m
node.jsで Isomorphic フレームワーク作ってみようとしたら超辛かった - mizchi's blog
現状どんな実装があるかはここみてください Isomorphic JavaScript - The future of web app development 主張 Node.jsは現状フロントエンドユーティリティに最も適している Node.jsは一般にサーバーサイドでの運用は難しいし、自分もそう思う どうせやるなら、Node.jsにしかできないことをやるべきだ Node.jsのキラーアプリはRailsクローンではなく単体ソースからクライアント・サーバーのコードを同時に生成するIsomorphicフレームワークであるべきだ。 これだけは他のフレームワークには絶対に真似できないので、一応可能性は検証すべきだ 自分で実装することで、MeteorとかDerbyはなぜうまくいってないのかも考えたい というわけで Isomorphicなフレームワークを自分で作ってみたいと思っていた。 今ならせめてCo
何もやる気が起きない - mizchi's blog
たまに、突然に謎のやる気で包まれて、やりたいことを書き出して、アレもコレもと一つづつ手を出して、そのうちに徐々に熱意は発散していき、最後には何も残らず負の感情だけがぐるぐるとしているときがある。今がそれだ。 自分には、こういう時に、「思ったことを全部書き出す」ってのを、定期的にやってしまう癖がある。これはそういうテキストで、そしてそれを公開することを、あまり恥ずかしいとは思ってはいない。少なくとも、今このときは。 最近の悩み 自分が好きなこと、得意なことをやるのは、やる気が少なくていいけど、コストが低いけど、それじゃいずれ、次の波にのれなくて死んでしまうのではないか。そう感じることがある。 そもそも好きなことと思っているのは、本当に好きだったんだろうか。得意と本当は好きは違うけど、自分がそれが一致しているのは、自分が他人より優れていると証明したいだけだから、得意なことだけに逃げ続けているの
仕様の決まる速度で実装する - mizchi's blog
最近プロトタイピングの仕事が多くて、とにかく雑に実装して、これでいいかデザイナかディレクターに確認とって、そこでリファクタみたいな過程をとることが多い。技術的にどこまで可能か未検証で、かつ仕様もはっきり決まっていないので、手戻りを最小にするためにとにかく早い段階でデモをみせる。 技術的にどこまで可能なので、どうすると開発が楽で、どこから先が大変で、どこから先が不可能かを説明しながら、その場で仕様の隙間を埋めたり、時には仕様を変更することがある。プロトタイピングの段階で勝手に一部の仕様を決めちゃって、事後追認してもらってるときもある。そこで、説明しながらその場でコードを書いてる。 エンジニア同士のペアプロは、コードを書く過程そのもの意味があるから、すべての過程をみせることに意味があるんだけど、非エンジニアに自分の席の隣に来てもらって、説明しながらの作業だとエディタを長い時間みせるわけにはいか
技術的負債という(非エンジニアにとっての)隠しパラメータが生産性100倍を起こす - mizchi's blog
元糞コードマイスターとしては、生産性については思うところある。 技術的到達深度が深い人じゃないとそもそもかけないコードってのももちろん存在して、その前提で10倍とか100倍になりうる話をする。 そもそもマイナスになる人がいるって話。 隠しパラメータをモデル化 エンジニアA:「週に10の成果を出して3の負債を生む人」を考える。この人は開発を止めてリファクタリングをすれば10-3 = 7の技術的負債を返却できるとする。 ここで正確には成果10には* aの係数が掛かっている。これはプロジェクト開始時1.0で、技術的負債が貯まるほど0に近づいて行く 次に、エンジニアB:「週に15の成果を出して10の負債を生む人」を考える(これにも係数aがかかる)。この人は見た目上は上の人の1.5倍速く成果を出しているように観測できるが、負債もたまりやすい。リファクタしても綺麗になりにくい。 これは割とエンジニアに
力への意志 - mizchi's blog
(この記事は闇 Advent Calendar 2013 - Adventar の8日目です。) コンプレックスの話をする。 僕がプログラミングを始めたのは、2008年の夏、大学1年の夏休みだった。大学のサークルの新歓を巡ったはいいが、どこもかしこも絶望的につまらなくて、当時エンジニアとネットウォッチャーしかいなかったTwitterをみていると、彼らがとても楽しそうに見えていた。 だから僕はTwitter漬けになって、一人でプログラミングの勉強をすることにした。大学では最低限の単位を確保しつつ、とりあえずなんでもいいからアプリを作るぞと、はてブで流れてきたホットそうな技術をひたすら手につけてみた。とにかく、新しそうなものをやるという戦略だった。 最初にやったことは、ゲーム用だったWindowsのデスクトップマシンを潰して、ひたすらUbuntu8.04をインストールしては、Railsのサーバ
ウェブエンジニアの生存戦略 - mizchi's blog
最近、この話題について経営者目線の話が多かったので、エンジニアのスキル獲得戦略とその最大化という観点から話をする。 まず目下のウェブエンジニアとして一番の課題は、「35歳定年説をどう乗り切るか」、ということだろう。もちろん、みんな35歳定年説なんてのが、まやかしであるとはわかっている。若い業界だったウェブ業界も成立してからだいぶ経ち、結果として平均年齢が押し上げられ、自然と35歳以上のエンジニアも増えてきた。 問題は、人月という概念によって、できる人間とそうでない人間の区別がされていないことだ。ウェブエンジニアとしての悲哀や業界の歪みはここにあると思う。下手に謙遜したりして話をややこしくする前に言ってしまうと、自分をできる側の人間として話をする。 生産性を測る確固としたメトリクスがないのも事実だと思うが、すくなくとも熟達した人間と未経験者がおなじ1人月というのは、到底ありえない話だと思う。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
