タグ

2014年3月7日のブックマーク (15件)

  • 文具メーカー『キングジム』が佐村河内氏の謝罪会見の日に「デジタル耳せん」を発売 / キングジム「偶然の一致です」

    » 文具メーカー『キングジム』が佐村河内氏の謝罪会見の日に「デジタル耳せん」を発売 / キングジム「偶然の一致です」 特集 きょう2014年3月7日、話題の「佐村河内守」氏が、これまでの沈黙を破って謝罪会見を行った。彼は会見でゴーストライターの新垣隆氏が発表した内容について、「すべてウソ」と否定。その発言の真意が問われるなか、文具メーカー「キングジム」が Twitter で意味深なつぶやきをしている。 ・キングジムのつぶやき 「日発売した「デジタル耳せん」は、佐村河内氏の記者会見に意図して合わせたものではございません。偶然の一致です」(キングジム公式Twitterより引用) ・かえって不審 「偶然の一致」としているキングジムだが、そのようなことをつぶやかなければ誰も気づかなかったのではないだろうか……。むしろ、この内容をつぶやくことによって、かえって「意図したのでは?」と考えられてしまう

    文具メーカー『キングジム』が佐村河内氏の謝罪会見の日に「デジタル耳せん」を発売 / キングジム「偶然の一致です」
    hiromark
    hiromark 2014/03/07
    ああああ。
  • Why Yammer Believes the Traditional Engineering Organizational Structure is Dead

    Management Why Yammer Believes the Traditional Engineering Organizational Structure is Dead Yammer VP of Engineering Kris Gale explains why organizational norms are holding us back and what to do about it. Kris Gale, VP of Engineering at Yammer, argues the key to building fast at scale lies in small teams. He explores intricacies of organizational design in engineering and explains how making inte

    Why Yammer Believes the Traditional Engineering Organizational Structure is Dead
    hiromark
    hiromark 2014/03/07
    ふむ。
  • カフェで仕事するときの心がけ

    カフェで仕事するのが大好きな「数学ガール」著者(結城浩)が「カフェで仕事するときの心がけ」をまとめました。あなたの「心がけ」はありますか?

    カフェで仕事するときの心がけ
    hiromark
    hiromark 2014/03/07
    カフェで仕事はしませんが勉強はよくするのでその通りと思う。
  • 正論を言うから嫌われると思っている人の勘違い思考

    正論を言うから嫌われると思っている人の勘違い思考 2014-03-07-1 [Opinion] ちょっと前のサッカーコラムで、辛口評論家についての話がありました。これは多くの分野でもあてはまると思うので引用しておきます。 - 「辛口評論家」はなぜ好まれないか?│サッカーコラム J3 Plus+ http://llabtooflatot.blog102.fc2.com/blog-entry-4286.html 「人に対しては厳しいけれども、自分に対してはめちゃくちゃ甘い。」という人が信頼を集めるのは無理である。ただ、「辛口」を自認している人に限って、このあたりのことには気が付いておらず、「自分は正論をバシバシ言うから好かれていない。」と勘違いしている。 ネットだとこういう「正論を言うから嫌われると思っている人」はよく見かけます。頭が凝り固まっちゃって、問題を分離できない人が多いですよね。 と

    正論を言うから嫌われると思っている人の勘違い思考
  • さようなら、自作サーバー - stanaka's blog

    一昨日、自作サーバー同窓会というイベントを開催しました。 このイベントは2009/11(4年半前!)に開催した自作サーバーカンファレンスに登壇された方々を中心に、自作サーバー現役の方々を交え、あの頃の自作サーバーと、自作サーバーの今を振り替えってみようという趣旨のものでした。 イベントの詳細は吉岡さんのエントリ、桑野さんのエントリ、@nekoyaさんのエントリとtoggetterのまとめを参照してください。 僕の思いは「自作サーバー同窓会」という名付けに集約されています。AWSが常識になり、物理的な世界との距離が広がりつつある今、各社の様々な取り組みなどを楽しく振り返ることができました。 さようなら、自作サーバー。いろいろな面白い経験と仲間を得ることができました。登壇及び参加された皆さん、ありがとうございました! 余談 会場はフリークアウトさんの新オフィスで、シャレオツすぎて、前向きになれ

    hiromark
    hiromark 2014/03/07
    まだ生きる道がないではないんですけどね。
  • STAP細胞についての報道に思うこと | 研究者マンガ「ハカセといふ生物」

    研究者マンガ「ハカセといふ生物」 「ハカセといふ生物」は冴えない研究者である北大路柿生と、割と一般的な常識と感性を兼ね備えた普通の女子・姫杜冴子の文化交流に科学を添えてマンガにしたものである。 こんばんは。 小保方さん、再現実験に成功 論文発表後初めて - MSN産経ニュース STAP細胞の第一報から、随分と色々な報道がされてきましたね。 それらについて思うところがあり・・・ 少し長くなりますがここに書かせていただきます。 一連のSTAP細胞の捏造報道のあり方に、僕は疑問を持っています。 捏造とは穏やかな言葉ではありません。 インターネットなどから出て来た話がここまで大きくなったことに、やるせなさを感じています。 僕は今回の件が捏造か否か問われても 「これだけでは分かりません」 としか答えられません。 確かに、論文の記載に問題箇所はあるようです。 しかしそういった部分があるからといって、検

    STAP細胞についての報道に思うこと | 研究者マンガ「ハカセといふ生物」
  • MongoDBの監視

    ・MongoDBで何を監視すべきか ・MongoDBのコマンド・メソッドによる監視 ・運用監視ツールとの連携して監視 ・MMS(MongoDB Monitoring Service)で監視Read less

    MongoDBの監視
  • tmpfs のファイルを zfs の log device に入れられる件 #zfs #solaris - いちいの日記

    ちょっとしたメンテナンスで InnoDB のテーブル圧縮を並列でやっていたんだけど、 random i/o が多すぎて全然すすまない。悪いことにこのサーバは iSCSI ディスクしか無くて、どうしようかなと思っていたときにふと気づいたこと。 % dd if=/dev/zero of=/tmp/zero.dat bs=1048576 count=1024 1024+0 records in 1024+0 records out 1073741824 bytes (1.1 GB) copied, 1.10092 s, 975 MB/s% sudo zpool add tank cache /tmp/zero.dat cannot add to 'tank': cache device must be a disk or disk sliceこれはダメなんだけど、 % sudo zpool ad

    tmpfs のファイルを zfs の log device に入れられる件 #zfs #solaris - いちいの日記
  • Home - SkySQL – Your Trusted, Full-managed MariaDB in any Cloud

    Announcing SkySQL, Inc. – A Milestone Moment for SkySQL and the MariaDB Community. Read More Announcing SkySQL, Inc. – A Milestone Moment for SkySQL customers and the MariaDB Community. Read More

    Home - SkySQL – Your Trusted, Full-managed MariaDB in any Cloud
    hiromark
    hiromark 2014/03/07
    あー、こういう使い方が想定されてたのか。。。
  • YouTube & Go言語: MySQLをパワーアップするVitess - ワザノバ | wazanova

    http://www.youtube.com/watch?v=qATTTSg6zXk 1 comment | 1 point | by WazanovaNews ■ comment by Jshiike | 約3時間前 YouTubeのシステムアーキテクトであるSugu SououmaraneのFOSDEM 2014での講演です。スライドはこちらからダウンロードできます。 1) Vitessとは Vitessは大規模な番環境でMySQL DBを効率的に利用するためのオープンソースプロジェクトです。概要はプロジェクトゴールのページ にまとまってます。 MySQLは機能が豊富だがスケールさせるときは苦労する。一方、NoSQLはスケーラビリティには問題がないが、アプリケーションが複雑になるとできることに限界があるのがネックになる。セカンダリインデックス、joinsなどがサポートされていない。

  • http://www.approfan.net/iwatch/apple%E3%81%8C%E3%80%8Csiri%E3%80%8D%E3%82%92%E9%96%8B%E7%99%BA%E8%80%85%E3%81%AB%E9%96%8B%E6%94%BE%EF%BC%81%E3%81%9D%E3%81%AE%E5%85%88%E3%81%ABiwatch%E3%81%82%E3%82%8A/

  • MySQL 5.6 では innodb_flush_log_at_trx_commit の意味が MySQL 5.5 と違う : DSAS開発者の部屋

    MySQL 5.6 では innodb_flush_log_at_trx_commit の意味が MySQL 5.5 と違う innodb_support_xa と binlog の危ない関係 で、 MySQL がトランザクションログのコミットをシングルスレッドでシーケンシャルに fsync していると書いたのですが、誤解だったのでその補足です。 タイトルの通り、 innodb_flush_log_at_trx_commit=1 の場合も、トランザクションログが fsync されません。トランザクションがディスクに書かれるシーケンスは次のようになります。 1. prepare (fsync) 2. write binlog (grouped, fsync) 3. commit このうち 1 は従来通り各スレッドで並列に実行され、 2 と 3 が昨日紹介した sql/binlog.cc の

    MySQL 5.6 では innodb_flush_log_at_trx_commit の意味が MySQL 5.5 と違う : DSAS開発者の部屋
  • 準同期レプリケーション設定

    以前に行ったレプリケーションの設定は、 通常のレプリケーションで非同期で行われるレプリケーションになりました。 そこで、今回はMySQL 5.5からの新機能の準同期レプリケーションを試したいと思います。 通常のレプリケーション(非同期)と準同期レプリケーションの違いについては次のようになっています ■非同期レプリケーションの処理の流れについて 1.masterでトランザクション開始 2.masterが更新クエリ時にバイナリーログを出力する。 3.コミット完了 ここまでmasterの同期が取られている 4.slaveがmasterのバイナリーログを取得する。 5.slaveがmasterから取得しバイナリーログを実行する。 ※4、5はslave側で非同期で実行される。 ■準同期レプリケーションの処理の流れについて 1.masterでトランザクション開始 2.masterが更新クエリ時にバイナ

    hiromark
    hiromark 2014/03/07
    いまさらメモ
  • これは凄い!iOSアプリ内で動作するPHP·iPHP MOONGIFT

    iPHPはObjective-C製のソフトウェア(ソースコードは公開されていますがライセンスは明記されていません)です。 iOS上で動作するプログラミング言語と言えばObjective-CやJavaScriptくらいと思われています(アプリを開発できる言語はもっとありますが)。しかしその壁を打ち破るソフトウェアがiPHPです。名前の通り、PHPの実行エンジンをiOSアプリ内に埋め込んだソフトウェアです。 立ち上げました。さっそくphpinfoを実行します。 見慣れた画面です。PHPのバージョンは5.4.15となっています。 curlも組み込まれています。外部コンテンツを取り込んで…といったこともできるでしょう。 fileinfoやgdもあります。色々な使い方ができそうです。 evalを使って入力したテキストを評価させることができます。 こちらはベンチマークを実行した結果です。 iPHPは思

    これは凄い!iOSアプリ内で動作するPHP·iPHP MOONGIFT
  • 例えば OSFA な API をやめる - @kyanny's blog

    OSFA == one-size-fits-all 単一の API で全てをカバーするのをやめたらどうか、ということ。 APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sight @kenn 最近はRESTfulなエンドポイントは完全に後方互換なまま、クライアントごとにオーケストレーション層(radical versionin)を設けるという方向にシフトしようとしている。詳しくは http://t.co/zODm7mFr5B— Tatsuhiko Miyagawa (@miyagawa) February 28, 2014 この話のポイントとはちょっとずれてる && Podcast 聴いてないのですが。 Quipper プラットフォームで内部的に利用されている API も、 /v1 というパスの下にはえててごく一部のエンドポイントだけ /v2 がある、み

    例えば OSFA な API をやめる - @kyanny's blog