開発合宿で何を考えてどう作ったか - Hatena Developer Blog
こんにちは。はてな社長の id:chris4403 です。 この記事ははてなエンジニアアドベントカレンダー2014の14日目です。元エンジニアということでカレンダーに参加させていただきます。 先日、はてなのサービス開発合宿が開催されました。 合宿の開催概要については、先日チーフエンジニアのid:onishiがエントリを書いているのでそちらをご覧ください。 私もいちエンジニアとして参加したので、合宿の間、何を考えてどうやって作ったのかを書き記そうと思います。今後合宿に参加する人の何かの参考になればと思います。先に断っておきますが、あんまり技術的な話は出てきません。 day 1 AM 今回の合宿は、合宿の1週間ほど前に、作るサービスや機能の具体的なアイデアを持っている人が、参加者の前でプレゼンを行い、一緒に作る人を募るというチームビルドのフェーズがありました。私もそこに向けて、リッチメディアを
Ractive.js の紹介 — KaoriYa
HTML の DOM 操作を良い感じで隠蔽してくれる Ractive.js というライブラリを紹介します。 本記事は VirtualDOM Advent Calendar 2014 の13日目の記事です。 VirtualDOM といえば React だ、と言わんばかりの流れですが、本記事では敢えて Ractive.js を取り上げます。Ractive.js が VirtualDOM かって? 確かめてみましょう。 良し、大丈夫。VirtualDOMです。 Ractive.js とは? Ractive.js は本家サイトの説明を借りれば、テンプレートドリブンなUIライブラリです。なんのこっちゃわからないでしょうね。 まずVirtualDOMのメリットとは 生のDOMを直接操作しなくても、JavaScriptのオブジェクトだけを操作すれば、上手いこと自動的に書き換えてくれる ことだと言えます。
Xcodeコメントの基本 - Toyship.org
これはiOS Advent Calendar 2014の12日目の記事です。 年の瀬もだんだん押しせまってきました。 年末年始のお休みの後に、「あれ、このメソッドどんな目的で作ったんだっけ？こっちのメソッドとの関係はどうだったんだっけ……」など無駄に悩まないために、このあたりでソースコードのコメントを見直してみましょう。 Xcodeでのコメント そもそもソースコードにコメントを書いた方がいいかどうかは長い議論がありまして……。 コメントによりコードの理解は深まるので、あったほうがいいという意見もありますが、コメントを書いたあとにコードを変更してしまうと、コメントとコードの内容が違ってしまい、かえってバグを生んでしまうためコメントを強制するのは害悪だ、という考え方もあります。 また、適切な命名規則を守ればソースコードを読むだけで理解できるという考え方もあります。 実際には、プロジェクトのライ
【初心者向け】Mac OSX10.8(Mountain Lion)で Ruby on Railsを動かすための5ステップ « pplog.org
We are constantly updating our collection of different sources. All content absolutely free!
家族写真の可聴化について - Qiita
このエントリーは家庭を支える技術 Advent Calendar 2014の2日目として書かれました。 家族写真は、就業時に家族のことを想起し奮闘する上で重要なツールです。しかしながら、一般的なオフィスにおいては自席以外でくつろいだ姿勢で設計やコーディングを行うことがよくあります。 そういった状況において、家族写真のような家族を可視化するツールを持ち歩くことはあまり現実的ではありませんが、作業に使うコンピューターに家族の声を利用して一定の情報を可聴化するようなツールを導入しておくことで、その機能を代替することができます。 本稿では家族写真を可聴化によって代替するために、私がここ1、2年の間にとっている手法を紹介します。 寝た方がいいということを教えてもらう もう寝ろよ というGoogle Chrome Extensionを実装しています。この拡張をインストールした上で、午前0時以降にブラウ
Goサーバのモニタリング - Qiita
5日目担当の@cubicdaiyaです。先月末のGoConではGoのカンファレンスなのにほぼnginxをビルドする話しかしてなかったので今日はちゃんとGoの話をします。 Goで書くサーバプログラム Goではサーバプログラムを書くためのユーティリティが豊富に揃ってる上に、ゴルーチンやチャネルを利用することで高いパフォーマンスが要求される環境でも十分な性能を発揮することができます。いつだったか「あれはHTTPサーバ書くための言語ですよ」なんて話をとあるエンジニアから聞いたことがあるくらいです。 例えば「Hello, World!」を返すだけのHTTPサーバであれば標準ライブラリのnet/httpを利用することで以下のように書くことが出来ます。 package main import ( "fmt" "net/http" ) func handler(w http.ResponseWriter,
電子書籍執筆環境にCIを導入、EPUBをビルドしてDropboxに送る - Fuzoku実践入門ブログ
最近、次の作品の執筆をしているのですが、慣れとは恐しいもので、Rakeを利用した自動ビルドですら面倒になってきてしまい、CIが欲しいと思うようになりました。 複数人のプロジェクトならいざしらず、自分一人の執筆のためにCI環境を整えるのは、どうもやり過ぎな気がしていたのですが、CircleCIが1コンテナまで無料になったとを聞き、気になっていたため、執筆の息抜きにCI環境を簡単に整えてみました。 CircleCIでEPUBをビルドする 既にRakefileを書いているため、CircleCIを利用してEPUBをビルドするのは、とても簡単でした。 test: override: - rake md2review epub 上記のようなcircle.ymlファイルをコミットしてGitHubへpushしておき、後はCircleCIにログインして、GitHubのリポジトリを選択するだけです。 無事にビ
ファンタジスタ、電子書籍配信・販売サービス「mixPaper for Facebook」の英語版をリリース
電子書籍はJPEG、PNG、GIF（有料版ではPDFにも対応）から作成可能で、作成した電子書籍は、PCやスマートフォンなどで専用のソフトなどを介さずにブラウザビューワから閲覧できる。無料会員でも電子書籍の作成から配信、販売までが可能だが、作成した電子書籍に目次を付けたり、外部サイトへのリンクを設定するなどの機能を利用したい人には、有料のプランも用意されている。 日本語版は2013年11月にリリースされていたが、より多くのアクティブユーザーへ電子書籍の配信・販売することを目的に英語版を開発したという。現在は毎月5万人以上のユーザーが利用しており、電子書籍の閲覧数は15万回以上。 関連記事 電子書籍の制作・配信・販売すべてがFacebook上で操作できるアプリが登場 ファンタジスタが、Facebook上で手軽に電子書籍の制作・配信・販売ができるサービス「mixPaper for Faceboo
ＥＰＵＢ３は死に逝くおじいさんたちのフォーマット - INSIGHT NOW!プロフェッショナル
／ＥＰＵＢ３は、国際標準のＥＰＵＢ２と上位互換性の無い、事実上、日本のみのガラパゴス規格。死に体の出版社の古い「常識」で、またこんなアホなことをやっているヒマがあったら、国際標準に対応できる新しい日本語字組デザインを工夫した方がいい。／ 現時点でもなお電子書籍の国際標準はＥＰＵＢ２。それを発展させた上位互換がＥＰＵＢ３、ならよかったのだが、そうではない。両者は、互換性が無い、まったく別のフォーマットだ。もともと、アルファベットの横文字の文章だけなら、ＥＰＵＢ２で十分。ところが、右開きだ、縦組だ、ルビだと、事実上、日本人だけがＥＰＵＢ２にケチをつけて、ＥＰＵＢ３を作らせた。このために、日本語のみＥＰＵＢ３が標準、なんていう面倒な商業サイトもあって、国際標準のＥＰＵＢ２の方がはじかれてしまう。それで、なんとしてもＥＰＵＢ３にしなければ、ということになるのだが、世界全体で言えば、いまだＥＰＵＢ３
現場で使える効果的なHTML&CSS構造設計（Effective HTML&CSS）
2. プロフィール • 竹内 真 / TAKEUCHI SHIN #singtacks – 創業企業＆所属 • 株式会社レイハウオリ 代表取締役社長（W3Cメンバー） • 株式会社ビズリーチ 取締役CTO • 株式会社ルクサ CTO – 主な運営サービス • • • • • 2 ビズリーチ http://www.bizreach.jp/ ルクサ http://luxa.jp/ RegionUp http://www.regionup.com/ codebreak; http://www.codebreak.com/ CareerTrek http://www.careertrek.com/ #singtacks supported by
リアルな DOM はなぜ遅いのか - steps to phantasien
これは VirtualDOM Advent Calendar 2014 に勝手に参加する記事です。 あたたかい春の昼下がりのこと、あるブラウザベンダの社内を不穏な噂が駆け巡った。 「React.js なるライブラリ、どうも仮想 DOM というやつのせいで速いらしいぞ」 もうリアルな DOM はお役御免、ブラウザも商売上がったりか・・・。雇用に不安を覚える人(私)がいる一方、 そのアイデアをとりこんでブラウザの DOM を速く出来ないかと考える人たちもいた。 仮想 DOM はなぜ速いのか。誰かのつてを辿って React.js チームにおいでいただき、速さの秘密をテックトークしてもらう。 イミュータブルなデータ構造による単純化、非同期適用による処理のバッチ化、差分アルゴリズムによる副作用の最小化… いくつかのアイデアはブラウザからはどうにもならないが、たとえば非同期化なんかは形は違えどブラウザ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
WebPのインストール方法と簡単な使い方 - Qiita