github という公的なインフラを使うために必要なこと - アンカテ を盛大に dis っとかなきゃなという気持ちになった。 Pull Request ベースの開発 階層型組織構造 は特に対立するものではないですし、階層型がいいのかフラットがいいのかは場合場合によるでしょう。階層型でばりばりに管理するような開発チームでも ディレクターが issue を起案する 開発リーダーとディレクターがプロダクトマネージャーなどを交えてスケジュールを決定する 開発リーダーがその issue を閉じる Pull Request を作る人とそれをレビューする人を決定しスケジュールを伝達する 所定のタイミングでリリース権限を持っている人がマージボタンを押す みたいなカチカチした運用でいろいろやっていけると思いますし、これでも Github Flow というか Pull Request ベースの開発の恩恵を十

よいデザインがなにかを論じるのはむずかしい作業ですが、わるいデザインをあげつらうことはそれとくらべればかんたんなものです。 ここで最悪なデザインについてかんがえていきましょう。 こういうものをかう人は、これらの虫を不快だとかんじているからかうわけです。にもかかわらずこれらの害虫のリアルな絵がえがかれていることでいったい誰がしあわせになるというのか。 ほんとうにクソだしデフォルメした絵にしてほしい。 back to index of texts Site Search

これ マッキントッシュ フィロソフィーのトロッターシリーズ 一見ただのスーツなんだけど、ジャージ素材でできてて、着心地は完全にジャージ。 ジャージを着て外出することは通常最寄りのコンビニまでしか許されていない(佐賀県民や群馬県民、栃木県民はもっと遠くまで外出することを特別に許可されている)のだけど、これを着ていると本当にどこにでもジャージで外出することが出来る。 ジャージを着ていると本当に楽なので便利。ネックはちょっと価格が高い。ジャージでどこにでも行きたい人には本当におすすめです。 ジャージ素材なので家庭の洗濯機で洗うことができて、しかもそうやって洗濯しても全く型崩れしないのも便利。 しかし一つ問題があって、 IT 技術者は見た目で他人を差別するレイシストが多いのでスーツを着ているとバカにされる場合がある。そのあたりは適宜やっていきましょう。 back to index of texts

UI エンジニア云々にかかわらず、プロダクトに深い理解をしめして幅広い範囲でコミットしてくれるメンバーが(しかも年収 600 万円とかで)ほしいみたいなのがよくあります。 しかしそんな優秀な人が入ってくればあなたはお払い箱で、あなたがただのマネージャーならば解雇されますし、あなたが企業のオーナーだとすると優秀な社員は VC と結託してあなたを追い出します。 なのでそれなりのメンバーをうまく組み合わせてやるほうがいいです。 back to index of texts Site Search

という言い方が最も適切かどうかは別として、比較的頻繁に執り行われております。内装をそんな感じにするとか、中学高校っぽい部活やるとか。 で。そういうのいいですねみたいな声が大きいので、そうなっていく IT 企業が多いのですが、 ガキっぽいエンジニアは声が大きい というだけで、 優秀なエンジニアは子供っぽい というわけでは絶対にないと思います。子供っぽいオフィスを用意しとけば優秀なエンジニアが集まるかというとそうではなくて、それで逃げていく優秀なエンジニアも確実にいます。 優秀なガキっぽいエンジニアみたいのがいないというわけではないですから、そういうタイプの人とそうじゃない人が住みわけられるようなオフィス設計というのがあってもいいのではないかと思ってます。 こちらからは以上です。 back to index of texts Site Search

DHH の主張って TDD は糞だ TDD によって「テストのしやすさ」が主眼となるため設計がむしろ歪む DCI は糞だ、 Concerns でいいだろ Concerns の結果として超絶巨大なドメインモデルが実行時に作られたところで知ったことではない とかそんな感じで、ある種の複雑さを許容しよう。結果として最適な設計を得られる。というような感じのことが多いと思ってます。 ソフトウェアというのは元来複雑なものです。結局のところ、その複雑さをどのレイヤーで受け入れるかというのが、ソフトウェア開発の本質の一つではないかと思います。 DHH の主張というのは、それを薄く広く受け入れろというようになっている。 一方で TDD や DCI の仕組みって人に何かをアサインする人が全体的な整合性を整えて、あとの人は目の前の問題解決に注力するみたいな形になりがちで、中央集権的と言えると思う。 つまらない話

これ http://emija.hatenablog.com/entry/2014/03/11/231940 の話です。 Web のパフォーマンスは我々の共通の懸案ですから、真面目に考えていきましょう。 当該 URL で調査 広告オン時 Adblock した時 いずれもキャッシュ無効です。 結論 広告ベタベタ増やしてる + WiMAX のルーター置いてる場所がなんかダメなのが悪いんじゃないの？ 参考資料 読み込みに使ってるページはこれ http://blog.livedoor.jp/dqnplus/archives/1790719.html 痛いニュース広告オン 痛いニュース Adblock なんとなくブログ界隈全体が表示遅いんじゃないかという気がしますね。 ちなみに以下はうちのサイト さらにいろいろ調べた結果 ブログだいたい Adblock して 4 秒ぐらいで表示されてしてないと 8

これの話。 次のような二つの職場があったとしたら、優秀なプログラマの大部分は前者を選ぶのではないでしょうか。 テスト・CI をきちんとやっていて、ソースコード管理は Git & GitHub、もちろんデプロイもほぼ自動化されていて、過去のバージョンに戻すことも簡単にできるため実験がやりやすい。リファクタリングの価値が認識されている。タスク管理ツールや連絡ツールも新しいものを積極的に採用している。権威的な人間がおらず、設計やコードの良し悪しを率直に話し合える。年収 400万。 テストもろくにない Java のコードを手元の Eclipse でコンパイルして、その .class ファイルを WinSCP でコピーしてデプロイしている。バージョン管理システムはろくに活用されておらず、間違えたらおしまいなので PukiWiki の手順書に「～を厳守する」という心構えが出てくる。ファイルを zip

昨日の夜買って読み始めたら朝の 10 時に読み終わった。いろんな人がいろいろ感想書いてるからごちゃごちゃ書くことはしない。 「利口な UI」というコラムが序盤にあった。これは「バカにプログラミングさせるとビューにロジックが集中する」「かといってバカにはモデル駆動開発は無理」という話です。極めて説得力を感じるのですが、この問題に関して最後まで読んでも特に解決策は載ってませんでした。 優秀なエンジニアがその辺にいくらでも生えてるということは稀なので、教育とかいう難しいやつをやる必要がある(難しい) — トデス子 (@todesking) February 22, 2014 というようなのが現実だと思います。ここから得られる課題は、「利口な UI」しか書けない人をどのようにモデル駆動開発に耐えられる専門家に教育するかという点です。 ある程度の人間が「ビジネスサイドの人間と会話する共通の言語を基に

はすべてこのサイトのデザインに表れています。絶対にこれが正しいと思っているし、色の使い方とかそういうことを考える前に色を使うのをやめてほしい。 back to index of texts Site Search

というようなのよく言われますがこれは間違っていて 生産性の低いエンジニア: ある閾値を越えたものは作れない 生産性の高いエンジニア: 生産性の低いエンジニアの作れないものでも作れる というような感じであることが殆どで、生産性の低いエンジニアに 10 倍の時間を与えたからどうにかなるというようなもんでもないでしょう。 時間が何でも解決すると思ったら大間違いだ。 back to index of texts Site Search

ssig33.com 初心者が２ヶ月でプログラミングをマスターする方法 そんなものは無い back to index of texts Site Search

さてはてな民のみなさんが大好きな英語の話題です 300 ブクマぐらいしていいんですよ。 ここ数年ぐらい英語圏の人達と作業をする機会が散発的にあり、英語力というものについて考えさせられることになりました。 英語が下手とか周囲の人に言われる人の特徴というのがなんとなく見えてきました 協調性が低い 専門分野における知識が糞 だいたいそんなところじゃないかと。専門分野における知識がある人が多少英語が下手だったとしても（あるいは多少以上に下手だったとしても）周囲が気を遣ってくれますし、あるいは通訳を雇ってもコスト的に問題ないみたいな話になる。 まあ逆の事例もありまして、専門知識が無い英語ネイティブが、専門知識の無さ故に会話についていけなくなった結果、専門家にたいして「英語が下手で何いってるか分からない」とか言うことでプライドを保とうとする事案についても見かける機会が結構ありました。まあこれは対処のし

結論: 程度問題だし個別に判断しろ この辺に関する話 http://mizchi.hatenablog.com/entry/2013/09/07/171644 http://shunirr.hatenablog.jp/entry/2013/07/01/000944 http://d.hatena.ne.jp/gnarl/20120407/1333725733 退職時に古巣に後ろ足で砂をかけるようなブログ記事をかけるような人達がいる。それに怒っている人達がよくいる。という訳で個別の事例について考えていきましょう。 mizchi 技術力はそこそこある。人格は糞。月給 24 万とかだったらしいし 24 万が新卒として安いかというと、まあ安くもない。絶対的に人的資源としての価値だけ考えれば多分微妙に安い。彼は「成果」を主張しているが結局あの地獄の JS プロジェクトそんなに売り上げたってないっぽい

みたいの結構良さそうな感じがするんですが。実際そうではないです。 運営はユーザーからのクレームやサービスの問題点を大声で議論をします。エンジニアは大抵気が弱いので四六時中聞かされていると会社を辞めてしまいます。 また運営は四六時中エンジニアから「そんなこと言いますけどそれ実装するの無理です」と言われ続けますからストレスで会社を辞めてしまいます。 そうして誰もいなくなる。残るのは悪意に鈍感なウスノロだけでそんな奴は使い物になりません。なので大抵の場合運営と開発はある程度物理的に距離をとってしまうほうがよいです。 ですがまあ距離を近くしよう的な策が取られることが多いです。これは何故かというと、「企業家」「経営者」といった連中は上記のような地獄をとおりぬけてきた人間や、それをなんとも思わないような人間だからです。その辺こういう話に近いと思います。 雇われてるだけの人間は精神壊す前に逃げましょう。

使ってから言及しろと思うわけです。 新しい Google Play Music UI が Windows 8 っぽくなって猛烈に重くなりました。スクロールがガクガクで曲再生しながらスクロールしたらブラウザ(Google Chrome)落ちた。 Android アプリのほうはどうなってるのか知らん。 例によってアメリカからしか新機能は使えません。アメリカ人以外からは Web がゴミになっただけ。 新しい Google+ Google は使い辛い SNS の頂点を極めようとしているのだと思います。幅の広いシングルカラムは素早く読むことが出来、幅の狭いカラムが複数並んでいるものは欧米人が視覚的には好むが実際には読み辛いことが各種の実験から知られています。 つまり新しい Google+ は見栄えだけをとり実質的な使いやすさはゴミ箱に捨てているということになります。実際使ってみると分かりますが驚異的

延々と議論されるテーマですが、実態として 綺麗なコード: 動く 汚いコード: 動かない であることが殆どだと思いますので、あえて汚くする理由がどこにもない。 back to index of texts Site Search

本当に基本的なことを書きます。これから書くのは本当に基本的なことです。ですが以下のことへの理解が足りない事例をよく見ます。その結果の悲劇もよく見ます。 経営者の皆さんへ あなたの会社の社員はあなた程仕事へのモチベーションがありません。あなたが掲げる理念をあなた程信じてもいません。当然です。あなたと同じようにモチベーションがあり、あなたと同じように強烈な信念があれば、あなたと同じように起業するはずです。 もしあなたが仕事のモチベーションも信念もなく適当に会社を売り抜ければそれでいいなどと考えているならば、あなたのその価値の無い仕事は売り抜けることなど出来ないでしょう。 経営者の皆さんは起業した自分の理念に命を賭す価値があると信じていることでしょう。実際その価値は本物かもしれません。ですがあなたの会社の従業員は給料に見合っただけの労力を提供すればいいと思っています。そんなもんです。社員があなた

なんか最近そういうの流行ってるようですね。僕も考えを書いてアクセス数を稼ぎます。 ページ遷移を過度に抑えようとするな 下手に AJAX 使いまくるぐらいならページ遷移したほうがマシであることが多いです。世の中にはページ遷移を抑えようとして酷いことになってる JS を沢山見ます。よく考えろ。 ローカルストレージを活用しない localStorage に画像とか放りこむの異常に重くなるのでオススメしません。認証持たないサービスで設定値保存するのに使うとかに留めた方がよいと思う。 非同期な API 絶賛してて気に食わない感じはしますがこの記事を一読することをお勧めします。 localStorage は小さなデータをいくつか入れる分には十分に高速です。大きなデータを入れると十分に低速です。 scroll イベントに対してリスナーを置かない scroll イベントの監視は実際最悪のアイディアです。こ