  |
はてなキーワード: バックエンドとは
うん。
ざっと検索してみたりコメント読んでみた限り、反論してるのは反原発ゆとり脳に送る豆知識の人くらいしかいなかった。
で怪しんだよね。
多分元ネタが電力会社とか原発推進あたりの資料だろうから、なんとか教授みたいに、あからさまに変ないじり方はしていないんだろうけど。
元ネタが、推進派大好きな、資源エネルギー庁 施策情報 電力・ガス・熱供給事業政策 電気事業制度改革 電気事業分科会 コスト等検討小委員会なんだとすると、この資料って元々の意図が「原発のコストが一番安い」ではなくて、「バックエンドもろもろ含めても原子力発電のコストは他の発電方法と遜色ない」ってニュアンスだと思うんだよね。
太陽光だとか風力とかの、再生可能エネルギーとの比較であればいいけど、火力（特に石炭やLNG）や水力との比較だと、条件によって逆転したりするし。
核燃料廃棄コスト、補助金投入まで含めた維持、管理コスト 以下のように明記してあるため、加筆修正の必要なし。 税金・補助金関係は、詳しくは「資源・エネルギー関連予算案の概要」「電気事業と税金 2010」を参照。 5.9円/kWh程度と、低コスト。これは廃棄費用（原子力発電施設解体引当金総見積額と原子燃料サイクル・コスト）も計算に入れている。 現在は原発は補助金に頼っていない。原子力関連の補助金は1,816億円で、電力会社が払っている電源開発促進税は3,292億円。
だが、以下のように、増田の「論理的」主張を完全に否定する見解が研究者から示されている。
ゆとり脳は、どっちなんだろう。
http://mainichi.jp/area/kyoto/news/20110403ddlk26040355000c.html
東日本大震災で発生した東京電力福島第１原発の事故。放射性物質の流出や拡散は多方面に巨額の経済的被害をもたらし、他の電力会社も含めて安全対策の大幅な見直しを迫られている。事故前からエネルギーの費用計算で原発政策の問題点を指摘し、昨秋に原子力委員会で識者として提言した大島堅一・立命館大国際関係学部教授（経済学）に原発に関する問題点などを聞いた。 【聞き手・太田裕之】
◆原発では、（１）発電に直接要する費用（燃料費、減価償却費、保守費など）の他に、（２）原発に特有の「バックエンド費用」（使用済み燃料再処理費、放射性廃棄物処分費、廃炉費）（３）国からの資金投入（開発・立地のための財政支出）（４）事故に伴う被害と被害補償費－－を考える必要がある。
（１）（２）は料金原価に算入されており、この合計を発電単価とする。電力９社が公表している有価証券報告書総覧のデータ（１９７０～２００７年度の合計）を経済産業省の料金算定規則に基づき電源別に推計すると、１キロワット時当たり、火力９・８０円▽原子力８・６４円▽水力７・０８円だった。
ここで注意が必要なのは、原発は出力調整が出来ないため、需要の少ない深夜電力で水をポンプで上げて貯水し、昼間に発電する「揚水発電」をしている点だ。原発のコストは「原子力＋揚水」で見なければいけない。水力のうち、揚水は５１・８７円、一般水力は３・８８円。「原子力＋揚水」は１０・１３円となり、火力を上回り最高額となる。
－－（３）の財政支出はどうなってるのか？
国家財政からの資金投入は、一般会計と電源特会から行われている。電源別に計上された財政資料は存在しないため、「国の予算」を基に可能な限り再集計した。１９７０～２００７年度の合計で見ると、９５％が原子力に費やされていた。火力の１０６倍、水力の２７倍だ。
そして、（１）（２）に（３）を加えた「総単価」を電源別にみると、原子力１０・６８円▽火力９・９０円▽水力７・２６円。一般水力３・９８円、揚水５３・１４円で、「原子力＋揚水」は１２・２３円に跳ね上がる。原発は安価ではないどころか、国民にとっては最も割高であることが明らかになった。
原発の最大の課題は放射性廃棄物の処理・処分を含む発電後の放射性物質の扱いだ。使用済み燃料の再処理を含む核燃料サイクル事業、放射性廃棄物の処理・輸送・処分、原子炉の廃止措置など（２）の「バックエンド費用」は０４年の政府審議会報告書で総額１８・８兆円とされた。前述の単価計算でも含んでいる。
ここで問題なのは、劣化ウラン、減損ウランは高速増殖炉で利用できるとして廃棄物に分類されていないことだ。だが、高速増殖炉の見通しが立たない現状では廃棄物として加わる恐れがある。また、使用済みのＭＯＸ燃料（ウランとプルトニウムを混ぜた混合酸化物燃料）の再処理または処分の費用も含まれていない。さらに再処理費（１１兆円）に算入されたのは使用済み燃料の半分しか対応しない六ケ所再処理工場だけで、単純に考えて全量では倍額になる。高速増殖炉サイクルに関する事業も含まれていない。
そして、これらの事業は世界でも大規模な実施例がない。高レベル放射性廃棄物とＴＲＵ（長半減期低発熱放射性）廃棄物は処分地が未定だ。不確実な再処理工場の稼働率も考慮すると、現在のバックエンド費用の見積もりは過小評価ではないか。海外の再処理工場の実績稼働率は０７年で仏５６％、英４％。政府が想定する１００％は不可能で、実際には数倍に膨れ上がる恐れがある。
－－こうした指摘に対し、反応はどうか。
これらの調査・分析の結果は講演会などで報告し、昨年３月に東洋経済新報社から出版した。昨年９月には原子力委員会が原子力政策大綱を見直すかどうかの検討で識者として意見を述べた。その場でも疑問や反論があれば議論して正確にしたいと要望したが、特に大きな反論はない。公表データに基づいているので、反論しようがないのではないか。
まったくもってナンセンス。話の桁が違いすぎる。
大域ってテキスト情報の大域なんざ静止画の数百分の一も食わない。音声通話の数万分の一も食わない。動画の百万分の一も食わない。
同様の事を千人でやっても大域に関してはまったく問題が無いという話をしてるんだ。
TCPコネクションにしてもたとえばMicrosoft.comは毎秒平均7000～9000回もの攻撃を受けていると言われる。
Librahack氏は毎秒一回ではなく、アクセス毎に１秒のウェイトを入れていた。瞬時の返答があった場合の最高1回/secに過ぎない。
これが、どんだぇ少ないアクセス頻度だか。HTTPコネクション数に限って言えば１００人がクローラ使ったとしても中古パソコンで裁ける程度の話。
バックエンドDBがあってもそう。オラクル使っといて一人当たり数万アクセス程度でこけるとか無駄遣いもいいところ。
今回の状況って、個人用に図書館の目録作りたいんですとかいって図書館の全部の棚の前にびっしり大量の人がはりついて他の人が棚使えなくなってるような状況と一緒でしょう。
鳴門海峡に割り箸千本さしたら海流が止まってしまったというぐらいナンセンス。常識的に考えてちっとも大量の人ではない。
ご自由におとりくださいと書いてある店のチラシを１人で無意味にごっそり全部持っていくようなもんだよね。
限りあるリソースの占有ではない。チラシをとろうとしたら突然床が抜けて屋根が落ちてきたようなもの。
まさかこの程度で落ちるわけないし、適切なエラーが返ってこないし、どうなってるんだ？と思っていたら逮捕されました。あまりに理不尽。
三菱が税金ぼったくって、図書館も税金無駄づかいを知らん振りの怠慢。まともに作れば落ちるようなアクセス頻度ではない。
元増田です。
を多くの皆様にお読みいただけましたこと、大変ありがとうございます。
にしても、スイス戦は完敗でした。
オットさんのチームを相手にするときは、たまたまアイスの読みに失敗するとき
（これはどんな名スキップでも1大会にいつかは来ることがほとんど）を除けば、
辛抱強くつきあって細かなミスをつくか、スーパーパフォーマンスを生かすしかないのですが、
今のチーム青森ではちょっと辛かったです。
＃過去に日本は、五輪と世界選手権では1度しかオットさんに勝ったことがありません。
＃放送中に何度も紹介されたようにトリノではラウンドロビン突破の可能性を絶たれ、
＃08年世界選手権では準決勝進出戦で勝つもその後のブロンズメダルマッチで破れ、
＃今回の敗戦。まずはオットさんに勝てるようになることが目標です。
決勝トーナメント進出は自力を尽くした上で他力に委ねられたとはいえ、まだまだ一つずつの試合は見所満点です。
06年トリノ五輪金メダリスト、アネッテ・ノルベリさんの率いるチームです。
世界各国の迫力あるマダムカーラーをすでに数多くご覧になったことと思いますが、ノルベリさんのオーラはまた一回り大きなものです。
その辺もぜひお楽しみください。
ノルベリさんのチームはスウェーデンのヘヴィーメタルバンド「Hammerfall」のPVに出演したこともあります。
確かにこのチームは、ヘヴィメタでした。それくらいの破壊力があるチームでした、トリノの頃は。
トリノの後は、もちろん世界でも上位の実力のチームではあるのですが、世界選手権の代表選考会で敗れたりとか、
年齢から言ってもさすがに全盛期は過ぎたかなと思わせるところもありましたが、このバンクーバーではちょっと
以前とは印象の違うカーリングをしてきました。
これはスイス戦のスコアなのですが、このゲームが実に特徴的でして、
・お互いにスチールしたエンドがひとつもない（後攻のミスがない）
・ブランク（0-0）のエンドがひとつもない（先攻が確実に1点を取らせている）
・3点以上取ったエンドがひとつもない
ということで、今日オットさんのゲームをご覧になった方々は、その堅実さに閉口されたことと思いますが、
今大会のノルベリさんは、そのオットさんを上回る固い試合運びで勝ち星を稼いでいます。
（トリノの頃は、もっと攻撃的な印象が個人的にはありました。当時はあまり知識もなかったので間違っているかも）
このノルベリさん相手に、日本は五輪・世界選手権含めて7回対戦して1度も勝てていません。
トリノ五輪のラウンドロビンでは、かなりのところまで勝利に近づいたのですが、こちらのミスではなく実力で粘られ、
エクストラエンドまで持ち込みましたが力尽きました。
上記のような固いゲーム運びは、ひとつ何かが決壊するとダダすべりとなり、現にロシア戦では1-10で7エンド終了時
ギブアップという惨敗を喫しています。
今のチーム青森がそこにつけ込めるかどうかは、やってみないとわかりませんが、この巨大な壁相手に、胸突八丁の状態で
どう挑むか、そこを楽しみにしてください。
デンマークは、カーリングの実力とは違った意味で、いろいろ面白いところがあります。
20代のデュポーン姉妹のルックスとか、カーリングチームでは珍しいスカート着用とか。
それと、このチームはスキップがフォース（4番目）ではない珍しいチームです。
チーム最年長、36歳のアンジェリーナ・イェンセンさんがセカンドでスキップとなります。
技術に優れた若いデュポーン姉妹がバックエンド（3、4番手）となり、経験値の高いイェンセン姉妹が
ゲームを作るフロントエンドとスキップをつとめる、ということで、チームの戦略に合致しているんですね。
スキップ＝フォースという固定観念を取り除くうえでも、この試合、中継してほしいんですけどね。
（デンマーク戦は放送されるかどうか、まだ未定なんです）
このチームは世界選手権で銀1、銅1と国際実績はあるのでランキングは高いのですが、チーム青森は
このチーム相手にはとても相性がいいのです。
そういう意味でも、この試合は注目なのですが、とにかく生中継してほしいなあと。
（この稿、書きかけです。まだ続きます）
分散コンピューティングやグリッドコンピューティングで計算が出来るからスーパーコンピュータが不要だという発言が、実際に計算を行っていない人からなされています。であれば世界中で一カ所に集めたスーパーコンピュータがるのはなぜか？分割した計算を最終的に集めて同期を取らないといけないから。
一方で、ウェブ分野では、分散コンピューティングによる並列計算や、それをサポートする技術に注目が集まっているのも事実。基本的には、PCで使ってるCPUコア単体での性能向上が見込めなくなってきたのが大きな原因ではあるけど、それだけじゃない。
早い話がGoogleのMapReduceで、全体の処理を部分に分割できるタイプの計算なら、並列計算を非常に簡単にプログラミングできるフレームワークが出てきている。この間同社がリリースした「Go」もそうだね。
Googleがこうしたアーキテクチャを用いるのは、基本的にはコストの問題。Googleのバックエンドは、新しいマシンを投入すれば投入しただけ規模を拡大できる「スケールアウト」型のアーキテクチャになっている。マシン自体もコモディティなパソコンがベースになっているので、新規導入コストが非常に安い。この辺は、典型的な「スケールアップ」であるスパコンとは対照的（例えば地球シミュレータは、アップグレードのために200億円近くのコストがかかったりしている）。
また、ランニングコストも非常に安くできる。壊れたマシンは自動的にシステムからパージされるので、後からそのマシンだけ取り替えればいい。省電力の意味でも結構有効らしい。
このシステムが苦手なのは、元増田が引用したように、まさに計算の同期が頻繁に必要なタイプの計算。ただ、そうでないタイプの計算に有効なのはもちろん、コスト面で総合的に上回ったりとか、アルゴリズムの改良で分散システムでも扱えるようになるとか、そういう可能性はないのかなぁ、ということは思っている。
というわけで、詳しい人突っ込んでくれ。
今日、知り合いがエクシングワールドに参入した事を嬉しそうに話してくれた。
自分は生業がほぼSIerな人間なので、エクシングワールドについて既知であって、
実はそれなりに展開に興味(無論マイナス方向ねwww)があったのですが、
漸く身近にプレメンが現れたので色々と聞いてみました。
※恐らく、簡潔でなく、要点を得ず、凄い長文なんで適当に読んで下さい。
というような按配の事を言っていました。
先ずは気になるのが、
この3つを混同している事。
フレパーネットワークスはオフィシャルな情報のみでは直接ビズインターナショナルとの繋がりは無いように見える。
フレパーネットワークスの有価証券報告書にI.D.RとXING WORLDの記載はあるが、あくまで開発の受注として記載されている。
現在知り得る色々な情報を元にエクシングワールドの事を考えると、
となっているようだ。
有価証券報告書から想像できるお金の流れは、ビズインターナショナル→I.D.R→フレパーネットワークスとなっており、
一帯の関係がありそうなのですが、先にも書いたようにビズインターナショナルとフレパーネットワークスの繋がりは表立って目にする事が出来ません。
実際にフレパーネットワークスに問い合わせをした人は無関係であると言われたようです。
(プレメンは会員番号かなんかを伝えると教えてもらえると言っているようです。)
フレパーネットワークスとI.D.Rの繋がりは有価証券報告書で顧客として確認する事が出来て、
且つ、I.D.Rの代表取締役と同姓同名の方がフレパーネットワークスの大株主として存在しています。
(これははっきりと同じ人物か確認は出来てませんが･･･。)
有価証券報告書を見る限りではI.D.Rからの受注でフレパーネットワークスの業績は改善傾向になっています。
I.D.Rとフレパーネットワークスに関しては第9期の半期報告書(2007/12/28提出分)で、
仮想空間都市(セカンドライフ)の譲渡及び運営権の許諾という契約を結んでおり、
第9期の有価証券報告書(2008/06/30提出分)で、メタバース事業の基幹システム開発の受注の契約がなされています。
また、この有価証券報告書にはXING WORLDの記載がはっきりとあります。
フレパーネットワークスがI.D.Rに仮想空間都市の企画を売り渡し、
I.D.Rが買った企画の開発をフレパーネットワークスに発注したようにも見えますね。
もし、そうならばフレパーネットワークスは企画を売り収益を上げ、その売った企画の開発の受注でまた収益が。
おいしいのう、おいしいのうwww
で、そのI.D.RはビズインターナショナルにMLMでプレメンを募集させていると。
I.D.Rとビズインターナショナルの間の契約がどうなっているかは知る由もありませんが、
ビズインターナショナルの収益がI.D.Rに流れているんじゃないですかね。
で、まあ、結局プレメンが払ったお金はフレパーネットワークスに。こんなのはまあ戯言であって、ちょっと調べればなんとなく解る範囲なんですが。
ここまでアレなのにビズインターナショナルとの関係を表向きには否定するフレパーネットワークス。なんだろうなあwww
ウチは開発を受注しているだけなんで関係ありませんってか。何処の何を開発しているかは守秘義務があるからって事で答える必要も無いしな。
そのエクシングワールドも開発が遅れに遅れている様子ですが、どうなんだろうな実際。
自分の知人のプレメンはまだ画面すら見ていないようです。今年の09月にオープンするから大丈夫だと言っていましたが。
まあ、それも去年だったり今年の06月だったり諸説飛び交っておりますので、このあたりは突いてもしょうがないですねwww
ま、ここで先ほど箇条書きにしておきました件を漁ってみますwww
とか言わずに、にくじゃが喰っとけ、っていう話です。
この手の話に乗った人で完全に夢中になった人は説得すればするほどに、反撃の牙を剥きます。此方が如何に論理的に話そうとしても、
と、上記のような事を言ってのけます。
自分の知人は宮城県の情報公開に対しても、あれは行政の虚偽だとか、正しい知識の無いプレメンが勝手にやった事だと言っています。
情報公開された対象になっているのは企業であるビズインターナショナルであり、一部のプレメンではありません。勘違いしないように。
とまあ、ダラダラ駄文を垂れ流しましたが、仲の良かった知人や家族に上記のような事を言われると、大変胸が痛いものです。
自分はまた楽しく酒を飲みたいだけなのになあ。
結局、なにがしたいか、なにが学びたいか、だろうな。
元増田も大元増田も、とりあえず言語を学んだ。てにをはと挨拶は分かった状態。それでどうするのか、とりあえず小説を書くのか、言語学を学んでみるか、ラノベを研究してみるのか。
SICPだと、プログラミングとは何ぞや？とメタな言語学的になるのかな。あと、アルゴリズムとか、より抽象的、数学的な方向へ向かうのか。
ブックマークコメントに多いのは、とりあえず作れってやつ。しかし、現状で作りたいものがあるなら、もう作っているはずで、特にないから困っているのだろう。
ジャンル的にはWebアプリかGUIアプリか。あと、サーバソフトウェアもある。
Webアプリだと、HTTPとかブラウザ側と、CGIとかapache等サーバ側とのインターフェースを知る必要がある。他にもデータベースマネージャーとSQLに手を出すとか、railsとかフレームワークに手を出すか。
GUIアプリだと、ライブラリやフレームワーク、OSとのインターフェースを知る必要がある。データベースを使っても良いし、ネットワークに手をだすならSOCKETとか。WindowsならWindowsの、XならKDEとかgnomeとかの作法があるし。
GUIアプリでもだけど、サーバソフトウェアならネットワークやプロトコルの他に、スレッドだとかある。
これらも、一から自分で始めてみるか、既存の、例えば自分が使ってるOSSに機能追加してみるとか。
あと、アセンブラって出てたけど、コンピューターの実際的な構造とか、OS内部、ドライバの作りなんかへ進む手もある。
元増田は標準ライブラリを使ったプログラミングとフレームワークの内部構造を把握すればよいんじゃないかな。
というわけで、よりフロントエンドなライブラリやフレームワークの方向か、バックエンドなシステムコールやOSへ向かうか、
より抽象的なアルゴリズムとか情報理論の方向か、実際的なネットワークやデータベースなどの周辺要素へ向かうか、
どういう方向に興味があるのか分からない事には。
大都会のシステム開発に、ぽっかりと大きな穴が開いているようだ。
東京都内で、バグの多すぎる納期間近の３６０人月のプロジェクトが七つの外注候補に緊急要請を断られた。約１時間１５分後に官公庁に運ばれてサービスインしたものの、３日後にデータベースまわりのバグで動作停止となった。
同じようなことが一昨年、奈良県でもあった。バージョンアップ中のバックエンドシステムが動作不良になり、デバッグが必要になったが、隣の大阪府も含めて１９の外注に受け入れを断られ、やはりDBのバグで動作停止なった。
背景には、全国的なプログラマ不足がある。急な開発を受け入れる余力が、ITベンダに乏しくなっているのだ。
それにしても、ITベンダがたくさんあるはずの東京で、と驚いた人も多かったのではないか。厳しい条件の中でも、なんとか開発をやり遂げる態勢をつくるにはどうすればいいのか。今回起きたことを点検し、今後のために生かさなければならない。
動作停止したプロジェクトは仕様上の曖昧な部分や契約面での不透明な箇所があった。元請けベンダの手に負えないことから、下流工程での受け入れ先を探した。
最初に連絡したのは、危険の大きい開発案件に２４時間対応するために都内に９カ所あると言われているベンチャー系開発企業の一つ、○○だ。
ところが、○○では中堅社員の過労による退職のため、７月からは週末や休日の開発要員は１人になり、急な開発の受け入れが原則としてできなくなっていた。
この日は土曜日だった。１人だけのプログラマは受け入れを断り、他の開発企業を紹介したという。紹介した企業にも「COBOLを書ける人間がいない」などの理由で次々に断られ、○○は２度目の依頼で退職者を呼び出して対応した。
ベンチャー系開発企業は最後のとりでだ。そこが役割を果たせないようでは心もとない。プログラマ不足という事情があるにしても、東京都には急な仕様変更に備える態勢づくりにさらに努力してもらいたい。
いくつもの企業で受け入れを断られた背景には、都市圏ならではの要因もある。地方と違って開発企業が多いため、ほかで受け入れてくれると考えがちなのだ。
そうした考えが、危険なプロジェクトに備えるSI業界のネットワークが必ずしも十分には機能しないことにつながる。マネージャ同士でもっと緊密に連絡を取り合うことに加え、ネットワークの中で使い勝手の良い外注先を探す司令塔のような存在をつくることも考えたい。
もう一つ大切なことは、全く別々に運用されている元請けと下請けの連携を強めることだ。元請けで開発が進まないときは、とりあえず下請けを投入する。そうした柔軟な発想が必要だ。
プログラマ不足を解消する努力はむろん大切だが、SI業界やマネージャの間で連携に知恵を絞ることはすぐにでもできる。
http://www.asahi.com/paper/editorial20081023.html#Edit1
2008年09月28日 ocs 増田 LLFutureでも語られてたけど、RoRは進歩が早すぎるという暗黒面があるらしい。http://www.ey-office.net/public/LLFuture2008.pdf
進歩するのはいいんだけど、互換性が軽視されてるってのはどうなんだろう。リンク先読むと、互換性はない、古いバージョンはメンテされない、サーバーのリブートは毎日と書いてある。要するに枯れるまで触らない方が安全ってことか。
2008年09月28日 ezookojo 特定の記事が書かれた当時の手順のままで動作しなければならないRailsかわいそうです / とか言ってるとオフィシャルのREADMEやガイドページだったりする
一人ツッコミやってるので、補足するのもなんだけど。ダイアログの手順が少々変わったくらいでうろたえている訳じゃなくて、指定されたサイトから最新のパッケージをダウンロードして、そのパッケージにとって正しいと思われる手順を実行したら、動かなかった。
2008年09月28日 dbfireball 増田 Railsすごいよ！って言ってた去年あたりだったら、マジで10分でした。そこから色々アップデートされてその通りにやってもできないっていう状況。
参考にしたのは10分で作るRailsアプリfor Windows。やっぱり互換性がなくなってるんだ。
2008年09月28日 takeshiketa takeshiketa RoRラブな俺だけど、同意。RoRは導入コストで語るんじゃなくて、手になじんだ後の生産性で語るべき
うーん。ラブな方も現状については同じ意見。手になじんだ後の生産性ってのは一見わかる気もするけど。作った後のメンテナンスは誰がやるんだろう。導入コストは低くないと言ってるみたいだけど、互換性軽視の開発が続く中で、デベロッパの手をなじませ続けるラニングコストはどうなんだろう。
2008年09月28日 FTTH # |ω・）…… ハイハイハイ俺も云いたいです！！ RoRの機構使うよりSQLベタ書きの方がポータビリティもメンテナンス性も良いと思います！ バックエンド意識しないでいいようなアプリなんてどうせその程度です！！
ポータビリティもメンテ性もべた書きより劣るフレームワークって…。
幸いITのプロじゃないので他人ごとなんだけど、RoRで業務サイトを構築している人が居るってのは、少々寒気がする。肝が据わってるのか、想像力がないのか、それとも俺が思っているよりずっと人月って金がかからないのか。
Slicehost VPS Hosting is now Rackspace Cloud Servers hosting
Slicehost Articles: IP failover - High Availability explained
All requests for the website come to the front end Slice.
That Slice then proxies the request to larger Slices running in the backend of the network.
Slicehost Articles: IP failover - Slice setup and installing Heartbeat
Monitoring Ubuntu Services Using Monit | Ubuntu Geek
$ sudo tasksel
Slicehost Articles: Ubuntu Hardy setup - page 1
Slicehost Articles: Ubuntu Hardy setup - page 2
Automatic Rails on Ubuntu 8.04 LTS « Enjoying Rails
joerichsen's gist: 16225 — Gist
Setting up Ubuntu Jaunty for Ruby and Rails development | Joe Ocampo's Blog
5-minutes to Rails // Slicehost VPS Hosting is now Rackspace Cloud Servers hosting
slicehostでRails2.2.2を動かすまで - なんとなく日記
Slicehost Articles: Ubuntu Hardy - Ruby on Rails
Slicehost Articles: Ubuntu Gutsy - Django installation
UbuntuにLAMPサーバを手早くインストールする方法 - builder
LAMP（Linux、Apache、MySQL、PHP）サーバを手早くインストールする最も簡単な方法
Slicehost Articles: CentOS setup - page 1
Slicehost Articles: CentOS setup - page 2
CentOSのPHPにはマルチバイト対応入ってませんのであとから入れましょう (技術メモ)
タグ「slicehost」を含む新着エントリー - はてなブックマーク
naotaka blog » Blog Archive » Slicehostに申し込み
slicehostでUbuntu8.04の設定1 初期設定 - delab
Slicehost : Tag Archives - delab
ホスティングサービス Slicehost のドキュメントがすばらしい : 僕は発展途上技術者
SlicehostへのRedmine導入手順（Ubuntu Gutsy)
つくるぶガイドブログ: 失敗しない Rails が動かせるホスティングサービス選びと環境構築
具体的にどこがおすすめかという質問を受けた場合、共用サーバーならば海外の Slicehost、専用サーバーならさくらインターネット
Slicehost に移行しました - milk1000cc
Web 管理画面で、OS 再起動・再インストール、コンソール操作、DNS 設定などができます。
バックアップ入れても月額 $25、
レンタルサーバはさくらインターネット | 「さくらのレンタルサーバ」「さくらのマネージドサーバ」
格安レンタルサーバーならステップサーバー | 高機能で格安なレンタルサーバーTOP
レンタルサーバーNSF - 月額100円〜容量無制限可の格安レンタルサーバー
ロリポップ！レンタルサーバー - 月額105円～容量最大30GB 初期費用半額キャンペーン中！
チカッパ！レンタルサーバー - ご利用中のユーザー様へのご案内
レンタルサーバー「heteml」 - 大容量・高機能のレンタルサーバー
Slicehost VPS Hosting is now Rackspace Cloud Servers hosting Slicehost Login
Linode - Xen VPS Hosting Linode Login
Linode.comのVPSホスティングを契約してみた - m-kawato@hatena_diary
Webbynode Hosting - Host and Deploy Ruby on Rails, Django, Node.js, PHP and more
VPS Hosting � Virtual Private Server Hosting | DataRealm.com
Coupon codes, promotions and special offers - CheapVPS
VPS :: VPS Hosting :: VDS :: Virtual Private Servers :: Virtual Dedicated Servers :: Server Axis
RootBSD - FreeBSD and OpenBSD VPS Hosting - Welcome to RootBSD
レンタルサーバーならVPSレンタルサービス｜VPS stock
激安の専用サーバ：ServerPronto なんと月額$29〜 | 海外サーバ.jp
サーバ本体無償提供、ホスティング向きハウジングサービスを月額7,780円で
専用サーバの料金と仕様 | 専用レンタルサーバ（ホスティング）のさくらインターネット
Dedicated servers | Windows and Linux dedicated web servers
Dedicated Servers, Self-Managed Dedicated Server, Dedicated Hosting at ServerPronto
MegaNetServe - Value Driven Dedicated Servers on Linux, Windows 2008, Windows 2003 & FreeBSD
Domain Names, Web Hosting and SSL Certificates - Go Daddy
Dedicated Servers, vSERVERs – SERVER4YOU
Web Hosting | Dedicated Hosting | Domain Registration |
海外の安い専用サーバプランをいろいろ並べて検討してみた - GIGAZINE
再度、レンタルサーバ（共有ではなく「専用」です）で、国内外を.. - 人力検索はてな
Website Hosting in the Yahoo! Directory
デル株式会社(Dell Japan)の公式サイト | Dell 日本
HP-ProLiant-ML115 G5まとめwiki - トップページ
各メーカーの最安サーバを比較検討してみた - GIGAZINE
バックエンドアーキテクチャーのおかげで、2テラバイトの画像を、$1000のLinuxサーバー1台で賄うことができる。だから、年間わずか20万ドル程度の設備投資で、現在サーバー500台を保有している。
ドメイン登録 - VALUE DOMAIN:バリュードメイン
Domain Names, Web Hosting and SSL Certificates - Go Daddy
Amazon S3をWindowsにマウントできるJungle Disk Kawanet Tech Blog/ウェブリブログ
Online storage and backup | Secure file sharing | Unlimited online storage | Jungle Disk
Amazon.co.jp： 現場が教えるホスティングサービスの勘所―立ち上げから運用管理までのノウハウ (NEサポートシリーズ): 合阪 省: 本
Amazon.co.jp： レンタルサーバをはじめよう!―ホスティングのためのサーバ構築術: 斎藤 高洋: 本
議論しても仕方のないことだけれども、このテーマだけはどうしても一度は向き合わずにはおれない。自分の頭を整理するためにも、文字にしてみたいと思う。
米国にはSI業界ってあまりなくてコンサルティングとかプロフェッショナル・サービスに分かれているのに対し、欧州では日本的なSIerが結構あって、富士通サービスなど日本勢も頑張っている。この違いはどの辺からきているかというと、結局のところ雇用流動性だ。米国では要らない社員をいつでも切れるから、プロジェクトの中核には技術を分かった人間をインハウスで採る。そういう連中を必要に応じて雇える労働市場の厚みがあり、要らなくなったらクビにしても問題ない。
日本のソフトウェア産業が弱いと言われる一つの理由として、この説明は自分にはしっくりくるし、それが政策的な問題だと言われると、とても悲観的な気持ちになる。職場環境の上でも技術の上でも、本気でソフトウェアをやるなら海外に行った方がいい、というのは少なからず感じるのだけれども、じゃあ自分も海外へ、という気持ちにはなれない。一度は暮らしてみてわかった。自分は日本が好きだ。
だから大前提として、日本で何が出来るんだろう、という話になる。あるいは、日本のソフトウェアエンジニアは何に力を振り向けるべきなんだろうか。
今の時代、どんな業界でもソフトウェアは必要とされるし、仕事がなくなることはないだろう。そして日本人が必要とするソフトウェアは、どうせなら日本人が作った方がよいだろうと思う。別に世界に打って出るようなものではなかったとしても、必要とされるものは誰かが作らないといけないんだ。
問題は、コストか。日本の優秀なエンジニアがみんな海外に出て行くのだとしたら、誰に仕事を頼むのかということになる。同じお金を出すならば、日本の平均的なエンジニアよりも、アジア各国の優秀なエンジニアに頼む方がいいのではないか。少なくとも日本の経済的優位が続いている限りは。
日本でソフトウェアの仕事がなくなるわけではないけれども、日本のエンジニアが負けないためには、海外のエンジニアと比べてコスト優位性がなければならない。そのためには安い給料に甘んじる・・という選択肢は考えないことにする。前向きに行こう、うん。
人件費を下げることなくコスト競争力を上げるには、どれだけ付加価値のあるものを作り出せるか、ということだ。
どうすれば価値の高いものを生み出せるか、なんてのは自分にはわからないし、自分はただ目の前で必要とされているもの、自分が価値あると思うものを精一杯作り続けるだけだ。
ただ、それでもなんとなく時代の変化みたいなものは感じている。
ただ著者は、物理的インフラが集中する一方、情報は各ユーザーがつくるuser-generated contentとして分散化し、ウェブが「バルカン化」する可能性が高いと予想する。その結果、在来型のメディアは無料化して産業としては縮小し、新聞は広告媒体となり、映像・音楽はインフラ産業のプロモーション・ツールとして買収されるだろう。意外に時代は、ソフトがハードのおまけだった時代に戻るのかもしれない。
コンピュータの世界は集中と分散を繰り返すと言われるが、今はまた集中の時代へと向かってきている。Googleの言う「クラウドコンピューティング」が成功するかどうかはわからないけれども、そうでなくともサーバの集約や仮想化といった話はとても身近だ。
インフラが集中し、ハードウェアのコストが上がれば上がるほど、ソフトウェアのコストは相対的に小さくなる。ソフトウェアの開発費が「おまけ」と言われるくらいに小さく出来るならば、逆にソフトウェアの付加価値は非常に高くなる。集めたハードウェアを生かすのはソフトウェアなのだから。
集中の時代には、ソフトウェアを作りやすくなるのかもしれない。
そうであるなら、自分たちも集中の時代に合わせたソフトウェアを作るというのはどうだろうか。必要なものはいくらでもあるだろう。多数のマシンを効率的に活用する基盤システム。多数のユーザにサービスを届けるウェブシステム。業務をサービスとして行なうSaaS型アプリケーション。システムを集中管理し、プロセスを改善していくバックエンドの技術。
個々の技術がビジネスとして成功するかは全くの別問題なのでここでは考えないけれども、個々のエンジニアの立場として考えるならば、集中の時代を意識して技術を磨くというのは一つの方向ではないかという気がしている。
