  |
はてなキーワード: 標準規格とは
増田の指摘は的を得ていて、内燃機関から電気に変わって何が変わるのと言うのは仰る通りだと思われる。
それは何故かと言うと、現在のEVは、内燃機関の基本設計を電動化しだけだから。
PHEVなどはまだエンジン積んでるから仕方が無いにしても、EVにするんだったら、もうちょっとEVだからできる事を追求するべきではないかと思う。
各社色々なコンセプトカーが出ているが、実際にはなかなか普及しない。
これがEVで望まれるイノベーションの最たるもの。今までの内燃機関だと、中央に大きなエンジンがあり、それをシャフトなどを通じて物理的に力を伝え、2輪もしくは4輪を駆動するという仕組みだった。
これを、車輪の中、あるいは車輪のすぐ近くにモータを置いて、直接タイヤを回してやろうという考え方がある。これを「インホイールモータ」などと言う。
これにすることで、
こんなにいいならじゃあなんで製品化できねえの？と言う話としては、ホイール部分というのは最悪600℃とか超高温になり、10Gとか強い衝撃が加わるため耐久性に問題があるのである。
よく言われるバネ下質量が大きくなる問題については、実は制御である程度どうにかできるのだが、そのためのコストアップが結構キツい。
ただ、自動車業界は諦めていないので、いつかは商品化されて売れるようになると思う。ただいつになるかは不明。
トヨタは小型モビリティから実用化を始めていて、まずはここら辺からかもしれない。
参考記事：
https://car.watch.impress.co.jp/docs/news/1479589.html
https://www.nissan-global.com/JP/INNOVATION/TECHNOLOGY/ARCHIVE/IN_WHEEL_MOTOR/
https://response.jp/article/2021/10/05/350066.html
https://xtech.nikkei.com/atcl/nxt/news/18/16374/ (有料だけど）
内燃機関には不可能だが、EVだったら可能な制御は実はかなり多い。
最も分かりやすいのが「速度制御」ではなくて「トルク制御」が可能な部分。
速度制御というのは、どれぐらいのスピードで回すか制御するかということ。これはエンジンでも当然できます。
一方で、トルク制御というのはどれぐらいの力を出すかという制御ができるということ。これはエンジン車でやるにはかなり大変。トルクセンサでセンシングはできるんだが、制御する方法が摩擦を使う方法ぐらいしかない。
この他にも制御はEVの方が優れている部分が多くて、自動車が電子制御になればなるほど、EVの利点が上がっていく。
では何故普及していないかというと、電子制御のシステムが高すぎるから。特にセンサーが凄く高く、そのシステムだけで車一台買える価格がする。これでも安くなったんだが、価格の下落は停滞中。
さらに、実はこの部分のメリットを出すだけなら、ハイブリッドカーでもできるんだけどね。と言うか一部はやってる。
車の標準的な利用としては、普段は、一日1時間～2時間ぐらい使って、それ以外は止まっていると言うケースがほとんどなので、バッテリーはせいぜい50～100km分ぐらいしかつかわない。
しかし、ちょっと遠出するときに困るため、より多くのバッテリーを搭載していることがある。
この時に、この余っているバッテリーを家庭用蓄電池として使おうと言うのが、このV2H。シンプルには、太陽光発電などで昼間ためた電気を夜使おうと言うことなんだが、これはあんまり筋が良くない。何故かと言うと、昼間は家に車がない。職場などに向かうため充電ができない場合が多いからだ。
なので、一歩進んで
ことにして、自宅という環境から切り離して、電力網全体として備わっているEVの電池を電力供給のバッファーとして機能させると言う構想。
太陽光発電で昼間余った電力を、その家という範囲を通り越してBEVに充電、夜間放電させ電力供給側に回す。これを面的な制御で行う事で、電力網の最適化と安定化を行おうというわけだ。
既に島単位で実験都市などがつくられて実現しているところがあり、有効性も確認されている。のだが、電力網の仕組みそのものから更新しなければならず、更に電力網って装置の更新周期が20年とかが当たり前なので、今から普及が始まっても相当に時間がかかると思われている。
ちなみに自動車側の充電規格、CHAdeMO(チャデモ）という規格があるが、これはV2H対応の仕組みが入っているので、CHAdeMOに対応しているEVで、ちゃんと実装している車はやろうと思えば数にV2Hを適用できる。
日本の規格らしく、最初からこれらに利用できるように整備されている訳だが、一方で北米でテスラが作った規格の方は、現在まだ非対応（2025年対応予定と言われているが、Teslaの提示スケジュールの信頼性はほとんど無いので…）。
また、次に日本と中国が中心となって作っているChaoJi(チャオジー）という規格はCHAdeMOの発展形で、こちらもV2Hに最初から対応してスタートする予定。
ちなみに、よく「北米ではテスラのスーパーチャージャーが標準規格になったんだから日本はCHAdeMOなんてガラパゴス規格捨ててそっちに合わせろ」というようなことを言う人がいるけど、あれは日本のCHAdeMO規格に乗りたくなくて北米の自動車メーカがぶち上げたCOMBOという規格がクソ過ぎた結果、CHAdeMO相当の技術を多少は備えていたスーパーチャージャーになっただけで、別にスーパーチャージャーが優れているわけではない。確かに規格上大容量に対応していると言うが、まだCHAdeMO規格を超えるような高出力出せる充電設備も自動車もまだほぼ存在してない。
この辺りはちょっと調べれば嘘だと分かるような事を振れて回っている人がいるので要注意だ。嘘を広めたいか、外国から聞こえてくる作られた偶像に踊っているかどちらかだと思うんだけど、EV界隈ってどっちも多いから厄介。
一方でChaoJiと言う規格は日本と中国が中心となって作られているが、これはスーパーチャージャーを含め他の規格に対して後方互換を確保し（コネクタ形状の変換だけでいけるので）最終的には、少なくとも内部システムはこれに統一されていくと思われる。
閑話休題。
この可能性は3つぐらい思いつく。
EVは補助金を全開にして購入すると結構安く買え、さらに電力にはガソリン税やら軽油取引税やらかからないので安く済む
例えば、都市内で、一日60km以内ぐらいの配送作業（郵便局でだいたい走行距離一日30kmぐらいらしい）で住む宅配のラストワンマイルとかでは既にコストメリットがある。
ただ、地道な改良による電池の価格下落は限界が近づいているようなので、苦しい。全固体電池も直接的に価格を安くする技術ではない。
ガソリンスタンドはどんどん減っていて、特に山間部の過疎地で維持出来なくなってきており、燃料供給に影響が出ている。
ただ、市場としてはわずかなのと、トラックなどの商用車のEVが一般化するのは相当時間がかかると思われるから、EVで解決してそれにより地方から普及、というには結構厳しいかも知れない。
一方で、全く燃料インフラが存在しない途上国などでは、ソーラー発電システムさえあればとりあえず電力供給ができるのは大きく、あり得るかもしれない。
ただ、間違いなく採算性が悪い市場だから、テスラとかは絶対やらないしどうかな、とは思う。
例えば、国内産業の育成のためと言ったような政策予算がガッツリ付いて、安く買える場合、あるいは、政策に対応するために購入する必要がある場合。
近年だと2010年ぐらいにHTML5でサポートする動画とかのコーデックで特許があるから、ブラウザ間で足並みが揃わなかったりしたと思う。
その後googleとかが中心になって自由なコーデックを作ったりしたはずだ。
自社が他社から訴えられるリスクを下げるために防衛的に特許を使うならともかく、積極的に他社を特許侵害で訴えるのは好きになれないな。
ソフトウェアは自由なライセンスで広く使ってもらって改良していこうという文化があるかもしれない。
また、特許によって標準規格が揃わないと、それようにコード書かないといけないから手間だというのもある。
Qi2がMagsafeベースで標準化されることについて「AppleがLightningでこれをやってれば」的なコメントに星が沢山付いてたのを見て思ったことを適当に書く。
何故かそのことを記憶から捨て去ってる人達がはてな村には多い。なぜだろう。
個人的な見解としては、「Appleがスマートフォンの物理ポートの標準化を積極的にやることは今までもこれからもないんじゃないか?」という感じだ。
Lightningが何故標準化されなかったか、それは「セキュリティリスクの不確定要素が増す」からだと思ってる。
物理的に接続して電気信号をやりとりするポートの仕様を他社と合意を取りながら決めると、おいそれと変更できなくなる。
他社の要求を捻じ込まれて自社の仕様を曲げなければならなくなる場合もある。
沢山の企業の都合が限界まで盛り込まれて見るも無惨な混乱が生じている。
その混乱が物理ポートで起こると、USB-Cの仕様上の欠陥がスマホのセキュリティリスクを生じさせることもある。
自社の独自仕様なら仕様策定も自社のみで対応可能だが、標準化されているとその対応を多数の会社の合意を取りながら進めなければならない。
そういう自社の戦略上の自由度が減ることを嫌っているというのもあると思う。
あとはこれだ。
広告屋になり損ねたAppleが生存の為に仕方なく掲げたのは「プライバシー保護」だ。
プライバシー保護の観点からすれば仕様違反の機器の接続を拒否できない物理ポートの実装は受け入れられない。
もちろん、iPadの外部ディスプレイ接続のようにメリットがあれば実装するだろうが、スマホを物理ポートで画面出力する需要がそこまで大きいモノではないのは個人的な実感としてもそうだし、Appleもそう考えてるだろう。
他国の企業が好き勝手商売するのが気に食わないから自国企業に利益誘導したい、というのを標準化を盾にやっているので、Appleも従わざるを得ない。
EUは2024年10月までに対応必須というのも絶妙な期限なのが面白い。
物理ポート廃止にはちょっと早すぎるが、一度物理ポート標準化を受け入れてしまうとなし崩し的にビジネスが変容していく。
今回Qi2の発表でiPhoneのUSB-C実装の噂に冷や水ぶっかけられたのは大きいだろう。
実際に物理ポートの標準化を突っぱねられるかどうかは正直微妙だと思ってるが、周りが盛り上がりすぎて逃げ道を塞がれるのはギリギリ防いだ感じだろう。
資源の無駄とか持続可能性がないとかいくらでもいちゃもんはつけられるけど
じゃあそれがアートなんですとか伝統工芸なんですとかいっても同じ調子で圧殺されちゃうのかなって思うわけ
うちの国、SDGｓ進めてるんでアーティストの染料とかもう作らないし売りません、みたいなね
あと、持続可能性って聞くと標準規格化みたいな話を連想しちゃってさ、凡人が天才を殺す文化の醸成に繋がりそうだよね
そんな飛躍してないと思うけどな、だってSDGｓってポリティカルなコレクトネスで踏み絵を迫られちゃ、大抵はムリでしょ
まあうわべだけ取り繕って、いえいえSDGｓを頑張りつつ新たな表現の模索を云々かんぬんって言えなくもないだろうけどさ
お前が直ちにこの世を去った方が環境にやさしいよねって違和感を胸に抱えながら、表向きは立派なことをしている風でずっとやっていかなきゃいけない
呪いですよこれは
なんかもう、最強のポリコレこん棒ができちゃったよね
どうすんのこれ
不要不急でなく、人類のためになることでないと存在を許されないよ
こわいねえ
現在、弥生では「事業コンシェルジュ」を標榜し、主要な顧客層である中小企業・個人事業主に対し、さまざまなサービスを提供する方針をとっている。その方向性には2つあり、1つは「業務支援サービス」として、会計ソフトの提供などを通じて業務効率の直接的な向上を支えようというアプローチ。そしてもう1つが、起業・開業から事業承継まで、中小企業のビジネスそのものを支援する「事業支援サービス」である。
「事業支援サービス」については、全国各地の会計事務所とも連携しながら、小規模事業者が必要とする支援策を用意。11月にもスタート予定の「資金調達ナビ」では、行政からの補助金といった方法も含めた資金調達手段が一括検索できるようにする。すでに3月には「起業・開業ナビ」を公開しているが、今後も12月には「税理士紹介ナビ」、2022年に「事業承継ナビ」を展開する計画だ。
「従来の弥生というと、事業者向けの業務ソフトを提供するところにだけフォーカスが当たりがちだったが、今は会計事務所向けの支援であったり、企業の事業そのものの支援にも取り組んでいるところをぜひご理解いただきたい。」（岡本氏）
そのうえで岡本氏は、企業活動を含めた社会的システム全体について「デジタル化」を目指すべき、との姿勢を改めて表明した。
ここで言う「デジタル化」とは、「電子化」とは異なる概念だ。戦後、コンピューターのない時代に支配的だったのは「紙文化」であり、その“紙”のやり取りを単純に電子データに置き換えたのが「電子化」。電子データを部分的に利用してはいるものの、業務のあり方は紙文化時代の発想とそれほど変わらない。
これに対して、電子データありきで業務を発想し、そのフローについてもゼロから見直すのが、岡本氏の主張する「デジタル化」だ。例えば行政の電子化は少しずつ進行しているものの、行政に対して書類などを提出する事業者側にとっては、それまで紙だけでよかったものが電子データもプラスして管理する必要が発生したりと、必ずしも業務効率化に直結するものではなかった。
電子化ではない「デジタル化」は、この5年で海外でも急速に進んだと岡本氏は指摘する。シンガポールとオーストラリアでは、2018～2019年にかけて電子インボイス規格「Peppol」が採用され、着実に普及が進んでいるという。
現状の日本におけるインボイスとは、2023年10月の制度スタートが予定されている「適格請求書等保存方式（インボイス制度）」がなんといっても想起される。企業間でやり取りされる請求書について、販売側（売り手側）が消費税の納税事業者であることを意味する、登録番号の記載等の要件が満たされなければ、仕入れ側（買い手側）はその金額を税額控除の対象にできないため、消費税の免税事業者を中心に大きな影響が出ると予想されている。
複雑な消費税計算を伴うインボイス制度を、紙の書類だけで運用するのは現実的ではない。会計ソフト等なんらかのコンピューター処理を介在させる必要があるとみられ、市中の多くの企業が対応を進めることになる。インボイス制度の施行は、あらゆる業務の「デジタル化」を目指す弥生にとって、それまでのビジネス慣習を根本的に見直すための好機……というわけだ。
とはいえ、事は弥生の1社だけで完結させられる規模のものではない。そこで2020年7月、「電子インボイス推進協議会（EIPA）」を立上げ、さまざまな立場の企業と連携しながら、標準規格の策定などを進めている。
EIPAではまず、請求業務のインボイス対応を滞りなく実現するための準備を優先。日本においてもPeppolの採用を訴えている。Peppolはヨーロッパ発祥の規格だが、前述のようにシンガポールやオーストラリアでも採用され、グローバルスダンダートとなる可能性が高い。また、EIPAの検証では、日本の商慣習にも対応できる柔軟性が備わっているという。
「電子インボイス推進協議会（EIPA）」では、Peppolの採用を訴えていく
ただ、最終的には、見積書の発行から発注書のやり取り、さらには請求金額と受取額の付き合わせ（消込）まで、企業間取引で必要なあらゆる業務を全てデジタル化・自動化するところまでを、電子インボイスで実現しようというのがEIPAの目標だ。
「全てをデータでやり取りするという考え方は、特段新しいものではなく、大企業を中心にここ20年で広がっているし、特定の業界内で閉じたかたちで使われている。これを中小企業でも、誰でも使えるようにするのがEIPAの目標だ。」（岡本氏）
「見積書の発行から発注書のやり取り、さらには請求金額と受取額の付き合わせ（消込）まで、企業間取引で必要なあらゆる業務を全てデジタル化」できている弊社は零細だからできることだったか。（自動化は半分しかできてないが）
GPGPUアプリケーション開発の環境およびAPIとしては、ハードウェア内部構造自体が汎用性を増したDirectX 10世代の統合型シェーダーアーキテクチャGPUの登場以降、NVIDIAによるGPGPU専用の統合開発環境「CUDA」や、AMDによるGPGPU基盤「AMD Stream」（旧称ATI Stream）、そしてクロノス・グループによる標準規格「OpenCL」が現われ、GPGPU活用の幅が広がりつつある。 https://ja.wikipedia.org/wiki/%E3%82%AF%E3%83%AD%E3%83%8E%E3%82%B9%E3%83%BB%E3%82%B0%E3%83%AB%E3%83%BC%E3%83%97
https://www.nikkei.com/article/DGXZQODF276MJ0X20C21A1000000
経団連の中西宏明会長は27日、連合の神津里季生会長とオンラインで会談し「日本の賃金水準がいつの間にか経済協力開発機構（OECD）の中で相当下位になっている」と語った。26日に開いた労使フォーラムによって2021年の春季労使交渉が始まり、連日で労使トップが意見を表明した。経団連は新型コロナウイルスの影響で一律の賃上げ方針は見送ったが、業績の堅調な企業には積極的な対応を求める。
徒に日本アゲをしたい訳ではないが、日本のGDPは先進国の中で〜位とか、こういう上のようなニュースを見ているとモヤっとするところがある。
日本の給与水準や物価が海外諸国と比べて安くなっているのは事実なのだが、実際にヨーロッパなどに旅行してみるとお世辞にも日本より治安が良いわけでもないしインフラや生活が快適なわけでもない。むしろ日本での暮らしが諸外国と比べても快適なのもまた事実だと思う。日本の給与や物価が低く抑えられているのは、為替の要因も大きいだろう。それはつまりここ30年くらい経済成長をして来られなかったツケでもある。
今から20年も前に東南アジアの発展途上国に行くと、物価が日本の1/3以下で小銭で豪遊できたのを思い出すが、一方でいまたとえばオーストラリアなどに旅行すると日本より物価が何倍も高いので目を剥くことになる。経済成長著しい諸外国から見て、今の日本の立場はむしろ20年前の東南アジアのように映るのだろう。しかし、インフラのまだまだ貧弱だった昔の東南アジアと、一度は世界一まで迫る経済発展をし今でも曲がりなりにも高い工業力を維持している日本とを同列に見ることには少し無理がある。良かった時代の残照とはいえ、日本がいまだにいくつかの分野で競争力をもった快適なハイテク国家であるのも事実だ。日本は一回りして今の位置にいるのだ。
思うのは、実はこうしたGDPや給与水準といった単一の経済貨幣による社会の豊かさの比較というのが、日本のような一回りして独自のポジションを築き上げた老成国家に対する物差しとして機能していないのではないかということ。だいたい世界の経済や教育の水準を測るスタンダードはイギリスのような標準規格作成大好き国家が自分たちが知っている範囲の狭いクオリアの中から作り出したもので、残念ながら日本をはじめ後発のアジア国家はそういったスタンダードに唯々諾々と甘んじている現状がある。
日本がもう一度世界の中で強いリーダーシップを示したいのなら、DVDなどの工業規格でそうしたように、日本の本当の良さを正当に評価できる新しい指標を提唱してそれを元にランキングを発表してみるべきだと思う。そういう新しい価値の提案というのも、日本のような老成国家の世界に対する責任の一つだろう。
情報処理技術者試験なんて、実務、特にマネジメントなんかやっていると役に立つことが多いです。
まず前提の捉え方がちょっと違いますが、「情報処理技術者試験」とは国家試験でありながら、医師国家試験や危険物取扱者試験などの国家試験とは異なり、
別に持ってなくても実務に従事できるって言う不思議な国家試験であること。
なので、別にこの試験がなくても、情報処理技術者としての仕事にまったく支障はないです。
情報処理技術者試験は、ちゃんと情報処理のこと勉強してますよ！ある程度の知識は修めてますよ！って言うためのものでしょう。
名刺に資格もってるよマーク載せてIT系なら任せてよアピールをするためのものでしょう。
またこの資格を持っていることで、ちゃんと勉強している人間なのか、その指標にもなるのでマネジメントの一助になるです。
ご指摘の通り、暗記問題ばかりで実際の業務には何ら役に立たないように思えますが、
一方で実務以外のコンピュータ技術の本質的な設問であったり、法務関係の問題もあったりして、
マネジメントの他、教える立場になったときや、企画開発なんかで広く浅い知識が必要になったときには役に立つかと。
そもそも逆なんですよね。この問題を解けたら良い設計ができる、とか、優れたコーディングができるんじゃなくて、
まともな設計知識を持っていたら、このくらいの問題は知っていますよね？ってのが技術者試験の一面です。
※あと、「コードが書けるわけでも、良い設計ができるわけでもありません。」って否定をするなら、せめて応用のほうから持ってきてくれないと･･･ｗ
ちなみに、UMLの基本や、開発手法、MPEGなどの標準規格の名称なんかを覚えるのは、設計やコーディングにおいて「超大事」なことです。
そうした名称をもとにして開発を進めていくわけで、いちいち「要求分析から実装までの開発プロセスを繰り返しながら、
システムを構築していくソフトウェア開発手法」でやります！みたいな説明しなくても「今回はスパイラルでーす」って一言で終わるじゃないですか。
基本情報技術者試験レベルをメンバー全員が資格取得してくれていれば、「スパイラルでーす」で終われるってすばらしい。
合格率は基本情報技術者試験で３割弱、応用情報技術者試験で２割強となっています。
なので、一見難しそうに思えますが、非常に簡単です。覚えればいいんですから。
（そもそも基本情報なんて、非IT系会社勤務の方の合格率が、IT系会社勤務の方の合格率を超えているという･･･）
なのに合格率が低いのは、みんな真面目に勉強（暗記）していないからと思われます。
試験会場にいくと分かるのですが、まずスタート時点で１割強は机の空きがあります。とりあえず申し込んでいるだけなんでしょう。
会社によっては予算取ったから行って来いよ、みたいなところもあるのでしょう。
暗記試験で引っ掛け問題も少なく、広く浅い問題範囲なので、１～２か月真面目にやればだれでも取得できますよ。
ただ、さすがに150分座ってるだけで取れるような試験ではないことは確かです。
範囲は広いですし、勉強してなきゃ聞いたことがない言葉なんてザラです。
上記を言い換えれば、真面目にコツコツ勉強してくるやつアピールが出来ます。
合格率２割の国家試験を、通常業務をこなしながら取得してくるだと･･･！？化け物か！ みたいな
雰囲気でとらえてくれるおじさんは、まだまだいっぱいいますよ。
| 時間 | 記事数 | 文字数 | 文字数平均 | 文字数中央値 |
|---|---|---|---|---|
| 00 | 67 | 13646 | 203.7 | 60 |
| 01 | 57 | 8080 | 141.8 | 56 |
| 02 | 29 | 4017 | 138.5 | 37 |
| 03 | 63 | 4050 | 64.3 | 19 |
| 04 | 57 | 4157 | 72.9 | 45 |
| 05 | 38 | 2467 | 64.9 | 37.5 |
| 06 | 59 | 5663 | 96.0 | 43 |
| 07 | 101 | 8952 | 88.6 | 52 |
| 08 | 115 | 9934 | 86.4 | 36 |
| 09 | 131 | 17370 | 132.6 | 43 |
| 10 | 110 | 10915 | 99.2 | 62 |
| 11 | 122 | 15866 | 130.0 | 46.5 |
| 12 | 171 | 13705 | 80.1 | 42 |
| 13 | 195 | 15043 | 77.1 | 44 |
| 14 | 137 | 22796 | 166.4 | 79 |
| 15 | 160 | 11617 | 72.6 | 37.5 |
| 16 | 184 | 12413 | 67.5 | 41 |
| 17 | 175 | 14905 | 85.2 | 37 |
| 18 | 152 | 11820 | 77.8 | 35.5 |
| 19 | 158 | 16994 | 107.6 | 36 |
| 20 | 129 | 13702 | 106.2 | 46 |
| 21 | 120 | 8060 | 67.2 | 30 |
| 22 | 110 | 9915 | 90.1 | 35.5 |
| 23 | 107 | 7845 | 73.3 | 35 |
| 1日 | 2747 | 263932 | 96.1 | 42 |
ヘテロラブ(6), お茶子(5), FORTRAN(4), 検察庁法改正案(4), ブルースリー(4), ４０年(5), ２０日(3), ピーコ(3), ジェネレーター(5), HL(9), ロマンスカー(3), １０倍(3), スクール(37), プログラマ(50), プログラマー(54), プログラミング(68), 賭け(19), アジア人(17), 専門学校(12), アルゴリズム(11), 金髪(11), コード(41), Web(25), 白人(31), エンジニア(45), ファイル(12), 職種(11), 滅(8), テレワーク(18), プログラム(20), IT(27), 借金(18), 職業(21), 正社員(15), 分野(15)
■プログラマーって選民感情持ってる人多くない？ /20200521200340(35), ■プログラミングを生業としてる人って /20200521175300(28), ■どうして未経験者はそんなにWebエンジニアにこだわるんだい？◕‿‿◕ /20200522005004(14), ■専門学校卒はどこに消えてるのか /20200522133643(10), ■借金ありおたく女、結婚する /20200522180754(10), ■俺が政権をとったら絶対にやる10のマニフェスト /20200522202451(10), ■いまだに自民党以外を支持する気になれない /20200522162237(9), ■景気回復してくれ /20200522200945(9), ■アニメキャラ白人説とレイシズム /20200522093502(9), ■2階に住んでて下が床屋なんだけど /20200522114020(8), ■はてなブックマークを象徴するブクマカ 追記追加あり /20200522001329(8), ■ /20200521094511(7), ■高峯のあは一生声がつかなそう /20200522060629(7), ■Chrome と FireFox のタブクローズボタンの位置が標準規格を無視している /20200522072657(7), ■先輩が異動させられるかと思ったけど多分コロナのどさくさで無かったことになった /20200522130445(7), ■【追記アリ】今日も寿司屋に行くぞお！🍣 /20200522164640(6), ■東大生だけど、高校一年生の数学の問題がわからない /20200522180132(6), ■anond：20200521094511 /20200522151133(6), ■増田って個人プレーばかりだよね /20200522194409(6), ■みんなで一斉にアンマウントするのはどうか /20200521181610(6), ■MTを選んだ己を呪っている。 /20200521144628(6), ■旦那のやることなすこと全てにイライラする /20200522203320(6)
真面目に回答したら良いのかな？
おそらくは日本でネット投票がまともに解禁されるようになるには、インターネットで使われる情報技術の標準規格を選定するW3Cが定めたSelf-Sovereign Identity(SSI)というポリシーに則ったDecentralized Identifiers(DID/DIDs)が日本でまともに運用されてからだと思われる。
Self-Sovereign Identityとは訳すと自己主権型アイデンティティで、これは技術の規格というよりも技術を開発・運用するためのポリシーなんだ。
詳しくすると論文が書けてしまうので要約するけどSSIでは以下の10項目が提言されている。
これらの10項目はまだ上手い日本語訳が無くて俺の意訳が含まれていることに注意してもらいたい。
このSSIが何を言いたいかといえば個人情報の公開を第三者ではなく個人自身が管理・制御できるべきということなんだ。
SSIを定めたW3Cはそのポリシーに則って個人情報を管理するためのシステムの仕様を定めた。
それがDecentralized Identifiers(DID/DIDs)で、これも訳すと非中央集権型識別子ということになる。
何のことだが小難しい漢字語になってしまったので、より現代人へ理解しやすく平易な言葉へ置き換えると分散型デジタルIDと表現したほうが理解しやすいと思う。
現在、個人情報(アイデンティティ)というものは中央官庁や巨大企業によって中央集権的に管理されてしまっている。
これでは個人情報の本来の持ち主である個人が自由に利用することが難しいし、そして自身の個人情報がどのように扱われているのかというのを把握するのが非常に難しくなってしまっているよね。
更には中央官庁や企業としても日本国法で言うところの個人情報保護法の兼ね合いで個人情報管理に関して大きなコストを支払わざる得なくなっており、もし仮に個人情報が流出した際に賠償責任などのリスクを負う可能性があるのが現状だ。
そこでW3CはSSIポリシーに則ったDIDという仕様を定め、これまで問題視されてきた個人情報管理の問題点を解消しようと近年動き出している。
DDIはブロックチェーンにより分散的に個人情報を管理しつつ改竄を防ぐ仕様が取られている。
更に特徴的なのは個人が個人の意思によって個人情報請求に対して公開したい範囲の個人情報のみを開示できる仕様になっているんだ。
これはどういうことかと言えば、現在の日本ではタバコや酒類を購入することに関して成人であることが条件になっていて、成人認証には運転免許証やマイナンバーカードなど公的機関が発行する資格・証明証が用いられている。
この問題点はタバコや酒類を購入する際に必要な個人情報は「成人である」という証明だけのはずなのに、例えば運転免許証であれば氏名や現住所、許諾されている運転車両の範囲など余計な個人情報も記載されてしまっていることが問題なんだよね。
しかし、DIDを用いるとタバコや酒類の購入者が開示する情報は「成人である」ということができるようになる。氏名も生年月日も現住所も許諾されている運転車両の範囲も開示する必要がないんだ。
これは中央官庁や企業に取っても非常に安心な仕様だ。何故ならもし誤って個人情報を流出させてしまっても流出するのは誰のものだか判然としない「成人である」という情報のみだから。
他にも携帯電話通信契約などの場合でも本人確認や法的に契約できる者なのかを確認しなければ契約の締結はできないけれど、DIDを用いると開示する情報は「本人である」というものだけになる。
契約業務をする目の前のスタッフはアナタがどこの誰だか全くわからないけれど、アナタが本人であることを知ることができる。こういうことを可能とするのがDIDというシステムなんだ。
ポイントカードやクレジットカードもDIDと紐付けば何枚も持ち歩く必要なんてなくなる。
そして選挙は本人であることや、投票できる年齢であるかどうかを確認したり、投票の秘密を守らなければならない。更に言えば投票の集計もしなければならないよね。
DIDは中央集権に寄ることなくアナタが本人であり投票できる者であることをアナタの許諾を得て承認し、投票の秘密を守り、更にはコンピュータだから超高速に投票集計もしてくれるんだ。
SSIの透明ポリシーによって投票集計のプログラミングコード・アルゴリズムもオープンに公開され公正に選挙が行われる。
これが最も先進的な個人情報管理のために提言されている新しい技術だ。
SSIとDIDが日本でまともに運用開始されるとネット選挙の未来はそう遠くなくなるよ。
法律違反とかどうかわわからんけど、社内規定が守れてないとか心当たりがありすぎる。
最近、コンプライアンスだか標準化？、国際的な安全要求の高まりとかいろいろルールできすぎ。
ちょっとなんかするとすぐ文書つくれ、エビデンス残せ、承認して組織として責任持つ形にしろ、前工程の文書承認降りてから作業しろ
とかそんなのばっか。
承認する人出張いっちゃって中々承認おりないし、ぶっちゃけ日付操作してハンコ押してくださいって頼むことが多い。
工程逆転もしょっちゅう。だってあり得ないタイミングで仕様変更入るし。
知らんがな。下請法はどうなってるんだろう。こんなタイミングの仕様変更受け付けなければいいのに。
本来作るべきタイミングで文書作れてなくて、後づけて体裁整えるために文書作るとかよくあるわ。
いろいろ社内規定が守れてないことに心当たりがあるんだけど、
http://itpro.nikkeibp.co.jp/atcl/column/14/346926/101101158/
Q1.役所の仕事なんて全国でほぼ一緒なのに、なんで自治体ごとに別のシステムを作るの？
A1.地方自治体の事務や財務について法律で決まっているのは大枠だけだよ。
それを実務≒内部規定に落とし込むのは各役所ごとなので大枠は似てても実務プロセスは全然各役所で違うよ。例えば同じ業務でも独自の語彙があったり、下手すると同じ語で市町村ごとに意味が違ったりするよ。
Q2.なんで新規で作らないの？
A2.80年代ぐらいにやったよ。その結果が政令市クラスに残ってて今回京都市が更新しようとしてるような、メインフレーム上のシステムだよ。
A3.みんなが使ってるWindowsとかLinuxとかのOSがなかった時代のコンピュータだよ。IBMとかがベンダーごとに作っていてOSもベンダー謹製だよ。性能はいいけどメチャ高いよ。
システム内でクローズして専用線以外では他とつながってなかったから、汎用機からPCサーバへの移行を「オープン化」と言うよ。
オープンソースソフトウェアとは全然関係ないよ。
Q3.使いまわしってどうやってやるの？
A3.80年代とかに作ったシステムで動いてるCOBOLとかPL/IとかをLinuxとかUnixとかWindows上で動く言語にコンバートしてリコンパイルするよ。
DBのデータも階層型データモデルからリレーショナルDB用にコンバートして移行するよ。こういう開発形態を「マイグレーション」と呼ぶよ。
あと、バッチジョブ制御もJCLという汎用機用の言語で動いているよ。これもそのままでは動かないのでコンバートするよ。
コンバート先はperlだったり、シェルスクリプトだったり、ベンダごとの独自スクリプトだったりするよ。
COBOLとかの実行プログラム移行も大変だけど、帳票の大量印刷はたいていバッチジョブでこなしてるので、JCLの移行もめちゃ厄介で大抵もめるよ。
Q4.80年代のものを使いまわすとか。新規で作ればいいじゃん
A4.お金が無限にあればできるよ。今の時代にお金があった時代のシステムをフルスクラッチで再開発するととんでもない予算になって市役所内の決裁が通らないよ。
しかも汎用機時代の納品は割といいかげんだったのか、仕様書が残ってなかったりするから、費用はさらにかさむよ。
Q5.そんなんでよく運用できてたな
A5.当時はSEが汎用機の付属品みたいについてって、困ったらオペレーターとして介入して動かしていたみたいだよ。
そうやって現場感覚バリバリでやっているので、オペレーターしか知らないプロセスがあったりするよ。
マイグレーション開発では総合テスト中にそういう隠しプロセスが「発見」されたりするよ。こわいね。
上記の通り仕様書がないことも多いうえ、システム課に限らず市役所の人員は基本ローテーションするよ。
導入当初の担当者が残っていることは珍しいし、30年も前に導入した汎用機のことなんてここ10年に入った職員にはわからないよ。
Q7.なんで入札にしたの？ 現行ベンダに指名してやらせたほうが良くない？
A7.金額がでかいから、たぶんどこの市役所でも入札案件だよ。
随意契約（随契）は無理だし、入札業者を発注者が指定する指名競争入札は談合の温床になってたから最近はあんまりやらないよ。
（裏技としてRFPを指名したいベンダーに書かせて公募型指名入札にしたり、RFPの段階でハードを全部特定ベンダで型番まで指定するというのがあるけど、公になると多分問題になるよ。こわいね）
Q8.じゃあ役所は悪くないの？
Q8.悪いよ。
入札案件はRFPで書かれた各項目をどれだけ満たすかの技術点と、価格点で決まるよ。点が高ければだいたい自動的にそのベンダーに決まるよ。
なので、技術点の項目に現行システムの調査にかかる項目を入れるとかして、現行機の開発・保守ベンダが高得点を取れるようにしておけば価格勝負してくるベンダーをはじけた可能性はあるよ。
もちろん現行の会社に嫌われて逃げられたとか、役所が現行の会社をめっちゃ嫌いになって声をかけなかったとかもあるかもしれないけれど、可能性は低いと思うよ。
A9.ここまで述べたようにこの手のマイグレーションは火薬庫だよ。火を噴いても爆発しなければラッキーぐらいなので、強いて言うなら入札したことが悪いよ。
A10.前にマイグレーションをやったことがあるSEだよ。もうやりたくないよ。今は転職してSIerじゃなくなったからやらなくてよくなったよ。うれしいね。
しょぼいSEだからここに書いたことは個人の体験に基づく参照情報だよ。一般的じゃないことを言ってたり、間違ってたら教えてもらえると助かるよ。
(2017.10.13 追記）
Q3がかぶっていたよ。恥ずかしくてなきそうだけどブコメに番号で言及してくれている人がいるから忍んでそのままにするよ。
あと、「オープン化」の定義が違くない？という指摘があったよ。確かに増田が間違っていたので、記事の主旨から外れるけど補記するよ。
メインフレームは本文で述べたようにOSからハードまでメーカー謹製なので独自仕様のカタマリだよ。
これに対しPCサーバは標準規格で作られているよ。こういう標準規格に基づくサーバをオープン系と呼ぶよ。
独自規格でクローズしたコンピュータから、そうでないオープン系に移行するからオープン化なのであって、専用線とかは関係なかったよ。半可通な知識で語ってしまったよ、ごめんね。
京都市で火中にいるシステムズさんのサイトの解説がこの増田よりも分かりやすくて正確だから気になる人は見てほしいよ
http://www.migration.jp/column/column01.html
完全に余談だけどオープン系のx86サーバに移行しても、システムはそんなにオープンにならなかったりするよ。
H系に頼むとDBが拝承DBになったり、Fに頼むとシステム管理が全部SystemWalkerになったり、要するにベンダ独自のミドルに入ってがっつりロックインされたりするよ。
はてなブックマーク - 経産相「いきなり電気自動車にいけるわけでもない」 | NHKニュース
まともなブコメまとめていくが、これ否定できるならやってみろよ。
どうせ経産省批判する流れが出来てからなんとなく乗っかかって物言ってるだけの思考停止したバカはてな民。
gokkie 30kWhリーフ買って一月半で2500km乗ったけど、今のトコ不満はない。先行者特権でフリーライダーになれるのは限られた期間やろし、格安で買った車でガンガンフリーライドしまくるで
600以上ブクマついてるのに実際に電気自動車を買って乗る人が二人しかいないはてな民ｗｗｗｗ
fusionstar 欧州の EV 推進は原子力発電前提なんだけど乗っかっていいのかなあ
u-chan ただの腰巾着かと思ったら、まともなこと言ってる。これで「電気自動車ダー!!」なんて言ったら、後、新設の原発何基作る気なんだ？？ だしね
raitu 短い航続距離(最大でも600km)および長い充電時間(40分)をすぐどうにか出来るわけでもないから、そんなに変なことは言ってない
mur2 いきなり電気自動車にしろという人はリチウムやネオジムを筆頭とした大量のレアメタルをどうやって安定的に調達する気なんだろうか。エンジン関連パーツ、燃料系統を作ってる下請けも死ぬぞ。
otihateten3510 英仏中がやってるのはあくまで政治だと思う。技術置き去りの政治に良い印象はない。支援はわかるが規制に便乗するのはおかしいだろ？ どちみちメーカーは対応しなきゃならないわけで、経産省の立場はこれでいい
Earth_f1 EVに関して過度に期待しすぎるのもどうかと思う。HV/PHEV/水素/にだってモーターとバッテリーの技術はあるわけだし悲観しすぎでしょ。あとガラパゴスで言ってる人は日本メーカーの海外売上比率を見てみてはどうですか？
ukidousan LNG以外の火力発電所を潰すまではHV優位かなあ https://headlines.yahoo.co.jp/hl?a=20170913-00010007-msportcom-moto
moegi_yg トヨタが水素押し、EVにしなきゃ乗り遅れる、ガラパゴス、云々全部的外れ。中印蘭以外はHV, PHVも可、電動化の肝はバッテリー。日系はそこは進んでるし、スバル/マツダですらロードマップに数年後に導入
Dicer あれ？トヨタもEV用の高性能電池を開発中じゃなかったの？？→ http://jp.techcrunch.com/2017/07/26/20170725toyotas-new-solid-state-battery-could-make-its-way-to-cars-by-2020/
poko_pen インフラ整備が不要なプリウスなどHVが20年掛けてやっとシェア30%(世界ではもっと低い)。充電スポットや新規発電所建設などインフラ整備が必要不可欠な電気自動車がどれだけハードル高いか理解して欲しい
dannier インドフランスはEV縛り宣言したけど、ドイツは同じ問題抱えてるから実はEV宣言はしてないんだよね。まあ研究開発と充電設備に巨額の投資はしてるけど。あと中国もいつ急に降りるかわからん、という感じなのだろ
ryokujya 日産のノートeパワーを見ましょう。リーフを出した日産がエンジンを発電に使うノートを出した意味を。今はハイブリッドが適している
もちろん私だって別にEVを否定してるわけじゃないぜ。政治的にもアドバンテージを取らないといけない部分があるのはその通りです。
インフラ整備や普及のための補助金、標準規格競争など、適切なタイミングを見て国が参加する必要はあります。はてブもそのあたりわかってる人をちゃんとフォローしたいですわ。
awkad いかにも日本だ。作る側が神と思ってる。決めるのは需要側なんだよ。中国とアメリカがEVだっていったらEVだ。日本は需要で負けてるんだから決定権なんてない
mamezou_plus2 充電スタンド規格「CHAdeMO」と別規格を欧米に作られ日本外し。EVが普及すると充電負荷が高すぎるのでスマート電力のシステムとかサービスとか。内燃車とは特性が違うから交通などデザインし直さなきゃいけない
giyo381 電気自動車の時代って言ってる人の中でwell to wheel知ってる人どんくらいいんだろ。石油が連産品とか、発電効率とか知ってるのかしら
石谷久（東京大学教授）による「Well to Wheel」でのＣＯ2排出量（ 2005 ）/ ガソリン車：193 / ガソリンハイブリッド車：123 / 燃料電池自動車：86 / 電池電気自動車：47 / https://blogs.yahoo.co.jp/zaqwsx_29/18278184.html
お前らみたいなアホが、燃料電池の時も同じことを言ってて、
燃料電池がだめになったらその時応援してたことも忘れて手のひらクルーするわけよ。
おまえらどうせEVについても、EVにさっさと乗ろうとしない政府は無能とか言っておきながら、
いざ上手く行かなかったら、「誰だよEVに一足飛びに行こうとしたやつは」とかいい出すわけよ。
２０４０年になった時、さすがにお前らもはてなをやってないとは思うが、
このブックマークページのコメントは保存しておいて「ほーら２０年前にこういうバカなことを言ってる人たちがいたんだよ」って晒してやるから覚悟しとけよ。
まあそれなりの人が参加してればそれなりと言えるかもしれない。構成員わからないけど。
https://www.itu.int/md/T17-SG16-170116-TD-WP2-0024/en
慶応大川森氏によるQ28/16のプレゼンテーション。(イラストやが世界進出してる)
http://www.ttc.or.jp/files/3213/5884/2008/TTCniyosete_kawamori_2013_01_Vol.27_No.4-3.pdf
医学的に十分信頼できる話かどうかは、判定できない。意識低い工学系の研究者だからね。
ホッテントリメーカーで作るような煽りタイトルって、みなさんもう見飽きてると思うんですよね。
今調べたらホッテントリメーカー2008年だそうで。どうりでねー。古臭いなーと思いましたよー。
「一から学ぶJava」ってのをね、1.0にするだけでこんなに素敵なタイトルになるんだから面白いですねー。
タイトルを思いついただけだったんですけど、思いついたらやっぱりちゃんと中身も書かないと行けないじゃないですか。やだー
面倒くさいんですけどね。ちょっと1.0から学んでみましょうか。
Javaの1.0がリリースされたのは1996年1月23日ですね。発表されたのが1995年5月23日でJavaの誕生日といった場合にどちらを取るかで揉めることがあります。
かれこれ20年前なわけで、当時のパソコンというとハードウェアはCPU が Pentium 133MHz メモリ16M とかそんな感じだったかなあ。今どきの携帯電話の例としてiPhone 6sを挙げるとCPUが1.85GHz メモリ 2G ってんだから凄いですね。OSは1995年11月23日にリリースされたWindows95とかそんな時代背景です。インターネットがようやく一般に普及し始めたところでしょうか。
今から思うと相当弱いハードウェアですけども、そろそろVM方式を採用しても良さそうな、そんな時代でした。インタープリタだと流石に遅い、でもC言語のようなコンパイル言語だと"Write once, run anywhere"とはいかない、という判断もあったのだろうと思います。Javaが純粋なオブジェクト指向言語ではなくintなどのプリミティブ型を持つというのは、当時のマシンスペックを考えた場合、ある程度妥当な判断だったと言えるでしょう。これが後々苦しくなってくるわけなのですが。
Javaを作った会社はSun Microsystems(サン・マイクロシステムズ)というアメリカの会社で、2010年1月27日にオラクルにより吸収合併され今はありません。SolarisというOSとSPARCプロセッサでUNIXサーバーの販売で90年代後半までは一人勝ちのような状況だったと聞きます。当時にすでに「ネットワークこそがコンピュータ」（The Network is the Computer）というモットーを掲げてたんだからおかしい。1996年リリースのJavaが標準でネットワーク機能を備えていたのもこのあたりの思想から来ているのかもしれませんね。
当時のプログラミング言語としてC++が挙げられますが、C++でのプログラマへの負担といいますか、ヒューマンエラーの起きやすさといいますか、その辺を改善する目的で開発されたのがJavaだったわけです。
1996年の時点にこんな言語が登場したのですから革新的でした。
いろんな企業がJavaに賛同します。その中にはMicrosoftもありました。この時期、Microsoftは次期のWindows開発用のプラットフォームにJavaを据えようと考えていました。その後、袂を分かつことになるのですが……。
プログラム言語として構文などを見ると、C++を強く意識した構文なのは間違いなく、しかしポインタ演算を廃してポインタを機能を限定した「参照」に置き換えるなど簡素化が多く見られます。C++からはいろんな機能が削られています。関数ポインタ、構造体、演算子オーバーロード、テンプレート((テンプレートについては実装が間に合わなかったという話を聞きます))などなど。そのためC++の劣化であるように揶揄する人もいますが、こうしたものを捨てて言語仕様を比較的小さくシンプルに抑えた点は評価に値すると思います。しかし、今でもこうした削減された機能を愛する人からはJavaを腐す要素として挙げられてしまうのでした。
Wikipediaからピックアップすると1.1での大きな機能追加は
といったところです。当初よりJavaの内部文字コードはUnicodeで文字を表すchar型は16bitで設計されていました。Unicodeは当時それほど普及しておらず、Unicode対応のテキストエディタさえ少なかったと記憶しています。時代を先取りしていると言えますが、大きな誤算はUnicodeが当初16bitのコードポイントに世界のあらゆる文字を格納しようとしていたことで、漢字圏の我々からすると16bit=65,536程度の空間に文字が全部入るわけないだろ！というものだったが故に早々に破綻し、Unicodeは21bitのコードポイントに拡張されることになるのです。これはまた後の話。
なんにせよ、日本語が対応されたのは1.1からで、日本でのJavaの採用が始まったのはこの頃からと言えましょう。
当時のJavaのGUIはAWTというものでしたが、これを用いたGUIの開発は当時は結構行われていたイメージですね。Visual BASIC でGUIを作るプロダクトも結構あったと思います。GUIのためのオブジェクト指向言語としてJavaが使われていたイメージがありますね。JavaBeansもそのための仕様でした。件のsetter/getterの話題に繋がっていくのですが。
JDBCはJavaとデータベースをつなぐインターフェースです。RMIではあるJava VMから別のJava VMにオブジェクトを送って実行する、といったことができます。こうした機能が用意されたことで、ソフトウェアのフロントとしてのGUI、裏方の実装のためのネットワーク機能、データベース機能、さらにはソフトウェアを配布するためのJava Appletという布陣でJavaでのソフトウェア開発が加速していた時代といえます。
Microsoft Visual J++ もこの時代ですよ。
Java 1.1以降のバージョンのものは互換性確認のためにOracle Java Archiveからダウンロードすることができ、今でも入手することができます。もちろん、Java7ですら2015年4月にEOL(End of Life,サポート終了)となっているので、通常利用するのはJava8としてください(本稿執筆時点)。
当時のドキュメントを見るのも一興です。現在と比べると標準APIがかなり小さい。なお、当時のjavadocは今とはデザインが大きく異なります。
この時代であれば、全パッケージを舐めて標準APIを学ぶこともそう難しくはありませんでした。この時代から触っている人間は新バージョンが出るたびに増えるAPIを順に学んでいけたのです。しかし、現代にJavaを学ぶ場合、どのバージョンでは何があって……というのをいちいち学ぶ必要はほぼありません。Java5以前は一緒くたでいいと思いますし、一部のAPIで歴史的経緯があってねーというのを知っていればおそらく十分ではないでしょうか。
strictfpキーワードは浮動小数点演算をやる人は覚えておきましょう。JavaはパフォーマンスのためにCPUの浮動小数点演算を扱うことが許されており、そのため実行するCPUによって精度が異なることがあるんですね。まあ今時のCPUだと大丈夫だとは思うんですが。
リフレクション機能ではJavaのクラスを抽象的に扱うことができます。設定ファイルに書かれたクラス名のclassをロードして実行する……みたいなことができるんですね。フレームワーク的なものを作る場合には多用することになります。
1.2からは新しいGUIのSwingが採用されました。AWTがOSごとのGUIパーツを用いていたためデザインに違いがあったのに対し、Swingでは統一的なルック・アンド・フィールが用いられるようになりました。まぁ今ならJavaFXを使うのが良いと思います。
初期のJavaはやはりVM方式の実行速度の遅さが指摘されていました。実行時の構文解析を伴わないだけインタープリタよりは早いものの、実行バイナリを作るC/C++よりは遅い、そうした評価です。ここではサン・マイクロシステムズのVMにJIT(ジャストインタイムコンパイラ)が乗ったことが挙げられていますが、JIT自体は別の会社が先駆けて開発していたことは記しておきたいと思います。
JITコンパイラは実行時にJavaのバイトコードを環境のネイティブコードにコンパイルして動かす技術です。この後、JITコンパイラ、動的再コンパイル技術、世代別ガベージコレクションを備えたHotspotといった様にJavaVMは進化していきます。現代では実行時の最適化が進み、大きなスケールで見た場合、Javaの実行速度はC/C++での実装と比べてそれほど遅れるものではありません。遅くても倍の時間は掛からない程度といったところでしょうか。
あとは特記すべきはコレクションフレームワークです。皆が多用しているであろうjava.util.Listやjava.util.Mapといったライブラリが整備されたのがこの時なのです。それ以前はjava.util.Vectorやjava.util.Hachtableというクラスが可変長配列の機能を一手に担っていました。今ではVectorやHashtableは使うべきではありません。
Java の開発はSun Microsystems が主導していたけども、すべてがSunのものだったというわけでもなく。Javaには多くの会社が出資していてその中のひとつがMicrosoftだったわけですね。
Microsoft の Visual J++ では delegate とか独自機能拡張もありましたけど、裁判で問題になったのは J++ でコンパイルしたclassファイルはMicrosoftのVMでしか動かないという部分ですね(他社製のVMで動くclassファイルを作ることもできる)。classファイルがどこのVMでも動くの大事だろ、"Write once, run anywhere"だろ、お前何してくれてんの！と喧嘩になったわけです。当時のMicrosoftはブラウザまわりでも独自拡張がやりたい放題、標準規格？なにそれ美味しいの？みたいなスタンスをあちこちで見せていたものです。
結局、この事件でMicrosoftのJavaはバージョン1.1相当でストップ。好き勝手にやれないなら独自に言語作るわーとばかりに.NET フレームワークと C# といった方向に舵を取ります。
JavaがPC上でのUI開発の主力になろうとした勢いはここで潰えます。
Java SE とは別にこの時代に Java EEがリリースされていることは特記しておきたいですね。これ以後、それまでのCGIに取って代わって、JavaはWebサービスの開発のプラットフォームとして多用されるようになります。
2000年あたりからはJavaはGUI開発というよりは、Webサービスの開発が主流という流れになっていきます。インターネットのサービスが非常に発達していった時代、背後ではとてつもない量のJavaのプログラムが支えていたわけです。ただまあ、こうした産業利用は一般的なユーザーの目にはあまり入らないわけです。一般人からすればJavaといえばJava Appletみたいなイメージはずっと残っていたでしょうが、実体としてはJavaといえばServletという時代になっていたわけです。
企業で用いられる社内システムにもServletは多く採用されました。
理由はいろいろ挙げれると思うのですが
というのが大きな理由だろうと思います。JSPというテンプレートエンジンを用いてHTMLを整形してWebページを作り出す、というアーキテクチャはある意味では便利で簡単でした。
もっともHTMLの表現力に足を引きずられるため、GUIの機能性という点では後退したわけなのですが。それでもメリットが大きいと判断されたのでしょう。というか、まともにGUIを組めるプログラマがほとんどいないから、GUIのシステム開発がなかなか成功しないってのもあったんでしょうけどね。
2000年あたりというと携帯電話の普及も取り上げなければなりません。現代のスマホ、ガラケーに比べれば非常に機能は貧弱で、まさに携帯「電話」でした。要するに電話とメールぐらいしかできなかったんですね。
そこにdocomoのiアプリ、Jフォン(ボーダフォンを経て現ソフトバンク)のJavaアプリ、auのEZアプリという携帯電話上でちょっとしたアプリが動くよ！というのが乗るようになってきたんです。これがJavaを組込み用途にコンパクトにしたJava MEというものが土台となっていて(正確にはiアプリはちょっと違う)Servletと並ぶJava言語の大きなもうひとつの領域となっていました。
iアプリは当初は容量が10k byteまでといった制約があり、容量制限が非常に厳しかったのですが、新機種が出るたびに容量は緩和されていきました。
docomoはiアプリ含めiモードによって一世を風靡します。こうした土台を作ると、その上で商売をしたい人がたくさんやってきて、勝手にコンテンツを作ってくれる。docomoはそれらから手数料を取るので労せずして大金を稼げるというわけです。賭場の胴元というわけです。
この賭場が、将来にAppleのiPhone, GoogleのAndroidに荒らされることになります。docomoがなかなかiPhoneを出さなかったのもiモードという自前の賭場を失うことを良しとしなかったためです。金づるを失ったdocomoはSamsungと組んで独自の携帯向けOSであるTizenの開発に乗り出します。そんなTizenですが鳴かず飛ばず。噂ではインドあたりではリリースされたとか、なんとか。
話を2001年に戻しましょう。
Microsoft離反でGUIのプラットフォームとしてのJavaというものは存在感を弱めていました。この分野の復権に寄与したのはJava 1.4 (2002年2月6日)で導入されたJava Web Startです。
Java Appletがブラウザ埋め込みで動作したのに対し、Java Web Startではブラウザから起動しつつも独立したアプリとして起動するのです。
Webシステムが企業の社内システムに採用された話は先に述べたとおりですが、やはりWebシステムのGUIというのはHTMLに引きずられて貧弱だったんですね。
端的に言えば入力値が数字かどうか？みたいなチェックがなかなか難しい。HTML上でJavaScriptでやるわけなんですが、なかなか気持よく入力できるような感じにはならなかったんですね。
また、Ajaxによるブラウザのページ遷移を伴わない通信というのが出てきたのも2005年ぐらいなので、入力値に対してサーバ問い合わせするようなことはできなかった。当時だと一旦画面遷移させないとできなかったわけです。
こうした事情から、クライアントサイド、要するにPC側でもっとリッチなUIが使いたい！という要望があったわけです。Webシステム使いにくい！という不満の噴出と言ってもいい。そこで出てきたのがRIA (Rich Internet Applications)というわけです。
Javaは1.0時代のAppletからそうですが、ネットワークを介して別のPCにプログラムを送り込み、そこで動作させるという能力を持っていました。それこそまさにRIAに求められる機能性だったわけですね。
RIAの代表とされるのは
あたりです。三つ巴の戦い、どこに軍配が上がるのか！？と注目されましたが、勝利したのはHTML / JavaScriptでした。
Google MAP で注目を浴びたAjax技術、それまでブラウザでは不可能と思われていた高級なGUIをHTML / JavaScriptで実現させました。もうやめて欲しいですよね。せっかく脱ブラウザの流れが来たと思ったのにまたWebシステムに逆戻りですよ。
RIAが失速した理由として考慮して置かなければいけないのはスマートフォンの台頭です。RIAでは端末を選ばずどこでも同じアプリが動かせる点がポイントのひとつでしたが、スマートフォンではそうは行かない。"Write once, run anywhere"を破壊したのはスマートフォンだったというわけです。
しかし、先日インストールなしでアプリを実行するAndroid Instant Appsが発表されたりしまして、結局RIAの思想といいますか、要求というのは今でも息づいているのだなと思った次第です。
1.3 / 1.4 では機能追加はあっても言語構文が大きく変わることはありませんでした。大きく変わったのはJava 5です。この時からバージョニングが変わって1.5ではなく5と表記されるようになりました。
Java5の特徴はなんといってもジェネリクス。それまでjava.util.Listにデータを出し入れするのにはキャストが必須だったわけですが、ようやくキャストから開放され型の安全度がぐっと高まりました。その他に以下のような変更があります。
言語としては随分変わっったわけですが、もうかれこれ10年以上前のことですからこれらの機能が「Java5から導入された」という知識は今となってはあまり必要とされません。これらの機能が使えないJava 1.4で開発をする事案が殆ど無いからです。0ではないのが悲しいところではありますが。
Java 6 (2006年12月11日)がリリースされた後、Java 7 (2011年7月28日) が出るまでJavaは停滞してしまいます。その間にSun Microsystemsという会社がなくなってしまったためです。
Sun Microsystems の経営状況が悪化しており、ついに身売りをすることになりました。身売り先はIBMともGoogleとも噂されましたが結局2010年1月27日にオラクルに吸収合併されました。
Javaの停滞中にはJava VM上で動く非Java言語も台頭してきました。Scalaなどですね。
やや戻って2007年にAndroidが発表されます。Androidの開発言語にはJavaが採用されていますが、実行環境はJava VMではなく、ライセンス的な事情でJava(TM)は名乗らない微妙な位置関係にあります。
Java 5 以降で大きく言語仕様に手が入るのは Java 8 (2014年3月18日)です。並列処理を行うためのStream APIと、そのために簡易に関数を定義するためのラムダ式が導入された点が大きいですね。日付APIも刷新されました。
このように、Javaは1.1の黄金時代から今に至るまで利用ジャンルを転戦しながら産業の土台となって支えてきた歴史があります。ジャンルの趨勢により浮き沈みもあります。今後についても決して楽観視はできないでしょう。Javaを学ぶことはプログラミングを学ぶステップとしては意義はあると思いますが、Javaを学べばゴールというわけではありません。プログラム言語も次世代へと移りつつあります。業界動向には注視していきましょう。
ちまたで日本語なのに読めないと話題の某Web製作会社代表のあいさつを理解しようと努めてみたがやっぱり読めない。
ていうかそもそも大事なことは何も言ってないから読む必要もないんだが。
この代表さんはビジネス書やマーケティング書ななめ読みしすぎだろw
http://liginc.co.jp/company/message/
2000年初頭に起こった枠組みの変化により様々な溝が取り払われ、各社の中核事業の経済価値が同質化された結果、先の見えない不況が我々の眼前に覆いかぶさってきています。
LIGは自社の強みでもある競争のない未開拓市場での事業展開、
顧客にとっての障害を取り除くことによって利益を創出する事業に集中する事で、安定的な成長を続けています。
『ソーシャル・ネットワーキングの人気者』
我々の資産でもある、知識として蓄積されたSNSにおける情報マーケティング戦略は、継続することで世の中に多様な影響を与えられると信じています。
さらに社員ひとりひとりが複数のポジションをこなすことのできる選手として活躍する事により確立されたリスク分散の手法は、
他業種との提携を積極的に結ぶ事で効率化を図り、いずれ社会における標準規格となっていくと確信しています。
（そんな社員を便利に使うことや外注することをリスクヘッジマネージメントって言っていいんかいｗ）
現実に必要なものは、自由な発想、機敏さ、そして創造性だと考えています。
縮小される（クライアントのWeb）予算をどのような企画で獲得していくのか、
挑戦を続ける気持ちを持ち続けながら「計画を立てる」「実行する」「行動を評価する」「改善する」という流れで仕事をまわしていくこと、
常に主体性をもって物事を考えて仕事に公平な評価を付与していく。
LIGの成功はそれらの想いの先にあるものなのです。（←どの想い？）
