地熱発電の現況｜河野太郎公式ブログ ごまめの歯ぎしり
７月にスタートした固定価格買い取り制度の対象に認定された設備容量は、２ヶ月で１３０万キロワット、既に原発１基分相当となった。 その内訳は、非住宅用太陽光発電が７２.５万ｋＷ、住宅用太陽光３０.６万ｋＷ、風力２６.２万ｋＷ、バイオマス０.６万ｋＷ、中小水力０.１万ｋＷ。 まだ地熱発電はあがってこないが、実は少しずつ、地熱発電も進んでいる。 岩手県八幡平市では、岩手地熱が開発する７０００ｋＷクラスの地熱発電所が２０１６年にも運転を開始する。将来的には５万ｋＷクラスまで規模を拡大できるが、東北電力の系統の問題で７０００ｋＷからスタートすることになった。しかし、ケガの功名で発電容量７５００ｋＷ以下ならば環境アセスが不要となり、４年程度開発期間が短縮された。 八幡平市ではこの他に安比でも検討が進んでいる。 秋田県湯沢市では、山葵沢・秋ノ宮地区で湯沢地熱の４.２万ｋＷクラスの地熱発電所の環境
SubversionとGitでリポジトリ間を同期させるツール「SubGit 1.0」 | OSDN Magazine
チェコTMate Softwareは9月24日、SubversionからGitへのマイグレーションを容易にするツール「SubGit 1.0」を公開した。SubversionリポジトリとGitリポジトリを双方向にレプリケーションする機能を持ち、既存のSubversion環境を変更なしにGitからアクセス可能にするという。 SubGitはJavaで実装されたツールで、SubversionレポジトリをGitリポジトリにマイグレーションする機能を持つ。また、SubversionとGitを併用するための同期機能も備えている。Gitには同様の機能である「Git-Svn」が含まれているが、これと比べた優位点として、レポジトリのクローンが不要な点、Gitレポジトリに対してコミットでき両者間の変換は最小限で済む点、SubversionとGitの両方の機能をすべて利用できる点、さまざまなツールを利用できる点な
めんどうくさいWebセキュリティ(Michal Zalewski) - ただのにっき(2012-09-27)
■ めんどうくさいWebセキュリティ(Michal Zalewski) これは誕生日プレゼントにいただいたものですね、ありがとうございます。なにしろ書名のとおりマジで「めんどうくさい」ので、読むのにすごい時間がかかってしまった。といっても文体が理解しにくいとか、内容が難解というわけではなくて、Webの世界があまりに混沌としていて読んでてずーんと気分が重くなるので読み進むのが「めんどうくさい」(文体はところどころくすぐりが入っていたりして、軽くてわかりやすい)。 面白いと思ったのが、この本はXSSとかCSRFみたいなセキュリティ上の問題を(たとえば事例を交えるなどして)解説するというスタイルではない、という点だ。そうではなくて、Webというこの10年間に急速に、そしてつぎはぎだらけに発展してきたテクノロジーが、なかば必然的に内包することになった「仕組み上の問題点」をつぎつぎとあげていく。もち
jQueryのバブリングと、「return false;」「e.stopPropagation();」「e.preventDefault();」について
jQueryのバブリングと、「return false;」「e.stopPropagation();」「e.preventDefault();」についてTweet どうも（ｏ´ω｀ｏ）ノ 今年もあと10週間ですねー。 今日はjQueryの、イベントのバブリングについてです。 バブリングの「バブル」は泡です。たぶん。 jQueryはHTMLで書かれた要素（DOM）を、以下のようにツリー形式で持っています。 そして、一番下のA要素をクリックすると、それが一番親のwindowまで伝わります。 これがイベントのバブリング（「伝達」とでも言うのかな）です。 クリックイベントは、例え自分がクリックされていなくても、子孫要素がクリックされれば発動します。 イベントは子供から順番に起きます。 よくAタグの「href="#"」を無効にするために、Aタグのクリックイベントの最後で 「return false;
hostsにループバックアドレスを指定することでリスクが増大するケース
前のエントリhostsファイルにループバックアドレスを指定することは危険か?で、hostsにループバックアドレス（127.0.01）を記述することは危険とは言えないと書いたのですが、その後malaさんとkazuhoさんから、レアケースではあるがリスクの増加はあるよという指摘を受けました。 議論の想定は、Android端末のローカル上にWebアプリケーションが動いており、それに対する攻撃が可能か否かを検討するものです。この状態で、利用者が広告よけを目的としてhostsファイルを修正して、example.comを127.0.0.1に指定しようとしていると仮定します。 まず、malaさんの指摘ですが、Google+に読者限定で投稿されています。このエントリは読めない方が大半なので以下に転載します（転載の許諾はいただいています）。…と思ったらmalaさん自身が見える場所に転載いただいたいました。こ
hostsファイルにループバックアドレスを指定することは危険か?
Androidの広告よけにhostsファイルを書き換えるAdAwayというアプリ（ルート化必要）が紹介されています。それがきっかけとなり、hostsファイルを書き換えることの危険性、とくに他人が作ったhostsファイルをそのまま自端末に適用してしまうリスクがtwitterで話題になりました。 これはまったく正しいのですが、なかのきえた氏から、以下のようにlocalhostのIPアドレスを記述することも問題と指摘がありました。 @shigecchi2007 @ks_desire localhost系を書くこともヤバイのです。WindowsでローカルのIISが回り込まれたりWinNTの頃から既知の問題なんです。やるならFirewall機能で適切にブロックする事が必要です。 9月 23, 2012これに対して、ko-zuさんから、ループバックやLAN内ホストでの脆弱性対策についてというブログ記事
仕事の内容に応じて適切な「モード」に切り替える | シゴタノ！
クルマがスピードに合わせてギアを切り替えるように、人も取り組む仕事の内容に合わせて切り替えるとうまくいきます。 人にとってのギアにあたるものは「モード」です。これ自体は目に見えないものですが、仕事の内容にフィットしたモードでいるとき、人は高いパフォーマンスを発揮します。 「今日の午前中はなぜか調子がよかった」「午後の会議後に○○をやったらいつもより早く片付いた」といった、偶然良い結果が得られることがありますが、この場合がまさにモードが仕事の内容にフィットしていたときです。 この「偶然」を「必然」に変えることができれば、すなわち必要に応じて必要なモードに切り替えることができれば、仕事はもっと楽に片づけることができるでしょう。 では、具体的にはどうすれば良いか？ 環境とモードの掛け合わせで決まる 僕自身、特定のオフィスを持たず、自宅か出先かのいずれかで仕事をしています。 自宅でしかできない仕事
「クラウドにこそ必要なSIがある」、地場の小規模SI案件などが増加。サイボウズが支援プログラムを発表
「（クラウドの）cybozu.comを導入したお客様のうち、パッケージからの移行が約3分の1、他社からの移行が3分の1で、残りの3分の1はグループウェアを使ったことがなかったお客様。明らかにクラウドは市場のすそ野を広げている」。 サイボウズ代表取締役社長 青野慶久氏は、26日に都内のホテルで開催したイベント「Cybozu.comカンファレンス2」の記者発表会場でこう発言し、クラウドが市場を広げているとの認識を示しました。 「クラウド版を見てみると、5ユーザーとか7ユーザーといったお客様がたくさん含まれている。グループウェアを使うのは10ユーザー20ユーザーくらいからだと思っていたが、そうではないとクラウドが教えてくれた」。青野氏はこうした小規模ユーザーが増えた理由として「クラウドでは運用をまかせられるからではないか」と分析しています。 イベントには「元気があればチャレンジできる！」アントニ
IPv6 IPoE接続事業者数が3から最大16に拡大へ:Geekなぺーじ
これまで、BBIX、JPNE、インターネットマルチフィードの3社だったIPv6 IPoE接続事業者が、最大16に拡大されるようです。 NTT東日本 報道発表：次世代ネットワーク（NGN）におけるIPoE接続事業者数の拡大に係る接続約款変更の認可申請について NTT西日本 ニュースリリース：次世代ネットワーク（NGN）におけるIPoE接続事業者数の拡大に係る接続約款変更の認可申請について 今年の5月に総務省で開催された「IPv6によるインターネットの利用高度化に関する研究会（第18回）」当時は、IPv6 IPoE事業者(VNE)数は恐らく検討中だったものと思われます。 そのときには「数十」と発言した後に「十数」と言い直されていましたが、最終的には16となったようです。 これは結構大きな変化と言えそうです。 引き続き、今後の推移を見守りたいと思う今日この頃です。 関連 「マルチキャストを含めた
pushの権限を持っていないリモートリポジトリに更新内容を反映する - podhmoの日記
pushの権限を持っていない環境(ユーザ)で適用した更新を、リモートリポジトリに反映したい時がある。 例えば、本番環境でのhotfixなど。 今のところ以下のような手順で行っている。 (localとproductionという2つのホスト上で作業をしているとする。localが自分の環境。productionが本番環境) 大まかには productionでformat-patchでpatchの作成 localでpatchを取り込んでリモートリポジトリにpush productionでリモートリポジトリの変更をpull 実際の内容 production git add . #変更をaddして git commit -m "this-is-hot-fix" #commit git format-patch HEAD~ ## 0001-*.patchが作成される local scp producti
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「Flash Player 11.5」「AIR 3.5」ベータ版が公開、高速リリースサイクルへ移行