Lazy Diary @ はてな

"B"-con に戻る / mixi の個人ページへ
1000 | 01 |
2003 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2004 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2005 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2006 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 09 | 10 | 11 | 12 |
2007 | 01 | 02 | 03 | 05 | 06 | 08 | 09 | 10 | 11 | 12 |
2008 | 01 | 02 | 03 | 04 | 05 | 06 | 08 | 09 | 10 |
2009 | 01 | 02 | 03 | 05 | 10 |
2010 | 02 | 03 | 05 | 06 | 11 |
2011 | 03 | 10 |
2012 | 02 | 03 | 05 | 06 |
2013 | 05 | 09 |
2014 | 05 | 07 |
2015 | 06 | 07 |
2017 | 02 | 05 | 10 | 12 |
2018 | 01 | 03 | 04 | 05 | 07 |
リストのページ
聴きたい CD リスト / 観たい映画リスト / 読みたいまんがリスト / 輪講で使った本 / その他の物欲
 

2018-07-16

[] 藤と葛

  • (A) 世界の侵略的外来種ワースト100に載ってるクズのことを葛と呼ぶ。
  • (B) 世界の侵略的外来種ワースト100に載ってるクズのことを藤と呼ぶ。

生物の同定って難しいよね、という話。

[] 教養とは?

  • (A) 教養とは、文化に関する知識のこと。
  • (B) 教養とは、立ち居振る舞いのこと。

初めて(B)を聞いたとき、それは「品格」のことでは……と思ったんだけど、実際「教養」という言葉が(B)の意味でしか通用しない社会、多いのではという気がする。

トラックバック - http://d.hatena.ne.jp/satob/20180716

2018-05-02

[文化的まちがいさがし] 小学校でひらがなの読みを教えるか?という話

  • (A) 小学校の授業は自国語で行われるんだから、自国語の話す・聞く・読む・書くはある程度できる状態で小学校に入ってくる前提だ、という考え方。たとえば「移民の多い土地では自国語で授業ができず問題となっている」という例が論拠として挙がる。
  • (B) 自国語の話す・聞く・読む・書くは小学校で始めて習うんだから、全くできない状態で小学校に入ってくる前提になっていないとおかしい、という考え方。たとえば「インドには地元の言葉は使用禁止の小学校がある、しかもエリート校だ」「日本統治時代の台湾の公学校では日本語で授業が行われていた」「日本でも方言を使う土地では学校以外で標準語にあまり触れていないケースがある」という例が論拠として挙がる。
トラックバック - http://d.hatena.ne.jp/satob/20180502

2018-04-30

[] GitLabのworker_processesの設定

GitLabのunicornの設定のうち、worker_processes(プロセス数)はCPUコア数+1がおすすめ、という話がGitLabのドキュメントに載っている。

https://docs.gitlab.com/ee/install/requirements.html#unicorn-workers

なんだけど、これってだいたい奇数になるし、それにスループットしか見てないのでは?という疑念が。

  1. GitLabをOmnibus package経由でインストールすると、GitLabの前段にnginxを置く構成になる。ここで、前段のnginxの設定のworker_processes, worker_connectionsの設定と合わせて、unicornのプロセス数を、nginxからGitLabに入ってくるコネクションx2にしないと、複数のリクエストが同時にGitLabに到達した場合、1つのリクエストが1つずつプロセスを掴んだままスタベーションを起こして、そのまま処理がタイムアウトするケースがある。参考: https://docs.gitlab.com/omnibus/settings/unicorn.html
  2. プロセス数が奇数だと、最初に処理を開始したプロセスと、後追いで割り当てられたプロセスとで、タイムアウトのタイミングがバラバラになるから、片方のプロセスだけがタイムアウトする危険性がある。

GitLabの挙動自体に問題が出るケースとしては上記の2つだけど、他にも、2つのプロセスを同時に割り当てられたリクエストと、1つずつバラバラに割り当てられたプロセスとで、nginxのログに残るリクエストごとのターンアラウンドタイムにばらつきが出るから、負荷テストのときなんかにその理由を説明する必要がある、という開発運用上の問題もあるのでは……

[文化的まちがいさがし] (特に小学校の)プールの運用方法

  • (A) 夏、屋外のプールが終わっても水を張ったままにしておき、翌年の春、プール開きの前に虫やカエルなど水生生物の観察をする文化。そのあとプールに繁茂した藻やら何やらを一生懸命に掃除して、やっとプール開き。
  • (B) プールは必ず屋内に設置されているので、藻なんか生えないし、虫もいない。毎年藻が繁茂するようなプールなんて不衛生で泳げない、という文化。

夏の気温が低い土地だと、プールの水温が低すぎてプール授業が行えないことがある(文科省基準では水温≧20℃、よくある自治体基準では水温[℃]+気温[℃]≧45)ので、水温や気温を上げるために屋内プールになっているみたいですね。

そういう人が、関東地方の市民プールや児童プール((A)の状態であることが多い)を見て「汚なくて、とても子供を入れられない」と思うのも無理からぬことなのかもしれません。

トラックバック - http://d.hatena.ne.jp/satob/20180430

2018-04-24

[] 小さな生き物を使った「実験」

  • (A) 子供が小さな生き物を「実験台」にして遊ぶのは、よくあることだし実験や科学的な知識に興味を持たせるのによい、という考え方。
  • (B) 生き物を「実験台」にするのは残酷で、許されることではない、という考え方。

たとえば私の地元は(A)の考え方で、友人の父親(私の親があの人は人格者だとよく言っていた)が、空き缶にアマガエルを入れて焚き火に放り込み、即席骨格標本を作って見せてくれた。

他にも、NHKの夏休み子ども科学電話相談の先生が「昆虫のさなぎを解剖しても大丈夫、先生が許す」と言ったりするのも(A)の考え方だと思う。

一方で、シリアルキラーに対して「むやみに脊椎動物を殺さないこと」という常識を指導をしたという話(ソースどこだっけ)もあって、これは(B)の考え方によるものなのかな〜と思う。

トラックバック - http://d.hatena.ne.jp/satob/20180424

2018-03-29

[] 「事故」という用語の由来

業務アプリの開発者は、よく「料金計算の結果が間違って出力された」とか「システムが○時間止まった」というトラブルを指して「事故」という言葉を使う。

高校や大学では使ったことのない用語だったので、これって業界用語だよね?と思って調べてみると、どうやらそうでもないみたい。

プログラムのバグや、それに起因したトラブルを指す言葉として、高校や大学ではよくJIS X 0014やJIS Q 9000に基づく表現を教えられる。

  • 障害(fault): JIS X 0014
  • 誤り(error): JIS X 0014
  • 故障(failure): JIS X 0014
  • 欠陥(defect): JIS Q 9000

なんだけど、以下に示す Design Wave Magazine の記事では、

  • 障害(fault)→異常(error)→故障(failure)→潜在危険(hazard)→事故(accident)

という表現が取られていた。

参考URL: http://www.cqpub.co.jp/dwm/contents/0109/dwm010900270.pdf

JIS X 0014 の表現とは食い違うように思うけれど、これはこれで分かりやすい。何由来の考えかたなんだろう?(ISO 26262? ISTQB? IEC 61508?)

トラックバック - http://d.hatena.ne.jp/satob/20180329

2018-03-25

[] お金の使いかた

  • (A) 「1円でも多く貯めておけ」という考え方。
  • (B) 「ここで使っとかないと使うときがないぞ」という考え方。

私の育った家は(A)の文化でした。私の育った地域には「買い初め」という文化が存在せず、かつ交通の便がよい場所で、自動車で30分〜1時間も行けば大概のものは手に入れることができました(つまりある時に買い逃したものがあってもまたすぐ手に入れるチャンスがある)。(A)の考え方で不自由しなかったのは、そういった背景もあるのかもしれません。

一方で「買い初め」という文化が存在し、かつ大きな町まで100km(ある時に買い逃したものがあると、次に手に入れるチャンスがあるのは100km先まで移動する用事があるときだけ)という文化だったりすると、どうしても(B)の文化になるのかもしれませんね。

トラックバック - http://d.hatena.ne.jp/satob/20180325

2018-03-22

[] 人から話を振られたときの「えーと」の意味

  • (A) 何か打ち合わせをするときに、わざわざ前もって「頭出しのための打ち合わせ」を行う文化。打ち合わせの中で質問を受けたときに「えーと」と発言しても問題ない(論点を整理しようとしてるんだろう、くらいにしか思われない)。
  • (B) 打ち合わせの場でもないのに、いきなり「○○の件なんだけど」と話を振られたとしても、即答できることが求められる文化。「えーと」などと言おうものなら、主題について真剣に考えていない(真剣に考えているなら即答できるのが当たり前で、その場で何か考えているようでは検討に参加してもらっている意味がない)と捉えられる。

担当者と顧客の対応関係が一対多だと(A)に、一対一だと(B)になるのかとも思ったんだけど、どうやらそういう訳でもないみたいなんだよね。「顧客から見て」担当者と顧客の対応関係が一対一に「見える」……言いかえると、担当者と顧客の対応関係が一対多であることが想像もつかない、という前提だと(B)になるのかな。

トラックバック - http://d.hatena.ne.jp/satob/20180322

2018-03-19

[] 小さいうちの自然との触れ合いかた

英語を学ぶことをもって異文化コミュニケーションとか言うことがあるけど、言語以外の異文化っていっぱいあるよ、という話。

  • (A) 小さいうちは自然に触れ合って遊ぶのが良い、という考え方。小学校で「校区の良いところは?」と先生が聞くと、「緑が多いところ」と答えるのが定番だったりする。
  • (B) 小さいうちは自然に触れ合うのは危険だ、という考え方。野山は毒のある動植物が多いし、迷い込んだりすると危険。人の手の入らない山が多かったり、気候が厳かったりするとこうなりがちなのかもしれない。
トラックバック - http://d.hatena.ne.jp/satob/20180319

2018-03-15

[] 業務アプリケーションの排他処理あるある

一言で「排他処理」と言っても、業務アプリケーション開発で「排他」というキーワードに関連する処理はいっぱいある。パッと思いつくだけでもこれだけある。

  • DBMSトランザクション分離レベル(排他レベル)
  • DBMSの共有ロックや排他ロック(WITH EXCLUSIVE LOCK)
  • DBMSのLOCK TABLEによる排他処理 (テーブルのバッチ更新中に、他のバッチやDBAの叩くSQLからテーブルを保護する)
  • アプリケーションフレームワークで行うDBレコードの楽観的排他処理
  • アプリケーションで実装するDBレコードの悲観的排他処理
  • アプリケーションで実装する業務閉塞処理 (バッチ処理中にオンライン業務が走らないようにする)
  • 並行処理用のライブラリ(JavaのConcurrentHashMapなど)
  • 処理系の同期化機構(Javaのsynchronizedなど)
  • リクエストごとのリソース分離(リクエストごとに一時ファイルを分けるとか)
  • 窓口制御による直列化(MaxThreadsを1にしちゃうとか)

これらの処理を混同せず、かつ使う時にはそれぞれの適不適を判断する必要があるわけです。開発者全員にこれらすべてを正確に理解してもらえるかと言ったら、そりゃ無理ってものです。

アーキテクチャ設計が不得手な人に無理に理解して設計してもらおうとすると、こんなことが起こる。全部本当に言われたことです。

  • 「DBの排他レベルはどうなってますか?」と聞くと「楽観排他をしてるからDBの排他レベルは大丈夫です!」と言われる
  • 「楽観排他処理のテストが抜けてませんか?」と聞くと「同じユーザが複数同時にログインすることはないからテストしてません」と言われる
  • 「これだと処理が競合しますよ」と言うと「処理が同時に行われる確率は低いから大丈夫、SHA-256だって『確率は低いから大丈夫』なんでしょ」と返される
  • 「これだと他のスレッドからデータが見えちゃいますよ」と言うと「ConcurrentHashMapを使ってるから他のスレッドから機密データが読まれることはありません」と返される
  • 「処理の追い越しが起こったときに問題が起こりませんか」と言うと「処理の追い越しはされないはずです、DBMSと同じです」と返される
  • 「複数の処理が同時に走ったらどうなりますか」と聞くと「CPUが1つだから複数の処理が同時に走ることはありません」と言われる
  • 「この処理が間に挟まったら他のリクエストから一時ファイルが見えてしまうのでは」と言うと「ソースのすぐ次の行でファイルを削除してるから間に処理は挟まりません」と返される
  • 「DBのテーブルに楽観排他用の連番がないですよ」と言うと「こう処理をしたら楽観排他がなくても大丈夫でしょ」と返される。パッと見大丈夫そうに見えるのだが、実は2多重には耐えられるが3多重になるとダメな処理になっている。

だから、アーキテクトとかテックリードとかが「こういう時にはこの処理を行うこと」 *1 というプロジェクト内ルールを決めたり、個々の開発者が考えなくてもいいようにアプリケーションフレームワークが面倒を見たりするわけです。

でもそうすると個々の開発者は、「フレームワークが面倒見てくれるんでしょ」と言って排他処理のことを考えなくなったり、業務知識の必要な排他処理の設計を「技術チームで検討してよ」と他へ押し付けたりと、排他処理のことをどんどん考えなくなっちゃう。そうするとアーキテクトやテックリードの裾野が狭くなっちゃうわけで、困ったもんですね。

*1:ちなみに、こういう場合にはあえて「排他」という言葉は使わない方が得策です。前述したとおり「排他」にはいろいろ種類があるもんだから、アーキテクトに言われたとおり実装してなかった担当者が「こっちの『排他』でも用は足りるんだからいいでしょ」と不適切な排他処理を自前で実装してしまったりするので……

トラックバック - http://d.hatena.ne.jp/satob/20180315

2018-01-21

[] キーノートとプレゼンと卒論発表の違い

卒論発表なのにAppleのキーノートみたいになっているケース、この辺を取り違えているのかなぁ、という印象。

キーノートプレゼン論文(卒論とか)発表
聞く人は話の内容に興味があるの?興味があるから聞きに来てる商品やサービスがよく分からないから話を聞いてる興味があるもないもそれで食ってる
聞く人の人数は?とても多いだいたいあまり多くないだいたいあまり多くない
聞く人の知識は?人によって知識はバラバラ商品やサービスそのものとは別に、何か専門分野を持っていることが多い発表される内容の専門家
発表者は何に注目してほしい?このカンファレンス自体(またはそこで発表される商品)がいかに魅力的かプレゼンで直接紹介している商品やサービスがいかに魅力的か発表の自体の内容が妥当か
発表の目的は?カンファレンスを盛り上げること商品やサービスに興味を持ってもらうこと発表者自身が卒業等に足る知識を持っていると証明すること
トラックバック - http://d.hatena.ne.jp/satob/20180121

2018-01-20

[] Cupheadの元ネタ、あまり触れられていなさそうなところ

Super AttacksのGiant Ghost
これは妖怪道中記のご先祖様じゃないのかなぁ……
Wally Warbles (Phase 1)
グラディウスII (VULCAN VENTURE)のステージ1ボス(フェニックス)っぽい。「ドンキーコング リターンズ」が元ネタじゃないの、とも言われてるみたいだけど……
Wally Warbles (Phase 2)
グラディウスIII (Gradius III) のステージ5ボス(ドガス)、またはパロディウスだ!のステージ1ボス(キャプテンペンギンノフスキーIII)
Pirouletta
極上パロディウス (Fantastic Journey) のステージ1ボス(アンナ・パブロワ&めろーら)では。少なくとも回転して弾をバラまくところはそうだと思うんだけど。
Cagney Carnation
これは怪しいけど、足場の下から上向きにツタを伸ばしてくるあたりが、アクトレイザー (ActRaiser) マラーナAct1のボス(ラフレシア)を思いだすんだよね。あと、このステージの足場はロックマン2 (Mega Man 2) のアイテム1号では。
トラックバック - http://d.hatena.ne.jp/satob/20180120

2017-12-30

[] 私は如何にして心配するのを止めて年賀状の宛名を手書きするようになったか

ポエムです。

背景

年賀状の宛名なんて、筆まめやら何やらで印刷すればいいとも思うんですよ。特に、私はコンピュータ・ソフトウェア・エンジニアなので、自動化はまさに自分の存在意義に関わる訳です。

でも、そういう訳にもいかない事情があるわけです。主に人間系で。

年賀状の宛先には、コンピュータ・エンジニアリングを解さない人もいます。もっと言うと、コンピュータを解さない人がいます。そういう人にとって、コンピュータは「字引き」です。「辞書」じゃないですよ?「字引き」です。アイコンという概念は理解できないので、コンピュータが動作している様子を見ても、ひらがなが漢字に変わることだけを認識して「これは字引きだ」と理解する訳です。話がそれました。

若い人でコンピュータを解さない人もいますが、そういう人は単にコンピュータに無関心なだけなので、宛名が印刷だろうが手書きだろうが問題ないと思います。もっと言うと、若いがために、そこから文句が出ても、封建社会の中で自分が受けるダメージはさほど大きくない。

リスク

問題は、一族の中で発言力を持つ人が、印刷された宛名に対して何かを気にかけたケースで、かつ自分がそこからダメージを受けるケースです。なので、たとえ自分は宛名が印刷された年賀状を受け取っているとしても、何の助けにもなりません。宛名を印刷する人は、文句を言う側の人かもしれません。それに、自分宛の年賀状の宛先面を、自分が年賀状を書く相手に見せたりしないですよね?

リスクとしては、たとえば「年賀状をすべて配偶者に作らせているのではないか」という疑惑が発生するケースが考えられます。これは配偶者が専業主婦/専業主夫だと発生しやすそうにも思われますが、かといって共働きだからといって発生しない訳ではないので(なぜかという話は土地・時代の背景によるので省略)、回避しておくに越したことはありません。

回避策

そして、このリスクを回避(低減ではなく回避です)するために、宛名を手書きするわけです。リスクの低減策として以下のような対策も考えられますが、リスク対策コストの面から採用はやめました。

  • 宛名(表面)は印刷して、裏面は手作り
    • 本当はこれがやりたかったんだけど、幼子のいる家では無理ですねコレ……
  • 宛名も(表面)も裏面も印刷して、裏面にコメントを書く
    • 自分のまわりではこれが多いですね。ただ、コメント考えるの大変じゃないですか?宛名書く方がラクじゃないですか?
  • 宛名(表面)を印刷する人と、手書きする人とを分ける
    • 管理が大変だし、高々数十枚なら手順を揃えた方が運用系がラクです。管理を間違えてリスク回避に失敗してもつまらないし。
トラックバック - http://d.hatena.ne.jp/satob/20171230

2017-12-27

[] Gitでときどき見る誤解

中央リポジトリへのpushと納品との関係

誤解

ソフトウェアの請負開発を行っており、自分は下請です。ソースコードの管理に、元請が設置したGitサーバを使っています。

Gitサーバにソースをpushすると、元請の管理するサーバにソースコードをアップロードすることになるので、「ソースを元請へ納品した」ということになりますよね?

回答

ブランチ構成にもよりますが、一般的なブランチ構成の場合、Gitサーバにソースをpushしただけではマスタソースは変更されません。そのため、一般にはpushしただけで「納品」とは扱われないと思います。Gitサーバへのpushは、一時ファイルをサーバに置くのと同じ感覚と捉えて問題ないと思います。

その上で、心配であれば元請に確認をしてください(なお、元請が「納品扱いです」と言ってきたら、Gitを効果的に使えていないのではと疑った方がよいかもしれません)。


ファイルの先祖返りの防止

誤解

今はSubversionでソースを管理しているのですが、ときどきソースが先祖返りしてしまって困っています。

Gitでソースを管理したら、先祖返りしないんですよね?

回答

Git自体に先祖返りを防止する機能はありません(もしあったら、変更を元に戻す修正ができなくなってしまいますよね)。

Subversionでも正しく運用すればソースの先祖返りは防止できます。そのため、先祖返りの原因は使っているツールではなく、ソフトウェア構成管理の運用にあると思われます。

ソフトウェア構成管理の運用が間違っていたら、SubversionだろうがGitだろうが先祖返りは起こります。


Gitの位置付け

誤解

GitはSubversionの後継なんですよね?

回答

GitがSubversionを元にしているとか、GitがSubversionの後継となるよう作られたとかではありません。GitとSubversionとの間に直接的な関係はありません。「ファイルのバージョン管理を行う」という用途が同じで、Gitの方が後から出てきたというだけです。そういう意味で「ChromeはIEの後継なんですよね?」という質問に似ているかもしれません。

あとは「後継」という言葉の意図によりますが、たとえば御社の技術部門が、以前Subversionを推していたところ、Gitを推すように変わったのなら、御社の中では「GitはSubversionの後継」と言ってもよいかもしれません。

トラックバック - http://d.hatena.ne.jp/satob/20171227

2017-10-11

[] ソースコードの自動生成の意義

ここ5〜10年くらいのソフトウェア工学では、「ソースコードの自動生成」はだいたい悪手と言われているみたい。(「どこに何を書いたらいいか分からない」という人のためのガイドとしては、雛形ソースの生成がとても有効だけど、それとは別物の、ロジックを含めた自動生成の話ね)

理由は、生成したコードに間違いがある場合の修正が大変とか、UMLをもとにModel-Drivenな生成をしても結局大した内容は生成できないとか。そんなんだったら、フレームワークを用意して、ホットスポットビジネスロジックだけ書いてもらう方がいいよ、ということみたい。

でも実は、「ソースコードの自動生成」には、技術的というより政治的な利点があるんではないかと思っている。もちろん、それがアプローチとしてイケてるかダサいかは別として、という話なんだけど……

例えば、自分の書いたビジネスロジックのコードが動かないと「フレームワークのバグだ!」って騒ぎ出す人、結構居るんですよ、理由はいろいろですけど。

本当は自分のコードが悪いの分かってんだけど、それを修正する時間を稼ぐために、とりあえずフレームワークが悪いと騒いどいて、フレームワークの開発元(あるいはフレームワークの適用を決めた共通チーム)が調査したり見解書いたりしてる間に自分のコードを直そう、とかね。

そういうことやらかす人に「このフレームワークのこの部分って、何やってるんですか?」って聞かれたとして、共通チームのチームリーダーが30秒間で説明できないような複雑な処理をやってる箇所があると、絶好の時間稼ぎポイントにされちゃうんだよね。

ビジネスロジックがマズいせいで上手く動いてないなら、共通チームはその理由をビジネスロジックの開発担当者の上司(作業指示者)に説明する必要があるわけ。フレームワークの上に載っかってるんだから、こう実装しないとダメなんですよ、とか。

ところが、いまベテラン管理職になってるくらいの人が若い頃は、「ライブラリ」の形でのソフトウェア再利用が持てはやされてて、フレームワークという考え方はあまり広まってなかったから、「フレームワーク?何それ?」ってなっちゃうことがある。

GoFデザインパターンが出たのが1995年、フレームワークの考え方がエンタープライズ分野に入ってきたのが2000年代前半くらいだから、若めの管理職の人はそんなことないんだけどね。

「『関数の呼び出し方が悪い』というなら理解できるんだけど、『呼び出され方が悪い』って何それ?訳わかんないよ。共通的なクラスって、ライブラリのことでしょ?ライブラリ呼び出すどっかの引数がおかしかったんじゃないの?え、違う?何それ。」とかいう反応。

「書いたロジックを上から順に読んできゃいいんじゃないの?え、それも違う?どういうこと?」とかね(この「上から順に読んでいく」以上のことができない人、世代関係なくかなり多いのよ。たぶん、ソース上の記述と実行時の動きを区別できないんだと思う)。

特に、そのやらかしさんの上司が、要点だけ話さないと理解できないソーシャルタイプの人だったりするとなおさら。「口で説明されても分からんから、エビデンスを表にまとめて、頭紙に見解書いて持ってこい!」とかね。

だからフレームワークの機能はできるだけ簡素にしといて、代わりに自動生成したコードで機能を補うわけ。フレームワークの機能が単純なら疑問を挟む余地が少なくなる。

それに、ビジネスロジックの開発担当者にコードが見えてさえいれば、生成したコードが多少長くても「生成されたコードをちゃんと読まない奴が悪かった」っていうことを理由にできる(上司にしても共通チームにしてもプロマネにしても、そういう風に上に報告できる)からね。

開発担当者が抗弁しても、上司やプロマネは「読まなきゃならんコードが多い?共通化とか再利用とかしとらんのはけしからん。え、フレームワーク?何それ。ああ、自動生成。それだったら分かる。理解しやすいようにチュートリアルは用意しといてくれよ」となることが多い。

フレームワークの導入支援をしてる共通チームって、人員が少ないうえに担当作業の影響範囲が広いから、こういうトラブルに巻き込まれるとプロジェクト全体の進捗にすごく悪いんだよね。その上、技術面での責任を負わされてることが多いから、責任をなすりつけられやすいし。

なお悪いのは、調査の結果フレームワークに非がないことが分かっても、「あのフレームワークは疑われたことがある」っていう事実とか、悪印象って消えないんですよね。

だから、一度騒がれるとまた次に騒がれた時に「フレームワークが悪いんじゃ?」って思われてしまいやすくなるんです。そうすると、次にまた時間稼ぎがやりやすくなる悪循環に陥っちゃうんです。

でも、フレームワークに対してチーフプロマネなんかの偉い人が悪印象を持ってると、そのせいで使ってもらえなかったりするんです。だから、なおタチが悪い。だから、そういう時間稼ぎに使われたりされるのを防ぐことだけ考えれば、ソースコードの自動生成は結構有効なんだと思うんですよ。

もちろん、政治的な理由で技術的にまずい設計を採用すると後で痛い目を見る、ってのはよく言われることだけどね。

あとは、サポート期間の話とか。フレームワークの中のロジックは、基本的にフレームワークの開発元が面倒を見る必要がある。業務ロジック考える人たちは、フレームワークのことまで考えてられないからね。それに、フレームワークの亜種が多発すると、ノウハウの使い回しに支障が出る。

一方で、生成したソースの方にロジックがあれば、それはプロジェクトの持ち物(受託開発プロジェクトなら顧客の資産)なので、もちろんフレームワーク開発元もテストはするけれど、リリースしたあとはプロジェクトが面倒を見ればいい。

システムによっては50年物のコードとかがあるんだけど、フレームワークの開発元が50年間面倒見るのはさすがに難しい。システムは50年生きるかもしれないけど、開発手法が50年生き続けることはないだろうからね。

フレームワーク自体をプロジェクトに譲渡する手もあるけど、もともとフレームワークの実装を隠蔽することで業務ロジック開発の負荷を下げていたわけだし、プロジェクトがわも頼る先がなくなるわけで、これは本当に最終手段かな。

[] 日本における貧困率(相対的貧困)と世界貧困線(絶対的貧困)

日本における貧困率のカウントには、相対的貧困が用いられる。日本における貧困率にカウントされるのは、2017年の国民生活基礎調査の場合、年間の等価処分所得が122万円未満の世帯。

世界における貧困率のカウントには、絶対的貧困が用いられる。世界単位で貧困率にカウントされるのは、2015年の世界銀行の設定の場合、貧困線を購買力平価が1.90$/日(1ドル112円として年間で7.77万円)未満の世帯。

トラックバック - http://d.hatena.ne.jp/satob/20171011

2017-10-10

[] iOS 11ではリマインダーに保存したツイートのURLからTwitterのアプリを開けない

  • iOS 10.3では、リマインダーに保存したツイートのURLはTwitterのアイコンで表示される。また、TwitterのアイコンをタップするとTwitterのアプリが起動し、対応するツイートが表示される。
  • iOS 11.0では、リマインダーに保存したツイートのURLはアイコンなしで表示される(Safariのアイコンも表示されない)。また、Twitterのアイコンをタップしても、TwitterのアプリもSafariも起動しない。なお、ツイートのURLでない一般サイトのURLにはSafariのアイコンが表示される。

今のところ回避方法は見つかっていない。

[] OSSの資産計上

ソフトウェアが資産計上される話で「じゃあOSSはどうなるの」という話があった。もしかして「自社の金でソフトを開発したけど、OSSとして公開するから自社資産じゃないでしょ」と言い張ることで一括損金計上することが可能?

  1. まず、実現可能性が検証できていないソフトウェアの開発は、資産化できるか分からないから、研究開発扱いで始める必要があるんだよな。そして研究開発扱いで作成したソフトウェアは資産にできない(でないと、投資してないのに謎の資産が生えてくることになる)。
  2. だからプロプラソフトの実現可能性検証を研究開発扱いで行う場合、掛ける工数は程々にしてプロトタイプっぽいものの開発だけ行うことが多い(以降の開発は資産化する必要があるから投資扱いで行う)。
  3. なんだけど、ここで研究開発扱いのまま開発を最後まで進めてしまい、OSSとして公開した上で、その費用は一括損金計上してしまう。あとは、そのOSSの利用ノウハウだけ内部で秘密にしておけば、減価償却が不要なソフトウェアと、他社と差別化できるノウハウが手に入る……という理解でいいのか?

やっぱり「OSSなら自社資産じゃない(≒損金計上しても脱税じゃない)」が怪しいな。OSSライセンスの多くは著作権法に立脚しているから、著作権は自社に留保されている訳だしな。「収益獲得又は費用削減に使えるか」という判断基準だと文句なしに「使える」訳だし……

トラックバック - http://d.hatena.ne.jp/satob/20171010
 

Firefox latest-Release (Ring Server)

Bugzilla-jp に報告したバグ / Bugzilla-org で関係しているバグ

Wikipedia:翻訳のガイドライン / Wikipedia:FAQ 翻訳