  |
はてなキーワード: エンバグとは
Android版バグについて開示された文書を少し読むだけでいくつかのデマが分かった。
https://note.com/mugura/n/ncc3c61de39ea で情報開示されたPDFを読むことができる。
議事録側はまだ読んでいない。
最初にHER-SYSの開発のためにパーソルプロセス＆テクノロジー株式会社と税込約2億の契約があった。
COCOA開発は原契約を税込約3億へ変更とすることで対応した。
契約変更の時、再委託先を株式会社FIXERの1社から以下5社へ変更する申請がなされた。
厚生労働省 ┗ パーソルプロセス＆テクノロジー 2億6771万（税別。以下同様） ┣ FIXER 1億2062万 ┣ エムティーアイ 1615万 ┃ ┣ E社 355万（MTIから） ┃ ┗ D社 41万（MTIから） ┗ 日本マイクロソフト 2201万
| 株式会社FIXER | 新型コロナ感染者等情報把握管理システムの開発、監視運用、サポートデスクの一部業務、およびサービスの提供 |
| 株式会社エムティーアイ | 接触確認アプリケーション開発の一部、リリース後のヘルプデスク/運用保守業務 |
| E社（MTIからの委託） | メールサポート（日本語/英語） 接触者に対する電話サポート（日本語のみ） |
| D社（MTIからの委託） | 初期検収業務の一部、および保守開発準備業務の一部 |
| 日本マイクロソフト株式会社 | PMO支援、技術支援 |
デマについて
・まず2億から3億の差額約1億がHER-SYS側への繋ぎこみおよびiOS・Androidのアプリ開発に充てられていることになる。アプリ開発が3億のように言うとデマ。
・そして3次請けの位置の2社は業務範囲に開発は含まれていない。「多重請負でたったこれだけに」みたいな図でここの金額が出てきたらデマ。
ここからは憶測や調べ切れていないこと。（議事録側で分かることもありそう）
・COCOAのベースはOSSのCOVID-19Radarで、開発に関してはどこかにOSS利用という線を引いた方が分かりやすい。
・OSS利用を0円発注の搾取とは通常言わないが、今回に限っては、1国1アプリの条件がある中で、6月中旬公開の宣言されて実質納期になったり、
初期の品質批判がコミッターに直撃してリタイアしたところを見ると受託者に近いようにも思う。
https://www.itmedia.co.jp/news/articles/2006/23/news107.html
・開示された文書での契約期間は2020/7/31までだが、それ以降の体制は未確認。
・2020/9/28にiOS版の不具合（通知あるのに接触なし表示）修正のためにアップデートが行われ、その時Android版にエンバグが発生した。
https://www.asahi.com/articles/ASP236SR9P23UTFL00R.html
・政府CIO補佐官(ブクマカ)のツイートでは、EN API自体の制約や、アプリで選定された技術から人材・機材の手配の難しさに言及している。
https://twitter.com/masanork/status/1358207125546127362
https://twitter.com/masanork/status/1358187420492001281
・人材についてはMSがいるのにと思ったが、MSの支援が切れる事情でもあったのだろうか。
・COVID-19Radarでない方のまもりあいJapan（の一般社団法人Code for Japan）は新型コロナウイルス感染症対策テックチーム第1回から参加していたが、採用されないことになったについて根拠が不透明とある。
https://medit.tech/code4japan-not-incharge-of-contact-tracing-app/
・COVID-19Radarの中心がMS社員であったことや、Azure DevOpsなどMS一色の技術選定であったことなどから経緯を訝しむ考察があった。
https://blog.rocaz.net/2020/06/2140.html
https://blog.rocaz.net/2020/06/2171.html
https://blog.rocaz.net/2020/07/2257.html
・そして今回の開示された文書でもなぜCovid-19 Radarが選ばれたのか不明とある。
・選定が不具合と直接関係ないとは思うものの、利用人口少ない技術スタックを選んで人材不足になったなら遠因にはなってる気がする。
・大きくやらかした時に責任取り切れず法人ごと消えることの無さそうな大企業を窓口に選びたいところまでは分かる。
あの増田あの後どうなったかな、などと気になる事がよくある。もしかしたら追記があるかもと、見に行ってしまう。追記してくれると嬉しい。嬉しい気持ちはもちろんあるのだ。
しかし、考えや悩みを一旦なんの相槌も無く吐露するという、日常会話では発生せず、インターネット上のテキストコミュニケーションでもあまりない状況から生じる文章こそを楽しんでいる自分も居る。
そこは完結して、完成している。いくらか逡巡しながら、場合によっては少し言い回しを編集しながら、自分の中にあったわだかまりに名前をつけて書き出す。昔の公文書や文豪の私筆よりは重くなく、 SNS の投稿よりは軽くない、ここにしか表れ得ない文章がある。
そんな完成された文章に追記が入ると、リアルタイムで読んでいた人のためのものになってしまうような気がして、なんだかもったいないような気がしてしまうのだ。いつか誰かが辿り着いたとき、ただその文章に良さを感じて読み進めると、一応のオチや締めがついている。もう本人は見ていないという事実だけが、閲覧者に流れ来る。
一度完成された文章に関連付けるものとして、トラックバックがあった。近藤さんの独自解釈によって本来の目的は変容し、ある場所ではコメント機能になり、ある場所では呼び出し機能になった。
近藤さんのサービスセンスは好きだが、技術理解に関しては何かと異論を唱えたくなる。彼にとって技術は手段であり、我々にとっては目的である。トラックバックというシンプルな技術仕様は、 Web 的には大変よくできたものだった。 SPAM 耐性が低いのは一旦置いておこう。
本来、リンクする側からしかアプローチできないけれど、そのエントリに言及している記事はみんな読みたい。言及側から言及したことを知らせられればリンクできるのでは、というものがトラックバックだった。そしてその頃の感覚として、他人の記事にわざわざ言及するには、一定の価値ある資料とするべきであるという雰囲気があった。そしてそんなにコストを掛けるのであれば、自分の blog の記事にしたいというのは自然なことである。
トラバが言及になったから変わったとは言わない。ここは他エントリに起因する記事があったり、全記事を読むブクマカが居たりすることで成り立っている、特殊な環境だ。そこで使われるトラックバック機能は既に本来の意味から遠ざかっていたので、名前をそれらしいものにした方が良い。正直、外部トラックバックを受け付けなくした時点でスレッド型 BBS のようなものにした方が良かったと思うが、既に開発者がいないラボサービスにそこまでのコストは掛けられなかったのだろう。
現在でもたまにある改修は、新人に「はてな」を弄っていることを自覚させるための儀式なのかもしれない。
まとまらなかった！ PV があるうちは存続させてもいい程度なのだと思っていたけれど、ちょいちょい改修が入る（しかもエンバグする）。
あるフリーランスのプログラマーにバグ修正をやってもらってた。
フリーランス君はそんなふうに自分が仕事ができないのをなぜか他人のせいにしていた。
責任をなすりつける相手は顧客窓口を担当していたSEさんだった。
SEさんはバグ修正の優先度や修正スケジュールも決めていてフリーランス君に修正期限を指示していたのが気にくわなかったのだろう。
フリーランス君はSEさんに向かって「だったらSEさんがバグ修正すればいいでしょう!!」と逆ギレしたこともある。
遠くの席からそれを聞いていた僕はSEさんが反論する前に「それはフリーランス君の仕事でしょう!!」と大声を上げた。
そんな逆ギレを許していたらチームが無茶苦茶になってしまうから。
また、会議の時にフリーランス君が「元々のコードが悪いからそもそもバグ修正は無理なんですよ」と発言したこともあった。
その元々のコードは昔、SEさんが書いたもので要するに自分が仕事ができないのはSEさんのせいだと言いたいわけだ。
SEさんが「元々のコードが具体的にどう悪いのか説明してください。」と反論したら黙ったけど。
僕はそのやりとりを聞いてもうフリーランス君は切ろう、と決め後任のプログラマー探しを始めた。
そんな中、SEさんが顧客とメールで交渉しているメールスレッドを見て真っ青になった。
メールスレッドにフリーランス君が割って入って意味不明の主張をしていたからだ。
これには顧客が「窓口はSEさんのはずなのになぜアンタが割り込むのか!?」と強い言葉でフリーランス君に注意していた。
フリーランス君は顧客に注意されて意気消沈していたので「余計なことをせずに自分の仕事に集中してください」と言うに留めた。
しかし、しばらくしてフリーランス君はうちの会社に来なくなった。
フリーランス君とうちと直接契約してたわけじゃなく、ある会社の社員としてうちに来ていた。
その会社の社長に連絡を取ってもらっても、もう仕事を続けるのは難しいの一点張りとのことだった。
仕事を放り出してバックレたフリーランス君のケツ拭き作業が始まった。
そのケツ拭き作業の1つとして、チームメンバーへのヒアリングもした。
するとフリーランス君は他の協力会社の人達に「SEさんは言い方が優しくないから一緒に仕事ができない」と陰口を言ってまわっていたこともわかった。
「はあ?! 言い方が優しくないから一緒に仕事ができない?!」
頭がクラクラした。
そこまで腐っていたのか・・・、なぜもっと早くフリーランス君を切らなかったんだろうと激しく後悔した。
ケツ拭き作業が落ち着いてから、フリーランス君を仲介した会社の社長と話をした。
社長の口から出たのはなんと「おたくのSEさんの言い方が優しくないからフリーランス君が潰された」という耳を疑う内容だった。
「言い方が優しくない」
つまり、フリーランス君は仕事のバックレはSEさんのせいだと社長に言い訳したのだ。
その腐った言い訳を右から左に口にするだけの社長に僕は言った。
「すみませんでした、これから御社の社員には優しい言葉で接するように気をつけますよ。」
社長の顔色が変わった。自分の間違いに気がついたんだろうけどもう遅い。
https://anond.hatelabo.jp/20180609124213
不具合修正だけでアップデートするの嫌だったのでなにかないかと思っていたところ
自分がスターつけたブコメが一目でわかるよう色や印がつくと、自分が支持した意見や参考になった意見が一覧にできて、考えや参照情報が整理しやすくなると思う。あと、自己を客観視しやすい。賛同してくれる人いる？
それをそのまま実装した形です。
どこにマークするかはいろいろ試した結果、AddStarボタンの枠線に落ち着きました。目に付きやすいし同じブコメに意図せず複数回★付けるのを防ぐ意味で。色は黄色や青だと馴染んでしまうので赤です。
★自体にもマークするのはちょっとやりすぎかなぁと。うっかりデマにつられてしまって★消したいけど100個も200個も★付いてて探すの大変！ということはあるかもしれませんが。レアケースでしょう。
ちなみにinner_starというのは「★17★」みたいなやつです。HatenaStar.jsでそのように命名されてます。
使っているうちにこまごま見つかった不具合をちまちまと潰し、潰してはエンバグして、また潰し、とやってなんとか一段落しました。
不具合5は特に酷く、★フィルタ作成時に「色情報が入っていてそのままでは使えない」からこそaltでなくhrefから取得することにしたにもかかわらず、それをすっかり忘れてエンバグしてしまうのだから情けないこと頻り。忘れるのはわかりきっているので通常は当たり前でない処理にはコメントを入れて未来の自分に注意を促すわけです。今回は忘れることを忘れてしまってコメントを入れなかったのが敗因ですね。
mobile版含め落ち着いたので次は環境固有の不具合…と言いたいところですが報告のあったアドオンの組み合わせバグはどうしようもないかもしれないなと正直思ってます。まだ何も調べてませんが。うまく直れば「同一ユーザーの★をまとめる機能」と合わせて1.1.0をリリースしたい気持ち。お気持ちの表明。
或る趣味界隈で有名な大学教授が作ったオープンソースのプロジェクトがあって、ほとんど9割方完成されてたので（というか特段改めて更新する必要性も無いくらいの状態というか）、みんな便利に使ってたのだけど、その中になんかやけに意識高い人がいて、そのプロジェクトに少しだけ手を加えちゃった。
その人、ダウンロードされていく様を見て「自分が作ったソフトが普及するのは気持ちいい」「自分はこのプロジェクトに一番貢献している」って言ってた。
UI関係の変更だったのだけど、使ってみたらどこを弄ったのか知らないけどUI以外のところでエンバグが起こっているし、UIの変更っていっても今までのを使っていても別に問題は無い程度で特段便利ってわけでもなかった。
タイトルを見ると派生物っぽく正規のプロジェクト名のとなりに「z」とか書いてあったので、確かに派生した部分はその人が関与してるんだけど、「作った」って書いてあるとなんかモニョる。
駄目なプログラマはとにかく人に親切でない。この程度のデバッグならと思えるようなこともしない。金銭的な面だけじゃなくて、「ずっと担当しているプログラムに対してこの程度の手間なのに」と驚くようなことすら断ったり。
これはおそらく、デバッグをして見つかる不具合修正の費用対効果を計算できず、自分のメンツを重視するからだと思う。とあるプログラマにお願いを断られたこと（だいたいプログラマ個人の作業として30分もかからないこと）で、私は落胆し、数万円くらいのバイトを紹介するのをやめたことがある。数万円は曲がりなりにも派遣でプログラミングをしているプログラマにしてはたいしたことがない数字かもしれないが、それでも30分くらいの手間で、数万円のバイトを紹介してもらえるなら、悪くない投資のはずだが。
駄目なプログラマはとにかく無駄遣いをする。プリミティブな定数で済むところでも、かまわずにオブジェクトを生成する。メモリ少ないのにいいのか、と私が思うようなことでも、無駄なものに考えなしにメモリを使う。
駄目なプログラマはメモリを使わない。無駄遣いはするが、メモリは使わない。
うまくいえないが、メモリを使う勘所を意識していないのではないか。キャッシュを作ってメモリ上に保持すべき所で毎回 DB にアクセスし、効率的なキャッシュで DB アクセスを減らして高速化を行う事に気が回らない。
いわゆる memchached もそうだが、実績のあるライブラリなどを利用するための準備には時間とお金を惜しむ。そのことでより開発が楽になることを知らないからだ。
駄目なプログラマは周りを大切にしない。エンバグばかりする代わりに、同僚のテストは手伝わないし、私のようなプログラマにバグのパッチを送ったりは決してしない。
これは、その行為を無駄遣いだと思ってるのかな、と思ってたのだけど、そこまで合理的ではない。ただ周りの好きな人間を大切にしなくてもかまわないという気持ちのようだ。
駄目なプログラマは勉強をしない。とにかく本を読まない。講演を聴かない。人から教えてもらわない。
勉強したことが無駄にならないことをわかっていないからかもしれない。
駄目なプログラマは書くより語る。末端で参加しただけのプロジェクトの自慢話をしたりはしょっちゅうだ。そして自分のプログラムを書こうとしない。
プログラムを書いて学ぶメリットより、自分の話をするメリットのほうがでかいと思っているわけだ。ペラペラ自分の話ばっかりする駄目なプログラマは多い。
駄目なプログラマは挑戦をしない。やったことない言語や、苦手なことをあえてやってみようとしない。たとえば、勉強会なんかにいかない人たちだが、たまたまいったら流行っている言語をやってみようなどということはない。普通の人が面倒になって見てるだけだったりするのに加わるだけで、積極的に挑戦をしようと思わないことが多い。
失敗するリスクの低さと、経験のリターンの大きさを知らないのだろう。
駄目なプログラマは短期的にポジティブ、長期的にネガティブである。よく駄目なプログラマはネガティブな人が多いと言われるが、実際には、そうでもない。短期的には楽観的だったり不安に思わなかったりすることが多い。避けられるバグをなるべく避けようとする気持ちが少ない。
一方で、将来的に自分がどうなるか、などに関しては驚くほどネガティブである。長期的に悲観になっても無駄だということを知らない。逆に、短期的に「まあいいか」と楽観的になると、のちのちバグが発覚するのを知らないので、目の前のことに対しては真剣に考えない。
私が知っていることをまとめてみたが、実際にまとめてみると驚くほどシンプルである。だがこれを全部できてる人はなかなかいない。
駄目なプログラマになりたいと思っている人は、マネしてみるといいことがあるかもしれない。
※「貧乏人に大量に触れて初めて気づいた8の共通点」http://anond.hatelabo.jp/20110825204218 のプログラマ版です。
「素性の良い言語」に求められる性質は色々あるけど、一つは、モジュール同士を疎結合に保つための機能が備わっていることが挙げられる。つまり、「理解していない人」がエンバグしても、その影響範囲を最小限に留められるということ。これが、機能追加やデバッグ時にどれだけありがたい性質であるかは、多くのプログラマに同意してもらえると思う。
大規模なコードになるほど、一人の開発者から見てブラックボックスになる部分が増えるのは避けられないこ。Javaの言語機能を適切に使えば、手に負えないバグを埋め込むことを回避しやすくなる。
最近、中国人と仕事をする機会があって、文化の違いというかいろいろ見つけたことがあるので増田に書いてみる。
とにかく手を動かすことについては早い。割とボリュームのある（日本人の目で見て５人チーム１週間程度）仕様変更も、１日とか２日でリリースしてくる。
ここで注意したいのは、彼らはリリースしてくると言うところ。何度も目を疑ったのだけど、デバッグということをしてこない。
エンバグも日常的に起こる。デバグＡを済ませたらエンバグして、そのバグを直したらバグＡが再び出てくるというような。もちろん、バグ報告したあと直してくる速度もめちゃくちゃ速い。
しかし、手を動かしてくれないときは、とことん動かしてくれない。何度指示をしても「わかりました」という返事をきいても、指示がきちんと反映してくれない。この差はなんなんだ。
お金儲けに関しては天才的。常にいろいろなビジネス展開を考えていて、話をしてみるとあらゆるビジネスというか、商売のネタを披露してくれる。よくそこまで考えられるなーって思う。
彼らの特徴としては、確実に儲ける方法が好きというところ。リスクを取りたがらない。たとえば、売れるかどうかわからないけど、売れるとぼろもうけする物と、すでに売れている物の模倣をすることだったら、迷わず模倣を選ぶ。確実に儲かるから。
ビジネスに対する考え方は至ってシンプル。なので、いらなくなった人は問答無用で切られる。本当にあっさりしてて、さっきまで隣で談笑してた人が数時間後に解雇されてたなんて事もザラにある。
仕事をしていてリソースが不足してきたとき、日本だと現状で解決できないかを考え、その結果として効率化といった手法をとることがある。しかし彼らは「人を増やせばいい」の一択。中国にある本社の社員数は、半年で４倍になったという。
ただし、首切りは頻繁に行われるので、人の入れ替えはあり得ないほど激しい。誰でもできる仕事は、かわりはいくらでもいるということだ。
食べながら話をするというのも、ごく普通にありふれた風景。ランチミーティングなどになったら、クチャラーのオンパレードであの音が嫌いな人はたぶん卒倒するかも。１ヶ月もすれば慣れるけど。
もっとあるかなと思ったけど、まとめたらこんな感じになってしまった。
本当は詳しくいろいろ書きたいのだけど、所属などがばれてしまうといろいろ面倒なので今回はこの辺で。
