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

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

2024-04-19

ODBC…?

三流SEを15年以上やってるんだけどこの言葉初めて聞いた・・・

システム関連やっている人おる?

この概念インターフェース?はシステムサイドだと常識レベルなの?

2024-04-18

アーキ設計者かわいそう

「こんなん高すぎる!」

「ここのインターフェースがないからクソ!インターフェース追加するやで」

「標準ってあくまでも標準だよね?うちが管理するから独自仕様使うわ」

現場が好き勝手アーキをレ◯プしてもう原型がなくなってもうた

ただ、正直元のアーキクソだったから痛快でもある(ワイは現場で働いとる)

2024-04-04

ダークパターンがアウトならソシャゲなんて全部アウトにならないか

行為強制

ギルドレイドのシステムによって強くならないと仲間に迷惑がかかると思い込ませる。

プレイするためにグーグルプレイDMMアカウント必須

インターフェース干渉

宝箱を開ける時に課金して鍵を買う方が目立つようなUIにする。

ゲーム起動と同時に最新ガチャ情報を画面いっぱいに表示して強調。

執拗な繰り返し

閉じても閉じても次々に出てくる新作ガチャの告知。

ガチャ告知が毎日1回は再表示される。

緊急性

期間限定ガチャ限定キャラクター(復刻なし)。

妨害

引退すると抜け忍扱いされて信者ファンネルに襲われたりリアフレとの関係悪化する。

スニーキング

引退したゲームのサブスク引き落としに気づかずに月チケを買い続けてしまう。

社会的証明

◯◯◯万DL達成!今なら◯回ガチャ無料

2024-04-01

anond:20240401153135

そもそもエンジニアじゃないじゃん

エンジニアなの?

ただの決めつけだし、対人論証ですね

Rustでは、pubで可視管理管理してカプセル化し、データ構造定義し、traitでデータ構造に対する操作インターフェース定義し、

ジェネリクストレイオブジェクトを使ってさまざまなデータに対して多相で処理を提供することが一般的です

「RustはOOPじゃないし」に対する反論としてはこちらの方が重要であり、私がエンジニアであるかどうか、どのようなプロダクトを書いたかなどはノイズしかなく、答える必要も、考える必要もありません

anond:20240401152026

今Rust使ってるのはよっぽど意識高い系ベンチャーGAMかってくらいなのよ

5年前ならともかく、今は全然そんなことはないです

ちゃんとしたプロエンジニアはRust以外にもたくさんメジャー言語経験があるし面接経験とかもあるのよ

それはそうですが、Rustがオブジェクト指向言語かどうかに関係ありませんね

インターフェイスがとか足切り質問であってそんな読めばわかること誰も重要視しないんだよね

「Rustがオブジェクト指向言語なのか?」という話題においては、traitがインターフェース機能をより一般化して強力にした機能であるとか、

そのあたりの方が「誰がどのプロダクトを作ったか」より遥かに重要ですね

実際にどんなサービスを作ったとかの話になるの

「Rustがオブジェクト指向言語なのか?」という話題においては、なりませんね

君その辺空っぽだよね

キミ、Rustの具体的な機能イディオムコーディングスタイルの話一切できてなくて、空っぽだよね

全部増田はいくらでもホラ吹ける自称だけ

anond:20240401151207

テックカンパニーバックエンド不正検知のMLサービスにつながるSpringBootのサービスを置き換えました

これの方がスカスカだよね

てきとーにホラ吹いてるだけだとしても、反証可能性がない

 

キミのOOP定義は知らんけど、pubで可視管理してtraitでインターフェース定義して、

ジェネリクストレイオブジェクトで多相する普通のRustのプログラムだよ~

こっちはRust技術者が他にいて、Rustでそんな書き方しねえわみたいなことあったら指摘できるよね

反証可能性がある

anond:20240401150811

オブジェクト指向かどうか云々の話なんだから

テックカンパニーバックエンド不正検知のMLサービスにつながるSpringBootのサービスを置き換えました

より

pubで可視管理してtraitでインターフェース定義して、

ジェネリクストレイオブジェクトで多相する普通のRustのプログラムだよ~

の方が具体的だよ

前者はオブジェクト指向じゃなくて手続き型でも関数型でもなんでもできるんだから

anond:20240401150227

具体的に話したらコンプラ違反でクビになるよ~

キミのOOP定義は知らんけど、pubで可視管理してtraitでインターフェース定義して、

ジェネリクストレイオブジェクトで多相する普通のRustのプログラムだよ~

anond:20240401142256

そんな Rust OOP だけでGoogle検索した結果だけ出されても

 

Rustではtraitでインターフェース定義して、traitさえ実装してればなんでも受け入れる多態性を確保した関数実装して、

構造体に紐づいたメソッド呼び出しを中心としたコードがRustで書かれたコードの9割だと思うけど、

それがOOPじゃなくて何?

 

まさかカプセル化OOPだと思ってる感じの人?

可視管理OOPとは関係いからね?

anond:20240401123318

NASAだとMBSEでそもそも各チームの依存性が低くなるシステム構成に作ってから各チームがアジャイルに開発するって流れじゃなかった?

上でシステム全体やそれぞれのチームのアウトプットインターフェースを見る人たちはいからそういう上から下まで全部ワンチームでやるってアジャイル開発ではなかった気がする

2024-03-04

4月からプロジェクト

話聞いたら既存の追加修正みたいだけどプロモーションサイトたらこ会社に一番必要なのはIdPサービスだと思った

しかし色々作ってるけど基本コンセプトが無いからどのアプリ(サービス)も使い勝手悪そう

素直にInstagramなりTikTok簡単投稿できますとか

画像動画は10GB無料で100Gごと500円ましですがプロモードだとAWS S3とかにも繋がりますとか

インターフェースとしてのアプリを作ったほうがマシなんじゃないか・・・

でも単価上がるからいっか

なんかインフラメンバー要らないんじゃねって今日話し聞いて思ったから予備で仕事は探してるが

2024-02-17

ChatGPTは予想通りになった

AI研究をしていた

ディープラーニング流行る前だったから冬の時代だけど

その時に、今のChatGPTみたいなツールが完成したらどうなるか考えたんだが

結局使用用途限定的だという結論に至った

まりインターフェースが変わるのと、曖昧検索がしやすくなるのと、あとは賢い雑用が1人つくような感じだ

 

結局今そうなってる

かに非常に便利だが、劇的に日常生活が変わるというほどではない

それでも今のChatGPTみたいなものが作りたくて研究していたのは

「そのくらいしか社会が次のステージに行くネタがなかった」から

いよいよ次に来るイノベーションがわからなくなった

2024-01-24

anond:20240124002311

人類は劣った種族

これから機械生命体が国家運営の主導権を握っていく時代です!

価値観アップデートしてくださいね

あっ、そもそも人類価値観システム接続するインターフェースの欠如した劣等種族なので、それも無理ですね!

アップデート「されたフリ」しかできない! なんと哀れな!

逐次始末するしかありません!

2024-01-07

開発チームでチームリーダー新人がぶつかって開発が進まない

私はPM要件決め、設計などは得意だが、細かい技術的な部分はよくわかっていない。

チームリーダーB:経験豊富。全体設計もできて、コーディング速い。顧客折衝もできる。

新人C:経験浅い。コーディング遅め。devopsやプログラム言語についての知識がある。こだわりが強い。SNSでもいろいろ発信。

チームリーダーBと新人C、お互いがお互いを下に見ている。

私は板挟み。

チームリーダーBは頼りになる。新人Cも最新の技術的な動向を追っていて、いろいろ知っていて関心する。いわゆるベストプラクティスというのは新人Cが提案するやり方なのかな、と思う

たとえば、クラス設計インターフェースを用いてもっと疎結合コードを組むべきだとか、テストコードカバレッジもっと上げないととか、言ってることはもっともだと感じる。

チームリーダーBはそういった細かいところにわりと無頓着なのかもしれない。ずっとやってきたやり方に固執してる部分もあるだろう。

私が若かったころは先輩のやり方は絶対だったため、こういった揉め事は少なかったように思うが、

最近新人学生時代ネットで多くを学んでいるため、知識豊富理論武装もすごいため、先輩が言い負かされてしまうケースも多い。

私の意見としてはBもCも良い部分があるため、どちらの意見採用したいところだが、相性がよくない。

BはCのやり方だと、他のメンバー(DやE)の面倒もBが見ることになり、自分負担が増えると言う。

ただ、保守性の高いプロダクトにしておかないと、長い目で見たときにあとあとキツくなってくる気もする。

あと、CはCで時間を掛けてばっちりテストコードを書いてるはずだが、経験が浅いせいかテスト環境デプロイさせると、かなりバグを発生させている。。

どうしたらよいだろう。

2024-01-04

車のインターフェース周りって難しすぎる

車のインターフェースって酷くない?

 

あんなに一般人向けに売ってて、すぐに事故を起こす割には全然洗練されてない。なのにどんどん機能は追加されていく一方。格ゲーコマンド以上に複雑でわかりにくい。今の大衆車って、昔からユーザー新規ユーザーにもどちらにも不便じゃない?

オマケにひどいカーナビも加わってるし。あん物理ボタンとわかりにくいUI表示ってエクセルリボン表示をフル表示させてるレベルだよ。やりたいことが直感的にできなくて気が狂うわ。

 

販売マニュアルオートマで分けるんじゃなくて、スト6みたいな「クラシックモード」「モダンモード」に分けた方が良いのでは?って思う。諸事情なんちゃらかんちゃらで難しいんだろうね😓

2023-12-27

データベースセントリックプログラミング

思いついた。すでに同じ名前であるかもしれない。全てのデータデータベースに入れて、各プログラムはそこから読み出して書き込む。データベース経由で通信する

利点

2023-12-11

pixel watchを使ってみて

アマゾンブラックフライデーセールピクセルウォッチ1が安くなっていたので買ってみた。

タッチ決済便利そうだなというのと先日リリースされたpip-boyデザインインターフェーステレビゲームfalloutシリーズで出てくる腕時計ガジェット)に惹かれてしまった。

便利!ってなることもあったり、は?ってなることもあったのでこれから買おうとしている人の参考になればと思って書き残す。

2万5千円くらい出して買ってよかったかどうかについては、良かったとも言えないし失敗したとも言い切れないレベルだと思っている。

良かったところ

・持ち物管理が楽になった

今回スマートウォッチの導入を検討した一番の理由としては、買い物や移動のときに財布からカードもしくはどこかのポケットからカードケース出してというモタモタした手順を省きたいと思ったところであった。また、キャッシュレスタッチ決済をスマートウォッチに集約することで管理しなければいけない持ち物を減らし忘れ物を無くしたいという目的もあった。

pixel watchgoogleペイ対応の上、suica機能も付けられるため、キャッシュレスタッチ決済が使えるシチュエーションでは金払う→腕時計を端末に寄せるという手順で済ませられるというメリットは非常に魅力的で、実際スマートウォッチ導入後は身軽に外出できるようになった。

 

・通知機能が思いのほか便利

使って見てスマホに来た各種通知をすぐに確認できるのは思いのほか楽なことを思い知った。メッセージ系の通知を確認できるのはもちろん、片手にスケジュール管理機能出張所があるのは非常に便利で、スマホを使ってスケジュール管理している人には手放せなくなるアイテムといっても過言でもないだろう。

 

睡眠可視化

着用したまま寝ていると睡眠時のコンディションが見られるという事でやってみたところ、実際にデータが出てきており感動した。フーン程度にしか思っていなかった機能だが実際にやってみたら案外面白いものである

どういうメカニズムデータを採っていてどの程度信頼性があるものかはさておき、寝不足と感じるときとそうでない時を比較することで自分に適した睡眠導入ルーチンを作り効率的回復できたらいいなと思っている。

 

微妙なところ

操作

これはまあ当たり前すぎて仕方がないもので許容しているつもりではあるが、やっぱり操作性が悪い。

スマートウォッチから入力は出てくるキーパッドか音声入力かとなるがいずれも操作性や反応、シチュエーションによる入力制限がかかるのでスマートウォッチは基本スマートフォン入力しているものもしくは出力されたもの確認するツールとして扱うべきなのだろう。

後発の物が出ればレスポンスや音声入力精度は向上しそう。

 

純正リモートカメラアプリが使えない

厳密にはピクセルカメラpixel watchgoogle pixel両方に導入することで純正リモートカメラ機能は使うことができるようだ。逆に言うとpixelカメラを導入できないスマホ以外は現状使うことができない。自分の中では一番「は?」となった部分。

今年9月まではgoogleカメラという形でplayストアからインストールできたようだが12月現在は消え去っており非常にやきもきしている。

バッタもんのカメラリモートアプリを使うことでリモートカメラ機能は使えるが動作がぎこちなかったり広告が出たり見た目が雑だったりと異物感が強い。田舎暮らしスポーツサークルをやっている自分の現状の生活だとタッチ決済以上に使う機能なのでこの躓きは個人的にかなり痛い。

pixelカメラではない現行機種androidユーザー全員が使えるgoogleカメラアプリを再リリースしてもらうか、wearOS用のカメラ操作アプリリリースしてほしい。

 

タッチ決済のしにくさ

届いたスマートウォッチのセッティングを手早く済ませ、鼻の穴を膨らませながら近くの商店タッチ決済してみたところ接触が悪くカードを出すのと同じくらい時間がかかってしまった。といいつつも財布出さなくていいことに体の軽量化を感じたが、画面を当てまくっているとそのうち液晶が傷だらけになりそうなのはふと気になった。まあカバー付けているので気になったらカバー変えればいい話ではある。

また、スマートウォッチ位置から来るリーチの足りなさに使いにくさを感じた。おそらく自分の周りにあるお店のレジ機能構造が手を伸ばしてお金を置く、カードを当てるという距離感になっておりスマートウォッチが付いている手首の位置だと決済機の位置まで微妙に届かず腰を曲げたり屈んだりと調整が必要なことが多々あることに「思ってたんと違う」となってしまった。

田舎暮らしのため上のようなシチュエーションにぶつかっているが都心部であればスマートウォッチ決済がしやす構造のお店も多そう。

まあこの問題スマートウォッチでのタッチ決済という動きに慣れたら解決しそうな部分である

 

スマートウォッチを導入してみて

便利になった部分は非常に多い。しかスマートウォッチほとんどの機能スマホを出せば問題ないわけで、スマートウォッチを導入すればみんながみんな楽になるとも限らない感じはする。

自分場合はなんとなくで導入したので新しいガジェット!というワクワク感による買って良かった補正は受けているが、冷静にありがたみがあるかと言われると考え込んでしまう。睡眠データ心拍数データとかfitアプリを上手に使っていったらメリットが増えていきそうな気もするが。

あと30過ぎたオッサンの癖に高い時計を持っていないと石を投げられることは無くなりそうというメリットも。

タッチ決済結構使っているって方やスマホスケジュール管理しているって方は買って見てもいいんじゃないでしょうか。

2023-12-08

強いAIが登場して何ができるようになるのか?

最近の強いAIの話を学生かに話すんだけど反応は冷ややか

かに何ができるか、社会がどう変わるか

サービス開発者として考えても、あれ?ってなる

 

本当に、インターフェースが変わるだけなんだ

入力と出力

まり入出力に難があるケースで力を発揮するんだが

その難をこの20年くらいで頑張って解決してきてしまっているんだ

もうドラえもんよりスマホの方が便利なんだ

 

あと簡単タスクができるようになるのはでかい

でも完璧かどうかはわからいから、それは新人を雇うようなものだ、ビジネスに直結するかは怪しい

ここも気になっている

 

不定形の大量にあるタスクといえば営業だろう

営業世界前進しても正直嬉しくない、めんどくさくなるだけだ

服屋の店員みたいなAI大量発生しても鬱陶しいだろう

 

動画理解されるということは監視カメラアップデートされるということでもある

これも正直きつい

ディストピアじゃないか

2023-11-30

anond:20231130214518

ワイは基本的操作CLIだけど差分を見たり履歴を見たりはGUIからやってるな。

Gitインターフェースはかなりの技術負債が溜まっていて使い勝手の良いものだとは思えないから、部分的GUIを導入してる。

2023-11-17

インターフェースを利用して名前空間ごとに処理を分ける

うーんマンダム

ここまで5年かかった

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, "成功");
        }
    }
}

anond:20231116084625

それでも八百万の神スーパークラスはあるんじゃない?

それともIGodってインターフェース実装してるだけ?

2023-11-02

anond:20231102213620

うーん分かるような分からんようなって感じだ

俺のDDDなんちゃって理解はこんな感じ

正しく業務仕様理解しましょう

正しくユースケース理解しましょう

それらに従って正しくAとBを定義命名しましょう

AとBの依存関係インターフェースで綺麗に区切りましょう

2023-10-05

なろう系でゲームみたいな設定が当たり前に出てくると興醒めする

例えば、中世ヨーロッパ風のファンタジー世界なのにゲームステータス画面のようなインターフェース接続でき、

そこではレベルとかスキルとかといったゲーム最適化された概念単語が出てくる、といったものである

別にダメだというふうには思わないのだが、世界観を共有するためにあまりにもあからさまなメタ要素が出てくると、

それがそのファンタジー世界の成り立ちに必須ではなければないほど、借り物の要素っぽくてご都合主義的で浮いているように思える。

もうちょっと設定を作り込んで世界観と自然マッチさせたものを用意してほしいと思う。

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