タグ

2015年6月15日のブックマーク (10件)

  • pixiv小説縦書き機能 開発の裏側 ~横のものを縦にする~ - pixiv inside [archive]

    はじめましてこんにちは。pixivでアルバイトをしているhakatashiです。 さる6月10日、パソコン版pixiv小説にて縦書き表示機能がリリースされました。この開発のあらかたを担当したので、今回の縦書き機能開発における裏側を紹介いたします。 構想 縦書き機能開発にあたり、設計段階からその大部分を一任されました。小説機能開発において自分の中に絶えず理念として存在していたのは、ユーザーに最高の読書体験を提供することです。縦書きによって得られる利益を最大化し、快適な閲覧を支援するために、以下のような構想を置きました。 縦書き横書きの組版の差異における違和感を可能な限り軽減すること。 スクロールとページングを融合した、柔軟で快適な閲覧インターフェイスを提供すること。 この2点について詳しく解説します。 縦組版 まず、ウェブブラウザで縦書き表示を実現するにあたり、どのような手法をとるかという問

    pixiv小説縦書き機能 開発の裏側 ~横のものを縦にする~ - pixiv inside [archive]
    gfx
    gfx 2015/06/15
  • 祭 with Android – Google

    新しい Android の世界へようこそ。 2015 年 6 月 16 日 (火) 〜 21 日 (日) 六木ヒルズ この夏、Android 5.0 Lollipop 搭載の最新端末で毎日がもっと楽しくスマートに。 2015 年 6 月 16 日 〜 21 日の 6 日間、 Android 搭載のスマートフォンやタブレット、Android Wear、Android TV など最新 Android 端末を体験できる「祭 with Android」を開催します。 端末のタッチ&トライや、 Android の世界を太鼓やお面で楽しめるコーナーなど、無料コンテンツをたくさんご用意しています。 会場には、たこ焼き、わたあめ、ラムネのフード屋台も登場。スマートフォンで 祭 PASS をご提示いただいた方に無料で提供いたします。 祭 PASS はコチラ Android スマートフォン 2 台をバチのよ

    gfx
    gfx 2015/06/15
    “2015 年 6 月 16 日 (火) 〜 21 日 (日)”
  • Android+mockitoが動かなかった - Qiita

    Androidmockito を使う場合は、mockito と dexmaker の jar を libs フォルダに入れるだけで良いのですが、それだけだとどうも DI に失敗するパターンがあるようです。詳細までは追えていませんが、下記のパターンそれぞれに対処が必要でした(私の場合は両者の同時対処が必要でした…) パターン1 Caused by: java.lang.VerifyError: org/mockito/cglib/core/ReflectUtils at org.mockito.cglib.core.KeyFactory$Generator.generateClass(KeyFactory.java:167) at org.mockito.cglib.core.DefaultGeneratorStrategy.generate(DefaultGeneratorStrat

    Android+mockitoが動かなかった - Qiita
    gfx
    gfx 2015/06/15
    testing-support-lib 0.1に入っているAndroidJUnitRunnerこのどちらの設定もやってくれるみたい
  • さよなら哀スレッド ~ わが青春の愛スレッド - YAPC::Asia Tokyo 2014

    2003年春、仕事もなく暇な私は――ithreadsと出会った。 「それ」はとてもスロウでバギィでリークなコードクラッシャーだった。 情報収集、テストコード、セグフォルセグフォル。そして―― さようならithreads プロローグ 少々昔の話をしますと、2003年頃、私は仕事もあまりなく暇でした。それでふとithreads(Perlのスレッドシステム)関連のドキュメントを翻訳してみたのです。気づけば私は熱に浮かされたようにithreadsの情報を集め、Tipsページをつくり、初めてCPANにあげたXSモジュールはithreadsをサポートするものでした。私はithreadsの虜となったのです。 当時の情熱の一端は、今でもこのような形でその影をとどめています(もうデータも古くて使い物にはならない部分も多いですが)。 それから、そう。私の初めてのCPANにアップしたXSモジュールはThread

    さよなら哀スレッド ~ わが青春の愛スレッド - YAPC::Asia Tokyo 2014
    gfx
    gfx 2015/06/15
    “「それ」はとてもスロウでバギィでリークなコードクラッシャーだった”
  • mockito=モック伊藤

    異論は認めます。 mockito - simpler & better mocking - Google Project Hosting http://code.google.com/p/mockito/ 続きを読む

    mockito=モック伊藤
    gfx
    gfx 2015/06/15
    ふーむ
  • 第2回 設計編 | gihyo.jp

    カンファレンスの準備も大枠ではプログラムを書くことと似ています。全体の設計をせずに突き進む事も不可能ではありませんが、やはり全体像の設計を事前にしておかないと要所要所で躓きがちです。 どんなに細部がうまく実装できてもプロジェクト全体としてうまく機能しないことはよくあります。YAPC::Asia Tokyoのようなイベントもまさにそれと同じで、まずそのイベントについての大枠の設計が重要となってきます。 イベント運営をする際にこのような設計が重要になってくるのはひとえにイベント運営とは取捨選択の連続だからです。決断を迫られた際にどちらの方向に判断を倒すかという指針をアドホックに決めていると収拾がつかなくなりがちなのですが、前もって設計をちゃんとやっておけばいざという時に一貫性を持って判断ができるようになります。 What(どんなイベントなのか) 最も重要な事項の一つにそれが何を目的としたイベン

    第2回 設計編 | gihyo.jp
    gfx
    gfx 2015/06/15
    経費2000万、収入700万、1300万をスポンサーしてもらう、40~50件のスポンサーが必要
  • 「2位じゃダメ?」の事業仕分けで分かる、なぜ理系新卒が就活で面接を突破できないか

    蓮舫さんの「2位じゃダメなんでしょうか?」発言で有名な、次世代スーパーコンピュータ開発の事業仕分け。 さて、その事業仕分けなんですが、「面白い」んですよ。コンテンツとして。こんな面白いものを楽しまないなんてもったいない。「2位じゃダメなんでしょうか?」発言を知っているだけでは、ラピュタで「バルス」のシーンだけを観たことがあるようなものです! というわけで、音声ファイルと議事録を公開しておきます。晩酌のお供に、子供の夜泣きにぜひどうぞ。流し聴きをオススメします。 知っとくとよい前提知識 事業仕分け当時(2009年)、プロジェクトの雲行きは怪しかった 総予算1,154億円のうち、仕分け当時すでに100億円の予算超過をしていた スーパーカミオカンデ1個分の予算超過 当時のアメリカでのスパコン開発状況では、仮に日がスパコンランキングTOP500で世界一をとったとしても一瞬で終わることが予想されて

    「2位じゃダメ?」の事業仕分けで分かる、なぜ理系新卒が就活で面接を突破できないか
    gfx
    gfx 2015/06/15
  • 転校生の本歌取 - steps to phantasien

    ふと思い出し書き直しの話 (1, 2) の続き。 書き直しの必要に迫られることも、たまにはある。それはオリジナルが手に入らないとき。転職先で前の職場にあった内製ツールが使いたい。慣れたプログラミング言語にあったライブラリが新しい言語に欲しい。そんなときは自分の新しい環境でオリジナル相当品を書き直したいかもしれない。再発明、移植なんて呼ぶこともある。 この書き直し、再発明は、必ずしもオリジナルを超えなくていい。越えるべきオリジナルを使えない事情があってのコードだから。スポーツの試合で怪我をしたエースのかわりに急遽投入された補欠の立場に似ている。ベストを尽くし役割を果たせばいい。補欠系書き直しとでも呼ぶことにしよう。 Bazel と補欠たち 一応の役目は果たすものの、オリジナルほどはぱっとしない。そんな補欠系書き直しはたくさんある。 プログラミング言語をまたいだ補欠系書き直しとして真っ先に思い

  • 書き直さない時代の気分 - steps to phantasien

    なんとなく続き。(前回) Martin Fowler が蒸し返すまで、 自分は書き直しについてことさら何か書く気が起きなかった。 どうでもよさは時がたつほど増していった。気分の出処を見直してみたい。 部分的に書き直す 最初の理由は、書き直しがゼロかイチかの大きな判断ではないという納得かもしれない。コードの書き換えには様々な粒度がある。一番小さいのが厳密なリファクタリング。一番大きいのがフルスクラッチの書き直し。その間には様々な大きさの書き直しがある。書き直しの粒度が連続的である以上、どちらか一端を擁護する議論は虚しい。 小さい刻みの変更を積み重ねれば危険を冒さず大きな変更ができる。それがリファクタリングのテネットだ。刻みは小さいほど安全だから、良いプログラマは大きな変更を連続した小さい変更へと噛み砕く。変更の難しさに実力が及ばないと刻みが大きくなり失敗の危険が増す。バグが増えたり納期に遅れ

  • 手に関する衝撃の事実が明らかになり、ネット上騒然!!!!(画像アリ):暇つぶしニュース

    4: 名無しさん@おーぷん 2015/06/14(日)07:06:00 ID:vDb あっ、当だ 今まで曲がっている感覚だった

    手に関する衝撃の事実が明らかになり、ネット上騒然!!!!(画像アリ):暇つぶしニュース
    gfx
    gfx 2015/06/15
    まじか…