<< Prev Page Next Page >>

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。


ドラゴンボールの一輪車

HONDAのあの一輪車、横とかに走れてすごい不思議だったんだけど、こうなってたのか!なるほど!


■1輪で前後左右斜めに移動 シートとステップを畳んだ状態ではエレキギターあたりを思わせるU3-Xの最大の特徴は、車輪が1個しかないこと。HOTドライブシステムと名づけられたこのホイールは全方位駆動車輪機構と呼ばれ、前後・左右・斜めと自在に走ることができる

ホンダ U3-X フォトインプレッション 【 carview 】
萌えるねー。萌え萌え。


現状を変える意志

イケてない現状を変えるには。

とりあえず「なんだこのダメな状態は!」って叫んでみる。

叫んだ時点で周りから自分自身への信頼度がある閾値を超えているなら、「どうしたらいい?」と頼られ、権限が委譲される。そっから実際にイケてる状態までもっていくにはまたたくさんの血と汗と涙が混じり合って池となり結晶したり空と~ぉ~君と~の~あ~いだ~にはぁ~(間違い)

で、それはまだ楽な話。

「なんだこのダメな状態は!」って叫んだ時「うるせーこのダメ人間」と罵られたり「そうだねーでもどうしようもないんだよねー」とテンション低ーかったりするのはまだ信頼度のパラメータが足りなくてフラグが立っていない状態。

ここで叫び続けるのは下策。

叫び続けたところで、ウザがられて、「んなに言うならやってみなよ」とめんどくさそうな顔で言われて、「まかせとけ!」かなんか言っちゃって、頑張ってみたものの、悪い現状に陥るにはそれなりのみんなの積み重ねってものがあるんであって、それを一人で覆すのは、天才君なら出来るけど凡才君の多少のがんばり程度ではどうしようもなくて。

自分が天才君だと勘違いしてしまってるのが最大の間違いなんだけど、
「俺がこんなに頑張ってるのに周りがついてこない」
とmixiに書き込んでマイミクのひとたちに「うんわかるー」とか言われて、

やーい負け犬ー。(あっ言っちゃった)

やっぱり多大なエネルギー量を必要とすることを凡才君がやろうとするには、
・自分が凡才だと認める
・時間をかけてエネルギーをためて一気にドカン
・周りの人の元気もオラに分けてもらう
そういうことが必要なんだと思う。

このうち、自分が凡才だと認めるのが難しいって人は、まあ頑張って強く生きてもらうとして、時間をかけてエネルギーをためるのは結構難しい。

たいていの場合、自分にも仕事とかあるわけで、現状を変えるための準備どころか、イケてない現状に巻き込まれてよけいに疲れちゃったりして難しいけど、そこは何とか知恵を使う。上手いこと言い訳して内職するとか、体調不良で休んどいて家で準備するとか。大事なことのために、大事じゃないことは犠牲にして爪を研ぐんだ。

そして、チャンスを待つ。イケてない現状のせいでみんなが痛い目に遭うのを待つ。みんなが「くそーこんなダメな現状だからつらくてしょうがない!」って思うのを待つ。

そして、かねてからの準備を解き放つ。解き放ち方も気を遣う。みんなに元気を分けてもらわないと一人じゃムリだから!
「くそーこんなダメな現状だからつらくてしょうがない!」
「はーっはっはっはっ、こんなこともあろうかと、俺様が現状を根こそぎ改革するために準備しておいたのだ!」
「…さぼってやがったのかこの屑が」
こうじゃなくて。

「くそーこんなダメな現状だからつらくてしょうがない!」
「ほんとだよね!…もしかして、こうやれば良くならないか?」
「そらそうかも知れないけど余力がない…」
「俺ちょっと頑張ってみる!みんなのために!」
(2日後)(しれっと)「試しに途中までやってみた。」
「おお、これは!…もしかして、イケるかも!?すげえ!たったの2日で!」
「でもここからはみんなの協力が必要だ!みんな!オラに元気をわけてくれ!」
こんな感じで。ちょっと天才君のふりができるけど勘違いはしない。

で、ようやっと血と汗と涙やらよだれやら糞尿やらが混じり合って風の中のす~ばる~砂の中のぎ~んが~というアツい物語が始まる。

一度実績ができると次回からみんながもっと協力的になってくれるかも。そこでもっと酷いことになったらもう誰も話し聞いてくれないかも。


でも、ま、そんなん面倒だから黙ってるのがラクかもね。


フォルダ監視している間だけ同期 MonitSync

「フォルダ監視している間だけ同期 MonitSync」
というフリーウェアを公開したよ。おもに自分が使うために。要.NET Framework2.0。
http://tkr.nsf.jp/monitsync/

xcopyとかみたいにどーんと一括で同期するんじゃなくて、起動している間だけ同期する。
NTFSのイベントに100%依存しているので、すごい勢いでドバドバ更新がかかるとイベントが落ちる可能性があります。個人のPCでの利用がいいと思います。

ソース公開…そのうちします。といっても別に見てもなんも面白くないけどね。


晒すだけじゃだめなんだぜ

現代的な Perl を再習得する方法は? - スラッシュドット・ジャパン

→dankogaiさんのエントリ
perl - 現代的な Perl を再習得する方法は
より

モダンPerlに限らず、プログラミングを再?習得するのに最適な方法、それは....
ブログに書きつづけること
です。他のどんな手法もこれに勝ることはないと弾言しましょう。
うん、それは良い方法。…上手な誰かに添削されたりすればウデも急上昇だよね。


ただし、見てもらえるならば。(きしだメソッいやちがうdanメソッド)


上手な誰かに添削してもらえるようになるには、晒して晒し続けてあちこちトラックバックして、アクセス数を伸ばして、ということは、リピータを増やすために面白いことも色々書かなきゃいけないぜ。

ただ漫然と書いてるだけじゃダメなんだぜ。ソースこのブログ。添削されたことなぞ一度もありません。
算数 - とっくりばー
ちょくちょく晒してるんだけどなー。

HTML内タグの閉じ忘れをチェックするツール-ブックマークレット - とっくりばー
とか、頑張ってるんだけどなー。ちーとも反応ないし。何かに反応して作ったわけでもないからトラックバック打つ先も無いしなー。


設計のテクニックってどうすれば。

こないだ tenjin.web/5 に参加したときになんとなく考えていたことを追記。

短く言うと、「女性のみなさん!春日のこの完璧でビューチフルな設計に基づいてコーディングすれば春日の心はいつもあなたと一緒ですよ!」「すぐ逃げてくださーい」「ウィ」
ていうか、意訳すると、つまり設計意図や、複雑性の回避のために支払っているコストをプロジェクト全体で共有するのって一筋縄じゃ行かないよな、という現実。

MVCパターンって、イベント→Controller→Model→Viewっていうイベントの通知まわりが面倒くさいから、誰かが崩し始めたらもうどんどん崩れていくばかりになってしまう。そして、MVCくずれになっちゃったコードをメンテする際、当初一番設計に気を遣ったViewとControllerを分離する仕組み自体が一番邪魔なお荷物になっちゃってたりすると切ない。

ほかの、たとえばStrategyとかFactoryとかも、破ろうと思えば簡単に破られちゃう。せっかく苦労して結合度を下げてたのに!みたいな。

またJavaScriptって自由だから、設計の意図をコードに語らせることができないのも辛いところ。強い型付け+finalとかabstractとかstaticが厳密にあるJavaで社内用フレームワーク作ってたあの頃(「全員、オレ様の意図から外れることは許さんぞ!フハハハ」な頃)がちょっと懐かしかったり。でも自分の中の黒歴史だったり。

もちろん、王道としては、デザインパターンなど一般的な知識をプロジェクトの構成員みんなで勉強しましょう、ということなんだし、細かいテクニックをみんなもっと身につけるんだ、ということなんだけど。

そういう細かいところの積み重ねが、大きなプログラムで効いてくる。プロジェクトで実際に使うテクの大半が、細かいテク。大局的な設計の考え方も、実際にはその細かいテクの延長線上にある。
技術日記@kiwanami

どぉも王道の道のりが遠すぎるような気がするんだよね。

いや、僕も歳とったなあ。もっと若い頃は「みんなを教育してレベルを底上げするんだ!」って息巻いてたのに。

最近僕が求めているのは、
(1)コードが少なくて済んで
(2)各人がマスターして守らなきゃいけない決めごとが少なくて
(3)下手な人が何か書いても全体を壊さなくて
(4)ブラウザ依存とかのやっかいな問題を各人が考えなくて良くて
(5)性能もちゃんと出て
(6)拡張もスムーズで
(7)お客のわがままにも普通の手間で融通が利く
という、そんなコーディング。

で、最近ちょっとFlex3+ActionScript3でAIR(またはswf)っていうのがどんな感じになるのか検討中。

ActionScript3が強い型付けのECMAScriptだってことで、上の(2)(3)を満たす上で結構いいんじゃないかなと期待大。

mxmlの書式を覚えなきゃいけないけど、カレンダーとかスライダーとかをいちいちスクリプトで実現しなくていいし、HTMLとCSSのバッドノウハウをアドホックに覚えてもらうよりはリファレンスにまとまってるぶん、使えるレベルまで到達するのが早いと思う。

そんで、PHPしか書けないって人にはサーバーサイドの、「このURL叩くとこういうJSON返して。」みたいな部分(それもフレームワークの上でやればほぼ定型作業)をやってもらう作戦。

なんとか研究時間を捻出していい方向に向かわせたいところ。それにしても、Java FXとXULとXAMLとmxml。ほとんど同じようなモノがあちこちからボコボコ出てくるあたり、やっぱみんな、僕と同じでHTML嫌いなんだよね!


tenjin.web/5に行ってきた

tenjin.web/5に参加してきた。ええ、久しぶりの参加です。

今回のお題はJavaScriptでRIAなMVCパターンということで、簡単なJavaScriptプログラムも作りながらーのいろいろ脱線しながらーの、楽しかった。

brazilの人のお手本をざっと見つつ、試しにお手本を使わずイチから全部作ってみたらModel部分が結局同じような感じになっちゃったりして、それはそれで教育的な何かを示唆しているような

さて、今日作ったやつを晒しますよ。帰ってきてからもう少し手を入れて、フワッヒュイッと動くようにだけしました。jQueryって便利やね。

JavaScriptでのMVCパターンのお勉強なので、ページ遷移とか通信とか無し。あくまでもメモリ上のModelに対する変更をトリガーとしてViewを更新する、というお話。うん、こういうのあらためて作ると最初にかける一手間はやはり大事なんだよねって再確認。ちゃんとMVCのカタチを意識して作ると楽が出来る。

細かいことを言い出すときりがないというか、たとえば、Modelを変更したときにViewに更新を促すために、ModelのほうにViewのメソッドを呼ぶコードを書いていいのか、とか、JSONで得られたデータをViewにくっつけるべきなのか、とか、教科書的に正しくやろうとすればこのコードだといろんなアラがある。

で、教科書的な正しさ(適切さ)と、実装の手間をできるだけ減らすってことと、作るアプリケーションをどの程度育てていく必要があるかの見極めのバランスで、適当なところで手を打たないとこんな仕事はやってられないのだよね。

もし、ModelとViewがもう、複雑なのがたくさんあるようなことになっちゃうようだったら、Observerパターンみたいなのを実装したほうがいい(=トータルで楽)だろうし、今回作ったコレぐらいだったら、いいじゃんModelの中でViewを呼んじゃえば。と、僕は思う。

あと、C#みたいに、言語仕様の中でイベントハンドリングを面倒見てくれてる場合はサクッと乗っかれば良いんだと思う。


» Read More...

知っていればもっと楽しいデジタル家電の仕組み

@ITでなんだか妙な連載が始まったみたいだよ!

「液晶テレビとプラズマテレビの違いって?」 そんな乙女の疑問に理系男子がお答えします!

決定版! 液晶とプラズマはここが違う(1/2) - @IT MONOist
mononavi_otome.jpg

液晶とプラズマの違いを文系女子にでも解るように解説するお手本を見せてくれるらしい。

そもそも解説しようとすること自体が間違ってるとかいう野暮なツッコミは入れちゃいけないことになってるんだぜ!
図1は液晶テレビが映像を映し出す仕組みを図で示したものです。イメージとしては、シャッターと同じ役割を持つ液晶が
…(中略)…
状態を保ちます。すなわち、ホールド型表示です。

決定版! 液晶とプラズマはここが違う(1/2) - @IT MONOist
いやいやいやいやいや。理系男子のボク、2回読み直しちゃったよ!歳かなあ。
次に、図2のプラズマテレビについて
…(中略)…
プラズマテレビはデバイス(プラズマ)自体が光ります。分かりやすく例えると、プラズマテレビの中にはたくさんの豆電球が並んでおり、その1つ1つが必要に応じて光り加減を制御しています。
ここでイメージした豆電球(=セル)内には、ガスが含まれており、放電により内部に紫外線を
…(中略)…
パッとついてパッと消えるインパルス型表示です。

決定版! 液晶とプラズマはここが違う(1/2) - @IT MONOist
ちょっ、まっ、

さらに次のページでも文系女子が知りたがるようなことは何一つ教えずに走る走るオレたち。
デバイスには、表現できる色の領域(色域)が決められています。中でもHDTV色域と呼ばれるデジタルハイビジョン放送を映すRGB(色の3原色)領域を100%満たしているかどうかが、1つの指標と考えられます。
自発光のプラズマテレビに比べ、発光原理の異なる液晶テレビは、バックライトの分光特性やカラーフィルター特性などにより、色の領域を広げることが難しいとされています。

決定版! 液晶とプラズマはここが違う(2/2) - @IT MONOist
色域とか!

いや、理系男子のボクにとっては、へぇ、なるほどーって、面白いんだ。知ってることと知らないことのつながりみたいな情報って面白い。

mononavi_osarai.jpg
そんな文系女子はいねえ。

この記事、パナソニックの人に書いてもらった文章に@ITの記者さんが妙な男女を紛れ込ませたから変なことになってる。

しょーがないから既婚で理系男子の僕が模範解答を教えてあげるよ。
プラズマは37インチより小さいのが売ってないのでウチの場合は液晶しか選択肢がありません。
でも最近はプラズマでも安いのだと10万円ぐらいからあるみたいだ。へー。

っていうか、模範解答はどう考えても
原理とか色々違うんだけど最近はあんまり違いも無くなってきてるし、うん、じゃあ明日一緒にヨドバシ行っていろいろ見てみよっか
じゃね?


DBDesigner4ファイルからExcelの定義書を作成するツール

DBDesigner4→Excel定義書ツールDBDesigner4の保存ファイルを読み込んでExcelのDB定義書を作成するツールをHTAで作ったよ。

これがあれば、テーブルが100個以上あるデータベースからリバースエンジニアリングしてExcelの定義書が作れたりして便利嬉しい。

Excelのマクロに頼らない点も好感度高い(?)

なお、おまけ機能として、カラムのコメントを例えば

削除フラグ 0:通常 1:削除
みたいに書いてある場合に、
カラム論理名…「削除フラグ」
選択肢…「0:通常 1:削除」
と、分けて表記します。

で、一番苦労したのは、DBDesignerがXMLに保存したマルチバイト文字列をデコードする部分です。なんでUTF-8で保存してないのよぉ。ShiftJISのままでASCIIコード以外を\133とかエンコードした文字列を書き出してるのをADODB.StreamでコチョコチョしてJScriptで扱える文字列に…全然本質と違うとこで…

それから、XMLのDOMを読み込むとのにjQuery使ってます。HTML以外でもそこそこ使えて便利!

環境:Excel2003で確認。
ZIP形式ダウンロード


スゴいフレームワークの構想(2) 言語はなにに

Webアプリのフレームワークにどの言語を選ぶかは悩ましいところ。

僕の興味は、とにかく楽をしながら、でもできるだけ妥協しないで自分と顧客の納得のいくモノを作ること。Ruby on RailsとかCake PHPとかmojaviとか、レールから外れたらかえってつらくなるみたいなのはイヤだ。


言語そのもの
言語そのものは、Java、Ruby、PHP、perlから選んでみる(Pythonは触ったことがない…)。現時点での慣れについては考慮しない。なんとでもなるから。開発~デバッグ~導入~保守~性能のトータルで考えたときに一番楽な組み合わせを選択したい。.Netは書けるけど、結構気に入ってるけど、環境にお金がかかるのがネックなのでちょっと選択しにくい。零細企業ですから。

ロジックが気持ちよく楽に書けるのはRuby。PHP5もだいぶいいけど、[1, 2, 3]で配列にできたり{a:1, b:2, c:3}でハッシュが作れたりするRubyに比べると全然劣る。多重配列に恐ろしく自由に代入できるところはPHPが便利。

PHPの似非オブジェクト指向的な部分は、僕は実は全然平気。文字列や配列がオブジェクトじゃないと気持ちよさが減るけど、扱う関数がちゃんと用意されてれば困りはしないじゃない?そういう意味でPHPの配列関数の充実っぷりはステキ。

ただ、ぶきっちょな言語=パーズが簡単な言語=エディタ が発達する。EclipseのJavaエディタは数ある言語、開発環境の中でも最強だと思う(それでもJava書くのはやっぱり面倒だけど)。EclipseのPDTはかなりキてる。


性能について
性能を考えるとJavaはつらいところ。メモリがばがば使って1サーバーで捌けるユーザー数が明らかに減るのはきつい。Seasar2がようやくtomcat上でホットデプロイできるようになった、って、そこまでいくのにいったい何MBのクラスをロードするんだろうって。


Viewについて
テンプレートに行く前のロジック部分に、表示のための整形みたいなコードを入れたくない。だってそれはViewがやるべきことでしょ。で、PHPのmojaviみたくViewのために別クラスを用意するってのもめんどくさい。

今のところ僕にとってPHPの魅力はSmartyがあること。僕は新しい言語習得が全く苦にならないからだと思うけど、Model、Controller、Viewを適材適所の言語で書きたい。使いやすいUIを作ろうとすれば、ViewにはViewなりの複雑なロジックを入れなきゃいけなくなることがあるので、RubyのAmritaとかPerlのHTML::Templateとかではまだ足りない。

HAMLは、ちょっとHTMLから離れすぎで自由に書きにくい。テンプレートをWYSIWYGエディタでいじるとこまでは今のところ必要ないけど、あっちでプレーンHTMLとJavaScript書いて実験して、こっちにコピペ、みたいなことはやっぱり必要。

Smarty遅いけど、まああれくらいまでなら許容できる。それにどうしてもレスポンスが必要になるページに限ってPHP直書きに逃げるっていう手も残されてるし。

|encode とかをいちいち書かなきゃいけないのもかったるいけど、他の機能があるから仕方ないか。


Modelについて
RDBの接続が自由に出来るのはどの言語でも同じ事だから、考慮することは特にないと思われる。Javaだとコネクションプーリングがある。PHPもコネクションをある程度使い回してくれる。


うーん、やっぱりPHP5+Smartyかなあ。
Rubyで書きたいんだけどなあ。Rubyで、Railsを越えるフレームワーク作って、地を這うRailsのみなさん、こっちは軽くて速くて簡単なRuby on Wingだぜとかって自己満足に浸りたいんだけどなあ。


ツンデレテレビ

タカラトミー、世界初の“ツンデレ”ワンセグテレビ

購入当初、チャンネルボタンなどを操作すると女性の声で「チャンネル変える気ぃ!?」や、輝度を上げると「まぶしいんだけど」と、ツンツンした対応。

 しかし、使い込んで仲良くなると「ええーっ、帰っちゃうの?」(電源OFF)、「チャンネル変えるね」、「明るくしまーす」(輝度向上)など、デレデレな応対になる。

…なにやってんの馬鹿じゃないの。でも笑ったから僕負け。

いやいや。でもチョット待てよ。

こういう脱力おもちゃをメーカーがホントに作っちゃうってのは、ひょっとしたらそこに一定の市場があるって考えたからなのかも。その市場とは…いやげもの?

人生銀行とかラブジェンガとかと同じ所にある商品なのかなー。

げ。全部タカラトミー。すごい。



上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。