「サーバ」を含む日記 RSS

はてなキーワード: サーバとは

2025-03-13

基本情報を持ってる人に サーバIP アドレス 192.168.1.5/24 だったら、そのネットワークアドレス CIDR 24許可設定してほしいって言ったら、通じると思うじゃん?

なんで通じないんだよ……



ブコメへの反応を追記

ACL なんぞ BIND やら Apache やら DHCP やらサーバでも扱うもんだろ。

なんでネットワークスペシャリストが出てくるんだよ。疎通確認 NGとき、どうやってトラブルシュートするん?

そもそもネットワークアドレスとか、基本情報範囲内でしか話してないよ。

病院内で提供されるWiFi挙動メモ

身体を壊して先日ちょっと入院していたのだが、病院内ではWiFi提供されていたので、消灯時間外の日常生活アクセスはそれのお世話になっていた。消灯時間は夜9時から朝6時までだ。

事前に「入院生活にそぐわないサイトには接続できません」という告知が為されていたので、覚悟の上で使ったのだが、Webアプリ開発者としての業務必要サイトとかも禁止されていたので、ここにメモしておく。

どうせ数年以内には持病が悪化して再び入院するし。

通信制のしくみの考察

通信禁止されていると思われるサイト接続すると、ブラウザ側ではタイムアウトエラーとして表示される。もちろん、それなりに待たされる。ブラウザの開発ツールの様子を見るに、おそらく TCP handshake に失敗していそう。

正常に接続できるサイトの様子を見た範囲では、HTTPS接続証明書改ざんは行われていないようだったこからHTTPS暗号を解読してどうのこうの、という処理をしていない可能性が非常に高い。つまり通信制限は接続ドメインまたはIPアドレスによる判断実施している可能性が高い。

また、中間的なサイト存在する。通常2秒以内で表示できるようなサイトの表示に10秒(体感)かかるところがある。稀にタイムアウトする。

なのは通信禁止されていそうなサイトでも「待たされた挙句、つながることが非常に稀にある」ということと、curl等ではすんなりと接続できることである

DNS設定と一緒にproxy設定が落ちてきているのであればこの挙動理解できるのだが、手元のOSネットワーク設定にはproxy情報が何も出てこない。ちょっとよくわからない。

もしもDNSに対するAレコード(AAAAも?)問い合わせに対してニセモノを返すという仕組みで通信制限しているのだとしたら、「非常に稀につながる」挙動にはならないはずなので、透過型proxyによって頑張っているのではないか想像するところである

なお、消灯時間中は全てのリクエストタイムアウトになる。消灯時間開始直前に HTTP Request を送出して、応答が来る頃には消灯時間に入っている場合にはどういう挙動をするのか、というテストをやる暇は無かった。スマソ

つながるサイトと、つながらないサイトメモ

業務で使う全部のサイト検証できた訳じゃなくてゴメンね。結局のところ仕事携帯回線でやっちゃったから。

ドメインサイト概要接続の様子
hatelabo.jpはてな実験サービス置き場すんなり
anond.hatelabo.jp増田禁止
??????.hatenablog.jpはてなブログドメインの一つ、そして増田中の人ブログ遅い
console.aws.amazon.comAWS管理コンソール禁止
www.amazon.co.jpショッピングめちゃくちゃ遅いけどつながる
www.amazon.comショッピングめちゃくちゃ遅いけどつながる
ja.wikipedia.org百科事典禁止
www.php.netプログラミング言語PHP禁止
www.typescriptlang.orgプログラミング言語TypeScriptすんなり
stackoverflow.comプログラミング質問サイト(英語)すんなり
qiita.comプログラミング質問サイト(日本語)禁止
packagist.orgPHPパッケージ管理遅い(通常通り?w)
www.npmjs.comJSパッケージ管理すんなり

なお、自分ドメインサブドメイン禁止ドメインを入れたようなもの、例えば anond.hatelabo.jp.example.com のようなドメインに対する接続可否は検証していない(面倒だったw)

どこの会社受託しているのか?

サーバ目線で見える client IPwhois等で調べると、某F社さんだった。AWS管理コンソールへの接続禁止するあたり「あっ…!」と思ったり…w

2025-03-09

メギド72というソシャゲ今日サービス終了しま

オフライン版で遊べます

と聞いて1週間前に始めました

サービス終了前だからといってガチャ大盤振る舞いとかは全然なく、静かでした

ただ今日日付が変わったくらいのときオフライン版のデータDLのせいでサーバが重くなってました

それくらいです

このソシャゲガチャキャラめっちゃ出にくいです

クソみてえなアイテムが出まくります

キャラが出るのが当たりって感じです

キャラが10%の確率で出ると書かれてたガチャを、一生懸命ためた石で10連したのに一人もキャラがでないときマジでクソだと思いました

2025-03-05

サーバサバサバサバw

サバサバパワーで若い男を魅了するサバねえ

「黙れ」?そんなの知らないサバ

2025-02-24

anond:20250220202010

悪名高き?パルワールドピーク時のサーバ代が月7000万円

https://x.com/urokuta_ja/status/1753318561991532756

同接は185万人らしい


規模が違いすぎるけど、YouTube運営費用は月180億円らしい

180億かかってても重いときは重い


たぶん今のインフラ力だとVRに本格的に手を出せないんだと思う

とら婚は「オタク同士で結婚できる」とかい誇大広告をやめろ

オタクオタク結婚できる可能性は、極めて少ない。ガチャ未満

なぜなら、登録するととら婚の登録者だけでなく他の相談所の人もいる、IBJ大海に放り出されるからである

MMORPGで例えるなら、IBJというゲームにとら婚サーバからログインしたようなもの

登録すると1月あたりに20人分のお見合いの申し込みができる

毎月1日に20回分付与されるのだが、1日で使い切らず週ごとに何人かに分けて申し込むように言われた

回数はさておき、その中からオタクを探せと言うのだ。無理

「この人はとら婚の人です」みたいな注釈とかは載っていない

からといって、非オタ女性プロフィールから判断して申し込んだとしても

翌日に断られるか、返答期限の10日間を過ぎて自動的お断りされる

1か10かで断り続けられ1年、写真の撮り直しやプロフィール修正も何度もやった

金出してデータをもらったが、顔で断られていたのが9割だった

自分と変わらない年収だったのにご丁寧に「顔が好みではありません」とコメントしてくる女もいた

事細かに修正していたプロフィールも見てもらえないようなもの無駄だった

申し込んだ人の中には、宗教病気・障碍持ちの人もいた

一度確認担当者から来るのだが、藁にもすがる思いで、そのまま申し込んでみたが

断られるのが翌日から4,5日後くらいになるだけだった

結局、オタクは秒で切られて終わり

1年間やっていたが、お見合いは1件もできずに終わった。申し込まれたのも件数も0

担当の人はなんだかんだで相談に乗ってくれていたので、この人が原因にならなくてよかった

高い金出して1年間、それなり凡人美人を眺める作業だけで俺の婚活は終わった

実際、高い金出しているのだから、それなりに容姿の整った人や年収の高い人が多いのは必然なのかもしれない

からブスは相談所に登録しない

でもいわゆるチー牛は相談所に登録する。なんで?

あと、これからとら婚に限らず婚活やるやつ、成婚白書ってやつをググって見た方がいい。

とら婚で婚活やって知ったやつ、これの存在しか得たものがない

から、とら婚は「オタク同士で結婚できる」とかい誇大広告をやめろ

2025-02-20

インターネットで呪ってやるとかいちいち考えなくていいし、伝えなくていい

ここには個がないのでそういったことをする必要がない

明らかな返信だったとしても別人として捉えてもいい

まり同じアカウントとの会話なんてない

正しくはとかサーバ上ではとか例外なんてどうでもいい

俺はこの発言以降二度と現れることはないし、今別のところでクソみたいな発言しているやつも、誰かの心を救ったあいつも二度と現れない

「ここでクソみたいな発言をしたあいつはあの発言以降この世から消えた。だからどうでもいい」

から憎しみが離れないってやつはそんな思考をしてみると楽になるかもね

2025-02-17

NFT in game

まず前提としてNTFの実体は、IDとその所有者の組み合わせを記録・更新できるシステムに過ぎない。

当然そのようなシステムブロックチェーンを用いない一般的サーバでも実現できる。

 

そして非代替トークン(NFT)の「非代替性」とは「そのシステム中で重複するID存在しない」という意味にすぎない。

一般的サーバで実現したシステムトークンも、同様の「非代替性」を持っている。

(MMORPG世界に1つしかないユニーク武器を考えれば、その性質は明らかだろう)

 

ではNFTの何が特別なのかというと、

特権ユーザによるデータ自由な書き換えが原理的に出来ないことが保証されている点

特別なのである

 

その前提のもとで考えてみて欲しいのだが、

そもそもゲーム運営会社に対して「特権ユーザによるデータ自由な書き換え」を危険視するユーザがどれだけ居るだろうか?

 

かにゲーム運営会社特権的なデータ書き換えを行える権限を持っており、

世界に1つしかないユニーク武器だったはずのアイテムが、明日にはオリジナル区別がつかないもの

プレイヤー全員に配布されるかもしれない。

そしてNFTを使えば確かに、それを防ぐことが出来る。

 

だがNFTなど使わなくても、最初からそんなことはされない信用はあるのである

さらに言えば仮にNFTを使っていたとしても、IDが違うこと以外は全く同じアイテムを配布されたり、

そのユニーク武器ゴミになるような超性能武器を出されることは防げない。

またNFTを持っていたとしてもゲーム運営会社特権的に「IDは所持しているが、そのIDゲームアイテムと紐づかなくなる」という処置アイテム無効化することも可能である

 

ゲームにおけるNFTには、意味は無いと断じていいだろう。

2025-02-16

駿河屋買取手続きフォーム

半角カナ絶対使用しないでください。」って書いてるんだけどそんな絶対ってつけることある…?

入力したらサーバが爆発でもするのか。

AI PC とか AI スマホって優良誤認じゃね?

そりゃ深層学習計算を一部CPUにたよらず計算できる機能ちょっとついてるかもしれないよ。

でもそれが動く瞬間っていつさ?いったいどのアプリがそんな機能実際に使ってるのさ?

スマホならまだ写真撮影後とかに動くかもしれんけど特にPCの方な。

本当にCopilotがローカル演算機つかってんのかー?ちゃんと確かめたかー?

現状だとサーバにお願いだけして結果受け取ってるだけなんじゃねえの。

サーバ側の進歩が落ち着くまでプログラムが変わり続けててローカルの側で計算するところまでできてなくね?

AIPCお金払うぐらいならゲーミングノート買ってCUDA動くようにした方が良いし、それよりもPC買い替えないでそのお金ChatGPTとかに払った方が幸せになれるんじゃね?

2025-02-14

AI生成記事

九州大学病院オブジェクト指向システム導入の記録

序章:革新的システムへの期待

1990年代半ば、九州大学病院(九大病院)は病院情報システムの全面刷新計画していた。従来の断片化したシステム統合し、最先端オブジェクト指向技術を全面採用した次世代システムに生まれ変わらせるという大胆な構想である

tumblr.com

。入札条件にも「純粋オブジェクト指向技術で実現すること」を掲げ、業界内でも前例の少ない大規模プロジェクトに挑むことになった​

tumblr.com

。この計画応札した日本IBMは、開発言語にSmalltalk採用し、社内外からオブジェクト指向開発の専門家を総動員する。日本IBM自身のチームに加え、Smalltalk豊富経験を持つ多数のシステムインテグレータ各社が協力企業として参画し、一時期は約200名もの技術者が開発に従事する巨大プロジェクトとなった​

tumblr.com

医療現場からは「21世紀を先取りするシステムになる」という期待の声が上がり、IBM側も「国内最高峰病院に最新技術を投入できる」と意気込んでいた。誰もが、この試みに大きな希望を抱いていたのである

1996年プロジェクト始動曖昧要件定義

プロジェクト1996年、本格的に動き始めた。九大病院情報システム担当者たちは、院内各部からシステムへの要望ヒアリングし、「新システムへの要望リスト」を作成して日本IBM提示した。しかし、その内容は具体性に欠けていたと言われる。「実現したい業務全体像がはっきりしていなかった」のだ。病院側は約1,400床を擁するマンモス病院ゆえ、部門ごとの意見をまとめ上げ全体方針を打ち出すことが難しく、提出された要件定義書は「中身はほとんどなかった」と関係者は振り返る。一方の日本IBMも、その不十分な要件定義を十分詰め直すことなく開発を進めようとし、この問題放置してしまった。プロジェクト序盤から、実は大きな不安の種が芽生えていたのである

それでも当初の計画は極めて野心的だった。フェーズごとに順次システムを稼働させる計画で、第1次カットオーバー最初の稼働開始)は1997年1月と定められていた​

tumblr.com

。限られた時間の中、日本IBMと協力各社の開発チームはオブジェクト指向の新手法に挑みつつ、多数のサブシステムを並行開発するという難事業に取り組み始めた。しか要件曖昧さは各所で影響を及ぼす。開発メンバーの一人は後に「実際にはオブジェクト指向入り口にさえたどり着けなかった」と語っており、肝心の新技術を活かす以前に基本事項の詰め直しに追われる状況だったという。

1997年初頭:見えてきた遅れとすれ違う思惑

年が明けて1997年になると、第1次稼働予定の目前になっても開発は難航していた。結局、日本IBM1996年10月末になって九大病院側に「当初予定の1997年1月にはシステム稼働が間に合わない」と突然伝えることになる。これは病院側にとって青天の霹靂であった。代替策として「一部機能範囲を絞れば1月稼働も可能」といった提案すら無く、一方的に延期が告げられたことに、病院担当者たちは強い不信感を抱いたという。プロジェクトマネージャー同士の密なコミュニケーションも欠如しており、延期決定前から両者の意思疎通は十分でなかったようだ。これが最初の綻びとなった。第1次稼働時期は当初計画より9カ月遅れ1997年10月へと大幅に後退する​

tumblr.com

この延期表明を境に、現場は混乱に陥る。病院側は日本IBMだけに任せておけないとの思いから、一部の協力会社と直接組んで独自プロトタイプ開発に乗り出すなど、プロジェクト体制は分裂気味になった。一方、日本IBM側の士気も下がり始める。ある協力会社メンバーは「これほど求心力のないプロジェクトも珍しい」と当時を振り返り、リーダーシップ不足だったIBM姿勢に驚いている。複数の外部企業(延べ10社以上)が関与する巨大プロジェクトでありながら、日本IBM1997年10月頃まで一貫して主導権を握れずにいた、と多くの関係者が指摘する。誰がハンドルを取っているのかわからないまま巨艦だけが突き進む――そんな不安定な状況であった。

事態を重く見た九大病院日本IBMは、1997年2月から6月にかけて要件定義のやり直しに着手する。一度作成した要件定義書を更地に戻し、業務フローも含めてゼロから整理し直す作業だ。しかしこのリカバリーにも時間を要し、プロジェクトの遅延はさらに広がっていった。「ようやく問題点に光を当て始めたかに見えたが、時すでに遅し。気づけば頭上に厚い雲が垂れ込めていた」と語る関係者もいる​

b.hatena.ne.jp

プロジェクトは先の見えないトンネルに入り込み、関係者の心にも次第に不安が募っていった。

1997年春:一筋の光明オブジェクト指向データベースの導入

混迷を極めるプロジェクトに光が差し込んだのは、1997年春のことである要件定義の立て直しと並行して、日本IBMシステム技術基盤を強化すべく重大な決断を下した。従来のリレーショナルDBではなく、米国GemStone Systems社のオブジェクト指向データベース(ODB)「GemStone」を採用する方針を固めたのだ​

tumblr.com

。GemStoneはSmalltalkとの相性が良いことで知られ、オブジェクト指向開発との親和性が高い製品である

tumblr.com

。この採用決定に伴い、GemStone社から複数名のコンサルタント来日プロジェクトに参加。停滞していた開発体制の再整備が行われた​

tumblr.com

経験豊富専門家の助言により設計も見直され、チームはようやく開発の目処を掴み始めたのである

tumblr.com

病院側もこの動きを歓迎した。長引く遅延に業を煮やしていたものの、最新のODB導入で性能や拡張性の課題解決されるならばと期待を寄せた。協力各社の技術者たちも「ようやくトンネルの先に光が見えた」と胸をなでおろした​

b.hatena.ne.jp

現場には久々に前向きな空気が漂う。遅れを取り戻すべく、再結集した開発チームはスパートをかけた。システム全体のアーキテクチャをGemStone前提に再設計し、失われた時間を埋めるため懸命な努力が続けられる。巨大プロジェクトは今、再び軌道に乗ろうとしていたかに見えた。

1997年夏:GemStone契約交渉の決裂、暗雲の再来

しかし、その光は長くは続かなかった。1997年7月初旬、プロジェクトに再び試練が訪れる。日本IBMとGemStone社との契約交渉が突如決裂し、参画していたGemStone社コンサルタント陣が全員帰国してしまったのだ。肝心のGemStone製品も利用不能となり、頼みの綱を断たれた開発チームは一瞬にして暗闇に放り込まれた。まさに「悪夢のような出来事」であった。

7月20日になって、日本IBMはようやく協力各社を集め緊急説明会を開いた。日本IBM側の説明によれば、「GemStoneとの交渉決裂は企業日本IBM)の根幹に関わる問題による」という。詳しい理由として、契約書の条項に**「システムユーザー等が何らかの理由でGemStone社を訴えた場合、メイン・コントラクタである日本IBMが全ての法的対応を負わねばならない」といった内容が盛り込まれており、日本IBMはこの重い責任リスクを受け入れられなかったのだという。さらに料金面でも折り合わず、3カ月間におよぶコンサルタント8名の派遣ソフトライセンス料などに数億円近い費用**を要求されたことも判明した。法的リスクコスト高騰――企業として譲れぬ一線を越える契約条件に、日本IBMは最終的に「ノー」を突きつけた形だ。だが、それは即ちプロジェクト生命線を断つことを意味していた。

この報に接した開発現場は騒然となった。GemStoneを中核に据えて進めてきたアーキテクチャ設計を一から練り直す必要が生じたためである。ある協力会社関係者は「この時点でプロジェクトの失敗を覚悟した」とまで語っている。大黒柱を失ったチームには動揺と失望が広がった。折しも夏本番を迎え、福岡の空は照りつける日差しに覆われていたが、プロジェクトには再び厚い雲が垂れ込め始めた。

1997年8~9月代替案への賭けと懸命の設計変更

GemStone脱落という非常事態に対し、日本IBMと九大病院必死リカバリーを図る。1997年8月上旬、急遽代替のODB製品としてフランスA.D.B社の「Matisse」を採用する決断が下された。Matisseは国内では知名度の低いODBだが、日本でも過去Smalltalkアプリケーションデータベース採用された実績があり、「何とか使えるめどは立つ」と判断されたのである

しか代替とはいえGemStoneとMatisseでは機能に大きな違いがあった。GemStoneで可能だったサーバ側でのSmalltalk処理実行がMatisseではできず、セキュリティ機能も貧弱だったため、開発チームは不足分を自前で作り込む必要に迫られた。この結果、システム全体の設計クライアント中心処理へ大幅に変更せざるを得なくなり、再び設計の手戻り作業が発生した。炎天下での再出発であるエンジニアたちは寝食を忘れ、懸命にコードを書き直した。

その甲斐あってか、1997年9月末の時点で第1次開発の主要部分を年内に実現できる見通しが立ったという。一度は暗転したプロジェクトにも、わずかながら光明が見えた。病院側も「何としても年内稼働を」という思いで支援を続ける。だが、このとき水面下では別の動きが進んでいたことを、現場の多くは知らなかった。

1997年10月:小さな後退、大きな決断

1997年10月9日、事態は最終局面を迎えた。この日開かれた会議で、日本IBMSmalltalkによる開発断念と、マイクロソフト社のVisual BasicVB)への全面的方針転換を突如宣言したのである晴天の霹靂とも言えるこの決断に、現場は凍りついた。幾多の苦難を乗り越えようやく目指してきた最先端技術での構築を諦め、当時広く普及していたVBという「オブジェクト指向ではない」開発ツールで作り直すというのだ。九大病院が当初求めた**「純粋オブジェクト指向」**という条件にVB合致するかは議論の分かれるところだが​

tumblr.com

病院ももはや背に腹は代えられない。最優先すべきはシステム稼働そのもの――この苦渋の転換を受け入れる以外になかった。

実はこの決断に至る伏線存在した。日本IBM1997年4月からかにVB採用可能性を九大病院に打診しており、さら8月からは段階的にSmalltalk担当エンジニア現場から引き上げ始めていたという。ある協力会社メンバーは「裏ではVBによる開発をすでに進めていたようだ」と振り返っている。つまりGemStone交渉決裂後、表向きはMatisseによる巻き返しを図る一方で、日本IBM本体は別動隊でVBシステムの構築に乗り出していた可能性が高い。振り返れば、日本IBMにはSmalltalk固執しない理由もあった。同社は翌98年2月長野冬季オリンピック向けシステムSmalltalkで構築しようとして失敗し、結局VBで作り直したという“前歴”もあったと伝えられる。アトランタ五輪1996年)では自社Smalltalkツール(VisualAge)を投入したものの、国内の大型案件では苦戦が続いた経緯があった*4。豊富人材がいるVBなら「最後人海戦術で何とかできる」という計算も働いたようだ。GemStoneとの契約不成立も、IBMにとっては結果的Smalltalkを断念する良い口実になったのではないか――協力会社メンバーの一人はそんな憶測さえ口にする。

方針転換の発表とほぼ同時に、Smalltalkで開発を担っていた協力会社の大部分はプロジェクトから撤退することになった​

tumblr.com

10月中旬には、多くの外部技術者が病院を後にしている。自ら招いた転換とはいえ日本IBMにとっても苦渋の決断であった。投入したリソース費用は莫大で、一からVBで開発し直すのは会社としても大きな後退だ。しかし背に腹は代えられない状況まで追い詰められていたことも事実であろう。IBM現場責任者は病院側に深々と頭を下げ、「必ずや残された方法で間に合わせます」と約束したという。九大病院担当者も沈痛な面持ちで頷き、「形はどうあれ、患者さんに影響を及ぼす前にシステムを動かしてほしい」と絞り出すように告げた。

以降、日本IBMは自社内のVB技術者や、自社が持つ病院向けオーダリングシステムパッケージ製品*5などを総動員してシステム構築を続行した​

tumblr.com

データベースも、当初IBM提案していながら見送っていた自社のリレーショナルDBDB2」を採用する公算が高まった​

tumblr.com

目標は「年度内(1998年3月まで)の第1次稼働」​

tumblr.com

。もはやオブジェクト指向の夢を追う余裕はない。現実的かつ確実に動く仕組みを、一刻も早く届ける――プロジェクトはその一点に向け再編成された。かつて200名近くいた開発陣は大幅に縮小され、構成メンバーも一変する。病院看護師スケジュール管理など一部のサブシステムは、撤退しなかった協力会社が細々とSmalltalk開発を続けていたが、その姿はもはや主流から外れた存在となっていった​

tumblr.com

。ある古参の協力技術者は去り際に「全力を出して戦う前に、白旗を上げてしまったという感じがする」と寂しげに語ったという。こうして九大病院プロジェクトの第1フェーズ――オブジェクト指向技術による野心的挑戦のフェーズは幕を下ろしたのであった。

1997年末:現場への波紋と社会的注目

VBへの方針転換後、九大病院現場には複雑な空気が流れていた。病院スタッフにとってシステム刷新は長らく待ち望んだ悲願だったが、その中身は当初聞いていた「最新技術結晶から一転して、従来型の技術で作られるものになってしまった。「結局、夢物語に終わったのか」という落胆の声も一部にはあった。しかし同時に、「多少古くてもいい、とにかく業務改善する仕組みを早く動かしてほしい」という切実な声も強まっていた。目指すゴールは変われど、一日でも早く新システムを稼働させ、慢性的業務負荷を軽減することが現場の切実な願いとなったのだ。プロジェクトチームは日夜作業を続け、簡易な操作研修なども始めながら、年明けまでの稼働に向け突き進んだ。

そんな中、1997年11月3日付の西日本新聞朝刊一面にこのプロジェクトに関する記事掲載される。タイトルは「九大病院システム未完 巨額費用批判」。内容は「九大病院システム未完成にもかかわらず日本IBMに月額4,250万円を支払い続けており、税金無駄遣いとの指摘が出ている」という衝撃的なものだった。同日、このニュース地元RKB毎日放送東京ではTBS)のテレビニュースでも報じられ、九大病院プロジェクト社会問題として一気に世間の注目を浴びることとなった。院内では「患者そっちのけで何をしているのか」といった批判も耳に入るようになり、大学本部所管官庁からの問い合わせも相次いだ。追い打ちをかけるように外部から視線が厳しくなる中、病院IBMはただひたすら開発を前に進めるしかなかった。

結末:プロジェクトの結末と残された教訓

1998年初頭、紆余曲折を経た九大病院の新システムは、当初の構想とは似ても似つかない形でようやく一部稼働に漕ぎつけた。日本IBMは多数のVBプログラマを投入して力技でシステムを完成させ、旧来システムの置き換えを順次進めていった。最終的に納入されたのはSmalltalkでもオブジェクト指向DBでもなく、Visual BasicリレーショナルDBによるシステムだった。かくして九大病院の「純粋オブジェクト指向システム」への挑戦は事実上の敗北に終わった。現場医師職員は、当初期待された華々しい先端技術恩恵を受けることはなかったが、ひとまず業務に支障のない情報システムが手に入ったことで安堵するより他なかった。プロジェクトは当初の理念を捨てて現実路線へ舵を切ることで、なんとか沈没だけは免れたと言えるだろう。

振り返れば、この失敗の背景には最新技術への挑戦ゆえの困難もあったが、それ以上に古典的とも言えるプロジェクト運営上のPermalink | 記事への反応(0) | 21:29

GoogleマップタイムラインjsonKML

> アプリ内のデータバックアップしたのを自分ダウンロードしてテキスト化する方法いかなあ/できたわ。設定→位置タイムラインタイムラインエクスポートjson可能。あとは誰かが処理系を作るだけだ!

https://b.hatena.ne.jp/entry/4766225990155446401/comment/punychan

書く場所を思いつかなかったのでこちらに投下。Python

これを使えばXXXX-XX-XX.kml 形式で日付別のタイムラインデータを出力できる(ChatGPT製)。

KMLファイルGoogle Earth Proなどで開くことが可能で、ビジュアルとして行動履歴を見ることができる。

ただ、以前GoogleMapsタイムラインが吐いていたKMLではPlacemarkという項目に直接建物名などが書かれていたが、現在出力されているjsonではplaceIdというものに変更されていて具体的な名前がわからない。

placeIdを実際の建物名などに変換するにはGoogle Maps API の Place Details APIを使うしかないようだが、膨大なリクエスト(有料)をしなければならず非現実的

もともと欧州プライバシー関係規制のせいでGoogleサーバ上でのタイムライン履歴が行われなくなったのが今回の問題の起点。

ユーザー自由尊重するなら、個人が行動履歴自己管理する自由ももっと尊重してもらいたいものだな、と思った。


import json

import os

from xml.etree.ElementTree import Element, SubElement, tostring

from xml.dom.minidom import parseString

# JSONファイルの読み込み

with open("タイムライン.json", "r", encoding="utf-8") as f:

data = json.load(f)

# 出力フォルダ作成

output_folder = "kml_output"

os.makedirs(output_folder, exist_ok=True)

# `semanticSegments` に移動データが含まれている

if "semanticSegments" in data:

date_segments = {} # 日付ごとにデータをまとめる辞書

for segment in data["semanticSegments"]:

# `startTime` から日付部分(YYYY-MM-DD)を抽出

if "startTime" in segment:

date = segment["startTime"].split("T")[0]

# 日付ごとのリスト作成

if date not in date_segments:

date_segments[date] = []

date_segments[date].append(segment)

# 日付ごとにKMLファイル作成

for date, segments in date_segments.items():

kml = Element("kml", xmlns="http://www.opengis.net/kml/2.2")

document = SubElement(kml, "Document")

for segment in segments:

if "timelinePath" in segment:

for point in segment["timelinePath"]:

coords = point["point"].replace("°", "") # 度記号を削除

time = point.get("time", "Unknown Time")

# Placemarkを作成

placemark = SubElement(document, "Placemark")

# タイムスタンプ

timestamp = SubElement(placemark, "TimeStamp")

when = SubElement(timestamp, "when")

when.text = time

# 座標

point_element = SubElement(placemark, "Point")

coordinates = SubElement(point_element, "coordinates")

lat, lon = coords.split(", ")

coordinates.text = f"{lon},{lat},0" # KML形式: lon,lat,alt

# KMLデータフォーマット

kml_str = tostring(kml, encoding="utf-8")

formatted_kml = parseString(kml_str).toprettyxml(indent=" ")

# KMLファイルに保存

kml_filename = os.path.join(output_folder, f"{date}.kml")

with open(kml_filename, "w", encoding="utf-8") as f:

f.write(formatted_kml)

print(f"KMLファイルを出力しました: {kml_filename}")

2025-02-13

anond:20250213180142

監視するサーバを見つけるほうが大変よ。

年齢は関係ない。

世の中そんなに大したシステム多く無くない?

これはオンプレミス回帰を謳っていたり、パブリッククラウド否定するものでは無いです

2025年現在サーバを準備するってなると、初手で AWS だの GCP だのってのを SNS ではよく目にするけど、

世の中の大半のシステムって、レンサバで十分だし、もっと言うなら事務所の片隅に置いたラップトップに「絶対シャットダウンしないでください」って付箋貼って置いておけば十分なモノばっかりじゃない?

オートスケールが云々とか、スペック拡張が容易だとかクラウドメリットはたくさんあるけど、実運用でそんなに使わなくない?

VMスペックが足りなくなってきたか拡張しますっって、そんな場当たり的な対応よりも、コードチューニングした方が良くない?

テレビ特集されたとかでアクセスが増えたときに捌けないと困るとか、そんなのサーバが落ちた方が流行ってる感出るじゃん

機会損失とか言うけど、そんなテレビ特集で最終的に購入までしてくれるユーザなんてほんの一握りなわけで、そこに大した機会なんてないんですよ

かに超有名なサービスとかなら、そういうのがあった方が良いと思うけど、世の中の大半って管理者用の管理サイトとか、大したアクセスもないコーポレートサイトとか

そんなのばっかりでしょ

月額のコストを見ても、クラウドは過剰なコストが掛かりすぎてる場合が大半じゃない?

今一度本質を見つめなおして欲しい

2025-02-12

プログラマーを目指す人のための超初心者向けガイド

1. ブラインドタッチ習得しろ

正しい指の位置を学び、ブラインドタッチできるようになれ

練習ソフトぐらいはいくらでも転がっているが、指の位置が把握できるものが良い

2. Ubuntuインストールし、Linuxコマンドを学べ

基本的操作コマンドでできるようにしろ

特に複数コマンドパイプで渡す等、標準入出力に習熟しろ

サーバ運用必要コマンドは一通り学んでおけ

3. VimEmacsnoxで使えるようになれ

noxとは、要するにGUI環境無しでということだ

サーバ運用する上ではGUIに頼れないことが多いため、noxで使えるエディタマスターしろ

4. プログラミング言語を学べ

ここにきてようやくプログラミング言語

まず共通知識としてHTML,CSS,JavaScriptぐらいは知っておいたほうが良いだろう

あとはどんなプログラマーを目指すかに依るが、組み込み系ならC言語Web系ならphppython機械学習ならpythonやRを学べ

オンラインチュートリアル最初は十分足りるだろう

シェルスクリプトは便利だからbashマスターするのも望ましい

5. アルゴリズムデータ構造を学べ

要は効率的に処理を書ける必要があるが、LeetCodeやAtCoder基本的問題集を解けるようになれ

アルゴリズムデータ構造について書かれた書籍を読め

線形代数確率論など基本的数学も学んでおけ

6. ライブラリドキュメントを読め

例えばpythonプログラマーなら、numpy, scipy, scikit-learnなどのライブラリドキュメントを読めるようになれ

あるいはElasticsearchを使わなければならなくなったときに、ドキュメントを読んで操作できるようになれ

ドキュメントを読む経験が増えれば、新しく何かをやるときにすぐに着手できるようになる

7. AWSを使えるようになれ

最近の開発環境ではAWSを使うことが多い

AWSを有料で勉強するのはキツイので、就職後に先輩から学ぶか、あるいは認定試験を本やオンライン講座で勉強するのでもいいだろう

8. Gitを使えるようになれ

バージョン管理システムは知っておくべき知識

いわば、ソースコードの巨大なUndo, Redoみたいなもんだ

これがなければ、ソースコード安全に保てない

9. 基本的セキュリティを学べ

パスワードをどう管理すればいいのか、ネットワークセキュリティの仕組み、など基本的セキュリティは学んどいたほうが良い

10. キレイコードとは何か、を徹底追及しろ

クリーンコードに関する書籍はたくさんあるので、時間があるときに読んでおけ

自分が使っているプログラミング言語に関連するベストプラクティスを学べ

PEP8などの標準をしり自動フォーマティングする方法を知れ

2025-02-07

anond:20250207084452

紐づけした後も両方で使えるのか

ってことはカードには番号の情報だけで残高はサーバ側にしかないのか

2025-02-06

プログラマの三大「心臓が止まりそうになるとき

あと一つは?

2025-02-04

anond:20250204142237

具体的に言うなら、例えばExcelマクロと同じで、書いた人間会社辞めたとか、部署を移動になったとか、

何らかの業務自動化するスクリプトRPAで言えばシナリオか、をどう管理するかが問題になる

全員がプログラマーとか、プログラミング素養があるとか、開発現場だったら、

業務自動化するシェルスクリプトとか、なんかPythonなりPHPなりなんでもいいけど、

やっつけで書いた自動化も喜ばれるんだよ、書いた人いなくなっても、なんとか再利用できるだろうという雰囲気がある

でも、そうでない現場文系人間しかいない現場になると、例えば上司拒否反応を起こす

自分理解できないものをやられると、ものすごく恐怖を感じるのだと思う

上司だけでなく、プログラミング素養がない人たちが多数派現場のみんながそうだと思った方がいい

仮に私が書いたとして、それが便利だとしても、おまえがいなくなったらどうするんだ?そんなブラックボックス書くな!という反応をされる

あと、自動化スクリプトRPAシナリオ外注するにしても、タイムラグがあるし、現場外注とのコミュニケーションコストとかバカにならない

プログラムを書く側からすると凄く腹立たしいのだけど、意外と文系職場って、自分がやってる業務ワークフローさえ分かってない現場があったりする

誰も自分たちが毎日やってる業務全体像を把握してない

自分担当のことしか知らない、自分範囲毎日やってればいいと思ってる

例えば、Aさんの仕事とBさんの仕事デッドロックするとか、そういう複雑な関係ちゃん論理的に考えて、全体を論理的に把握してる人が一人もいない

こちからすれば、正直あたおかと思ってしまうが、そうやって毎日働いている人たちがいるのである

そうなると、要は仕様書が書けない、ちゃんとした仕様書が書けない、作れない

じゃあ、外注側で仕様書も作ります、と言って、調査というかインタビューというか聞き込みみたいなのしても、外注としても全体像が見えない

そうやってるうちに、ワークフロー自体そもそもおかしいのではないか業務自体おかしいのではないか、みたいな現場問題点に気付いたりする

しかし、おたく業務おかしいですよ、みたいに指摘しても、相手激怒するか、無視するか、とにかくこれまで通りの毎日を送りたい、みたいな話になる

事なかれ主義であるが、まあ、人間みんなそんなもんである

開発現場だったらそんなことはない

なんか自動化したいな、とまず自分仕事自動化する、シェルスクリプトを書くとか、Pythonとか、自分ならPHPWeb関係ない処理も書けるので書いてしまうかもしれない

それを会社で借りてるGitHubなり、なんなりにpushして公開しておけば、誰かが見るだろうし、使ってもくれるだろう

ああ、そうそ

Excelマクロとか、RPAシナリオとか、Gitのようなバージョン管理を前提としてないものは、ファイルコピーしてファイル名に日付を書き加えたりして、

いや、ファイル名も書き換えるのが面倒だからって、~のコピー、~のコピーコピー、みたいなファイルファイル共有サーバフォルダーの中に大量に入ってたりして、

あー、雑な仕事とか管理してる会社ってみんなそうなんだけど、ファイル共有サーバーになんでも放り込んでカオスになってたりするよね

ファイルシステムじゃなくて、なんらかのバージョン管理システム下に放り込むなら管理できるんだけど、

駄目な会社って、みんなExcelファイルに何でも書いて、それをファイル共有サーバーに置いて、そのファイルを同時に開きたい人が複数いるけどロックされるとか、そんなことばっかりやってるんだよね

なんか愚痴ばかりで支離滅裂になってしまったけど、悪いことは言わない

RPAなんか使わない方がいい

何ならExcelマクロも使わない方がいい、マクロ作っても電卓計算しろみたいな笑い話があるけど、自分あながち間違ってないと思う

上司とか、偉い人が理解できないことをすると、反発を招くだけだし、マクロを作った人がいなくなったけど、マクロ挙動おかしい気がするとか、どうせ対処できなくなる

まあ、使ってみれば分かる

外注RPAシナリオ作らせるにしても、お試しに何か仕様をまとめて、作ってもらって、それをまた直してもらって、みたいなサイクルを試しにやってみれば分かる

全然効率が良くならないか

そして、良くならない理由の多くは、RPA問題があるんじゃなくて、RPAを導入しようとか甘い見積もりをしている企業側にある

自分としては、そういったことを解決できるのは、これからの生成AIのような技術だと思ってる

それはRPAシナリオを作るとか、外注に作らせるとか、プログラミング素養必要だとか、そういうことが一切なくなった世界になるからである

今、ソフトバンクの孫氏とOpenAIがやろうとしてることとか、そういう方向に期待した方がいい…😟

2025-02-02

仕事社会生活でのコミュニケーションなんて相手のいうこと理解して共感した体を見せつつ、うまいこと自分の主張も通していくだけのもんだと思う

AI使ってどうこうできるならもうAIでいいよ

メールサーバチャットサーバAIが穏当な表現添削してやりとりする

自分は毎回、お客さんへの連絡文は社内AIに貼り付けては添削してるけど、もう全部AIでいい

向こうもこちらへの連絡はAI通してほしいわ

2025-02-01

10年以上続けたFF14をやめた

黙って勝手にやめろよって話ですけど、10年以上続けたゲームですし最初最後に1つぐらい駄文を残してもいいよね。

プレイ履歴

レガシー時代

ベータから参加。正式サービス開始のサーバはBodhum。九英雄の1人かどうかはわからないですが

人がいないサーバだなぁと思ってました。途中でExcaliburに統合

外人サーバなのでフレンドもできずクローズまで1人で遊んでいました。

新生時代

アルファから参加。ベータ2でリアフレも遊んでいた事がわかり、最後ベータで同じサーバで始め

辞めるまでそのまま2人で遊んでいました。

DCはエレメンタルから勝手メテオ。エレメンタル時代はトンべりが大暴れして色々ありました。

プレイタイル

むちゃくちゃ下手で雑魚です。零式どころか極もやらずライト向けコンテンツやギャザクラで遊んでいました。

エンドコンテンツ24レイド(滅以前)。エウレカとかボズヤとかDDとかVDはめちゃくちゃやりこみました。

ギャザクラもかなりやりました。イシュガル復興称号も持っています

自分みたいなド下手を10年以上も遊ばせてくれたFF14は本当に凄いゲームだと思います

■なんでやめたのか

簡単に言うとゲームから追い出されました。といっても問題を起こして炎上してなどではなく

10年目を迎えた7.0からFF14方針が大きく変わり自分プレイタイル蚊帳の外になりました。

ライト向けコンテンツがどんどん削られ、絶や滅や零式など高難易度に重点を置くようになり

自分が遊べるコンテンツがなくなってしまいました。

4.0の末期にも相方フレが「シナリオがつまらんので辞めたい」と言い出したのですが

5.0のニーアコラボをやりたくて無理やり残ってもらいました。

たまたま5.0と6.0のメインシナリオが良くフレも大満足だったのですが

7.0でシナリオがクソなのでまた辞めると言い出しまして

コンテンツも上の通りなので同意し一緒にやめました。

勝手考察

吉田さんは新生時に「10年続けます」と宣言され、有言実行されたのは本当に素晴らしいと思います

そして今後10年を見据えた時に以下の事を考えたのではと推察します。

・今後プレイヤーは減り続ける

・全難易度コンテンツ作成を続ける事はコスト的に不可能

 PvPや対戦ゲームであれば1つのコンテンツを広い難易度で遊べます

 FF14PvEが中心なので難易度を絞り込む必要があります

・世のゲームは高難易度志向になっている

 最近ゲーム全部難しいですよね。

ゲームプレイするものではなく見るものになる

 昨今のゲームプレイ人口よりYoutubeなどで見ている人口はるかに多いです。

 eSportsなどプロプレイヤーも高難易度でないとビジネスになりません。

 草野球では金がとれませんが、プロ野球なら金取れるのと同じです。

 FF14では零式が上位プレイヤー1-2割、絶では1割未満がクリア可能難易度設定です。

 零式すら出来ないなら辞めろというのは良く言われる話ですが、零式未クリア者を全員排除すると

 次は残ったクリア者の中の1-2割しかクリアできない零式が出現します。

 そうして選ばれしトップ層の見世物で金を稼ぐしか無いのが昨今のゲーム事情です。

■ここだけは直してほしかった

ツール規制がない

 無法地帯です。

 たまにバレて話題にはなりますが、お咎めを受けたという話は聞いた事がありません。

プレイヤーのモラル

 ほかのゲームに比べれば平和と聞きますが君だけ部外者とかなんで放置したのかわかりません。

  「下手は来るな」と連呼する割に、下位コンテンツ舐めプして即死されている光る武器をお持ちの方を良く見かけました。

 MPKも多いですし上手ければ何をやっても良いという文化は好きではありませんでした。

・上位プレイヤーの優遇

 もう消えてますけど一部で話題になった例のサイト情報体感とも合っていて信憑性がありました。

 零式や絶クリア者が優遇されるのはわかりますロットドロップまで優遇するのはあんまりだなぁと思いました。

■おわりに

色々書きましたがFF14長期間とても楽しませてもらいました。

スクエニさんが新しいMMORPGを作られたら、また参加したいです。

2025-01-29

一言でいうと、普通は抜けない情報を抜いているうえに、アカウントIDSQLインジェクションなどのやり方を組みわせることで住所やクレジットカードの番号を抜く一歩手前まで来ているかなのだ

537:既にその名前は使われています\(^o^)/:2025/01/28(火) 12:57:00.19 ID:Ej52JzgX

理解してないガイジ多すぎだが情報は一切抜かれてねーし個人情報チャットも何も漏れてねーよクライアントに送られてる情報を読み取っただけでサーバから強奪したわけではないから何も漏れてない公開されたのもキャラクター情報であって個人情報ではないここで騒いでるのはサブキャラ名前を自宅住所とかリアル名にしてるアホかな?

https://ff14net.2chblog.jp/archives/62115422.html

まず、例のツールでサブキャラの行動やチャット履歴などGMしか見れない情報が見れた。これ自体問題ではある。ただ、これで済めば、まだ傷は浅い。

もっとやばいのはスクエニウェブサービスチョメチョメすることである。さすがにここら辺は対策してあると思いたいが、慣れてしない人だとウェブAPIから飛んできた値をチェックせず、そのまま、SQLに突っ込んでしまうことがある。人によってはSQLから飛んできた情報をそのままJSONで出してしまうこともある。俺も一度やらかしそうになったことがあるが、クレジットカード情報データーベースの保存しようとするコードを書いてしまたことがある。さすがにこれはほかの人が気づいて止められたので、大事には至らなかったが…運悪く通ってしまうことがある。スクエニに限らず、契約社員という雇用形態を好き好んで使っているところは、タイミング的な問題―時給が安いとか雇止めされやすいとか残業代を出さないとかで―でこの手のセキュリティに詳しい人がいないことがあるのだ。

そして、こういう事情脆弱性あるシステムができてしまえば、あとは簡単で――例えばアカウントIDがわかってしまえば、ウェブAPIパラメーターに

;SELECT * FROM payment_infomation WHERE accountid = [どこかでとってきたアカウントID];

みたいなやつを突っ込むと、なぜか取れてはいけない情報が取れてしまうことがある。

むろん、スクエニみたいなところであれば、ペネトレーションテストとかやってると信じたいが、ペネトレーションテストもただではない。そこらへんについて詳しくない取締役お金がかかるという理由ペネトレーションテストをしないことがあるにはあるし、人件費ケチりたいという理由でQA関係になれた人間リストラし、残された人、たいていの場合、QAとインフラチームやコードを書く人が心身を削りながらウェブアプリを作ってしまい、そのまま脆弱性のあるウェブアプリが世に出てしまうことがある。(脆弱性を埋めるのが大変だし、やったらすぐばれるし、莫大な費用請求しないといけないので、あえて放置するというパターン受託開発だとあるらしいが、スクエニだとさすがにないとは思う)

から、サブキャラ特定できてしまうのは非常にまずいのだ。

なお、私個人としてはゲームガードを突っ込むのは反対である。このゲームガードはHyperVやVMWareチートツール判断することがあり、非常にストレスなのだ

2025-01-28

仕事のできない同僚が嫌になって会社を辞めたんだけど、なんとなく元会社求人を見たらその同僚がインタビューされてた。

自分で一度考えてみて、違和感があれば人に聞くようにしてます

だとよ。

バカかよ。何度も在籍中に「〇〇さんは未経験違和感とかそういうレベルではないので、とりあえず何かあったら報告してくださいね」って教えたじゃん。

それなのに「自分で考えてから」をひたすらに貫き続けた結果、サーバアラート出てるのに無視してサービス落ちて、「なんでアラート出てるの教えないの?なんで勝手自分判断するの?まだ判断できる知識ないでしょ?」ってめっちゃ俺怒ったじゃん。んで知識のないキミは何もできないから俺が1人で復旧したじゃん?

なんで成長しないかな〜

2025-01-27

anond:20250127213129

阿部寛ホームページは、バックエンドニフティ

ニフティサーバシステム自身クラウド化したので

クラウドに変わってるし、ハードウェアも随時刷新されてる

爆速表示は、ページが軽いだけでなくサーバが新しくなってることもある

anond:20250127212204

管理端末にはそういうの見るけど

サーバでは見たことないな

理由は一つで、スペック不足でまともに動かなくなるから

ユーザ1000人くらいのwebサーバでも、

10年持たせるのは無理で5年がいいとこ

リース契約とかがちょうどその辺りなので

オンプレミスでもリースにする場合は多い

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