My talk from SassConf on October 12, 2013 in New York City.
My talk from SassConf on October 12, 2013 in New York City.
サービス終了のお知らせ NAVERまとめは2020年9月30日をもちましてサービス終了いたしました。 約11年間、NAVERまとめをご利用・ご愛顧いただき誠にありがとうございました。
だいぶ前にトレーラーを見て、一目惚れしたゲーム「Type:Rider」が、遂にリリースされましたよ。 他のことをすべて放り出す勢いでレビューします。 このトレーラーに魅せられて、ずっと楽しみにしていた…はずだったのですが、時間が経ちすぎてすっかり忘れていました。 見て聞いて、転がり感じる、フォントの世界ヘッドホン推奨です。 奥行きのあるBGMと効果音が、世界観にさらなる深みを与えてくれます。 あの大手タイプファウンドリーMonotypeがパートナーですと！ 一気に高まる期待感。 「TYPE:RIDER」！ 楽しみにしていたぜ。 画面中央の丸二つ、コロン「:」が主人公です。 タップして移動するのね。 白いアスタリスク「＊」はアイテムです。 これを取ると… タイポグラフィの歴史の1ページがアンロックされました。 なんとすばらしい、楽しみながら勉強できるというわけだすな。英語だけど。 かといって
テスト書きすぎ問題 - hitode909の日記 階層が増えるとテストが増える - はこべブログ ♨ テストと対応関係 - $shibayu36->blog; 最近書いているWebアプリは、HTTPリクエストを送ってレスポンスと状態をテストする、というテストだけ書くようにしてる。リクエストするとブログエントリを返す、というサービスだとこういう風なテストを書いてる。(HTMLを返すようにすると話が広がって説明が面倒なのでJSONを返すAPIで説明する) describe "Entry resource" do let(:params) do {} end let(:env) do { "HTTP_AUTHORIZATION" => "Bearer: #{access_token.token}" } end let(:access_token) do AccessToken.make(user
テスト書きすぎるとよくないって言ってる人がいた．DHHっていう人．作業時間の1/3以上テストしてたらおかしいとか，ActiveRecordのバリデーションなど，Railsの機能はテストしない，とか． Signals vs. Noiseの去年のエントリに、テストをどれくらい書くべきかということについてDHHが指針を示していたものがあったので... - Sooey 偉い人が言ってるからという理由で，テスト手抜き派の人に良い材料を与えてしまった．僕は意見ちがって，作業時間半分以上はテスト書いたりしてる． テストたくさん書くと，最初に書くときのコストは増える．けど，あとから読む時や，変更したい時には，読むだけだし，書くのも差分だけで良い．コード本体を理解できれば，要らないテスト捨てるのは，落ちたのを消すだけだから簡単．あとで見て，テスト足りないと分かったときに，明文化されてない仕様からテストを補う
目次 ホーム 連絡をする RSS Login Blog 利用状況 投稿数 - 1078 記事 - 2 コメント - 26545 トラックバック - 363 ニュース 著作とお薦めの品々は 著作とお薦めの品々は 東方熱帯林へ。 わんくま 東京勉強会#2 C++/CLI カクテル・レシピ 東京勉強会#3 template vs. generics 大阪勉強会#6 C++むかしばなし 東京勉強会#7 C++むかしばなし 東京勉強会#8 STL/CLRによるGeneric Programming TechEd 2007 @YOKOHAMA C++・C++/CLI・C# 適材適所 東京勉強会#14 Making of BOF 東京勉強会#15 状態遷移 名古屋勉強会#2 WinUnit - お気楽お手軽UnitTest CodeZine Cで実現する「ぷちオブジェクト指向」 CUnitによるテスト駆
Signals vs. Noiseの去年のエントリに、テストをどれくらい書くべきかということについてDHHが指針を示していたものがあったので読み返してみました。 Testing like the TSA by David of 37signals（TSAはTSAロックのTSAですね。RailsConf行く時に買った） 予想通り、DHHはなんでもかんでもテストを書くということに対してはだいぶ批判的なスタンス。 曰く、テストを書くということの裏側には、テストを書く時間、テストをアップデートする時間、テストコードを読んで理解する時間といったコストが発生しているので、テストを書くことによって得られるメリット（回避できる問題）とのバランスをよく考える必要がある、と。 議論を呼ぶことは承知のうえでDHHが提案する「Railsアプリのテストにおいて、やってはいけない7つのこと」は以下の通り。 100%の
Contributing to this website? Awesome! Use this style guide, developed by Team Sass Design. If you add new design, please document it here. Site ObjectivesSite Objectives permalink Show why Sass is the best CSS Preprocessor, and why you should use it. Be a resource for those who are already using Sass, at whatever level.
Sass is the most mature, stable, and powerful professional grade CSS extension language in the world. CSS Compatible Sass is completely compatible with all versions of CSS. We take this compatibility seriously, so that you can seamlessly use any available CSS libraries. Feature Rich Sass boasts more features and abilities than any other CSS extension language out there. The Sass Core Team has work
For full Access Subscribe to Brand New Subscription includes Full content. Polls and comments. Full RSS functionality. The Follow-up podcast. The weekly newsletter. NEED SOME CONVINCING? Whether it’s you, your boss or manager, your significant other, your parent, or your HR department that needs some objective reasons to the value of a subscription we have put together a 2-page PDF to help! Alread
iOS7上のSafariがどのように変化したかについて、Maximiliano Firtman氏（@firt）がブログで詳細に解説しています。 この記事では、同氏のブログから、Web制作者／開発者にとって重要と思われる情報を引用して、Web技術者にとっても大きな影響を持つこのアップデートについて紹介していきたいと思います。 元記事は非常に長大、かつ詳細なため、全てのポイントを紹介することはとてもできません。素晴らしい記事ですので、関心のある人は、ぜひ元記事を参照してください。 ちなみに、最初にガッカリさせることになってしまいますが、@firt氏によれば、「1.0以降最もバグの多いバージョンだ」（this is the buggiest Safari version since 1.0）だそうです… UIが大幅に変更、フルスクリーン（に近いサイズ）がデフォルトに Webブラウジングをしている
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
