  |
はてなキーワード: プログラムとは
以前、短期間だけど、B2B通信のミドルウェアメーカーにいた。B2B通信っていうのは企業間でのデータのやりとりのこと。
あなたが近所のスーパーやドラッグストアで買い物をしているとする。お店は品物を仕入れるため、B2B通信で「冷えピタを20ケース売ってください」というデータを送り、受け取った卸売業者は「受注しましたよ」というデータを返す。卸売業者はさらに、メーカーに対して発注データを送り、メーカーは卸売業者に受注しましたよというデータを返す。
あるいは、あなたがAmazonで買い物をしたとする。Amazonはクレジットカード会社に請求データを送り、クレジットカード会社は成否をAmazonに返す。
あるいは、あなたが使っているA銀行の口座から、別のB銀行の口座に振込をしたとする。当然、銀行間でやり取りが行われる。
こういうデータのやり取りが、毎日恐ろしい件数で行われている。サマータイムが導入されるとしたら、B2B通信にも影響がある。ちょっと考えただけでも、
サマータイム導入が決まった場合、そういった問題が起きないように対応しなければいけないわけだけど、
限られた予算の枠内でサマータイム導入にコストを取られるということは、それ以外の施策は後回しになる。停滞のもとだ。
対応方法が企業によってばらけそうなところも問題だ。B2B通信しているすべての企業が揃って完璧な対応をできれば問題ない。でも、場合によっては、「うちはIT予算に余裕がないので、サマータイムの切り替わりタイミングでサーバの時計を2時間ずらすだけにします」みたいなところも出てくるだろう。そうすると、「時刻は確かに2時間ずらされているけど、タイムゾーンの指定はJSTのまま」みたいなデータが送られてくることになる。メーカーとユーザ企業の力関係にもよるけど、ミドルウェアでは「通信相手ごとにサマータイムの対応方法が違う」という前提で複雑なプログラムを組まないといけなくなるかもしれない。
おそらく、サマータイムの開始・終了時には、夜間にも関わらず関係各社の担当者が待機させられることになるだろう。B2B通信も夜中には頻度が下がるのが確かだけど、ないわけではない。データの種類によっては「毎日1回夜中の3:00に送る」みたいなケースもある。万が一何も起きなければ安心して寝ればいいけど、何か障害が起きた場合、影響が大きくなる早朝までに対応しなければいけないので、ミドルウェアメーカーの運用担当者も開発担当者も召集され、タクシーで集まって全員で対応するハメに、というのも十分ありうる。
海外との取引がある企業もあるから、日本だけの話でもない。「へぇ、日本でもサマータイム導入されるんだ。どれどれ、このJDTっていう1時間ずれるやつかな」なんて中途半端に対応されてトラブルになるケースもあるかもしれない。
……ここまで書いてきて思ったけど、サマータイムの対応で問題なのは、費用負担が一番大きいんじゃないだろうか。
オリンピックは、主催者や、そこから仕事をもらっている広告代理店、建築業者、スポーツ用品メーカーなどが収入を得る。それ自体は別にいいんだけど、そのためにサマータイムが導入されて、オリンピックと関係ない企業や、そこで働く人たちが負担を求められている。娯楽はそもそも、提供する側がサービスして、享受する側がお金を払うという交換をするわけだけど、サマータイム導入で反感を買っているのは、オリンピックから直接利益を受けない企業や人が、「あくまでサマータイム対応にコストがかかるのであって、オリンピックにお金を徴収わけではないから問題ない」という論理でタダ働きさせられることが大きい気がする。いわば、日本全体から金をふんだくって、オリンピック主催者・関係者に集約するかたちになっている、その構図が問題なのではないか。
そこで提案なんだけど、「サマータイムは導入してもいいから、対応にかかる費用を東京オリンピック主催者に請求できる」というかたちに持っていくのがいいのでは。
「いやいや、開始までの時間が残り少ないのが問題だよ」という意見もあると思うけど、費用が請求できるなら、優先度上げてできることが色々増えるよね。単純に人を増やしたり、深夜残業代にあてることだけじゃなくて。
たぶん、開催時刻をずらすんじゃなくてサマータイム導入、という話が出たのも、「IOCとの契約で時間が決まっちゃってるから変えると違約金払わされる」とかそういうことだと想像するので、サマータイム対応にかかる費用を主催者が負担して違約金回避できるなら、問題ないよね。……まさか、対応費用が払えないほど莫大になることがわかっていて、それを全国の企業に押し付けようとしているわけではないよね？ もちろん、「サマータイム対応費用を都や国が補助金とか出して負担する」ではダメですよ。それだと結局、主催者が儲かるために国民全員に負担を押し付けるかたちになっちゃうので。
いやぁ、いい案を思いついた。これなら全員がニッコリ、Win-Winな感じになれそうですね。よかったよかった。
統合失調コントロールする気ないに反応ありがとう。
森田？は直後は多少効果あったみたいだけど大きな変化はなかった。
正確には森田のプログラムやったわけではないけど、
自主入院したいって言うから入院させたら
1週間で「気が狂いそう」「マジ病院ヤバイわ」「あの状態よりは大丈夫です」
そう言って出てきた。
認知は通っているデイケアの社会福祉士さんが超ナイスガイだった時は少し常に前向きだった。
性格的によいカウンセラーがいるって言うのは大事みたい。
ただ、職業カウンセラーというよりデイケアと合体してる方が良いみたい。
東京に住んでるので色んなプログラム団体があるはずだからと言ったら興味は示したけど
電車に乗りたくないとやはり拒否した。
いつものように自称スーパー営業マンが突拍子もない事を言ってきた。
営「ねえ、Excel 作ってよ」
俺「一部の機能だけなら作れますけど、それでもExcel買ったほうが安いですよ」
営「それだと ウチで売れないでしょ。ウチで作ればウチが売れるじゃない」
俺「（何言ってるんだコイツ）はあ」
営「WordとかPowerPointは要らない、っていう人向けにさ、Excelの半額で売り出せば、間違いなく売れると思うんだよ」
俺「（何言ってるんだコイツ）はあ」
営「どう？作れる？」
俺「1億円くらいあれば作れるかもしれませんね」
って、答えたんだけど、1億円でも無理だよなーと思ってきた。
フェルミ推定の得意そうなはてなの皆さんなら、いくらと言って諦めさせますか？
LibreOffice の クローン から始める、とかではなく、自社で販売するにあたって何のライセンスにも違反しないようにするとして。
目に見える地下鉄や道路の建設などには、時間が掛かることは想像しやすいですが。
プログラムって400字詰め原稿用紙で何枚分のプログラムを書き換えることになるのだろうか？
OSのアップデートで何とかなるのはWindowsでOfficeとWebブラウザしか使ってない人と、iOS/Androidで純正アプリしか使ってない人くらいでしょうね。
一方、電気水道通信料金の計算、列車や飛行機の運行、コンビニのPOS、銀行や証券のシステムから電子マネーの決済基盤とか、全部プログラム見直しですよ。
――ん？ 元増田へじゃなく？
ベアプロやってれば他人に問う意味ないじゃんって話かと思ったけど、俺への言及だと別に独り言だからいいじゃん、みたいな感じか？
表現力とweb投稿の動機は、自己対話による整理とは根本的に違うぞ。
甘えがあるかどうかだ。
プログラムはほぼ正解が存在し、それ自体を稼働させるのが目的だが、文章表現は訴えたい内容を伝えることが目的。
web系プログラマは稼働する経緯より結果を重視して目的が得られればいいと考える傾向が強いらしいが、それでも文章表現とは全く異なるのを自覚した方がいい。
正解の決まったコーデックのＱ＆Ａと、表現力が目的なのにそれに悩んで他人に縋るのは違うんだよ。
増してやその部分のオリジナリティで勝負する側面があるのに、匿名だし"読者"の助言がベアプロみたいなものだと誤解させるような言及はどうかと思う。
寧ろ、webに書き散らして顔の見えない誰かのくれたアドバイスが、独り言に自動POSTされた無償のレスだと元増田が思ってしまうようなら、本当に文章書きには向いていない。剽窃が常態化するだけだ。
俺はそう思う。
会社でどんな影響がでるのか調べてみたので、メモしておきます。
・チャイム
40年ものの機材。始業と昼休みと終業を告げるチャイムを車内に鳴らす。放っておいても1か月に5分進む微妙な精度。サマータイムボタンはもちろん付いていないので、手動で調整する必要がある。
・FAX
時計が入っていて、タイムスタンプが入るよね。あれはあまりいじったことないけど、サマータイム機能とかなさそう。海外展開していたら、ありそうだけど、日本仕様は機能をデチューンしてそう。
UTC時を基準に動いているので、対応は可能。現在の日本ではサマータイムがないので、タイムゾーンを東京・大阪あたりを選ぶとサマータイム機能がオフになるようになっている。正式にサマータイムが決定して、windowsアップデート後にサマータイム機能が利用可能になる。
・携帯電話
いわゆるガラケー（ガラパゴス携帯）は、一応、電波で時計の調整がかかっているので、キャリアが対応すれば、勝手に変わりそうな気がする。スマホもOS自体は対応してそう。アプリは開発者ごとに国際化対応を考えていたかどうかなんだろう。
電波の元が調整したら勝手に変わるのか。テストしたことなないだろうから、実際に発動させたら大変そう。
サマータイムボタンはもちろん付いていないので、手動で調整する必要がある。
これが厄介。開始時間にバーコードを読み、さらに終了時間にバーコードを読むようなプログラムの場合、通常時間からサマータイムに変更されるタイミングにかかったときに正しい経過時間が記録されない恐れがある。多分、夜中に行うのであれば、いまのところ影響は回避できそう。24時間操業のところだと困りそう。サーバーは、そのまま放っておくというのも手のような気がした。記録を引きだす必要があるときに変換するとか、解釈するというのが現実解かも。
・予定表プログラム
同じ時間が2回くるタイミングと2時間飛ぶタイミングはどう表現しようか。深夜のことなので、寝ているだろうからスルーしていいのだろうか。切り替えタイミングのときに例外処理をいれたほうが親切かな。現時点では同じ数え方で時間が経過することを前提に描画しているので、サマータイムによる時刻の変更は想定していない。実際にない制度のことを想定してコストをかけても誰もお金を払ってくれないよね。
サマータイムの初日は、夜勤の後の朝の交代の人は2時間早くくるのか。サマータイムの終わりの日は、2時間残業しないと次の交代の人がこないのか。
サマータイムは開始時と終了時が大きなトラブルが発生すると考えられています。
例え話にします。ある製造業の会社があります。オフィスには社員が見える位置に壁掛け時計がついています。この時計は少し特殊で、秒数しか表示されません。具体的に言うと、ロンドンで1970年1月1日0:00から経過した秒数です。例えば、日本時間の2018年8月11日午前0時は、1533913200となります。
けど、これでは不便なのでオフィスには変換器が用意されています。その変換器を通してみれば日本時間の日付と時刻を教えてくれます。ですので、多くの社員はこの変換器を利用しますが、たまに、変換器を使わずに仕事をする人や自分で変換器を作る人もいます。また、オフィスの変換器は、サマータイムに対応しています。サマータイムが始まる際は、XX年6月30日23:59:59の1秒後はXX年7月1日の2:00:00です。また、終わる際は、XX年9月1日2:00:00の1秒後はXX年9月1日の0:00:00です
毎日0時になったら仕事を始めるAさんがいます。Aさんは、オフィスの他の人が自分の机に持ってきた書類をファイリングして、日付をつけてキャビネットにしまう仕事をしています。その書類には完成した商品の情報が書いてあります。完成した商品の情報が書いてある書類をキャビネットに入れることで、お客様が商品を受け取りに来た時に、受付の社員がどこに取りに行けばいいのか分かるのです。
XX年6月30日。その日の仕事を終えたAさんは、次の0時を待っています。しかし、変換器を通した時間ではXX年7月1日の0時は存在しません。ですので、次に仕事をしたのは7月2日の0時でした。
7月1日の朝になってオフィスにお客様が品物を受け取りに来ました。受付のBさんはお客様の依頼を受け、キャビネットを探しに行きますが、書類が無いので、「まだ完成していません」と答えます。本当は商品はできているのに…。
XX年8月31日0時。Aさんは、普段通り仕事をはじめました。自分の机の上にある書類をまとめて、「XX年8月30日分」と書いてキャビネットにしまいます。しかし、その2時間後、またXX年8月31日0時がまた来ました。あわてて自分の机の上を見ますが書類はありません。（工場が動いているのは8時〜20時）書類が無かったので空のファイルに「XX年8月30日分」と日付を書いてキャビネットに向かいますが、すでに同じファイルがあります。
キャビネット内に同じ名前のファイルは存在していけない決まりなので、そのファイルは捨てて空のファイルをキャビネットにしまいました。
朝になってオフィスにお客様が品物を受け取りに来ました。受付のBさんはお客様の依頼を受け、キャビネットを探しに行きますが、書類が無いので、「まだ完成していません」と答えます。本当は商品はできているのに…。
さて、これを解決するにはどうしたらいいでしょうか。
そうです、Aさんには◯月◯日には、0時はないので2時に仕事して下さい。さらに、□月□日は0時が2回くるので2回目の0時に仕事して下さい。また、受付のBさんには□月□日の1回目の0時には、キャビネットには書類は来ないので、2回目の0時になるまで待って下さい。と教えればすみます。サマータイムはこうして対応可能なのです。
サマータイムを考慮していないシステムは無数にあると思われますが、考慮したシステムに改修すれば問題ありません。不具合が発生するケースは、例え話以外にも考えられますし、解決方法は他にもあるでしょう。
自社の全てのシステムをチェックして、上記のようなエラーが起きる可能性はないか精査します。多くのシステムは仕様書がなかったりするので、その場合は実際にテストしてみたりしないといけません。さらに、AさんとBさんの連携のように、他のプログラムと連動する場合は、サマータイムの開始・終了の際にどう対応するかを取り決める必要があります。社外のシステムの場合もあるので、そうした会社と調整が必要になります。
精査、改修、そして実際に問題ないかテストするプロセスで、日本全国で対応できるまで、おそらく最低でも数年程度はかかるでしょう。2000年に合併したみずほ銀行のシステム統合は今年完了するようです。18年経って、完成しないのではと言われていましたが、なんとか完成に漕ぎ着けられそうです。
また、改修には予算がかかります。ぽっとその予算を確保できるでしょうか。大企業なら内部留保等で対応できるかもしれませんが、中小企業だと数年かけて積み立てないといけないかもしれません。
いずれにせよ、5年くらいかければサマータイムを導入することは可能です。それでも一部のシステムは間に合わないかもしれませんが、生活に支障が出るレベルではないでしょう。多くの技術者に「無理だ！」と言われて心配していた、オリンピック委員会のみなさん、安心して下さい。
大丈夫です。最短でも2023年にはサマータイムは導入することができます。
現在動いているシステムは、すべてサマータイムを見越して作るべきだったかもしれません。それは確かにそのとおりです。その意味では、IT屋にも責任があるのかもしれません。
しかし、サマータイム対応となると考慮した設計をしなくてはならず、費用が余分にかかります。１億のシステム開発で、サマータイム対応することで２０００万余計にかかる、ということも充分考えられます。元号や2000年問題と違って、導入されなければ永遠に使われない機能です。
web もあるし、紙の表示もあるし、それとは別にPDF作成もあるし、
最近の（ネットで有名な）プログラマーは、プログラム作るばっかりで、（くそコード）保守の経験が少ないからのう。
COBOLから移行したシステムは、たとえCで書いてあっても、ロジックはそっくりCOBOL時代のままだし、時刻文字列なんてむしろ当然のことさ。
幸いJSTはサマータイムの変動がないので、JST - 9 すれば全部 UTC に変換できる。
というわけで、JSTで保存しているプログラムも内部はそのままでUI部分だけ変えれば無理くり対応できる可能性があるんじゃないか？
サマータイムはタイムゾーンの一種と考えることもできるので（該当時期だけタイムゾーンがずれると解釈できる）、複数タイムゾーンにすでに対応しているシステムだと導入は楽だ。
アメリカの場合はタイムゾーンが西部、中部、東部と3つあるので国内向けのシステムでもほとんどがタイムゾーンを意識して作られているし、そもそもタイムゾーンが導入されてから長い。
ところが、日本はどうだろうか？
日本は結構東西に長いのだが、タイムゾーンは一つしかない。日本標準時 JST だ。 UTC より9時間すすんでいるので (UTC+9)と表記される。
複数タイムゾーンに対応したプログラムを作る場合は、内部では UTC に変換して処理や保存を行い、表示と入力部分だけ現地時間に対応するのが一般的だ。
サマータイムになろうが、別タイムゾーンに飛行機で移動中であろうがUTCは常に進み続ける。（正確にはうるう秒があるので1秒間足踏みしたりするのだが）
ローカルタイムはサマータイムになった日とか場所を移動した日には前後に飛んでしまうので時刻順にデータを並べ替えたりするのには使えないのだ。
ちなみにアメリカ軍の戦闘機F-22が日付変更線を超えて沖縄に初めて来たときソフトウェアがバグって修理のためにアメリカに帰って行ったことがあった。笑いごとではない。
さて、日本中にある既存のシステムはどうだろうか？君の作ったシステム、関わったシステムはどうだろう？
MySQLのシステムタイムゾーンをJSTにしていたりしないか？
「JSTで保存して、JSTで出力すればタイムゾーンの変換なんかしなくていいじゃん？だって日本人しか使わないんだぜ？言語のバリアがあるからね（はぁと」
なんてシステムはざらだ。下手すら時刻を文字列型としてJST前提で保存してたりして。
他のシステムと相互通信するソフトウェアはどうだろうか？相手のタイムゾーンがJSTであると仮定していないか？アメリカ西海岸から接続があった時も大丈夫か？
てか、そもそもロジックと表示部分がちゃんと分離されているか？モデルとビューの分離。教科書でならっただろ？
おいおい、ビューで計算したものをモデル側で未チェックで保存したりしてないよな？
テストは書いてあるか？タイムゾーンが変わって時間が飛んだり戻ったりしたデータが送られてきてもこけないようになっているか？
そもそもテストは書いたことあるのか？てかソースはそもそもあるのか？
あー・・頭痛くなってきた。やめよう。
「大臣、無理です！」
そうだね。
ところで、それほどまでに優れたサマータイム採用国のアメリカですら、サマータイム絡みのプログラム不具合は割とよくあるようだ。であるならば、極東の島国ごときでそのように高度な仕組みであるサマータイムを採用しようなどとは、おこがましいことなのではないだろうか？
プログラムの動作パターンがtrue/falseの2分岐だけで表現できるとは限らないってだけの話に
「２値論理ではなく３値論理が必要」とかSQLの型にはnullがあるとか「現実世界の正確なモデリング」とか言い出してたのかよ
マジめんどくせーな
実際のプログラムって「現実世界は真・偽だけじゃない、不明もある、だから3値論理でモデリングすれば解決」なんてものじゃないぞ。
不明があるなら「不明の扱いはどうするのか」を決めなくちゃならない。
「不明なら真or偽として扱う」ならやはり真偽の2値でいいしそうするべき。（世の中のプログラムはほとんどこのパターン。だからなるべくnullableにするなと言われる）
真・偽・不明の3パターンで扱いが変わるなら、true/false/nullを入れることも考えられるが、ほとんどの場合は、パターンが更に増えることを考えて、整数型でパターン１、パターン２、パターン３のように扱うべきだと思う。
関数型プログラミング使ってないでしょ？
バリバリに使ってるが
実務でプログラムの仕様検討なりレビューなりするときに、お前みたいなこと言いだすやつがいるとしたら邪魔でしか無いが、関数型プログラミングで何作ってる人なんだ？
