タグ

ブックマーク / postd.cc (95)

  • テスト駆動開発(TDD)はもう終わっているのか? Part 1 | POSTD

    後編を公開しました(2014/10/8) これは、テスト駆動開発(TDD)とTDDがソフトウェア設計に与える影響についてKent Beck、David Heinemeier Hansson、および著者の3人で行った一連のディスカッションの議事録です。 ディスカッションに至った経緯 あるセンセーショナルな発言とブログ記事が発端となり、お互いの見解と経験について理解を深める目的で、話し合いが持たれました。 この会話のきっかけとなったのは、 DavidがRailsConfで行った基調演説です。 彼はRailsコミュニティでTDDおよびユニットテストへの不満を表明しました。 程なくして、彼はいくつかのブログ記事を公開しましたが、そのうちの最初の記事で “TDDは終わった” と宣言したのです。 それから2~3日後、Davidのその後の記事について私がタイプミスの修正を送ったところ、 Davidは彼の

    テスト駆動開発(TDD)はもう終わっているのか? Part 1 | POSTD
    efcl
    efcl 2014/10/07
    TDDは死んだのハングアウトの記録
  • MediumのCSSはこの上なく最高! | POSTD

    自分は常に最高であれって思っている。最高の香りを身にまとい、最高の振る舞いをする。ごみ1つ捨てるのだって、ほかの誰よりイカしてなきゃ。 ―Lil Wayne ずっと長いこと恥も外聞も知らずに、MediumでCSSについて執筆しようと思っていました…。 それからどうなったって? 違うことをやっていた? 何てこと、どうやったら同じことができるかって? やり方を教わりたいって? これから書くことは私たちのCSSについての覚書で、これまでに歩んできた道のりと現在のCSSについて述べています。 始まり(これまでの道のり) だいたい2年ほど前、私はソフトウェアアプリケーション開発と(皆さんが読んでくれているといいのですが) medium.com に取り組むためにObvious Corp.に加わりました。 その時、Mediumは、すでに一連の”スタイル更新”を行っていました( スタイル更新とは デザイナ

    MediumのCSSはこの上なく最高! | POSTD
    efcl
    efcl 2014/09/19
    MediumのCSSの変遷 "人々は困惑していました。さらに悪いことには、実際はそうでないにもかかわらず、みんな自分はとてもうまくCSSを書いていると思っていたのです。" これはありそう
  • リモートワークチーム用の究極のツールボックス:必須ツール15選 | POSTD

    The Ultimate Toolbox for the Remote Team: 15 Tools You Can’t Live Without by Matt Boyd Sqwiggleの共同設業者で、熱心なリモートワーカー。他には執筆やドラム演奏も。コーヒー愛飲者。Twitter Sqwiggleは、リモートワークチームのための常時"繋ぎっぱなし"ビデオチャットアプリ。PCのカメラより定期的に作業の様子が共有され、呼び出しや同意の必要がなく、実際に話しかけるように1クリックですぐに会話が始めることができる。 リモートチームの一員である場合、適切なツールを見つけるのは難しいことがあります。企業文化の決定、進捗、生産性には欠かせません。ツールの選択次第で会社を作ることも壊すこともできるので、適切なツールを選んでいるか確認してください。 テクノロジーに意味はありません。大切なのは人々を信じ

    efcl
    efcl 2014/09/17
    リモートワークツール集。Sqwiggleの人
  • デバッグを必修科目にするべき理由 | POSTD

    更新版: まずはここで私がコンソール ロギングでのデバッグを非難したり、無視しようとしているのではないということをはっきりさせておきたいと思います。コンソール ロギングは組み込み型プログラムやIDEがソースコードをスタックフレームに正しくマッピングできない場合、ブレークポイントが進捗を妨げてしまう場合等、様々な場合に使われます。要は他に適した方法がある時にコンソール ロギングを使うことを悪いと思っているのです。 プログラミングでは新しい機能を加える代わりに、 コードのメンテナンス と問題の解決にそのほとんどの時間を費やされるということが常識になっています。また、デバッグを通じて問題を発見できてもそのバグの解決方法がわからないということが多いのです。また ハイゼンバグやネッシーバグ のような再現できないバグに遭遇することもありますが、通常はどこを探すべきかが全くわからない状態で、大規模なコー

    デバッグを必修科目にするべき理由 | POSTD
    efcl
    efcl 2014/09/12
    デバッグについての教育。 デバッグ手法についてのコース例
  • 抽象化と組み合わせができるレイアウト言語があれば、CSSは必要ない | POSTD

    Web上の視覚的なスタイルを指定するCSSは、あまりにも複雑で、恐らく今までに一度も正確に実装されたことはないだろう。それにもかかわらず、バージョンが上がるにつれて、その複雑さは増すばかりだ。一方で、CSSではできることが限られており、初歩的なデザインでさえ不可能であるか、あるいは法外に難しいことも少なくない。加えて状況依存的(または計算的)な側面を持つものは、すべて外部で対応しなければならないという有様だ。その結果、CSSに関するほとんどの手引きでは、希望する外観に何とか近づけたり、非互換性を回避したりするための頼りないハックに多くの労力が費やされている。 – Bret Victor 私は近年、クライアントサイドの開発技術を数多く見てきました。そして、その中でも特に興味深いと思ったのが Elm です。関数型のプログラミング言語としては、Elmはそれほどワクワクするようなものではありません

    抽象化と組み合わせができるレイアウト言語があれば、CSSは必要ない | POSTD
  • 型安全性とは何か | POSTD

    以前書いた(C言語についての) メモリ安全性について定義した記事 について、型安全性について説明する記事も投稿してほしいというコメントがありました。型安全性についてはかなりよく知られてきていると思いますが、ズバリこうだと簡単に定義できるほどにはまだ理解が浸透していません。特に誰かが”Javaは型安全な言語だ”と言った場合、これは厳密に何を意味するのでしょう。全ての型安全な言語はある意味”同じ”と言えるでしょうか。ある特定の言語について、そして一般的な意味で、あなたを悩ませる型安全性とは何でしょうか。 実際のところ、型安全性が何を意味するのかは言語の型システムの定義によります。最もシンプルなケースでは、型安全性はプログラムの動作が正しく定義されるように保証します。もっと一般的な話をすると(この記事ではそのあたりをカバーするつもりですが)、言語の型システムはそのプログラムの正確さと安全性を推論

    型安全性とは何か | POSTD
    efcl
    efcl 2014/09/04
    型安全とは何かについて
  • クラスの「継承」より「合成」がよい理由とは?ゲーム開発におけるコードのフレキシビリティと可読性の向上 | POSTD

    コード構造における重要な問題として、複数のクラスを共有する場合に合成と継承のどちらを用いるかという点があります。“has a”の関係と、“is a”の関係と言われる2つの対比です。例えば、“ソファには綿が入っている”と、“ソファは家具である”という違いのようなものです。この例では2つの違いは非常に明白ですが、実際には、“has a”の関係でも“is a”の関係でも意味を成すケースがたくさんあります。ゲームのキャラクターについて、これはコリジョンボックスを持っているかと聞くのと、これは衝突可能なオブジェクトかと聞くような場合です。この2つは全く同じことではありませんが、それぞれが(または両方一緒に)衝突を処理する主構造として用いられ、どちらの方がよいかは必ずしも明白ではありません。私の経験では、直感的には継承の方がよいと思うことも多いのですが、それだと問題がたくさんあって結局は合成の方がよか

    クラスの「継承」より「合成」がよい理由とは?ゲーム開発におけるコードのフレキシビリティと可読性の向上 | POSTD
    efcl
    efcl 2014/09/03
    継承と合成。 ゲーム的なのだと合成のほうが柔軟に対応しやすい
  • 爆速HTML – Elmでの仮想DOM | POSTD

    新たな elm-html ライブラリでは、HTMLCSSElmで直接使用できます。FlexBoxも使ってみたいし、既存のスタイルシートも使い続けたいですか? Elmは使いやすくなり、処理が 速く なりました。例えば、 TodoMVC アプリを再作成する場合、Elmの コード はとても単純で、 事前のベンチマーク でも、他の人気ライブラリに比べ処理速度が極端に速いという結果が出ています。 elm-html とMercuryは、どちらも virtual-dom プロジェクトを基にしているので、パフォーマンスが優れています。この記事では、前半で“仮想DOM”とは何か、 純粋性 と 不変性 によっていかに処理速度が上がるかということについて詳しく検証します。この検証によって、なぜOm、Mercury、Elmがベンチマークでこのような素晴らしい数字を出したかが分かるでしょう。 パフォーマンスは人

    爆速HTML – Elmでの仮想DOM | POSTD
    efcl
    efcl 2014/08/28
    mercuryをベースとしてelm-htmlについての翻訳。 Virtual DOMの仕組みについて分かりやすい。mercury触ってたので記事書いた http://efcl.info/2014/08/28/mercury/
  • モダンなWebプロジェクトにおけるベストプラクティス | POSTD

    Oktavilla では、私たちは定期的に新規プロジェクトを立ち上げています。数年にわたって、私たちはこうしたプロジェクトを通してベストプラクティスを見つけ出してきました。そのおかげで、新規メンバーがスムーズにプロジェクトに参加できるようになり、エラーを減らすこともできました。こうしたベストプラクティスを、組織内部、クライアントを問わず大半のプロジェクトに活用しています。結果として、私たちは高品質のWebプロジェクトを実現しています。ここでお伝えするのは、そのプロセスの一部です。 このブログ記事では、技術面に関わるベストプラクティスに焦点を絞りたいと思います。例えばセットアップや、プロジェクトのツールやプロセスを選択する際に考慮すべきことなどについてお伝えします。各プラクティスの文末に、詳細な情報へのリンクをいくつか貼っています。 READMEファイル まずは、プロジェクトで最も重要なファ

    モダンなWebプロジェクトにおけるベストプラクティス | POSTD
    efcl
    efcl 2014/08/04
    プロジェクトの設計。 README、VCS、コミット、pull request、GitHub Flow、パッケージマネージャー、デプロイ
  • Webページレンダリングについて知っておくべきこと: ピクセルは高コスト | POSTD

    Web開発者として、ユーザの画面表示にピクセルがどのように関わるのかということは知っておくべきでしょう。知ることが目的なわけではなく、効率性のため画面表示を最適化する際にその知識が必要となってくるからです。 先日、「 フロントエンド開発者がWebページレンダリングで知っておくべきこと 」を読んだのですが、重要なポイントを外してしまっている印象を受けました。その記事で強調されていたのは、CSSセレクタのマッチング、レイアウト(FirefoxのようなGeckoベースのブラウザではリフロー)、そして レイアウトスラッシング という名でも知られる強制同期レイアウトに注意することです。確かに、これらは気をつけたほうがいいことだとは思いますが、私としては、ページレンダリングについて開発者が知っておくべきことをその記事ですべてカバーしていたとは思えません。大抵の場合、Web開発者は60fpsの表示を目指

    Webページレンダリングについて知っておくべきこと: ピクセルは高コスト | POSTD
    efcl
    efcl 2014/07/31
    ブラウザの描画レイヤーと合成composeについて。
  • 機械学習とは何か? – 機械学習の定義と使える言い回し | POSTD

    この記事で、取り上げたいのは 「機械学習って何?」 ということです。 機械学習に興味がある人なら、少しはその内容について、かじったことがあるでしょう。ですが友人や同僚に機械学習の話をふると、誰かに「機械学習って何?」と質問されるリスクがあることを覚えておいてください。 この記事の目指すところは、機械学習について考えるための定義、それも覚えやすい気の利いた言い回しをいくつか提案することです。 まずは、この分野で信頼のおける教から機械学習のスタンダードな定義について触れるところから始めましょう。それから機械学習についてのプログラマ的な定義をはっきりさせ、最終的には、「機械学習って何?」と聞かれても、いつでも答えられるようになるのが目標です。 信頼できる定義 それでは最初に、一般的に大学の講義レベルで、よく使われている機械学習の教4冊から見ていきましょう。信頼できる定義であり、この問題を熟考

    機械学習とは何か? – 機械学習の定義と使える言い回し | POSTD
    efcl
    efcl 2014/07/17
    機械学習とは何かという定義な話
  • GitHubでの”Merge pull request”の弊害 | POSTD

    私は GitHub が大好きです。GitHubはオープンソースへの コントリビューション (寄与貢献)を何十倍も容易に、そして楽しいものにしたと思います。ですが、GitHubがPull RequestというwebのUI形式で前面に押し出しているオープンソースの メンテナー のワークフローが、プロジェクト品質とコントリビューションを受けつけるスピードの弊害になるということに気がつきました。そこで、GitHubの Pull Request にある「Merge pull request」ボタンをクリックする前に、少しお話をさせてください。 メンテナーの紹介 ジェーンはそこそこの成功を収めているオープンソースプロジェクトのメンテナーです。彼女は毎週プロジェクトGitHubリポジトリに上がる新しい Issue を確認し、リクエストに対し速やかにフィードバックを返します。リクエストをすべて実行する時

    GitHubでの”Merge pull request”の弊害 | POSTD
    efcl
    efcl 2014/07/09
    githubのpullrequestを自分で取り込む際にhub amを使った方法について。 pull requestを取り込んだ履歴がMerge ...だらけにならない
  • CSS will-changeプロパティについて知っておくべきこと | POSTD

    はじめに WebKit系ブラウザでCSS transformanimationといったプロパティを使った時に発生する、“例のちらつき”。これに気づいたことのある人ならば、おそらく“ハードウェア・アクセラレーション”という用語をこれまでにも耳にしたことがあるでしょう。 CPU, GPU, ハードウェア・アクセラレーション 一言で言うと、ハードウェア・アクセラレーションとは、グラフィックス・プロセッシング・ユニット(GPU)を用いてセントラル・プロセッシング・ユニット(CPU)の処理量を軽減し、ブラウザのレンダリング処理を効率化することです。ハードウェア・アクセラレーターを有効にしてCSS処理を使うと、ページのレンダリングが速くなり、ページ表示が高速化されます。 名前の通り、CPUGPUはどちらもプロセッシング・ユニットです。CPUはコンピュータのマザーボードに取り付けられている部品で、ほ

    CSS will-changeプロパティについて知っておくべきこと | POSTD
    efcl
    efcl 2014/07/04
    GPUを使うためのtranslate3dというハックではなくwill-changeというそれを用のプロパティについての話。 予めて変化するものをブラウザに伝える事で最適化し、変化後に削除する。 CSS animationのチラツキの軽減とハードウェアア
  • JavaScriptフレームワークはもうこりごり | POSTD

    JavaScriptでフレームワークを書くのはもうやめましょう。 JavaScriptフレームワークというものは、あたかも避けられない死と税金のようなもの、絶対にぶちあたる避けられないものといわれています。こっそり聞いてみましょう、新しいウェブプロジェクトが始まるとき、一番初めに聞かれる質問は?十中八九は「どのJSフレームワーク使っているの?」でしょうね。昨今の業界においてJSフレームワークというものは当に根深く浸透しているのです。でも、だから必須だというものではないのです。実際、もう使うべきではないのです。 どうしてこういった結論に至ったのか、振り返ってみましょう。 AngularにBackbone、Ember・・・ ここのところ長い間、 ウェブプラットフォーム とはHTML+CSS+JS、と簡潔に技術用語の羅列でまとめられてしまっていましたが、そこにはもっとぴったり表す用語“大混乱”

    JavaScriptフレームワークはもうこりごり | POSTD
    efcl
    efcl 2014/06/22
    一つの何でも入りフレームワークと、小さいライブラリの組み合わせ
  • JavaScriptの読み込みにおける非同期スクリプト注入の悪影響 | POSTD

    Synchronous(同期)スクリプトは効率が悪い。というのも、ブラウザにDOM構築をさせ、スクリプトを読み込ませ、残りのページをリロードする前に実行してしまいます。今さらな話ですが、これがわれわれプログラマがasynchronous(非同期)スクリプトをよく使うようになった理由です。ここに分かりやすい例があります。 <!-- BAD: blocking external script --> <script src="http://somehost.com/awesome-widget.js"></script> <!-- GOOD: remote script is loaded asynchronously --> <script> var script = document.createElement('script'); script.src = "http://somehos

    JavaScriptの読み込みにおける非同期スクリプト注入の悪影響 | POSTD
    efcl
    efcl 2014/06/21
    script injectするパターンとasync属性を付けた時の違いについて。 サポートしてるブラウザの違い以外と実行順序が保証されない以外はasync属性の方がよい。