  |
はてなキーワード: Guiとは
動いているプロセスのGUIに表示されている文字列を取得するとか、
例えばWindowsでできなくもないけど、
そんなの流行る前から自分はPythonで自動化してきたのだけど、
スクリーンショット取得して、そこから特定の画像に似た画像を探してそこにマウスポインタを移動するとか、
画像として文字を取得して、OCR通して文字列にしてログに残すとか、
あんな高価で変なアプリ買わされなくても子供でも書けそうな時代に思うんだが。
import "空を飛べる"
と書くだけで空が飛べるようになるPythonは便利だ。
（昨日、pip一発で動かなくてハマってたのは秘密だ
Cygameのプレゼンにあった、別プロセスのウィンドウのウィンドウID？指定して貼り付けるのをやってみた
これ面白いなあ
面白いけど、Windowsの電卓は今は昔みたいなWin32APIで書かれてないからなのか失敗する
ペイントもSpy++でなんか変なIDが取得されるし失敗してしまう、残念
でも、メモ帳とパフォーマンスモニターはそのまま貼り付けられるｗ
PythonでQtで作ったGUIの中にWindowsのパフォーマンスモニターがあると違和感すごいｗ
Cygameさんのプレゼンでこの別プロセスがゲームでちゃんと貼り付けられることが前提だからいいけど、
自分がやりたいことでこれで色々うまくいくのかと思うと、うーんとなるなあ
画像の表示も別プロセス側で行って上記方法でそのまま貼り付けられるのはいいけど、
なんでだろう
これまで改良はされてきたし、最新のは知らんのだけど、
プロジェクトの設定とかとりあえず必要最低限だけ表示すればいいのにドバーッと全部表示してしまってて、
しかも結局はコマンドラインのオプションをGUIでチマチマ書くような感じになってしまってて、
これIDEの意味あんの？みたいになるわけだけど、Xcodeを使わないと基本的にMacやiOSのアプリを開発できない縛りもあるわけで、
あと、うろ覚えだけど昔たしかInteface Builderのnibファイルとかバイナリだったんじゃなかったかな
バージョン管理しづらい、差分が分からない、うっかりマウスを滑らせてどこか変更してしまっても分からない、
NeXTはそれでも良かったのかもしれないけど、なんだかなあと思って、できるだけ使いたくなくなる不思議なIDE
プログラミングできる気になった自称中級者は、ソースコードに共通のパターンが現れると決まって、その処理を関数などに共通化したがる。
たしかに、そうすることでソースコードは短くなるし、一見して保守性が上がったような気になるのだが、それは間違った作法だから止めろ。
細かいこと言っても伝わらない自称プログラマが読んでることを想定して、先に結論を簡単に書いておく。
なぜコードを共通化するのがいけないのか。理由は簡単だ。要するに、コードが似ているのは単なる偶然であって、それらは別の処理だからだ。
別の処理だから共通化するのはおかしいし、もし共通化した処理の一方のみ仕様が変わった場合、その修正は他方にも影響してしまう。つまり、保守性が下がっている。
たとえば、同じプロジェクトの中に、10%の消費税を加える処理と、10%の金利を加える処理があったとする。この2つの処理はともに元の金額を1.1倍する処理であり、全く同じ処理であるが、共通化してはいけない。
これらを共通化してしまうと、たとえば金利が8%に変更になったとき、金利計算の処理だけではなく、消費税を計算している箇所すべてを変更しなければならなくなる。
実際のアプリケーションでやりがちなのは、複数の処理の「事前処理」「事後処理」などを1つの関数にして、呼び出し毎に細かい挙動を引数で制御するようなパターンだ。
これは結局、改修を重ねる度に「事前処理」「事後処理」の内容が使用箇所によって全く異なるものとなり、それに対応するために
他にも、GUIアプリでユーザーの応答を待つDialogクラスなんてものを作って、使用箇所ごとにメッセージやボタンに割り当てる処理などを切り替えることがある。
これも間違いなく、プログラムが成長するにつれて破綻する。たとえば、ある場所のダイアログは、表示するメッセージがテキスト形式のみではなくなり、脇に画像を表示するかどうかのフラグをコンストラクタに渡したり、Dialogを継承させて表組みを表示するTableDialogサブクラスを作ったりすることになる。ボタンが「OK」と「キャンセル」の2種類の場合じゃなくなって、表示するボタンの数をコンストラクタに渡したり、ボタンに割り当てる処理をリスト形式で渡したりし出す。
こうして、最初は良い設計に見えたDialogクラスはどんどん複雑になる。こうなった原因は明らかで、本来は異なるものを共通化したからだ。おかしな色気を出さずに、素直に別々に実装しておけばよかったのである。
プログラミングをする上で「コードを共通化する」なんてことは意識しなくていい。それよりもプログラマがすべきことは、処理に適切な名前をつけることだ。そのプログラムにおいて「単なる変数の操作」を超えた意味のある処理には名前をつけろ。そして、同じ意味の処理なら同じ関数を使うし、違う処理なら違う関数を使う。それだけだ。コードが共通化できるかどうかなんて全く関係ない。
変数、関数、クラス、名前空間等が再利用のための機構だという先入観は一旦捨てろ。それらの真の意義は、「関心の分離」にある。つまり、実装を隠蔽し、その意図を抽象するために存在する。たまに勘違いしてる奴がいるが、別に1回しか使われない関数とか、1行しかない関数はあってもいい。というか、この原則にしたがって設計すると、ほとんどの関数（or メソッド）は数行になる。
上の消費税の例で言えば、「消費税を加える」「金利を加える」処理は、明らかに単なる算術演算以上の意味のある操作だから、関数化する。そして、それぞれの実装は当初の仕様では奇しくも全く同じになる。消費税を加える箇所では前者の関数を呼ぶし、金利を加える箇所では後者の関数を呼ぶ。
これはこう言い換えることもできる。消費税を加える関数を変更するのは、消費税の計算処理が変わったときのみであり、金利を加える関数を変更するのは、金利の計算処理が変わったときのみである。つまり、すべての関数は、それを変更する理由がただ1つになるように設計しろということだ。
こういうアプローチでプログラムを書くと、ソースコードはあたかもそのアプリケーションのドメイン特化言語で書かれたかのような見た目になる。
また、一つ一つの関数は小さく、理解しやすく、テストやデバッグも容易になる。そして、結果として再利用もしやすくなるし、プログラムの変更も容易になる。
タイトル通りなんだが、
「初心者にはmacおすすめ！」「世の中のプログラマはみんなmac使っている！」
というバカなことを言っているアホが仰山いて笑える。
しかも、最近、OS事情が大きく変わっているのに、未だにwindowsはunixコマンドガーとか言っているやつが居る。もうね、言葉を失うよね。
まず、最近のＯＳ事情の移り変わりなんだけども、windowsが最近かなりLinuxに近い触感になるような機能が多く追加され続けている。
例えば、wsl(コマンド関係)やwinget(CUIインストール)が挙げられる。
他にそれらを取り巻くプログラミング事情としては、vscodeがある。vscodeは、powershellやsshだけでなく、wslのコマンドも使えるようになっている。
そのため、従来はpythonやらjsはめんどくさ。とおもっていた点もある程度は改善されている。
ちなみにmacは特に最近はプログラミングに関する話を聞かない。
自分が、プログラミング環境の次に、大事な要点だと思っているのが、一般人の使用含めたシェア率。
正直、作っても誰にも使ってもらえないという状況では、全く意味がないので、シェア率は非常に大事だと思っている。
最近のデータでは、88%ぐらいがwindowsであるという統計がある。web系やiosアプリならまだしも、パソコン一般人に使わせたいソフト(特にゲームとか)を作りたいなら、windowsしか選択肢ないと思う。
そんなわけで、元からmac使いなら、まだしもわざわざwindowsから乗り換える必要は全くない。
ただ、mac使いでも全くwindowsでないと非常に困るということは、ある程度は…無くなってきてはいるですよねー。
ほれ、クロスプラットフォーム開発が盛んで、ライブラリなどの環境から障害は、少なくなってきているので…ただし、ios開発お前だけは許さない。
１点目は、web系からプログラミング始めたいとかいう奴に釘差したい、
web系はある程度セキュリティやらデータベース、コマンド知識やらないと爆死する。そんなわけで、GUIオンリーでパソコンを楽しんできた奴には、マジでお勧めしない。
まずは、webからではなく、統合開発環境上で実行ファイル(メモ帳とか)を作れる方面から始めろ。そして、linuxとかネットワークとかセキュリティとかの本を片っ端から読め。webを始めるのは、それからだ。
webでも実行ファイルを作ることは、星の数ほどあるし、別に必要ない知識はないぞ。
２点目は、勉強用とはいえ、いつも使っているＯＳ上で、コマンドが使えるからと鯖建てるな。(windows・macどちらも)
かならず、仮想ＯＳでやれよ。ミスって、apacheインストールできないとか言われても、周りは困る。とりあえず、わけわかめになったら、スナップショットでリセットしとけ。
