http://peatix.com/event/121751/ での発表資料です
GMOペパボでは、常に新しいサービスを作り続けています。その理由は3つあります。 1つ目は、インターネット大好き人間が集まった会社だから、です。新しいサービスを作れないことは、会社全体のジレンマになってしまうんですね。 2つ目は、我々がやっているインターネットインフラ事業はストック型ビジネスで安定的だけれど、成長が二次曲線になりにくいビジネスモデルでもあるということ。サービスは、「続けること」ができれば売上も徐々に増えていくものです。しかし、中には一気に成長できるサービスもあります。我々の場合、この「一気に成長できるサービス」を持ち合わせていませんでした。急成長できるものを生み出すためにも、とにかくサービスのポートフォリオを増やす必要があります。 3つ目は、ヒットするサービスを生み出せる組織を目指す必要があるということ。検索やポータルサイトといった普遍的なサービス以外は、ライフサイクルのよ
golang - Goで外部コマンドをパイプして実行する - Qiita もっとうまいやり方誰か教えてください( ꒪⌓꒪) http://qiita.com/yuroyoro/items/9358cd25b5f7fe9dd37f 本当はプロセスの生死と共にパイプが閉じられないといけないので io.Pipe ではなく Cmd.StdoutPipe を使った方がよい。ただしコード量はもう少し多くなる。確かに毎回書くのはダルいのでパッケージを作った。 mattn/go-pipeline - GitHub https://github.com/mattn/go-pipeline これを使うと簡単にコマンドパイプラインが扱える。 package pipeline import ( "fmt" "log" ) func ExampleCommandPipeLine() { out, err := Ou
shibaraku gem をリリースしました これは何? ActiveRecord で期間を持つ model を扱う gem です。期間限定公開や、予約公開したいときなんかに使います。 作ったのは 1 年前なんですが、ずっと社内 gem として使用していたものを rubygems.org / github.com に上げました。 https://rubygems.org/gems/shibaraku https://github.com/onk/shibaraku USAGE 基本的な使い方 start_at, end_at のあるモデルを用意します。 create_table :campaigns do |t| t.datetime :start_at t.datetime :end_at end shibaraku と 1 行書くと class Campaign < ActiveRe
最近のLinuxでは、自動的にCPUの動的クロック変更が有効になっています。トラフィックの激しいサービスを受けるサーバーの場合、無効にしたかったので、その方法を調べてみました。エコでなくてすいません・・・。 まず、Ubuntu 12.10 amd64 では、次のとおりです。 1. cpufrequtils パッケージをインストールします $ sudo apt-get install cpufrequtils 2. 現在の状態を確認します $ cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor ondemand ... ondemand という表示が CPU コア数分表示されている場合、CPU の動的クロック変更が有効になっています。 ついでに現在のクロック数を確認します $ cat /sys/devices/system/cp
米Symantecの認証局が手違いにより、「google.com」などのドメイン向けのテスト証明書をドメイン所有者が知らないうちに発行していたことが分かり、米Googleは10月28日、同社に対して対応を要求した。Symantecの対応次第では、Google製品でSymantecの証明書が安全とみなされなくなる可能性もあると警告している。 Symantecが10月2日に発表したインシデント報告書で、GoogleやOperaなど5組織向けのテスト証明書23件がドメイン所有者の知らないうちに発行されていたと報告した。これに対してGoogleは、不審な証明書はそれ以外にも存在すると指摘。その後、Symantecは10月12日に出した更新版の報告書で、さらに76ドメイン向けの証明書164件と、未登録ドメイン向けの証明書2458件が見つかったと発表した。 GoogleはこうしたSymantecの対応
追記(2016-07-13 16:40) Changelog に書いてあるとおり(BUG/MEDIUM: dns: unbreak DNS resolver after header fix)、 動的名前解決ができないバグが修正されました。 HAProxy 1.6.6 で動的名前解決できないバグが修正されていました(Changelog にも書いていますが一応検証しました)— tkuchiki (@tkuchiki) 2016年7月13日 詳細は省きますが、本記事と同様の検証を行い、動的名前解決ができることを確認しました。 追記(2016-06-24 12:34) HAProxy 1.6.5 は、DNS の動的名前解決が動作しないようです。 ご注意ください。 HAProxy 1.6.5 で動的名前解決できない問題については 1.6.4 で困っていなければそれを使って、1.6.5 がよければ
計算機プログラムの構造と解釈、通称SICPを一から翻訳し直しました。 ファイル: SICP非公式日本語版 翻訳改訂版 リポジトリ: https://github.com/hiroshi-manabe/sicp-pdf また、今回の翻訳をするにあたって考えたことを別記事にまとめました。 腐った翻訳に対する態度について SICPはMITの有名なプログラミングの教科書です。詳しくはminghai氏の記事をご参照ください。 この翻訳改訂版は、minghai氏の非公式日本語版(以降、minghai氏版)のあまりにも惨憺たる翻訳を見かねて、原著から翻訳をし直したものです。この翻訳を進めるにあたっては、minghai氏版の訳を置き換えていくというやり方で進めていきました。しかし、差分を取ればわかっていただけると思いますが、minghai氏版のテキストは痕跡をとどめていないはずです。この方式を採ったのは、
空白行やタブなどの非表示文字を使って、文書を構造化できるテキストエディタ。「構造化エディタ」は、プレーンテキスト形式のままで文書に階層構造を持ち込むことのできるユニークな“アウトラインプロセッサ風”テキストエディタ。スペースやタブなどでマークアップして構造化を実現する「sted format」により、プログラムのソースコードなども編集することが可能。目的のセクションにすばやくアクセスできるブックマーク機能やHTML形式での保存機能などもある。MDI形式/SDI形式が個別のアーカイブで配布されている。 メイン画面は、左側にツリーペイン、右側にエディットペインが配置された2ペイン構成。文書ファイルは「セクション」単位で構造化される。ツリーペインには現在編集中の文書のセクションがツリー構造で表示され、ツリーペインで選択したセクションの内容がエディットペインに表示される仕組み。ツリーは、(一般的な
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く