はてなキーワード: サーバとは
基本情報を持ってる人に サーバのIP アドレス 192.168.1.5/24 だったら、そのネットワークアドレス CIDR 24 で許可設定してほしいって言ったら、通じると思うじゃん？
なんで通じないんだよ……
ACL なんぞ BIND やら Apache やら DHCP やらサーバでも扱うもんだろ。
なんでネットワークスペシャリストが出てくるんだよ。疎通確認 NG なとき、どうやってトラブルシュートするん？
そもそもネットワークアドレスとか、基本情報の範囲内でしか話してないよ。
身体を壊して先日ちょっと入院していたのだが、病院内では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.com | AWSの管理コンソール | 禁止 |
| www.amazon.co.jp | ショッピング | めちゃくちゃ遅いけどつながる |
| www.amazon.com | ショッピング | めちゃくちゃ遅いけどつながる |
| ja.wikipedia.org | 百科事典 | 禁止 |
| www.php.net | プログラミング言語PHP | 禁止 |
| www.typescriptlang.org | プログラミング言語TypeScript | すんなり |
| stackoverflow.com | プログラミング質問サイト(英語) | すんなり |
| qiita.com | プログラミング質問サイト(日本語) | 禁止 |
| packagist.org | PHPのパッケージ管理 | 遅い(通常通り？ｗ) |
| www.npmjs.com | JSのパッケージ管理 | すんなり |
なお、自分のドメインのサブドメインに禁止ドメインを入れたようなもの、例えば anond.hatelabo.jp.example.com のようなドメインに対する接続可否は検証していない（面倒だったｗ）
サーバ目線で見える client IP をwhois等で調べると、某F社さんだった。AWS管理コンソールへの接続を禁止するあたり「あっ…！」と思ったり…ｗ
https://x.com/urokuta_ja/status/1753318561991532756
同接は185万人らしい
規模が違いすぎるけど、YouTubeの運営費用は月180億円らしい
180億かかってても重いときは重い
オタクがオタクと結婚できる可能性は、極めて少ない。ガチャ未満
なぜなら、登録するととら婚の登録者だけでなく他の相談所の人もいる、IBJの大海に放り出されるからである
MMORPGで例えるなら、IBJというゲームにとら婚サーバからログインしたようなものだ
毎月1日に20回分付与されるのだが、1日で使い切らず週ごとに何人かに分けて申し込むように言われた
「この人はとら婚の人です」みたいな注釈とかは載っていない
だからといって、非オタの女性をプロフィールから判断して申し込んだとしても
翌日に断られるか、返答期限の10日間を過ぎて自動的にお断りされる
1か10かで断り続けられ1年、写真の撮り直しやプロフィールの修正も何度もやった
金出してデータをもらったが、顔で断られていたのが9割だった
自分と変わらない年収だったのにご丁寧に「顔が好みではありません」とコメントしてくる女もいた
事細かに修正していたプロフィールも見てもらえないようなもので無駄だった
一度確認が担当者から来るのだが、藁にもすがる思いで、そのまま申し込んでみたが
断られるのが翌日から4，5日後くらいになるだけだった
結局、オタクは秒で切られて終わり
1年間やっていたが、お見合いは1件もできずに終わった。申し込まれたのも件数も0
担当の人はなんだかんだで相談に乗ってくれていたので、この人が原因にならなくてよかった
高い金出して1年間、それなり凡人美人を眺める作業だけで俺の婚活は終わった
実際、高い金出しているのだから、それなりに容姿の整った人や年収の高い人が多いのは必然なのかもしれない
あと、これからとら婚に限らず婚活やるやつ、成婚白書ってやつをググって見た方がいい。
まず前提としてNTFの実体は、IDとその所有者の組み合わせを記録・更新できるシステムに過ぎない。
当然そのようなシステムはブロックチェーンを用いない一般的なサーバでも実現できる。
そして非代替性トークン(NFT)の「非代替性」とは「そのシステム中で重複するIDが存在しない」という意味にすぎない。
一般的なサーバで実現したシステムのトークンも、同様の「非代替性」を持っている。
(MMORPGで世界に1つしかないユニーク武器を考えれば、その性質は明らかだろう)
ではNFTの何が特別なのかというと、
特権ユーザによるデータの自由な書き換えが原理的に出来ないことが保証されている点
その前提のもとで考えてみて欲しいのだが、
そもそもゲーム運営会社に対して「特権ユーザによるデータの自由な書き換え」を危険視するユーザがどれだけ居るだろうか？
確かにゲーム運営会社は特権的なデータ書き換えを行える権限を持っており、
世界に1つしかないユニーク武器だったはずのアイテムが、明日にはオリジナルと区別がつかないものが
プレイヤー全員に配布されるかもしれない。
そしてNFTを使えば確かに、それを防ぐことが出来る。
だがNFTなど使わなくても、最初からそんなことはされない信用はあるのである。
さらに言えば仮にNFTを使っていたとしても、IDが違うこと以外は全く同じアイテムを配布されたり、
そのユニーク武器がゴミになるような超性能武器を出されることは防げない。
またNFTを持っていたとしてもゲーム運営会社は特権的に「IDは所持しているが、そのIDがゲーム内アイテムと紐づかなくなる」という処置でアイテムを無効化することも可能である。
そりゃ深層学習の計算を一部CPUにたよらず計算できる機能がちょっとついてるかもしれないよ。
でもそれが動く瞬間っていつさ？いったいどのアプリがそんな機能実際に使ってるのさ？
スマホならまだ写真撮影後とかに動くかもしれんけど特にPCの方な。
本当にCopilotがローカルの演算機つかってんのかー？ちゃんと確かめたかー？
現状だとサーバにお願いだけして結果受け取ってるだけなんじゃねえの。
サーバ側の進歩が落ち着くまでプログラムが変わり続けててローカルの側で計算するところまでできてなくね？
AIPC にお金払うぐらいならゲーミングノート買ってCUDA動くようにした方が良いし、それよりもPC買い替えないでそのお金ChatGPTとかに払った方が幸せになれるんじゃね？
1990年代半ば、九州大学病院（九大病院）は病院情報システムの全面刷新を計画していた。従来の断片化したシステムを統合し、最先端のオブジェクト指向技術を全面採用した次世代システムに生まれ変わらせるという大胆な構想である
tumblr.com
。入札条件にも「純粋なオブジェクト指向技術で実現すること」を掲げ、業界内でも前例の少ない大規模プロジェクトに挑むことになった
tumblr.com
。この計画に応札した日本IBMは、開発言語にSmalltalkを採用し、社内外からオブジェクト指向開発の専門家を総動員する。日本IBM自身のチームに加え、Smalltalkの豊富な経験を持つ多数のシステムインテグレータ各社が協力企業として参画し、一時期は約200名もの技術者が開発に従事する巨大プロジェクトとなった
tumblr.com
。医療現場からは「21世紀を先取りするシステムになる」という期待の声が上がり、IBM側も「国内最高峰の病院に最新技術を投入できる」と意気込んでいた。誰もが、この試みに大きな希望を抱いていたのである。
プロジェクトは1996年、本格的に動き始めた。九大病院の情報システム担当者たちは、院内各部門から新システムへの要望をヒアリングし、「新システムへの要望リスト」を作成して日本IBMに提示した。しかし、その内容は具体性に欠けていたと言われる。「実現したい業務の全体像がはっきりしていなかった」のだ。病院側は約1,400床を擁するマンモス病院ゆえ、部門ごとの意見をまとめ上げ全体方針を打ち出すことが難しく、提出された要件定義書は「中身はほとんどなかった」と関係者は振り返る。一方の日本IBMも、その不十分な要件定義を十分詰め直すことなく開発を進めようとし、この問題を放置してしまった。プロジェクト序盤から、実は大きな不安の種が芽生えていたのである。
それでも当初の計画は極めて野心的だった。フェーズごとに順次システムを稼働させる計画で、第1次カットオーバー（最初の稼働開始）は1997年1月と定められていた
tumblr.com
。限られた時間の中、日本IBMと協力各社の開発チームはオブジェクト指向の新手法に挑みつつ、多数のサブシステムを並行開発するという難事業に取り組み始めた。しかし要件の曖昧さは各所で影響を及ぼす。開発メンバーの一人は後に「実際にはオブジェクト指向の入り口にさえたどり着けなかった」と語っており、肝心の新技術を活かす以前に基本事項の詰め直しに追われる状況だったという。
1997年初頭：見えてきた遅れとすれ違う思惑
年が明けて1997年になると、第1次稼働予定の目前になっても開発は難航していた。結局、日本IBMは1996年10月末になって九大病院側に「当初予定の1997年1月にはシステム稼働が間に合わない」と突然伝えることになる。これは病院側にとって青天の霹靂であった。代替策として「一部機能に範囲を絞れば1月稼働も可能」といった提案すら無く、一方的に延期が告げられたことに、病院担当者たちは強い不信感を抱いたという。プロジェクト・マネージャー同士の密なコミュニケーションも欠如しており、延期決定前から両者の意思疎通は十分でなかったようだ。これが最初の綻びとなった。第1次稼働時期は当初計画より9カ月遅れの1997年10月へと大幅に後退する
tumblr.com
。
この延期表明を境に、現場は混乱に陥る。病院側は日本IBMだけに任せておけないとの思いから、一部の協力会社と直接組んで独自にプロトタイプ開発に乗り出すなど、プロジェクト体制は分裂気味になった。一方、日本IBM側の士気も下がり始める。ある協力会社メンバーは「これほど求心力のないプロジェクトも珍しい」と当時を振り返り、リーダーシップ不足だったIBMの姿勢に驚いている。複数の外部企業（延べ10社以上）が関与する巨大プロジェクトでありながら、日本IBMは1997年10月頃まで一貫して主導権を握れずにいた、と多くの関係者が指摘する。誰がハンドルを取っているのかわからないまま巨艦だけが突き進む――そんな不安定な状況であった。
事態を重く見た九大病院と日本IBMは、1997年2月から6月にかけて要件定義のやり直しに着手する。一度作成した要件定義書を更地に戻し、業務フローも含めてゼロから整理し直す作業だ。しかしこのリカバリーにも時間を要し、プロジェクトの遅延はさらに広がっていった。「ようやく問題点に光を当て始めたかに見えたが、時すでに遅し。気づけば頭上に厚い雲が垂れ込めていた」と語る関係者もいる
。プロジェクトは先の見えないトンネルに入り込み、関係者の心にも次第に不安が募っていった。
1997年春：一筋の光明 – オブジェクト指向データベースの導入
混迷を極めるプロジェクトに光が差し込んだのは、1997年春のことである。要件定義の立て直しと並行して、日本IBMはシステムの技術基盤を強化すべく重大な決断を下した。従来のリレーショナルDBではなく、米国GemStone Systems社のオブジェクト指向データベース（ODB）「GemStone」を採用する方針を固めたのだ
tumblr.com
。GemStoneはSmalltalkとの相性が良いことで知られ、オブジェクト指向開発との親和性が高い製品である
tumblr.com
。この採用決定に伴い、GemStone社から複数名のコンサルタントが来日しプロジェクトに参加。停滞していた開発体制の再整備が行われた
tumblr.com
。経験豊富な専門家の助言により設計も見直され、チームはようやく開発の目処を掴み始めたのである
tumblr.com
。
病院側もこの動きを歓迎した。長引く遅延に業を煮やしていたものの、最新のODB導入で性能や拡張性の課題が解決されるならばと期待を寄せた。協力各社の技術者たちも「ようやくトンネルの先に光が見えた」と胸をなでおろした
。現場には久々に前向きな空気が漂う。遅れを取り戻すべく、再結集した開発チームはスパートをかけた。システム全体のアーキテクチャをGemStone前提に再設計し、失われた時間を埋めるため懸命な努力が続けられる。巨大プロジェクトは今、再び軌道に乗ろうとしていたかに見えた。
しかし、その光は長くは続かなかった。1997年7月初旬、プロジェクトに再び試練が訪れる。日本IBMとGemStone社との契約交渉が突如決裂し、参画していたGemStone社コンサルタント陣が全員帰国してしまったのだ。肝心のGemStone製品も利用不能となり、頼みの綱を断たれた開発チームは一瞬にして暗闇に放り込まれた。まさに「悪夢のような出来事」であった。
7月20日になって、日本IBMはようやく協力各社を集め緊急説明会を開いた。日本IBM側の説明によれば、「GemStoneとの交渉決裂は企業（日本IBM）の根幹に関わる問題による」という。詳しい理由として、契約書の条項に**「システムのユーザー等が何らかの理由でGemStone社を訴えた場合、メイン・コントラクタである日本IBMが全ての法的対応を負わねばならない」といった内容が盛り込まれており、日本IBMはこの重い責任リスクを受け入れられなかったのだという。さらに料金面でも折り合わず、3カ月間におよぶコンサルタント8名の派遣とソフトライセンス料などに数億円近い費用**を要求されたことも判明した。法的リスクとコスト高騰――企業として譲れぬ一線を越える契約条件に、日本IBMは最終的に「ノー」を突きつけた形だ。だが、それは即ちプロジェクトの生命線を断つことを意味していた。
この報に接した開発現場は騒然となった。GemStoneを中核に据えて進めてきたアーキテクチャ設計を一から練り直す必要が生じたためである。ある協力会社の関係者は「この時点でプロジェクトの失敗を覚悟した」とまで語っている。大黒柱を失ったチームには動揺と失望が広がった。折しも夏本番を迎え、福岡の空は照りつける日差しに覆われていたが、プロジェクトには再び厚い雲が垂れ込め始めた。
GemStone脱落という非常事態に対し、日本IBMと九大病院は必死のリカバリーを図る。1997年8月上旬、急遽代替のODB製品としてフランスA.D.B社の「Matisse」を採用する決断が下された。Matisseは国内では知名度の低いODBだが、日本でも過去にSmalltalkアプリケーションのデータベースに採用された実績があり、「何とか使えるめどは立つ」と判断されたのである。
しかし代替品とはいえGemStoneとMatisseでは機能に大きな違いがあった。GemStoneで可能だったサーバ側でのSmalltalk処理実行がMatisseではできず、セキュリティ機能も貧弱だったため、開発チームは不足分を自前で作り込む必要に迫られた。この結果、システム全体の設計をクライアント中心処理へ大幅に変更せざるを得なくなり、再び設計の手戻り作業が発生した。炎天下での再出発である。エンジニアたちは寝食を忘れ、懸命にコードを書き直した。
その甲斐あってか、1997年9月末の時点で第1次開発の主要部分を年内に実現できる見通しが立ったという。一度は暗転したプロジェクトにも、わずかながら光明が見えた。病院側も「何としても年内稼働を」という思いで支援を続ける。だが、このとき水面下では別の動きが進んでいたことを、現場の多くは知らなかった。
1997年10月9日、事態は最終局面を迎えた。この日開かれた会議で、日本IBMはSmalltalkによる開発断念と、マイクロソフト社のVisual Basic（VB）への全面的な方針転換を突如宣言したのである。晴天の霹靂とも言えるこの決断に、現場は凍りついた。幾多の苦難を乗り越えようやく目指してきた最先端技術での構築を諦め、当時広く普及していたVBという「オブジェクト指向ではない」開発ツールで作り直すというのだ。九大病院が当初求めた**「純粋なオブジェクト指向」**という条件にVBが合致するかは議論の分かれるところだが
tumblr.com
、病院側ももはや背に腹は代えられない。最優先すべきはシステム稼働そのもの――この苦渋の転換を受け入れる以外になかった。
実はこの決断に至る伏線は存在した。日本IBMは1997年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が提案していながら見送っていた自社のリレーショナルDB「DB2」を採用する公算が高まった
tumblr.com
tumblr.com
。もはやオブジェクト指向の夢を追う余裕はない。現実的かつ確実に動く仕組みを、一刻も早く届ける――プロジェクトはその一点に向け再編成された。かつて200名近くいた開発陣は大幅に縮小され、構成メンバーも一変する。病院の看護師スケジュール管理など一部のサブシステムは、撤退しなかった協力会社が細々とSmalltalk開発を続けていたが、その姿はもはや主流から外れた存在となっていった
tumblr.com
。ある古参の協力技術者は去り際に「全力を出して戦う前に、白旗を上げてしまったという感じがする」と寂しげに語ったという。こうして九大病院プロジェクトの第1フェーズ――オブジェクト指向技術による野心的挑戦のフェーズは幕を下ろしたのであった。
VBへの方針転換後、九大病院の現場には複雑な空気が流れていた。病院スタッフにとってシステム刷新は長らく待ち望んだ悲願だったが、その中身は当初聞いていた「最新技術の結晶」から一転して、従来型の技術で作られるものになってしまった。「結局、夢物語に終わったのか」という落胆の声も一部にはあった。しかし同時に、「多少古くてもいい、とにかく業務を改善する仕組みを早く動かしてほしい」という切実な声も強まっていた。目指すゴールは変われど、一日でも早く新システムを稼働させ、慢性的な業務負荷を軽減することが現場の切実な願いとなったのだ。プロジェクトチームは日夜作業を続け、簡易な操作研修なども始めながら、年明けまでの稼働に向け突き進んだ。
そんな中、1997年11月3日付の西日本新聞朝刊一面にこのプロジェクトに関する記事が掲載される。タイトルは「九大病院システム未完 巨額費用に批判」。内容は「九大病院はシステムが未完成にもかかわらず日本IBMに月額4,250万円を支払い続けており、税金の無駄遣いとの指摘が出ている」という衝撃的なものだった。同日、このニュースは地元RKB毎日放送（東京ではTBS）のテレビニュースでも報じられ、九大病院プロジェクトは社会問題として一気に世間の注目を浴びることとなった。院内では「患者そっちのけで何をしているのか」といった批判も耳に入るようになり、大学本部や所管官庁からの問い合わせも相次いだ。追い打ちをかけるように外部からの視線が厳しくなる中、病院とIBMはただひたすら開発を前に進めるしかなかった。
結末：プロジェクトの結末と残された教訓
1998年初頭、紆余曲折を経た九大病院の新システムは、当初の構想とは似ても似つかない形でようやく一部稼働に漕ぎつけた。日本IBMは多数のVBプログラマを投入して力技でシステムを完成させ、旧来システムの置き換えを順次進めていった。最終的に納入されたのはSmalltalkでもオブジェクト指向DBでもなく、Visual BasicとリレーショナルDBによるシステムだった。かくして九大病院の「純粋オブジェクト指向システム」への挑戦は事実上の敗北に終わった。現場の医師や職員は、当初期待された華々しい先端技術の恩恵を受けることはなかったが、ひとまず業務に支障のない情報システムが手に入ったことで安堵するより他なかった。プロジェクトは当初の理念を捨てて現実路線へ舵を切ることで、なんとか沈没だけは免れたと言えるだろう。
振り返れば、この失敗の背景には最新技術への挑戦ゆえの困難もあったが、それ以上に古典的とも言えるプロジェクト運営上の Permalink | 記事への反応(0) | 21:29
> アプリ内のデータかバックアップしたのを自分でダウンロードしてテキスト化する方法ないかなあ／できたわ。設定→位置→タイムライン→タイムラインのエクスポートでjson化可能。あとは誰かが処理系を作るだけだ！
https://b.hatena.ne.jp/entry/4766225990155446401/comment/punychan
これを使えば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
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]
date_segments[date].append(segment)
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:
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")
# 座標
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_str = tostring(kml, encoding="utf-8")
formatted_kml = parseString(kml_str).toprettyxml(indent=" ")
kml_filename = os.path.join(output_folder, f"{date}.kml")
with open(kml_filename, "w", encoding="utf-8") as f:
これはオンプレミス回帰を謳っていたり、パブリッククラウドを否定するものでは無いです
2025年現在、サーバを準備するってなると、初手で AWS だの GCP だのってのを SNS ではよく目にするけど、
世の中の大半のシステムって、レンサバで十分だし、もっと言うなら事務所の片隅に置いたラップトップに「絶対シャットダウンしないでください」って付箋貼って置いておけば十分なモノばっかりじゃない？
オートスケールが云々とか、スペックの拡張が容易だとかクラウドのメリットはたくさんあるけど、実運用でそんなに使わなくない？
VM のスペックが足りなくなってきたから拡張しますっって、そんな場当たり的な対応よりも、コードのチューニングした方が良くない？
テレビで特集されたとかでアクセスが増えたときに捌けないと困るとか、そんなのサーバが落ちた方が流行ってる感出るじゃん
機会損失とか言うけど、そんなテレビの特集で最終的に購入までしてくれるユーザなんてほんの一握りなわけで、そこに大した機会なんてないんですよ
確かに超有名なサービスとかなら、そういうのがあった方が良いと思うけど、世の中の大半って管理者用の管理サイトとか、大したアクセスもないコーポレートサイトとか
そんなのばっかりでしょ
月額のコストを見ても、クラウドは過剰なコストが掛かりすぎてる場合が大半じゃない？
今一度本質を見つめなおして欲しい
練習用ソフトぐらいはいくらでも転がっているが、指の位置が把握できるものが良い
サーバー運用する上ではGUIに頼れないことが多いため、noxで使えるエディタをマスターしろ
ここにきてようやくプログラミング言語だ
まず共通知識としてHTML,CSS,JavaScriptぐらいは知っておいたほうが良いだろう
あとはどんなプログラマーを目指すかに依るが、組み込み系ならC言語、Web系ならphpやpython、機械学習ならpythonやRを学べ
シェルスクリプトは便利だから、bashをマスターするのも望ましい
要は効率的に処理を書ける必要があるが、LeetCodeやAtCoderで基本的な問題集を解けるようになれ
例えばpythonプログラマーなら、numpy, scipy, scikit-learnなどのライブラリのドキュメントを読めるようになれ
あるいはElasticsearchを使わなければならなくなったときに、ドキュメントを読んで操作できるようになれ
ドキュメントを読む経験が増えれば、新しく何かをやるときにすぐに着手できるようになる
AWSを有料で勉強するのはキツイので、就職後に先輩から学ぶか、あるいは認定試験を本やオンライン講座で勉強するのでもいいだろう
バージョン管理システムは知っておくべき知識だ
いわば、ソースコードの巨大なUndo, Redoみたいなもんだ
パスワードをどう管理すればいいのか、ネットワークセキュリティの仕組み、など基本的なセキュリティは学んどいたほうが良い
クリーンコードに関する書籍はたくさんあるので、時間があるときに読んでおけ
自分が使っているプログラミング言語に関連するベストプラクティスを学べ
具体的に言うなら、例えばExcelマクロと同じで、書いた人間が会社辞めたとか、部署を移動になったとか、
何らかの業務を自動化するスクリプト、RPAで言えばシナリオか、をどう管理するかが問題になる
全員がプログラマーとか、プログラミングの素養があるとか、開発現場だったら、
業務を自動化するシェルスクリプトとか、なんかPythonなりPHPなりなんでもいいけど、
やっつけで書いた自動化も喜ばれるんだよ、書いた人いなくなっても、なんとか再利用できるだろうという雰囲気がある
でも、そうでない現場、文系人間しかいない現場になると、例えば上司が拒否反応を起こす
自分に理解できないものをやられると、ものすごく恐怖を感じるのだと思う
上司だけでなく、プログラミングの素養がない人たちが多数派の現場のみんながそうだと思った方がいい
仮に私が書いたとして、それが便利だとしても、おまえがいなくなったらどうするんだ？そんなブラックボックス書くな！という反応をされる
あと、自動化のスクリプトやRPAのシナリオを外注するにしても、タイムラグがあるし、現場と外注とのコミュニケーションコストとかバカにならない
プログラムを書く側からすると凄く腹立たしいのだけど、意外と文系の職場って、自分がやってる業務のワークフローさえ分かってない現場があったりする
自分の担当のことしか知らない、自分の範囲を毎日やってればいいと思ってる
例えば、Aさんの仕事とBさんの仕事がデッドロックするとか、そういう複雑な関係をちゃんと論理的に考えて、全体を論理的に把握してる人が一人もいない
こちらからすれば、正直あたおかと思ってしまうが、そうやって毎日働いている人たちがいるのである
そうなると、要は仕様書が書けない、ちゃんとした仕様書が書けない、作れない
じゃあ、外注側で仕様書も作ります、と言って、調査というかインタビューというか聞き込みみたいなのしても、外注としても全体像が見えない
そうやってるうちに、ワークフロー自体がそもそもおかしいのではないか、業務自体がおかしいのではないか、みたいな現場の問題点に気付いたりする
しかし、おたくの業務、おかしいですよ、みたいに指摘しても、相手は激怒するか、無視するか、とにかくこれまで通りの毎日を送りたい、みたいな話になる
開発現場だったらそんなことはない
なんか自動化したいな、とまず自分の仕事を自動化する、シェルスクリプトを書くとか、Pythonとか、自分ならPHPでWeb関係ない処理も書けるので書いてしまうかもしれない
それを会社で借りてるGitHubなり、なんなりにpushして公開しておけば、誰かが見るだろうし、使ってもくれるだろう
ああ、そうそう
Excelのマクロとか、RPAのシナリオとか、Gitのようなバージョン管理を前提としてないものは、ファイルをコピーしてファイル名に日付を書き加えたりして、
いや、ファイル名も書き換えるのが面倒だからって、～のコピー、～のコピーのコピー、みたいなファイルがファイル共有サーバのフォルダーの中に大量に入ってたりして、
あー、雑な仕事とか管理してる会社ってみんなそうなんだけど、ファイル共有サーバーになんでも放り込んでカオスになってたりするよね
ファイルシステムじゃなくて、なんらかのバージョン管理のシステム下に放り込むなら管理できるんだけど、
駄目な会社って、みんなExcelファイルに何でも書いて、それをファイル共有サーバーに置いて、そのファイルを同時に開きたい人が複数いるけどロックされるとか、そんなことばっかりやってるんだよね
なんか愚痴ばかりで支離滅裂になってしまったけど、悪いことは言わない
RPAなんか使わない方がいい
何ならExcelマクロも使わない方がいい、マクロ作っても電卓で計算しろみたいな笑い話があるけど、自分はあながち間違ってないと思う
上司とか、偉い人が理解できないことをすると、反発を招くだけだし、マクロを作った人がいなくなったけど、マクロの挙動がおかしい気がするとか、どうせ対処できなくなる
まあ、使ってみれば分かる
外注にRPAのシナリオ作らせるにしても、お試しに何か仕様をまとめて、作ってもらって、それをまた直してもらって、みたいなサイクルを試しにやってみれば分かる
そして、良くならない理由の多くは、RPAに問題があるんじゃなくて、RPAを導入しようとか甘い見積もりをしている企業側にある
自分としては、そういったことを解決できるのは、これからの生成AIのような技術だと思ってる
それはRPAのシナリオを作るとか、外注に作らせるとか、プログラミングの素養が必要だとか、そういうことが一切なくなった世界になるからである
黙って勝手にやめろよって話ですけど、10年以上続けたゲームですし最初で最後に１つぐらい駄文を残してもいいよね。
ベータから参加。正式サービス開始のサーバはBodhum。九英雄の１人かどうかはわからないですが
人がいないサーバだなぁと思ってました。途中でExcaliburに統合。
外人サーバなのでフレンドもできずクローズまで１人で遊んでいました。
アルファから参加。ベータ２でリアフレも遊んでいた事がわかり、最後のベータで同じサーバで始め
辞めるまでそのまま２人で遊んでいました。
DCはエレメンタルから勝手にメテオ。エレメンタル時代はトンべりが大暴れして色々ありました。
むちゃくちゃ下手で雑魚です。零式どころか極もやらずライト向けコンテンツやギャザクラで遊んでいました。
エンドコンテンツは24人レイド(滅以前)。エウレカとかボズヤとかDDとかVDはめちゃくちゃやりこみました。
ギャザクラもかなりやりました。イシュガルド復興の称号も持っています。
自分みたいなド下手を10年以上も遊ばせてくれたFF14は本当に凄いゲームだと思います。
■なんでやめたのか
簡単に言うとゲームから追い出されました。といっても問題を起こして炎上してなどではなく
10年目を迎えた7.0からFF14の方針が大きく変わり自分のプレイスタイルは蚊帳の外になりました。
ライト向けコンテンツがどんどん削られ、絶や滅や零式など高難易度に重点を置くようになり
4.0の末期にも相方フレが「シナリオがつまらんので辞めたい」と言い出したのですが
5.0のニーアコラボをやりたくて無理やり残ってもらいました。
たまたま5.0と6.0のメインシナリオが良くフレも大満足だったのですが
吉田さんは新生時に「10年続けます」と宣言され、有言実行されたのは本当に素晴らしいと思います。
そして今後10年を見据えた時に以下の事を考えたのではと推察します。
・今後プレイヤーは減り続ける
PvPや対戦ゲームであれば１つのコンテンツを広い難易度で遊べますが
FF14はPvEが中心なので難易度を絞り込む必要があります。
昨今のゲームはプレイ人口よりYoutubeなどで見ている人口がはるかに多いです。
eSportsなどプロプレイヤーも高難易度でないとビジネスになりません。
草野球では金がとれませんが、プロ野球なら金取れるのと同じです。
FF14では零式が上位プレイヤー1-2割、絶では1割未満がクリア可能な難易度設定です。
零式すら出来ないなら辞めろというのは良く言われる話ですが、零式未クリア者を全員排除すると
次は残ったクリア者の中の1-2割しかクリアできない零式が出現します。
そうして選ばれしトップ層の見世物で金を稼ぐしか無いのが昨今のゲーム事情です。
■ここだけは直してほしかった
無法地帯です。
たまにバレて話題にはなりますが、お咎めを受けたという話は聞いた事がありません。
ほかのゲームに比べれば平和と聞きますが君だけ部外者とかなんで放置したのかわかりません。
「下手は来るな」と連呼する割に、下位コンテンツで舐めプして即死されている光る武器をお持ちの方を良く見かけました。
MPKも多いですし上手ければ何をやっても良いという文化は好きではありませんでした。
もう消えてますけど一部で話題になった例のサイトの情報は体感とも合っていて信憑性がありました。
零式や絶クリア者が優遇されるのはわかりますがロットやドロップまで優遇するのはあんまりだなぁと思いました。
■おわりに
色々書きましたがFF14は長期間とても楽しませてもらいました。
一言でいうと、普通は抜けない情報を抜いているうえに、アカウントIDとSQLインジェクションなどのやり方を組みわせることで住所やクレジットカードの番号を抜く一歩手前まで来ているからなのだ。
537：既にその名前は使われています＠＼(^o^)／：2025/01/28(火) 12:57:00.19 ID:Ej52JzgX
理解してないガイジ多すぎだが情報は一切抜かれてねーし個人情報もチャットも何も漏れてねーよクライアントに送られてる情報を読み取っただけでサーバから強奪したわけではないから何も漏れてない公開されたのもキャラクター情報であって個人情報ではないここで騒いでるのはサブキャラの名前を自宅住所とかリアル名にしてるアホかな？
まず、例のツールでサブキャラの行動やチャット履歴などGMでしか見れない情報が見れた。これ自体も問題ではある。ただ、これで済めば、まだ傷は浅い。
もっとやばいのはスクエニのウェブサービスでチョメチョメすることである。さすがにここら辺は対策してあると思いたいが、慣れてしない人だとウェブAPIから飛んできた値をチェックせず、そのまま、SQLに突っ込んでしまうことがある。人によってはSQLから飛んできた情報をそのままJSONで出してしまうこともある。俺も一度やらかしそうになったことがあるが、クレジットカードの情報をデーターベースの保存しようとするコードを書いてしまったことがある。さすがにこれはほかの人が気づいて止められたので、大事には至らなかったが…運悪く通ってしまうことがある。スクエニに限らず、契約社員という雇用形態を好き好んで使っているところは、タイミング的な問題―時給が安いとか雇止めされやすいとか残業代を出さないとかで―でこの手のセキュリティに詳しい人がいないことがあるのだ。
そして、こういう事情で脆弱性あるシステムができてしまえば、あとは簡単で――例えばアカウントIDがわかってしまえば、ウェブAPIのパラメーターに
;SELECT * FROM payment_infomation WHERE accountid = [どこかでとってきたアカウントID];
みたいなやつを突っ込むと、なぜか取れてはいけない情報が取れてしまうことがある。
むろん、スクエニみたいなところであれば、ペネトレーションテストとかやってると信じたいが、ペネトレーションテストもただではない。そこらへんについて詳しくない取締役がお金がかかるという理由でペネトレーションテストをしないことがあるにはあるし、人件費をケチりたいという理由でQA関係になれた人間をリストラし、残された人、たいていの場合、QAとインフラチームやコードを書く人が心身を削りながらウェブアプリを作ってしまい、そのまま脆弱性のあるウェブアプリが世に出てしまうことがある。（脆弱性を埋めるのが大変だし、やったらすぐばれるし、莫大な費用を請求しないといけないので、あえて放置するというパターンも受託開発だとあるらしいが、スクエニだとさすがにないとは思う）
なお、私個人としてはゲームガードを突っ込むのは反対である。このゲームガードはHyperVやVMWareをチートツールと判断することがあり、非常にストレスなのだ。
仕事のできない同僚が嫌になって会社を辞めたんだけど、なんとなく元会社の求人を見たらその同僚がインタビューされてた。
「自分で一度考えてみて、違和感があれば人に聞くようにしてます」
だとよ。
バカかよ。何度も在籍中に「〇〇さんは未経験で違和感とかそういうレベルではないので、とりあえず何かあったら報告してくださいね」って教えたじゃん。
それなのに「自分で考えてから」をひたすらに貫き続けた結果、サーバにアラート出てるのに無視してサービス落ちて、「なんでアラート出てるの教えないの？なんで勝手に自分で判断するの？まだ判断できる知識ないでしょ？」ってめっちゃ俺怒ったじゃん。んで知識のないキミは何もできないから俺が1人で復旧したじゃん？
なんで成長しないかな〜