スタッフブログ
先週にまた一つ年齢が上がったせいか、週の前半からバテ気味のgusagiです
さて、こちらでminahitoさんが書いていますが、近いうちにXCL2.1.7が出るようです。
前述のフォーラム内、minahitoさんの投稿から引用：
バグFIXなどが中心のマイナーアップデートで、HD1.0.3で適用されたパッチなども取り込まれる予定です。
今のところ月内にはRC版がリリースされるようですので、興味と余力のある方は、2.1.7RCがリリースされたらテストに参加してみては如何でしょうか？
また、XCL2.2の開発も、gigamasterさんとkilicaさん中心で着実に進んでいるようです。
こちらについても、XCL2.2 Profileモジュールのプロトタイプが先日公開されています。
こちらは、まだ公開サーバに導入するのは難しいようですが、今のうちにXCL2.2の雰囲気を味わってみたい方は試してみるのも良いかも知れませんね
さて、こちらでminahitoさんが書いていますが、近いうちにXCL2.1.7が出るようです。
前述のフォーラム内、minahitoさんの投稿から引用：
今後は 2.1.x 系で可能なフィーチャーリクエストの消化と、新しいデリゲートの導入、 v2.2.0 レベルのコンフィグレーション解釈の適用（デリゲートマネージャなども選択可能）を行い、 3/14 〜 3/15 あたりに RC アーカイブを作成する予定です。
バグFIXなどが中心のマイナーアップデートで、HD1.0.3で適用されたパッチなども取り込まれる予定です。
今のところ月内にはRC版がリリースされるようですので、興味と余力のある方は、2.1.7RCがリリースされたらテストに参加してみては如何でしょうか？
また、XCL2.2の開発も、gigamasterさんとkilicaさん中心で着実に進んでいるようです。
こちらについても、XCL2.2 Profileモジュールのプロトタイプが先日公開されています。
こちらは、まだ公開サーバに導入するのは難しいようですが、今のうちにXCL2.2の雰囲気を味わってみたい方は試してみるのも良いかも知れませんね
最近、時間をつくって社内で利用するフォームをつくっています。
フォームといってもWebアプリケーションで等のコンピュータシステム用のフォームでなく、印刷してペンで書き込む紙ベースのフォーム（記入用紙）です。
多くの会社では、このようなフォーム（記入用紙）は既にいくつも作ってあって運用されてると思います。
RYUSは設立時は二人だけだったので、ほとんどの用事は口頭で片付き、決まったフォームの必要性が低かったので、整備しないままきてしまってたんですね。ここ1年強で、急に人が増えてしまったので最近になって必要性を感じてつくってるわけです。
フォームの作成にはエクセルや iWorkなどのソフトを使うときもありますし、イメージが固まらないときは、A4のコピー用紙に手書きでざっくりと作成してコピーして使ってみることもあります。
こういう紙ベースのフォームの良さは、不完全でも利用できてしまうところにあります。
記入する欄が用意されていなくても、その気になれば余白に記入してカバーすることも可能です。
記入した内容を一覧したくなったら、ひとまずデスク上にバァッと広げてしまえば、一覧性も確保できます（数に限りはありますが）
また、フォームを作成する時間コストが非常に少ないというのも利点です。思いつきでパッとつくれますし、運用して不満な点があってフォームを修正するのも短時間で済みます。
ただ紙だと検索性が悪く、同時に別々の席で複数の人が参照することはできないなど不便な点もありますので、ある程度運用してみて、コンピュータシステム化した方が良さそうだと感じたら、XOOPSのモジュールとして作成して、社内ポータルサイトへ組み込もうと思っています。
もし社内の業務をシステム化することを考えているなら、まず紙のフォームを新たに作ったり、今あるオームを改良することから考えてみてはどうでしょうか？
紙のフォームをどんなに改良しても運用コストが高くつくという結論になってから、コンピュータシステム化を考えてみても良いと思います。そのときは是非ご相談くださいね。
フォームといってもWebアプリケーションで等のコンピュータシステム用のフォームでなく、印刷してペンで書き込む紙ベースのフォーム（記入用紙）です。
多くの会社では、このようなフォーム（記入用紙）は既にいくつも作ってあって運用されてると思います。
RYUSは設立時は二人だけだったので、ほとんどの用事は口頭で片付き、決まったフォームの必要性が低かったので、整備しないままきてしまってたんですね。ここ1年強で、急に人が増えてしまったので最近になって必要性を感じてつくってるわけです。
フォームの作成にはエクセルや iWorkなどのソフトを使うときもありますし、イメージが固まらないときは、A4のコピー用紙に手書きでざっくりと作成してコピーして使ってみることもあります。
こういう紙ベースのフォームの良さは、不完全でも利用できてしまうところにあります。
記入する欄が用意されていなくても、その気になれば余白に記入してカバーすることも可能です。
記入した内容を一覧したくなったら、ひとまずデスク上にバァッと広げてしまえば、一覧性も確保できます（数に限りはありますが）
また、フォームを作成する時間コストが非常に少ないというのも利点です。思いつきでパッとつくれますし、運用して不満な点があってフォームを修正するのも短時間で済みます。
ただ紙だと検索性が悪く、同時に別々の席で複数の人が参照することはできないなど不便な点もありますので、ある程度運用してみて、コンピュータシステム化した方が良さそうだと感じたら、XOOPSのモジュールとして作成して、社内ポータルサイトへ組み込もうと思っています。
もし社内の業務をシステム化することを考えているなら、まず紙のフォームを新たに作ったり、今あるオームを改良することから考えてみてはどうでしょうか？
紙のフォームをどんなに改良しても運用コストが高くつくという結論になってから、コンピュータシステム化を考えてみても良いと思います。そのときは是非ご相談くださいね。
最近本屋さんに行く時間がなくて、枯渇していたところ、地下鉄の売店で発見した本です。
インド人の頭ん中
ご当地モノがわりと好きで読むのですが、インドモノは初めてでなかなかに興味深い内容でした。
その中でも記憶に残ったエピソードがあります。
日本人だけでインドのレストランに行き、シャンパンを注文。楚々としたウェイターさんがシャンパンを抜こうとしてのですが、なかなか抜けない。と、それまでの気取った態度が一変してなんとか抜こうと色々やり始め、とうとう「そうだ！瓶を振って泡立てれば抜ける」と言いだし、猛烈に瓶を振り始めたという。
あわてて止めるのですが聞きいれてもらえず、瓶を振り続けるウェイターさんと、「そんなことしたら空いたとたんにシャンパンが半分になっちゃう」と困る日本人。結局はシャンパンはいいから他のものをくださいというのを聞き入れてもらって事なきを得るっていうことなんですが。
筆者が驚いていたのは「なんで目先のシャンパンを抜くことに気持ちが集中してしまい、当初のシャンパンを抜いて提供するということを忘れてしまうのか（その方法では中身が半分になり、提供できないではないか）」ということなのですが。
筆者が思うにカースト制の行き渡ったインドならではのことではということ。カースト制はかなり細かく分かれていて掃除のカーストであれば掃除しかしない。電気修理のカーストならば電気修理しかしない。つまり電気屋さんが修理に来たとき、周りを散らかすだけ散らかして「電気は修理できたよ」という状態で帰り、あたりにはゴミの山が残る、という。掃除は自分の仕事の範囲でないから、ということが徹底しているからではないか、代々カースト制に縛られているインド人としては当然の成り行きなのかな、と推測しています。
でもこれ日本人でも、ときどき仕事などでやってしまわないでしょうか。最初は何かのために方法を考えていて、ある方法を思いつく。思いついた時点で「最初の何かのために」という部分を忘れ、ある方法の実現のみに気持ちが行ってしまうようなことが。
自分でもそんなことがあるといけないので、はっ！それたことやってるかも、と思い出せるためにもシャンパンを抜く方法、のエピソードを憶えていたいと思った次第です。
インド人の頭ん中
ご当地モノがわりと好きで読むのですが、インドモノは初めてでなかなかに興味深い内容でした。
その中でも記憶に残ったエピソードがあります。
日本人だけでインドのレストランに行き、シャンパンを注文。楚々としたウェイターさんがシャンパンを抜こうとしてのですが、なかなか抜けない。と、それまでの気取った態度が一変してなんとか抜こうと色々やり始め、とうとう「そうだ！瓶を振って泡立てれば抜ける」と言いだし、猛烈に瓶を振り始めたという。
あわてて止めるのですが聞きいれてもらえず、瓶を振り続けるウェイターさんと、「そんなことしたら空いたとたんにシャンパンが半分になっちゃう」と困る日本人。結局はシャンパンはいいから他のものをくださいというのを聞き入れてもらって事なきを得るっていうことなんですが。
筆者が驚いていたのは「なんで目先のシャンパンを抜くことに気持ちが集中してしまい、当初のシャンパンを抜いて提供するということを忘れてしまうのか（その方法では中身が半分になり、提供できないではないか）」ということなのですが。
筆者が思うにカースト制の行き渡ったインドならではのことではということ。カースト制はかなり細かく分かれていて掃除のカーストであれば掃除しかしない。電気修理のカーストならば電気修理しかしない。つまり電気屋さんが修理に来たとき、周りを散らかすだけ散らかして「電気は修理できたよ」という状態で帰り、あたりにはゴミの山が残る、という。掃除は自分の仕事の範囲でないから、ということが徹底しているからではないか、代々カースト制に縛られているインド人としては当然の成り行きなのかな、と推測しています。
でもこれ日本人でも、ときどき仕事などでやってしまわないでしょうか。最初は何かのために方法を考えていて、ある方法を思いつく。思いついた時点で「最初の何かのために」という部分を忘れ、ある方法の実現のみに気持ちが行ってしまうようなことが。
自分でもそんなことがあるといけないので、はっ！それたことやってるかも、と思い出せるためにもシャンパンを抜く方法、のエピソードを憶えていたいと思った次第です。
おはようございます。
argonです。
今日は昨日、自分が参加した第8回CMS Night 3/4について書いて見ようと思います。
http://it.isogaya.co.jp/index.php?action=pages_view_main&page_id=44 より引用：
参加者はまず、いろいろなCMSのデベロッパー、エンジニア、デザイナー、関係者。
またCMSに興味を持った方。あまりウェブ関係とは関わりがない方までいろんな方が参加されています。
自分は昨日行われた回で4回目の参加なのですが、毎回新しい出会いや興味深い話があり参加していて楽しいイベントです。
今回のテーマはCMSがはじめての人へのプレゼンーションということで、NetCommons紹介やプレゼン手法について、MODxの紹介、NetCommons2でのワークフローモジュールの開発についての発表がありました。
発表の後に質疑応答の時間があり、あまりCMSを知らない方からいろいろと質問をうけていました。
やはり、はじめての方、知らない方に上手く説明、プレゼンテーションするのは難しい事だなと再認識しました。
次回の開催は4月8日の予定だそうですので、CMS関係で仕事をしている方、CMSに興味がある方は参加してみると面白いかもしれません。
こちらの写真は懇談会の様子になります。
argonです。
今日は昨日、自分が参加した第8回CMS Night 3/4について書いて見ようと思います。
http://it.isogaya.co.jp/index.php?action=pages_view_main&page_id=44 より引用：
CMS Night は、磯谷商店IT事業部(長尾正）、オープンソースワークショップ（永原篤）、株式会社Ryus （天野龍司）が企画しているレクチャー＋懇親会形式のイベントです。
参加者はまず、いろいろなCMSのデベロッパー、エンジニア、デザイナー、関係者。
またCMSに興味を持った方。あまりウェブ関係とは関わりがない方までいろんな方が参加されています。
自分は昨日行われた回で4回目の参加なのですが、毎回新しい出会いや興味深い話があり参加していて楽しいイベントです。
今回のテーマはCMSがはじめての人へのプレゼンーションということで、NetCommons紹介やプレゼン手法について、MODxの紹介、NetCommons2でのワークフローモジュールの開発についての発表がありました。
発表の後に質疑応答の時間があり、あまりCMSを知らない方からいろいろと質問をうけていました。
やはり、はじめての方、知らない方に上手く説明、プレゼンテーションするのは難しい事だなと再認識しました。
次回の開催は4月8日の予定だそうですので、CMS関係で仕事をしている方、CMSに興味がある方は参加してみると面白いかもしれません。
こちらの写真は懇談会の様子になります。
Services_Google_Calendar ( http://openpear.org/package/Services_Google_Calendar )は，
文字通り，GoogleCalendarをコントロールするライブラリです．
GoogleCalendarには，Google Calendar Data API (http://code.google.com/intl/ja/apis/calendar/)があり，
本ライブラリはこのAPIを使って，カレンダー制御を実現しています．
使い方は，パッケージのサイトを見てもらうとわかるように，インスタンスを作成し，getEventsでイベント取得．
addEventでイベント登録になっています．
イベントの参照
イベントの登録
このように非常に簡単に操作できるのですが，
この操作を行う前にしっておかなければいけない要素が3つあります．
それは，「カレンダーのid」「パスワード」「ハッシュ」です．
カレンダーのidとは文字通り，カレンダー毎に割りふられたidです．
プログラム上ではこれを引数に指定する事でカレンダーを指定します．
プライマリーカレンダー(アカウントを作った時に最初にできているカレンダー)の場合，
カレンダーのidは，gmailのメールアドレスになっています．
が，後で作ったカレンダーは，ランダムなidがついているので，参照時にこれを指定する必要があります．
カレンダーのidは，googleカレンダーにログインし，カレンダーの設定から「限定公開URL」のXMLフィードのURLで調べる事ができます．
限定公開URLは以下のような形式になっています．
この中の[ID]が，カレンダーのidになっています．
パスワードとは，そのままgmailのパスワードを示します．特に説明の必要はありませんね．
ハッシュとは，先ほどの限定公開URLにある[HASH]の部分の事です．
カレンダーidとハッシュを指定する事で，プライベートなイベントを取得する事ができます．
今まで，Google CalendarのAPIは難しそうだからとicalを出力して，それをGoogle Calendarに読ませていたのですが，
icalは表示できる量に制限があるので，これからはServices_Google_Calendarでイベント登録をしていこうと思います．
文字通り，GoogleCalendarをコントロールするライブラリです．
GoogleCalendarには，Google Calendar Data API (http://code.google.com/intl/ja/apis/calendar/)があり，
本ライブラリはこのAPIを使って，カレンダー制御を実現しています．
使い方は，パッケージのサイトを見てもらうとわかるように，インスタンスを作成し，getEventsでイベント取得．
addEventでイベント登録になっています．
イベントの参照
require_once 'Services/Google/Calendar.php';
// initialize
$gc = new Services_Google_Calendar();
// get events data
$public_data = $gc->getEvents($gmail_id);
// get events data (private mode)
$private_data = $gc->getEvents($gmail_id, $hash);
イベントの登録
require_once 'Services/Google/Calendar.php';
// initialize
$gc = new Services_Google_Calendar($gmail_id, $passwd);
// set event data
$entry['title'] = 'Event title';
$entry['content'] = 'Event description';
$entry['where'] = 'Where the event helds';
$entry['when'][0] = '2006-10-20';
$entry['when'][1] = '2006-10-24';
$entry['transparency'] = 'transparent';
$entry['visibility'] = 'private';
// add an event
$result = $gc->addEvent($entry);
このように非常に簡単に操作できるのですが，
この操作を行う前にしっておかなければいけない要素が3つあります．
それは，「カレンダーのid」「パスワード」「ハッシュ」です．
カレンダーのidとは文字通り，カレンダー毎に割りふられたidです．
プログラム上ではこれを引数に指定する事でカレンダーを指定します．
プライマリーカレンダー(アカウントを作った時に最初にできているカレンダー)の場合，
カレンダーのidは，gmailのメールアドレスになっています．
が，後で作ったカレンダーは，ランダムなidがついているので，参照時にこれを指定する必要があります．
カレンダーのidは，googleカレンダーにログインし，カレンダーの設定から「限定公開URL」のXMLフィードのURLで調べる事ができます．
限定公開URLは以下のような形式になっています．
http://www.google.com/calendar/feeds/[ID]@group.calendar.google.com/private-[HASH]/basic
この中の[ID]が，カレンダーのidになっています．
パスワードとは，そのままgmailのパスワードを示します．特に説明の必要はありませんね．
ハッシュとは，先ほどの限定公開URLにある[HASH]の部分の事です．
カレンダーidとハッシュを指定する事で，プライベートなイベントを取得する事ができます．
今まで，Google CalendarのAPIは難しそうだからとicalを出力して，それをGoogle Calendarに読ませていたのですが，
icalは表示できる量に制限があるので，これからはServices_Google_Calendarでイベント登録をしていこうと思います．
なおとです。
先週、毎日の仕事に使っているPCのハードディスクを入れ換えました。
いままで、毎分5,400回転のディスクだったのですが、プライベート含めて初の7,200回転になりました。
もっと騒々しいものを想像していたのですが、オフィスで使う分にはまったく静かであるといえます。
いままではディスクIOがボトルネックだったため、動作速度の改善も体感として、感じます。 特にシャットダウンが素晴らしく速くなりました。
ついでにメモリーも増やしました。 「ついでに」といえるほど、メモリーの価格は去年の半分程度かというほどまで下がっていて、これで増設しなければなんの苦行かと思います。 もっとも会社の経費ですが。
ディスク入れ換えに伴ってOSを更からインストールし、自動更新や各種アプリのインストールもしました。 開発環境の中心はVM Ware PlayerのなかのUbuntu Linuxなので、移行はスムーズです。
これで快適度がアップしたと喜んでいます。 そうは言っても、同僚のargonさんが使っているマシンに比べたらまだまだですけどね。
satoです。
CakePHPの1.1→1.2は、一部大きな修正があります。そのまま使おうとすると、思った通りに動作しない可能性があります。
今回は大きな変更が加えられているSecurityコンポーネントについて説明します。
Securityコンポーネントは、1.1では大きく２つの機能があります。
・CSRF対策
・POSTメソッド制限
※今回の調査に関して、CakePHP1.1の通常パッケージのダウンロード先がわからなかったため、nightlyを使用しています。
1.1では、controllerのbeforeFilter内で、
のようにすると、addアクションでのみトークンチェックが入ります。
また、$this->Security->requirePost('add');のようにすると、addはPOSTメソッドでしかアクセスできなくなります。
1.2では、機能自体が大幅に増えています。
1.1の機能の他に
・BASIC/DIGEST認証
・POST以外のメソッド制限（GET/PUT/DELETE）
・SSLチェック
といったものが増えています。
しかし、CSRF対策のコードが、1.1と1.2で別物になっています。
1.1は
・startup内で、requireAuthに現在のアクション名が入っていたら、トークンチェックを行う
というものでしたが、1.2では、
・requireAuthに現在のアクション名が含まれる場合、allowedControllersとallowedActionsをチェックする（含まれない場合は特に何もチェックしない）
・controllerにrequested==1というパラメータが入っているか、validatePost==trueでない限り、POSTリクエスト時に_validatePostでトークンのチェックを常に行う
という、不可解な挙動をします。
つまり、requireAuthに何が入っていても、Securityコンポーネントを組み込んだ時点で全ての画面にトークンチェックが入ることになります。
ドキュメントを見る限りだと、1.2でもrequireAuthを見てトークンチェックを行うような感じではあるのですが、どう解釈していいのかわからないところです。
現状としては、Securityコンポーネント自体を使わず、独自でCSRF対策を用意するのが無難だと思います。
この他にも1.2での変更点は多いので、1.2をダウンロードして1.1の解説サイトを見て困らないように注意しましょう。
CakePHPの1.1→1.2は、一部大きな修正があります。そのまま使おうとすると、思った通りに動作しない可能性があります。
今回は大きな変更が加えられているSecurityコンポーネントについて説明します。
Securityコンポーネントは、1.1では大きく２つの機能があります。
・CSRF対策
・POSTメソッド制限
※今回の調査に関して、CakePHP1.1の通常パッケージのダウンロード先がわからなかったため、nightlyを使用しています。
1.1では、controllerのbeforeFilter内で、
function beforeFilter() {
$this->Security->requireAuth('add');
}
のようにすると、addアクションでのみトークンチェックが入ります。
また、$this->Security->requirePost('add');のようにすると、addはPOSTメソッドでしかアクセスできなくなります。
1.2では、機能自体が大幅に増えています。
1.1の機能の他に
・BASIC/DIGEST認証
・POST以外のメソッド制限（GET/PUT/DELETE）
・SSLチェック
といったものが増えています。
しかし、CSRF対策のコードが、1.1と1.2で別物になっています。
1.1は
・startup内で、requireAuthに現在のアクション名が入っていたら、トークンチェックを行う
というものでしたが、1.2では、
・requireAuthに現在のアクション名が含まれる場合、allowedControllersとallowedActionsをチェックする（含まれない場合は特に何もチェックしない）
・controllerにrequested==1というパラメータが入っているか、validatePost==trueでない限り、POSTリクエスト時に_validatePostでトークンのチェックを常に行う
という、不可解な挙動をします。
つまり、requireAuthに何が入っていても、Securityコンポーネントを組み込んだ時点で全ての画面にトークンチェックが入ることになります。
ドキュメントを見る限りだと、1.2でもrequireAuthを見てトークンチェックを行うような感じではあるのですが、どう解釈していいのかわからないところです。
現状としては、Securityコンポーネント自体を使わず、独自でCSRF対策を用意するのが無難だと思います。
この他にも1.2での変更点は多いので、1.2をダウンロードして1.1の解説サイトを見て困らないように注意しましょう。
美味しい焼肉を食べて、幸せな気分のgusagiです
最近、自宅サーバの調子がおかしくなっており、真剣に新しいマシンの購入を検討していたりします。
ハードウェア構成はだいたい決まってきているのですが、自分の当初の計画では、Windows Vista Business(64bit)上にVMwareで仮想環境を構築しようと思っており、VistaがDSP版であっても2万円近くするのが悩みの種でした。
「新しいPC上に仮想環境で複数のサーバを構築したい」という要求と「急な購入なのでなるべくコストを抑えたい」という要求を満たすために、社内で相談してみました。
やはり「64bitのLinux上にVMwareを入れるのが良いんじゃないか」という意見が一番多かったのですが、satoさんからCitrix XenServerを教えて貰ったので、少しだけ調べてみました。
Citrix XenServerは、昨年の10月に発表されたXenServer5が最新で、4つのEditionが存在するのですが、その中の一つ「Express Edition」が無償で利用出来ます。
XenServer4.1までは同時稼働させることが出来る仮想ホスト数やメモリ制限があったようなのですが、5からはこの制限が撤廃され、単一の物理サーバ上に構築するのであればExpress Editionでも実用可能なようです。
更に、有償のEditionでは、複数の物理サーバ上で仮想ホストを実行することで高可用性を確立したり、仮想ホストを実行中のサーバに障害が発生した場合に別のサーバで仮想ホストを復旧させたりという機能もついているようです。
流石に、個人で手が出せる価格ではありませんが、まずはXenServerを試してみるという意味でも、Express Editionを一度試してみるのは面白そうです。
更に更に、つい先日にはEnterprise Editionを無償配布するというプレスリリース（英語）も発表したようです。
自分も、このプレスリリースについてしっかりと読み込んでいないのですが、配布開始時期などによってはこちらを導入してみたいと思っています。
最近は、ハードウェアスペックも上がってきており、仮想化が実現しやすくなっています。
興味のある方は、まずは無償版のソフトウェアを使って試してみては如何でしょうか？
最近、自宅サーバの調子がおかしくなっており、真剣に新しいマシンの購入を検討していたりします。
ハードウェア構成はだいたい決まってきているのですが、自分の当初の計画では、Windows Vista Business(64bit)上にVMwareで仮想環境を構築しようと思っており、VistaがDSP版であっても2万円近くするのが悩みの種でした。
「新しいPC上に仮想環境で複数のサーバを構築したい」という要求と「急な購入なのでなるべくコストを抑えたい」という要求を満たすために、社内で相談してみました。
やはり「64bitのLinux上にVMwareを入れるのが良いんじゃないか」という意見が一番多かったのですが、satoさんからCitrix XenServerを教えて貰ったので、少しだけ調べてみました。
Citrix XenServerは、昨年の10月に発表されたXenServer5が最新で、4つのEditionが存在するのですが、その中の一つ「Express Edition」が無償で利用出来ます。
XenServer4.1までは同時稼働させることが出来る仮想ホスト数やメモリ制限があったようなのですが、5からはこの制限が撤廃され、単一の物理サーバ上に構築するのであればExpress Editionでも実用可能なようです。
更に、有償のEditionでは、複数の物理サーバ上で仮想ホストを実行することで高可用性を確立したり、仮想ホストを実行中のサーバに障害が発生した場合に別のサーバで仮想ホストを復旧させたりという機能もついているようです。
流石に、個人で手が出せる価格ではありませんが、まずはXenServerを試してみるという意味でも、Express Editionを一度試してみるのは面白そうです。
更に更に、つい先日にはEnterprise Editionを無償配布するというプレスリリース（英語）も発表したようです。
自分も、このプレスリリースについてしっかりと読み込んでいないのですが、配布開始時期などによってはこちらを導入してみたいと思っています。
最近は、ハードウェアスペックも上がってきており、仮想化が実現しやすくなっています。
興味のある方は、まずは無償版のソフトウェアを使って試してみては如何でしょうか？
社内で使うNAS用にスタッフが無停電源を提案してくれました。
無停電電源（UPS)は高くてでかいというイメージだったのですが、今は1万円切ってわりとコンパクトな製品もあるんですね。
一般的な用途としてはファイルサーバ用あたりだと思いますが、これだけ値段が安いと、急なブレーカー落ちや雷雨時の瞬間的な停電対策として、デスクトップPCやゲーム機用に購入してもいいですよね。
ちょっとした停電などで「うおぉぉぉっこれまでの作業時間がパーだっ！」っていう事態を防ぐために、こういうちょっとした投資は積極的におこなっていきたいところです。
というわけで下記UPSを購入予定です。
無停電電源（UPS)は高くてでかいというイメージだったのですが、今は1万円切ってわりとコンパクトな製品もあるんですね。
一般的な用途としてはファイルサーバ用あたりだと思いますが、これだけ値段が安いと、急なブレーカー落ちや雷雨時の瞬間的な停電対策として、デスクトップPCやゲーム機用に購入してもいいですよね。
ちょっとした停電などで「うおぉぉぉっこれまでの作業時間がパーだっ！」っていう事態を防ぐために、こういうちょっとした投資は積極的におこなっていきたいところです。
というわけで下記UPSを購入予定です。
最近からだが弱ってるせいか、毎日持ち歩いているノートパソコンのせいで右側の腰痛が半端ないことになってきました。
せめて背中に背負えれば、でも大人の女性がもちあるいて普通に見えるショルダーないなぁ、電車に乗ったときとかは肩掛けになるといいんだけどな、と。一昨日の昼休みにそんなことを思いながら楽天を見ていて見つけたんです！理想のカバンを。
http://item.rakuten.co.jp/heessac/hl-85289/
早速愛用のThiknPadを入れたところちょうどよく、リュックからショルダーへも紐をしゅるしゅるっとするだけで変身します。これで混み合った車内でもすぐに持ち帰られます。実際に背中にしょったところ、今までの重さが嘘みたいに軽く感じました♪
てことで、軽くてシンプルなリュック&ショルダーバッグをお探しの方に是非お勧めします♪
