「ジャストインタイム」を含む日記 RSS

はてなキーワード: ジャストインタイムとは

2020-04-24

日本人=毎回ノーガード戦法で自滅する民族?🤔

コロナ後の世界 - 内田樹研究室 http://blog.tatsuru.com/2020/04/22_1114.html

 

■「独裁か、民主主義か」という歴史的分岐点

コロナ以前」と「コロナ以後」では世界政治体制経済体制は別のものになるでしょう。

 

最も危惧しているのは、新型コロナウイルス民主主義を殺すかもしれない」ということです。

こういう危機に際しては民主国家よりも独裁国家の方が適切に対処できるのではないか・・・と人々が思い始めるリスクがある。

 

今回は中国都市閉鎖や「一夜城」的な病院建設医療資源の集中という、民主国家ではまず実施できない政策を強権的に下して、結果的感染抑制成功しました。

中国他国支援に乗り出した。どの国も喉から手が出るほど欲しがっているもの国内で潤沢に生産できる。このアドバンテージを利用して、習近平医療支援する側に回った。

 

今後、コロナ禍が終息して、危機を総括する段階になったところで、「米中の明暗を分けたのは政治システムの違いではないか」という議論が出て来るはずです。

少なくとも現時点では、アメリカンデモクラシーよりも、中国独裁制の方が成功しているように見える。

欧州日本でも、コロナに懲りて、「民主制制限すべきだ」と言い出す人が必ず出てきます

 

中国はすでに顔認証システムなど網羅的な国民監視システムを開発して、これをアフリカシンガポール中南米独裁国家に輸出しています

そういう抑圧的な統治機構に親近感を感じる人は自民党にもいますから、彼らは遠からず「中国に学べ」と言い始めるでしょう。

 

 

■なぜ安倍政権には危機管理能力がなかったのか

東アジアでは、ほぼ同時に、中国台湾韓国日本の4か国がコロナ問題に取り組みました。

中国はほぼ感染を抑え込みました。

台湾韓国は初動の動きが鮮やかで、すでにピークアウトしました。

その中で、日本けが感染が広まる前の段階で中国韓国ヨーロッパ情報が入っているというアドバンテージがありながら、検査体制治療体制も整備しないで、無為のうちに二カ月を空費した。

準備の時間的余裕がありながら、それをまったく活用しないまま感染拡大を迎えてしまった。

 

―― なぜ日本は失敗したのですか。

 

内田 為政者無能だったということに尽きます

これだけ危機的状況にあるなかで、安倍首相官僚の書いた作文を読み上げることしかできない。

ドイツメルケル首相イギリスボリス・ジョンソン首相ニューヨークアンドリュー・クオモ州知事まこと説得力のあるメッセージを発信しました。

それには比すべくもない。

 

一つには、東京オリンピックを予定通り開催したいという願望に取り憑かれていたからです。

そのために「日本では感染は広がっていない。防疫体制完璧で、すべてはアンダーコントロールだ」と言い続ける必要があった。

から検査もしなかったし、感染拡大に備えた医療資源の確保も病床の増設もしなかった。

最悪の事態に備えてしまうと最悪の事態を招待するかも知れないから、何もしないことによって最悪の事態の到来を防ごうとしたのです。

これは日本人に固有な民族誌的奇習です。

気持ちはわからないでもありませんが、そういう呪術的な思考をする人間近代国家危機管理に当るべきではない。

 

「準備したが使用しなかった資源」のことを経済学ではスラック(余裕、遊び)」と呼びます

スラックのあるシステム危機耐性が強い。スラックのないシステムは弱い。

 

東京五輪については「予定通りに開催される準備」と「五輪が中止されるほどのパンデミックに備えた防疫対策の準備」の二つを同時並行的に行うというのが常識的リスクヘッジです。

五輪準備と防疫体制のいずれかが「スラック」になる。でも、どちらに転んでも対応できた。

しかし、安倍政権は「五輪開催」の一点張りに賭けた。それを誰も止めなかった。

それは今の日本政治家や官僚の中にリスクヘッジというアイディア理解している人間ほとんどいないということです。

久しく費用対効果だとか「ジャストインタイム」だとか「在庫ゼロ」だとかいうことばかり言ってきたせいで、「危機に備えるためには、スラックが要る」ということの意味がもう理解できなくなった。

感染症の場合、専門的な医療器具や病床は、パンデミックが起きないときにはほとんど使い道がありません。

から、「医療資源効率的活用」とか「病床稼働率の向上」とかいうことを医療の最優先課題だと思っている政治家や役人感染症用の医療準備を無駄だと思って、カットします。

そして、何年かに一度パンデミックが起きて、ばたばた人が死ぬのを見て、「どうして備えがないんだ?」とびっくりする。

 

 

コロナ危機中産階級が没落する

―― 日本が失敗したからこそ、独裁化の流れが生まれてくる。どういうことですか。

 

われわれに出来るのは、これからその失敗をどう総括し、どこを補正するかということです。

本来なら「愚かな為政者を選んだせいで失敗した。これからもっと賢い為政者を選びましょう」という簡単な話です。でも、そうはゆかない。

 

コロナ終息後、自民党は「憲法のせいで必要施策が実行できなかった」と総括すると思います。必ずそうします。

コロナ対応に失敗したのは、国民基本的人権配慮し過ぎたせいだ」と言って、自分たちの失敗の責任憲法瑕疵転嫁しようとする。

右派論壇からは、改憲して非常事態条項を新設せよとか、教育制度を変えて滅私奉公愛国精神を涵養せよとか言い出す連中が湧いて出て来るでしょう。

 

コロナ後には「すべて憲法のせい」「民主制は非効率だ」という言説が必ず湧き出てきます

これとどう立ち向かうか、それがコロナ後の最優先課題だと思います

心あるメディアは今こそ民主主義を守り、言論の自由を守るための論陣を張るべきだと思います

 

―― 安倍政権コロナ対策だけでなく、国民生活を守る経済政策にも失敗しています

 

内田 コロナ禍がもたらした最大の社会的影響中間層の没落」が決定づけられたということでしょう。

民主主義の土台になるのは「分厚い中産階級です。

しかし、新自由主義的な経済政策によって、世界的に階級二極化が進み、中産階級がどんどん痩せ細って、貧困化している。

 

ささやかながら自立した資本家であった市民たちが、労働以外に売るものを持たない無産階級に没落する。

このままゆくと、日本社会は「一握りの富裕層」と「圧倒的多数貧困層」に二極化する。

それは亡国のシナリオです。

 

―― 中産階級が没落して民主主義形骸化してしまったら、日本政治はどういうものになるのですか。

 

内田 階層二極化が進行すれば、さら後進国すると思います

ネポティズム縁故主義がはびこり、わずかな国富を少数の支配階層排他的に独占するという、これまで開発独裁国や、後進国しか見られなかったような政体になるだろうと思います

森友問題加計問題桜を見る会などの露骨ネポティズム事例を見ると、これは安倍政権本質だと思います

独裁者とその一族権力国富を独占し、そのおこぼれに与ろうとする人々がそのまわりに群がる。

そういう近代以前への退行が日本ではすでに始まっている。

 

 

民主主義遂行する「大人」であれ!

―― 今後、日本でも強権的な国家への誘惑が強まるかもしれませんが、それは亡国への道だという事実を肝に銘じなければならない。

 

内田 確かに短期的なスパンで見れば、中国のような独裁国家のほうが効率的運営されているように見えます民主主義合意形成時間がかかるし、作業効率が悪い。

でも、長期的には民主的国家のほうがよいものなんです。

 

それは、民主主義は、市民の相当数が「成熟した市民」、つまり大人」でなければ機能しないシステムからです。

少なくとも市民の7%くらいが「大人」でないと、民主主義システムは回らない。一定数の「大人」がいないと動かないという民主主義脆弱性が裏から見ると民主主義遂行的な強みなんです。

 

民主主義市民たちに成熟を促します。王政貴族政はそうではありません。少数の為政者が賢ければ、残りの国民はどれほど愚鈍でも未熟でも構わない。

国民が全員「子ども」でも、独裁者ひとりが賢者であれば、国は適切に統治できる。むしろ独裁制では集団成員が「子どもである方がうまく機能する。

から独裁制は成員たちの市民成熟求めない。「何も考えないでいい」と甘やかす。

その結果、自分もの考える力のない、使い物にならない国民ばかりになって、国力が衰微、国運が尽きる。

その点、民主主義国民に対して「注文が多い」システムなんです。でも、そのおかげで復元力の強い、創造的な政体ができる。

 

民主主義が生き延びるために、やることは簡単と言えば簡単なんです。システムとしてはもう出来上がっているんですから

後は「大人」の頭数を増やすことだけです。やることはそれだけです。

 

―― カミュは有名な小説ペスト』のなかで、最終的に「ペスト他人に移さな紳士」の存在希望見出しています。ここに、いま私たちが何をなすべきかのヒントがあると思います

 

内田 『ペスト』では、猛威を振るうペストに対して、市民たち有志が保健隊組織します。

これはナチズム抵抗したレジスタンス比喩とされています

いま私たち新型コロナウイルスという「ペスト」に対抗しながら、同時に独裁化という「ペスト」にも対抗しなければならない。

その意味で、『ペスト』は現在日本危機的状況を寓話的に描いたものとして読むこともできます

  

ペスト』の中で最も印象的な登場人物の一人は、下級役人グランです。それがカミュにとっての理想的市民としての「紳士」だったんだろうと思います

紳士」にヒロイズムは要りません。過剰に意気込んだり、使命感に緊張したりすると、気長に戦い続けることができませんから日常生活を穏やかに過ごしながらでなければ、持続した戦いを続けることはできない。

コロナ以後」の日本民主主義を守るためには、私たち一人ひとりが「大人」に、でき得るならば「紳士」にならなけらばならない。私はそう思います

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

2015-09-20

トヨタカレンダー理屈は変だ

anond:20150920130007 の理屈は変だ。

 

工場機械を止めたり動かしたりすることが非効率である。(機械の停止処理と稼働処理には思ったよりも時間がかかる)

 

今の祝日は週末につながっているのが普通で、飛び石にならない。ゆえに、止めたり動かしたりする回数は変わらない。

たとえば、今回の連休は、

  土日

  土日月火水

のどちらでも、止めたり動かしたりする回数は同じである。(時期がズレるだけだ。)

飛び石連休混同してはならない。

 

納入する部品は、すべて5日分を1ロットとして考えるだけで済む。今週は4日しかないから普段の80%の製造量にしなくては、などと例外対応する必要がない。

 

トヨタカンバン方式ジャストインタイムで最適の量を納入する。「5日分を1ロットとして考える」なんて、カンバン方式よりも前の、ずっと古い方式だろ。在庫管理コンピュータ制御できる時代に、何を言っているんだ。50年前の手書き伝票時代と間違えているんじゃないのか? 

また、「今週は4日しかないから普段の80%の製造量に」なんてことはない。普段の100%の製造量にして、稼働日数を80%にするだけだ。自動的に調整が付く。普段の80%の製造量にしたら、稼働日数が80%なので、生産量は64%になってしまうぞ。勘違いするべからず。

  

結局、トヨタカレンダーにまともな根拠はない。

では何があるかというと、「ほとんどあるかなきかの小さな会社利益向上のために、従業員に多大な迷惑をかける」ということだ。「自分が1円の利益を得るために、従業員に100円の損失をもたらす」ということだ。

こうして、従業員生活犠牲にして、家族の団らんを破壊することで、エゴイズムを貫徹する。乾いた雑巾を絞り、従業員の血の一滴も絞るようにして、ひたすら自社の利益を上げようとする。

 

こんな会社欧米にあったら、たちまち指弾される。

トヨタカレンダーなんてものは、日本だけで成立する。

決して世界トヨタで共通する方式ではない。

日本労働者がなめられているだけだ。

 

   - - - - - - - - - - - - - - - - - - - -

  

すべては自民党のおかげだよ。

きみたちが自民党にいっぱい投票たから、自民党はお返しで、労働者虐待して上げるんだ。

マゾ労働者は、「嬉しい、嬉しい」と感謝して、鞭打たれていろ。

 

  ※ 最後の「きみたち」とは、トヨタ労働者のことではない。一般国民(の大半)のことだ。

    ここでは話が変わっている。わかりやすくするために、あとで区切り線を入れておいた。

 

 


 

 追記しておくと、トヨタ海外工場は、原則として、現地の労働法制に従っており、違法行為はしていない。(日本と同じならば、違法になることもあるが。)

 たとえば、フランスでは、法律を守って、週 35時間労働で、バカンスもある。

     http://www.mynewsjapan.com/reports/1262

     http://www.ritsumei.ac.jp/~hyodot/semihomepage/kenkyutenkai3.html

 

 

2008-07-05

http://anond.hatelabo.jp/20080705004832

社会主義の方は、読み手(の感覚)が分かりやすい表現ってことで例を挙げた感じです。

流通か・・・確かに余り考えてませんでした。

現場を知らないので何とも言えませんが、Amazonの場合は1日に何回もトラックがモノを運んでると考えると、トヨタの「ジャストインタイム」のような方式を採用しているはずです。

となると、トラックを若干待たせる(トラック運転手に払う給与が増える)という無駄はあるものの、運送会社に膨大な数の注文を出すと言う立場を生かして、量販店よりも流通コストを安くできるのではないでしょうか?

デルは組立工程をを運送会社に投げて、運送会社自身が組立すぐ発送と言う手法を取ったとかなんとか。(大前研一「新・資本論」)

流通に関しては良く知らないので、良い解説を頂けると嬉しいです。(単に知りたい)

デルAmazonの比較ですが、後者は複数のジャンルにわたる商品を1つのボックスに詰めるわけですから、工場固定資産税、箱詰めする従業員の賃金、などがかさみますね。

あと、

>>巨大資本零細企業競争に関しては、飛躍があり過ぎて話にならない。<<

>>自分勝手理論から脱出できない<<

次回以降、もう少しまともな記事を書けるようになるためにも、流通以外で飛躍してる点と、自分勝手理論の部分がどこらへんにあるか、そしてそれは何故かを具体的に教えて下さい。(バカですみません)

>>自分勝手理論から脱出できない。それこそが、別次元同士での不毛な議論を生み出してしまう原因です。<<

確かに良くあることだと思います。

>>(と思うよ)<<

優しさが滲みでてて、嬉しかったです

2008-03-02

俺のウンコ

どうも七時間か八時間で、製造されているみたいなんだが、

これって早いほうじゃないだろうか。

ジャストインタイムって、こういうのか?

【追記】

ちょっと調べてみたら、普通は九時間から十六時間というところらしい。

朝晩二回、ウンコをすることが多いのだけれど、ぼんやり一日を送っていると、

ついさっき食べたものが出てきたような気がして、びっくりしてしまう。

 
ログイン ユーザー登録
ようこそ ゲスト さん