PukiWikiからGoogle Apps版Googleサイトにデータを移行する一番てっとり早い方法は何ですかね・・・。
「Googleサイト側にAPI無いんだからコピペするしか無いか」
などと考えていたんですが、予想以上に移行予定のPukiwikiのページ数が多かった・・・。
komagataの悲しみが鬼なった。
OpenID for Google Apps – Account Authentication API - Google CodeNote: OpenID authentication is currently only supported for Google accounts, not Google Apps (hosted) accounts.
「ITベンチャー勝ち組セット」などとほざいてましたが、まさにGoogle Appsマンセー状態でGmail、Googleカレンダー、Googleサイトなどに依存しまくってます。（WikiはRedmineのよりGoogleサイトの方がよさそうです。）
なんかちょっと社内アプリ作るなら面倒なのでGoogle Appsのアカウントを使いたいなあと思ったんですが、普通のGoogleアカウントだけでGoogle AppsアカウントはOpenID対応してないんですね。がっかり・・・。
Google Appsアカウントにまとめると何が便利って、入社・退職の処理が簡単になるからです。なるべく自動化したいなあ。
日本ではありとあらゆるものに神様が宿るという考えがあります。
でも最新の神様はあんまり皆さんご存じ無いんじゃないでしょうか？ 丁度良い機会なのでいくつかご紹介したいと思います。
最新の八百万の神（信仰を集めてる順）
- printfの神
- Visual SourceSafeの神
- Mach-Oの神
- find . -name \* -exec rm {} \;の「{}」の部分の神
- mail.force_extra_parametersの神
最後のは邪神です。怖い。
年末やったSSLの証明書が先月末切れた！？
設定ミス？
もはやこれまで！
さあopenssl genrsa … と刺青を彫ろうか、と思ったが、お金の支払いの問題で切れただけだった。（支払いは俺がやってないので）
よかった。銭湯行けなくなるとこだったよ・・・。
ユーザがサーバ障害・不具合を認識 │ ├───┐ │ ユーザがユーザ掲示板に書き込み │ ↓ │ xrea 側からの反応一切無し │ │ ├───┐ │ ユーザが value-domain のお問い合わせフォームから問い合わせ │ ↓ │ サポート受付担当者からテンプレートな返事にて │ 担当部門が緊急対応をしており、 │ 受付担当者は受付が担当の為、詳細の状況は何も返答できず、 │ ユーザ掲示板にを活用しつつ待つようにと返答 │ ↓ │ ユーザがユーザ掲示板に書き込み │ ↓ │ xrea 側からの反応一切無し │ │ ├───┐ │ ユーザが digirock のコンタクトフォームからお問い合わせ │ ↓ │ digirock 側からの反応一切無し │ │ └───┐ ユーザが digirock の代表電話番号へ電話 ↓ 留守番電話に切り替わり、人が電話に出ず
XREA&CORE SUPPORT BOARD - View Single Post – FTP障害・メール障害の原因は逆引きDNSの不具合？以上のことから、サポート受付担当は、障害・不具合を認識しているが、 サーバ管理担当者やネットワーク管理担当者が、何をしているのか、 ユーザには、何も報告されず、何も分からない状況。 ユーザは、不具合の状態のまま、ただ待つのみ。 xrea に見切りを付けたユーザは、xrea 以外のレンタルサーバに移動を始めている模様。
サポート受付担当者は担当部門が緊急対応を 行っていると言うが、不具合があまりも長時間にわたるため、 サーバ管理担当者やネットワーク管理担当者が、実際何をしているのか全く分からない。
XREAが5日ぐらい障害中。（エクスリアって読むらしいですよ！）
技術的な問題だけでなく、サポート体制や組織内の意思疎通も正常な状態ではないように思えます。
個人向けサービスと考えて、仕事では同じレンジの用途では別のサーバーを探そうと思いました。
id:dandasoに「3日ワイアードに凸る」というメッセを受けて行って来ました。id:perezvonと合流してワイアードさんに。広くて綺麗なオフィス。そのあと3人プラスid:p4lifeさんで飲み行きました。
そこの場で出た、
「スピリチュアルプログラミング・スピリチュアル系プログラマー」
という概念をまとめておきたいと思いました。
スピリチュアルプログラミングとは
オカルトによってコードの持つ本来の力を高める方法論である。追い詰められたプログラマーならば誰しも感じたことのある「小人」や「妖精」の存在もコードに宿る八百万の神の一部である。
コード力が高まる行為
- 祈る もっとも基本的な行為。一心不乱に祈ることでバグ発生率を抑える。 （ぬるぽの神、セグフォの神、OOM Killerの神などに祈る）
- 強い信念 バグは作っていない。というか今までバグを書いたことが無いというぐらいの気骨が重要です。
- 徹夜する 徹夜をすると絶対動くんだ。むしろ動かないと俺が死ぬ！という強い思いがコードに注入されます。一行入魂。
コード力が低下する行為
- ブランチを切る ブランチを切ることでコードに集まるパワー（バグ出るなという想い）が分散してしまいます。
- テストをする テストは唯一無二のコードの動作に対する疑いにつながります。絶対に動くという強い意思を持ちましょう。
- コードをジェネレートする コードをコンピューターごときに書かせてはいけません。手書きにこそ強い念が篭るのです。
スピリチュアルプログラミングはポッと出のTDD/BDDなどに比べて数千年の歴史があります。
みなさんも、スピリチュアルプログラミングにチャレンジしてみるか、もしくは反面教師としてはいかがでしょうか。
「パソコンが動かない」という留守電を受けて実家へ行ってきました。
実家のパソコンはVAIO type-N N51B。フツーのVistaのノートです。確か１０万ぐらいでした。
 |
|
電源入れてみると、「ログインマネージャーが立ち上がりません」的なメッセージと、C++ランタイムライブラリのエラーでエクスプローラーが立ち上がらない。セーフモードも同じ。
Linuxで言ったら、GDMエラーとGTK+のエラーみたいな状態？ログはどこに書かれてるんだろうとか思いましたが、深追いせず、UbuntuのCDで立ち上げてデータを救った後、リカバリしました。
最近のパソコンにはWindowsPEとかいう組み込みWindowsがリカバリで起動するらしくて、えらい楽でした。
ただ、ハマッたりはなかったんですが、リカバリとWindows Updateは単純に10時間ぐらいかかりました・・・。
それと、両親にはHotmailを規定のメールソフトとして使ってもらってたんですが、勝手にアップデートされた（そう操作したんだろうけど）のでメールが使えなくなった。と言っていた。
Outlook Express、Windows Mail、Windows Live Mail、Windows Live Hotmailと似たようなソフト／名称がありまくって混乱。
実装も、Windowsネイティブ、ASP.NETベース？、SilverLightベース？と良くわからん状態。
正確に言うと、Windows Live Hotmailを「規定のメールクライアント」にしたい（UIが変わると親が混乱するので）のだが、出来ない。
Windowsネイティブの「Windows Mail」か、Webアプリをローカル化した「Windows Live Mail」のどっちかを使えということらしい。
Windows Live hotmailのURLショートカットをデスクトップに置いて使ってもらうことにした。
また、データ紛失が怖いというのでDropboxを設定してきた。バックアップや同期の概念は分かりづらいと思うので、今度また説明する必要があるなと思った。
オープンソースソフトの作者の方、ニコニコ動画などでの動画の作者の方、オモシロテキストを書いてくれる方。
月にこのぐらい儲かればバージョンアップができる、月にこのぐらい儲かれば動画を週１でアップできる、月にこのぐらい儲かれば毎日更新できる。
Paypalなどを使って、寄付というより、複数人の利用者 対 作者で、金額 対 成果物の基準のテンプレみたいのを作って、両方が幸せになれる仕組みはできないものかと・・・。
主に、ニッチなソフトや動画作成者の方は社会人になると同時にほぼその活動から引退されます。（生活のために当たり前です）
それが私は嫌なのです。少々の金を払ってもあなた方のニッチに暴走した作品が使いたいのです。見たいのです。
# ディシディアファイナルファンタジーを買いました。6000円ぐらいでした。埃被ったPSPに入れて電源を入れると、ファームウェアのバージョンアップをしないとプレイできない旨のメッセージ。バージョンアップしようとするとバッテリーが足りない旨のメッセージ。辞めました。
# kawaduと飲みました。7000円ぐらいでした。楽しかった。
# 注文してたノート（Thinkpad x61）用のメモリ（2GB）が届きました。2000円ぐらいでした。OSが4GBを認識できないそうで、意味ありませんでした。
# 6000円ぐらいで買ったUSBバーコードリーダーを試しました。本のバーコードを読んでみると、「ISBNの数字とリターンキー」を入力したのと同じことになりました。これは色々使えそうです。
# ニコニコ動画を見ました。月額525円のプレミアム会員料金を払っています。板東英二の動画で笑いで涙が出ました。またRULE of ROSEのゲーム実況動画を見始めました。とても先が楽しみです。
 |
|
 |
|
 |
|
ここのところ、金銭感覚というか、お金に関する基準があやふやで、自分自身の買い物に対する評価が出来ません。
商品にかけられた手間、商品からうける影響、自分の満足度、消費される時間、など色々な要素があると思うんですが、それらに関するモデルが自分の中に無い感じです。
みなさんは上記の買い物に関して「良い」「悪い」で言ったらそれぞれどう思われるでしょうか。
判断基準なども教えていただけると参考になります・・・。
この前書いたこの問題。
長いので以下ステージング環境認証問題と言うことにします。
（ステージング環境についてはこちら）
元エントリーにもコメントをいただき、大変参考になりました。僕の場合、３日考えて良い解決法が見つからない時は大抵１ヶ月かかっても見つからないのでブログに書いたり人に助けを求めたりします。（サーセン・・・）
今回もそれを実行したところid:dandasoにナイスアイデアを頂きました。（Thanks!）
皆様方におかれましては、
「そんなに悩むところか？」
感が否めないかもしれませんが、僕と同じく悩んだ方がいて、参考になったりすれば幸いです。
ステージング環境認証問題対応方法
一言で言うと、「クッキーの値で認証する」ということです。
fooというアプリがあるとして、まず、下記のようなBASIC認証をがかかった認証用クッキーを設定するプログラムを見えないとこに置きます。（PHPが便利でした）
<?php
$user = 'foo';
$pass = 'bar';
$realm = 'foo';
if ($_SERVER['PHP_AUTH_USER'] === $user and $_SERVER['PHP_AUTH_PW'] === $pass):
setcookie($realm, sha1($pass));
header('Location: /');
else:
header("WWW-Authenticate: Basic realm=\"{$realm}\"");
header("HTTP/1.0 401 Unauthorized");
?>
<html>
<head>
<title>Authentication</title>
</head>
<body>
<h1>Authentication</h1>
<p>正しいユーザー名とパスワードを入力してください。</p>
</body>
</html>
<?php endif ?>本来、問題になっているアプリ「foo」に上記のアプリのAliasを張ります。（上記をfooのリポジトリに入れたくないので）
<VirtualHost *:80>
ServerName foo
Alias /auth /path_to/auth.php
...(snip)...
</VirtualHost>fooのアプリのApplicationControllerでlogin_required（本来のBASIC認証）より先にcookieを見て認証します。（認証失敗したらさっきのPHPにリダイレクトする）
require 'digest/sha1'
class ApplicationController < ActionController::Base
...(snip)...
before_filter :cookie_auth_required if $STAGING
def cookie_auth_required
redirect_to "/auth" unless cookies["foo"] == Digest::SHA1.hexdigest("bar")
end
endステージング環境でのみこの認証を追加したいので、capの設定ファイルにステージング環境用フラグを追加するタスクを書きます。（フラグの書き方、もっとキモくない方法しりたいです・・・）
config/deploy/staging.rb:
namespace :deploy do
desc 'Added staging flag in production.rb'
task :before_restart do
run "echo '$STAGING = true' >> #{current_path}/config/environments/production.rb"
end
endこれで http://foo/auth というURLと foo / bar というID/PASSをお客さんに教えることでステージング環境を認証有りで確認してもらうことができました。
お客さんの手間と本来のアプリのリポジトリの影響を最小限にしたいがためにこんな形になりました。
ブラウザを閉じるまでの間、cookie内にパスワード（のハッシュ）があるので大事な認証に使うのは辞めた方がいいと思います。利便性とのトレードオフで今回の自分ような、見られても致命的な影響が無いものならいいかなと思いました。
Apacheの設定とかでcookieの値を見てはじければ、fooから認証コードが取れてもっとよさげです。そういうモジュールとか無いのかな？引き続き模索してみます。
参照