これ見た>< すごくおもしろかった><>< -- SWITCHインタビュー 達人達(たち)「石黒浩×清水ミチコ」 www4.nhk.or.jp/switch-int/x/2…
これ見た>< すごくおもしろかった><>< -- SWITCHインタビュー 達人達(たち)「石黒浩×清水ミチコ」 www4.nhk.or.jp/switch-int/x/2…
流れちゃんと追ってなくて元の話しよくわかんないけど、航空も鉄道も両方好きで、鉄道趣味誌毎月2冊読んでて(予算の都合上エアラインは興味ある号しか買わない・・・><)、さらに超多趣味すぎて何マニアだか忘れるレベルだけど、鉄オタが突出してマナー悪いと思う><
鉄オタが何でマナー悪いかというと、オレンジの仮説的に、元々鉄オタが急増した時期の日本人のマナーのレベルって平均的にそんな感じだったのが、文化のごとく鉄オタコミュニティーで受け継がれてしまった説が><
「東大入試の最頻出英単語クイズ!難関大を志望する人は80点以上を目指すべし!」 orangeの成績: 60点! 判定: D判定 appli-maker.jp/quiz_apps/15404
@ejo090 せめて死なない飲み物飲むほうが・・・>< コンシューマー向け>< meiji.co.jp/meiji-eiyoucar… プロ(?)向け>< products.abbott.co.jp/medical/produc…
経腸栄養剤飲んでた時期何度かあるけど、飲んでる間わりと体調楽なのすごい><(体調崩したから飲むわけだけど体調いい><(矛盾><;))
・・・・・>< -- Mr Fusion on Flightradar24.com #flightradar24 fr24.com/Mr Fusion/outatime
Flightradar24.com - Live flight tracker! flightradar24.com/Mr%20Fusion/ou…
なんかプログラミングの初心者の方の相談の会話で、薦められるままQt-Jambi&EMF(?><)になりそうな流れの会話を観測したけど、こういうのこそ「C# の方が躓かないで手っ取り早く作れるよ><;」って言いたくなるアレだ><;
こう、「やっぱGUIを持ったソフトウェアのプログラミングってすごく難しいんだな・・・」と思わせちゃう方向に導かれちゃってるようにオレンジには見える・・・><;
プログラミングの初心者で迷ってる人に、環境構築から躓く可能性があるものはなるべく薦めちゃ駄目だと思うし、なるべく結果を超高速に得られる物の方が挫折しないから優れたRADを薦める方がいいよね><(だからオレンジはC# でデジタル時計を一瞬で作るところからやるべきって考えてる><)
@nebula121 Hello worldは、開発環境を正しくインストールできたかの確認用としての面が大きいはずなんだけど、教える側の人でもそれを理解できてない人がわりと居る気がする・・・><(環境の特徴を理解するためという面も大きいけど超初心者にはそれほぼ関係ないし><)
@nebula121 わけのわからない英語のような物をまったくわけがわからないまま書かされるよりは、パレットから部品を選んで貼り付けてビジュアルに操作できる方がとっつきやすいと思うんだけど…><(テキストエディタは「私はそれをどうやって知る事が出来ますか?」に答えられない><)
たぶん、Eclipse Modeling Frameworkを薦めた人も、そういう意味で『ビジュアルにプログラミングするほうが優しい』と考えて薦めたんだろうけど、なんというかそれは・・・う~ん><;
@nebula121 非ビジュアルなプログラミング環境には、提示が全く無いから、何もかも自力で調べなければいけない>< 選択肢はRADでも非RADでも実は全く変わらなくて、(レストランとかの)メニューがあるかないかみたいな違いでしかない>< おいしそうなのを注文すればいい><
HSPは別の意味で全くお勧めできない><;(高度な事をしようとすると通常よりとても高度でバッドノウハウなテクニックを要する環境って、高度な事をしようとすると本末転倒になってしまうから><;)
@nebula121 この辺読むほうがなんでそういうのがあるのかは理解できるかも>< itmedia.co.jp/im/articles/02…
「私はそれをどうやって知る事が出来ますか?」に答えられるかどうかってつまり、「ヤサイニンニクアブラカラメ」とか「ベンティアドショットヘーゼルナッツチョコレートクリームフラペチーノ」とかそんなわけのわからない知らないよ!><どこかにわかりやすく書いとけよ!><;みたいな><
RADな開発環境なら、そんな謎の呪文みたいなのをドキュメント読んで探すんじゃなく、パレットからそれっぽいの選べばいい>< 写真がいっぱいのメニュー見て、メニュー指差して店員さんに「これください><」って言えばいいような気軽さ><
例えば非ビジュアルでテキストエディタでプログラミングする環境で、ユーザーに色を選択させるGUIを作りたいときどうすればいい?>< ググれとな?>< RADならそれっぽい部品を見つければいい>< Color何とかって名前がついてるやつとかそれっぽいアイコンのとか><
@nebula121 調べるの意味が違う>< ドキュメントを読む必要が発生するのがやさしくない>< 説明書を読まないと使えない製品と変わらない>< そうではなく、タイマーが使いたいのであれば時計っぽいアイコンのを見つければいいし、使い方もプロパティとかいじればいい><
@nebula121 そもそもそのテキストに何をどう書けばいいのかどうわかるの?>< 例えばタイマーが使いたかったとしてどう呼ぶのか?そもそもタイマーの存在をどう知れるのか?>< 提示が無い=説明書を読む以外に知りようがない><
@nebula121 RADを使うのに必要な知識は、「パレットからそれっぽい部品を選んで貼ってみる(違うと思ったら剥がせばいい)」「部品の動作はプロパティとかそんな感じの所で弄ってみる(弄ればリアルタイムに反映)」「実行は三角の再生ボタンみたいなやつ押せばおk」の3点かも><
@nebula121 つまり弄ってみて違ってたら剥がすいうプロセスで知れるのRADで、わざわざ勉強して覚えないといけないのが非RAD>< それっぽいのを見て「なんだろうこの部品?><」で貼ってみてわかんなかったら剥がせばいい気軽さ><
@nebula121 普通は気づけるように、新規にプロジェクトを作れば、さらに物によっては(たしかDelphi 7が)、起動したら何もしなくてもフォームが真ん中に、パレットがバーン!とあって、何も説明しなくても判る工夫がされてる>< 「気づける」正しいデザイン><
@nebula121 そこから先は超高度な補完処理の出番かも>< そこだけはどうしてもちょっとだけ勉強しないといけないけど、例えばC# ならCtrl+スペースを押せば選択肢が提示され、それを選ぶとどうなるかのヘルプも同時に勝手にポップアップ表示される><
@nebula121 RADにおいては極端に言うと全体像なんて理解できてなくていい><(実際デザイナが作ったファイルなんて見ない><) わからなくても実行してみればいい>< 何になるのかは実行したそのまま>< 頻繁にコンパイルしても気にならない高速なコンパイラが使われてる事多いし
@nebula121 実際問題としてRAD云々に関係なく、全体像を真に理解できてるプログラミングなんてする事まず無いかも>< ほとんどの場合だいたい何かが隠蔽されてる>< 例えばQtが裏でOSに対して何をしているかなんて(Qt内部のコードを全部読んだ人じゃなきゃ)知らない><
今の会話で初めて気づいたけど、プログラミングの比較的初心者の人って、プログラマは全体をすべて理解できるのが普通みたいに考えちゃうのかも・・・?>< 実際は部品単位に、見方を変えるとレイヤ単位に分業されてて、部品や下の層が具体的に何するかなんていちいち知らない><
@nebula121 (2つの意味が混ざっちゃうけど)、全体像は思い浮かべる必要が出る事はたしかだし、試作じゃなければちゃんと設計する必要があるけど、自分以外がする仕事の中身は、知っていた方がいいけど知らなくてもいいために分業されてるし、そのためにツールキットなるものがある><
@nebula121 その通りではあるけど、正しく使った場合、部品同士の連携の部分と未実装のロジックと構造のみ最小限書いてる事になるかも>< それはRADに限った話では無くQtも含めたあらゆるツールキットやライブラリ、あるいはOS等を正しく使った場合そうなるはず><
@nebula121 QtはRADっぽさが全く無くてビジュアルに連携できない(シグナルスロットエディタ(?)なる不完全な物は一応あるけど)けど、少なくともDelphiの場合だと、ビジュアルに「この部品にあの部品に関連する動作をさせて・・・」みたいな事もできるようになってる><
QtデザイナがRADとして不完全というか全然RADっぽさが無いのって、シグナルスロットエディタが不完全というよりも、GUIパーツって概念はあってもコンポーネントって概念が無いから、非GUI部品との連携が出来ないせいで無意味になってるのかも><
Qtデザイナが、あらゆるQtのクラスを、RAD環境のコンポーネントのごとくフォームに貼り付けられるみたいな無理やりな方式にしたら、RADになりそう?><;
@nebula121 そうじゃなく普通にコードもテキストとして弄る必要もあるんだけど、部品の設計が他の部品と連携するような感じでうまく出来てて、プロパティの所と指定するだけで連携できる場面が多い感じ>< Qtのシグナルとスロットがすさまじく増えた感じ?><;
@nebula121 コンポーネント指向的にそれをやろうとすると、buttonコンポーネントに『数字ボタン』みたいなモードも持たせて、そのボタンの数字も設定できるようにして、他の部品に渡すってするかも>< 実はそれ、OKボタンとかキャンセルボタンはそう実装するのが普通><
@nebula121 ちなみにC# というか.NetのOKボタンとかの実装>< 例えばDialogResultにOKを設定するだけで、多くの人が想定するであろうOKボタンになる><(TextにもOKって書かないとあれだけど><;) msdn.microsoft.com/ja-jp/library/…
@nebula121 よくわからないけど、オレンジがそれをRAD的に考えるなら、他の部品に実行のシグナルを送るボタン、処理をして二つの結果を出力できるコンポーネント、そのコンポーネントにテキストボックスを二つ指定できるようにしてあって、それがテキストを書き換えるってする><
@nebula121 電卓の例って(実際は無いと思うけど)例えとしてすごく優れてて、例えば『電卓コンポーネント』が、押された(シグナルを飛ばしてきた)ボタンに設定された(数字とか加減乗除とか)の動作を行うコンポーネントとして設計されていたら、それはとてもRAD的な発想かも><
@nebula121 無い部品は自分で作るしかないし、無い物だけ作るべきかも>< 欲しいけど部品が無い機能を、部品として作るよりも短く書く方が手軽であればそうすべきで、それは例えば、デジタル時計の1行だけ書くlabelに時刻の文字列を与えるコードがそうかも><
@nebula121 それはその通りで、だからこそGUIのみでフローチャートを弄るような環境と別にRAD環境がある感じ><(その複雑な処理は単一あるいはいくつかのコンポーネントとして作るのがコンポーネント指向>< そのコンポーネントはさらに複数のコンポーネントから出来てたり><)