  |
はてなキーワード: インタフェースとは
プログラム同士を連結しにくいので、どうしてもその目的限定の用途しか持てないし、アプリの機能に深く依存した作りになってしまうから、賞味期限も短い。なにせプログラミング界に「過度の対話的インタフェースを避ける」って原則があるくらいだ。VBA や Applescript はまあまあ上手くやっているけどね。
個人用の作業補助ツールを黙々と作ってきたけど、今は、なるべくやるべきではない、って考えを持ってる。
社会全体をひとつの大きなソフトウェアハウスとみなすと、各ユーザーが独自に自分用ツールを持ってコッソリ使うという状況は、コードの重複に他ならない。各個人でメンテする必要があって、バグもそれぞれの環境で発生する。それよりも、機能要望の声を集め、製作に手を挙げたプログラマーが責任を持ってプログラムを管理し、ユーザーはバグレポートをその人に報告する方が、労力の集約・責任の分担の観点でより効率的だ。
twitter でその道の専門家を探し、ツイートを引用して議論に引っ張り込み、目的の機能がないって言質をとる。やり取りを togetter にまとめる。暇なプログラマーが最初の実装を書く。reddit で紹介されて世界に広まり、 github でフォークがたくさん作られる。プログラミング言語を換えた、より洗練された Yet another ツールが作られる…
SNS は汎用の、新機能リクエストプラットホームとしても使われてる。
自分で自分のためのツールを作る気になって、でもそれを使う想定ユーザーがどう考えても自分以外に思いつかないときは、糊(のり)だけを作りたい。アプリの拡張フックと、配布されてるモジュール・コマンド・汎用プログラミング言語、OSの標準機能。それらを繋ぐだけの簡単なお仕事を。
それを超える苦労の必要は、サインだ。「ここに誰かの仕事の入り込む余地があるな…」
この記事を読んで、自分もそういうのあったなぁって思ったので書いてみた。
仲間がいるように思えてちょっと嬉しい。
でも仕事が忙しかったりで家でも練習せず、お金ももったいないなと思い始めたので辞めた。
写真をバンバン撮って、ネットにアップロードして売っちゃうぜ！
なんて考えていたけど、カメラが重いし持ち運びも不便だしで触らなくなってしまった。
ちなみに一眼レフカメラは2台（時期をずらして）買ったけど埃を被っている。
・バイク
続いている趣味と言えば趣味なんだけど、数ヶ月乗らなかったりもする。
ちなみにアドベンチャータイプのバイクと大型ツアラーと2台所有してる。
・車
車が趣味というより、自転車代わりにどこか近所に出かけたりするのに使ってる。
ちなみに車をいじったりとかは全然興味ない。
Civ系が面白いと聞いたのでやってみたけど、自分には操作が不便で面白さが分からなかった…
他にも面白そうなものとかはあったんだけど、インタフェースが英語なので諦めた。
・旅行
旅行行くだけで数万飛ぶし、休み潰れるしで「旅行行きたいな」って思うだけで十分なことに気がついてしまった。
・小説
歳取ったせいか（30代後半）、昔ほど「この本を一気に読むぞ！」という気力も無ければ、読んでる本を途中で読んでることすら忘れてしまうことが多い。もうダメかもしれない。
面白いのとかもあるんだけど、1〜2時間ずっと見続けるってのは意外と根気が必要で、だるいなぁって思うのが先に勝ってしまう。
・映画
ネット配信動画と同じ感じで、たまに映画館には行くけど、よっぽど見たいものでなければ行かなくなってしまった。
・サバゲー
興味はあるし、中学生の時にちょっとやってたんだけど、身近にやる人がいないので何も手つかず。
・イラスト
安いペンタブ買ったけど、もともと絵心がないのもあって埃被ってる。
・家庭菜園：前にも少しやってたけど、水をあげることすら忘れてしまう…
といった具合なんだけど、いくつか副業をしていて、副業は仕事だからやらないといけない強制力が働いてやってる。
時代についていけてないオッサンの独り言なのだが、今のデジタル技術に閉塞感を感じている。
機械学習は論文を読んで実装してを繰り返しているが、なんせ金がなくてクラウドを使えない。
（安いクラウドくらいは書籍やネットで調べて使えているが、業務でやってる人からするとレベルは低い)
1回数十万～億単位の金なんて個人では無理で、RTX3090だと結果が出ない。
時代に追いつこうとして取り組んでいるが、やりたいことではない。
物理が好きなので、応力、流体、電磁波、光学、電子といったシミュレーションがやりたいことだが、
GAFAMと呼ばれるところが良い物を出してくれるわけではないので、良くならない。
UIを作れるスキルがあればいいのだが、残念ながら古臭いインタフェースしか作れない。それにUIを作りたいわけでもない。
オープンソースや個人で買えるレベルの設計ソフトでは機能が足りていないし、
USBやHDMIの規格にあっているかのチェックをするハードウェアは個人では買えない価格のままだ。
ゲームを配信したり、ネットフリックスを見たり、漫画を電子書籍で読むといった、
時代にあった物が楽しいと思えればいいのだが、自分には合わず止めてしまった。
今の主流に乗っていて、次々と新しいものが出てくるのを楽しめていれば閉塞感も感じないのだろうが。
ZXスペクトラムとかなつかーしーなーおい。
まぁ当時ですら、VRAMに立てられたビットがどうやってブラウン管電子銃のスキャン時に特定の場所を光らせるのか、ましてやキャラクタジェネレータやスプライトのハード的仕組みを理解している人なんか殆どいなかったし、そういうのを疑問に思って勉強したくても、今よりもコストが高かったと思う。ネットのおかげで遙かに当時にくらべて技術情報はアクセスしやすくなったしなぁ。
今はHDMIインタフェースと液晶が全盛の時代になってしまったが、暴論すれば電荷を読み取って信号としておくって電極をはさんで人間の網膜に届ける光をコントロールするという意味では昔のブラウン管も液晶もプラズマも変わらんじゃんとも思う。
1a. 簡単なライブラリとかＡＰＩとかのオープンソースのやつを全部読めばよくね？例えばprintf()の中身とか。
あるいは自分で作ってみればよくね？
2. alloc()すると空きがあれば8byte確保してそのアドレスを返します。空きが無ければNULLを返します。
これくらいは自分で考えて作れるでしょ？
そういう事の積み重ねで高度なことをやってる。
1b. オブジェクト指向を知っているならカプセル化も知ってるでしょ？中身を知らなくても外のインタフェースだけ知っていれば使える。てか全ての中身を理解しようとしてたら何もアプリケーションなんて作れないです。
例えば俺ははてな匿名ダイアリーが裏でどのように動いているのかわからないけど、毎日記事を書いてる。これがカプセル化。
2a. 一般人に説明するには比喩を使うしかないでしょう。あと、その話題の領域でオブジェクト指向は関係なくね？
2b. それと、べつに「知らないことがあるけど使っている」のはITだけじゃないです。たとえば全身麻酔の原理とか最近までよくわかっていませんでした。航空力学もあんまりわかってないんじゃなかったっけ？なぜ飛行機が飛ぶのか。船も、何故かよくわからないけど速くなる装置があるんですよね。流体力学はよくわからかないです。こんぺいとうがトゲトゲになるメカニズムも解明されていない。べつにブラックボックスはＩＴだけじゃないです。
4. 例えば、長い時間をかけて改善を重ねて2015年の時点で最高の出来のWindows10が発売されたわけです。それを「今更出すな。1995年の時点でWindows10を出せ」とか言われても無理です。強くてニューゲームかよ。
テキストの説明が理解できないとき、学習者がすべきなのは自身の理解を正すことであって、自己流の解釈を思い付くことではない。つまり、
といったことをすべきなのであって、自分の腑に落ちるQiitaの記事とかを探すことは、全く理解に近づいていない。むしろ遠ざかっている。
というか、「明らかに分からない用語などがあるのに、そこを回避して全体を理解しようとする」のは、プログラミングに限らず勉強法として根本的に間違っている。
かつて、どうしても「コメント」の意味が理解できない新人がいた。
要するに彼は、プログラムの処理に関係の無い機構が存在する意味が理解できなかったらしい。
「コメントは、コードでは表現できない実装の意図をソースコード中に記述するときに用います」
などと説明してみても、
... // 15の倍数を先に判定しないと、たとえば15がFizzになってしまう if (n % 15 == 0) { return "FizzBuzz"; } else if (n % 3 == 0) { return "Fizz"; ...
「コメントは、処理をコメントアウトしてデバッグするための機構である」
と言う結論に達したようだった。勿論、普通のプログラマなら誰でも知ってるように、そういう使い方は良くない。
「プログラミング言語のあらゆる機能が、プログラムの何らかの処理と対応している」
という誤ったメンタルモデルを正すことである。それを放棄して、自分にとって都合の良い出典不明の情報を鵜呑みにしたのが、そもそもの間違いである。
こういうことは、何も新人に限った話ではない。自分では一丁前のつもりのプログラマにも、ライブラリ等の全く見当違いな使い方をしてくる奴がよくいるのである。
そういうのは、自分の経験のある別の言語の○○という機能に対応している、と勝手に思い込んでいたり、あるいは、実装とセマンティクスの区別ができず、インタフェースのような処理と直接関係ない機能が理解できなかったりする。
要するに、不明点を正しく理解することを放棄して、自分に都合の良い解釈を得て早合点しているのである。
そういう人はプログラマには向いていない。
完全に正しい多段継承でテンプレートパターン使いすぎて使い勝手最悪のライブラリを見たことがあるのでリスコフが全てだとは思わないかな。
> AをラップしたクラスA'を作り、A'とBに同じインタフェースを実装する
これは一見無駄なAを呼び出すだけのメソッドを気にしない訓練が必要。
「AをラップしたクラスA'と、BをラップしたクラスB'を作り、A'とB'に共通のインタフェースを実装する」
AにBを持たせる
class A { private B b; // 実装 }
interface IB { // Bのメソッド } class AWrapper implements IB { private A a; // 実装 } class B implements IB { // 実装 }
キチガイに刃物、ゴミプログラマに継承。危険なものは取り上げるべきだ。
オブジェクト指向プログラミングにおける継承は強力な手法であるが、これを正しく使えるプログラマは残念なことに極めて少ない。たいていの場合、継承を使うことで却ってプログラムの保守を困難にしてしまう。継承のアンチパターンの最たるものは、単なるメソッドやメンバ変数の共有のために継承を使うパターンだ。これを行うとデータが密結合になってバグの原因になり、プログラムを把握することも極めて困難になる。
そもそも、熟達したプログラマの感覚では、業務で書くアプリケーションの実装に継承を使うべき局面などほとんど無い。ライブラリ等のより低レベルな処理で仕様が確定しているものについては、継承が効果的となる場合もあるが、複雑なアプリケーションのロジックに継承を使うのはほとんどの場合、時期尚早な抽象化となる。
また、凡庸なプログラマが継承で実現したいと思うことは、ほとんどの言語でより適切な手段が存在する。
継承を誤って用いるプログラマが多いにも関わらず、実は継承の使い時ははっきりしている。以下は、一定水準のプログラマならば、誰でも答えられる質問である。これに答えられないプログラマは不勉強を恥じるべきである。
答えられない人、自分の答えが正解の内容と一致しているか即座に判断できない人は、継承を使うべきではない。医学知識ゼロの素人が外科手術をするようなものであり、非常識極まりない。
リスコフの置換原則は、オブジェクト指向の文脈で言えば、以下のようになる。
「Baseを基底クラス、DerivedをBaseの任意の派生クラスとするとき、Base型として生成されたオブジェクトをDerived型のオブジェクトに置き換えても問題なく振る舞うようにしなければならない」
ゴミプログラマが継承を使いたがる理由の99%は、以下である。
こんなもん、何も難しいこと考えずとも、以下のどちらかの方法で解決する。
わかるわかるwww。
とりあえず、Visual Studio などのIDEでできることは、Emacsは使わない。
普通の「テキストエディタ」の用途だけで使えばいいと思えば気も楽になるよ。
たまに Mac, Linux を使うとき、共通のインタフェースで複雑なカスタマイズが可能なエディタがあることがすごく助かってる。
なにしろ1984年生まれで、マウスが普及する前に生まれたエディタだ。
右手をマウスとキーボードで往復することを前提とした左手のC-c, C-v などのコピーペーストのショートカットの概念がない。
これが辛い。すごく他のアプリとかけ離れてて辛い。ここだけは脳にスイッチを作るしかない。英語と日本語おぼえるようなものだな。
あと考えてみたら、今やEmacsで使う時間の 99%は org-mode だなー。あははは。
org-mode で、Python とか Julia とかをデータと統合したりすると、Jypiter なみに柔軟なノートブックが作れる。
あとは、前のコメントにもあったが、 Lisp系とか、マイナーな関数型プログラミング言語 (Agda2とかね) はEmacsしか選択しないなー。
人間が棒上の物体を使って、平面に言葉を表現するっていう時点で、そもそも世界中の文字がだいたい線だけで構成されることは確定なんだよな
顔料だって豊富じゃないから単色で使うこと前提になる。だから文字を書くときに、色の違いは考慮されない(赤い「あ」と青い「あ」はどちらも「あ」という音を表す意味)
もちろん人間の顔だとか表情みたいな複雑な絵は誰もが書けるわけじゃないし、いちいち言葉を記すためだけにそんな面倒なもの書きたくないので、とりあえず「？」で終われば疑問文ということにして、読むときも語尾のイントネーション上げて読む。みたいな規約を作って運用しました。
これがもし入力インタフェースとして棒を使わないで、サクッとどんなに細かい絵も一瞬で書けるような時代になるとどうなるのか。
絵文字とかLINEのスタンプとかが流行ったのは必然だったのかもしれない。昔の人も本当はわざわざ言葉を文字にするのかったるかったと思う。
写真とか動画とか絵文字を瞬時に保存したり、相手にそのまま見せることができれば、それ使うのとうぜんだよな。
