タグ

2014年4月21日のブックマーク (11件)

  • 「超チューニング祭 ~ニコニコを超快適にしてみた~ in ニコニコ超会議3」の問題点 - Webパフォーマンスについて

    来る2014年4月26日(土)・27日(日)に、「ニコニコ超会議3」が開催され、その中で「超チューニング祭 ~ニコニコを超快適にしてみた~」が開催されるそうです。 これは、現行のスマートフォンサイトのTopページのソースファイルを競技者がチューニングして、速度やデザイン・UIの改善をして、速度と使い勝手を競うのだそうです。 「これは面白そうだ! 会場は家から近いし!」と思って参加するつもりでいましたが、事前調査で計測してみた結果、フロントエンドのチューニングでは速くならないことがわかったので、その内容について説明します。 (主催者の方にも、フロントエンドのチューニングでは速くならないという情報は伝えてあります。) まずは、計測データ まずは実際のトップページ(http://sp.nicovideo.jp)の計測データを見てみましょう。 計測は、NTT DoCoMoとSoftBankの3G回

    「超チューニング祭 ~ニコニコを超快適にしてみた~ in ニコニコ超会議3」の問題点 - Webパフォーマンスについて
  • booleanメソッドのネーミング講座(Java編) - 意識の高いLISPマシン

    僕は、booleanメソッドを命名するとき、なんとなくis○○とか付けていました。 でも、○○は形容詞なのか、名詞なのか、文なのか?が曖昧なまま、 コードをゴリゴリ書いていました。 命名規則を曖昧にしたまま月日が経つと、 だんだん自分の付けた名前に嫌悪感が募るものです。 「すっきり!」を目指して、命名規則を調べてみました。 調べてみる(Javaを中心に) 命名規約 【Okapi Project】 2.9.4.boolean 変数を返すメソッド boolean 変数を返すメソッドについては、「is + 形容詞」「can + 動詞」「has + 過去分詞」「三単現(三人称単数現在)動詞」「三単現動詞 + 名詞」のいずれかの名称をつけます。特に動詞は三単現以外の動詞は利用してはいけません。また、true の場合がどちらであるか判別しやすい名前にするために通常は true の場合を名称にします。

    booleanメソッドのネーミング講座(Java編) - 意識の高いLISPマシン
  • DevLove関西で「課題をテストで解決する」という発表をしました - $shibayu36->blog;

    DevLove関西に行ったので、「課題をテストで解決する」という発表をしてきました。 内容はスライドに書いてあるとおりです。以下のことを特に話したくて、今回の発表をしました。 何度も起こる課題があったときに人が気をつけようとしない 最悪のケースでは根原因を知ろうとせず、間違えた人を怒ることで解決しようとしてしまう 何度も起こる課題なら、機械に自動的にやらせる その例として今回はテストでやりましょうという話をした あとテストいろいろあって始め方がわからないという時は、こういう課題をテストにするというところから始めるとやりやすいかもしれない 参考 この資料作るにあたってひたすらブログ書いたので参考にどうぞ 設定の仕様をドキュメントに書くのではなく、テストにしてしまう - $shibayu36->blog; ドキュメントの場所を知らせるために、落ちるテストを作る - $shibayu36->b

    DevLove関西で「課題をテストで解決する」という発表をしました - $shibayu36->blog;
  • 似非プロジェクト科学(1) - 勘と経験と読経

    ソフトウェア開発プロジェクトに限ったことではないかもしれないけれど、一見正しいようで不適切なことを求められることがある。疑似科学じゃないけれども、似非プロジェクト科学としていろいろ考えてみている。もちろん、単なる政治の問題なのかもしれないけれども。 疑似科学 - Wikipedia ブルックスの法則、あるいは規模の不経済 この手の話で一番有名なのはブルックスの法則だろう。つまり、「遅れているソフトウェアプロジェクトへの要員追加は、プロジェクトをさらに遅らせる」というものだ。 「9人の妊婦を集めても、1ヶ月で赤ちゃんを出産することはできない」 ブルックスの法則 - Wikipedia この原因の一つにはメンバー間のコミュニケーションパスが、プロジェクトメンバーが増えるに従い爆発的に増加するからだ。ブルックスの法則は遅れているプロジェクトのリカバリに焦点を当てているけれども、遅れていないプロジ

    似非プロジェクト科学(1) - 勘と経験と読経
    teracy_junk
    teracy_junk 2014/04/21
    『ブルックスの法則、あるいは規模の不経済』
  • 問題形成チャートについて - 千里霧中

    少し前に佐藤允一さんの問題構造の書籍を読んでいたが、そこで説明される問題形成チャートが書籍で解説される問題構造をうまくまとめていて良かったので、今回紹介したい。なおこのチャートは結構昔に提唱されたものだけれど、REBOKに似た図が使われている等、今でもある程度普及しているようだ。 問題形成チャート 問題形成チャートは以下のような形を取る。主に問題の構造を明示化するのに使われる。 なお注意として、これは問題の因果関係を図化するのではなく、問題を産んだ一連の活動を図化する。例えば「テスト漏れによるバグ流出」という問題について図を描くならば、Whyツリーのようなバグ流出の要因の連なりを描くわけではない。その時のテストのやり方を図に展開して、結果として目標と現状の間にバグ流出という問題が発生している、という図を記述する。 各部の説明だけれど、この図の定義においては、問題は「目標と現状のギャップ」と

    問題形成チャートについて - 千里霧中
  • 2014年、春のGit事情 - fujimuradaisuke's blog

    なんとなく最近どんな感じでGitを使っているか、適当にリストアップしてみた。 よく使うやつ git status git status --branch --short にしている。変更されたファイルが出る。とりあえず何をしたかざっくり把握する用。sにエイリアスしている。一日100回くらい実行しているのではないか。 git diff 特にオプションは指定していない。何をしたかしっかり把握する用。dにエイリアスしている。一日50回くらい実行しているのではないか。 git grep バージョン管理しているファイルから渡した単語を含む行を検索、表示。関数の検索などあらゆる場面で超便利。オプションは --line-number --show-function --color --heading --break がオススメ。 git ls-files バージョン管理しているファイルのファイルパスを表

    2014年、春のGit事情 - fujimuradaisuke's blog
  • 見習いJavaプログラマ向け10冊+α(2014年版) - カレーなる辛口Javaな加齢日記

    http://d.hatena.ne.jp/JavaBlack/20101203/p1 の焼き直し. とくにピアソン桐原の撤退の影響が大きい.*1 前回と同じく,あくまで一例であることは断っておく. プログラミング言語 Java 第4版 作者: ケンアーノルド,デビッドホームズ,ジェームズゴスリン,Ken Arnold,David Holmes,James Gosling,柴田芳樹出版社/メーカー: 東京電機大学出版局発売日: 2014/05/10メディア: 単行この商品を含むブログ (4件) を見る定番Java言語解説書.ピアソン桐原撤退の時には一度絶版になって泡ったが,他社より再出版されたので一安心. EFFECTIVE JAVA 第2版 (The Java Series) 作者: Joshua Bloch,柴田芳樹出版社/メーカー: 丸善出版発売日: 2014/03/11メディア

    見習いJavaプログラマ向け10冊+α(2014年版) - カレーなる辛口Javaな加齢日記
    teracy_junk
    teracy_junk 2014/04/21
    『和書では名著でも絶版になるのは珍しくない.良いと思った書籍は見つけた時に確保しておくか,さもなくば英語で読めるようになっておくかした方が良いだろう』
  • iOS開発とGitタグ

    いままでAppleにアプリを申請するタイミングでタグを打っていて、 その後にリジェクトされると以下のようなタグが残ることがありました。 非常にダサいですね。 1.0.0 1.0.0-2 1.0.0-3 最近は少し学習して、QAに入る段階でrelease/1.0.0といったブランチを切るようにしました。 審査に出した段階ではまだタグは打たず、もしもリジェクトされた場合は引き続きrelease/1.0.0を更新します。 審査を通過した場合はそこでタグを打って、release/1.0.0をmasterにマージします。 以下の図のようなイメージです。 このように運用することで、余計なタグが打たれることはありませんし、審査中のバージョンを見失うこともありません。 もしかしたら普通のiOSデベロッパーは当たり前のように実践していることなのかもしれませんが、 自分は最近までダサいタグを打ったり、タグを打

    iOS開発とGitタグ
  • 僕が1週間でWebサービスを公開するまで - ぐだぐだ言ってないでコードを書けよ、ハゲ。

    先日、FeedlyGraph を1週間で公開した。 photo credit: surfzone™ via photopin cc 公開までを振り返ってみる。 0日目 アイデア出し 僕は普段からこんなサービスが欲しいな〜というアイデアをメモに残すことにしている。 iCloud 便利。 今回はそこから規模感が合うものをチョイス。 1日目 アイデアの検証 問題を解決するサービスが世の中にあるかどうかを確認した。 今回は「Feedly の購読者数の推移を確認したい」が問題。 既にあった解決策に近いものは以下のとおり。 Feedly Insight Feedly Subscribers Checker 2 FeedlyやlivedoorReaderの購読者数をGrowthForecastにポストするRubyスクリプト作った 上から順に WordPress でないと使えない 今の購読者数しかわからな

    僕が1週間でWebサービスを公開するまで - ぐだぐだ言ってないでコードを書けよ、ハゲ。
  • | タイトルを入力してください

    ブログをはじめるたくさんの芸能人・有名人が 書いているAmebaブログを 無料で簡単にはじめることができます。

    | タイトルを入力してください
    teracy_junk
    teracy_junk 2014/04/21
    自分が好きなものを推す為に他をdisると大炎上するってばっちゃが言ってた
  • 「よりよいコードを求めて命名について頭をひねる会」のログ

    http://www.zusaar.com/event/438105 アプリケーションを作る英語 の著者の西野さんを交えて、クラス名とかメソッド名とか変数名とか命名で困っている課題を1つ以上持ち寄りみんなで一緒に検討する勉強会をしました。 「アプリケーションを作る英語電子書籍 http://tatsu-zine.com/books/english4app 紙 http://www.amazon.co.jp/gp/product/4844332848/ はじめに:西野さんからちょっとお話 The Art of Readable Code から第2章と第3章 第2章:名前に情報を詰め込むようにする どういう情報をつめこむか。 明確な言葉を選ぶ get は不明確らしい getPage(url) -> FetchPage(url) や DownloadPage(url) 特色のある(color

    「よりよいコードを求めて命名について頭をひねる会」のログ