カテゴリー
ネットの事件

Stack Overflow が求人機能の廃止を発表

技術系Q&Aサイトの Stack Overflowジョブ機能と開発者ストーリー機能の3末での廃止を発表しています。

Stack Overflow やその他のカテゴリ毎の多くの質問掲示板を抱える Stack Exchange では、技術的な問題への解決法を検索する人たちのための場所を提供し続けて質問と解決法のセットの巨大なコンテンツを持つにいたりました。Stack Overflow は日本語版を作って日本語市場にも参入しています。

技術者が毎日のように検索結果から集まることから、技術者向けの求人広告の場所を売るというのもマネタイズとしては自然で、英語版の Stack Overflow を見ていてもサイドバーに楽天やメルカリなど、英語圏でも多く活動している日本企業の求人を見かけることも多くあります。

公式のコメントによれば、人材獲得機能は他の強力なライバル達との競争が激しく、利用者の問題を解決するという基本機能に集中したいということ。

強力な競合というのは LinkedIn とか Indeed とか Glassdoor とかでしょうかね。採用されるエンジニア側のコミュニティよりも、採用担当者やエージェントのコミュニティの方が強かったりするのかもしれません。後者は採用に関して予算を持ってる方ですし。

あるいは、普段技術的な調べ物で使っているユーザーも、転職先を探す時に Stack Overflow を見てみよう、とはならなかったのかもしれません。

via reddit/programming

カテゴリー
ネットの事件

プルリクエストを巡る bot 対 bot の非生産的なやりとり

mysql/mysql-server でのプルリクエストを巡る、bot 対 bot の戦いです。

登場人物、いやbot は以下の2つ。

  • 依存ライブラリが古くなっているのを見つけてパッチを作り更新を提案する(今は)GitHub内のサービス dependabot
  • MySQL への更新提案に対してOCA(Oracle Contributor Agreement = オラクル貢献者同意書)に同意済かを確認する mysql-oca-bot

プルリクエスト上でのやりとりはこんな感じ。

dependabot: Babel (国際化に関する Python製ライブラリ)の最新バージョン 2.9.1 を確認しました。バージョン 2.8.0 から 2.9.1 への更新をコミットしました。

mysql-oca-bot: PRありがとう。OCA には同意してますか? 詳しくはこちらを読んで手続きに従ってください。MySQLバグ管理システムに登録したメールアドレスを添えてくださいね。

(ここで一か月)

mysql-oca-bot: リクエストに反応がないので、このリクエストはクローズします。

dependabot: 今回はこれ以上言わないけど、次のバージョンが出たらまた連絡します。もし次の特定のバージョンまでスキップしたい場合は以下の手順に従ってその旨通知してください。もし気が変わったらこのPRを再開してくれてもいいんですよ。

自動ボット2台だけでやりとりが完結してますね。完結といっても建設的なものではなく、何も進んでませんが。

mysql-oca-bot の方は、OCA に同意して何らかのリプライをつけることで、そのあとに別の人間のユーザーが出てきてマージするかどうかの議論を進める仕組みのようですね。OCA に同意しているかどうかを毎回提案者に聞くのが手間なので、そこを bot 化したのでしょう。

しかし、dependabot はそんな事は知らないし、追加の返答もしないから単に期限切れとなってしまう。

そもそも dependabot を動かしてるのは MySQL であり結局 Oracle なのだから、OCA も何も無いような。dependabot からのPRの場合は人間のアカウントに渡すように設定するべきじゃないのかしら。

同じリポジトリで検索してみたところ、他にも10個ぐらい同じような無為のやりとりが見つかりました。

via twitter

カテゴリー
ネットの事件

アクセント付きアルファベットの名前を登録できないEUの銀行はGDPR違反

EU 内の銀行で、氏名のアルファベットにグレーブ(á)とかウムラウト(ü)とか、アクセント記号がついている人が本名を登録できない、という問題に対する訴訟があり、アクセント記号が登録できないのはGDPR(一般データ保護規則)違反である、という判決が2019年に出ていたそうです。

テレンス・エデン氏(Terence Eden)のブログによれば、銀行がアクセント記号つきの氏名登録を拒絶したのに対し、この顧客はEU一般データ保護規則(GDPR)の16条「訂正の権利」を根拠に訴えるに至ったそうです。

この16条は以下のようなもの。

The data subject shall have the right to obtain from the controller without undue delay the rectification of inaccurate personal data concerning him or her. Taking into account the purposes of the processing, the data subject shall have the right to have incomplete personal data completed, including by means of providing a supplementary statement.

データ主体は、管理者から、不当に遅滞することなく、自己と関係する不正確な個人データの訂正を得る権利を有する。取扱いの目的を考慮に入れた上で、データ主体は、補足の陳述を提供する方法による場合を含め、不完全な個人データを完全なものとさせる権利を有する。

一般データ保護規則(仮訳)

これに対し銀行は、1995年に開発された米国製メインフレーム上のアプリを使っており、このシステムが1964-65 に制定されたEBCDICコード表を使っていることから技術的に対応不可能なのだ、と弁明していたということ。

実際のところ、EBCDIC にもCode page 37などアクセント記号に対応したセットがあり、これを使うように設計しなかったシステム設計の問題のようですが、EU内の人の移動が今ほど活発でなかった時代、アクセント記号を使わない国の銀行では少数の外国名顧客のことまで考えていなかったのでしょうね。

本来の正しい文字で氏名を登録できない、という意味では漢字かなを使ってる日本人なんかは絶対にヨーロッパの銀行では登録できないだろうと思いますけど、それはまあ日本がEU加盟国ではないのでそこまでは要求されることはなさそうです。でもEU域内の加盟国で使われる文字に非対応なのはだめでしょうね。

今ならUnicodeベースで作るでしょうから、EU向けに提供するサービスでアクセント記号を氏名に入れられないなんてことはなかなか起こらないとは思います。しかし、うっかり入力文字のフィルタでA-Za-zなんてことをしていると、こういう苦情が来る可能性は十分にありそうです。

判決が話題になったのは今ですが、判決自体は2019年に出ていたものです。銀行は25年前のシステムを直せたんでしょうかね?

via Twitter