英語動画の日本語訳が見たいので20分ほどのオモチャを作った

DeepLにおんぶに抱っこです。本当にありがとうございました。

やってることは簡単で、Chrome標準機能の自動字幕文字起こしの結果をOCRで読み取ってDeepL翻訳かけてるだけです。
言い訳をしておくと本当にオモチャで、これ単体Jar出力してから、プログラムとして動かすとJava起動に時間がかかって遅いとか色々な問題があります。
実行画面にフォーカス戻ってくれないから連続実行できないとか。
でも処理としてループかけるとGUIを触るツール(マウスが動くタイプの自動化ツール)のため、自分のマウス操作が制限されるので避けたい。

詳しい人は内部的に引っ張ってきてDeepLのAPIに投げる→テキストに残してテキストのほうを順次成形して表示、って感じのやつを作って公開してくれると信じてる。(というかワシが欲しい)

環境：Windows１１
準備：Windowsの設定からディスプレイの設定を開いて、拡大率を100％にする。
　　　(Sikulixというツールの問題解消のため)
　　　Chromeの自動字幕起こしをON
　　　Sikulix2.05
　　　DeepLのデスクトップツール(動画じゃなくても入れておいて損しないです)

ソース(エラー出たらコメント削除してください)：
#マウス速度高速化

Settings.MoveMouseDelay = 0.05
#デスクトップ版DeepLのOCR起動ショートカット

type(Key.F8,Key.CTRL)
#Regionをプログラムウィンドウのオブジェクトからエリア取得しようとした時の残骸(多分いらない)

myApp = App("C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe")

#下のRegion()は自分の環境で修正してください。
#自動字幕起こしのウィンドウを範囲指定し、ドラッグドロップの動きで範囲選択を再現

regiontab = Region(20,1761,687,319)

with regiontab:

    drag(getTopLeft())

    dropAt(getBottomRight())

コント。ラスト。

画像処理はじまた。

嘘です。まだです。

メイクができないんだよねー。
難しいよねー。
こう、なかなか綺麗に仕上がらないんだよね。
一箇所を直すと他の場所で不具合がでてきたりね。

化粧のメイクとプログラムのメイクで何か作ろうと思ったけどなかなか思いつかないね。

仕方ないね。片方はしたことないもんね。

実習先にいく　→発展途上言語でＷｉｎ版がどうもバグってる模様→リナックス環境もってこい→ノートない→学校に頼む→藤田さんが用意　Σ(◞≼◉ื≽◟ﾟ;益;◞≼◉ื≽◟)マジカ！　→明日からscilabつかった配列計算の勉強ですね。

とりまＶＭ更新してＳＣＩＬＡＢいれた。イミフ。インターフェースきもい。

とりま慣れていきますよ。強力な簡易アルゴリズム実験機みたいなもんなんでね。

女の子とカラオケいきたい。←唐突


夏が終わったら。。。俺。。。。


フラグだけ立てとこう。

では。ノシ。

チャットシステムのシステム性向上のためにできることを考えてみる。

同時入力に対応する。

主に多重化という動作らしいが、厳密な部分は理解していない。
通信による割り込みがおこるソケット系の動作の特性を使ってサーバーの動作を一時的にウェイトするように設定する。
これを実現する上でソケットによるブロッキングを避けるためにノンブロッキングにするのだが、これがまたややこしく、チェック回数がソースをみるだけでも２回以上になっている。
少しでも回数を減らすためにサーバーを一時的に止めるようだ。

ついでにＦＤ増えるって言うね。

セレクト関数などを上手く使えばブロッキング時間ほぼなしで動作可能らしいが。。。難しそうだな。

とりあえず、現状だと同時入力に対して固まるか文字列がつながるかの２択なのでいかんともしがたい。

より効率的なアルゴリズムをくみたいが。。。仕様から勉強しないといけないだろうなぁ。。。

書き込みと読み込みのＦＤが分けられるということは入室時と入ってからのＦＤを別物、つまり、前者は構造体で後者は文字列にできないだろうか。

ゲームにしても文字列で送ったほうが軽いだろうが、管理は構造体がらくだ。

個人設定をさせておいて、その情報を構造体でいちいち送っていたのでは効率が悪い。最初にデータをサーバーに保存させてみてはどうか。

しかしサーバーの負荷を軽くするアルゴリズムも必要だ。

今のシステムでは正直時間がかかりすぎている。

一回のコマンドに平均１６０マイクロ秒。

文字列だけだと０．２マイクロ秒だったのでこれは明らかにｇｔｋとの相性もあるが、その処理時間にまで待ち状態を残してしまっているということだ。これは問題である。

つまり、こういうことだ。一人のＧＵＩがウェイトになればサーバーが解放されずに占有状態に入ってフリーズする。これはかなりまずい。

むつかしいね。

でもネットワークおもしろいよネットワーク。

プログラミングでわっほい。

コンパイル時の差をFEDRA、ubuntuの間に確認。開発はfedraのほうが有利なもよう。これは初めて知った。

Win７が自動的にシステムチェックを行い、VMwareのデータが破壊された。また、このような開発環境としてはプロ以上の７OSに搭載される仮想環境を想定しているのだろう。VMware自体もコンパイルできないレベルまで破壊されていた。

ウィンドウズの他OS駆逐作戦はいつまで続くのか。

LIN,WINどちらも古臭いOSだが、使い勝手は良い。個人開発レベルでは確かに管理ソフトがあれば楽だろう。

うむ。。。スクリプト言語に手を出したいが、勉強にならないため、また、特定の動作で早さがでないとのこと。後回しだ。

いろいろとあるが、やればやるほどCが最強に思えてくる。

objectivC（だっけか？）ってのはどのくらい強力なんだろう。

Cがオブジェクトになったら死角ない気がするんだが、基本的な考え方が違うだろうから不具合はありそうだ。

何にせよ、いろんな機能盛り込むならC#、JAVAが強力。

そもそもJAVAはいろんなことさせたときに初めて生きてくる言語だからなぁ。。。

ほとんどの仕様差を感じずにプログラムが組める。ここは流石だ。

っと。課題やらないといけないのでメモはここまで。

プログラムが組めればまたここに乗せるかします。

サードパーティーは確かにありがたいが、使いにくい。

これはやはり考え方が違うからか。今日はこんなところで。

では。