総務省がソフトバンクモバイルを第二種指定事業者にするかどうかについて意見募集を行っている（ケータイWatch、総務省）。 電気通信事業法では、通信事業者が一定のシェアを保有すると「指定電気通信設備」を保有する第二種事業者と指定され規制対象となる。シェアが大きくなると、他社との接続交渉を行う際に優位な立場にあると判断されるためだ。第二種指定電気通信設備に指定されると、接続約款を総務大臣へ届け出たり、公表したりすることが義務付けられる。また接続料の算定も総務省が示したガイドラインに則ることになるという。これまではシェア25％以上のNTTドコモやau（KDDIおよび沖縄セルラー）が第二種指定事業者となっていたが、今年6月に電気通信事業法が改正され、シェア10％以上のソフトバンクモバイルも対象に含まれることになった。 今回の意見募集は、この「ソフトバンクモバイルを追加する」かどうかについてのもので
さて、前回まで基礎部分をいろいろと説明したので今回からは実装について。現在のソースやその成り立ちを説明するのもいいんだろうけど、今日からはちょっぴりハンズオン形式に趣向を変えてみよう。ってことで node.js を作っていくよ！ 実装編その一はJSエンジンであるV8にJavaScriptのソースを食わせて実行する、つまりはオレオレJS環境を作るまでを扱うのだ。 V8はもともと他のソフトウェアに組み込まれて使用されることを想定（例えばChromeとかね）されているのでこういう作業が必要になる。 手順は大きくわけて二つ 1. まずはV8のソースを落としてきてV8のビルド 2. V8のソースディレクトリに自作のC++のソースを作ってコンパイル＆実行 C++が出てきた時点で引いちゃったかもしれないけど、C++を使えるようになるのが今回の目的ではないのでまずはリラックス。C++っていったってそんなに
今日はnode.jsで採用しているCommonJSの話である。 CommonJSの説明だけだとあっという間に終わってしまうのでJavaScriptの歴史を混ぜ込んだら期せずして長くなってしまった。 さて、1995年に発表されたJavaScriptは開発当初「Mocha」と呼ばれ、次に「LiveScript」となり（実際Netscape Navigatorの2.0のアルファ版ではではこの名前だった）、最後にようやくJavaScriptになる(Navigatorの2.0B3から)という変遷をたどった。このJavaScriptという名前っていうのはJavaというコンパイル言語を補完するスクリプト言語にしたいという考えがあったからという話もあるんだけど、そのころ開発元のNetscapeはSunとの業務提携を発表しており、ちょうどそのころJavaが世に出てNetscapeブラウザ上でクールなJava
昨日に引き続き、いざ！part2なのだ。 前回では node.js と v8 の結びつきまでを書いたので、今日は Non-Blocking I/O の話を。 Non-Blocking I/O という言葉からブロックしない I/O をイメージするのはたやすい。でもこれを実現しようとなるといろいろとまあ面倒くさいんだよね。 それを解決する常套手段で言うとファイルディスクリプタ（ネットワークならソケットだね）を開いてそれをselectシステムコールの監視対象に加えておき、selectを呼び出すことで監視するっていう方法がある。こうすると何が嬉しいのかファイルディスクリプタが２つある場合で考えてみよう。 まずAとBというファイルディスクリプタを監視対象とする。 selectシステムコールを呼び出し、そのどちらかが読み出し準備完了となっていないかを確認する。 もしどっちも準備できていなかったらプロセ
期せずして久々の更新になってしまった。ブログを書く気がなくなったとかそういうのではなくてただ単に忙しかっただけ。その間、まぁ仕事が予期せぬ方向から炎上してみたり、事故をもらって愛車が全損したり（フロントガラスが全面熱線入りなんていう変なオプションなどを諸々付けていたからお気に入りだったのに）と決して良いことばかりで忙しかったわけではないけどね！ で、今回は node.js のお話。異様な盛り上がりを見せているものの、じゃぁそれっていったい何かというと「JavaScriptを用いたNon-blocking I/O環境」という非常にシンプルなものだ。 その根底には「うまくスケールできること」と「動作が速いこと」という理念が見受けられる。 まず「うまくスケールできること（多量のアクセスを捌けること）」を解決するにあたり、まずはスレッドモデルか、イベントループかという問題があった。そこで auth
日経ソフトウェア8月号にJavaScriptの特集がありまして、そこでNode.jsが紹介されていました。 それを読んで、僕は以下のようなツイートしました。 日経ソフトウェア8月号のJavaScript特集のNode.jsの記事みたけど、これはちょっとひどいな。非公式のWindowsバイナリを使ってるせいでnpmの使い方おかしいし、「Node.jsのAPIはCommonJSに従った形で実装」とか嘘書いてあるし。 #nodejs_jp 2011-06-26 13:43:59 via web *1だと言わざるをえません。Node.jsはCommonJSの仕様のうち「Module 1.0」と「Unit Testing 1.0」には一応準拠していることになっています（http://wiki.commonjs.org/wiki/CommonJS#Implementations）。が、Node.jsの
外部からの監視はしておきたい@HIROCASTERでございませう。 例えば、 apacheの設定ミスに気づかず、一部VirtualHostが外部から見えない クライアントの回線が悪いのかVPSの回線が通信障害なのかの切り分け ドメインの有効期限切れに気づかず失効 このような障害を起こさないためにも外部からの監視を利用したいところです。 監視ツールにはNagiosなどの代表的なツールがありますが、このシステムを24時間稼働させていること自体がコストであり、面倒だったりします。そこで、無料で提供しているサービスを活用して、外部からの監視をオススメします！ Site Alert http://site-alert.net/ SSL証明書やドメインの有効期限をチェックしてくれるので重宝しています。どれだけサーバーが正常に稼働していても、ドメイン更新のメールに気づかず、失効してしまったらサービスが停
RFCとなった「OAuth 2.0」――その要点は？：デジタル・アイデンティティ技術最新動向（2）（2/2 ページ） OAuth 2.0をセキュアに使うために知っておくべきこと スマホアプリでのFacebook IDを用いたログインには注意！ これは何も「Facebook IDでログイン」に限った話ではありません。しかし、OAuth 2.0ベースのID連携を行う場合、利用されるOAuth ServerはほぼFacebook APIになるので、ここではFacebookの名前を直接挙げています。 OAuth 2.0とProfile APIの組み合わせによってID連携を実現する際、スマホのネイティブアプリなどのPublic Clientは、Implicit Grantフローを利用することになります。 すべてのサービスがネイティブアプリ内で完結する場合には特に問題ないのですが、実際には、アプリが独
いまだに知らないなんてありえない病とは、プログラマー同士の会話の場で、 「いまだに○○という本さえ読んでいないなんてありえない」 「いまだに○○というフレームワークさえ使っていないなんてありえない」 「いまだに○○という言語を触ったことさえないなんてありえない」 「いまだに○○というパターンさえ知らないなんてありえない」 というように、自分が知っていて相手が知らないものについて、 「いまだに知らないなんてありえない」 と発言してしまう病の総称である。 発症例として、例えば次のようなものがある。 「いまだにマシン語が書けないなんてありえない」 「いまだにRubyを1行も書いたことないなんてありえない」 「いまだにVisitorパターンさえ知らないなんてありえない」 「いまだに高校レベルの数学も押さえていないなんてありえない」 「いまだに個人で開発したアプリが1つもないなんてありえない」 「い
ネットによって文章を書くようになった人たちは消費者でもなくクリエイターでもなかった - Togetterまとめ 上記のまとめを読んでいると、なんとなく、「うんうん、その通りだね。プロの社会的価値を下落させる何者かを、“あるべき顧客の姿”に戻さないといけないね」と頷きたくなる。しかし少し真面目に考えてみれば、他業種・他分野では到底通用しない考え方だと気づかざるを得ない。 他業種・他分野では、“プロの社会的価値を下落させ、顧客を喪失させる何か”の実例はいくらでもある。 例えばマイカーの普及は、馬車の御者や人力車といったプロの仕事を奪い、後にはローカル鉄道や路線バスの採算性をも破綻させた。人々が欲しかったのは、馬車でも人力車でもなく「素早く目的地に到達すること」だった。だから「素早く目的地に到達すること」がマイカーで達成されるようになれば、馬車や人力車やローカル鉄道にお金を払いたいとは誰も思わな
キクチ @skikuchi ひとつだけ。ある新しい物事が普及することが、その分野の勃興や隆盛ではなく、低価格化による地盤沈下を意味するというのは、なんなんだろうな。00年代以降の特有の現象だと思うんだけど。個人的にはすげえ理不尽な感じがするわ。 2012-08-29 00:51:37
経済産業研究所が公表した「サービス産業における賃金低下の要因～誰の賃金が下がったのか～」というディスカッションペーパーは、最後に述べるように一点だけ注文がありますが、今日の賃金低迷現象の原因がどこにあるかについて、世間で蔓延する「国際競争ガー」という誤解を見事に解消し、問題の本質（の一歩手前）まで接近しています。 http://www.rieti.go.jp/jp/publications/dp/12j031.pdf 賃金構造基本統計調査を使用して、1990 年代及び2000 年代における日本の常用雇用労働者の賃金変化の要因分析を行った。その結果、既存の研究結果と異なり、国際的な価格競争に巻き込まれている製造業よりむしろ、サービス産業の賃金が下がっていたことが判明した。 途中の数理分析は飛ばして、結論のところの文章を追っていくと、 製造業の賃金は、1993-1998 年の期間には上昇、19
2012/09/10 オンラインでの動画サービスを提供している米Netflixは9月4日、Amazon Web Services（AWS）クラウド向けの負荷分散ツール「Eureka」をオープンソースとして公開した。 Eurekaは、AWSで構築しているミッドティアサーバの負荷分散およびフェイルオーバーを目的とした、RESTベースのツールだ。サービスの制御を行う「Eureka Server」と、アプリケーションサーバにインストールされ、Eureka Serverと連携しながら負荷分散を行うJavaベースのクライアント「Eureka Client」で構成される。同クライアントもラウンドロビンによる基本的な負荷分散を行うロードバランサ機能を備えている。 AWSはすでに、エンドユーザーからのトラフィックに近いエッジサービスの負荷分散を行う「AWS Elastic Load Balancer（ELB
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://ecx.images-amazon.com/images/I/51p3V45ESlL._SX350_CR124,0,180,350_.jpg
