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

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

2024-03-12

建設API

建設的AsokohaPantunoInterface(けんせつてきあそこはパンツインターフェイス

2024-02-19

[] モジュール

コードを簡潔に保つにはモジュール化が必須であるしかし同じモジュール関係のない機能が含まれていたりすると混乱の元になる。

モジュール内の関数機能的関連性は凝集度という。

一方で、関数というのは引数の細かな仕様依存せずに、汎用的に呼び出せた方が何かと好都合だ。引数になんらかのオブジェクトを渡し、そのオブジェクトしか持ち得ないような特殊情報で処理を行なったりすると、関数オブジェクトが互いに依存しあってしまう。

これはモジュールの結合度と呼ぶ。

高い凝集度、低い結合度によってモジュールを作れば、保守性は上がる。

さらモジュール内では、公開する必要のない関数はprotectedまたはprivateにするべきだ。

そのためにはモジュールが公開すべき関数についてインターフェイスを作り、公開関数に対するユニットテストを書いておくのが良いだろう。

2024-01-31

[]メイン関数の書き方

メイン関数では主要な処理をざっと実行する。このときに、以下を気をつけると保守性が高くなる。

こうすると、自然言語を読むような形でコードを読めるようになり、技術的詳細は隠蔽するので、担当者をわかりやすく分離することができる。

2024-01-22

anond:20240122111105

適切な粒度関数を分割しとけば生産性上がるけどね。

module_name.pyみたいなモジュールごとにファイル分割して、インターフェイスだけ公開してその他はdef _funcみたいにprotected(or private)にしとく。

でも「共通性がありそうだから共通関数にする」はアンチパターンだな。たまたま共通してただけの場合分岐コードが増えて共通関数保守コストが上がる。

あとありがちなのは、php開発者関数分割しないですべてメインコードにべた書きするケース。こういうのはやめないと保守が大変。

とっておきのクズがやりがちなのは、神オブジェクトを作るとかだな。Userクラスフィールド関係する機能が多いからといって、コンポジションなどによるクラス分割をせずにユーザークラスにあらゆるフィールドメソッドを追加して、さらに進むとユーザーとは無関係機能も含めすべてをユーザークラス定義するアフォ。こうなってしまったら、後から修正するのが難しくなる。

先に手を打つことが、プログラマーの素質「怠惰」につながるのであり、面倒臭いといって後回しにするのは美徳でもなんでもない。

2023-12-14

コミュニケーション能力冪等性

https://x.com/nwxksjphozj0vpw/status/1734573090070561274

2023-12-12

「ChatGPTの核心はWebインターフェイスだ!」とかカスなことを言う程度の知能のアホが「日本技術は落ち込んでいる」なんて馬鹿なことを言うから困ったものだ😥

anond:20231212110708

ChatGPTって普通は「OpenAIが行った事前学習済みモデル」と思うで

コードインターフェイスもどうでもええやん

anond:20231212103459

からお前は素人って言われるんだよ。

ウェブなんて入出力のインターフェイスに過ぎねえんだよボケ

ChatGPT is fine-tuned from GPT-3.5, a language model trained to produce text.

https://help.openai.com/en/articles/6783457-what-is-chatgpt

OpenAI ChatGPT is a language model developed by OpenAI that is built on the GPT (Generative Pre-trained Transformer) architecture.

https://dzone.com/articles/comprehensive-guide-on-integrating-openai-chatgpt

はい論破

2023-12-06

回転寿司おもんなくなったな

俺は回転寿司基本的に注文せずにレーン流れてくる寿司を取って食うスタイル

なんやこれ?wと思ったやつは必ず食うようにしてたんよね。

回転寿司面白さってそういうちょっとした出会いだと思ってたからさ。

本屋行ってうろうろ棚見てたらちょっと面白そうなタイトル見つけて買っちゃうみたいな。

注文して食うんやったら普通カウンター立ち食い寿司でもいけばええんやし。

でもなんか最近ほとんど寿司回ってないし、

みんな注文しかしないからついでに自分の分も頼んでもらうようになったし

なんか回転寿司わざわざ行く意味なくなったなってなっちゃった

注文のタッチパネルインターフェイス微妙操作ストレスもムカつくし

2023-11-16

anond:20231116115013

お前のいう通り書いたったわ(C#だが)。

非常に稚拙コードで悪いが。

八百万の神スーパークラスがある場合

//宇宙
namespace Universe
{
    //あらゆる神の根底存在する唯一神とその司る運(スーパークラス)
    public class GodLuck
    {
        public string Name { get; }   //神の名前
        public string Power { get; }  //神の力
        public string Plan { get; }   //神の計画
        public string Factor { get; } //運の要因

        public GodLuck(string name, string power, string plan, string factor)
        {
            Name = name;     //神の名前
            Power = power;   //神の力
            Plan = plan;     //神の計画
            Factor = factor; //運の要因
        }

        //神が何かを創造するメソッド
        public void Create(string thing)
        {
            Console.WriteLine($"{Name} created {thing}.");
        }

        //神が何かに対して支配や介入をするメソッド
        public void Control(string thing, string action)
        {
            Console.WriteLine($"{Name} {action} {thing}.");
        }

        //運が何かに対して影響を与えるメソッド
        public void Affect(string thing, string outcome)
        {
            Console.WriteLine($"{Name} affected {thing} and the outcome was {outcome}.");
        }
    }

    //恵比須様
    public class EbisuSama : GodLuck
    {
        public EbisuSama()
            : base("恵比須様",
                   "商売繁盛や五穀豊穣の力",
                   "人々に幸せを与える計画",
                   "商売繁盛や五穀豊穣の要因")
        {
        }

        //作物を守る
        public void Save(string crops)
        {
            Control(crops, "守る");
        }

        //人間成功させる
        public void MakeSuccessful(string person)
        {
            Affect(person, "成功");
        }
    }
}

↓IGodLuckというインターフェース実装した場合

(大いなる力を別のクラス移譲したくなったが、神と大いなる力は同一のオブジェクトという要件があるからやめた)

//宇宙
namespace Universe
{
    //神の振る舞いを定義したインターフェイス
    public interface IGodLuck
    {
        public string Name { get; }
        public string Power { get; }
        public string Plan { get; }
        public string Factor { get; }

        //神が何かを創造するメソッド
        public void Create(string thing);

        //神が何かに対して支配や介入をするメソッド
        public void Control(string thing, string action);

        //運が何かに対して影響を与えるメソッド
        public void Affect(string thing, string outcome);
    }

    //恵比須様
    public class EbisuSama : IGodLuck
    {
        public string Name { get; }   //神の名前
        public string Power { get; }  //神の力
        public string Plan { get; }   //神の計画
        public string Factor { get; } //運の要因

        public EbisuSama()
        {
            Name = "恵比須様";                   //神の名前
            Power = "商売繁盛や五穀豊穣の力";    //神の力
            Plan = "人々に幸せを与える計画";     //神の計画
            Factor = "商売繁盛や五穀豊穣の要因"; //運の要因
        }

        //神が何かを創造するメソッド
        public void Create(string thing)
        {
            Console.WriteLine($"{Name} created {thing}.");
        }

        //神が何かに対して支配や介入をするメソッド
        public void Control(string thing, string action)
        {
            Console.WriteLine($"{Name} {action} {thing}.");
        }

        //運が何かに対して影響を与えるメソッド
        public void Affect(string thing, string outcome)
        {
            Console.WriteLine($"{Name} affected {thing} and the outcome was {outcome}.");
        }

        //物を守る
        public void Save(string thing)
        {
            Control(thing, "守る");
        }

        //人間成功させる
        public void MakeSuccessful(string person)
        {
            Affect(person, "成功");
        }
    }
}

2023-11-15

オブジェクト指向人類の退化の象徴

オブジェクト指向とかかっこいい言い方をしても無駄だ。従来の構造プログラミングから進歩したことなど一つもない。オブジェクト指向がなぜダメであるのか、それを今から話すぜ。

 

1. データと処理をまとめるという発想。

データと処理をまとめてクラスとして置くという発想がある。しかし、このようなことをしなくとも、モジュールという単位で利用データと処理の集合をまとめればよかったので、クラスを使う必要はない。しかクラスインスタンス化のときに、不要情報まで持ってくるのでメモリ効率が明らかに悪い。コンピュータ進化しているかメモリのことはあまり考える必要がないとはいえ必要ない処理をまとめて閉じ込めるのは無駄が多い。なぜクラスという名詞概念分類できると考え始めたのかは不明だが、アルゴリズムデータ構造という構造プログラミング手法を、クラスと型というパラダイムに変換することで型にうるさいC++馬鹿を生み出し、彼らが発狂することになってしまった。しかデータと処理にわざわざ依存関係を持たせて、変更に対する柔軟性を失わせている。

 

2. 継承

継承によって既存構造を持ってこようとする必要性が全く無い。それどころか、継承を使うことによってプログラムスパゲティ化し、依存関係グラフがややこしくなってしまう。継承など使わず必要情報スコープの限られた共通変数、または関数引数として用意しておけば良い。もしクラスをどうしても使いたければ、共通インターフェイスをもたせたほうがマシであるインターフェイスを使えば、クラス利用者意識すべきpublicメソッドがなんであるか把握できる。

 

3. カプセル化

オブジェクト指向の中で役立つ概念カプセル化だけであるしかし、カプセル化クラスなしで構造プログラミング方法実装できる。pythonでは、モジュールの中でアンダースコアから始まる関数を用意しておけば、それがprotectedやprivateと似たように機能させることができる。オブジェクト指向がなぜカプセル化独自概念だと言い始めたかは謎。

 

4. ポリモーフィズム

同じ名前メソッドを、入力に応じて処理の内容を変える。このようなことはオブジェクト指向などと誇大宣伝をするほどのことでもない。構造プログラミングで似たようなことができる。

2023-10-19

anond:20231019134259

プログラマだけど昔はインターフェイスパソコン用に作ってたんだよね

最近スマホメインなのでそっちで見やすいのを作んなきゃいけない

長文をパソコンで読むにはもちろん句読点あった方が読みやすいんだけど

最近スマホメインなので長い行を句読点で区切るとスマホで読むと読みにくいのよ

2023-10-07

anond:20231007002935

呼び出したいfunction呼び出すために複数のfunctionを呼び出してパラメータを用意するって意味不明だわ

こういうこと?

f_root(param1, param2): _f_inner1(param1); _f_inner2(param2);

こういうことをすることは多々あるよ。ただ、_f_innerはprivate属性をつけるのがセオリー。なぜこういうprivate関数を作るかというと、論理的意味のある部分をまとめれば保守性と開発効率が上がるから

ただインターフェイスとして公開する部分はf_rootだけだから、_f_innerを設計要件に入れるのはイミフやけど。

2023-09-26

検索エンジンの仕組み

技術的な内容を増田に書くという実験のために、試しに検索エンジンの仕組みについて書く。

検索エンジンは、大雑把に言ってクロールするパート、インデクシングするパート検索インターフェイスを出力するパートに分かれる。

インデクシング時に使っている基本手法は「転置インデックス」と呼ばれ、文書内のngramを文書ID対応付ける辞書を保存する。

インデクシングの別の種類としては、文書エンコーダからベクトルへ変換し、それを近似最近検索できるようにするものもある。

インデクシングされたものキーワードマッチ的に絞り込まれると、さらに精密な手法が使われる。

クエリドキュメントから特徴量設計し、関連性の高いものを引っ張るような訓練をする方法はLearning to rankという。

Learning to rankの中に使われる特徴量の一つにPage Rankがあるが、これは初期の検索エンジン画期的とされた量で、「リンクされるページの価値は高い」「高価値ページにリンクされると価値が高い」という基準からマルコフ連鎖計算する。

Page Rankは人間論文評価するときと似たような評価手順であるとされる。

Learning to rankの中にエンコーダからベクトルを特徴量として組み込むことも可能であり、そのようなエンコーダの初期の例がBERTである

こうやって絞り込まれ文書に対して、さら有用情報を表示するモデルがいくつか使われる。

情報抽出モデルでは、クエリ質問と見做してその回答を文書から抽出することがある。

あるいはクエリ人物名や組織名場所名などであれば、そのエンティティの詳細情報データベースから取得することもでき、これはナレッジグラフとも呼ぶ。

2023-08-25

anond:20230823170620

まぁでも、月額2000以下でU-NEXT並みのコンテンツから悪くないか

ただインターフェイスがそのまんまどっかのパクりみたいな奴で使いづらいのなんとかならんかな。

2023-06-15

LGBTQQIAAPPO2S をオブジェクト指向表現すると

どういう構造になるんだろう。

 

とりあえず、orientation と identity のプロパティがあるのは確定だろうけど、それが持つ値を gender インターフェイス定義しなきゃいけないよな。

さらには現在の体の状態も持つ必要もあって、それは gender とは違うインターフェイスになるだろ?

アセクシャル場合、orientation はnull値だろうからnullableにする必要があり、バイのことを考えるとリスト表現する必要もある。

 

どこかに完全版を作った人いないかね。

2023-05-07

プログラミング歴5年目にしてやっと抽象性を手に入れた

継承インターフェイスといわれるやつ

今までプログラム丁寧に書いてればバグとか起きるわけねえだろwと思ってたけど、

処理分けする部分の抽象度高めて、インスタンス部分時点で保持するものをかえて、同一の呼び出しで、条件次第で、内部処理を変更するみたいなことやりだしたら、脳内で完全には処理追いきれなくなってバグあるかもなみたいな状態になってる

動物は鳴くからAnimal継承させて、鳴くを呼び出すみたいなのってわかりやすいように見えて人間にはわかりにくいよね

IF文ほど人類になじみがない

2023-04-26

anond:20230426171307

昔はダイヤル型のインターフェイスが多かったんだよ。

からぐるぐる回さないといけなかった。

2023-04-19

anond:20230419043607

ChatGPTはメアドだけで使えるWebインターフェイスなので若干の防壁が張ってある印象、特に3.5

なんかもうアホみたいに厳しいのがBing

2023-04-17

anond:20230416230307

ChatGPT4はありそうだが存在しない

GPT3.5(技術名、正式にはGPT-3.5)

GPT4(技術名、正式にはGPT-4)

・ ChatGPT(3.5も4も使えるWebサイトインターフェイス名)

・ ChatGPT Plus(月額200ドルを払うとChatGPTGPT-4が使えるサービス名。課金しても3時間に25回しか使えない)

2023-03-20

anond:20230320105638

ルー大○「ステューピッドにもユーズできるインターフェイスになってるのに、それ以下のオールドガイを『インクルージョンしろ』ってどうやるんだ?いや権力者オールドガイがソサエティクリエティティインクルージョンしてないのか?」

2023-03-15

anond:20230315102654

そうだね。ただAI自分で目と耳と口がついているわけではないので、インターフェイスとしてリアル情報入力する人間という存在が不可欠。

そのリアル情報入力して個別具体的な場面でAIを動かす環境を構築する人間必要になる。

従来よりもかなり人は不要になるだろうけど、手軽になる事で需要は伸びるから上手くやればいける。

2023-03-13

anond:20230313180246

10GBのLAN とか、RS232Cあたりが定番

RAIDM2、他欲しいインターフェイスがあれば、それで。

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