  |
はてなキーワード: インタフェースとは
時代についていけてないオッサンの独り言なのだが、今のデジタル技術に閉塞感を感じている。
機械学習は論文を読んで実装してを繰り返しているが、なんせ金がなくてクラウドを使えない。
（安いクラウドくらいは書籍やネットで調べて使えているが、業務でやってる人からするとレベルは低い)
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のスタンプとかが流行ったのは必然だったのかもしれない。昔の人も本当はわざわざ言葉を文字にするのかったるかったと思う。
写真とか動画とか絵文字を瞬時に保存したり、相手にそのまま見せることができれば、それ使うのとうぜんだよな。
コーダーってのはどういう人のことを言うの？
上流会社がコードを書いてはいけないという謎ルールがある会社では、「それを書くより自分でコード書いたほうが早くない？それを見たら何の疑いもなくコードになるよね？」みたいな仕様書で発注していたという噂を聞くけれど、それをプログラムに起こすのはコーダーって感じがする。
「前にいた会社ではすぐにコードに起こせるような詳細な仕様書をもらってました」みたいな発言もコーダーって感じがするけれど、そういう認識であってるのか？
プログラム中でどのアルゴリズムやデータ構造を使うか、どのライブラリーを使うかを自分で考えて選ばないといけないとだんだんとエンジニア感が出てくるんだろうか。インタフェースなどの仕様を決めて、複数人で仕事ができるようにできているとさらにエンジニアって感じがする。チーム内どころか遠隔手続き呼び出しなどで全く知らない人も呼べるような関数の設計をするとさらにエンジニアという感じがする。
プログラミング言語を印象批評している記事に触発されて、自分も印象批評してみようと思う。
JavaScript以外にもブラウザ上でぐりぐりするのにはJava AppletとかFlashとかSilverlightとかいろいろあったけれど、結局標準化を成し遂げたHTML5に淘汰されちゃった感じがする。LiveScriptからJavaScriptに改名されたり、規格を話すときはECMA Scriptだったりといろんな別名を持つ。一応、プロトタイプベースのオブジェクト指向言語なんだけれど、それを意識してコードを書く人がどれくらいいるかは謎。
Pythonは小さいコードを書くのには楽だけど、これで大きなコードを書くと思わぬ変更で思わぬことが起きるのでつらい。しばらく使うとPythonイヤイヤ病にり患し、goを使うようになるらしいとか、ならないとか。pythonで大規模なコードを万一書こうと思うなら、カバレッジが高いテストを書いてくれと思う。
Javaは初期のころオートボクシング / アンボクシングもなく、ストイックなオブジェクト指向言語だった記憶がある。ただ、staticを多用してオブジェクト指向とは程遠いコードも簡単に書けるので、Javaで書いているからと言ってオブジェクト指向だと思うのは禁物である。
PHPはWebネイティブな言語で、初期のころHTTP POST/GETなどで渡された変数がそのままプログラム中に出てくる機能や初期化していない変数を最初に使うと空文字列あるいは0で初期化するという機能があった。また、文字列と数字を臨機応変に切り替える機能もあり(今もそうかは知らん)、数字と文字の比較を比較演算子(==)でシームレスにできる。パスワードチェックみたいなコードで===ではなく、==を使っているとPHPを知らないバカ扱いされる。
C#はHello Worldくらいしか書いたことないから知らん。monoのような互換環境があるのは知っているけれど、わざわざPC Unix上でmonoを使う気分にはなれなかった。
C++は黎明期に使った感じと、C++11以降に使った感じが驚くほど違う言語。今はかゆいところには大抵STLで手が届くし、autoを使えばイテレーションで腱鞘炎になることもない。PC Unixにも最初から環境がインストールされているか、簡単にインストールできるので毛嫌いせず使うとよいと思う。
Rubyはぎょっとする変更をよくやるというイメージ。これで書かれたプログラムを長年愛用してきたが、ぎょっとした変更を入れられて動かなくなったのでgoで書き直した。その点ではpythonも3でおいていかれたので嫌い。
TypeScriptは書いたことないから知らない。JavaScriptだと大規模コードを書くとつらいのでTypeScriptを使おうという人がいるのは知っている。大規模なコードを書くとしたら、インタフェースに合った呼び出しかコンパイル時にチェックしてくれるような強く片付けされた言語のほうがよくなってくるというのはわかる。
Cは片付けし、構造化したプログラムを書きやすくしたアセンブラ...というイメージだったんだけど、C99くらいから便利機能がいろいろ入ってそうでもない感じになった印象。昔はCのコードを見たら最適化した後のx86アセンブリが見えていたんだけれど、最近は見えなくなってしまった。子供のころ、本屋で秘伝C言語問答 ポインタ編に出会ったのがこの業界に入るきっかけだったのかもしれない。ほかの言語でいろいろ楽に書けるから、カーネルをいじるか、システムコールをたたくかするときくらいしか自分の中では出番がなくなってしまった。
これ以下のランキングのもその気になったら書こうかな。
YouTuberくらいのクオリティをなぜか前提としてるんだよな、会話してると。
映像もとりあえずウェブカムでって言ってたのが、YouTubeみたいにならないとなり、一眼レフをUSB接続とかになる。
映像は資料見始めると関係なくなるので気にならなくなるが、音声はみんな気にする。
Bluetoothでつなぐヘッドセットはダメ。接続が切れたり、認識が甘かったり。
赤と緑の端子がついたヘッドセット、もしくはスマホ付属の4極端子のヘッドセットはいまいちだが、ギリギリ。
下手に新しく2000円くらいのものを買うよりiPhone付属のものの方がよかったりする。
コンデンサマイクとポップガード＋オーディオインタフェースだと、生活音が気になる。
SM58はマイクを口元まで近づけることをあまりしないので声が遠くなる。
それ以前にマイクとの距離が長時間の会議だと、姿勢を変えるので変わって、音が大きくなったり小さくなったりする。
会議に参加している人の音量がそろっておらず、再生する側の音量を大きくしたり小さくしたり定期的にしなくちゃならない。
あと部屋の中で反響する声も消えてくれる。ただでかい。卓上のマイクスタンドだと重すぎて角度を支えきれない。
