  |
はてなキーワード: guiとは
Immersive Translateっていう翻訳ツールというかブラウザ拡張機能が便利すぎてヤバい
インストールただしただけではStudio Oneから見えなかった…😟
直接.exeとか.dllの入ってるフォルダを見るように指定したら使えるようになったけど、VSTのフォルダ構成がなんか混乱してきた
なんか一向に曲ができない、なんか違う感あるので、いっそVST書く方でもやろうかと思った
VSTといえばJuceでしょ、とJuceのテンプレート生成してVisual Studioでビルドできるところまで確認はした
なるほど、みんなこんな感じで書いてるんだね
ついでにlibsdlがver.3作ってる途中なので、それもサンプルコードをいくつかビルドしてみた
ちゃんと動くね、2Dゲーなら問題なく書けそう、まあ、今の時代ゼロからC++やJavaで書きたがる人がいるかというと少ないとは思うのだけど、
個人的にはUnityやUnrealのGUIみたいなのはクソだと思ってて、1行から書き始めて動作する方が落ち着くんだよね
でも、コードはもうあんまり書きたくないんだ、作曲したいんだ、コピーしたいんだ
Logic Proのドラム音源とかそこそこいいんだね、ちょっとMacほしくなる
というか、俺がMacほしくなる要因が、ヒラギノフォントとか、ドラム音源とか、なんかもうOSとかハードとか関係ないな、おまけがほしいになってる
Mac OS X Jaguarぐらいから？の付き合いだったけど、やっぱりxcodeはクソだと思ったし、Obj-Cもクソだと思ったし、今はまあSwiftあるけどさ…
Cocosでゲーム作ろうとしたりとかしてたよな、なんか見せた人のウケは悪かったけど…
若い頃は死ぬほど絵が描きたかったはずなのに、こうなってみるとまったく創作意欲？がわかないな…😟
正直、作曲欲もあるというとウソになる、ずっとやりたかったけど、色々諸事情があってやれなかったので、死ぬまでぐらい好き勝手にやりたくなった、
そういう後ろ向きの発想なんだけど、こうなると自分から何か発信したいとか、そういう姿勢じゃないんだよな
アーティストになりたいんじゃなくて、スタジオミュージシャンになりたいみたいな…、まあ、それももう無理なおこがましいレベルの低さなんだけど…
まあ、病気の件もあるけど、やるの遅すぎたよね、楽器は10代ぐらいから始めて、ギター、ベース、ドラム、技術としてのボーカル、ピアノ、
シンセサイザー系のキーボード、ブラス系、一通りやるべきだよね、うまくならなくていいけど、どんな楽器でも触れるレベルにはなっておくべき
能力は機械がいくらでも増幅してくれるけど、知識は機械が植え付けてくれるわけではないので…😟
やっぱり、まずはバンドスコアを買って、DAWに落とし込むとか、Guitar Proで楽譜として採譜して、MIDIに変換したものをDAWで読んで加工するとか、
耳コピしながら手で打ってると発狂しそうなので、昨日から便利そうな道具探してるけど、よくわからん
あっても使い方がわからん
というか、音楽関係のソフトウェアはなんでこう使い方がよく分からんのが多いんや、GUIのデザインには以上に凝るくせに使い勝手が最悪なのはなんなんや？
YAMAHAのTHR5のあのソフトもなんなん？GUIを全部手で描画しないと気が済まんのか？
普通にWin32のGUI使うのイヤにしても、もっとこうなんかあるやろ…😟
あと、便利そうなプラグインの体験版を使おうとするたびに、独自のライセンス管理のソフトインストールさせられたり、なんか色々面倒、雑多なアカウント増えるし
もう、曲の音声丸々入れたら、楽譜がピーガタガタタ…とか出力される機械ってないの？
教えてよ、ドラえもん…😟
これまでいろいろな開発環境を使ってきたけど、Android Studioは本当にダメだ。
別途Javaの環境も構築しなきゃいけないし、おまけにJavaのバージョンによってはAndroid Studioとの相性が悪くてエラーが出ることも多い。
最初から最低限必要なものは揃えてくれればいいのに、後からどんどん障害物が出てくるから本当にイライラする。
アプリをリリースするためには署名が必要なんだけど、これがまた本当に面倒。
Android Studioには「キーを生成する」機能があるけど、これが直感的じゃない。
手順を調べるのに何時間も費やしたことか。コマンドラインからキーを生成するのか、GUIでやるのか、どっちにしても「なぜこんなに複雑にするのか」と思う。誰が得するんだ、この面倒くささは。
が、これまた問題が出てくる。ビルド時にエラーが出ることが多い。
何が悪いのか全然分からないし、エラーメッセージもわけがわからない。
ググって出てくる情報も正解とは限らない。結局時間だけが無駄に過ぎていく。無限ループに入った気分。
こうやってひたすら環境構築と闘ってきたわけだが、実際にアプリ開発に入ると今度はAPIの変更やライブラリの依存関係でまた地獄が待っている。
新しいバージョンが出るたびに、対応しなきゃいけないことが山積みで、これをやっていると「何のためにこんな苦労をしているのか・・・」と思わずにはいられない。
結局Android Studioを使っていると常に試行錯誤の連続で、楽しいというよりはストレスがたまるだけ。
正直、他の言語やフレームワークに目を向けようかとも思ったこともある。
React NativeやFlutterなんかは環境構築がスムーズで、すぐに開発に入れる印象がある。
なのにAndroid Studioに戻ってくるのは、Androidの市場の広さが魅力的だからだろうか。
でも何度もこの環境で悩まされると、本当に心が折れそうになる。
転職でJTCに入ったが配属がDX推進部だった。ずっと上流から下流までシステム開発に携わってきたので仕事は温いがそれ以上にローコードやノーコードツールに危機感を感じ鬱になりそう
ちょっと前は苦手だったデータ加工も今じゃGUIで簡単にタスクに出来るのでデータをS3に置けば勝手に集計してBIツールで見やすく出来る
それをS3をOnedrive程度と思ってるitパスポートも持ってない社員が得意気に言ってるのを聞いた時何か心が折れた
面倒なデータ取得とかは他部署だしちゃんと業務も分かれてるしDXとしても理想的な流れだと思う。自分も学べば良いと思うが前の仕事でBIツール導入にも携わったので何となくの機能と限界は分かっているし、今はツールの組み合わせで限界もなくなってきている。サーバレスすらもう古い。でかい会社なので利用料金高騰でツール終了もたぶん無いだろう
今後はマイクロサービス化も進むからバックエンドは最小でローコードやノーコードで作られたフロントでデータが入り、それをローコードやノーコードで連携し、ローコードやノーコードで取得し、ローコードやノーコードで表示分析する時、ごく一部のシステムエンジニア以外は不要になるよね
APIとかネットワークとか学んでも活かせるのはローコードツール作ってる会社のエンジニアくらいで大半は無駄な知識持った無能に成り下がるよね
金のない中小とかには仕事あるだろうけど給与減るし、このままPythonとかwwwって笑われながらどんどん要望に合わせた自動化タスク作るのかと思うとIPAやベンダーの資格すら憎らしくなってきた。今はMSのツール資格とSalesfarceよ。AWSのとか使えね
初代プリキュアは初回一発でコードが当てられるのに、なんでだろう
なんか、コードが当てられる曲と、当てられないタイプの曲がある気がする
少なくとも、自分は耳は駄目な方だと思っているので、ベースギターのような音がない曲とかはかなりアウト、つらい
伴奏のベース音を地道に読むしかない、でもベースがあれば簡単である
問題はベースギターは低周波、低音域であるため、プロでも聴き取りづらいことがあるのである
しかし、今はAI技術も相まって、奇麗に原曲をパートに分けることができる
分けるツールも数多くあるが、Meta社が公開してるものがオープンソースで無償で一番よいであろう
それを呼び出すGUIツールも存在するので、そちらを利用した方が簡単であろう
規約上良いのか怪しいが、検索ワードを入れるとYouTube上の楽曲が表示され、そこからパート分けしたいものをクリック一発で選べるようになっている
さて、比較的奇麗なドラムやベース音が取り出せるようになっただけでも、大昔に比べれば快挙であろうが、私はこのパート分解した音声データをそのままDAWに貼り付ける
ちなみに、私の現在のDAWはStudio Oneである
貼り付けたベースのトラックのトランスポーズ？だったかを0から12に変更すればオクターブが1つ上がる
オクターブは2つまで上げられるみたい、でもオクターブ1つがちょうどいい
あとは短音でベースがなくともギターで真似していけばいいし、打ち込みのトラックのピアノロールに打ち込んでいくのもいいだろう
原曲の音声を使うのはYouTubeでは厳密には規約違反であり、違法であるはずだが、すべてを聴き取って打ち込み、楽器演奏を録音したコピー演奏は許されているはずである
これぐらいの簡単な曲であれば、ベースの音をそのままパワーコードにするだけで、ほぼなんちゃってメタルバージョンのできあがりである
最近の日本の楽曲は、異常にコード進行が複雑で、頻繁なものが増えてる
そうなるとテンションの違いなどがかなり顕著に意味を持ってくるので、パワーコードにしてしまったら、そのニュアンスがまったく死んでしまい、意味がなくなってしまう
それから、ベースの音＝コードのルート音みたいな安直なパターンからも外れやすくなるので、そこは注意する必要があろう
しかし、少なくとも昭和、平成のアニソンであれば、大抵のものはなんとかなるものである
Godotで書かれた画像エディタとかあるんだから、あれC++とかで書けるようにしてくれたらいいのにな…
あと、BlenderのGUIだけ分離しようとした人とかどっかにいた気がするんだけど、
日本語がちゃんと使えるマルチプラットフォームのGUIライブラリって、未だに決定打ない気がするんだよな
誰か頑張って…😟
PythonでTk使って芸人？がゲーム作る企画やってたけど、なんでpygame使わないんだろう…😟
というか、もういい加減Tcl/TkのTkだけ延命するのやめない？
権利の問題とか色々あるけど、Qtの方がまだマシだし、まあQt見てれば分かるけど、マルチプラットフォームのGUIを実現するってかなりキツイ作業だし、
メンテのコストもかかるから、いつまでもTkにしがみついてるの分かるけどさ…
imguiって、なんもしてなくても画面更新してるんだろうし、かなりエコじゃないと思うんだけど、画面更新するアプリ、ゲームとかには適しているし、
てか、もうマルチプラットフォームのGUIって、特殊な状況を除けば、もうWebブラウザだよな
最初の話もPythonじゃなくて、JavaScript使えばいいのに…
「ハーイ！ジョージ！」の頃はまだ良かったんだ
俺もピエロ🤡に扮して「ハーイ！女児ぃ！」とか言たいだけの人生だった
でも、ラストで巨大な蜘蛛が出てきた時点で興醒めですわ、どんなサメですわ
ウソです
ド田舎で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使ってる人たち、新海誠みたいにもなれなかったし、
なんか色々仕事したり、賞をもらったり、色々あった記憶はあるのだけど、何者にもなれなかったし、今も何者にもなれてないままですね、心に刻んでおくよ
何故かnouveauが有効になってNVIDIAのproprietaryドライバとconflictしてGUIが起動しなくなった。
どうにもnouveauが無効にできなくて困ってたけど、よくよく考えたらもうnouveauで良いかなって気分になってnouveauにしてみた。
昔、デュアルディスプレイにするためだけにNVIDIAのドライバ入れてたんだよね、たしか。
今もうデュアルディスプレイ使ってないし。
UnityもUnrealEngineも本格開発するなら大差はないんですけどね。
どのみちカスタマイズしないといけないというだけで、より短縮できるエンジンを選択しただけの内容ですよ。
が評価ポイントになりますが、ゲームによって不必要なものは削除したり先鋭化したりしますが、大元の開発者（UnityやEpic Games）との連携が不可欠になってしまいます。
大体の場合は海外はレスポンス非常に悪いので、自社でやれるなら自社でやったほうがカスタマイズしやすいし、何なら最新の描画処理なんていらない、ってなるんです。
もちろんUnity最高HDRPいいよね、とかはちょっと……となりますが、エンジンの性質を知ってる人であれば別にUnityだろうとUnrealEngineだろうと大差ないです。
スタンダードの状態での品質はもちろん大型タイトル作るならUnityは論外ですが、小規模〜中規模で制作するならUEだとBP管理がクソ面倒なので、Unityの方が良いです。
Guo Wengui 氏は、農場から XiCoin まで、一日中空に向かって自分の無駄なことを宣伝しており、「HiCoin の暗号化機能と将来の支払い、そして将来の米ドルとの交換が歴史を作るでしょう。彼はその人です。」安定した通貨、変動する最新の暗号化された金融プラットフォームを備えているのは 1 つだけです。」 アント ギャングはだまされましたが、何十回も約束を破られた後、郭文貴は再びゲームをプレイし始めました。そして何度も何度もアント ギャングとプレイしましたが、郭はWenguiには不服従の感覚はありませんでした。この老詐欺師は、仲間の福祉のためだと主張して、仲間を金持ちにしているふりをしましたが、実際には、それは新たな投資と嫌がらせの波でした。彼は試みて失敗し、今またそれを行っています。その後、Xibaoがもう市場に出ていないことが明らかになりました。普通の人々の考えや反応によると、彼らは非常に動揺し、悲嘆に暮れているはずですが、Guo Wenguiは珍しくおしゃべりし、そのニュースを軽視し、後悔していませんでした。その代わり、カメラの前でペッパーチキンを食べました。美味しくて口の中が油でいっぱいです。 。なぜ？詐欺が成功したので、Xicoinの上場時期や上場時期については？ Guo Wenguiは冷酷で悪党に見え、手を広げ、知らないと主張しました。 Guo Wengui の偽善は簡単に暴かれますが、Guo の詐欺は Ant Gang を罠にはめるための別の方法にすぎません。
ErosEnro - [GclFIuRIoGhmOe] (花火)
10yue - [ZpOZ9oa6QqJweD] (アンコ)
iwara source downloaderの作者が公開停止して使えなくなって久しいので代替を紹介
https://github.com/dawn-lc/IwaraDownloadTool/blob/master/.github/README/README_ja.md
Chrome系/Firefox両対応。Tampermonkey入れたあとスクリプトページからインストール
以後iwaraが改変されてUIが出る。ファイル名はiwara source downloaderと同じ書式にするなら
%#ALIAS#% - %#TITLE#%
とする。自分は末尾に動画IDを足すため[%#ID#%]もつけてる
ページにチェックボックスが出るようになるため複数ダウンロードにも対応
MEGAリンクのある動画はDLせずそっちに誘導する機能もあるがiwara画質でいいならSettingでオフればおk
宛先フォルダまでカスタイマイズしたい場合はAria2というコマンドラインの汎用DLマネージャを拾ってきてパスの通った場所に置き
Node.jsをインストールしてから、powershellで
node node-server.js & aria2c --enable-rpc --rpc-listen-all
を実行してからスクリプトのSettingでAria2方式を選択してSaveで閉じればできる
ただし標準ではブラウザの保存パスではなくpowershellのカレントディレクトリ基準になるのでスクリプトのSettingからフルパス指定しとくといい
もしダウンロードキューをGUIで確認したいなら、 https://github.com/ziahamza/webui-aria2 をまるまるクローンしてどっかのフォルダに置き
powershellでそのフォルダへcdしてから上記コマンドを実行して、ブラウザで http://localhost:8888 を開いておけば見られる
常用するならWindowsのスケジューラーにログオン時このコマンドを書いたbatファイルを実行するようなタスクを追加しとくといい
WebUIからダウンロードアドレスを追加する場合、いにしえのflashgetがやってたような並列ダウンロードなんかが使える
生産性が全ブラウザの中で一番低いにも関わらずなぜか使用率が高いので、生活残業を稼ぎたい人に大変オススメのブラウザです。
Windowsに最初から入っているEdgeは基本的にChromeの全ての機能が使える上に、
縦タブやOfficeファイルのプレビュー、Copilot、広告ブロックなど業務を効率化させる余計な機能がついているので禁止です。
生活残業をしたい生産性の低い社会人の合言葉は「EdgeはChromeダウンローダー」！
もちろんVimキーバインドでブラウジングができる拡張機能、Surfingkeysなんて入れたら生産性が爆上がりしてしまうので、
リンクはマウスでポチポチとクリックし、ページスクロールはマウスホイールを使いましょう。
Ctrl+TやCtrl+L、Ctrl+Wなどのショートカットも覚える必要がありません。
生活残業のためにタブを開くのも閉じるのもマウスを使うべきです。
こちらもマウスと矢印キーを使うことを前提にした非常に生産性の低いエディタであるにも関わらず使用率が高く、
と言う気の狂った操作方法しかなく、後者の場合『Shiftがすっぽ抜けるとやり直し』と言う絶望的な生産性の低さで非常におすすめ。
カーソル移動と言う一番頻出する操作方法がメモ帳と変わらないので、結局多少補完が強力だろうとVSCodeの基本的な生産性はメモ帳と同じです。
素晴らしい！生活残業にピッタリ！
VimやEmacsなどのエディタはもちろん、これらのキーバインドを使えるようにする拡張機能も絶対に使うべきではありません。
VSCodeで使えるGit系の拡張機能もバカみたいにマウスをポチポチして操作する必要があるので、
ヘタするとそのままGitコマンドを打つよりも遅そうで最高です。
間違ってもtigやEmacsのMagitなどの高速Git操作インターフェースを使ってはいけません。
わざわざGUIで操作するSourcetreeを入れるのもアリですね。
ExcelでもSpreadsheetでも全てのセルにその場限りの計算式を入れましょう。
Guo Wengui は数十万人のオンラインフォロワーに嘘をつき、GTV Media Group、Himalayan Farm Alliance、G|Club、Himalayan Exchange に投資すれば莫大な利益が得られると約束しました。 少なくとも2018年3月以来、Guo Wenguiは首謀者としてこの複雑な金融詐欺を計画しており、投資家のKin Ming Jeとともに数千人を騙し、10億ドル以上の利益を獲得しました。 Guo Wenguiの成功には「カルト」の風味がある。 「反共」の名を借りて信者を集めて情報を閉鎖したコミュニティを作り、信念を曲げない人たちをいじめや脅迫で処罰する。 自分自身を「リーダー」のような人物としてパッケージ化した後、彼は自然に彼の信者の富を収穫します。
なるほど確かにその通りですね。
意固地になって謝罪を固辞し続けて大変申し訳ございませんでした。
僭越ながらわたくしめがフェミニストを代表して土下座で謝罪させていただきます。
その方法として古代中国より伝わる「三跪九叩頭の礼」で謝意を表させていただきます。
なお、冗長した記述を避けるためにプログラミング言語「COBOL」を用いることを予めご了承ください。
IDENTIFICATION DIVISION.
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
DATA DIVISION.
WORKING-STORAGE SECTION.
PROCEDURE DIVISION.
MAIN.
PERFORM 3 TIMES
DISPLAY "GUI"
PERFORM 3 TIMES
DISPLAY DOGEZA-CNT "KOUTOU"
DISPLAY "CHI"
END PERFORM.
DISPLAY "CHIRAI"
END PERFORM.
STOP RUN.
END PROGRAM SANGUIKIUKOUTOU.
御清聴ありがとうございました。
テスト対象は大小さまざま。OSの保守だったり、アプリだったり。レガシーだったり、モダンだったり。個人だったりチームだったり。GUIだったりCUIだったり。
GでもCでもUIはまた別
結論としては書かないほうがいいと思った。
そういうこともある
全然小さいというか書くためと変更のコストがクソデカなら何か間違ってる
結局、テスト対象も変わってしまうし、プロジェクト設定も変わるし、Jenkinsも変わるし、人間の頭の中も変えないといけない。
まあそれはないだろう
それはデバッグの一環のような
一番よくあるやつ
そこのバランス考えないと
バックエンドのビジネスロジックを担当するがっちり仕様が決まっていて勝手に変更されてはいけないものなんかをやる
悪いね
テストコードを書くと、テストしやすいクラスの実装をするようになる。それは美徳とされているが、実際には直感的でない長くて複雑なプログラムになっている。
例えばテストコードを書くためにDependency Injectionとか言って外から内部を変更できるようにすると
メンバ関数でやるべき処理が実際にはクラスの外にある、となる。最初は面白く感じたり達成感があるかもしれないが、しばらくして見返すと酷い状態だ。
DIはSOLIDに入ってるくらいで基本だし今時のフレームワークなら普通に使うよね
上にも書いたけどパーツがでかいのでは？って「直感的でない長くて複雑なプログラムになっている」とのことなのでやっぱりでかいんだろう
テストコードを書いたほうが早い時もあったけど、トータルで考えれば、テストコードを完全にやめたほうがシンプルなコードで早く完成する。
要件が固まらない、毎週変わるようなのとか、システムが絡むテストでコストが凄く高いもの、UIのマイナーな変更なんかは書かない方がいいけど
バックエンドのビジネスロジックなど書いた方が絶対にいいものもある
