昨日は結婚記念日だった。
嫁と上野動物園に行った。
パンダを見た。
大きな動物は迫力があったし
小さな鳥、は虫類、両生類もとにかく沢山の生き物がいて、
みんなしっかり生きてるなぁと妙な感心をした。
ところで、上野の森は木漏れ日が差し込みとても涼しく心地よかった。
こんなところで仕事が出来ればいいのにと思った。
そしてビルを建て、オフィスで仕事をするという今のやり方にとても疑問をもった。
ビルを建て閉じこもって冷房を効かせて、わざわざエネルギーを消費しようとすることに疑問を持った。
生活のレベルに関して言えば、昭和40年代と今の時代はそう変わる所は無い。
昔はクーラーなんて無かった。
クーラーが付いた時代もあったが、クーラーを付けると頭が痛くなったのですぐに止めた。
我々はもっと無駄なエネルギー消費を抑える事が出来るはずだ。
2011年6月23日木曜日
2011年6月21日火曜日
mongocco
mongoccoは昔自分がやってたアバターチャットシステムだ。
ちょっと記憶が定かでない部分があるけど説明してみる。
世界はオープンワールドとクローズドワールドがあって、孤島で成り立っている。
オープンワールドはインターネット越しにみなさんとチャットができる。
クローズドワールドは、自分の家のルータ内のアドレスでログインできるけど、インターネット越しには接続出来ない。
IDを持った人は、島一覧から好きな島を選んで起動する。
すると、その人がサーバ役になって、他の人が島に降り立つ事が出来るようになる。
サーバ役の人がいなくなると、別の人にサーバ役が引き継がれる。
サーバ役になれるのはIDを持ってる人でポートを開けたり設定しとかないといけない。
IDが無くてもGUESTで参加することが出来る。
GUESTはサーバにはなれないし、アイテムも持ち帰れなかったんじゃないかな・・・たしか・・・
島にはいろんなものが流れ着き、木には実がなる。
アイテムショップではどんぐりでいろいろな物を買える。
買ったものは島に配置することができる。
色々な色がついたキューブを並べたり積み上げたりして、
ドットアートのようなことをすることもできる。
島一覧には害虫の発生する島があって、そこで害虫を倒してどんぐりを稼ぐ。
アイテムショップはどんぐりで購入できる。
とまぁ、大体こういうシステムなんだけど、革新的だったのはサーバが必要なかったってことだ。
アイデア次第で、このシステムはもっと応用が出来ると思う。
すでにサービスは停止していて、ダウンロードも出来ないが、
ファンは結構残ってると思う。
ちょっと記憶が定かでない部分があるけど説明してみる。
世界はオープンワールドとクローズドワールドがあって、孤島で成り立っている。
オープンワールドはインターネット越しにみなさんとチャットができる。
クローズドワールドは、自分の家のルータ内のアドレスでログインできるけど、インターネット越しには接続出来ない。
IDを持った人は、島一覧から好きな島を選んで起動する。
すると、その人がサーバ役になって、他の人が島に降り立つ事が出来るようになる。
サーバ役の人がいなくなると、別の人にサーバ役が引き継がれる。
サーバ役になれるのはIDを持ってる人でポートを開けたり設定しとかないといけない。
IDが無くてもGUESTで参加することが出来る。
GUESTはサーバにはなれないし、アイテムも持ち帰れなかったんじゃないかな・・・たしか・・・
島にはいろんなものが流れ着き、木には実がなる。
アイテムショップではどんぐりでいろいろな物を買える。
買ったものは島に配置することができる。
色々な色がついたキューブを並べたり積み上げたりして、
ドットアートのようなことをすることもできる。
島一覧には害虫の発生する島があって、そこで害虫を倒してどんぐりを稼ぐ。
アイテムショップはどんぐりで購入できる。
とまぁ、大体こういうシステムなんだけど、革新的だったのはサーバが必要なかったってことだ。
アイデア次第で、このシステムはもっと応用が出来ると思う。
すでにサービスは停止していて、ダウンロードも出来ないが、
ファンは結構残ってると思う。
2011年6月18日土曜日
mantisについて
使う側の立場での使い方を書いておこうと思う。
設定する側の立場での使い方は以後書く予定
自分の書き方なんでかなり大雑把である。
1.基本は検索
検索を押しておけば、なにが残っているのか一目瞭然
メインなんか押してもまったく何の情報も出てこない
新規登録をする前にまずは「検索」をして、
他に似たような登録がないのかきちんと確認することが重要
2.登録
気をつけないといけないのは
(1)わかりやすいタイトル
(2)わかりやすい説明
(3)必要なときは再現手順
ステップ毎に番号をつけて、誰でも再現できるように記述する
3.ステータス変更→フィードバック
「フィードバック」はどのステータスからも戻り得るステータス
例を挙げると
(1)説明がわからない登録がされた場合
もっとわかりやすく書いて!と開発者から登録者にフィードバックを求める
(2)解決済みからフィードバック
本来QAが完了にするフェーズだが、
解決してないんじゃない?となると
開発者にフィードバックして治ってないよと知らせる。
担当者はその都度設定できるので、
誰が現状ステータスの担当なのかしっかり設定するのが重要
4.ステータス変更→内容確認
開発者が変更する事が殆ど
時間が無い時は、解決まで出来ないので、
とりあえず開いて内容確認しましたというフローにまでもっていく
QAに開発者が仕事してないから新規たまりまくってます!
とか言われるのは避けたいw
5.ステータス変更→再現済、担当者決定、解決済み
上記3、4もそうなんだけど、
ステータス変更するのは一体誰かというのが問題になる。
結論から言うと誰でもやるべき
完了以外はとりあえず開いて読むべき
そして、誰が担当なのがふさわしいのか考えて、担当者はきちんと設定する。
本当にバグなのか、問題なのか、仕様じゃないのかなんてことは、
プロジェクトにかかわる全員が把握するべき事なので、
誰もがステータスをどんどん前にすすめるベきなのは間違いない
6.ステータス変更→解決済み
これやるのは間違いなく担当者となった開発者
7.ステータス変更→完了
これやるのは間違いなくQA
完了にする権利は開発者には無い!
(QA居ない場合はしかたないけど)
ようするに6で解決済みになったからと言って終わりじゃないのだ。
最終的に完了と判断するのはQAであって、
QAが納得しなかったら完了になんかならない。
逆に解決済みから開発者にフィードバックされてしまうかもしれない
ステータスは上記のように順番ではなく、
新規からいきなり解決済みになることもある。
「新規」から「完了」になるパターンは、
よっぽどうっかり登録した間違いパターンだと思う
設定する側の立場での使い方は以後書く予定
自分の書き方なんでかなり大雑把である。
1.基本は検索
検索を押しておけば、なにが残っているのか一目瞭然
メインなんか押してもまったく何の情報も出てこない
新規登録をする前にまずは「検索」をして、
他に似たような登録がないのかきちんと確認することが重要
2.登録
気をつけないといけないのは
(1)わかりやすいタイトル
(2)わかりやすい説明
(3)必要なときは再現手順
ステップ毎に番号をつけて、誰でも再現できるように記述する
3.ステータス変更→フィードバック
「フィードバック」はどのステータスからも戻り得るステータス
例を挙げると
(1)説明がわからない登録がされた場合
もっとわかりやすく書いて!と開発者から登録者にフィードバックを求める
(2)解決済みからフィードバック
本来QAが完了にするフェーズだが、
解決してないんじゃない?となると
開発者にフィードバックして治ってないよと知らせる。
担当者はその都度設定できるので、
誰が現状ステータスの担当なのかしっかり設定するのが重要
4.ステータス変更→内容確認
開発者が変更する事が殆ど
時間が無い時は、解決まで出来ないので、
とりあえず開いて内容確認しましたというフローにまでもっていく
QAに開発者が仕事してないから新規たまりまくってます!
とか言われるのは避けたいw
5.ステータス変更→再現済、担当者決定、解決済み
上記3、4もそうなんだけど、
ステータス変更するのは一体誰かというのが問題になる。
結論から言うと誰でもやるべき
完了以外はとりあえず開いて読むべき
そして、誰が担当なのがふさわしいのか考えて、担当者はきちんと設定する。
本当にバグなのか、問題なのか、仕様じゃないのかなんてことは、
プロジェクトにかかわる全員が把握するべき事なので、
誰もがステータスをどんどん前にすすめるベきなのは間違いない
6.ステータス変更→解決済み
これやるのは間違いなく担当者となった開発者
7.ステータス変更→完了
これやるのは間違いなくQA
完了にする権利は開発者には無い!
(QA居ない場合はしかたないけど)
ようするに6で解決済みになったからと言って終わりじゃないのだ。
最終的に完了と判断するのはQAであって、
QAが納得しなかったら完了になんかならない。
逆に解決済みから開発者にフィードバックされてしまうかもしれない
ステータスは上記のように順番ではなく、
新規からいきなり解決済みになることもある。
「新規」から「完了」になるパターンは、
よっぽどうっかり登録した間違いパターンだと思う
mantisbt + dokuwiki on ドメインキングのレンサバ
現在日本ではwikiと言えばpukiwikiだと言える。
しかしその開発はすでにほぼ停止状態。
pukiwiki plus も出ているが、それで作られたサイトを見ると、
どうもwikiっぽいデザインから抜け出す事が出来ない。
会社のプロジェクト用にドメインキングのレンサバにmantisを設置した。
mantisとの連携ではdokuwikiを採用するのがベストである。
他のwikiとの連携も出来るのだが、
文字エンコーディングの問題があって行き着く先はmantisbt+dokuwikiであった。
使い勝手はpukiwikiの方が慣れていたのだが、dokuwikiでもそう難しくはない。
良いのはメンバーごとのアクセス制限が手軽に出来る事
これでレンタルサーバ上に置いてあったとしてもメンバー制限が出来るので内容が漏れることは無い。
セキュリティ上どうなのかは正直よくわからないが、
当面コレで運用していこうと思う。
しかしその開発はすでにほぼ停止状態。
pukiwiki plus も出ているが、それで作られたサイトを見ると、
どうもwikiっぽいデザインから抜け出す事が出来ない。
会社のプロジェクト用にドメインキングのレンサバにmantisを設置した。
mantisとの連携ではdokuwikiを採用するのがベストである。
他のwikiとの連携も出来るのだが、
文字エンコーディングの問題があって行き着く先はmantisbt+dokuwikiであった。
使い勝手はpukiwikiの方が慣れていたのだが、dokuwikiでもそう難しくはない。
良いのはメンバーごとのアクセス制限が手軽に出来る事
これでレンタルサーバ上に置いてあったとしてもメンバー制限が出来るので内容が漏れることは無い。
セキュリティ上どうなのかは正直よくわからないが、
当面コレで運用していこうと思う。
ARIAのアテナさん
川上とも子さんお亡くなりになったんですね、
ARIAのアテナ役の唄パート河井英里さんもお亡くなりになって、
声優パートの川上とも子さんもお亡くなりになってしまった
もしARIAの続編をつくるとしたらアテナさん役、
まるっきり変えないといけなくなってしまったけど、
あの雰囲気出せる声優さんているんだろうか・・・
それとももうARIAは作らないかなぁ・・・
いい感じで完結してるもんなぁ・・・
ARIAのアテナ役の唄パート河井英里さんもお亡くなりになって、
声優パートの川上とも子さんもお亡くなりになってしまった
もしARIAの続編をつくるとしたらアテナさん役、
まるっきり変えないといけなくなってしまったけど、
あの雰囲気出せる声優さんているんだろうか・・・
それとももうARIAは作らないかなぁ・・・
いい感じで完結してるもんなぁ・・・
2011年6月17日金曜日
iPad2からfonへ接続
iPadからFON_FREE_INTERNET へ接続する場合、
これが正しいかどうかわからないけど、
自分が遭遇した状況は、
FON_FREE_INTERNETヘ接続し、ログイン画面が表示され、
おめでとうございますというメッセージまで表示されているのに、
Wi-Fiマークが表示されなかった。
(当然?)Safariからはどこにも繋がらない
そこで調べてみたら以下のようにしろという記述を発見
設定→Safari→自動入力→オフ
しかしこれでも繋がらなかった。(というより最初からオフだった)
そこで試しに以下を試みた
設定→Wi-Fi→接続を確認→オン
これでWi-Fiが表示され、接続出来るようになった。
どういう事なんでしょう・・・
ちなみにMacBookから接続では、普通に接続して使えることも確認済み
iPadだけ挙動がおかしい。
これが正しいかどうかわからないけど、
自分が遭遇した状況は、
FON_FREE_INTERNETヘ接続し、ログイン画面が表示され、
おめでとうございますというメッセージまで表示されているのに、
Wi-Fiマークが表示されなかった。
(当然?)Safariからはどこにも繋がらない
そこで調べてみたら以下のようにしろという記述を発見
設定→Safari→自動入力→オフ
しかしこれでも繋がらなかった。(というより最初からオフだった)
そこで試しに以下を試みた
設定→Wi-Fi→接続を確認→オン
これでWi-Fiが表示され、接続出来るようになった。
どういう事なんでしょう・・・
ちなみにMacBookから接続では、普通に接続して使えることも確認済み
iPadだけ挙動がおかしい。
Joomla の使い方がなんとなく分かって来た
Joomlaはなんでもかんでも分けるようだ。
記事でもニュースフィードでもメニューでも「セクション」「カテゴリ」をきちんと設定してからでないと駄目なのだ。
最初その辺りがよくわからなかったが、そういうJoomlaのこだわりが分かればそれに従って考えればいい。
静的コンテンツの場合は分類を未分類にしておけばいいらしい。
記事でもニュースフィードでもメニューでも「セクション」「カテゴリ」をきちんと設定してからでないと駄目なのだ。
最初その辺りがよくわからなかったが、そういうJoomlaのこだわりが分かればそれに従って考えればいい。
静的コンテンツの場合は分類を未分類にしておけばいいらしい。
2011年6月15日水曜日
CALayer で move とか pinch 操作と拡大縮小処理の自前実装
コードの実例を減らして言葉で解説します。
まずtouchesなんたらについて
touchesBeganで現在何本の指がタッチされているのかは取得出来ません。
取得出来るのはtouchesMovedだけです。
取得の仕方は以下
どのくらい動いたのかは以下のようにすると取れる
CALayerの位置をdivx,divy分だけ移動すれば指で移動が出来る。
ピンチ処理をしたい場合は、
1.PrevTouchPointとnowTouchPointの比から、
拡大縮小率を計算し、それに合わせてCALayerのframeを変更する
2.PrevTouchPointから中間点を計算し、
その座標をCALayer座標系に変換してからCALayerのanchorに設定する
3.2の中間点(画面上の座標)へCALayer を setPosition する。
このとき、画面の上下左右に入るように
CALayerのsetPosition 位置を修正する必要がある。
という事をやると、指でタッチした位置の中間点を中心にして拡大縮小が出来る。
もちろんスクロールとかにCALayerを乗せれば自前なんてやる必要ないんだけど、
どうしても自前実装しなければならない時にご参考ください。
まずtouchesなんたらについて
touchesBeganで現在何本の指がタッチされているのかは取得出来ません。
取得出来るのはtouchesMovedだけです。
取得の仕方は以下
int i=0;
int divx,divy;
CGPoint nowTouchPoint[20], PrevTouchPoint[20];
for(UITouch *touch in [event allTouches])
{
PrevTouchPoint[i] = [touch previousLocationInView:self];
nowTouchPoint[i] = [touch locationInView:self];
i++;
}
どのくらい動いたのかは以下のようにすると取れる
divx = (nowTouchPoint[0].x - PrevTouchPoint[0].x);
divy = (nowTouchPoint[0].y - PrevTouchPoint[0].y);
CALayerの位置をdivx,divy分だけ移動すれば指で移動が出来る。
ピンチ処理をしたい場合は、
1.PrevTouchPointとnowTouchPointの比から、
拡大縮小率を計算し、それに合わせてCALayerのframeを変更する
2.PrevTouchPointから中間点を計算し、
その座標をCALayer座標系に変換してからCALayerのanchorに設定する
3.2の中間点(画面上の座標)へCALayer を setPosition する。
このとき、画面の上下左右に入るように
CALayerのsetPosition 位置を修正する必要がある。
という事をやると、指でタッチした位置の中間点を中心にして拡大縮小が出来る。
もちろんスクロールとかにCALayerを乗せれば自前なんてやる必要ないんだけど、
どうしても自前実装しなければならない時にご参考ください。
2011年6月12日日曜日
Joomla を入れた
会社用のWEBサイト構築のためにXoopsを使っていたが、なんだかでかい割には何をするにもモジュールが必要なので、いっそのことWikiにしてやろうかと思ったが、WikiだとWikiくさいから嫌だなぁと思っていたら、Joomlaというのを見つけた。これめちゃめちゃいいわ。
2011年6月8日水曜日
CALayerでアニメ+終了時のコール
//トランザクション開始
[CATransaction begin];
//csrPRE_MENUのフレーム位置をPRE_Buttons[i]のフレーム位置に変更する
csrPRE_MENU.frame = PRE_Buttons[i].frame;
// 終了時にClosePreMenuを呼ぶ
[CATransaction setValue:^{ [self ClosePreMenu];} forKey:kCATransactionCompletionBlock];
// ピカピカエフェクト
CABasicAnimation *pikapikaAnime = [CABasicAnimation animationWithKeyPath:@"opacity"];
pikapikaAnime.duration = 0.1;
pikapikaAnime.fromValue = [NSNumber numberWithFloat:1];
pikapikaAnime.toValue = [NSNumber numberWithFloat:0];
pikapikaAnime.removedOnCompletion = NO;
pikapikaAnime.fillMode = kCAFillModeForwards;
pikapikaAnime.repeatCount = 10;
[csrPRE_MENU addAnimation:pikapikaAnime forKey:@"pikapika"];
// トランザクション終了
[CATransaction commit];
と、ここまでやると、フレームの位置が変わって、透明度がちかちかして、その後ClosePreMenuという関数が呼ばれる。
2011年6月7日火曜日
CALayerのプロパティ
//Buttons[i]というレイヤーからbtnActionキーに紐づいた値(文字列)を取得
NSString* btnAction = [[Buttons[i] valueForKey:@"btnAction"] autorelease];
独自のプロパティが作れるというのは何やらJavaScriptのような感じでとても使いやすい
。こういうのはKVCという物であるらしい。
上の例は組みかけだが、ボタンに見せたレイヤを50個ほど作成して、
その当たり判定をした時にbtnAction で内部の関数を読んだりしようかなと思って作って
いる。
アクションによってラジオボタンとかボタンの透明度変えて表示したりしなかったりなど
を制御するつもり
ところで、NSString の扱いってよくわからないのだけど、上のように autorelease しと
かないと駄目なんだろうか?
教えて偉い人w
一応以下のような形でも動く事はわかった
if([[Buttons[j] valueForKey:@"btnAction"] isEqualToString:@"V_DIV2"]){
// ここにいろいろ処理
}
NSString* btnAction = [[Buttons[i] valueForKey:@"btnAction"] autorelease];
独自のプロパティが作れるというのは何やらJavaScriptのような感じでとても使いやすい
。こういうのはKVCという物であるらしい。
上の例は組みかけだが、ボタンに見せたレイヤを50個ほど作成して、
その当たり判定をした時にbtnAction で内部の関数を読んだりしようかなと思って作って
いる。
アクションによってラジオボタンとかボタンの透明度変えて表示したりしなかったりなど
を制御するつもり
ところで、NSString の扱いってよくわからないのだけど、上のように autorelease しと
かないと駄目なんだろうか?
教えて偉い人w
一応以下のような形でも動く事はわかった
if([[Buttons[j] valueForKey:@"btnAction"] isEqualToString:@"V_DIV2"]){
// ここにいろいろ処理
}
登録:
投稿 (Atom)
-
https://social.msdn.microsoft.com/Forums/vstudio/en-US/f0502813-9c4f-4b45-bab8-91f98971e407/popup-popupstaysopen-togglebutton-and-data-bindi...
-
どうも書かなくてはならないネタが出来てしまった。 マルチスレッドには欠かせないSleep(0)についてだ。 自分はSleep(0)を多用していた。 MSDNの記述 によると 「中断時間として 0ms を指定してこの関数を呼び出すと、現在のスレッドは自らに割り当てられている...