  |
はてなキーワード: Oracleとは
米中の技術競争に日本はおいていかれているように、いち技術者からは見える。
どうして今のような状況になったのか、考えてみたい。
原因は1つではなく、複合的だろう。
日本で半導体を開発しようとすると設計ソフト(Cadence, Synopsysなど)が必要だが、国産はもうないに等しい。
Webで働いている人からするとオープンソースで開発すれば、と思われるかもしれないが、あるにはあるが、実際の製造には使えない。
機能が全然足りていないのもそうだが、全部の設計工程用のソフトはない。
製造原価やウェーハ代や人件費がかかるでしょと言われるが、ライセンス料金も開発費の中でかなりの割合を占めている。
Web業界だとOracleの値上げに苦しんでいたと思うが、あれと同じような状況だ。
中国はどうかというと、日本と同様に設計ソフトは作れていない。
というよりGithubにそもそもないのでフォークするなど簡単には作れない。
Webやプログラミング関係だと書店にいけばあるが、半導体設計用のソフトに関しての和書はない。
最近のプログラミング関係の和書だと入門編で終わるのが多いが、中国では実際の設計の一連作業まで使い方を解説した書籍が存在する。
勉強しようにも勉強できない日本と、勉強しようとすればなんとかなる中国の差ではないだろうか。
簡単なCPUが作れるだけの書籍がある日本と、x86のクローンを作りかけの中国書との違いといえばいいだろうか。
最初からアメリカ製品を買ってきて作ることが当たり前になっていたので、国内計測機器メーカーにお金が流れが作れなかった。
書籍なども使い方までしかなく、計測機器を分解して中に入っている設計ノウハウについての解説はない。
アメリカだと設備に投資している。土地があるからというのもあるのだろうが設備が充実している。
また型落ちの設備も流通していることもあって、個人で所有している人もいる。
中国はというと、深センでわかるように、分解した部品が売られていたりする。
中堅SIerでいわゆるSEをやっている。中小企業や、大企業があっても部門システム程度のシステム導入や保守サポートが自分の仕事だ。オーダーメイドであればJavaやC#とOracleやMSSQLで開発するし、業務パッケージの導入支援なんかもする。規模が小さいから多重下請けみたいなのはほぼないが、PMだけとか仕様決めだけで、作成は外注頼みにして数回そうって、社内の技術空洞化が心配される普通のSI業だ。
IT業界の端くれらしく在宅リモートワークになった。お客さんは休業するところもあるにはあるが、多くはそのままだったり、営業時間を縮小したり、総務経理なんかをリモートにしたり、工夫しながら営業を続けている。チャット、メール、電話はそれなりに入ってくる。
例えば給与管理なら４月で雇用保険徴収の対象外になる人が出るけどどうすればいいの？みたいな季節モノから、自宅PCから会社PCにつないで/会社のノートを自宅において、あのシステム使える？とか、IT補助金出るみたいだけどPC10台調達できるか営業に伝えて、みたいなこの状況ならではの対応とか。出荷システムでピッキングがうまく行かないとか、普通の保守対応もたくさんある。
開発案件はストップや延期もちょいちょいあるけど、自宅から質問に答えたりリモートでトラブルシュートしたり営業やインフラ担当の手配をしたりなんのかんの忙しい。自分もお客さんも自社の営業やインフラSEもみんな在宅だったりするし普段とは違って変な感じだ。
いろんな企業のいろんな部署のいろんな人が働いていてITやソフトウェアに頼っているんだなとあらためて感じた。
Amazon楽天ヤフオクメルカリなんでもそうだが、今はみんながプラットフォーマーになりたがる。
商流を握れば手数料で儲けがスケールする。ITをコアにスケールする企業が生き残る。
でも、そこで流れる商品を作っているのはメーカーだし、調達して販売してるのは卸だし、在庫が置かれてるのは倉庫業だし、ものを運ぶのは運送会社だ。その他たくさんの業種。マケプレで僕らが買えるのはそうした企業があるからだ。
いろんな会社が、この状況下でも営業をしなけりゃ生活必需品が行き渡らない。
その大部分は中小企業で、ITはコアコンピタンスじゃない。高年収のフルスタックなITエンジニアを何人も抱えて内製化できない。情シスが何人かしかいなかったり、総務のお兄さん一人なんてところもある。そんな企業が日本だけで何十万とある。
そういうところに頼られて、なんか問題を解決して、支えていけるなら、喜ばれるんなら、SIerもそんなに悪くはないなと思ったりした。
会社の大先輩のおじいちゃんは、SAPが出てきたころにパッケージオーダーメイドなんてなくなると言われたけど、パッケージ導入や足りない部分の開発で結局食えたと言っていた。ならクラウド時代でもSaaSが主流になっても多分仕事は尽きないんだろうな。最悪自分がどっかの会社の情シスに潜り込んで内製に回れるような技術は身につけておきたいけども。
その１https://anond.hatelabo.jp/20200327214055
12 Dr. Hiroshi Nishiura is one of the few professionals of mathematical models of infectious diseases in Japan, and it is well known that his ability is outstanding. However, many people don't understand mathematical models themselves (I must confess that I can't say that I understand all of the findings because I'm not a professional of mathematical models either), so his findings and comments are easily deified. Because the contents of the mathematical model are a complete black box to many people, it makes it seem like the oracle is coming out like a shrine's oracle. Much of Japan's infection control policy relies on the Nishiura theory. So there is nothing wrong with that, but one of the problems in Japan is that there is no plan B in case plan A goes bust. Dr. Nishiura is an excellent scholar. It is not God. Hence the need to have that Plan B with the possibility of making a mistake. I am greatly concerned that bureaucrats and politicians who are prone to infallibilism will mistake science for an oracle. It is only when falsifiability is assured that science can continue to be scientific.
感想：おみくじと神託が同じoracleだったので変な文章になったが直していない。
13 数理モデルは演繹法の活用産物である。演繹法は帰納法やアブダクションで補完するのが、学問の基本であり、臨床医学の常識である。演繹法的にどんなに正しく見えても実はそれは違っていた、ということはこの業界ではよくあることなのだ。ヘーゲルやマルクスのような巨大な知性でも演繹法オンリーでは間違うのである。
Mathematical models are the product of deductive methods. The deductive method is complemented by the inductive or abduction method, which is the basis of scholarship and the common sense of clinical medicine. It's a common occurrence in this industry that no matter how deducibly correct it may seem, it's actually not true. Even a huge intellect like Hegel or Marx can make a mistake by deduction alone.
感想：「蓋を開けてみれば」を「実はそれは」に変更した。
14 モデルを使うな、といっているのでは決してない。ぼく自身、モデルを用いて論文を書く。しかし、モデルは無謬ではなく、そこには前提である仮定があり、仮定はしばしば間違っている。グラム染色を活用するとは、グラム染色にできないこと、分からないことを知悉していることであり、グラム染色万能論者にグラム染色は使えない。同じことだ。英国でも数理モデルは活用されているが、だからこそ英国人はその結語には非常に懐疑的で、常に反論、異論が起きている。健全で科学的な態度である。
I'm not saying don't use the model at all. I myself write a paper using a model. However, the model is not infallible, there are assumptions that are assumptions, and the assumptions are often wrong. Making use of Gram's stain means having full knowledge of what Gram's stain cannot do and does not understand, and Gram's stain cannot be used by Gram's stain universalists. It's the same thing. Mathematical models are also utilized in the UK, which is why Brits are very sceptical of their conclusions, and there are always counter-arguments and objections. It is a sound and scientific attitude.
感想：「前提たる仮定」がうまく訳せていなかったので「前提である仮定」にしたが、assumptions that are assumptionsになってしまった。
「英国人は」がないと主語がIになってしまったので追加した。しかしBritsじゃ意味違うよ。もっと正しく訳してくれない？
15 Japan's "now" is a well-controlled state of infection, which is much better than Wuhan at its worst, or Italy, Spain, France, England, or New York at the present time. The problem is that it doesn't guarantee that it will "always work".
16 懸念されるのは東京だ。感染報告が増えたことだけが問題なのではない。クラスターを形成できない、トレースできない感染者が増えているのが問題である。そして、その陽性患者数に比べて検査数がずっと少ない。47人の感染者を捕捉するために100人未満（陽性者の検査日が不明だが、おそらくこのへんだろう）しか検査していないのは少なすぎる。
It is Tokyo that is of concern. The increase in reports of infection is not the only problem. The problem is that more and more infected people are unable to form clusters and cannot be traced. And the number of tests is much lower than that number of positive cases; it's too little that they only tested less than 100 people (the date of testing for the positives is unknown, but it's probably around here) to capture 47 infected people.
Again, it's not necessary to figure out all the infected people. However, it is troubling that the flow of infection, movement and clusters are out of sight. Therefore, the threshold for testing must be lowered in Tokyo. The threshold for testing varies with the circumstances. That's what I explained with the Korean example. Sticking to the Ministry of Health, Labour and Welfare's "standards" will lead to a misunderstanding of the phenomenon itself. Already in the Kansai region, infected people have been found with taste and smell abnormalities, and clusters have been detected from there. I would like to make more use of the athletic sensibilities of these clinicians. I'm not sure "where" in Tokyo is the barrier to lowering the number of inspections, but that barrier needs to be removed immediately.
感想：「捕捉するのに」を「捕捉するために」に変更した。多分これでいいと思う。思いたい。
アスチュートがathleticになっているのはどう反応したらいいかわからない。
17 This conceptual diagram that everyone is looking at - lowering the peak of the infection and shifting it to the side. This is all a product of deduction, and I don't know if it's really true. As mentioned above, the UK estimates already suggest that this is not enough. It is possible that the damage that was shifted to the side could simply be "extra-long damage".
18 そして、ここが肝心なのだが、ピークを下げるという理念が、「ピークを下げなければいけない」という観念になり、「ピークは下がっているはずだ」という確信になり、「ピークは起きていないんだ」という自己暗示に転じてはいけないということだ。プランAに固執する日本あるあるの失敗のパターンで、ダイヤモンド・プリンセスでは「二次感染が起きてはいけない」が「起きているはずがない」に転じてノーガード下船を許してしまった。「ピークが起きてはいけない」が「ピークなんて見たくない」にならないように現実を見据える必要がある。たとえ、それが我々の見たくない不都合な真実であったとしても。
And this is the key point: the idea of lowering the peak should not become the notion that the peak must be lowered, or the belief that the peak must be lowered, or the self-implication that the peak is not happening. In a pattern of Japanese failure to stick to Plan A, Diamond Princess allowed no-guard disembarkation by changing "secondary infection should not occur" to "it can't have happened". We need to keep our eyes on reality so that "peak shouldn't happen" doesn't become "I don't want to see a peak. Even if it is an inconvenient truth that we don't want to see.
感想：mustが違う文脈で二回出てきている。よくわかるように変更したいものだ。
カギカッコがないとうまく訳せなかったので追加しているが、なぜかカッコ閉じるがいくつか抜けている。この箇所以外にも抜けがある。
19 Repeatedly. It's common knowledge in this industry that deductive methods are complemented by inductive methods. Nevertheless, PCR is often false-negative and has little power to determine the status of infection. That's why "testing everything" is so wrong. However, a serum test measuring immunoglobulin IgM and IgG would provide a more accurate picture of the "status of infection in the population. This, however, is not infallible. It is difficult to use for individual cases because it misses early infection, which is why it misses early HIV infection.Whether antibody testing is useful in individual cases remains to be tested, but it is well suited for epidemiological studies on a population basis. Roughly speaking, we can confirm whether the "infection is rampant" in Tokyo right now, or whether it's just an unfounded fear.
前例としては、ロンドンの血清検査で09年パンデミックインフルエンザが従来予測の10倍起きていたことが血清検査でわかっている。抗体検査はアウトブレイクのあとで事後的に行うことが多いが、慢性的パンデミックになりつつあるCOVID-19については、「今」こそが検証のポイントといって良い。
As a precedent, serology tests in London showed that the 2009 pandemic flu was 10 times more likely than previously predicted. Antibody testing is often performed after an outbreak, but now is a good time to examine COVID-19, which is becoming a chronic pandemic.
感想：「前例はあって」を「前例としては」に変えた。「前例はある。なおかつロンドンで〜１０倍起きていた」になってしまったからだ。
20 英国はさらにアグレッシブだ。家庭で抗体検査を行い、「感染者である」とわかればそれを自宅での自己隔離の根拠に使おうというのだ。ロックダウンが起きている中で、検査陰性は「自己隔離不要」を意味しないため、その戦略に欠陥はある。が、考え方としては「感染全体を抑え込みたい」というもので、検討の価値はあると思う。
The UK is even more aggressive. The idea is to test for antibodies at home, and if they are found to be infected, they will use it as a basis for self-isolation at home. That strategy is flawed because with the lockdown in place, a negative test does not mean "no self-sequestration". However, the idea is that we want to control the infection as a whole, and I think it is worth considering.
21 東京でどのくらいの感染が起きているか、帰納法的確認は必要であり、有用だ。その結果がどうなるかは預言者ではないぼくには分からない。が、どんな結果が出てきても、それを受け入れ、場合によっては自説を変えて、プランBに移行することにも躊躇しない態度が科学者には必要だ。科学者は、首尾一貫していないことにかけて、首尾一貫していなければならないのだ。形式においては首尾一貫していなくても、プリンシプルやプロフェッショナリズムにおいて一貫しなければならないのだ。事実に誠意を。
Inductive legal confirmation of how many infections are occurring in Tokyo is necessary and useful. I'm not a prophet, so I don't know what the outcome will be.However, no matter what the outcome, scientists need to accept it and not hesitate to change their thesis and move on to Plan B in some cases. Scientists have to be coherent in their inconsistencies.They may not be coherent in form, but they must be coherent in principles and professionalism. Good faith in the facts.
感想：首尾一貫という言葉を使いすぎて文章をアホっぽくしてしまったが他にいい方法が思いつかない。朝三暮四は理解してくれなかった。「自説を曲げ」は「自説を変えて」に変更した。
文章はもう少し整形できると思うがとりあえずこれで。
まつほろひとゆきが作った日本産のコンピューター言語。パールというコンピューター言語を元に作られていてWebサービスを作るためのフレームワークを搭載している。代表的なWebフレームワークはtDiary
C
デニス立地さんがNTTで開発した言語。マルチクスというOSを作成するために作られた。わざと複雑な言語仕様にすることで自分の役職ポジションを守ろうとしていたが、思った以上に世の中の人間はこの言語を使いこなしてしまい、超有名な言語になってしまった。スーファミのゲーム制作にさえ使えなほどの超高級言語
おまじないと呼ばれるプリプロセッサでの書き換えが必要な謎の文字列を埋め込む必要があったり、言語仕様に曖昧な部分も多く、同じソースなのに実行環境によって動きが異なる、欠陥言語である。(32bit向けプログラムが64bit環境で動作しないなど)
オブジェクト指向言語。すべてのオブジェクト指向言語はこいつから始まった。
主にWindows上で動作するゲームを作るための言語。今ではUnityとか色々なゲーム開発の環境とかあるが、結局はパフォーマンスとか考えたらC++使うことになる。
代表作はOpenGL、DirectX、Window10、LibreOffice など
JavaScriptから派生した言語。読み方は(ジャワ。ジャワ島のジャワ。)。もともとはOracleの創始者の博士が趣味で作成して、現在のOracleデータベースの基礎となるテクノロジー。アプレットという実行するための専用プログラムをインストールしないと、Javaで作ったプログラム(.classファイル)は動作しない。マークはコーヒーだと思われがちだが、紅茶(ジャワティー)である。
アンドロイドOSを作成するためにも使われており、アンドロイドのOSカーネルはJavaで制御されている。そのため定期的にGCが走るので、アンドロイド端末は定期的に動作を停止することがある(いわゆるプチフリーズ)。
対策するためにはGC戦略を見直してヒープ領域のサイズやメモリに乗せるキャッシュのサイズなどの調整が必要であるが、げんざいのGoogleにはこれらを調整する人員はすでにいない。
このように業務用データベースから携帯電話まで幅広く使われているので、Javaの技術があっても市場価値は殆どないと言われている。(みんな使えて当たり前)
晩年政界への進出を目論んでいた松下幸之助が、未来社会を見据えて開発した言語。主にWebアプリケーションを作成するために使われている。PはパナソニックのP。を略してPHP
かんたんにシェルコマンドを実行できたり、クエリストリングに代入した値を直接グローバルで評価できたりするなど、洗練されていてとても便利な言語である。
HTMLやメール本文の中にもPHPの処理を書き込むことができる。
この世のすべてのサーバーに実行環境が存在するので、PHPのコードさえあれば、コンパイルも不要でどのような環境でも動作する。
C言語の100倍生産性が高く、Wikipedia、Facebook、Slackなどの超一流のサイトやサービスで大量のアクセスを捌いている。
WardPressと呼ばれるフレームワーク(全世界のWebサイトの3分の1以上はWardPressで作成されている)を作成している言語であり、この言語なくして今のWebは存在していない。
データベースとも親和性がある、などと言われることもあるが特に根拠はない。
韓国人棋士を倒したAIに特化したプログラム言語。Googleが開発しており、もともとはDartという名前だったが、汚いという理由でなまえがGoに変わった。そのため現在はDartという言語は存在していない。
AIに特化しているというだけあり、低レイヤむけの実行ファイルを作成する必要があるため、コンパイルが必要ではあるが、だいたいどの環境向けのバイナリも生成することができる。
デフォルトでディープラーニングを使うための機能を持っていたり、プログラムを並列実行するための機能が備わっているので、コア数の多い環境で高速に動くプログラムを作りやすい。
JavaScript
Javaの元になったプロトタイプベースのオブジェクト指向言語。読み方はジャワエスクリプト。W3Mというブラウザの上でインタラクティブにWebサイトを動かすために作成された言語。もともとブラウザの上で動くための言語だったが、後にSafariブラウザに搭載されていたV6エンジンというJavaScript言語の実行エンジンを分離してNPMというJavaScriptを直接実行できる環境となった。
それ以降JavaScriptはブラウザ以外にVRゴーグルの中などで動くようになった。
並列プログラミングが不可能な作りのため、コールバックを多用して、スパゲッティーコードを量産することができる。
NPMを使う奴らは、JSがブラウザ環境で使われる言語であることを全然考えてないため、WebpackとかBabelといった謎の開発環境をシコシコ積み上げている。いつかその塔は爆発し崩れ去ることになるであろう。
Javaと同じくJavaScriptから派生した言語。Javaとは互換性は無いが、JavaScriptの上位互換があるため、JavaScriptのコードをそのまま実行することができる。
$マークから始まる命令のみで構成されているとても縁起のいいプログラミング言語。おもにパララックスなどを実現するために利用されていて、WardPressなどのドライバとしても使われている。
JavaScriptの改良版であり、現在JavaScriptと言われているプログラム言語の99%はjQueryのことである。そのため現在慣習的にJavaScriptと呼ばれているもののほぼ全てはjQueryである。
jQueryを覚えればJavaScriptは覚えなくても良い。などと言われるが、正確にはjQueryを覚えた頃にはJavaScriptも覚えている。というのが正確である。
JavaやjQueryなどと同じくJavaScriptから派生した言語。Microsoftが開発した関数型言語。開発時はF#(エフシャープ)というコードネームだった。
型に特化した言語であり、Microsoft製のVSCodeというIDE環境でしか開発、実行が出来ない。(ただしMacやLinux上でも動作可能)
TypeScriptを動かすにはサーバーにVSCodeもインストールする必要があり、言語やIDEのバージョンアップも多いため、メンテナスンスが困難である。
前進となるObjectiv-Cという言語が、気持ち悪い構文であったため開発者が不足しており、このままではOSのメンテナンスもままならない、という理由で最初のバージョンがわずか14日間で作られた言語。
Oracleなどのミドルウエアやdump解析やRAC構成相談も含めたテクニカルサポートだったけど、
↑ こういう成功例を間近で見たので、あらゆることはやる気の問題だと認識していたし
上記のクソ有能な管理者ほどではないけれど、自分自身もベンチャーや小規模組織で成功経験を積んだのでそれが当たり前だと最近まで認識していたけれど
どうも「当たり前」じゃないことに最近気づいたよ
ベンチャーで新規事業や業務への気軽な参加や社外の勉強会に業務として好きに参加出来る仕組みを作ったけど
ベンチャーですら全員はそれを喜ばなかったし(数字を預かる人や役員の小言／愚痴ではない)
グダグダしている組織に至っては完全に余計なことでしか無かったよ
出来ることが増えることは彼／彼女らにとって嬉しいことでもなんでもなく
ただひたすらに余計なことなのだ
この件⇒ https://togetter.com/li/1452558
ユニケージはbashのパイプで作られた、RDBMSを使わずテキストファイルによる空白区切り行志向レコードへのデータ処理（だいたいプログラム1本の処理内容がメインフレームのCOBOLのそれと同じくSQLクエリ1個に相当する）で、同形式によるマスタとトランザクションファイル（RDBMS内部のredoログに相当）を使う（データに含まれる空白文字0x20はアンダーバー0x5Fに置換する、アンダーバーが複数存在するデータの場合どう扱うかは知らない）
開発と更新は早いんだけど参照が（テキストファイルなので）インデクスが効かないためシャーディングするしかなく、要するに検索機能の柔軟性がなく、リアルタイム性を損なう
おそらく基幹系というか在庫管理をユニケージでやっているので、ウェブサイト自体はユニケージで実装されていないかもしれないけど、しかし根幹に上記のような手作りのデータベース実装があるし、RDBMSに移行するとなると全部を止めてマスタとトランザクションファイルをマージしてインポートすることになる
追記：トランザクションファイルのマスタへのマージは営業時間後の日次バッチとかでやるはず
システムを止めている間も店舗が運営を続けているなら、たとえば店頭在庫を潤沢に積んだうえで、店舗間での在庫の融通は禁止し、店頭での売り上げ分はどこかでRDBMSに計上しなければならない
追記：テキストファイルに対するインデクスをつくって行頭へのシークの高速化をすること自体はもちろん一般的には可能だけど、ユニケージの方法論だとそれをする標準的な方法はないはず。ユニケージはRDBでもNoSQLでもなく、バイト位置でのシークという操作自体がない世界なので。sedとかで行の差し替えをした場合（SQLのUPDATE相当）当然行頭のバイト位置が変更した行以降ですべてずれてしまう可能性があるのでインデクスの更新がひどく非効率になる
追記：文章下手ですみません。ユニケージの良いところはRDBMSの実装の基礎を理解できるところ（これはDate先生の教科書を読んだりOracle Silverの勉強をしたりSQLの書き方を工夫したりクエリプランを読んだりするよりずっと効率的に学べる、ただしファイル編成法の知識はちゃんとした教科書で補う必要がある）、アプリケーション実装技術について横断的な理解ができるところだと思います（USP研究所のシェルスクリプトマガジンには実際勉強になりそうな記事が多い）自分はユニケージへの移行案件を生き残れなかったクチなので。。
追記：Tsukubaiは好きになれませんでした。
