  |
はてなキーワード: guiとは
スキルというか"プログラミング"についての理解が足りてないだけだと。
適材適所。スキルレベルも含めて、そのとき一番"自分に"いい(楽とかスキルアップ)と思うものを選べばいいのでは？
なければ自分でやる。そもそも連携可能でなければ出てこないし、労力に見合わなければやらない。
Pythonからエクセルを動かすのは、試してみたが、VBAマクロの方が楽に感じる。操作を記録する機能はあるし、そこから不要部分削ったりすればよく、Pythonでエクセル動かそうとすると読みにくいし何やってるか結局わからない。
汎用型か、特化型か。Pythonで楽になるならVBAマクロはいらない。汎用性無双ならアセンブラか機械語でプログラミング言語は止まってる。
プログラマーの人はエクセルなどを嫌うけれど、matplotlibを細かい調整しようとすると調べて描画し直してを繰り返さないとならず、GUIでポチポチ調整する方が楽に感じてしまう。
エクセル含め便利なツールはがっつり使う。楽だから。エクセルで辛くなったら、GUI=>VBAマクロ=>自作ツール。GUIで楽なら無駄に自作ツールなんか作らない。楽になりたい時だけ
個人でGUIを作るとして、ボタンやプルダウンは簡単だけど、マウスを使ってインタラクティブになるとググってもすぐ出てこない。
Python使いじゃないのでなんともだけど、PythonオンリーならDjangoとか？
PythonはGUIが得意な印象がないので、自分ならJS(TS)+Pythonで。Python部分は必要最小限にして、Node.jsで呼び出しか、ReactでAPIコール。
自分はプログラマーではないので、スキルが足りてないだけなのかもしれないけれど・・・。
例えば動画を編集していてDaVinciと他のソフトを連携したいなと思っても、そういうのはググっても出てこない。
Photoshopのプラグインとして機械学習を使ったものを入れたいと思っても、ググっても出てこない。
Pythonからエクセルを動かすのは、試してみたが、VBAマクロの方が楽に感じる。操作を記録する機能はあるし、そこから不要部分削ったりすればよく、
Pythonでエクセル動かそうとすると読みにくいし何やってるか結局わからない。
プログラマーの人はエクセルなどを嫌うけれど、matplotlibを細かい調整しようとすると調べて描画し直してを繰り返さないとならず、
個人でGUIを作るとして、ボタンやプルダウンは簡単だけど、マウスを使ってインタラクティブになるとググってもすぐ出てこない。
例えば、狙ったところを操作できるような、タッチパネルの進化。昔のタッチパネルって強く押さないと反応せず、操作しにくくなかっただろうか？あれは抵抗膜方式といわれる方式が使われていたからだが、それが静電気で反応する静電容量式が普及することで一気に操作性が上がった。
後はCPUの処理性能。過去のLinux搭載の携帯端末なんかは処理速度が遅く、ストレスがすごくなかっただろうか？
だけどiPhoneは最初からぬるぬる動いていた。そのレベルでストレスなく動かせるにはCPUの性能が上がる2010年代を待たなければいけなかった。
静電容量式は新しい技術ではなかった（券売機とかATMとか）が、当時細かい操作に向かなかった。むしろ抵抗膜＆スタイラスの方が細かい操作が可能だったため、そこに固執してしまったが、静電容量式チューニング＆GUIを工夫した事が正解だった。
Linux 搭載のガラケーも IPhone 直前のモデルはそこまで遅くはなかったし、PDA 勢から見ても CPU 的には一足飛びに進化したわけではなかった。ただハードウェア・OSから作り込むことで、画面の描画やブラウザのカスタマイズで他より早く見せることが出来た。
初代 iphone 以前に要素はあったというか、言い換えると同じ要素が揃っていても、他のメーカーには iphone が作れなかった。（正解が見つけられなかった）
という方が近いのでは。
夏に初めてPSVRで人喰いの大鷲トリコと、OculusでVRChatを経験して人生変わる位感動してしまった。
8月にはVRChat内に「STELLA」というオープンワールドが登場した。とてもエキサイティングなのに、一般的にVRが普及しないのはなぜなんだろう？
確かにVR酔いはきついが、慣れてくればどうってことない。値段もOculus Riftなら中古で2万円位で購入できるし、新品で買ってもそんなに高くない。
だがしかし、amazonのこのレビューを見ると確かにと首を縦に振らざるを得ない。
ヘッドマウントディスプレイと操作のためのコントローラーが２つ。
動作の検出解像度は高く、微妙な動作、指先の動きまで検出してVR空間上にフィードバックしてくれる。
このクオリティでこのお値段というのはすごい事だと思う。
ハードウェアとしての★は疑いようもなく５つだろう。
いくつかゲームを購入したが、最初にVR体験から得られる感動に慣れると、あとはゲーム自体の質の方が重要になってくる。
残念ながら、ゲームの質は、他の据え置きゲーム機やSteamに数段劣る。
ストーリーを追えないので、当然楽しさは半減する。
また、VR特有の問題として入力インターフェースが実は不自由であるという点も問題だ。
マウス＋キーボードには数多くのボタンがあり、そのキーの数だけゲーム内の世界に対して多彩なアクションを行うことができるが、本商品のコントローラーは片手でボタン５つ＋モーションだけである。
これまではプレイヤーの母数が少なかったため、特有のインターフェースに適したGUIやゲームシステムが洗練されるだけの開発費が投入されづらい状況だったのではなかろうか。
本商品が大量に売れ、プレイヤーの母数が増えたことで、今後、VRゲームの質も向上が望めるのではないかと思う。
だが、残念ながら、現時点では非VRゲームで出会えた「自分の好みに合う、何百時間も没頭できるタイトル」は、VR環境では一つも見つけられず、本商品は置物になっている。
余談だが、本商品を活用して、メジャーなVRアダルトコンテンツにも手を出してみたが、正直、実用度は低い。
コントローラーから手を離すとVR空間に対して何もできなくなりVRの良さを体感することができず、かといってコントローラーを握ってるとナニを握れない、というジレンマに陥ってしまう。
@kis (id:nowokay) さんの以下の記事についてです。
https://nowokay.hatenablog.com/entry/2021/09/25/042831
ブコメにもあるようにちょっと内容が雑というかわかりにくいせいで賛否両論になってしまっていて、もしかしたら近いうちにアンサー記事が出るかもしれませんが、自分自身の理解を助けるためにも言わんとしていることを推測しつつ、自分の認識もまとめておこうと思い書くことにしました。明らかに誤読してそうな箇所があれば、指摘してください。
まずは前提を書いておかないと論点がぼやけると思うのでいちおう。
その他の前提:
2000年代に入って関数型プログラミングが脚光を浴び始めたのは、コンピュータ資源が潤沢になりパフォーマンスをそれほど気にしなくってよくなったことが大きな理由ではないか、という認識があります。
関数型プログラミング言語の内部実装を読んだことがないので推測ですが、データを不変にするということはその都度メモリ領域を新たに割り当てることになり、そのオーバーヘッドがプログラムのパフォーマンスに影響を与えるので、パフォーマンス要件がをシビアな場合、どうしてもメモリ割り当てや計算効率を考えるとミュータブルにせざるをえないと思います。が、ウェブアプリケーションに限っていえば、データベースアクセスやネットワークアクセスのレイテンシが大きいので、そうした相対的に細かいオーバーヘッドを無視しても（大抵の場合は）問題にならなくなった、というのが「時代」の流れなんだという認識です。
いっぽうで別の観点もあって、REST API や FaaS が一般化して、関数単位で処理を分割し、アプリケーション外部に配置することが当たり前になってきた現状があり、マイクロサービスのようにアプリケーション自体もモジュールの一単位として考えると、アプリケーション内部のモジュール同士でも関数ベースでやりとりする形になっても不自然ではないと考えられます。
元記事にもありますが、RPC の派生（実装？）として生まれた Java の CORBA や Microsoft の DCOM みたいな振る舞い付きのオブジェクト（コンポーネント）を共有しようという世界観は廃れ、REST API のような単一の振る舞い（エンドポイント）とそれにひもづく JSON のようなデータ構造のみを受け渡すやり方が一般的になったアプリケーション間通信の潮流と、計算機資源が潤沢になって再度脚光を浴びた関数型プログラミングが、レイヤーの違いを飛び越えてひとつになろうとしているのではないか、と。
つまり、元記事に書かれている「時代に合ってない」というのは、「データ構造と振る舞いが一体となったオブジェクト」のような「なにか」は、そうした背景があるために、どこにも存在する必要がなくなってきているのではないか、と解釈しました。
なので、以下のコメントはちょっと論点がずれてると思いました。
はあ？「再利用する方法としてはWeb APIが主流」って、その中身をオブジェクト指向で設計することは、全く矛盾しません。 部品化の単位は、慣習や柵などで大きく変わります。オブジェクト指向とはほぼ無関係です。
https://b.hatena.ne.jp/entry/4708813645995359202/comment/suikyojin
なんでサービスとして外とやり取りする話とサービスの内部設計の話をごっちゃにしてんだ。なんか理解度が怪しくない
https://b.hatena.ne.jp/entry/4708813645995359202/comment/ssssschang
たしかに、アプリケーション単位とアプリケーション内部のモジュール単位とでその表現形式を合わせる必要はないんですが、元記事の言わんとしていることはこの一文に端的に表れていると思います。
ソフトウェアの記述をまとめるという視点では主にステートレスな関数を分類できれば充分で、データと振る舞いをまとめたオブジェクトというのは大きすぎる、システムを分割して管理しやすくするという視点ではオブジェクトというのはライフサイクルやリソース管理の視点が足りず小さすぎる、ということで、オブジェクト指向の粒度でのソフトウェア管理は出番がなくなっているのではないか、と思います。
「オブジェクト指向でなぜつくるのか」という本がありますが、「え、いまどきオブジェクト指向でつくらなくない？」っていつも思います。内容的には、もうほとんどはオブジェクト指向関係ないソフトウェア工学の紹介になっていますね。
当該書籍は読んだので後半はまぁわかるんですが、前半は「え、いまでもオブジェクト指向でつくるのが主流じゃないの？」って思ってしまいます（オブジェクト指向の定義が「データ構造と振る舞いが一体となったオブジェクトの集まりとしてソフトウェアを組織化すること」なのであれば）。
Joe Armstrong が "Why OO Sucks" を書いたのが2000年とのことなのですが、そろそろこうした議論は収束に向かってほしいと個人的には思います（とっくに収束していると感じている方もいらっしゃるでしょうけど）。
文房具だと、シャープペンシルやボールペンなどは価格が安く、しかも種類が多くあり、
合わなければ他の商品を探せばいい。
紙についても色んな種類が手頃な価格であり、色んな物を試して、合うものを選べる。
紙の大きさも色々あるし、合わなければ自分でカットすればいい。
Apple Pencilや、ワコム、他のメーカーもあるが数が減る。
書き心地が気に入らないといって、別の物を買おうとすると高くてなかなか買えない。
ディスプレイにシートを貼り付ける方法もあるが、書き心地だけを変更したいのに、表示が悪くなったりする。
じゃあ使いやすい方でいいじゃんと思うだろうが、デジタル推進派は、紙の削減も同時に起こるので選択肢は減るのだ。
あとソフトについても、勝者総取りというか、もう勝負はついてしまっていて、
もう少し便利にならないかな、といったかゆい所に手が届くような改善はもうされない。
そしてデジタル推進派は、人間がシステムに合わせるべき、という。
プログラマーの人は便利になっている。
じゃあプログラミング勉強すればいいじゃんと言われるだろうが、
市販ソフトのここのGUIの使い勝手が悪いから変更したいというのに対して、書籍やネットを探しても出てこない。
アラン・ケイらによってAlto上で開発された世界初のGUIベースのオペレーティングシステム (OS) 的存在であるSmalltalkは、パーソナルコンピューティングの方向性をエンドユーザーに示すだけでなく、オブジェクト指向の概念を本格的に取り入れた設計で開発者にもアピールし、このときのオブジェクト指向によるOS（APIやフレームワーク）設計は、現在最先端と言われるOSにも今なお色濃い影響を与え続けている。
1970年代半ばにはすでに、ウインドウシステム、メニュー操作、アイコン付きパレット、WYSIWYGエディタなど、現在のパソコンに匹敵する特徴も備えていた。出資受容の条件に要求してこれを見た、Apple Computerのスティーブ・ジョブズに大きな影響を与え、LisaやMacintoshを開発させるきっかけとなった。
前にhttps://anond.hatelabo.jp/20210526121840を書いた増田ですが、Pythonを学んで1ヶ月が経ちました。
最近はPySimpleGUIを使いGUIアプリを作りつつ、更に自分の業務を色々と自動化しました。
ついつい自分の書いたコードを見返しながら、そこからコピペして作ったりばかりで
なかなか自分の記憶を引っ張ってコードを書くことが出来ていません。
最近はDjangoの講座動画を見ながら、休みの日にちょこちょこコードを書いています。
こういうのを学べば学ぶほど、サービスやアプリを安定稼働させているエンジニアの方々への感謝と畏敬の念ばかり浮かんできます。
