タグ

2014年3月12日のブックマーク (21件)

  • キートップからスイッチまで全てLEGOで作られたキーボード

    2014年3月11日 他機種のニュース 当サイトの記事には広告が含まれます。 こちらは、全てLEGOのパーツを使用して作ったというキーボード。 外枠やキートップだけでなく、キーボードスイッチまでLEGOで作られているというこだわりようです。 Source LEGO Computer Keyboard

    キートップからスイッチまで全てLEGOで作られたキーボード
    hiromark
    hiromark 2014/03/12
    なにこれすごい
  • 辻野晃一郎さん、それは違うんじゃないですか - 今日も得る物なしZ

    ちょっと前の話らしいけどなんか盛り上がってるので。 ソニーOBを批判していた匿名アカウントがソニー社員だったと話題にwww : IT速報 簡単に言うとソニーの元偉い人がソニー社員が言ってる悪口を見つけて恫喝したという大企業にありがちのハートウォーミングストーリーなわけですが、この騒動を受けて辻野氏はこういう文章を発表しています。 先人が切り開いたソニー・スピリットの復活を心から祈る―ソニーの病巣の深さを改めて考えた― 『現代ビジネスブレイブ リーダーシップマガジン』---辻野晃一郎「人生多毛作で行こう」より | BRAVE NEWS | 現代ビジネス [講談社] で、この文章がもうパーフェクトにひどい。 ここまでひどい主張は久々なのでその辺をちょっと見て行きますよ。 個人名が公になっている人は、ネットなどで突然思わぬ攻撃を受けることがあると思うが、私もツイッターなどで、「これはいくらなんで

    辻野晃一郎さん、それは違うんじゃないですか - 今日も得る物なしZ
  • TwitterのOAuthの問題の補足とか

    You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

    TwitterのOAuthの問題の補足とか
  • Redisのクエリーアナライザー "redis-traffic-stats" を書きました - (ひ)メモ

    redis-traffic-stats という Redis のクエリーアナライザーを作りました。 https://github.com/hirose31/redis-traffic-stats redis-traffic-statsはtcpdump -wで書き出したpcapデータを解析して、以下のような統計を表示します。 総ネットワークトラフィック量と平均byte/sec 総リクエスト数と平均とピークのreq/sec コマンド毎のリクエスト数、総リクエスト数に占める割合、req/secを、リクエスト数が多い順に上位10コマンドを表示 コマンド毎の総転送バイト数、byte/secを、総転送バイト数が多い順に上位10コマンドを表示 コマンド別に、キー毎の総転送バイト数、byte/sec、リクエスト数、リクエスト数の割合、req/secを、総転送バイト数が多い順に上位10キーを表示 時間のかかっ

    Redisのクエリーアナライザー "redis-traffic-stats" を書きました - (ひ)メモ
  • 「『ガンダム』を創った男たち。」 : 小野和俊のブログ

    機動戦士ガンダムといえばロボットアニメの金字塔であり、日国内に「ガンダム」という言葉を聞いたことがない、という人はほとんどいないのではないかと思える程の知名度を誇る作品だ。 こうした印象から、ガンダムと言えば「大成功したアニメ」という印象を持つ人が大半だろう。しかし「『ガンダム』を創った男たち。」を読むとその印象は一変する。 こうした紆余曲折を経て遂にTV上映が始まるが、その結果は大惨敗だった。15%〜20%が期待された第一回の視聴率はたった3%。そして第七回では遂に実質0%の「誰も見ていない番組」にまで落ち込んでしまう。この状況を打開すべく、次々と新モビルスーツを登場させ、さらに「オモチャが売れれば数字には目をつぶる」というスポンサーの声に応えるべく、ガンダムというドラマを完成させるための苦肉の策として、兵器としてはリアリティがまったくなく、しかし「オモチャとしては最高」の妥協の産物で

    「『ガンダム』を創った男たち。」 : 小野和俊のブログ
  • プッシュ通知を制するものがスマホを制する〜ツイキャスの事例〜 | F's Garage

    ツイキャスが最高な理由の1つに、スマホのプッシュ通知機能がうまく作用しているところがある。 閲覧する人が、好きなCAS主(配信者)さんの通知をオンにすると、次回以降に配信を始めた時に通知が送られてくる。 ライブ配信は一定の時間の長さを持っているものだし、番組を録画しなければ、その場限りの映像なので、通知に対する価値は高い部類に入るのではないだろうか。 (当然ニコ生にもあると思うが、というのを念のため追記しておく) 「番組表がないのに、見たい番組がいつ配信されるかわからない、だから通知で知ることができる」 人気のCAS主が通知を送ると即座に人が集まってくる。 これは放送では決してできなかったことだ。放送は編成やプロデューサーがその力を握っているらしく、タレントは評価されることでしか出演機会を得られなかったが、ツイキャスであれば、いつでも人を動員することが可能になる。 更にツイキャスでは、配信

    プッシュ通知を制するものがスマホを制する〜ツイキャスの事例〜 | F's Garage
    hiromark
    hiromark 2014/03/12
    これが、スマフォですらないデバイス端末となると。。。
  • 気象予報士のポイント解説(日直予報士) - 日本気象協会 tenki.jp

    人気の日直予報士を配信 tenki.jpの公式Twitterをチェック! 気象予報士のお天気解説を絶賛配信中

    気象予報士のポイント解説(日直予報士) - 日本気象協会 tenki.jp
    hiromark
    hiromark 2014/03/12
  • べからず集-情報処理学会

    論文誌ジャーナル/JIP編集委員会では、論文誌の採択論文数(採択率)が減少傾向にあるのを真摯に受け止め、昨年度は全国大会にて『会員の研究活動活性化に向けた論文の書き方・査読の仕方』と題した講演やパネル討論会を企画したり、新旧合同の論文誌ジャーナル/JIP編集委員会の合宿を通して、投稿数増に向けての推薦論文制度の改善/論文の書き方の指導、採録率アップに向けての査読内容の精査と手引きの充実等の活動を行ってきました。来年度も引き続きこれらの取り組みを実施していく必要があると考えております。特に、特集号の企画などを通して論文数の増大を図るとともに、投稿論文の改善につながる有益な査読結果の返送など、論文投稿をする会員にとって魅力のある論文誌を目指した取り組みを実施していくことを目指しています。 昨年度、『石を拾うことはあっても玉を捨てることなかれ』という査読ポリシーを明確にいたしました。また並行して

    べからず集-情報処理学会
  • YappoLogs: なぜ SQL_CALC_FOUND_ROWS や LIMIT OFFSET のページングが良く無いのか

    なぜ SQL_CALC_FOUND_ROWS や LIMIT OFFSET のページングが良く無いのか ここ最近の大規模サービス関連したデータページング考です。 mysql 5.5.34 で試して記事書いてます。 bigdata テーブルは id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, PRIMARY KEY (id) なカラムがある前提です。もちろん InnoDB です。 2014年なんだからCOUNT(*)とかSQL_CALC_FOUND_ROWSとかLIMIT OFFSETのページングはやめようぜ - Togetterまとめが発端にみえるけど、わりと昔から話されてる事なんだけど、「nippondanji SQL_CALC_FOUND_ROWS」でググっても有用な情報ないし文書化されてないからしとく。 ページング処理で使われがちな機能です。 S

    hiromark
    hiromark 2014/03/12
    良記事
  • [2015年問題2]大手でも低い利益率、日本流SIビジネスの構造問題

    多重下請けのピラミッド構造を前提とした現行のSI(システムインテグレーション)モデルは、もう限界点に達している。2015年問題は、急激な技術者不足とその後の人余りにより、この構造に属する業界の各社に大きな苦難を強いる。 だが日流のSIビジネスを構築する過程で日IT業界では、大手IT企業ですら営業利益率が6.7%と低く抑えられてしまった(図1)。最大手のNTTデータは2013年度上期に、SIの不採算案件のため250億円の損失を被った。一括受託を前提にIT企業がプロジェクト失敗のリスクを負うSIビジネスでは、そのリスクが大きな変動要因として効いてくる。各社はリスク管理と収益確保に向けた対策を打ち出しているが、元請けの企業ですら利益を出すのに苦心している。まして競合がひしめく2次請け、3次請けが利益を出すのはさらに困難になる。

    [2015年問題2]大手でも低い利益率、日本流SIビジネスの構造問題
  • 2014年なんだからCOUNT(*)とかSQL_CALC_FOUND_ROWSとかLIMIT OFFSETのページングはやめようぜ

    Masahiro Nagano / 長野雅広 @kazeburo 2014年なんだからCOUNT(*)とかSQL_CALC_FOUND_ROWSとかLIMIT OFFSETのページングはやめようぜ

    2014年なんだからCOUNT(*)とかSQL_CALC_FOUND_ROWSとかLIMIT OFFSETのページングはやめようぜ
  • オラクルはみんなが思っているほど悪者ではない | readwrite.jp

    オープンソースに明るくない人々にとっては、オラクルのMySQL運用にまつわる騒動はあまりピンと来ないかもしれない。オラクルが2010年にサン・マイクロシステムズを買収した際、オープンソースの技術者たち(私もその一人だ)は、オラクルがMySQLを台無しにするのではないかと危惧した。オラクルが開発への投資を縮小したり、技術をクローズド化するような事態を想定したのである。しかしそんなことは起こらなかった。実際にはオラクルの管理の下、MySQLのパフォーマンスは劇的に改善され、コードの大部分もオープンのまま残されている。 それでもなお、オープンソースのコミュニティには未だにオラクルのMySQL運用をバッシングする人たちがいる。ちょっとオラクルが気の毒になるほどだ。 崩壊の危機にさらされたMySQLコミュニティー確かにオラクルはコミュニティに対してあまり友好的ではなかった。そして、同社に何十億ドルも

    オラクルはみんなが思っているほど悪者ではない | readwrite.jp
  • Apache HTTP Server 最新情報 | OSSサポートのOpenStandia™【NRI】

    Apache HTTP Server情報 Apache HTTP Server とは 主な特徴 導入事例 類似プロダクト こんなお客さまにApache HTTP Serverの導入をオススメ Apache HTTP Serverのライセンス 製品ダウンロード オープンソース年間サポートサービス Apache HTTP Server とは Apache HTTP Server(アパッチ エイチティーティーピーサーバ)は、世界でもっとも広く使われているサーバソフトウェアのひとつで、大規模な商用サイトから、個人レベルの自宅サーバまで状況に応じた汎用性を発揮できるところが最大の魅力です。 普及率の高さは、多様なモジュール開発による柔軟な機能拡張や、技術者の確保、引き継ぎの容易さを実現しており、多言語からの移行もスムーズです。サービスの発展過程に合わせた、きめ細やかな運用が可能となりますので、あらか

  • Beginning of End for STAP Cell Story? Possible Outcomes - The Niche

    Beginning of End for STAP Cell Story? Possible Outcomes - The Niche
  • Single thread performance regression in 5.6 - Replication

    At Facebook, we have upgraded most of MySQL database tiers to 5.6, except very few tiers that have a special requirement -- very fast single threaded replication speed. As Oli mentioned, single threaded performance is worse in 5.6. The regression is actually not visible in most cases. For remote clients, the performance regression is almost negligible because network latency is longer than 5.1->5.

    Single thread performance regression in 5.6 - Replication
  • メモ - 第2回 MariaDB/MySQL コミュニティ イベント in Tokyo at DeNA - Glitch

    中盤2セッションだけメモりました。当にメモです。 MySQL to MariaDB Migration - SkySQL Colin Googleの話 Wikipediaの話 MySQL 5.1 -> MariaDB 5.5 追加の作業が嫌い - version upされていること XtraDB > InnoDB WikipediaはCSRを持っている Facebookも http://en.wikipedia.org/wiki/Facebook_Zero Tumblr Jetpants - tool of re-sharding, scale writes, eliminate SPoF multi-source replication, MariaDB 10.0 SpamExperts MySQL 5.0 -> MariaDB 5.1 Web of Trust over 114m u

    メモ - 第2回 MariaDB/MySQL コミュニティ イベント in Tokyo at DeNA - Glitch
  • MD5を解析するWebのサービス - うさぎ文学日記

    MD5が脆弱と言われていて、もう使っちゃダメと烙印を押されていても、さすがにハッシュ値から逆算して解析するアルゴリズムが存在するわけもなく、解析にはレインボーテーブルを使っています。レインボーテーブルというのは、平文とそのハッシュ値をDBのテーブルに格納しておいて、ハッシュ値で検索するというテクニックです。(この場合はレインボーテーブルじゃなくて、ただの平文とハッシュ値のテーブルかも。 参照レインボーテーブル - Wikipedia) たとえば、「password」という平文をMD5でハッシュ化すると「5f4dcc3b5aa765d61d8327deb882cf99」となります。こういった対応を表にたくさん入れておくことで、MD5のハッシュ値で検索すると元の平文が見つかるというわけです。 MD5のレインボーテーブルがWeb上から使えるサイトは結構あるようで、いくつかをピックアップ。どのサイ

    MD5を解析するWebのサービス - うさぎ文学日記
    hiromark
    hiromark 2014/03/12
    うわぁ
  • 楓 software: mozjpeg はどのようにして圧縮率を上げているのか?

    « Android 対応必要項目と工数見積もり | メイン | Lanczos3 を組み込んだ » 2014年03月10日 Misc.:: mozjpeg はどのようにして圧縮率を上げているのか? Tweet    @jin1016をフォロー ざっくりソースコード見たりしただけなので、間違っているかもしれないが書いておく。 一言で書くと「プログレッシブ方式で、DC成分の分割サイズを最適なものにすることで偏りを増やし圧縮率を上げている」ということのようだ。 この説明だと知っている人以外にとっては意味不明だと思うので、どのように圧縮しているのかある程度説明し、なぜ圧縮率が上がるのか説明してみる。 JPEG では、色空間変換 → DCT → 量子化 → ハフマン符号化+ランレングス と言う手順で圧縮している。 この中で実際に圧縮を行っているのは、「ハフマン符号化」と「ランレングス」の部分。 これ

  • コンピュータを進化させてきた偉大なるアルゴリズムまとめ

    By Kai Schreiber IT技術の進化のスピードには目を見張るものがありますが、それを支えているのはアルゴリズムと呼ばれる処理方法(技術的アイデア)です。さまざまなアルゴリズムの中でも、コンピュータの進化に革命的な影響をもたらしたとされる偉大なアルゴリズムは以下の通りです。 Great Algorithms that Revolutionized Computing http://en.docsity.com/news/interesting-facts/great-algorithms-revolutionized-computing/ ◆ハフマン符号(圧縮アルゴリズム) Huffman coding(ハフマン符号)は、1951年にデービッド・ハフマン氏によって開発されたアルゴリズム。頻出頻度の大小によって対戦するトーナメントツリーを考えて、ブロックごとに0と1の符号をもたせる

    コンピュータを進化させてきた偉大なるアルゴリズムまとめ
  • 毎日やると決めたことを休んで良いのはどういう時だろうか? - higepon blog

    何かを「毎日やる」と決めたことは誰でもあると思う。ジョギング、ウォーキング、ストレッチ、筋トレ、勉強。僕の場合は英語の勉強。それぞれ決めた内容によって「続ける」ことの困難さには違いがある。ただし継続の難しさは理解してもらえるだろう。朝起きたらだるかった。何となくサボってしまった。飲み会があったのでできなかった。いくらでも「できない」理由は見つかる。僕がよく考えるのはどういう場合に「毎日やる」ことをサボってしまっても自分で自分を許せるだろうかという疑問。 まずは簡単な計算をしてみよう。飲み会のある日にはやらなくてよいとする。仮に飲み会が2週間に1回ほどだとすると月に2回。1年だと 12/365*100 = 3.2% にあたる 12 日は「やらない」ことになる。飲み会の回数が週1程度だと 6.4 % になる。何となくだが「飲み会のある日にやらなくてよい」というルールはサボり過ぎのように感じてし

    毎日やると決めたことを休んで良いのはどういう時だろうか? - higepon blog
    hiromark
    hiromark 2014/03/12
    なるほど
  • You don't need API version 2 - yohei's diary

    周回遅れ感が半端ないけどバージョニング関連で色々読んで・聞いて思ったことを書く。 APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sight Kazuho's Weblog: 拡張可能なWeb APIの設計原則と、バージョン番号を使う理由について Rebuild: 35: You Don't Need API Version 2 (Kenn Ejima) rest - Best practices for API versioning? - Stack Overflow RESTfulなサービスのバージョンングから得られた知見 RESTとバージョニング 基的にいわゆる狭義のRESTとAPIのバージョニングは何も関係ない。強いて言えば、HATEOASはバージョニングにも使えるよ、というのがREST信者の主張であるものの、それが正しい(というか実用的)かど

    You don't need API version 2 - yohei's diary