「インタフェース」を含む日記 RSS

はてなキーワード: インタフェースとは

2021-07-12

anond:20210712140857

局所化の話はカプセル化の話やろ

動物キリンさんが出てくるのは、継承インタフェースの話やろ

なんで混ぜたん

2021-06-14

anond:20210614025554

この記事を読んで、自分もそういうのあったなぁって思ったので書いてみた。

仲間がいるように思えてちょっと嬉しい。

バイオリン

20数万円のバイオリンを買って、週1のレッスンにも通った。

でも仕事が忙しかったりで家でも練習せず、お金ももったいないなと思い始めたので辞めた。

一眼レフカメラ

写真バンバン撮って、ネットアップロードして売っちゃうぜ!

なんて考えていたけど、カメラが重いし持ち運びも不便だしで触らなくなってしまった。

ちなみに一眼レフカメラは2台(時期をずらして)買ったけど埃を被っている。

バイク

続いている趣味と言えば趣味なんだけど、数ヶ月乗らなかったりもする。

ちなみにアドベンチャータイプバイクと大型ツアラーと2台所有してる。

・車

車が趣味というより、自転車代わりにどこか近所に出かけたりするのに使ってる。

車があるからバイクに乗らなくなったとも言える気もする。

ちなみに車をいじったりとかは全然興味ない。

戦略SLGRTS

Civ系が面白いと聞いたのでやってみたけど、自分には操作が不便で面白さが分からなかった…

他にも面白そうなものとかはあったんだけど、インタフェース英語なので諦めた。

旅行

旅行行くだけで数万飛ぶし、休み潰れるしで「旅行行きたいな」って思うだけで十分なことに気がついてしまった。

小説

歳取ったせいか(30代後半)、昔ほど「この本を一気に読むぞ!」という気力も無ければ、読んでる本を途中で読んでることすら忘れてしまうことが多い。もうダメかもしれない。

ネット配信動画

面白いのとかもあるんだけど、1〜2時間ずっと見続けるってのは意外と根気が必要で、だるいなぁって思うのが先に勝ってしまう。

映画

ネット配信動画と同じ感じで、たまに映画館には行くけど、よっぽど見たいものでなければ行かなくなってしまった。

サバゲー

興味はあるし、中学生の時にちょっとやってたんだけど、身近にやる人がいないので何も手つかず。

イラスト

安いペンタブ買ったけど、もともと絵心がないのもあって埃被ってる。

ちょっと興味があるもの

アルトサックス:前からやってみたかった、楽器は高い

家庭菜園:前にも少しやってたけど、水をあげることすら忘れてしまう…

自転車:ずっとリモートワークなので運動したいか


といった具合なんだけど、いくつか副業をしていて、副業仕事からやらないといけない強制力が働いてやってる。

仕事趣味っていうとアレだけど、趣味みたいなもんなのかもしれない、働いたらお金もらえるし。

2021-05-13

anond:20210506152834

違います

オブジェクト指向の(オブジェクト指向に限らずあらゆるプログラミングパラダイムの)目的は「関心の分離」です

すなわち、

と言うことです

インスタンス化や継承はその手段ひとつであり、ポリモーフィズムはその結果生じるものです

まあしかし、メンバ変数オブジェクトインスタンスごとにスコープを持つことは、保守性に大きく寄与することは事実です

2021-02-01

anond:20210201152446

医学的な意味

なぐりころされて死ぬだろうな

ただ、安全ドキュメントを残さなものはあるが、API用のインタフェースヘッダは本物だしみればわかるように命名してある

ドキュメントを読んで信じたら事故るように作ってあるし、納品するときにはどこが意図的ミスか口頭で申し送る

 

簡単ミスではあるが、盗品と分かる仕組み

2021-01-20

時代に追いつけてないので、今のデジタル技術に閉塞感を感じてる

時代についていけてないオッサン独り言なのだが、今のデジタル技術に閉塞感を感じている。


機械学習論文を読んで実装してを繰り返しているが、なんせ金がなくてクラウドを使えない。

(安いクラウドくらいは書籍ネットで調べて使えているが、業務でやってる人からするとレベルは低い)

1回数十万~億単位の金なんて個人では無理で、RTX3090だと結果が出ない。

電気代も数万かかってしまっている。

時代に追いつこうとして取り組んでいるが、やりたいことではない。


物理が好きなので、応力、流体、電磁波光学電子といったシミュレーションがやりたいことだが、

GAFAMと呼ばれるところが良い物を出してくれるわけではないので、良くならない。

UIを作れるスキルがあればいいのだが、残念ながら古臭いインタフェースしか作れない。それにUIを作りたいわけでもない。


電子回路だとラズパイを使うよりも作りたいのだが、

オープンソース個人で買えるレベル設計ソフトでは機能が足りていないし、

USBHDMIの規格にあっているかのチェックをするハードウェア個人では買えない価格のままだ。


ゲーム配信したり、ネットフリックスを見たり、漫画電子書籍で読むといった、

時代にあった物が楽しいと思えればいいのだが、自分には合わず止めてしまった。

今の主流に乗っていて、次々と新しいものが出てくるのを楽しめていれば閉塞感も感じないのだろうが。

2021-01-15

テレワーク用のライティングマイクの話

ビデオ用のライティング

  1. 顔に当てる照明は直接向けない。白い壁に向ける。
  2. 強い光が良いわけではない。部屋の照明の補助的な光で影を消す
  3. からの光は人の目には違和感がある(お化けライト)。斜め上から光を当てて、首に影を落とす。
  4. 光源は大きければよい。顔の1.5倍くらいの大きさがあれば影が消え始める。小さい光源はほうれい線などが目立つ。小さい照明でも壁に当てれば大きな光源に近づく。
  5. ディスプレイも照明の代わりになる。外付けのUSBカメラを大きなディスプレイ(43インチとか)の手前、画面中央に置くのがライティング的にはいい。(画面がカメラに隠れてしまうが)


マイクの話

  1. よくわからないならUSBヘッドセットを買って、マイクの先端にウインドマフをつければいい。
  2. YouTuberが卓上マイクアームにおいてるかもしれないが、マイクと口との距離が変わったら音量が変わる。ヘッドセットかピンマイクだと口との距離が変わらない。
  3. ピンマイクは手を動かすと服がこすれるてノイズになることがある。
  4. 無線マイクは楽かもしれないが、1時間とかの会議中に途切れたりする。有線がいい。(曲の場合ヘッドセット側にバッファもっておけばいいが、リアルタイムだと通信途切れたら音も途切れる)
  5. マイクは口に近づけ過ぎると近接効果や、ペチャという唾の音までマイクに乗る。遠すぎると声と背景ノイズとの差がなくなってSNが悪くなる。適正な距離がある。
  6. ダイナミックマイクコンデンサーマイク、ガンマイクなど色々あり、単一指向性だと一方向からしか音を拾わずノイズ対策になる。ただしマイクの向きに注意する必要がある。
  7. 単一指向マイク説明書確認すること。前だろと思ったら違う場合がある。向きが違うと声が小さいとか言われることになる。
  8. 会議全員の音量が揃わないと聞き取りにくい。1人だけ高いマイクオーディオインタフェースを使って音量を上げても意味はない。
  9. VSTプラグインは他が出来てから導入する
  10. ゲインは音を録音して、波形が振り切れてない(クリップされてない)くらいのゲインがいい。背景の小さい音はノイズゲートプラグインで切るためにも

2020-12-17

anond:20201216122259

関係を結んだ相手と密結合したいって思うのは、女の性だから仕方ないよね。

「夫のコレクション」というプライベートメンバー勝手アクセスして、勝手例外コケて、

挙句勝手にそれをDisposeしようとしては例外でこけて、関係強制終了させるってオチか。

から、既婚と独身、子ありと子持ちの関係例外吐きまくって落ちるのか、女の人間関係って奴は。

幸せ」っていうインタフェースを作れば疎結合にできて、文字通り「幸せ」になれるのに。

2020-12-02

anond:20201202050739

ZXスペクトラムとかなつかーしーなーおい。

まぁ当時ですら、VRAMに立てられたビットがどうやってブラウン管電子銃のスキャン時に特定場所を光らせるのか、ましてやキャラクタジェネレータやスプライトハード的仕組みを理解している人なんか殆どいなかったし、そういうのを疑問に思って勉強したくても、今よりもコストが高かったと思う。ネットのおかげで遙かに当時にくらべて技術情報アクセスやすくなったしなぁ。

今はHDMIインタフェース液晶が全盛の時代になってしまったが、暴論すれば電荷を読み取って信号としておくって電極をはさんで人間網膜に届ける光をコントロールするという意味では昔のブラウン管液晶プラズマも変わらんじゃんとも思う。

2020-12-01

anond:20201130214610

1a. 簡単ライブラリとかAPIとかのオープンソースのやつを全部読めばよくね?例えばprintf()の中身とか。

あるいは自分で作ってみればよくね?

例えば、初歩的な動的メモリ管理をするアルゴリズムとか。

 1. 64byteの領域があります

 2. alloc()すると空きがあれば8byte確保してそのアドレスを返します。空きが無ければNULLを返します。

 3. free()すると確保したメモリ解放します。

 これくらいは自分で考えて作れるでしょ?

 そういう事の積み重ねで高度なことをやってる。

1b. オブジェクト指向を知っているならカプセル化も知ってるでしょ?中身を知らなくても外のインタフェースだけ知っていれば使える。てか全ての中身を理解しようとしてたら何もアプリケーションなんて作れないです。

例えば俺ははてな匿名ダイアリーが裏でどのように動いているのかわからないけど、毎日記事を書いてる。これがカプセル化

2a. 一般人説明するには比喩を使うしかないでしょう。あと、その話題領域オブジェクト指向関係なくね?

2b. それと、べつに「知らないことがあるけど使っている」のはITだけじゃないです。たとえば全身麻酔原理とか最近までよくわかっていませんでした。航空力学あんまりわかってないんじゃなかったっけ?なぜ飛行機が飛ぶのか。船も、何故かよくわからないけど速くなる装置があるんですよね。流体力学はよくわからかないです。こんぺいとうがトゲトゲになるメカニズムも解明されていない。べつにブラックボックスはITだけじゃないです。

4. 例えば、長い時間をかけて改善を重ねて2015年の時点で最高の出来のWindows10が発売されたわけです。それを「今更出すな。1995年の時点でWindows10を出せ」とか言われても無理です。強くてニューゲームかよ。

2020-11-18

愚かなプログラミング学習

テキスト説明理解できないとき学習者がすべきなのは自身理解を正すことであって、自己流の解釈を思い付くことではない。つまり

といったことをすべきなのであって、自分の腑に落ちるQiita記事とかを探すことは、全く理解に近づいていない。むしろ遠ざかっている。

というか、「明らかにからない用語などがあるのに、そこを回避して全体を理解しようとする」のは、プログラミングに限らず勉強法として根本的に間違っている。

かつて、どうしても「コメント」の意味理解できない新人がいた。

要するに彼は、プログラムの処理に関係の無い機構存在する意味理解できなかったらしい。

コメントは、コードでは表現できない実装意図ソースコード中に記述するときに用います

などと説明してみても、

...
// 15の倍数を先に判定しないと、たとえば15がFizzになってしまう
if (n % 15 == 0) {
    return "FizzBuzz";
} else if (n % 3 == 0) {
    return "Fizz";
...

みたいな簡単な例を示しても、一向に理解できない。

結局彼は、ネット解説記事をググった挙げ句に、

コメントは、処理をコメントアウトしてデバッグするための機構である

と言う結論に達したようだった。勿論、普通プログラマなら誰でも知ってるように、そういう使い方は良くない。

彼が本来すべきだったことは、まず

プログラミング言語のあらゆる機能が、プログラムの何らかの処理と対応している」

という誤ったメンタルモデルを正すことである。それを放棄して、自分にとって都合の良い出典不明情報鵜呑みにしたのが、そもそもの間違いである。

こういうことは、何も新人に限った話ではない。自分では一丁前のつもりのプログラマにも、ライブラリ等の全く見当違いな使い方をしてくる奴がよくいるのである

そういうのは、自分経験のある別の言語の○○という機能対応している、と勝手に思い込んでいたり、あるいは、実装とセマンティクスの区別ができず、インタフェースのような処理と直接関係ない機能理解できなかったりする。

要するに、不明点を正しく理解することを放棄して、自分に都合の良い解釈を得て早合点しているのである

そういう人はプログラマには向いていない。

2020-10-22

anond:20201022005749

完全に正しい多段継承テンプレートパターン使いすぎて使い勝手最悪のライブラリを見たことがあるのでリスコフが全てだとは思わないかな。

継承より委譲には賛成。

> AをラップしたクラスA'を作り、A'とBに同じインタフェース実装する

これは一見無駄なAを呼び出すだけのメソッドを気にしない訓練が必要

言語レベルで簡潔な記述サポートしてくれてたらうれしいけど。

anond:20201022005749

多くの場合後者方法が、もっと言えば

「AをラップしたクラスA'と、BをラップしたクラスB'を作り、A'とB'に共通インタフェース実装する」

のがベストプラクティスではないか

コード量は増えるが、外部に副作用を及ぼさない限り、ゴミコードはA'とB'内で閉じている。

anond:20201022005749

AにBを持たせる

class A {
    private B b;
    // 実装
}

AをラップしてBと共通インタフェース実装する

interface IB {
    // Bのメソッド
}

class AWrapper implements IB {
    private A a;
    // 実装
}

class B implements IB {
    // 実装
}

継承禁止するべき

キチガイ刃物ゴミプログラマ継承危険ものは取り上げるべきだ。

オブジェクト指向プログラミングにおける継承は強力な手法であるが、これを正しく使えるプログラマは残念なことに極めて少ない。たいていの場合継承を使うことで却ってプログラム保守を困難にしてしまう。継承アンチパターンの最たるものは、単なるメソッドやメンバ変数の共有のために継承を使うパターンだ。これを行うとデータが密結合になってバグの原因になり、プログラムを把握することも極めて困難になる。

そもそも熟達したプログラマ感覚では、業務で書くアプリケーション実装継承を使うべき局面などほとんど無い。ライブラリ等のより低レベルな処理で仕様が確定しているものについては、継承効果的となる場合もあるが、複雑なアプリケーションロジック継承を使うのはほとんどの場合、時期尚早な抽象化となる。

また、凡庸プログラマ継承で実現したいと思うことは、ほとんどの言語でより適切な手段存在する。

継承を使う資格があるか、一発で判定できる質問

継承を誤って用いるプログラマが多いにも関わらず、実は継承の使い時ははっきりしている。以下は、一定水準のプログラマならば、誰でも答えられる質問である。これに答えられないプログラマ不勉強を恥じるべきである

問題
継承を使うべき/使ってもよいのは、どのようなときですか。
正解
リスコフの置換原則を満たすときリスコフの置換原則 - Wikipedia

答えられない人、自分の答えが正解の内容と一致しているか即座に判断できない人は、継承を使うべきではない。医学知識ゼロ素人外科手術をするようなものであり、非常識まりない。

リスコフの置換原則は、オブジェクト指向文脈で言えば、以下のようになる。

Baseを基底クラス、DerivedをBase任意派生クラスとするときBase型として生成されたオブジェクトをDerived型のオブジェクトに置き換えても問題なく振る舞うようにしなければならない」

問題なく振る舞う」というのは、以下のことを意味する。


継承を用いないやり方

ゴミプログラマ継承を使いたがる理由の99%は、以下である

こんなもん、何も難しいこと考えずとも、以下のどちらかの方法解決する。

AからBの機能を用いる場合は前者を、Aを変更できないがBと同じインタフェースを持たせたい場合後者を使えばいい。

2020-10-21

センスの無い奴はプログラマにならないでくれ

インタフェース型を呼び出すと、それをimplementするクラスメソッドが増えたときインタフェースクラスの両方にメソッドを追加しないといけないけど、クラス型なら基底クラスメソッドを追加するだけでいいから、基本的クラス継承させるべき。

こういう馬鹿プログラマやめろ。

2020-10-01

anond:20201001003053

ていうか 3D を扱うコントローラって十字とジョイスティックでいいの? それって本当にスーパーマリオブラザーズときくらい考えた結果なの? とか思う。

今は表示デバイスの都合上、立体視3D なんて言ったりしているけれど、そのうち人間が動いた先にホログラフされる手がある。もう少し時代が下れば、さわれるかもしれない。その時のインタフェースは、この十字キージョイスティックなの? と思う。任天堂には未来を見ていて欲しいのに目先の利益ひゃくぱーなソシャゲ業界と関わったせいで百年の歴史を失おうとしている。

ごめん元増田とはあまり関係なかったかも。

2020-09-21

anond:20200921040234

わかるわかるwww

とりあえず、Visual Studio などのIDEでできることは、Emacsは使わない。

普通の「テキストエディタ」の用途だけで使えばいいと思えば気も楽になるよ。

自分Windows用のEmacsしか使ってない。

たまに Mac, Linux を使うとき共通インタフェースで複雑なカスタマイズ可能エディタがあることがすごく助かってる。

なにしろ1984年まれで、マウスが普及する前に生まれエディタだ。

右手マウスキーボードで往復することを前提とした左手のC-c, C-v などのコピーペーストショートカット概念がない。

これが辛い。すごく他のアプリとかけ離れてて辛い。ここだけは脳にスイッチを作るしかない。英語日本語おぼえるようなものだな。

あと考えてみたら、今やEmacsで使う時間の 99%は org-mode だなー。あははは。

org-mode で、Python とか Julia とかをデータ統合したりすると、Jypiter なみに柔軟なノートブックが作れる。

あとは、前のコメントにもあったが、 Lisp系とか、マイナー関数型プログラミング言語 (Agda2とかね) はEmacsしか選択しないなー。

まーでも無理に使う必要はないよ。あくまでも道具なんで、必要な時期に必要な部分だけ覚えればいいので。

2020-07-23

日本半導体チップの実設計説明した資料いね

CPUだと注目されるわりに、実際の設計までの解説はないし。

テストベンチの触りはあるけど、LINTやフォーマル検証をやってるのを見たことがない。

ソフトウェアから見たというか、コンパイラ作る人がアセンブラ見たりチューニングするためのアーキ解説は沢山ある。

日本だとフリーソフトのVerilatorを使ってる人も何人いるんだろうって感じ。次はVivadoとか。


富岳のCPUもよく作れたよね。フロントエンド部分とインタフェース部分くらいしか触れないというか、余力なさそうに見えちゃうけど。

PFNもMN-Core作ったけど、論理設計だけで物理設計以降は台湾企業のアルチップだし。


いつまでもアメリカが売ってくれればいいのだけど。

2020-07-21

絵文字が増えたのって筆記しなくていいか

人間が棒上の物体を使って、平面に言葉表現するっていう時点で、そもそも世界中文字がだいたい線だけで構成されることは確定なんだよな

顔料だって豊富じゃないから単色で使うこと前提になる。だから文字を書くときに、色の違いは考慮されない(赤い「あ」と青い「あ」はどちらも「あ」という音を表す意味)

もちろん人間の顔だとか表情みたいな複雑な絵は誰もが書けるわけじゃないし、いちいち言葉を記すためだけにそんな面倒なもの書きたくないので、とりあえず「?」で終われば疑問文ということにして、読むときも語尾のイントネーション上げて読む。みたいな規約を作って運用しました。

これがもし入力インタフェースとして棒を使わないで、サクッとどんなに細かい絵も一瞬で書けるような時代になるとどうなるのか。

絵文字とかLINEスタンプとかが流行ったのは必然だったのかもしれない。昔の人も本当はわざわざ言葉文字にするのかったるかったと思う。

写真とか動画とか絵文字を瞬時に保存したり、相手にそのまま見せることができれば、それ使うのとうぜんだよな。

おじさんは若者迎合していると思われるのが怖くて今でも絵文字使うの怖いです。よくSlackとか使ってられるよな

2020-06-25

アメリカ企業はなんで大規模なシステムを組めるのか

F-35のような軍用機をはじめ、大規模なシステムを組むことができている。

ハード的にも、ソフト的にも。

あれが不思議で仕方ない。

半導体を作っていると、小さい部品でもインタフェース間で注意しないといけないことが多く、ある程度の規模からより大きくできない。

エンジニア力と言われればそれまでかもしれないが。

もちろんシミュレーション確認するが、大規模になるとモデルの精度を下げて対応する必要に迫られるが、ある段階で物理特性からかけ離れて使い物にならなくなる。

計算機リソースも足りなくなる。

エンジニアが使えるリソース量が根本的に違うのだろうか。

2020-06-08

anond:20200608044631

あなたこそメモリが最重要だと言うだけで何も根拠を示さないよね。

とにかく重要から黙って金を寄こせとしか聞こえないよ。

あ、あとね、NVDIMMだとかNVMeとか、チップじゃなくてメモリモジュールインタフェース話がしたかったの?

2020-05-30

anond:20200530051548

コーダーってのはどういう人のことを言うの?

上流会社コードを書いてはいけないという謎ルールがある会社では、「それを書くより自分コード書いたほうが早くない?それを見たら何の疑いもなくコードになるよね?」みたいな仕様書発注していたという噂を聞くけれど、それをプログラムに起こすのはコーダーって感じがする。

「前にいた会社ではすぐにコードに起こせるような詳細な仕様書をもらってました」みたいな発言コーダーって感じがするけれど、そういう認識であってるのか?

プログラム中でどのアルゴリズムデータ構造を使うか、どのライブラリーを使うかを自分で考えて選ばないといけないとだんだんエンジニア感が出てくるんだろうか。インタフェースなどの仕様を決めて、複数人仕事ができるようにできているとさらエンジニアって感じがする。チーム内どころか遠隔手続き呼び出しなどで全く知らない人も呼べるような関数設計をするとさらエンジニアという感じがする。

ほかの増田たちはどの辺がコーダーでどの辺がエンジニアなの?

2020-05-22

anond:20200521225730

プログラミング言語を印象批評している記事に触発されて、自分も印象批評してみようと思う。

JavaScript以外にもブラウザ上でぐりぐりするのにはJava AppletとかFlashとかSilverlightかいろいろあったけれど、結局標準化を成し遂げたHTML5に淘汰されちゃった感じがする。LiveScriptからJavaScript改名されたり、規格を話すときECMA Scriptだったりといろんな別名を持つ。一応、プロトタイプベースオブジェクト指向言語なんだけれど、それを意識してコードを書く人がどれくらいいるかは謎。

Pythonは小さいコードを書くのには楽だけど、これで大きなコードを書くと思わぬ変更で思わぬことが起きるのでつらい。しばらく使うとPythonイヤイヤ病にり患し、goを使うようになるらしいとか、ならないとか。pythonで大規模なコードを万一書こうと思うなら、カバレッジが高いテストを書いてくれと思う。

Javaは初期のころオートボクシング / アンボクシングもなく、ストイックオブジェクト指向言語だった記憶がある。ただ、staticを多用してオブジェクト指向とは程遠いコード簡単に書けるので、Javaで書いているからと言ってオブジェクト指向だと思うのは禁物である

PHPWebネイティブ言語で、初期のころHTTP POST/GETなどで渡された変数がそのままプログラム中に出てくる機能初期化していない変数最初に使うと空文字列あるいは0で初期化するという機能があった。また、文字列数字臨機応変に切り替える機能もあり(今もそうかは知らん)、数字文字比較比較演算子(==)でシームレスにできる。パスワードチェックみたいなコードで===ではなく、==を使っているとPHPを知らないバカ扱いされる。

C#Hello Worldくらいしかいたことないから知らん。monoのような互換環境があるのは知っているけれど、わざわざPC Unix上でmonoを使う気分にはなれなかった。

C++黎明期に使った感じと、C++11以降に使った感じが驚くほど違う言語。今はかゆいところには大抵STLで手が届くし、autoを使えばイテレーション腱鞘炎になることもない。PC Unixにも最初から環境インストールされているか簡単インストールできるので毛嫌いせず使うとよいと思う。

Rubyはぎょっとする変更をよくやるというイメージ。これで書かれたプログラムを長年愛用してきたが、ぎょっとした変更を入れられて動かなくなったのでgoで書き直した。その点ではpythonも3でおいていかれたので嫌い。

CSS...はプログラミング言語なのか?そうか。

TypeScriptは書いたことないから知らない。JavaScriptだと大規模コードを書くとつらいのでTypeScriptを使おうという人がいるのは知っている。大規模なコードを書くとしたら、インタフェースに合った呼び出しかコンパイル時にチェックしてくれるような強く片付けされた言語のほうがよくなってくるというのはわかる。

Cは片付けし、構造化したプログラムを書きやすくしたアセンブラ...というイメージだったんだけど、C99くらいから便利機能がいろいろ入ってそうでもない感じになった印象。昔はCのコードを見たら最適化した後のx86アセンブリが見えていたんだけれど、最近は見えなくなってしまった。子供のころ、本屋で秘伝C言語問答 ポインタ編に出会ったのがこの業界に入るきっかけだったのかもしれない。ほかの言語でいろいろ楽に書けるからカーネルをいじるか、システムコールをたたくかするときくらいしか自分の中では出番がなくなってしまった。

これ以下のランキングのもその気になったら書こうかな。

ログイン ユーザー登録
ようこそ ゲスト さん