「標準規格」を含む日記 RSS

はてなキーワード: 標準規格とは

2017-10-12

京都市が今回失敗したような、自治体システム更新について

http://itpro.nikkeibp.co.jp/atcl/column/14/346926/101101158/

Q1.役所仕事なんて全国でほぼ一緒なのに、なんで自治体ごとに別のシステムを作るの?

A1.地方自治体事務財務について法律で決まっているのは大枠だけだよ。

  それを実務≒内部規定に落とし込むのは各役所ごとなので大枠は似てても実務プロセス全然役所で違うよ。例えば同じ業務でも独自の語彙があったり、下手すると同じ語で市町村ごとに意味が違ったりするよ。


Q2.なんで新規で作らないの?

A2.80年代ぐらいにやったよ。その結果が政令市クラスに残ってて今回京都市更新しようとしてるような、メインフレーム上のシステムだよ。


Q3.メインフレーム汎用機)って何?

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汎用機付属品みたいについてって、困ったらオペレーターとして介入して動かしていたみたいだよ。

そうやって現場感覚バリバリでやっているので、オペレーターしか知らないプロセスがあったりするよ。

マイグレーション開発では総合テスト中にそういう隠しプロセスが「発見」されたりするよ。こわいね


Q6.役所が現行システム資料を出すべきだろうが!

A6.もっともだけど、できないから無理だよ。

上記の通り仕様書がないことも多いうえ、システム課に限らず市役所人員は基本ローテーションするよ。

導入当初の担当者が残っていることは珍しいし、30年も前に導入した汎用機ことなんてここ10年に入った職員にはわからないよ。



Q7.なんで入札にしたの? 現行ベンダ指名してやらせたほうが良くない?

A7.金額がでかいから、たぶんどこの市役所でも入札案件だよ。

随意契約(随契)は無理だし、入札業者発注者指定する指名競争入札談合の温床になってたか最近あんまりやらないよ。


裏技としてRFP指名したいベンダーに書かせて公募指名入札にしたり、RFPの段階でハードを全部特定ベンダで型番まで指定するというのがあるけど、公になると多分問題になるよ。こわいね



Q8.じゃあ役所は悪くないの?

Q8.悪いよ。

入札案件RFPで書かれた各項目をどれだけ満たすかの技術点と、価格点で決まるよ。点が高ければだいたい自動的にそのベンダーに決まるよ。

なので、技術点の項目に現行システム調査にかかる項目を入れるとかして、現行機の開発・保守ベンダ高得点を取れるようにしておけば価格勝負してくるベンダーをはじけた可能性はあるよ。

もちろん現行の会社に嫌われて逃げられたとか、役所が現行の会社めっちゃ嫌いになって声をかけなかったとかもあるかもしれないけれど、可能性は低いと思うよ。



Q9.じゃあベンダーは悪くないのか?

A9.ここまで述べたようにこの手のマイグレーション火薬庫だよ。火を噴いても爆発しなければラッキーぐらいなので、強いて言うなら入札したことが悪いよ。

安すぎる見積もりを出したSEだか営業だかは死んでね。



Q10.お前(増田)は何者?

A10.前にマイグレーションをやったことがあるSEだよ。もうやりたくないよ。今は転職してSIerじゃなくなったからやらなくてよくなったよ。うれしいね

  しょぼいSEからここに書いたことは個人体験に基づく参照情報だよ。一般的じゃないことを言ってたり、間違ってたら教えてもらえると助かるよ。





(2017.10.13 追記)

Q3がかぶっていたよ。恥ずかしくてなきそうだけどブコメに番号で言及してくれている人がいるから忍んでそのままにするよ。


あと、「オープン化」の定義が違くない?という指摘があったよ。確かに増田が間違っていたので、記事の主旨から外れるけど補記するよ。

メインフレームは本文で述べたようにOSからハードまでメーカー謹製なので独自仕様のカタマリだよ。

これに対しPCサーバ標準規格で作られているよ。こういう標準規格に基づくサーバオープン系と呼ぶよ。

独自規格クローズしたコンピュータから、そうでないオープン系に移行するからオープン化なのであって、専用線とかは関係なかったよ。半可通な知識で語ってしまったよ、ごめんね。

京都市で火中にいるシステムズさんのサイト解説がこの増田よりも分かりやすくて正確だから気になる人は見てほしいよ

http://www.migration.jp/column/column01.html

完全に余談だけどオープン系のx86サーバに移行しても、システムはそんなにオープンにならなかったりするよ。

H系に頼むとDBが拝承DBになったり、Fに頼むとシステム管理が全部SystemWalkerになったり、要するにベンダ独自のミドルに入ってがっつりロックインされたりするよ。

オープン化(オープンではない)みたいなことになって面白いよ(面白くない)

2017-09-17

はてブやってるようなクズEVを買えないくらいに貧乏か車に興味ないかどっちかなんだよなぁ

はてなブックマーク - 経産相「いきなり電気自動車にいけるわけでもない」 | NHKニュース

車に興味ないなら黙ってろくそはてブ民。

まともなブコメまとめていくが、これ否定できるならやってみろよ。

どうせ経産省批判する流れが出来てからなんとなく乗っかかって物言ってるだけの思考停止したバカはてな民

ほんまお前ら害悪しかないわ。



gokkie 30kWhリーフ買って一月半で2500km乗ったけど、今のトコ不満はない。先行者特権フリーライダーになれるのは限られた期間やろし、格安で買った車でガンガンフリーライドしまくるで

etr そうなんだ・・・とりあえず私、テスラ乗るね。(モデル3予約してます。)

600以上ブクマついてるのに実際に電気自動車を買って乗る人が二人しかいないはてな民wwww




ちゃんと自動車のことわかってる人のコメント

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 インフラ整備が不要プリウスなどHV20年掛けてやっとシェア30%(世界ではもっと低い)。充電スポット新規発電所建設などインフラ整備が必要不可欠な電気自動車がどれだけハードルいか理解して欲しい

dannier インドフランスEV縛り宣言したけど、ドイツは同じ問題抱えてるから実はEV宣言はしてないんだよね。まあ研究開発と充電設備に巨額の投資はしてるけど。あと中国もいつ急に降りるかわからん、という感じなのだ

ryokujya 日産ノートeパワーを見ましょう。リーフを出した日産エンジンを発電に使うノートを出した意味を。今はハイブリッドが適している




もちろん私だって別にEV否定してるわけじゃないぜ。政治的にもアドバンテージを取らないといけない部分があるのはその通りです。

インフラ整備や普及のための補助金標準規格競争など、適切なタイミングを見て国が参加する必要はありますはてブもそのあたりわかってる人をちゃんとフォローしたいですわ。

awkad いかにも日本だ。作る側が神と思ってる。決めるのは需要側なんだよ。中国アメリカEVだっていったらEVだ。日本需要で負けてるんだから決定権なんてない

mamezou_plus2 充電スタンド規格「CHAdeMO」と別規格を欧米に作られ日本外しEVが普及すると充電負荷が高すぎるのでスマート電力のシステムとかサービスとか。内燃車とは特性が違うから交通などデザインし直さなきゃいけない

giyo381 電気自動車時代って言ってる人の中でwell to wheel知ってる人どんくらいいんだろ。石油が連産品とか、発電効率とか知ってるのかしら

石谷久(東京大学教授)による「Well to Wheel」でのCO2排出量( 2005 )/ ガソリン車:193 / ガソリンハイブリッド車:123 / 燃料電池自動車86 / 電池電気自動車:47 / https://blogs.yahoo.co.jp/zaqwsx_29/18278184.html


お前らみたいなアホが、燃料電池の時も同じことを言ってて、

燃料電池がだめになったらその時応援してたことも忘れて手のひらクルーするわけよ。

おまえらどうせEVについても、EVにさっさと乗ろうとしない政府無能とか言っておきながら、

いざ上手く行かなかったら、「誰だよEVに一足飛びに行こうとしたやつは」とかいい出すわけよ。


2040年になった時、さすがにお前らもはてなをやってないとは思うが、

このブックマークページのコメントは保存しておいて「ほーら20年前にこういうバカなことを言ってる人たちがいたんだよ」って晒してやるから覚悟しとけよ。

2017-08-07

誰か暗記プロセス標準規格作ろうよ

私は現在仕事ソフトウェア開発のプロセス改善活動をしている

そこで考えたのだが、なぜこの世の中には色々なプロセスの規格がないのか

様々な分野でプロセス規格を作ってみた面白そうではないか

例えば暗記方法

暗記方法は「人それぞれ」という言葉のせいで議論が進まなくなっているイメージで、効率の悪いことやっている学生がたくさんいるのではないか

そこで暗記方法ベストプラクティスを集めたプロセスの規格を作るのだ

暗記する者たちは、自分でそのプロセスの規格を読み、暗記方法改善する

または、プロセス規格からできたチェックリストを使って自分の暗記方法改善する

さあ、誰か標準団体を立ち上げよう

2017-07-31

https://anond.hatelabo.jp/20170731002447

結論から言うと、支援しなくていい、というか、支援しても「ムダ」である

まず高校中学の時点で妊娠するという時点でレールから既に大きく外れている

ここで言うレールは、世間一般人間が歩むであろうという最小公倍数な人生のレールである

こう書くとはてなでは非常に忌み嫌われるが、

実は国の社会保障などは全てこの「レール」の思想にもとづいて制度設計されている

大多数の人間がそれなりに歩むだろうと想定されるモデルを元に、

例えばこれくらいの病気したこれくらい安い医療が受けられるようにしてこれくらいの保険料徴収しよう、

初等教育負担はこれくらい軽減して税源はここから持って来よう、

失業者数は大体これくらいだろうから失業保険はこう設計しよう、

とまあこういった具合だ

大多数の標準規格を作ることができればそれに合わせた製品サービスを廉価で提供できるというのは経済学の基本中の基本

から、みんなが大体これくらいの人生を歩むだろうと想定される人生に、

基本ラインを合わせるのは当然の生きる知恵なのだ

人間が発揮しうる個性というのも、その基本ラインベースにした上で個性を積み重ねるのがセオリー

その基本ラインのものから外れてしまったら、人生設計のものが大きく狂わざるを得ないのだ


前置きが長くなったが、

日本に限らず先進国(教育コスト一定水準以上かかるところの)の一般社会において、

中学高校の年齢で生セックス中出しキメて挙句妊娠するような人間存在は「普通とは想定しない」のである

ローティーンから労働に駆り出されたり初潮を迎えたらすぐに嫁に出されるような非先進国はこの限りではない)


まずこの前提の確認重要である

左派リベラル思想が色濃いはてなではこう言うと凄まじい否定の嵐が吹き荒れるであろうが、

まあ理想社会としてそのようなレールから外れたティーンにも普通のレールに乗った人間と同じような待遇を、

と想定するのは立派なことではあるが、

現実を踏まえずに理想ばかりがなりたててその理想にそぐわない子供現実存在している事案に対して、

理想にそぐわない子供を助けない社会が間違っていると指弾したところで現実がその子供を救うことはない

安倍晋三のようなポンコツ宰相一人放逐できず、

一人一派だのと世迷い言を抜かすリベラルフェミニズム界隈に今の現実問題と向き合うにはあまりに荷が勝ちすぎていよう

この前提を共有できないのなら、

どうぞ世の中や国や社会に対してあらん限りの呪詛を垂れ流し続けるといい

その呪詛によって妊娠した高校生が救われるのであるのならな

社会さえ呪えば弱者は救われると考える原始宗教従事者が日本左派リベラルには多すぎてな

さてこの前提が共有されるのであるのなら、次が肝要である

社会一般のレールから外れてしまった存在に対して、

高校への復学だの一時金の支給だのというのは焼け石に水であり何の意味もないのだ

問題本質は、なぜ社会のレールから外れてしまったのか?という考察である


まりここからは十把一絡げな社会制度による手当は「無効」なのである

元増田が想定する支援というのもこの部類に属する

まり

高校妊娠してしまった生徒には一律このような支援を施します、

という手当は全く効果をなさないのである

なぜなら、そもそもそうした支援が効力を発揮するのはレールに乗った人間に対してであり、

レールから外れたのならもっと個別的な深い分析をせねば何をやってもムダであるからである

はてなに居る左派リベラルはこの点が全く分かっていない

原始宗教の如く、神(政治的正しさ)に祈り、悪魔(国・社会衆愚)を憎みさえすれば人間が救われるという思想に十年一日の如く染まり続けているのだから、仕方がないと言えば仕方がない

妊娠した高校生に対する社会的処方箋もっとコスト」がかかるのだ

個別具体的な諸条件をつぶさに分析して、その子供に最も適応した対応策を施さなければならない

十把一絡げの社会的支援など効くわけがないのである

言うなれば風邪難病の違いほどのもの

流通している薬さえ投薬すれば治るとでも思ってもらっては困るのである

さてここで、避妊もせず生セックスして中出しキメて挙句中絶もせず出産してしま中学高校生は、どうして生まれてきてしまったのかを、個別具体的に考える必要がある

普通に考えればまあ教育水準所得水準も低く、レールからそもそも外れてるようないわゆるチンピラDQN系の糞ガキであろう

こんなのは一々構う必要がないのははてな界隈でも容易にコンセンサスが得られるはずである

いわゆる爆サイ民であり、タバコを吸い、酒を飲み、政治的正しさなど毛ほども顧みず、イジメ差別を平気でして人権意識は皆無、男尊女卑で、セックスにおける同意?何それ?的な態度でセーフなセックスなど全くしないようなDQNに対して支援を!などと世迷い言をほざくはてなーはよもや一人も居るまい

だがしかし、世の中が複雑化してくると、こうしたDQNばかりではないケースも、徐々にではあるが、しかし出て来るかもしれないのだ

純愛の果てに生まれたケースというのももしかしたらなくはないのかもしれない

そのような場合には、DQNと同じように支援必要なし!と断ずるのは早計ではあるだろう

冒頭「支援必要はない」とは言ったが、個別具体的なケースを分析していった場合に、こうした従来のレールでは想定し得ない特殊な例が生まれている可能性も否定できないわけなので、

今後はDQN以外の救うべき対象の見極めが重要になってくるであろう

2017-04-13

http://anond.hatelabo.jp/20170413225101

続き。BHQの標準化活動

中身見れないけど、山川氏のアクティティはあるのかな。

まあそれなりの人が参加してればそれなりと言えるかもしれない。構成員からないけど。

https://www.itu.int/md/T17-SG16-170116-TD-WP2-0024/en

慶応大川森氏によるQ28/16のプレゼンテーション。(イラストやが世界進出してる)

http://www.itu.int/en/ITU-T/gsi/iptv/Documents/ws/201606Brain/S1P1-Masahito_Kawamori-Intro_to_ITU_and_Q28_work.pdf

NTT出身・・・からITU-Tなんだねえ。

http://www.ttc.or.jp/files/3213/5884/2008/TTCniyosete_kawamori_2013_01_Vol.27_No.4-3.pdf

医学的に十分信頼できる話かどうかは、判定できない。意識低い工学系の研究者からね。

一般論では、使われない"標準規格化"は腐るほどあり、それは最終的にはクソの山なので、これがそうならないことを祈る。

2016-06-17

1.0から学ぶJava

タイトルを見て釣られクマーな皆さんこんにちは

ホッテントリメーカーで作るような煽りタイトルって、みなさんもう見飽きてると思うんですよね。

今調べたらホッテントリメーカー2008年だそうで。どうりでねー。古臭いなーと思いましたよー。

「一から学ぶJava」ってのをね、1.0にするだけでこんなに素敵なタイトルになるんだから面白いですねー。

タイトルを思いついただけだったんですけど、思いついたらやっぱりちゃんと中身も書かないと行けないじゃないですか。やだー

面倒くさいんですけどね。ちょっと1.0から学んでみましょうか。

Java 1.0 1996年1月23日

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を腐す要素として挙げられてしまうのでした。

Java 1.1 1997年2月19日

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は今とはデザインが大きく異なります。

  • java.applet
  • java.awt
  • java.awt.datatransfer
  • java.awt.event
  • java.awt.image
  • java.beans
  • java.io
  • java.lang
  • java.lang.reflect
  • java.math
  • java.net
  • java.rmi
  • java.rmi.dgc
  • java.rmi.registry
  • java.rmi.server
  • java.security
  • java.security.acl
  • java.security.interfaces
  • java.sql
  • java.text
  • java.util
  • java.util.zip

この時代であれば、全パッケージを舐めて標準APIを学ぶこともそう難しくはありませんでした。この時代から触っている人間は新バージョンが出るたびに増えるAPIを順に学んでいけたのです。しかし、現代にJavaを学ぶ場合、どのバージョンでは何があって……というのをいちいち学ぶ必要はほぼありません。Java5以前は一緒くたでいいと思いますし、一部のAPIで歴史的経緯があってねーというのを知っていればおそらく十分ではないでしょうか。

Java 1.2 1998年12月8日

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は使うべきではありません。

Microsoft 離反

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 EE

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のシステム開発がなかなか成功しないってのもあったんでしょうけどね。

iアプリ Javaアプリ EZアプリ

2000年あたりというと携帯電話の普及も取り上げなければなりません。現代のスマホガラケーに比べれば非常に機能は貧弱で、まさに携帯「電話」でした。要するに電話とメールぐらいしかできなかったんですね。

そこにdocomoiアプリJフォン(ボーダフォンを経て現ソフトバンク)のJavaアプリ、auのEZアプリという携帯電話上でちょっとしたアプリが動くよ!というのが乗るようになってきたんです。これがJavaを組込み用途にコンパクトにしたJava MEというものが土台となっていて(正確にはiアプリちょっと違う)Servletと並ぶJava言語の大きなもうひとつの領域となっていました。

iアプリは当初は容量が10k byteまでといった制約があり、容量制限が非常に厳しかったのですが、新機種が出るたびに容量は緩和されていきました。

docomoiアプリ含めiモードによって一世を風靡します。こうした土台を作ると、その上で商売をしたい人がたくさんやってきて、勝手にコンテンツを作ってくれる。docomoはそれらから手数料を取るので労せずして大金を稼げるというわけです。賭場の胴元というわけです。

この賭場が、将来にAppleiPhone, GoogleAndroidに荒らされることになります。docomoがなかなかiPhoneを出さなかったのもiモードという自前の賭場を失うことを良しとしなかったためです。金づるを失ったdocomoSamsungと組んで独自の携帯向けOSであるTizenの開発に乗り出します。そんなTizenですが鳴かず飛ばず。噂ではインドあたりではリリースされたとか、なんとか。

RIA時代

話を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の思想といいますか、要求というのは今でも息づいているのだなと思った次第です。

Java 5 (2004年9月30日)

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を学べばゴールというわけではありません。プログラム言語次世代へと移りつつあります。業界動向には注視していきましょう。

2016-01-22

日本語なのに読めない

ちまたで日本語なのに読めないと話題の某Web製作会社代表あいさつを理解しようと努めてみたがやっぱり読めない。

ていうかそもそも大事なことは何も言ってないから読む必要もないんだが。

この代表さんはビジネス書マーケティングななめ読みしすぎだろw

()内は私のぼやきです。

http://liginc.co.jp/company/message/

『真の成功企業を目指して』

今、IT業界革命時代突入しています

2000年初頭に起こった枠組みの変化により様々な溝が取り払われ、各社の中核事業経済価値が同質化された結果、先の見えない不況が我々の眼前に覆いかぶさってきています

LIGは自社の強みでもある競争のない未開拓市場での事業展開、

顧客にとっての障害を取り除くことによって利益を創出する事業に集中する事で、安定的な成長を続けています

ソーシャル・ネットワーキングの人気者』

今では誰もがSNSを利用しています

我々の資産でもある、知識として蓄積されたSNSにおける情報マーケティング戦略は、継続することで世の中に多様な影響を与えられると信じています

さら社員ひとりひとりが複数ポジションをこなすことのできる選手として活躍する事により確立されたリスク分散手法は、

他業種との提携積極的に結ぶ事で効率化を図り、いずれ社会における標準規格となっていくと確信しています

(そんな社員を便利に使うことや外注することをリスクヘッジマネージメントって言っていいんかいw)

私たち現実

現実必要ものは、自由な発想、機敏さ、そして創造性だと考えています

縮小される(クライアントWeb予算をどのような企画で獲得していくのか、

その機会を逃さな管理体制こそがカギです。

挑戦を続ける気持ちを持ち続けながら「計画を立てる」「実行する」「行動を評価する」「改善する」という流れで仕事をまわしていくこと、

常に主体性をもって物事を考えて仕事に公平な評価付与していく。

LIG成功はそれらの想いの先にあるものなのです。(←どの想い?)

まあ挨拶とか言ってこれ全部ただの思いつきだけど!(←あっ、最後本音を言ってる)

2015-09-26

政治力呪いドイツ自動車メーカーはなぜディーゼルで失敗をするのか

資源呪いという言葉があります

https://ja.wikipedia.org/wiki/%E8%B3%87%E6%BA%90%E3%81%AE%E5%91%AA%E3%81%84

簡単に説明すると

資源があることで甘えが出てほかの産業への投資が怠る事や、資源があることで紛争汚職がはびこる原因になることです。

資源がある国の多くが途上国であることからそう言われるようになりました。

資源恩恵をもたらすものではなく、甘えや政治腐敗、紛争を引き起こすものであるという発想。

私はこの面白い考えが、今回のVWディーゼルエンジン問題にも言えるのではないかと思いました。

まりドイツ政治力引き起こしたのではないかと。

政治力といえばアメリカです。

日米貿易摩擦の時、ジャパンバッシング日本車をひっくり返すパフォーマンスなどをやっていた時代

関税など、ビッグ3を守るためにあれこれ政治的日本企業妨害していましたよね。

しか結果的ビッグ3がどうなったかみるとわかりますよね。政治力って本当に企業のためになるんでしょうか。

国際的日本企業は、自国国際政治立場の弱さを知っているため、国を当てにしていません。

トヨタなどはそれこそ日本の政治家や官僚以上にアメリカ政治に対して神経とがらせています

おなじくらい気を使っているのは、確かな技術です。技術は誰の目から見ても公平に評価ができる分野です。

なので私は、日本企業がまじめに技術と向き合っているのは、かなしいかな政治力のなさによって起こったものではないかなと思うのです。

なのでそういった理由からなのか日本企業の多くは国際的には技術押しで紳士対応しますが、内政だととたんに横暴な態度とったりしますよね。

政治力が使える相手なら政治で楽に対応する。そんなイメージがあります

かつてのドイツもそうだったのではないかと思うんです。

運よく政治力がなかったと。

僕のイメージするドイツ技術世界一的なイメージというか、

歴史的ドイツ技術力で他国を圧倒するようになるのは第一次大戦以降ではないかと思っています

大航海時代出遅れたために植民地もてなかったドイツが、産業革命出遅れドイツが、第一次大戦に負けたドイツが、

その結果のヨーロッパでの政治的立場の弱さを、技術習得に注力したのではないかと思います

そして、そういったドイツ稲穂の垂れるような態度を作り上げた外的要因が、ことごとくEU誕生、そしてユーロ誕生でなくなったと思います

アメリカロシアに対抗するために誕生したスイミー作戦EUによってドイツ宗主国立場になりました。

ドイツを仲間にすることでヨーロッパの争いを解決するというのもあったわけですが

皮肉なことにユーロのせいでユーロ圏内では、比喩ではなく本当に宗主国状態です。

ナチスに例える人も出てくるくらいですが、けして大げさではないと思いますね。あれはもはや帝国です。

いろいろケチつけましたが、とにかくスイミー作戦EUによってドイツ国際的影響力を持ったわけです。

メルケルもさぞかし楽しい政治ライフを送っていることでしょう。

しかし、その強い政治力が、産業に悪い影響を与えているのではないかという考えが、私のなかにうかびました。

まりドイツEU宗主国立場を利用し、ディーゼルクリーンものだということにして、技術開発競争から目をそむけたのではないかと。

かつてのアメリカのように。アメリカ化とでもいうんでしょうかね。



政治力必要ないとはいいません。軍事産業インフラ分野などは政治力必要なところもあるでしょうね

標準規格の争いも政治ものを言いますよね。アメリカEU、そして中国立場を強めています

日本企業勝手に行動するとむしろ国内の識者からガラパゴスだなんだとたたかますし。

しかし、今のところ一般の車はどこぞの団体が規格を握っているわけではないですし、

政治がかかわるにしても今回のように排気ガス規制などくらいです。

自動車産業自由技術を見せられる分野でうらやましいなと思います

私は家電屋ですが、今になって白物家電がもてはやされているのは規格に縛られずに作れるからだと思います

将来OS重要になり自動運転などが登場したときにどうなるかわかりませんが。

今のところ、日本自動車メーカー大丈夫だと思いたいですね。

日本企業も内政では政治で話を押し通す癖があります原発などもその一つでしょう。

他山の石として考えるべきことだと思います

2014-11-09

http://anond.hatelabo.jp/20141109114746

お前は俺か案件ですね。「伝統で言うなら、タブ幅は8じゃないですか?」と言い返したら、「タブ幅は4が標準ですよ。だいたいタブ幅が8だったら、インデントが深すぎて使えないじゃないですか」みたいなことを言われましたよ。

タブ幅に標準規格はねえし、タブはコードのインデントのためにあるんじゃねえんじゃよー、ぎゃわー!

タブ幅は8のほうが伝統的だし8で固定すべきという意見にはそれなりに同意できるんですが、現状としてタブ幅は固定でないし、もしタブ幅が8だとしたら、インデントにタブを使う人は減るんじゃないすかね。

コードからタブ滅するべし!

 
アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん