  |
はてなキーワード: guiとは
なんでだろう
これまで改良はされてきたし、最新のは知らんのだけど、
プロジェクトの設定とかとりあえず必要最低限だけ表示すればいいのにドバーッと全部表示してしまってて、
しかも結局はコマンドラインのオプションを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インストールできないとか言われても、周りは困る。とりあえず、わけわかめになったら、スナップショットでリセットしとけ。
それにともない、いわゆるプログラマーも、いわゆるデザイン系の知識というものが必要と言われるようになってきた。
いらないといわれれば、サーバ系を中心として、CUI時代の知識でも十分
難しいところではあるが、色についても各色８Bitという時代から各色１０Bit ４０Bit colorの時代に突入している。
そりゃそうだわな。誰が見ても、コンピューターの色
まぁ 廉価版
それがいつの間にか４８Bitの時代 そこそこ見られるようになっている。
リクエストも増えてくる
われわれにはCanonの色づくり Nikonの色づくり Sonyの色づくりというものがあるんだ。
ということまでで十分。それ以上はしらなくていいという世界。
一般的にはワークスがやっていて、市販品ではない技術が コンパイラ技術の発展でデフォルトライブラリに含まれ始めた
金銭的には思うことはあるが、それはマネージャーが考えれば良い。技術屋は考慮こそするが、そこまで考えることではない。
C++11がC++2Aということで１０年の歴史を経て安定気に入り採用が増えてきたことが１つの少佐であろう.
実用に十分な性能があるから、これまで個別のメーカアプリの機能だったものをデフォルトライブラリの範疇と考えて良いと思う。
ま、車で言うところの３No.アプリが増えている。
センスの無い奴の問題は、知識がないことではなく、頭がおかしいことなんだ。
これは後天的に直せない。そして、センスのないプログラマは他人に迷惑をかける。だから、センスのない奴はプログラマになってはいけない。
こんなのは誰でも書ける。身長(m)と体重(kg)を受け取って、(体重)÷(身長*身長)を計算して出力するだけだ。
GUI等をつけたとしても、総コード行数10数行で実装できるだろう。
ところが、センスのないやつは全く違うことを考える。
彼らの一部は、BMIを計算するプログラムを作るのに、なぜかユーザー登録画面を作ろうとする。
そして、身長と体重のほかに、年齢や性別などの様々なパラメータを管理できるようにし、それらのパラメータを日ごと、あるいは週ごと、あるいは月ごとに入力できるようにし、指定期間での推移をグラフで表示するシステムを作り出す。
ユーザーごとに管理するパラメータの種類は増減するため、BMIを計算する場合、「身長と体重はどのフィールドに格納されているか」というような間接的な情報が必要になり、それを記載した設定ファイル等を読み取る別のプログラムを作り出す。
BMI以外の様々な指標を計算させるために、設定ファイルに書ける独自のDSLのようなものを作り、パラメータ同士の加減乗除や、指定した期間の移動平均などを計算できるようにする。
データ定義にもとことん拘る。単位を何にするかとか、グラフで表示したときに何色にするかとか、軸に単位を表示するかとか、スケールからはみ出したときにどう表示するか等のありとあらゆる情報を各パラメータに対して定義できるよう設計する。
こうして出来上がった巨大なシステムは、身長Hと体重Wを入力すると、W/H*Hの結果を表示するためだけに使われる。
既に述べたように、ここで問題なのは、彼がYAGNI（You Ain't Gonna Need It.）という原則を知らないことではない。
「普通の開発者ならあえてそんなことはしない」ということを自然に行ってしまうこと。これが本質的な問題なのだ。
ちなみに、センスのない奴の頭のおかしさというのは、本当に常軌を逸している。だから、読者がすっと腑に落ちるような例を挙げることは極めて難しい。
たとえば、「数学ができない生徒がいる」という現象を説明するためには、「計算問題は解けるが、文章問題は解けない」というような類型を示すことができる。しかし、「センスのないプログラマ」は、常人の世界観を超越しているので、そういうシンプルな例示や説明ができない。上に書いたたとえ話ですら、実在する彼らに比べれば、まだマシなのである。
これまで使ってたパソコン(surfacelaptop)に不満がある訳ではなかったが、好奇心でmacも使ってみたい思いが募りついに買ってしまった。
2年くらい使って売ればそれなりに高く売れるやろの精神でかなりオーバースペックなやつを買ってしまった。
せっかくなので初体験直後に驚いた仕様・感じたことを記録しておく。(MBP16インチ)
ビビった。昔からの伝統なんだね。ウィンドウ無い癖にタスク切り替えには居座っててお前どういう状態やねんという感情が未だ拭えない
驚いた。GNOMEとかでも標準で使えるからmacにも当然標準搭載だと思ってた(課金するか迷ってる)
これは事前に知ってたけどやっぱ謎。結局caskのお世話になってるからあんまり見ないけど
ctrlのつもりでfnキー押す→いや押すべきはcommandだった、というパターンを20回くらい繰り返した
でもcontrolとcommandが別なの良い。まあ慣れよね。
マウスの加速度無効くらいはチェックボックスで設定させてほしい
というか英字→日本語への切り替え直後にラグくなるのは仕様なんだろうか
fnキーの位置が左下角になってるのはこいつのせいなのか？！おおん？？
大してディレクトリ構造が重要じゃなさそうなファイル添付画面とかで急に4ペイン表示になったりするのは何か意味があるんだろうか
というか素直にパス表示して欲しい(表示できたらごめん)
そんなに不自由しない。自分に合ったアダプタ勝手につけろの精神はきらいではない。
ねだん高かったからね
ねだん高かったからね
ねだん高かったからね
ねだん高かったからね、ってだけでは済まされないレベルで良い。謎技術
10年超のプログラマやってるものだけど自分の成長過程を書いてみよう
その後、GUIツールで操作しようとすると知識不足の壁が立ちはだかる。
インスタントに慣れてしまってマニュアルを読むのが面倒くさいけど、ここは焦らずにじっくり取り組もう。
Dockerインストールの次にやりたいことは、GUIでDockerを操作すること。
「Portainer」など、DockerをGUIで使えるツールがあるらしい。
こういうツールを試してみれば良いのだろうか？
なるほど、そういうものなんですね。
Dockerは、「Dockerfile」という設定ファイルを作って運用するみたい。
手書きでコマンドをまとめるのは、結構大変そうだから、こういう設定をGUIツールでチャチャッと済ませたい。
説明を最小限にして、操作の手順だけをまとめたら、これだけコンパクトな文量になるんだな。
もう13時だし、ここらで試しにインストールしてみるか。
