  |
はてなキーワード: 単一とは
現代社会において社会の大多数を占める人類が現役労働生活を送る期間にわたって使い続けられているソフトウェア関連の技術には何があるだろうか。
その期間を約40年間（20代前半～60代前半を想定）とすると、2018年から見ると1978年以前に導入された技術だ。
COBOLは1959年に開発された。ただし、COBOLの規格自体は1993年まで更新されている。
仮に1978年からアップデートしていないのならば、COBOL-78、または、日本の場合は第一次規格（COBOL-65相当）のいずれかになる可能性が高い。
FORTRANは1954年に開発された世界初の高級言語である。もちろん、FORTRANも規格の更新は行われている。
仮に1978年からアップデートしていないのならば、FORTRAN-77が理解している最新の規格となる。
C言語は1972年に開発された。当然C言語も規格の更新が行われている。
このため、仮に1978年から知識のアップデートをしていないのならば、K&Rが最新の知識となる。
UNIXは1969年に開発された。ただし、その後も実装・仕様は修正され続けている。
仮に1978年の技術からアップデートしていないのならば、その仕様・実装はUnix Version 5～6（System Vでは無い）、または、BSD 1.0で止まっていることになる。
POSIXはまだ無い。
1973年に着想された当初、TCP/IPは両者の責務を単一のプロトコルが持っており、そのプロトコルがTCPと呼ばれていた。
1978年にトランスポート層とインターネット層が切り分けられ、TCP v3、IP v3となっている。
現在も使用されているIPv4は1981年にRFC化されており、ARPANETに完全に適用されたのは1983年になる（当時はIP/TCPと呼ばれていたようだ）。
このため、TCP/IPがこのリストの対象であるかはかなり微妙だ。
ディープラーニングの礎の1つになっている多層パーセプトロンの初出は1961年のようだ。
1978年にはIntel 8086が発売されている。
RISCはまだ無い。
無い。
無い。
どれぐらい無いかというと、Sir Tim Berners-LeeがまだCERNにいないぐらい無い。
ちなみに、HTTPはどうもTBLの個人プロジェクトが源流のようだ（あの時代に？）。
エイリアン生命体が利用するこの奇妙な言語は、1958年に誕生した。
1978年から現在まで生き残っているLisp処理系はSchemeのみであるが、この時点での仕様はR1RSである。
ただし、マクロは1963年時点でLisp 1.5に追加されている。
他にも色々あるとは思うのだが、何があるだろうか？
「防災用の電池は単三に統一してるから、単一は使えないんだよな」と思ったけど、こういうのと組み合わせたら、12本一気につかえるかな?
https://nekogata.hatenablog.com/entry/2018/09/10/163206
この記事がはてブで大絶賛されてるが、個人的にはセンス無いなーと感じたので言語化してみる。
今回の仕様を図で書くと
みたいな感じになるとする。
すると、今回スライドで問題視しているのは矢印の右側の通知の部分が1クラスに共通化されている点。
しかし、オブザーバーパターンの出番は図の矢印の部分が絡まり合って処理が複雑になってしまった場合。
今回は1つのイベントから複数のリアクションが発生することは想定しないので
オブザーバーが不要なのは当然。選択肢に出てくるほうがおかしい。
そもそも問題認識(通知部分が問題)と解決策(矢印部分を解決)がズレてるから話がおかしな方向にいってる。
Notificationクラスのサブクラスを作ろう、ならまだ分かる。
確かに設計を言語化するのは大事だが、言語化というのは「それっぽいことは幾らでも言える」危険性がある。そもそもプログラミングというのは芸術であり文学なんだから、センス無いのに言語化を頑張っても「一見それっぽく聞こえるけど間違ってる説明」しか出てこない。
トトロは単一種のみでは繁殖できない特殊な生物です。基本的に全てのトトロはオスであり、メスは遺伝子異常でしか発生しません。繁殖の時には他生物のメスを利用します。しかし、その生物が性成熟的に繁殖可能であるとトトロの遊走子は着床できず分裂が始まりません。他生物のメスは未成熟である必要があり、またトトロは未成熟な者の前にしか現れないことが確認されています。一般に日本の山野ではタヌキのメスなどを利用して繁殖しているようです。メスの体内に放出されたトトロの遊走子は子宮にまで泳ぎ着くと着床し小さな胎盤を作ります。遊走子は３日ほどで２㎝ほどの半透明のトトロとなり体外に這い出てきます(出産) その後小胎盤も排出されます。なお画像はトトロが人間のメスに交尾を行っている貴重な場面を捉えたものです。この後、小胎盤から分泌される特殊な物質によりメスの交尾時の記憶はすぐに消えることがわかりました。(参考資料：日本山野生物学 宮崎某著)
私は一口頂戴や食べ物のシェアが当たり前の文化で育ったので別に気にしない。
家族旅行でラーメン等の外食は、ひとまず一周させて全員がそれぞれの料理を一口ずつ食べてからそれぞれ食べる文化で育った。
ただ、ラーメンみたいな、単一のものがドーン！みたいな料理はシェアもやりやすいけど、アラカルト系はシェアがやりにくいよね。
こないだ久しぶりに親戚そろって回転寿司に行ったときに、寿司の1貫を2人でシェアして食べたが、さすがにみみっちくない…？と思ってしまった。さすがに寿司は1貫一人で食べたいわ。せいぜい5貫分しか胃に入らないのに10種類食べたかったらそうするしかないんだけれど。
元号なんて、明日にでも変わりうることなんて子供でも知ってるから、すぐに変更できる設計にしないで、内部処理に使う人が単に中卒なみの教養しか持ってないだけなんじゃないの？
軽減税率決まってから少なくとも参議院・衆議院で１～２回くらい選挙やってるし、そこで議員陳情して選挙争点にすれば良かったのに、当事者は何をやってたの？
サマータイムは一部議員の暴走を安倍首相が宥める形で後ろ向き発言してるだけで、観測気球あげてる議員がいても実施されることは絶対にないとは思うけど、たとえば勤怠管理システムの勤務時間を日本時間で固定して、海外出張時の勤怠管理をごまかしてた会社も多そうだし、これを機に業務システムを tz data で時差管理するシステムにするよう、見直す機会にしてもいいんじゃね？
taskjuggler とかのフリーなプロジェクト管理システムが、労働者が全世界ばらばらで働いても管理できるように工夫されてるのに、日本の高価なパッケージが全然できてないのを見ると、日本という単一時間帯を前提にしているためとは思っても、もにょる訳で・・・・リモートワークや海外オフィスを簡素に導入できるチャンスとしてtz data化するのはいいことかな、とも思うんだけど。
昨日、菅官房長官が夏時間検討を否定していて一安心していたのですが、まだ前向きなのではないかと思われる報道がありましたので、もう一回しつこくポストします。
https://www.fnn.jp/posts/00398120CX
夏時間を推進しようとしている議員がネットで情報収集する人種ではないことは、SNS上での皮肉や批判にもかかわらず、こうして事態が進行していることからあきらかです。FAXとかはがきじゃないとだめなのかもしれませんが、幸いWeb上にフォームがあるので、自民党と首相官邸に今すぐ自分の意見を伝えましょう。
https://www.kantei.go.jp/jp/forms/goiken_ssl.html
なぜ、限定的な問題を解決するために社会全体の構造を変更しようとするのでしょうか。私はこのような全体主義的な問題解決姿勢には大反対です。仮に開催を２時間前倒すことで猛暑にオリンピックを実施することに伴う様々な問題が解決するとしても、変更が必要なのはオリンピックのタイムテーブルであり、社会全体の時刻ではありません。
ざっくり言うと、私見では2000年問題と同じぐらいヤバく、準備期間が少ないという意味で破滅的にヤバいです（＝回避不能な2000年問題）。
・世界中で夏時間と冬時間に2時間の差がある国はありません（間違っていたらご指摘ください）。ベストプラクティスが存在しません。
・何を大げさな、単に時計を進めたり戻したりすればいいだけじゃないか、と思うかもしれませんが、現代のコンピューターは世界中の様々なサービスと通信しています。そのため、時間を扱う際には内部的には一旦世界標準時で処理されるのが一般的で、内部時計を二時間進めたり戻したりすると様々な問題が起こります。ロシア/マガダン時間はすでに東京よりも二時間進んでいるので、現実的にはユーザーがスマホやPCの時刻自動設定を解除し、手動でマガダン時間に変更するしかないと思います。
・海外からオリンピックを観に来る旅行者にも「スマホの自動タイムゾーン設定を解除してロシア/マガダン時間に設定してください、マガダンのスペルはM, a, g, a, d...」などと航空会社が案内する感じになるでしょう。日本に来るのになぜかロシア時間。
・一方で、20世紀から稼働している古いシステムや、単純なシステムの中には、そもそも単一のタイムゾーン以外で動作することを考慮していないプログラムもあり、このようなシステムについては、内部時計をずらして対応するしかありません。このようなシステムから見ると、突然タイムスリップした状況に見えます。進む方はまだいいのですが、戻る方の処理は大変複雑です（たとえば、切替日の深夜営業の飲食店では、すでにタイムカードで23:30で打刻した人のあとに、22:30の打刻が出現するような状況になる）。この影響範囲についてはまったく予想がつきません。いい加減に対応すると、時計を進めていないサービスと現在時刻で同意できないために、通信ができないような事態が起こります。
夏時間の概念自体は新しいものではないので、ちゃんと日本夏時間が標準化され、各種OSが対応することが前提であれば、工数をかけて設計・実装を行えば、最新のOS上で新しく開発されるシステムは理屈上は問題なく対応することができます。
しかし、日本だけでなく世界中ですでに稼働している、時刻を表示する無数のプログラムについては、時刻表示に必要な処理や時刻設定に必要な選択肢を書き足す必要があります（日本政府が公式にロシア/マガダン時間を採用すると宣言しない限りは）。十分な準備期間を取らずに、変更が必要な箇所をすべて洗い出し、問題なく修正するのは大変むずかしいことです。また、上述のように、古いシステムではそもそも変更が不可能なこともあります。
万が一いいかげんな実装や適当な設計が行われるシステムが混じっていると、そのシステムと通信する際に２時間時間がずれて処理が行われるようなことが起こります。具体的には様々な表示時刻や予約時刻が２時間ずれたり、通信不通になるなどの問題が起こり得ます。
この結果、
・日本夏時間に正式対応していないので、ユーザーが時刻をロシアマガダン時間に手動設定することで当面正常動作するシステム（古いスマホやPCなど）
・日本夏時間に対応しないために、内部時計を進めたり戻したりして対応するシステム
・日本夏時間に対応せずに日本標準時間のまま動作し、ユーザーが時刻を頭の中で変換しなければいけないシステム
が混在することになり、社会的な混乱は必至です。
人間も機械も「それ、どっちの13時？」みたいに迷い、間違えるという毎日がやってきます。文房具屋のレシートには日本標準時が、コンビニのレシートには日本夏時間が印字されているような感じになるでしょう。ツイッターやフェイスブックなどのもともと複数のタイムゾーンに対応しているシステムや、JRや航空会社など大きい会社はたぶんちゃんと対応してくれますが、美容院の予約システムや小規模なネット予約システムは対応できずに日本標準時のまま稼働し続け、勘違いが起こります。
社会的に大きなメリットがあるのであれば、この大混乱のリスクを取ってでも前進するべきだと思いますが、本件については導入のメリットがあまりに限定的であり、得られるメリットに比べてリスクが大きすぎると思います。
https://anond.hatelabo.jp/20180609124213
不具合修正だけでアップデートするの嫌だったのでなにかないかと思っていたところ
自分がスターつけたブコメが一目でわかるよう色や印がつくと、自分が支持した意見や参考になった意見が一覧にできて、考えや参照情報が整理しやすくなると思う。あと、自己を客観視しやすい。賛同してくれる人いる？
それをそのまま実装した形です。
どこにマークするかはいろいろ試した結果、AddStarボタンの枠線に落ち着きました。目に付きやすいし同じブコメに意図せず複数回★付けるのを防ぐ意味で。色は黄色や青だと馴染んでしまうので赤です。
★自体にもマークするのはちょっとやりすぎかなぁと。うっかりデマにつられてしまって★消したいけど100個も200個も★付いてて探すの大変！ということはあるかもしれませんが。レアケースでしょう。
ちなみにinner_starというのは「★17★」みたいなやつです。HatenaStar.jsでそのように命名されてます。
使っているうちにこまごま見つかった不具合をちまちまと潰し、潰してはエンバグして、また潰し、とやってなんとか一段落しました。
不具合5は特に酷く、★フィルタ作成時に「色情報が入っていてそのままでは使えない」からこそaltでなくhrefから取得することにしたにもかかわらず、それをすっかり忘れてエンバグしてしまうのだから情けないこと頻り。忘れるのはわかりきっているので通常は当たり前でない処理にはコメントを入れて未来の自分に注意を促すわけです。今回は忘れることを忘れてしまってコメントを入れなかったのが敗因ですね。
mobile版含め落ち着いたので次は環境固有の不具合…と言いたいところですが報告のあったアドオンの組み合わせバグはどうしようもないかもしれないなと正直思ってます。まだ何も調べてませんが。うまく直れば「同一ユーザーの★をまとめる機能」と合わせて1.1.0をリリースしたい気持ち。お気持ちの表明。
公正な比較はできないんだけど、アカウント数および有償プラン契約数でいうと少なくとも国内のSlackはTeams(Office365)の足元にも及ばない。
https://www.publickey1.jp/blog/18/slack.html
国内だとSlackは無料アカウント含めて50万、有償プラン契約数は15万というのが上記の記事に書かれてる。
全世界だと有償プラン契約者数が300万人以上、ということらしい。単一機能のサービスでここまでの規模に成長しているのはまさにチャットツール市場の覇者と呼ぶにふさわしい。
一方のOffice365なんだけど、Teamsを今まで利用可能だった商用の有償プラン契約数は1億3500万人のMonthly Active Userと下記の2018年1～3月期の決算資料に載っている(スライド9枚目)。
流石に契約者数は明かしてくれないらしいが、Teamsを今まで利用できなかった一般消費者向けの契約者数は約3060万人契約とのこと(スライド10枚目)。
ちなみに少し前に発表されたSurfaceGoの国内版にだけバンドルされて大顰蹙を買ったOffice売り切り版は収入が16%落ちてるらしい。
クラウドへの移行が着々と進行中、という今更説明するまでもない状況みたい。
契約者をいくら誇ったところで、Teamsの利用者の声なんてあまり聞こえてこない。下記のブコメでも「実際に利用して具体的な意見を書いている人」は驚くほど少ない。
http://b.hatena.ne.jp/entry/s/pc.watch.impress.co.jp/docs/news/1132746.html
Office365を企業で大々的に導入している職場をいくつか経験した自分の感覚としても、Teamsをまともに利用している職場は見たことがない。
存在自体を知らない、モノ好きの情シスが適当に使ってる、大規模導入の検討初期段階、といった感じのところが多いのでは？
利用できる契約者は多くても、そもそも存在自体があまり知られてない、というのがMicrosoft Teamsの現状。
Slackはそもそも単一機能を売っているという関係上、契約者はチャットツールを使うために契約しているわけで、Slack契約者≒Slack利用者となるわけだが
Office365はそもそも「情シスの買い切りOfficeカウント地獄からの解放」というお題目や、
「メールサーバの運用からの解放」などといった感じで、Teamsを主目的の一つとしてとらえているユーザーがそこまで多くない感じ(そもそもOffice365リリース当初には無かったサービスだし)。
なので、Office365契約者＞＞Teams利用者となる。
個人的な見解は「ユーザー数拡大ももちろん視野には入っているだろうが、認知度向上の方が比重高いのではないか？」という感じ。
まずはニュースサイトが分かりやすい構図として「MSのSlack対抗サービスがついに無償化」みたいな記事を出せば「あぁ、うちが契約してるOffice365にもチャットツールあるんだ」と知ってくれる既存契約者も多いだろう。
それによって利用率向上を狙っているのでは、というのが自分の予想。
Slackへの攻勢をかけるという線も薄い。
わざわざ自社より小規模でロイヤリティ高くて引き剥がしにくいユーザーを狙う意味がない。
そもそもOffice365自体の契約者数は絶好調で成長中だからね。
よく言われることだが、Microsoft TeamsはSlackのパクリから始まったサービスだ。
それは間違いない。
ただ、現状のSlackとはターゲットユーザーが違う関係上、進化の仕方が微妙に違っている。
コミュニケーションプラットフォームという大枠の括りは一緒でも、自社内にチャットツール以外が無く、外部との連携で機能拡張をするSlackとは対照的に
Office365のビジネスプランにはMicrosoft版IFTTT的なFlow(これも始まりはIFTTT的な感じだったが、もはや全くの別物になった)や、
Microsoft版TorelloなPlanner、Web版Office(プランによってはクライアント版)、Sharepoint、Exchange、何でもありだ。
流行り物はどんどん巻き込み、投げ売りといってもいいレベルの価格付けでユーザーを囲い込んでいってる。
Plannerが無償版なしだったり、Flowの無償版がお遊びレベルの内容なのと違って、Teamsの無償プランがここまでのレベルなのは
単一サービスで300万以上の契約を勝ち取るクオリティ、リテラシーの高いユーザーによって構成される成熟したコミュニティ、
チャットツールの無償版なしではOffice365の契約が切り崩されかねないという危惧もあるのだろう。
チャットツールが代替するものとしてよく挙がる「メール」はOffice365で重要な位置にいまだあるわけで、
下手にSlack導入して「あ、これメールサーバ要らんな」みたいなことになると、Office365自体の契約も危ういわけで、必死になるわけです。
もう諦めて Slack 買収した方が良いのでは。
諦めるどころか、これから防衛戦頑張らなきゃならないんですよ。
買っても大したユーザー増にならないし、どうせ既存ユーザー逃げるし、金の無駄でしかないから
買収の線は薄いんじゃないですかね。
Trello対抗にとりあえず作りましたで後は放置のPlannerやWunderlist買収してから放置のToDoとかと同じ末路を辿る予感しかない
PlannerやToDoはバックエンドのAPI整備がやっと最近ひと段落したので地道に改善はしてたみたいですよ。
そのおかげでまだ不十分だけどFlowのトリガーとアクションが追加されたしね。
僕らのYammerが転生したってこと？(・・？)
Yammerって気軽に投票募れるぐらいしかTeamsに対する優位点見出せないんだけど、
ちょっと前にデスクトップアプリ出してきたりと、まだなんかやろうとしてるみたいなのが意味不明。
Skype for Businessを生贄にするぐらい今のMSはTeamsに本気だから、当分大丈夫だと思う。
上にも書いたけど、はっきり言ってチャットサービスとしての完成度はSlackが上だと思う。
Teamsは結構使ったけど、よく言えば頻繁に機能追加される。悪く言えばそもそも機能が足りてない。
1年以上前のリリース当初は場所によってIMEがONにできなかったりしたしね。
あと機能追加もよく言えばコミュニティベースだから、機能要望を挙げて、それに賛同者を募って
多数の賛同を得られないと開発者の目に留まりにくい。たまに投票数の低い案が優先的に実装されたりもするけど
基本的には投票数の多い案件から実装機能が選ばれることが多い。
ただ、わかってる人がゴリゴリ使い倒す、っていう方向でクオリティを上げてるSlackに対して
TeamsはあくまでもOffice365との密な連携を主題において、外部とも連携できるように、っていう方向なので
ターゲットユーザーがそもそも被らないのでは、と個人的には思ってる。
Slackに満足してる人はOffice365に囲われてるおまけって時点でTeamsの印象悪いだろうし、
Office365についてくるTeamsで十分な人はチャットツール単体に1000円/人月なんて払わない。
MS側もSlack対抗というより、Slackが開拓してくれたチャットツールという新たな魅力でOffice365の契約数を増やしたい、という感じに見える。
本エントリーは増田文学賞2018前期の投票に関する総合案内用のエントリーです。投票は以下にリンクを張った各部門の投票用エントリーのブコメにて行ってください。また、文学賞全体に関する質問・意見は本エントリーに、各部門に関する質問・意見は部門別投票エントリーにはてブか増田で行ってください。
2018年8月4日：結果を発表しました。発表が遅れ、すみませんでした。
はてな匿名ダイアリー(以下、増田）の匿名性と日記というフォーマットによって生まれた「名乗るほどではない、あるいは名乗ることはできないが誰かに話したい感情や体験、発想をウェブ上で共有し、称え合う文化」を守り、増田のますますの発展に寄与する
(注：以上期間はすべて日本標準時とする)
本文学賞の運営者は、各部門ごとに投票を集計し、投票されたエントリーのうち投票数上位5件を「ノミネート」、最多票を得たエントリーを「受賞エントリー」として投票所上で発表する。
コメント賞を除く全部門の投票を総計し、最も多くの票を得た記事を大賞とする。大賞の発表は別記事にて行う。
集計時はコメント文をプレーンテキストとして扱うので、リンクされなくても大丈夫です。
