「gui」を含む日記 
はてなキーワード: guiとは
2025-01-04
■MSXって早すぎたWindowsだったんだよな…
だって、どのメーカーのマシン買ったってWindowsマシンはほぼ同じ
どのメーカーのMSXマシン買ったってほぼ同じ、まあYAMAHAとかは差別化してた気がするけど、
差別化できないならメリットないよね、ってMSX帝国？は崩壊した
あの変態性の方向を変えればX68000やFM-TOWNSぐらいは行けたのに、3DO REALとかと組んじゃう辺りが松下社員っぽいんだよなｗ
でも、時代はもう逆だよね
だって、Windows同士だったら問題ないのに、Macにファイル持ってったらどうしてこうなるの？とか、その逆とかあるわけで、
GUIとかだって、Windowsは保守的過ぎて、スタートボタンなくしただけで発狂するんだもん
カーネルとか中身をごっそり書き換えて、素晴らしいWindowsになりました、でもスタートボタンがない、となったら、
ユーザーはソフトウェアの中身なんて知ったことか、スタートボタンを出せ、左下に出せ、ってなるんだもんな
Macも同じで、メニューは上にしろ、右上に寄せろ、でもウィンドウのボタンは左上でもいいよね？！って流石に20年、30年Mac OS Xユーザーやってた俺もアホかｗと思っちゃったけどさ…
もう、みんな外観、GUIしか眺めてないし、その差別化も求めてない
すべてがWindows95みたいになればいいと思ってる
2024-12-14
■anond:20241214123155
言われた話だと、定時出勤とかなんだよね、評価されるのは…
安定した勤務態度が優先されて、能力はまったく評価されない…😟
障害者には仕事は適当に低いレベルのものを渡すから、とにかく勤務態度が安定していて、波風立てないでくれ、みたいな感じ…
効率化するためのちょっとしたスクリプトだろうが、コードなんでもガリガリ書きますよ、みたいなのは評価されなかった
障害者雇用で躍起になってたときは、まだコード書く意欲があったけど、もうそれも失せてしまった
ChatGPTとかの登場も大きかった
生成AIのことは論文レベルで、どんなことができそう、というのは漠然と知ってたけど、
こうも急激に一気に総合力で実用化されるとは自分は想像してなかった
今となっては、テレビでも自分の両親みたいなITリテラシーが低い人でも普通にAIを使ってるし、
学校の教員とか、小学生でさえAIを、それこそ自分なんかより使いこなしてる可能性がある
いわゆるコマンドプロンプトとか、terminalが使えることが意味があった時代があって、
それがGUIになって、CUIが使えない人でもできるようになって、生成AIのプロンプトは更に人間寄りのUIということなんだろう
そのうち、コマンドプロンプトや端末エミュ経由でやってたこと、というかシェルというべきか、
その辺のレイヤーがAIのプロンプトっぽいものに置き換わる日は近いと思ってる
こうなってくると、プログラマーとか、ITリテラシーが高いみたいなアドバンテージは急速に失われていくだろう
社会の方向性としては正しいけど、アドバンテージがあることで仕事にしていた人たちの意味はなくなっていくわけだ
プログラムを書くこと、少なくとも自分が書くことは社会に必要とされてないわけだから、
もう仕事は自分のできる範囲であればいいが、何でもいいし、定時出勤だけが評価されるような仕事でももういいかな、とは思ってる
思ってるけど、それでも厳しいね、やっぱり年齢なんだろうね…😟
2024-12-01
■死ぬ前に入力ありのBMI（ブレイン・マシン・インターフェース）を触りたいものだ
ニッコマレベルのバカ大学でもなんとなくペタペタ触って遊んでる研究室があるらしいので、あと１０年もすればAI絵師と同じレベルで素人のオッサンたちによる趣味としてBMI研究が進むことだろう。
出力するだけのBMIなんてPCにフットペダルを追加する程度のレベルの進歩しか出来ないと思う。
やはり入力だ。
電極ぶっ刺し型は事故のリスクが高いことを考えると、ペースメーカーのようなものを埋め込む形にするほうが安全なのか？
それでも脳みそにそんなものをわざわざ入れる手術をすることがリスキーだ。
割れた頭蓋骨を補修するためにボルトをぶっ刺すのとはリスクのレベルが全然違う。
SFなんかじゃナノマシンが使われているが、ああいうのって使い古した後の古い奴はどうやって捨てるつもりなんだろう。
うむ。
あと２０年で出来たら凄い早いと言っていいだろうな。
５０年かかっても無理かも。
出力型のBMIについては５０年後には流石に実現しているだろうが、そのフィードバックは従来のGUIで終わりになりそうではある。
むしろ、視覚・聴覚・痛覚あたりの神経に対して何らかの入力拡張が出来るような仕組みを作ったほうが手っ取り早い可能性さえある。
たとえば人間は文章を読んでいる時にそこに記載されている物体や情景について視覚的なイメージを脳内に形成することが出来るわけだが、脳みそを直接弄らずにこの機能にアクセス出来るルートを作ってそこに視覚情報を流す形なら脳を焼き切る心配はかなり減るんじゃないだろうか？
重要なのは「今既に人体が持っている情報系を拡張させるような形で入力信号を得られるような仕組みに振れたい」ということなのだ。
いっそのこと睡眠学習的なやり方で人間の感覚を拡張さえてしまうとかもありかも知れないな。
たとえば点字みたいなものをもっと細かくしたような情報を体の特定の部位から得ることが出来るように人体に学習させれば……ブツブツ……
2024-11-20
■
Immersive Translateっていう翻訳ツールというかブラウザ拡張機能が便利すぎてヤバい
良いところ
- 原文の下に翻訳を表示する対訳タイプなので訳がおかしい時もすぐに原文を参照できる。
- YouTubeなど多数の動画サイトで字幕の2カ国語表示可能。
- もちろん翻訳のみを表示することも可。
- まるごと翻訳ではなく段落ごとの翻訳なので文章が破綻しづらい。
- 翻訳サービスの選択肢が豊富。一部のLLMも無料。サブスクユーザーならDeepLやChatGPTなども可。自分のAPIを使うならそれらも無料版で可。
- LLMは自分でSystemPromptを入力可能。プリセットも有り。
- 設定が豊富。痒いところにも手が届く。
- 完璧ではないが、PDFやepubをレイアウト維持したまま翻訳できる。2カラムで、左に本家、右に翻訳版が表示されるので参照が容易。
- テキストのみを順次翻訳するので、よくあるファイルサイズ制限にもひっかからない。
- ローカルファイルも翻訳可。
- GUIが日本語対応しているせいで言語が日本語判定される、普通の翻訳機能で訳してくれないサイトでも動作する。
- TextareaやInputで入力中、指定したキーを連打すると文章を翻訳できる機能もあり。
- 上記ほとんどの機能が無料。
ダメなところ
- 開発がたぶん中国
- 設定画面の日本語訳の品質がひどい
- 権限の都合で機能しないサイトはさすがに無理
- 文章量が多い・箇条書き判定されるサイトだと大量のキューが一斉に送信され翻訳待ちになるのでとても重くなる
- 対訳は単純計算でページの文章量が2倍になるためページが非常に長くなることがある
- 開発がたぶん中国
2024-11-02
2024-10-26
■ベースの音とかドラムの音をMIDIに自動的にしてくれような便利な道具ないの？ドラえも～ん！
耳コピしながら手で打ってると発狂しそうなので、昨日から便利そうな道具探してるけど、よくわからん
あっても使い方がわからん
というか、音楽関係のソフトウェアはなんでこう使い方がよく分からんのが多いんや、GUIのデザインには以上に凝るくせに使い勝手が最悪なのはなんなんや？
YAMAHAのTHR5のあのソフトもなんなん？GUIを全部手で描画しないと気が済まんのか？
普通にWin32のGUI使うのイヤにしても、もっとこうなんかあるやろ…😟
あと、便利そうなプラグインの体験版を使おうとするたびに、独自のライセンス管理のソフトインストールさせられたり、なんか色々面倒、雑多なアカウント増えるし
もう、曲の音声丸々入れたら、楽譜がピーガタガタタ…とか出力される機械ってないの？
教えてよ、ドラえもん…😟
2024-10-24
■Android Studioが糞過ぎる
これまでいろいろな開発環境を使ってきたけど、Android Studioは本当にダメだ。
別途Javaの環境も構築しなきゃいけないし、おまけにJavaのバージョンによってはAndroid Studioとの相性が悪くてエラーが出ることも多い。
最初から最低限必要なものは揃えてくれればいいのに、後からどんどん障害物が出てくるから本当にイライラする。
アプリをリリースするためには署名が必要なんだけど、これがまた本当に面倒。
Android Studioには「キーを生成する」機能があるけど、これが直感的じゃない。
手順を調べるのに何時間も費やしたことか。コマンドラインからキーを生成するのか、GUIでやるのか、どっちにしても「なぜこんなに複雑にするのか」と思う。誰が得するんだ、この面倒くささは。
が、これまた問題が出てくる。ビルド時にエラーが出ることが多い。
何が悪いのか全然分からないし、エラーメッセージもわけがわからない。
ググって出てくる情報も正解とは限らない。結局時間だけが無駄に過ぎていく。無限ループに入った気分。
こうやってひたすら環境構築と闘ってきたわけだが、実際にアプリ開発に入ると今度はAPIの変更やライブラリの依存関係でまた地獄が待っている。
新しいバージョンが出るたびに、対応しなきゃいけないことが山積みで、これをやっていると「何のためにこんな苦労をしているのか・・・」と思わずにはいられない。
結局Android Studioを使っていると常に試行錯誤の連続で、楽しいというよりはストレスがたまるだけ。
正直、他の言語やフレームワークに目を向けようかとも思ったこともある。
React NativeやFlutterなんかは環境構築がスムーズで、すぐに開発に入れる印象がある。
なのにAndroid Studioに戻ってくるのは、Androidの市場の広さが魅力的だからだろうか。
でも何度もこの環境で悩まされると、本当に心が折れそうになる。
2024-10-21
■JTCのシステム部門に居るけど何か心が折れた
1行まとめ
詳細
転職でJTCに入ったが配属がDX推進部だった。ずっと上流から下流までシステム開発に携わってきたので仕事は温いがそれ以上にローコードやノーコードツールに危機感を感じ鬱になりそう
ちょっと前は苦手だったデータ加工も今じゃGUIで簡単にタスクに出来るのでデータをS3に置けば勝手に集計してBIツールで見やすく出来る
それをS3をOnedrive程度と思ってるitパスポートも持ってない社員が得意気に言ってるのを聞いた時何か心が折れた
面倒なデータ取得とかは他部署だしちゃんと業務も分かれてるしDXとしても理想的な流れだと思う。自分も学べば良いと思うが前の仕事でBIツール導入にも携わったので何となくの機能と限界は分かっているし、今はツールの組み合わせで限界もなくなってきている。サーバレスすらもう古い。でかい会社なので利用料金高騰でツール終了もたぶん無いだろう
今後はマイクロサービス化も進むからバックエンドは最小でローコードやノーコードで作られたフロントでデータが入り、それをローコードやノーコードで連携し、ローコードやノーコードで取得し、ローコードやノーコードで表示分析する時、ごく一部のシステムエンジニア以外は不要になるよね
APIとかネットワークとか学んでも活かせるのはローコードツール作ってる会社のエンジニアくらいで大半は無駄な知識持った無能に成り下がるよね
金のない中小とかには仕事あるだろうけど給与減るし、このままPythonとかwwwって笑われながらどんどん要望に合わせた自動化タスク作るのかと思うとIPAやベンダーの資格すら憎らしくなってきた。今はMSのツール資格とSalesfarceよ。AWSのとか使えね
2024-09-26
■ハートキャッチプリキュアのopのコードが読み取れない
初代プリキュアは初回一発でコードが当てられるのに、なんでだろう
なんか、コードが当てられる曲と、当てられないタイプの曲がある気がする
少なくとも、自分は耳は駄目な方だと思っているので、ベースギターのような音がない曲とかはかなりアウト、つらい
伴奏のベース音を地道に読むしかない、でもベースがあれば簡単である
問題はベースギターは低周波、低音域であるため、プロでも聴き取りづらいことがあるのである
しかし、今はAI技術も相まって、奇麗に原曲をパートに分けることができる
分けるツールも数多くあるが、Meta社が公開してるものがオープンソースで無償で一番よいであろう
それを呼び出すGUIツールも存在するので、そちらを利用した方が簡単であろう
規約上良いのか怪しいが、検索ワードを入れるとYouTube上の楽曲が表示され、そこからパート分けしたいものをクリック一発で選べるようになっている
さて、比較的奇麗なドラムやベース音が取り出せるようになっただけでも、大昔に比べれば快挙であろうが、私はこのパート分解した音声データをそのままDAWに貼り付ける
ちなみに、私の現在のDAWはStudio Oneである
貼り付けたベースのトラックのトランスポーズ？だったかを0から12に変更すればオクターブが1つ上がる
オクターブは2つまで上げられるみたい、でもオクターブ1つがちょうどいい
あとは短音でベースがなくともギターで真似していけばいいし、打ち込みのトラックのピアノロールに打ち込んでいくのもいいだろう
原曲の音声を使うのはYouTubeでは厳密には規約違反であり、違法であるはずだが、すべてを聴き取って打ち込み、楽器演奏を録音したコピー演奏は許されているはずである
これぐらいの簡単な曲であれば、ベースの音をそのままパワーコードにするだけで、ほぼなんちゃってメタルバージョンのできあがりである
最近の日本の楽曲は、異常にコード進行が複雑で、頻繁なものが増えてる
そうなるとテンションの違いなどがかなり顕著に意味を持ってくるので、パワーコードにしてしまったら、そのニュアンスがまったく死んでしまい、意味がなくなってしまう
それから、ベースの音＝コードのルート音みたいな安直なパターンからも外れやすくなるので、そこは注意する必要があろう
しかし、少なくとも昭和、平成のアニソンであれば、大抵のものはなんとかなるものである
2024-08-29
■そういえば、GodotのIDE自体がGodotで書かれてるし、
Godotで書かれた画像エディタとかあるんだから、あれC++とかで書けるようにしてくれたらいいのにな…
あと、BlenderのGUIだけ分離しようとした人とかどっかにいた気がするんだけど、
日本語がちゃんと使えるマルチプラットフォームのGUIライブラリって、未だに決定打ない気がするんだよな
誰か頑張って…😟
■そういえば、いつだったか深夜にEテレ観てたら、
PythonでTk使って芸人？がゲーム作る企画やってたけど、なんでpygame使わないんだろう…😟
というか、もういい加減Tcl/TkのTkだけ延命するのやめない？
権利の問題とか色々あるけど、Qtの方がまだマシだし、まあQt見てれば分かるけど、マルチプラットフォームのGUIを実現するってかなりキツイ作業だし、
メンテのコストもかかるから、いつまでもTkにしがみついてるの分かるけどさ…
imguiって、なんもしてなくても画面更新してるんだろうし、かなりエコじゃないと思うんだけど、画面更新するアプリ、ゲームとかには適しているし、
てか、もうマルチプラットフォームのGUIって、特殊な状況を除けば、もうWebブラウザだよな
最初の話もPythonじゃなくて、JavaScript使えばいいのに…
2024-08-22
■面白かった頃のITを書いてみる
「ハーイ！ジョージ！」の頃はまだ良かったんだ
俺もピエロ🤡に扮して「ハーイ！女児ぃ！」とか言たいだけの人生だった
でも、ラストで巨大な蜘蛛が出てきた時点で興醒めですわ、どんなサメですわ
ウソです
ド田舎でMSXに搭載されていたマシン語モニター機能とか使ってマシン語書いてた頃ですかね
文字をレンガ🧱とかに変えて、ロードランナーみたいなの作ってました
ウソです
MSX1以降、大学に入るまで、私はほとんどパソコンを使っていないブランク期間があります
大学に入って、物置からMSXを発見して、当時購入したマシン語入門的な本とか、
MSXのカートリッジの機能を使って電子工作やる本を買ったりとかして、
MSXカートリッジの形状をしたユニバーサル基盤を秋葉原に買いに行ったことから、そこから毎週毎日秋葉原に行くようになります
まだ、オタク系のアニメとか漫画とかフィギュア模型の店とか、メイド喫茶とか、まったくない時代でした
MSXでZ80のマシン語を一通り理解して、MSXカートリッジにユニバーサル基盤刺して、自分で組んだ電子回路をMSXで制御したりして遊んでました
あと、大学入学祝いがPC-9801だったので、それをいじったりもしてました
Microsoft Quick CとかTurbo Cでプログラムを書いたり、Cマガジンを定期購入するようになり、TeXを最初に動かしたのもPC-9801だったと思います
そのあと、米国から輸入したPC/AT互換機を当時のドスパラだったかな？で購入して、私は運が悪いのか、ちょっと色々と酷いのが届いたのですが、
それを騙し騙し使うことにして、Laser 5が販売していたSlackwareのLinuxインストールしたり、DOS/Vで海外のゲームやったり、なんだかんだ楽しかったのかもな
あと、まだアルファ版？だったかんのJavaを、えらい長い時間かけてダウンロードして、それのサンプルをひたすら眺めて勉強したりしてました
CとJavaでソケット使ってネットワーク系のプログラム書いたりとか、簡単なチャットみたいなのとか、JavaだとAWTでGUIまで作れちゃいますから便利になりましたよね
そういえば、前のバージョンのScratchのソースコードをなんか読んだ記憶がある
ただ、自分はBIO100％みたいにもなれなかったし、X68使ってる人たちみたいにもなれなかったし、Lightwave使ってる人たち、新海誠みたいにもなれなかったし、
なんか色々仕事したり、賞をもらったり、色々あった記憶はあるのだけど、何者にもなれなかったし、今も何者にもなれてないままですね、心に刻んでおくよ
2024-08-21
■
何故かnouveauが有効になってNVIDIAのproprietaryドライバとconflictしてGUIが起動しなくなった。
どうにもnouveauが無効にできなくて困ってたけど、よくよく考えたらもうnouveauで良いかなって気分になってnouveauにしてみた。
昔、デュアルディスプレイにするためだけにNVIDIAのドライバ入れてたんだよね、たしか。
今もうデュアルディスプレイ使ってないし。
■anond:20240820124516
UnityもUnrealEngineも本格開発するなら大差はないんですけどね。
どのみちカスタマイズしないといけないというだけで、より短縮できるエンジンを選択しただけの内容ですよ。
- クロスコンパイルと各実行環境への最適化精度
- 計算処理郡（ライブラリ）自体の速度やCPU負荷、GPU負荷分散の精度や、メモリスレッドを考慮した精度
- 最低必要な処理郡（IKとかそういうやつ）のレベルの高さと不必要な処理の削減のしやすさ、選択のしやすさ
- グラフィックエンジンの能力、各プラットフォームの描画APIの最適化や、最新の描画技術の統合（GI等）
- GUIでの操作のしやすさ、非エンジニアとの連携のしやすさ、コンフリクトの起こしにくさ
が評価ポイントになりますが、ゲームによって不必要なものは削除したり先鋭化したりしますが、大元の開発者（UnityやEpic Games）との連携が不可欠になってしまいます。
大体の場合は海外はレスポンス非常に悪いので、自社でやれるなら自社でやったほうがカスタマイズしやすいし、何なら最新の描画処理なんていらない、ってなるんです。
もちろんUnity最高HDRPいいよね、とかはちょっと……となりますが、エンジンの性質を知ってる人であれば別にUnityだろうとUnrealEngineだろうと大差ないです。
スタンダードの状態での品質はもちろん大型タイトル作るならUnityは論外ですが、小規模〜中規模で制作するならUEだとBP管理がクソ面倒なので、Unityの方が良いです。