  |
はてなキーワード:OSDNとは
スラドとOSDN の受け入れ先募集を開始して 1 年以上が経過したが、残念ながらこのままサービス終了を終了する運びとなった。
OSCHINA はOSDN を無償で取得したものの、特に活用することができずに多額の費用を費やしたようだ。スラドはもともと OSCHINA に譲渡するのではなく、AWS 上で共存しているOSDNから分離して日本企業が引き取るという話になっていた。しかし、分離する前に OSCHINA への譲渡が完了してしまい、OSCHINA 側へ正確に分離の話が伝わっていなかったため、分離の交渉は難航した。ようやく OSCHINA が分離に合意したのは 2023 年12 月。この時点では引き取りを予定していた日本企業で一定期間事業買収ができない状況であり、OSCHINA 側は既にサービス終了の意向を示していた。
その後、OSCHINAはいったん発表したサービス終了を撤回し、受け入れ先募集を開始。OSCHINA では受け入れ先募集にあたって支払った経費だけでも回収したいとの意向を示していたが、スラドとOSDN を分離する場合のサーバー費用の比率が確定せず、応募していただいた企業の方々と交渉できないまま時間が過ぎていった。最終的にサービス終了との結論に至った理由についてはコメントを得ることができなかった。関連するドメインネームはすべて OSCHINA が保持し、将来的に新しいサービスで使用する可能性もある。
サービス終了予定は 3 月31 日。まだしばらく時間はあるが、新しい雑談場所を決めるなり、連絡手段を確保するなりしておくといいだろう。また、スラドの皆さんは多くが既に必要なデータを確保したと思われるが、まだの方はお早めに確保することをお勧めする。なお、サービス終了時点でAWS の契約は終了せず、OSCHINA のエンジニアがサービスを停止させる予定だ。そのため、消去作業を行うまでサービス終了後もサーバー上にはデータが残されるので注意してほしい。実際の停止時刻については後日お知らせする。
末筆ではあるが、スラドを存続させようとご応募いただいた企業の方々、および募集に協力していただいたアピリッツに謝意を示したい。
ストーリーby headless2025年03月15日 6時00分終了部門より
たまたま見かけたブクマカのお気に入りに、公式アカウントっぽいのがいっぱいいたのでまとめてみた。はてなID順。
なお、ブクマ最終日が特定の日付に偏っているのは、タイミングと注釈の内容から↓のせいじゃないかなと思っている。
2022-11-16 16:41 jumpplus,KAI-YOU追加
2022-11-17 7:30 coliss追加／要約文つけてブクマしているのは偉いと思う
2022-11-1810:45 otekomachi追加、いくつか列を追加
SMBCのソースコード流出、俺も昔どこかの大企業が販売しているシステムの、クローズドなはずのソースコードをSourceForge (現OSDN) で見たことあるよ。もちろん問い合わせ窓口から通報して、数時間もしないうちに消えたけど。
アジア系の名前の人のリポジトリに、普通に置いてあった。たぶん、その人にとっては、「無料でソースコードをアップして管理できるところ」以上の認識がないんだろう。「会社で作業して、終わらないなぁ。家に持って帰って続きをやるから、アップしとこう」「よし、今日も仕事するか。まずは、昨日家で書いたコードをダウンロードして...」という感覚で、公開・非公開、オープンソース・クローズドソースの概念がない人も多い。
WordPressにはパーマリンク機能があるんだけどそれは内部のrewrite_ruleとかいう機能で実装されている
そんで、rewrite_ruleはまぁ文字の通り書き換えルール何だけど、リクエストパスを良きように読み替えてくれる機能です。
んで、どうやってrewrite_ruleを書き換えるかと言うと、add_filter で 'rewrite_rules_array' にルールを追加するのが一般的っぽいです。
それを更新するために $wp_rewrite->flush_rules() を実行するんだけど、これ実は、アクセスごとに実行しては行けない機能っぽい。下記みたいな記事でinitフックで実行する用例がネット上には転がってるんだけど、これを鵜呑みに実装するとバグる。
https://qiita.com/M-Ikezawa/items/22d24455f776065865ea
wpdocs.osdn.jp にすらこの方法が書かれてるの…まずくね？
具体的にどうバグるかと言うと、rewrite_rules_array に設定した関数がときどき実行されません。
なんで rewrite_rules_array に登録した関数が呼ばれないかと言うと、WP_Rewrite::wp_rewrite_rulesっていうメソッドの中でget_option('rewrite_rules') して、DBに保存していたルールがなければ、新規にルールを作成するっていう処理をしている。その新規にルールを作成する処理ってのの一環でrewrite_rules_arrayに登録した関数も呼ばれます。
まぁこのDBにアクセスしているのが怪しいですね。怪しいんですよ。そのものズバリflush_rules()を実行するとこのDB値を一旦削除して、ルールを作り直すっていう処理が動くんです。
なので並列アクセスしていると、DBの中身が作成されたり削除されたりといった動作が繰り返され、「flush_rules()実行しているのに、rewrite_rules_arrayに登録した関数が呼ばれない」といった動作になります。つまりバグります。
そもそも rewrite_rules_array に登録された処理はアクセスごとに実行されるべきものではありません。WordPressでのリライトルールは上記の通りDB管理されていて、DBに保存されたものを使い回すので、rewrite_rules_array の実行は一度だけ行われれば十分になるような処理を書くべきです。rewrit_ruleは処理が重いので毎回ルールを書き換えるような利用は想定外なのでしょう。
そして rewrite_rules_array に登録した関数を変更したら、WordPressのパーマリンク設定で設定を変更するボタンを押せば、処理内部でflush_rules()が実行され、rewrite_rules_array に登録した関数の処理が適用されます。
できるといえばできるけど、毎回アクセスごとに動作させるのがNGとなると実質出来ないってことになります。rewrite_ruleで対応するのは諦めましょう。
