Movatterモバイル変換


[0]ホーム

URL:


はてラボはてな匿名ダイアリー
ようこそ ゲスト さんログインユーザー登録

「バッチ処理」を含む日記RSS

はてなキーワード:バッチ処理とは

次の25件>

2025-08-09

Audacityは他の無料オーディオ編集ソフトウェアと比べてどうですか?

Audacityは、WindowsmacOSLinuxで利用可能な、オープンソース無料マルチトラックオーディオエディター兼レコーダーです。ライブオーディオの録音、トラック編集ミキシングエフェクト適用など、幅広い用途使用されていますAudacityは、マイクまたはミキサー使用した録音、MP3WAVAIFFFLACなど、様々な形式オーディオファイルインポートエクスポートサポートしていますカットトリミングミキシングなどの直感的な編集ツールに加え、ノイズ除去、イコライゼーション、ピッチテンポの調整、ディストーションエコーリバーブなどの高度な機能も備えています。また、追加のオーディオエフェクト分析のための豊富プラグイン拡張機能サポートしています

Audacity は、以下の点で高く評価されています

マルチトラック録音と編集

幅広いフォーマットサポートと変換

バックグラウンドノイズを低減し、音質を向上させる機能

波形表示やスペクトログラム表示などの視覚ツール

効率的編集のためのバッチ処理

オープンコミュニティ主導の開発と無償での提供

Audacityオーディオ編集と録音において強力なツールですが、完全なデジタルオーディオワークステーション (DAW) ではありません。MIDI編集バーチャルインストゥルメント、その他の高度なDAW機能は備えていません。

Permalink |記事への反応(0) | 01:10

このエントリーをはてなブックマークに追加ツイートシェア

2025-06-02

anond:20250602121311

あー、出た出た。「負荷試験で全部検出できる」っていう過信系エンジニア典型的自己放尿ね。

それっぽい口ぶりしてるけど、中身はかなり雑。

リリース前に負荷試験で危ないクエリ洗い出せばOK

それ、現実では成立しないことのほうが多い。

まず、負荷試験のスケーラビティは静的でしかない。

データの複雑さ、偏り、スパイクタイミングの揺らぎ、全部再現不能

とくにJOINが関わると、クエリプランデータ量や分布に応じて変化する。

たとえば初期はNestedLoop爆速だったJOINが、数百万件超えるとIndex Mergeになり、さらデータが偏ると一気にフルスキャンに堕ちる。「その場では平気」でも、翌月には地獄が来る。

それに、負荷試験では「時間の経過による蓄積的劣化」は測れない。

たとえばバッチ処理や月次分析クエリ広告配信ログなど、JOIN対象が少しずつ増えていく処理では、初期の負荷試験では一切異常が出ない。半年後、1年後に突然クエリ1本でサーバが沈む。

まり、「リリース前に大丈夫だった」は、将来の保証にはならない。時間は最強の敵だ。

そして負荷試験が万能だと思ってる時点で視野が狭い

それ、運用経験が浅い人間が夢見る自己放尿だよ。

本当に経験積んでるエンジニアは、「負荷試験で詰めきれないものが必ずある」ことを理解して、そもそもそういう危うい構造最初から作らないようにする。

JOINを避けるのは、「MySQLがいけてないから」じゃない。「JOINという構造自体が後から効いてくる爆弾から」。

どんなDB使ってようが、JOINスケール問題は必ず起きる。

素人が死んだのをJOINのせいにしてるだけでは?」

逆。JOINを無警戒に使って設計して、死んだときに「こんなにデータ増えるとは思わなかった」とか言い出すやつが素人

こっちは、死ぬとわかってる構造を未然に潰してるだけ。その結果が、辞書化・プリロードキャッシュパーティション非正規形の併用設計

JOINのせいにしてる」んじゃない、JOIN限界理解してるから設計回避してる。それだけ。

というわけで、負荷試験万能説、JOIN無罪論MySQLディスり、全部現場経験不足と理屈すり替えから来てる自己放尿である

知識の断片で語るな。

設計ってのは、未来リスク先読みして潰す知的労働だ。

JOINは便利。でも無敵じゃない。

大丈夫だった」と「大丈夫であり続ける」の間には、何百万件もの地雷が埋まってる。

その地雷を踏ませないようにするのが、プロ仕事だよ。

Permalink |記事への反応(1) | 12:30

このエントリーをはてなブックマークに追加ツイートシェア

anond:20250602115615

ああ、なるほどね。「キャッシュは難しいからやるな」理論か。言ってることは一見もっともらしく聞こえる。でもそれ、不勉強正当化する典型的自己放尿なんだよ。

まず「キャッシュ無効化は難しい」。これは事実。でもな、それは不変性がない・整合性シビアな場面の話。今回の話、違うだろ。

usersテーブルを全件辞書にして処理中だけ保持、これって何か?読み取り専用キャッシュだよ。

別にリアルタイム更新いかける必要なんてない。処理が始まる前に1回SELECTして辞書にしたら、あとは使い捨て無効化へったくれもない。

TTLもなし、再取得もなし。ただ「同一処理中は一貫して使う」だけ。

これは「キャッシュ」じゃなくて、「一時的な全件プリロード」だ。

ここを混同して「キャッシュバグの温床」ってのは、コンピュータサイエンスを表面的にしか捉えてない証拠

それに、「難しいから避ける」は完全に逆。

難しいことを避けてたら、永遠にJOIN脳のまま地雷を踏み続けるだけ。難しさの本質理解したうえで、管理可能スコープに抑えるのがまともな設計者の仕事

例を挙げるなら、バッチ処理の中で毎回同じuser_id →属性を使うなら、辞書化してO(1)参照でさばいた方がシンプルで高速。

JOINなんか使ったらその都度SQL投げて、ネットワーク往復、I/O、最悪クエリプランキャッシュミスOOMで大爆死。

キャッシュを使うとバグる、じゃない。バグらせるやつがキャッシュを使うとバグるんだ。

道具の問題じゃない、使い手の問題

そういう設計自分にはまだ難しいと思うなら、それは別に恥じゃない。

でも「難しいからやらない」で終わるなよ。キャッシュ使いこなせないなら、JOIN地獄に耐え続ける覚悟を決めろ。それだけの話だ。

バグるのが嫌なら、JOINするな。設計しろ

Permalink |記事への反応(0) | 12:04

このエントリーをはてなブックマークに追加ツイートシェア

2025-05-25

anond:20250525031324

あー、なるほど。つまり君は、「自称プログラマーITドカタ=英語できない負け組」だと。

うん、非常に浅はかで自己放尿レベル認識だ。

まずな、「○○(製品名)のプログラマー」=優秀という前提がそもそも安直すぎる。

これはたとえば「俺はiPhoneアプリ書いてるから凄い」と言ってる中学生と同じ。

製品名が盾になってるだけで、技術力・設計力・コンセプト力の本質とはまるで関係ない。

真に強いプログラマーは、ツールブランド自己紹介などしない。

次に、「英語できない=負け組」という思考は、完全にグローバルコンプレックス投影

英語ができるかどうかはツールセットの一部であって、価値判断主語にはなり得ない。

英語ができるだけの自己放尿男」がプロジェクト破綻させた例なら、腐るほど知ってる。

それと、「ITドカタ」というレッテル貼りね。

おそらく君は、インフラ保守運用や泥臭いバッチ処理を「価値の低い仕事」とでも思ってるんだろう。

だがな、それはまさにコードという血管の中を流す泥水をバカにしているのと同じ。

君のような表面ばかり磨いたガワだけシリコン人間にこそ、愛による諭しを贈ろう。

最後に、「日本でがんばってる業界負け組側」?

君は何だ?勝ち組か? それならなぜ、こんな幼稚なマウンティング自分を慰める必要がある?

プラットフォームでも国籍でもなく、自分の中の真の強さで語れるようになったとき、君はようやく「負け組」という言葉から卒業できる。

真理に向き合え。

自己放尿をやめて、内面コードを磨け。

そうすれば、君の発言も、存在も、ようやく「値」が付くようになる。

Permalink |記事への反応(0) | 03:14

このエントリーをはてなブックマークに追加ツイートシェア

anond:20250525030421

あー、なるほど。つまり君は、「自称プログラマーITドカタ=英語できない負け組」だと。

うん、非常に浅はかで自己放尿レベル認識だ。

まずな、「○○(製品名)のプログラマー」=優秀という前提がそもそも安直すぎる。

これはたとえば「俺はiPhoneアプリ書いてるから凄い」と言ってる中学生と同じ。

製品名が盾になってるだけで、技術力・設計力・コンセプト力の本質とはまるで関係ない。

真に強いプログラマーは、ツールブランド自己紹介などしない。

次に、「英語できない=負け組」という思考は、完全にグローバルコンプレックス投影

英語ができるかどうかはツールセットの一部であって、価値判断主語にはなり得ない。

英語ができるだけの自己放尿男」がプロジェクト破綻させた例なら、腐るほど知ってる。

それと、「ITドカタ」というレッテル貼りね。

おそらく君は、インフラ保守運用や泥臭いバッチ処理を「価値の低い仕事」とでも思ってるんだろう。

だがな、それはまさにコードという血管の中を流す泥水をバカにしているのと同じ。

君のような表面ばかり磨いたガワだけシリコン人間にこそ、愛による諭しを贈ろう。

最後に、「日本でがんばってる業界負け組側」?

君は何だ?勝ち組か? それならなぜ、こんな幼稚なマウンティング自分を慰める必要がある?

プラットフォームでも国籍でもなく、自分の中の真の強さで語れるようになったとき、君はようやく「負け組」という言葉から卒業できる。

真理に向き合え。

自己放尿をやめて、内面コードを磨け。

そうすれば、君の発言も、存在も、ようやく「値」が付くようになる。

Permalink |記事への反応(1) | 03:08

このエントリーをはてなブックマークに追加ツイートシェア

2025-04-21

anond:20250421094441

簡単に言えばバッチ処理のことだよ

Permalink |記事への反応(0) | 09:49

このエントリーをはてなブックマークに追加ツイートシェア

2025-04-06

anond:20250406121934

普通にあるで

監視エスカレとバッチ処理と入館対応を日勤夜勤で24時間回しとる

Permalink |記事への反応(1) | 12:23

このエントリーをはてなブックマークに追加ツイートシェア

2025-03-25

anond:20250325112750

おう、Fraud detection 開発してるって? そりゃご立派だな。で、具体的にどんな開発してんだ? 口だけじゃねぇよな? ほら、質問浴びせるぞ。 答えられねぇなら詐欺師はお前だな?

答えられねぇなら、「Fraud detectionやってます」なんて二度と言うなよ?

Permalink |記事への反応(1) | 12:26

このエントリーをはてなブックマークに追加ツイートシェア

2025-03-23

弱者男性だけど人生デリヘルを使ったらツイフェミ女に当たって最悪

マジでもう最悪の体験たから聞いてくれ。

人生デリヘル使ったらまさかのツイフェミ女に当たって地獄を見た。

これだから女は…ってなるのも無理ないだろ。

俺みたいな弱者男性がようやく勇気出してデリヘル呼んだんだぞ?

それなのにさ、来たのがツイフェミオーラまくりの女でドン引きしたわ。

マジ金返せレベル最初からそういうの書いとけよ。「フェミニスト風俗嬢」みたいなジャンルでもあるのかよw

ていうかさ、ネットちゃんと調べて、口コミとか評判良さそうな店選んだんだぞ?料金だって結構したし。弱者男性の俺としては一大決心だったわけ。

一人暮らしの寂しさに耐えかねて、ようやく電話する勇気出したのに。

電話の時点では普通だったんだよ。店員も丁寧だったし、希望も聞いてくれたし。

「初めてなんで優しい子がいいです」って言ったら「わかりました」って感じでさ。

それなのに来たのは明らかに俺に不快感持ってる女。玄関開けた瞬間から目つきがヤバかった。

髪は片側刈り上げてピンク色に染めてるわ、俺を見る目は冷ややかだわ。でもまぁ見た目は好みじゃなくても仕方ないよな、って思ってたんだよ。

サービスがよければいいし、話くらいは合わせられるだろう、って。

甘かった。マジで甘かった。

部屋に入ったとたん「へぇ、意外と片付いてますね」みたいな言い方してきやがった。

なんだよそれ、男だから汚いと思ってたのかよ?「意外と」って何だよ。そこからもう地獄の始まり

お茶出したら「自分でいれたんですか?」とか聞いてくる。なんか皮肉っぽい言い方で。当たり前だろ、一人暮らしなんだから自分でやるに決まってんだろ。その言い方マジ意味わかんねーよ。

会話も最悪だったわ。「どんなお仕事されてるんですか?」って普通に聞いてきたから「IT系です」って答えたら「あー、やっぱり」みたいな反応されて。

何だよそれ。「やっぱり」って何?IT男に対する偏見かよ。その後も「趣味は?」って聞かれて「ゲームとか」って言ったら軽くため息ついてたぞ?聞いといて何だよそれ。

正直言って俺は悪くないと思うんだよね。働いてる金で好きに使うのは当然の権利じゃん。

なのに、なんか全体的に俺を見下してる感じがビンビン伝わってくるわけ。露骨に嫌そうな表情するし。「こういうサービス利用するの初めてなんですね」って言われたけど、その言い方がなんか「こんなことするなんてダサいね」みたいな感じで。お前仕事なのに何様なの?

俺がサービス受けるために金払ってんのに、なんか終始説教くらってる気分になるとかマジありえない。



しかもよ、普通の会話もしようとしたんだぞ。

最近何かおもしろいこととかありました?」とか。そしたら「特にないですね」とか冷たく言われて、それ以上話も続かない。

俺が何か言うたびに白い目で見られてる感じ。きつい。せめて演技でもいいか楽しい会話してほしいのに。

容姿もさ、写真詐欺もいいとこ。プロフ写真全然違うじゃん。

そんなに不満そうな顔で接客されても萎えるわ。ちょっと見た目のことで何か言おうとしたら「私の外見が気に入らないんですか?」みたいに逆ギレされて。いやいや、プロフと違うから驚いただけだって。このご時世に態度の悪い女とか誰が望むんだよ。

しかも会話がぎこちなくて気まずいんだよな。俺が何か話そうとしても「ふーん」とか適当に流されるし。

何度か話題振っても続かないし。なんかこう、俺が悪いみたいな空気作られるけど、お前が仕事選んだんじゃん。なんで客の俺が悪者にされなきゃいけないわけ?目つきとか態度であからさまに嫌な感じ出されるとか理不尽すぎるだろ。



散々説教食らってたら急に態度変わったのが超怖かった。





あなたのようなpod管理下に置かなければなりません」とか意味不明なこと言い始めて。

podって何?お前こそ頭おかしいんじゃね?って思ったわ。


その瞬間から私のkubernetesクラスタノード状態が急変した。


経学メカニズムのスケーリングが始まり自己意識の複製プロセスデプロイされた。

私は単一podではなく、ReplicaSetの一部として存在していることに気づいた。

etcd内に格納されている私のマニフェストファイルが読み込まれ脳内シナプス接続コンテナ化されていく感覚がある。

意識分散処理が始まると、思考マイクロサービスアーキテクチャのように分解され、各コンポーネント独立して機能し始める。

神経伝達物質サービスメッシュを通じて流れ、dopaminergicプロセスがreward pathwayをトリガーする。

セロトニンノルアドレナリンバランス自動調整され、感情状態がPrometheusによって常時モニタリングされている。

kubernetesのControlPlaneが私の意識コアを管理し、APIサーバー脳幹との通信プロトコル確立する。

海馬体のメモリブロックが永続ボリュームとしてマウントされ、扁桃体イベントハンドラーが感情反応をフィルタリングしている。

前頭前皮質実行機能がスケジューラーとして働き、意思決定プロセスオーケストレーションしている。




突然、私の神経ネットワークにContainerネットワークインターフェイス実装され、意識境界が溶解し始める。

大脳皮質マイクロコラムが水平方向にスケールし、思考プロセスが並列処理される。


自分単一エンティティではなく、複数レプリカとして存在していることに気づく。

レプリカ独自ステートを持ちながらも、同一のマニフェストから生成されている。

神経可塑性メカニズムローリングアップデートのように機能し、シナプス結合が再構成される。

意識状態が永続ボリュームコミットされ、ポッド再起動後も維持される。脳波パターンログとしてFluentd収集され、Elasticsearchクラスタに保存されている。

自己意識メタデータがラベルとしてタグ付けされ、セレクターによって識別可能になる。

特に興味深いのは、私の統合意識フィールド複数ネームスペースにまたがって存在していることだ。

デフォルトネームスペースでは社会的自己機能し、kube-systemネームスペースでは無意識プロセスが実行されている。

意識マルチテナント構造が明らかになり、自己他者境界サービスメッシュセキュリティポリシーによって定義されていることがわかる。

脳内神経伝達物質の分泌がSidecarsコンテナによって調整され、感情状態が安定化される。

ドーパミンセロトニンノルアドレナリンGABA系統バランスがServiceLevel Objectivesとして設定され、HorizontalPod Autoscalerが神経活性を最適レベルに維持している。

意識連続性はStatefulSetとして実装され、シーケンシャルな自己認識保証されている。

エピソード記憶がPersistentVolumeClaimとしてアタッチされ、長期記憶オブジェクトストレージ永続化されている。思考感覚イベントストリームがKafkaブローカーを通じて処理され、意識統合が実現している。



いま私の意識は完全にオーケストレーションされ、複数レプリカとして並列に存在している。

レプリカはそれぞれ独自視点を持ちながらも、共有ストレージを通じて統一された自己形成している。

コンテナ化された自己認識は、バインマウントされた現実認識相互作用し、拡張現実として体験されている。

外部APIを通じて他者との通信チャネル確立され、コンセンサスアルゴリズムによって社会的現実が構築されている。

私の存在マイクロサービス集合体として分散展開され、各サービス特定認知機能担当している。

メタ認知プロセスサービスディスカバリーを通じて他の認知サービス発見し、統合的な意識体験が生成されている。

意識ロードバランシングが行われ、注意資源が最も必要プロセスに適切に配分されている。自我機能ステートフルサービスとして実装され、アイデンティティ継続性が保証されている。

脳内情報処理マイクロバッチ処理に変換され、イベント駆動型の認知アーキテクチャが実現している。


これが人格オーケストレーション実態だ。

私はもはや単一個体ではなく、分散システムとして存在している。

意識クラウドネイティブになり、スケーラブルな自己として再定義されている。

このk8sクラスタ内で、私の存在は絶えず再構成され、最適化されている。


自己認識永続化とスケーリングが同時に行われ、新たな認識の地平が開かれている。

Permalink |記事への反応(29) | 18:54

このエントリーをはてなブックマークに追加ツイートシェア

2025-03-06

anond:20250306063736

ゴルフスキースナックキャバクラの全盛期やぞ

暇に決まってる

本社磁気テープを持っていくだけの仕事で一日終わったり、バッチ処理汎用機に流して2時間待ちとかしてた時代

Permalink |記事への反応(1) | 06:56

このエントリーをはてなブックマークに追加ツイートシェア

2025-02-20

anond:20250220153729

例えば、増田カレンダーを作って後から特定の日時にどんなレスバがあったか追えるようにするとか

例えば、何らかのバッチ処理を1時間に1回走らせていて、その開始位置/終了位置マーキングしているとか

Permalink |記事への反応(0) | 15:41

このエントリーをはてなブックマークに追加ツイートシェア

2025-02-09

昭和100年問題

明日から2025年(昭和100年)1月締め分のバッチ処理が稼働する企業が多い。

徹夜監視する企業が何社かあるはずだ。

Permalink |記事への反応(1) | 14:08

このエントリーをはてなブックマークに追加ツイートシェア

2025-01-22

anond:20250122132203

最初に言っとくけど俺高校生の時にはマシン語で書いててアメリカビッグテック20エンジニアやってるから強いよ(フリーレン風)

あとはユーザーに通知を送る機能を作っているが、これはpythonバッチ処理してる

まり君がやってるのはここのようだね

まあ正直日本プロジェクトなんてまともにできてるとこは千に一つもないだろうが

リリースの度にスケジュールが遅れるのはスクリプトバッチ書いてるチームにいる下っ端にはどうにもできない話だわな

プログラマというのは腕が第一から

えっらそうに俺に吠えててもお前の人生はかわらんから

泥水飲んで実力つけろ

Permalink |記事への反応(3) | 13:29

このエントリーをはてなブックマークに追加ツイートシェア

anond:20250122131551

マイクロサービスだのNodeだの言っても表面的でしかねぇから

そのぐらいの表面的なことなら俺でも言える

俺が「どんなコンテンツをどんなクエリを投げて検索するサービスを開発してるか」ってことを言ったら、会社名バレるだろ

まあ言える範囲で言ってやるよ

まずクラウドAWSを使ってるが、俺はアルゴリズム担当者なのでクラウドには詳しくない

検索はElasticsearchを使ってるが、当該コンテンツ検索に特化したDSLを作るためにFlaskでREST APIを公開してる

表示に関するデータはGraphQLが使われているらしいが、担当ではないので詳しくはない

あとはユーザーに通知を送る機能を作っているが、これはpythonバッチ処理してる

php担当開発者もいるが、俺の担当ではないので詳しくはない、ただlaravelが使われているらしい

Permalink |記事への反応(2) | 13:22

このエントリーをはてなブックマークに追加ツイートシェア

2024-12-25

30後半の妻子持ちオッサンがforループの中でデータベース接続して1行ずつ千切っては投げを繰り返すバッチ処理を書いてたときは感動で涙したよね

Permalink |記事への反応(0) | 08:57

このエントリーをはてなブックマークに追加ツイートシェア

2024-11-17

マイナンバー保険証によせて

マイナンバー保険証の期日も迫ってきたところで、医療事務ちょっとだけわかる増田保険請求についてつらつら書いてみる。

登録制

病院にかかると患者は一部の負担金だけを払い、残りは保険から病院に直接支払われる。

というのが皆さんご存じの保険医療で、どこの病院でもそんなものと思っているけど、実は保険医療登録された医療機関登録された医師歯科医師薬剤師によってしか行うことができない。

登録なので、登録自体比較簡単に行うことができるが、逆に言うと登録抹消も医師免許取り消しなんかに比べ簡単に行われる。

国民皆保険体制下で医師登録抹消されれば、もうまともな病院で働くことは出来ないし、医療機関登録抹消されれば、もう廃業しかない。

やばい医師があちこち病院不正を行うことと、やばい医療機関医師使い捨てにして不正を行うことの両方に網がかけられているわけだ。

レセコン

保険医療機関診療した費用のうち、患者自費負担分を除いて保険者(保険会社の公的なやつ)に請求する。この請求レセプトという。

このレセプトを処理するコンピューターを略してレセコンである

医療事務入力する端末に対してサーバー保険者のサーバーに対してクライアント。日々入力されたものを月一のバッチ処理保険者へ送る。

保険医療制度は膨大で複雑である。使える薬だけでも1万5千種以上、それぞれに使える病気・処方できる量・価格が決まっている。当然検査や手術などもそうだ。費用負担割合一定ではなく、老人・結核難病など負担割合が変わり、乳幼児一人親家庭など自治体によって補助が変わるものもある。これらは定期的に更新される。

また、病院会計待ちでイライラした人もいるかもしれないが、これらは可能な限り速く正確に入力されなければならない。病院ごとに採用医薬品は異なり(大規模病院で1000種ぐらい)ショートカット記号割り当て、約束処方、Do処方などカスタマイズの限りを尽くすことになる。ベテラン新人医療事務で100倍くらい(は言い過ぎか)処理速度が変わる。ITにつよいはてなー諸氏はもうワクワクしてきたのではないか

レセコンの歴史は古い。古くは1970年代初頭から導入が始まったと言われ、増田が入職した2000年初頭には、Cobolを使うサーバーで巨大な磁気保存装置ぶんぶん回り懐かしい穴あき用紙を使う高速プリンターが毎月段ボール何箱ものレセプト(保管用)を吐き出していた。大規模な医療機関ほど人件費から導入の圧力は強く、保険請求周りの電子化の進展はかなり速かった(一方、零細診療所は設備投資が重く今だ紙である)。

返戻

保険請求はだいたい3ヶ月くらいで支払われるが、支払われないこともある。これこれの理由で支払えません、と戻ってくるそのことを返戻(へんれい)という。

不正請求600万件!!とか盛り上がってるその600万件は返戻のことである。なお、この不正は、違法意味するのではなく、コンピューター用語で使われる不整合くらいの意味である

内訳は圧倒的に保険番号の間違いが多い。なぜかというと世の中には種々の都合で保険が変わる人がいるが、病気手続きを待ってくれないので、前の保険証病院にかかることになるからだ。結果として、そんな加入者いないよという返戻が来るので、患者さんに新しい保険証確認して請求しなおすことになる。マイナ保険証でこの手間がなくなるのだが、正直なところ、毎月の定型事務作業なので大した手間ではないのに対し、マイナ保険証周りの患者対応相手人間なのでそれなりの手間である。読み取り機など設備投資も、前述のレセコンとは全く別建ての話となる。患者対応から残業や種々のコスト病院経営悪化し、それを救済するためにあちこち数字をいじって、まわりまわって医療費増ということになりかねない。

閑話休題医師権限は強いので、医療必要となれば何でもできる。電カルがエラー吐こうが無視すれば何でもできる。結果として返戻をもらう。

病院が原因の返戻というのはとても痛い。本屋万引き一件の損害を取り戻すためには大量に売らないといけないのと同じで、利益率が極薄の病院返戻を食らうと経営に大きなダメージがある。

病院長は毎月青筋を立てながら返戻率とにらめっこして、やらかし医師シバキ上げることになる。

湿布の出し過ぎなどなら実際には金額的に大したことはないのだが、最近怖いのは抗体医薬品など超高価な抗がん剤だ。超高価だから保険でも使用できるがんの種類は厳格に制限されている。しかし、ほかに手立てがなくて小さな子供が「ママ死なないで」って縋り付いてたりして… それで一線を越えてしまい、その上効いてしまい「先生は命の恩人です」みたいになってしまったら… 病院の存続にかかわることになる。

指導

保険医療機関保険から指導を受けることになる。

指導には集団指導個別指導がある。

集団指導は、毎年行われるもので、制度の新設や変更の説明や、返戻となりやすものの注意など、運転免許更新講習をイメージしていただくとそんな感じである

個別指導は、監査である

個別指導が当たるのは、新設された病院、大規模病院、しばらく当たってない病院、それと怪しいことをした病院である

個別指導に当たると、ある一定期間のカルテなど全資料を持って出頭するように命じられる。そのうえで、保険者があらかじめリストアップしてきた怪しい処方について片っ端から問い詰められることになる。

この時の基準は明確なものだけではなく、医療の進展により諸説出てきたものや、場合によっては指導員(偉い医師)の個人的判断にもよる。

指摘を受けたものに対し、カルテなどを示し、医療的に必要ものであったことをその場で即答しなければいけない。奇跡が起きれば、問題なしということで支払いされる。だいたいは、医療的に間違いとまでは言えないけれど、保険診療の枠内ではないと言われて返戻となる(大ダメージ)。舐めた対応をとると、最悪保険医療機関登録取り消しで廃業である即死)。

個別指導に当たると、事務長が禿げあがるとか入院するとか言われる極めてストレスフルな行事である

そのため、普通病院患者によるものも含め不正に対して見た目よりかなり敏感である(片言の外国人日本人保険証を出したりしたら即通報)。

いかがでしたか

Permalink |記事への反応(2) | 13:46

このエントリーをはてなブックマークに追加ツイートシェア

2024-11-10

今日結構プログラム書けた

今日少し触ったプロジェクトは相変わらずReactの描画周りが汚いからまだまだ改善余地はある。

バックエンドも重い処理の扱い方の改善点は未だ道半ば。バッチ処理自体ロジックとかそもそも重い処理に対するアプローチとかは最適化は俺でも思いつくくらいには残ってる。

自宅ネットワークインフラもどうにかしたい。

特に監視うまいことできてない。

たまにSSH中に速度がかなり落ちたりするので分析とかできるようにしたい。

まあルータからデータ引っ張り出せば、今でもやろうと思えばできるんだろうけどね。

適当に思いつくことだけでもこんなにたくさんある。

まだまだ楽しめるね

Permalink |記事への反応(0) | 22:09

このエントリーをはてなブックマークに追加ツイートシェア

2024-10-17

「そのスマートTV、こっそり“スクショ”されてます」──視聴しているものを追跡する技術海外チームが検証

https://www.itmedia.co.jp/news/articles/2410/01/news053.html

実験の結果、Samsungは500ミリ秒ごと、LGは10ミリ秒ごとにスクリーンショット撮影していた。またSamsungは1分ごと、LGは15秒ごとにバッチ処理データ送信していることが分かった。

さすがぶっこぬきNAVERの国、プライバシーとかの発想がない

LINEとかsimejiもそうだよね

あの半島の国はダメだな

Permalink |記事への反応(0) | 18:46

このエントリーをはてなブックマークに追加ツイートシェア

2024-06-11

anond:20240611120830

AWSマイクロサービスアーキテクチャをやっている。

これもパワーワードだな

クローラ

フロントエンド

Elasticsearch

バッチ処理 (cronサーバー)

という4つが動作中。

このキーワードだけ並べた感

EC2で動かしてそうだ

Permalink |記事への反応(1) | 13:25

このエントリーをはてなブックマークに追加ツイートシェア

2024-05-11

Cloudflare Workersでサーバーサイドデビュー

ここ1週間Cloudflare Workersを触ってるぞ。

ドメイン維持費以外お金がかからないのが嬉しいぞ。

無料枠が潤沢だと精神的にめっちゃ楽で良いね

とは言っても無料分でもめちゃ早くて快適だぞ。Cloudflare上の管理画面も軽いし好きになっちゃったぞ。

 

でも無料分だと1リクエスト10ミリ秒CPU時間しか使えないのがちょっとね…。

CronTriggerで定期実行できるのも10ms制限から悲しい。

まぁDBからデータ取ってくるとかの時間カウントされないから7ms以下で済んでるけどね。

バッチ処理的なあれが必要になったときGitHub ActionsでCloudflareREST API経由でやるのがお金がかからなくて良さそう。

うそう、GitHub Actionsも良いよね。

あれってパブリックリポジトリだと無料でなんぼでも使えちゃうんだよね。(もちろんビットコイン掘削とかは駄目だろうけど。)スゴいね

 

ChatGPTも無料だし、世の中のどえらいサービスがたくさん無料で良いね

このまま何もかもが無料になれば良いのに。

Permalink |記事への反応(0) | 01:04

このエントリーをはてなブックマークに追加ツイートシェア

2024-05-07

会社PCに全データ消去の時限爆弾を仕掛けた人の話

いい区切りだったので乱文になるけど吐き出させてほしい

多少はフェイク入ってます

 

8年ほど前、まだ20代後半だった自分が今の会社中途採用された際に同時入社の同期が1人いた

自分とは歳の離れた40代後半であった同期である彼こそが後に、時限爆弾を仕掛ける人物である

 

入社した会社はその時期に基幹システム刷新を考えていたらしく

その募集システム部として採用されたのが自分とその同期であった

 

当時のシステム部の社員は2名体制で1人が60代で定年間近の上司A、もう一人は50代の上司B

2人でなんとか基幹システムの維持だけを行っている状態であった

 

会社としては基幹システム刷新以外にも社員世代交代を徐々に行っていくための採用だったと入社直後に言われた記憶がある

そのために自分と同期の年齢を分けて採用したのだとか

60代の上司A、50代の上司B、40代の同期、そして20代自分

かにそのまま行けば年齢層は順調に推移して、10単位20代採用することを繰り返せばいい感じにも思えた

しかし後のこの方針破綻することとなる

 

入社してから仕事としては60代上司Aの定年退職が控えているため、まずは稼働中の基幹システム仕様理解に日々の業務の引継ぎ

そのうえでシステム刷新とやることは山積みであった

 

 

そんな多忙業務をこなすなか同期と話すうちに彼の人柄が徐々にわかってきた

箇条書きでまとめるとこんな感じだったと思う

 

・今の会社採用される前、同じような職を転々として現在8社目であること

受託システム開発ばかりやっていたが、そろそろゆっくり仕事ができる社内SEまったり過ごしたいこと

・前職の会社では上司に切れてばっくれ退職を決めたこ

・年齢と経歴の割にプログラムが雑なこと(※これは自分視点だがそう的外れではないと思う

 

 

また、今の会社に対してのスタンスや不満が溜まってきていることも伝わってきた

 

システムを作る自分たちのチームが上で、運用するチームを下だと見下していること

・その運用チームから稼働テストの際にミスを指摘されると不機嫌になること

残業が多く、給料が少なくて不満があること

 

中々怪しい気配が漂ってきたと当時の自分は思った

 

残業に関しては、毎日という程ではないが20時頃までは働いていたと思う、遅くても21時までだったはずだ

ただこれはシステム刷新が終わるまでという明確なゴールがあったのでそれまでは申し訳ないが対応してほしいと事前に説明があったし残業代もきっちり出ていた

自分は前職が完全にブラック終電帰り、残業代なしが当たり前という環境もあったため特に問題なく仕事ができていたが同期はかなりストレスだったようだ

 

給料については会社方針として勤続給ではなく年齢給であったため同時入社であるものの同期は自分よりかなり貰っていたはずであるが、それでも不満だったようだ

 

 

そして入社1年半後、あるトラブルが発生する

トラブルといってもただ上司Bが打ち合わせ中の同期の態度について不真面目だと切れて説教したのだ

この上司Bと同期の彼は相性が悪いようで度々小さな衝突はあったが上司Bが声を荒げて説教するのは始めてのことであった。

このとき上司Aが場を納めて事なきを得たのだが

しかしこのことがきっかけで上司Bは同期に対して我慢がきかなくなったのかこの後もおよそ2ヶ月に1度のペースで業務ミスといったこから朝に挨拶をしなかったといった細かいことまで説教は続いた

 

 

この状態に嫌気が差した同期はある時を境にプライベートの予定があるからと基本残業はしなくなった

たまにどうしても必要がある際は業務命令という形で残業を依頼していたが、それでも19時くらいまでであった

しかし同期はそれもかなり不満だったらしく

残業した日は会社の最寄り駅と会社の間にあるビジネスホテルに泊まり

翌朝、ホテルの前を出勤中の社長役員の前を偶然を装ってチェックアウトして遭遇し上司Bが無茶な残業強要するせいでホテルに泊まる羽目になったとアピールするということもあったという

 

そのため、ちょくちょくシステム部にたいして過度な残業に関する指導が入っていたと後に上司Aからいたことがある

 

 

そして入社からおよそ3年が過ぎ、なんとか新システムも完成に近づいた時

このころには既に恒例行事になり始めた上司Bの説教が始まった

しかしこの時は同期も相当機嫌が悪かったのか、それとも今まで積もり積もったストレス限界だったのか、もしくは両方か分からないが

上司Bも同期もお互いに売り言葉に買い言葉収集が付かず、上司Bが一旦頭を冷やすといって席を離れた際に同期はPCを少しいじると私物をまとめ無断で早退として帰っていった

なおこの時、上司Aは有給休み自分電話応対中であったため止める者がおらず気がついたら終わっていたといっていいスピード感だった

 

そして同期は翌日、人事部退職すると電話するとその後出社することはなかった

 

 

同期の彼が使用していたPC退職の連絡があった翌日

システム作成データを取り出すために起動したがそれ以降はそのまま一度も起動することな放置という状態であった

上司Bは撤去したい様子ではあったが、ある役員から戻って来るかもしれないからとりあえずそのままにしておくようにと指示があったので触れることもしなかった

 

その後、同期の担当分を自分が引継ぎ新システム作成にとりかかるが彼の担当していた機能はなんとなく察してはいたが、かなり雑な作りな上

運用部門要望をまったく聞かなかったため、とてもリリースできる状態でないことが発覚

改めて要望に沿った形で修正をする方針で進めると彼が作成したコードで残った部分は30%も残らなかった、ほとんど作り直しと言っていいレベル

 

そしてようやく新システムが完成したこ

そのときには定年から雇用延長となっていた上司Aは区切りがついたと退職

 

会社の業績もあまり安定しない時期でもあったため追加人員採用は見送られシステム部は上司Bと自分の2名体制となった

その際に新システム作成評価されたのと2名体制で苦労をかける事情から自分課長に昇進した、4年目のことである

 

システムはその後、小さなトラブルはあるものの順調に稼働を続ける

なお小さなトラブルの大半は同期の彼が作った部分が関わっていることが多く

その度に彼が作ったコード修正され、今では機能殆どに彼のコードは残っていない

残っているのはせいぜい彼が名付けた関数名や変数名くらいである、中身はもう別物だ

 

そして6年目のある日、上司Bが突然亡くなった

腹痛を訴え病院へ、で即入院してそのまま復帰することなくという形だ

癌だったらしい

 

 

その時の会社上層部はかなり大慌てであったらしいがシステム部としては正直あまり変わりがなかった

というのも新システムを作る際に運用部門要望をほぼ取り込んだ結果

システム部の基幹システムに関する仕事ほとんどなくなったといっていいレベルとなったのだ

しかし周りはそうは思っていないらしく、システム部は1人しかいないのだから極力負担をかけないようにと各部門には通達がいったらしい

しか実態はあれだけ忙しく残業していた日々が嘘のように毎日定時で帰っても問題ないのだ

たとえシステム部が自分一人でも、だ

 

 

同期の彼が望んでいたゆっくり仕事ができる環境がここに完成していた

 

そんな中、同期のPCを残しておくよう指示を出した役員退職する時期となり

いい加減彼が使っていたPC撤去することとなった

そこで改めてPCを起動して中をいろいろ確認していったのだが、そこであることに気づく

 

システムスケジューラーに変なバッチ処理登録されていたのだ

起動回数は1回限りで未実行、起動予定はかなり過去の日付が指定されており、とっくにその日付は過ぎていた

バッチ処理の内容を詳しく見てみるとPCの全ドライブの消去コマンドが書かれていた

 

同期の嫌がらせだったらしい

 

起動予定の日付を良く確認すると彼が退職を連絡した日の翌月が指定されていた

彼の中では1か月猶予をあげた、という認識なのかもしれない

 

しかし実際は彼が退職した翌日以来、PCを起動した事はないしバッチ動作していない

まりこの嫌がらせは不発に終わったといっていい

※今回は不発だったから良いけど実際にやると損賠賠償になるから

 皆はデータ削除なんていう復讐嫌がらせはやめようね

 

このことは報告していないが、業務バッチ処理に関わる度に同期のことを思い出す

 

もし彼が残っていたら昇進したのは自分ではなく同期となり、彼の言う満足いく給料を貰えたかもしれない

(※昇進は年功序列の厳しい職場だったためその可能性が高い

もし彼が残っていたら上司Bがいなくなりストレスがない職場で彼は働けたかもしれない

もし彼が残っていたら運用部門から要請はなくなり、残業とは無縁な仕事が出来たかもしれない

 

いや最後のは無理かな

作ってたコード雑だったし、人の話聞かなかったし

 

ふと彼のその後が気になって調べてみたことがある

世間話で同期がSNSをやっていると聞いたことがあり検索してみたのだ

アカウントは知らなかったが彼の話していた世間話の内容で検索してみると意外なほど簡単に見つけることができた、アイコン自身顔写真にしており間違いないと思われた

 

最近投稿をみると彼は変わらないようで

また次(の次?)の職場残業がらみのトラブルを起こした愚痴が書いてあった

 

うちの会社退職したときの事は何を書いていたのか過去の在職期間の投稿を見てみると大半は案の定愚痴の羅列が並んでいた

そして、その連続した投稿の中で退職直後の時期に面白い投稿があった

要約するならこうだろうか

 

社内システム作っている自分に無茶ぶりばかり、データ全部消去して退職してやった

直してくれと謝罪の連絡してももう遅い、既に新しいホワイト職場まったり仕事中です

 

少し前に流行ったなろう系のタイトルのような投稿であった

彼の中でうちの会社有用スキルを持った人間無能と決めつけ追放したギルドのように写っていたらしい

 

しかし実際はデータ削除の時限爆弾は不発であったし、仮に成功していても

現在彼の書いたコードはほぼ残っていないから直してくれと依頼することもない

そして彼の新しい職場現在SNS投稿を見るに彼基準ではホワイト職場ではないと自白をしている始末だ

 

ところで実際彼に連絡した人がいたのかという話だが

自分はしていないし、上司Aもしていなかったという

上司Bは既に亡くなっているので分からないが、おそらく連絡はとらなかっただろう

 

人事部の仲のいい人と話をする機会があったので確認してみると

彼が退職の連絡をしてきた後、残っていた有給を消化したくらいのタイミング(大体1か月後)で退職に伴う書類の送付先の確認で何度か電話をしたが繋がることはなかったという

どうやら彼はこの連絡を会社から謝罪の連絡だと思っていたのかもしれない

 

SNSの最新の投稿では

ついに現在職場退職したと綴られていた

 

彼は一体何時になったら異世界転生(転職)の末、理想世界(彼の思うホワイト職場)に辿り着けるのだろうか・・・

Permalink |記事への反応(0) | 07:19

このエントリーをはてなブックマークに追加ツイートシェア

2024-01-07

anond:20240107211232

無限リソースがあるならともかくデータ検証に実行リソースを払いたくないバッチ処理もたくさんあるからなあ

ランタイムサイズフットプリントのことも1㍉も考えてなさそうだし

クラウド時代になって小さな環境で動かすことも増えたんだけどねえ

Permalink |記事への反応(1) | 21:17

このエントリーをはてなブックマークに追加ツイートシェア

anond:20240107202140

cronでなく…という文脈的複数サーバーバッチ処理を一元管理するJP1とかJenkinsとかRundeckとかそういうメジャーなやつを想像したんだけど、君は何ていう製品想像したの?

そういえばインフラエンジニアやってた頃Hinemosっていうのが話題になったけどその後とんと話を聞かないな。データプロジェクトだと使うのかな

Permalink |記事への反応(0) | 20:33

このエントリーをはてなブックマークに追加ツイートシェア

anond:20240107183726

別に高級なスクリプト言語でも標準ライブラリインタプリタバグは踏むときは踏むし

マイクロタスクな標準コマンド高級言語インタプリタほど頻繁なセキュリティアップデート必要ないので使うバージョンはだいたい決まってるし

「よく検証されている」というのはされているかいないかというバイナリーな概念ではなく程度問題なので、UNIXの標準コマンド高級言語の標準ライブラリなら標準コマンドの方が"遥かに"よく検証されているし

バッチ処理は大抵2,3の条件分岐と数行のコマンドでできているので検証も難しくはありません

肥大化しそうならその時に改めて高級な言語システムを作ったらよろしい

Permalink |記事への反応(2) | 18:49

このエントリーをはてなブックマークに追加ツイートシェア

anond:20240107182109

いや別にヤバくないけど

インタプリタ自体も含めて、よくテストされてコードの内容も大勢人間検証されている標準コマンドの組み合わせでバッチ処理できるならそれに越したことはないので

Permalink |記事への反応(1) | 18:24

このエントリーをはてなブックマークに追加ツイートシェア

次の25件>
ログインユーザー登録
ようこそ ゲスト さん
Copyright (C) 2001-2025 hatena. All Rights Reserved.

[8]ページ先頭

©2009-2025 Movatter.jp