  |
はてなキーワード: Vmとは
まあVMWorldとかで10年以上人生の春を謳歌してきたからもう十分やろ
お疲れさん
～VMwareが提案する、DRにも対応するマルチクラウドソリューション～
昨今のCOVID-19流行への対応やDXを推進する中で、クラウドサービスの利用はビジネススピードの加速や柔軟なシステム運用に効果的であり、従来のオンプレミス環境と併用するハイブリッド環境や、複数のクラウドを利用するマルチクラウド環境が増えている。一方で、これらの環境を維持していくには課題も多く、セキュリティリスクも増大してしまう。ここでは、こうした課題を解決するVMwareのソリューションを紹介する。
COVID-19流行への対応やDX（デジタルトランスフォーメーション）のためのビジネス変革が進む中で、ビジネススピードの向上やニーズに対する迅速で柔軟な対応がこれまでになく求められている。これらを実現するために、アプリケーションの変革やクラウドへの移行が加速している。
多くの企業が、「ビジネスのスピードに対応できるモダンアプリケーション」や、「あらゆるクラウド、データセンター、エッジでビルドおよび実行が可能であること」、「エンタープライズクラスのレジリエンス、セキュリティ、運用の実現とビジネス変革」がDXを実現するために必要であると考え、これらを実現するためにマルチクラウド環境の活用が前提になってきている。
具体的には、Amazon Web Services(AWS)、Microsoft Azure(Azure)、Google Cloud Platform(GCP)といった複数のパブリッククラウドサービスを併用し、適材適所で使い分けているのが現状であろう。しかし、マルチクラウド環境では解決が必要な課題が存在する。その課題とは、「ワークロードのシームレスな移行・連携」、「クラウドごとのスキル習得」、「運用管理の簡素化」、「セキュリティリスクの低減」、「最適なコスト管理」の5つである。この5つがクラウド利用の理想と現実のギャップとなっており、これらを意識して進めていく必要がある。
特にマルチクラウド環境を適材適所で使う場合、クラウドごとに利用する技術が異なるため、設定項目や内容に違いがあり、その設定ミスによるインシデントも発生している。重大な影響を及ぼす場合もあるため、それぞれのクラウドを扱う際のスキルが重要になる。
こうしたマルチクラウド環境における課題を解決するには、一貫性のあるクラウドインフラストラクチャ、および運用管理サービスが重要なポイントとなる。例えばVMwareは、複数のパブリッククラウドだけでなくオンプレミスを含むハイブリッドクラウド環境においても、仮想的なレイヤーを構築することで管理や運用を一元化している。
VMware Cloud on AWSは、VMwareとAWSが共同で開発したもので、AWSのベアメタルサーバー上にvSphere、NSX、vSAN、vCenterを導入し、ホスト専有型のクラウドサービスとして提供するものだ。
その特長は3つある。1点目は「VMware製品をベースとしたクラウド」であること。VMware製品で仮想化されているため、AWSの世界にいながらオンプレミス環境で利用していたスキルセットや運用管理ツールを利用でき、新たなスキルを習得する必要がない。
2点目は「シームレスにクラウドに移行できる」こと。ワークロードをオンプレミス環境から無停止で移行することができる。アプリケーションを更改する必要もないため、クラウドに移行する時間やコスト、リスクを大幅に削減することが可能だ。
3点目は「VMwareが管理を行う」こと。ハードウェアやソフトウェアのトラブル対応や運用管理、メンテナンス対応など、すべてサービスの中でVMwareが実施する。3カ月に一回の頻度で新しいリリースを提供しており、ユーザーの要件を反映しながら新たな機能を追加している。
最近のアップデートの大きなものとして、日本で第2のリージョンとなる大阪リージョンを設置し、サービス提供を開始したことが挙げられる。例えば西日本地区でデータセンターを持つユーザーは、より低遅延でサービスを利用できるようになった。昨今は感染症の流行や地震の発生などによってBCPを見直すユーザーが増え、VMware Cloud on AWSをリカバリサイトとして利用するケースも増えている。その意味でも、大阪リージョンは活用度が高いといえる。
VMware Cloud on AWSが選ばれる理由は、大きく3つ挙げられる。1点目が既存のノウハウや運用管理手法をそのまま踏襲できるという点。VMware製品をベースとしたクラウドサービスであるため、オンプレミス環境における管理者のスキルや運用ノウハウなど、既存の資産をそのままクラウド上でも活用でき、新たなスキルの習得や、運用管理手法の大きな変更の必要もない。クラウドとオンプレミス環境をvCenterから一元管理できる。
2点目が、規模に依存しないシンプルなクラウド移行を実現できる点。ワークロードをそのままクラウドへ簡単に移行することが可能だ。VMware Cloud on AWSには標準でVMware HCXが含まれ、これはオンプレミスのデータセンターとクラウド間のネットワークをL2延伸する。ネットワークがつながった環境で仮想化環境、VMをそのままマイグレーションできる。アプリケーションやIPアドレスを変更することなく、無停止でワークロードを移行することができる。
3点目が、モダナイゼーションを推進して、ユーザーのDXの加速を支援できる点。まず、クラウドならではのインフラストラクチャとして、1顧客あたり最小2ホストから最大640ホストまで拡張できるが、俊敏性を兼ね備えて提供される。例えば、ホストの展開に1時間半程度、ホスト数を追加するのに15分程度と、オンプレミス環境ではありえないスピード感で環境を構築、提供される。
また、リソースを最適化する機能も提供される。ユーザーのリソースの使用状況に応じて、利用するホストの台数を自動的に増減させて最適化する。さらに、名前の通りにAWSが提供する各種サービスとの親和性が非常に高いことも特長。VMware Cloud ENIと呼ばれる専用のインタフェースを経由して接続することで、低遅延で高速な環境を利用して各種のAWSのサービスとシームレスに連携することができる。この面も同サービスの大きな強みとなっている。
最近では、VMwareが提供するKubernetesディストリビューションであるVMware TanzuをVMware Cloud on AWS上で稼働させることが可能になった。これにより、短時間でコンテナ、Kubernetes環境が導入できるようになる一方で、ハードウェア、ソフトウェアの管理はすべてVMwareが行うため、管理者はKubernetes環境に集中できる。
VMware Cloud on AWSのユースケースには、主に「オンプレミス環境のクラウド移行」、「データセンターの拡張」、「災害対策サイト」、「次世代アプリケーションのプラットフォーム」の4つが多い。特に最近は、災害対策としての利用が増えているという。VMware Cloud on AWSをリカバリサイトとして活用する際に強力なサービスとなるのがVMware Cloud Disaster Recoveryだ。
VMware Cloud Disaster Recoveryを利用すると、平常時には本番サイトのデータをクラウド上のストレージ領域にレプリケーションしておき、万一DRイベントが発生した際に初めてVMware Cloud on AWS上にホストを展開し、保護していた仮想化環境をフェイルオーバーする。リカバリサイトとしてあらかじめ物理的なサイトを構築しておく必要がないため、大規模な初期投資が不要となる。
VMware Cloud Disaster Recoveryの特長
このタイプはオンデマンド展開型と呼ばれ、DRイベント時にホストを展開したタイミングでリカバリサイトに対する課金が開始される。復旧後に仮想化環境を本番サイトに戻すことで、ワークロードもフェイルバックでき、不要となったリカバリサイトのリソースも削除され課金も停止される。なお、オンデマンド展開型のほかに、事前にホストを展開しておく事前展開型も用意されており、RTOを重視する場合には事前展開型が推奨される
また同サービスは、最近話題になっているランサムウェアへの対策にも有効だ。クラウドストレージ上に本番環境のデータをバックアップする際には、リカバリポイントを長期的に保持することが可能である。このため、ランサムウェア攻撃に遭ってしまった場合、その直前の時点からリストアすることが可能となる。
マルチクラウド環境を可視化するVMware vRealize Cloud
マルチクラウド環境では、各クラウドが複雑化し、サイロ化してしまう可能性がある。クラウドごとに管理ツールや必要とされるスキル、ノウハウも異なるため、利用するクラウドが増えるほど複雑化、サイロ化の問題が大きくなり、その結果セキュリティリスクやコストが増加してしまう。そこで有効な解決策となるのが、クラウド環境をまたがって一貫性のある運用・管理を実現できるVMware vRealize Cloudである。
まず、VMware vRealize Operations Cloudは、VMware Cloud on AWSのリソースだけでなく、他のパブリッククラウド上のリソースも一元管理できる。複数クラウドの環境にまたがってデータを収集、分析評価を行うことで、例えば常にパワーオフ状態の仮想化環境や、実体がない状態のディスクなどを検知された場合に最適化していくことが可能。これにより、最終的にコストの最適化も図ることができる。
コストや運用を最適化できるVMware vRealize Cloud
また、VMware vRealize Log Insight Cloudによって、複数のクラウドを横断してログを管理できる。例えば、監視対象のイベント通知をあらかじめ定義しておくことで、不正な行動を検知した際には管理者に通知し、適切な調査と対応を行うことができる。セキュリティやコンプライアンスの強化にも有効だ。
さらに、クラウド間のネットワークの可視化は、VMware vRealize Network Insight Cloudで実現できる。End to Endを含むネットワーク全体を可視化できるため、ネットワークに関するトラブルシューティングや、不審な通信を洗い出すこともできる。また、アプリケーションの通信も把握できるため、アプリケーションの移行計画にも活用できる。
今後、DXの推進を加速していく上で、必ずしもひとつの環境、ひとつのクラウドを利用するのではなく、マルチクラウド環境の利用が当たり前になっていくと考えられる。そこで直面する前述の5つの課題に対し、VMware Cloud on AWSそしてVMware vRealize Cloudの活用は課題を解決するだけでなく将来への有効な投資となる。企業規模や業種に関係なく検討すべきソリューションといえるだろう。
少し前にmacOSはLinuxではないとTwitterで話題になりました。その際に
といった内容のTweetを見かけたのですが「元になったのはBSDではなくMachなんだけどな～。昔を懐かしみつつ、調べながら何か書くか」と思いつつ、面倒になったので記憶のまま適当に書くことにしました。
Machは当時一世を風靡していたマイクロカーネル設計を採用したOSで、BSDとは全く違うOSです。
ただしBSD互換機能を利用していたユーザーは、内部に関心が無ければ
といった印象を持っていたのではないでしょうか。互換機能としては成功なのですが。
macOSのもとになったNeXTSTEPはMachを改造して始まりましたが、現在では別物であると考えるべきです。
macOSは直接にはMachから派生したもので、BSDではありません。ただし
など、BSDと誤解させる点があるのは確かです。
上記のUnix → BSD → Mach → NeXTSTEP → macOSではソースコードを利用しながらOSを作って行ったため共通の部分がありますが、これらとは全く関係無く独立して開発されたものです。
しかし現状ではNode.jsやPythonなどでプログラムを作ろうとした場合にシェルで使うコマンドはmacOSとLinuxでは共通するものも多く
ごめん「障害点が増える」「難易度が上がる」って言ったほうがよかったわ
まさかここでそのあたりまでツッコめる人いないだろうと思ってたんでｗ
多重化をすれば回避できるのはソフトだろうがハードだろうが当たり前のことだけど、
ハードウエアであることによる発見の困難さ、ってのはSDSより難易度が上がるからね
OSを積んでるRAIDカードってのは初めて知ったけどｗ、そんな何百万もするハードはレアな運用になるし、
RHEL・MS・HCIメーカー提供のSDSより圧倒的に情報も少ないからね
ベンダーに言われるままにハード入れて某銀行のようなことが起きる
SDS万能って言ってるわけじゃないけどね
物理的なモノが増えればそれだけ厄介が増えるよて話よね
今やiPhoneを始めとしたスマホカメラの方が性能が良い場合も多いのだが
一眼レフに馬鹿デカいレンズを付けてる方が良い写真が撮れると信じている人が多い
特にバズーカと呼ばれる望遠でF値の低いレンズを買ってはわざわざ興味も無い飛行機を撮りに空港へ行く理系男子は多い
ちなみにその手の望遠レンズはエクステンダーを使うことで更に焦点距離を伸ばすためにF値が低い
エクステンダーを付けることでより望遠になるが、明るさを下げることになるからだ
望遠と超望遠の2本を持ち歩くのが面倒かつ高価なのでエクステンダーを使うような、ネイチャー系の人が使う
わざわざ夕方以降の暗い空港で飛行機を撮るために作られてるわけではない
当然、明るいレンズは写りが良くなるわけでは無いし、そもそも絞って使う
他にもフルサイズ信仰やキヤノン・ニコンの無意味な闘争などキリが無い
という人でもULTRA HDでハイレゾなヘッドホンを使ってる人が多い
人間の可聴域を超えた音を感じ取れると主張する
AACの256kbpsで十分すぎるほどに再現出来ているはずなのだが違いが分かるそうだ
まぁ若い人が聞き比べればもしかしたら分かるのかもしれないが、そもそも聞き比べなければ良い
そして30歳を過ぎたら自分の耳に自信を持たない方が良い
豆の種類、産地、精製処理、焙煎度合い、淹れ方、エスプレッソ、ラテアート、などなど
一番こじらせてるのは自分で焙煎・手挽き・ネルドリップとかやってる人だ
Youtubeで見つけることができたりする ただしこちらの深淵も覗かない方が良い
個人事業主で何かサービスを始めるわけでもないのに自宅ラックをやってる人からは距離を取ろう
自宅ラックを運用することで技能習得できるとかいう謎理論をかざすが、自宅の庭にSASUKEを作る人と大差ないことに気付いてない
サーバならVMやクラウドで良いし、ルータ・スイッチもシミュレータで良い
そもそも最近のルータはCISCOじゃないことも多いし独自コマンドが多いので実際に使い始めてからマニュアルを読めば良いし、それで間に合うような技能を付ければ良い
データセンターの近くに住むことで低遅延だという主張も多いが光は1kmを5マイクロ秒で進むという事実からは目を背けている
何故か？筋肉が付いてない人がエセ科学を主張しても誰も信用しない
万人に共通するとは限らないがその人には少なくとも効果があったということは外から見て分かる大きな事実だ
アホは田舎の小金持ちと一緒にきゃっきゃ愛国ごっこを出来たら満足で
つか、日本よりも社会活動家が武闘派で日本よりも公正な欧米でも
年がら年中、ITを始めるのは遅すぎるか？とか増田でやってるので
何歳からのチャレンジも遅く無いの増田で引用したblogの人は
日立でめっちゃ社歴が長かったシニア・マネージャーだったみたいだぞ
その経験を持ってなお、手を動かせれば職はあるかなぁ程度の様だ
💻 56歳のプログラミング初心者 💻 としての自分を完全に受け容れられるようになる前の私は、
クリティカル・インナー・セルフ（内なる自分）と上手く付き合わなければならなかった 🙄
内なる自分：なんでこの年でプログラミングの勉強を始めたんだい？
わたし ：本当に言いたいのは、あとどれくらい生きられるのか？
そして、プログラミングで稼げるだけの時間が本当に残っているのか、だろ？
わたしはアメリカ人だから平均寿命は 78.8 歳だ。とするとまだ 22.8 年生きる可能性が高い。
20歳の人間からするとそんなに長いとは思えないだろうけど、わたしは56歳でストリートで踊れるくらい元気だ。
内なる自分：すべてのテック企業は大学を出たてのガキを雇いたがるものじゃないの？
わたし ：それは大した問題じゃないな。わたしはシリコンバレーに住みたくもないし、巨大なテック企業で働くつもりもないから。
内なる自分：今やってること全てが時間の無駄ではないと言い切れる？
わたし ：本当はこう聞きたいんだろう？
「もしプログラミングを学んだ後でフルタイムの給料をもらえなかったらどうするつもりなのか？」と。
わたしの答えはこうだ。
「だから何だ？」
ーーーーーーーーーー
【原文】[Next Avenue] VM Vaughn - 56 and Learning to Code
https://www.nextavenue.org/learning-code-56/
【日本語訳】[Medium] 56歳からコードを書き始めて食べていく方法
「やめとけ」と叫び続ける内なる自分とひたすら言い争ってみました
https://medium.com/japan/i-am-learning-to-code-at56-37054b5dc8ce
そんなこんなで、組織に向いていようがいまいが全力で組織にしがみつく方針は維持しつつも(外資か公的な仕事になるだろうな)、
その時に日本がみんな貧乏だったら中国か新興国相手のビジネスをしなきゃならない
https://anond.hatelabo.jp/20210610184501
文面からおそらく弊社の、しかも関わりのある事業部なのだろうと想像した。そういう意味ではまずは今までご苦労様。
まず自己紹介からしよう。私は主に公共向けのSEをしている部長相当職（社内ではある固有名詞で呼ばれている）だ。社内の製品は一通り把握している自負はあるので、よっぽどマイナーなものでなければおそらく君のところの製品も触ったのではないだろうか。
開発に必要があるなら申請を出せば普通に入手できるし、Gitも普通に使っている。正直なことを言おう。そんな小さいことで辞めたのか？と思ってしまった。35歳で主任（これもある固有名詞で呼ばれてたんじゃないか？）ということはそもそも開発者なんてフェーズはとっくに過ぎてマネージメントを任される頃のはず。これはたとえ製品開発の事業部だったとしてもそんなに変わらない。それなのにその視座の低さがとても気になったよ。概して若いコーダーは顧客のメリットが0であるような単なる自己満足としてGithubの利用やDockerを使いたがるが、悪いけどそのまま大人になってしまった感じを受けた。開発環境の優劣というのはそんな低レベルな話ではなく、上流工程での品質の作り込みがしっかり行われているかとか、品質管理のKPIがしっかりされており、そのKPIに対するPDCAが回っているかとか、人月単価を適正に管理し競争力のある製品を作る予算管理ができているかといったことのほうがよっぽど重要。
弊社はあくまでも「ものづくり」「エンジニアリング」の会社であって、「コーダー」の会社ではない。そのためDockerだのGithubだのMavenだのといった要素技術に対してそんなに価値を認めてないんだよね。もちろんそういった技術で儲けようとしているWeb系の企業がたくさんあるけれど、年収を比べてみれば結局どっちの市場評価が高いのか、よくわかるんじゃないかな。「ものづくり」で大事なのはあくまでも顧客の要求を満たすことで、それはDockerだのGithubだのMavenだのを使うことととは次元の違う話だし、市場価値が高いところにコミットしてそうでないところを適正に管理しているからこそその年収が出せるものだと思ったほうがいい。今の年収と同じ水準でモダン 笑な環境に転職したじゃないかと反論されそうだが、転職市場は前職の年収ベースになるので結局君の実力ではなく弊社の実力が評価されただけなんだよね。そこは謙虚になったほうがいいと思う。
まずシステム開発は「ものづくり」ということが見えていない。「ものづくり」というのは単にコードを書くというだけでない（君はそこにフォーカスしすぎて、その環境の悪さだけが目についたように見えた）。市場の要求に対して適切に答えてるのが命題であり、技術は単なる手段ということを忘れてはいけない。プログラミングというのは手段である技術のたった一要素に過ぎない。そういう徹底的な顧客志向を日本のメーカーは長いことやってきており、高い生産性を実現してきたし、社員にもその精神を学んでほしいという一心でビジネスを動かしている。だが、最近のIT系企業は「ものづくり」ではなく技術を目的にしているところが多いよね。MacやGithubとか言ってる層は特にその気が強いと思うのだが、君は結局そこに行ってしまったようだ。
以上を踏まえておじさんから一つだけアドバイス。今のWeb系がやっていることは所詮大昔の技術を再発明しているだけであり、本質的に価値が薄いということ自覚した上で本当に顧客が欲しい物を作るということを忘れないでほしい。例えばDockerなんて大昔からLinuxが持っている機能の寄せ集めだし、Gihubなんて本質的にはファイル名に日付を管理するのと変わらない。弊社に関して言うと、AWSなんていってるけど所詮VMだし、弊社はハードウェアレベルでより高い技術を持っている。AI企業は専用AIを個別案件ごとに作っているが、弊社は汎用AIを世界で初めて開発した。でもそれらを積極的に宣伝はしていない。なぜか？それらは単なる手段だから。むしろお客様へのソリューションという形で宣伝していて、結局顧客のビジネスにフォーカスしているんだよね。だからこそ利益が出せ、年収も高いというわけ。なので、再度いうが、本当に顧客が欲しい物を作るということを忘れないでほしい。
3年前、世間一般にはメーカー系SIerとして知られている会社を退職した。ただ俺のポジションはパッケージソフト開発であり純粋なSIerとは異なる。
客ともSEとも会話せず、ひたすらドキュメントとプログラムを書く部署だ。といっても別にペーペーではなく主任クラスであり、
会社の業績がとてもよかったこともあり年収は1000万弱はあった。35歳。
これだけ見るととてもいい待遇に見えるだろう。でも耐えられないことがいっぱいあった。
Linuxで動くアプリなのにVMを動かすのも苦労する8GBしかメモリのないWindows PC、紙にコードを印刷して説明しないと納得しない品質保証部、
手作業で実施しExcelにチェックを付けていくテスト、jquery一つ使うのに3ヶ月かかる承認フロー、開発中にバグを一つ出すごとに
ひたすら反省文を求める品質保証部と一緒になって詰めてくるマネージャー、常にコンパイルできないtrunk、
Java 5の時代から進化しないコード、使いにくい社内ミドルウェアの利用を強制される設計、開発期間の半分以上を占める最上流設計、
一旦書いたコードは消してはならずコメントアウトしないといけないコーディング規約など、数を上げればきりがない。
色々改善活動を頑張ったものの、結局Subversionの導入も品質保証部がついていけないから、ということでClearCaseといわれる
今ではほぼ誰も使ってないであろうバージョン管理ツールが使われ続けることになった。使いにくい社内ミドルウェアは
研究所がその道のプロと聞いたので一緒に改善を図った。そしたらRubyしか書いたことがない文系新卒の子が出てきた。
一応研究所の人だし…と思って新バージョンのプロトの開発を依頼したら、1分以上稼働できない状態になって出てきた。
研究開発は準委任相当なのでそれ以上修正を依頼できずに期間が終わった。
また前の会社独特の文化として、大きなバグを出した開発者の反省会（社内ではとある固有名詞で呼ばれている）があった。
この反省会のターゲットになった開発チームはその資料準備で開発が1〜3ヶ月ほど止まるほど大掛かりなイベントだ。
このとき、担当の品質保証部は「連帯責任だから」という理由で資料レビューに大変な精を出す。余計なお世話だ。
このため10〜20ページほどの資料を毎週レビューにかけて最高のものにしていく。でも結局本番では幹部からの怒号が飛んで終わりである。
連帯責任とかいっていた品質保証部は幹部と一緒になって詰めてくる。連帯責任ではなかったのか。
幹部によると、この反省会があるから今の会社があるんだそう。これを経験して一人前らしい。
こんな感じで開発の体制はひどかったが、世間一般ではホワイト企業と見られている通り有休は取りやすかった。
そのため、転職活動を始めた。そしたらなんと「メモリ32GBのマシン」「mavenが気兼ねなく使える回線」「自動テスト」
「GitHub」「CI/CD」 という発言がポンポン出てくる。メルカリだのGoogleだのといったイケイケWeb系ではなく、
いわゆるSIerでもだ。最初は何だこの格差はと思ったが、まぁ営業トークなんだろうな、と思い直した。というわけで
イケイケWeb系も内定は出たものの、つい安定をとってしまい某大企業のDX系の部署に転職した。
そしたら何だこれは。最高スペックのMacBook ProからGitHubにpushするだけで自動デプロイで即サービスイン、
問題が発生したら社用携帯に通知が飛んできて、クラウド監視サービスでログをチェック、即修正即デプロイ。
社内の連絡はSlackで、スタンプを押せばIssueがたち即関連部署が対応に走る。OfficeツールはGoogle Docsで、
計算表はちゃんと表として使っている。開発者はちゃんと開発をしており、反省会の準備や品質保証部の接待なんて業務はなく
純粋にエンドユーザーだけを見ている。ここはなんて最高の環境なんだと歓喜した。また個人的にはおまけ程度であるが、
年収は30万ほど増えて大台に乗った。
さて、それから3年がたった。人間というのはいい環境になれると対して喜びを感じなくなる、というのはそうだと思う。
今では別にdeployブランチにマージされたらCIが走って自動でテストが走りデプロイされるのも、だから何？
って感じだしまぁ普通の仕事として淡々とやっている感じはする。待遇面で悪化した点もちらほらあるし
（例えば年間休日が5日ぐらい減った、残業が月5時間ぐらい増えたなど）などもある。
ただ一つ言えることは前の会社には戻れないな…ということである。人間一度生活レベルを上げてしまうと下げるのは
ただ、一つだけ今の会社に転職してよかったと感じ続けられることが一つある。それは人だ。
前の会社では家でプログラムを書いているなんていった日にはおちょくられたり、人生楽しいの的な目で見られたりした。
芸能人とゴルフの話ができないとコミュ障扱いされた。そのため仕事の話はしても、飲み会にはできるだけ行きたくなかった。
でも今の会社では雑談としてFastlyが落ちても大丈夫なCDN構想とか、AtCoderの話をして盛り上がることができる。
ダイバーシティなんていうが、人間は所詮同質な人間同士で集まったほうが快適なんだな・・・という複雑な思いを抱いている。
皆さん読んでくれてありがとうございます。いくつか質問が出ているので答えられる範囲で答えます。
真面目な疑問なんだけど、Java5のコード書いてる人を1000万で雇う会社があるの？どういうモチベーション？？
製品自体が90年代から脈々とバージョンアップしている企業向けのソフトウェアなので、コードベースが古いというのがあります。
またユーザーからすると中身がJava17だろうがJava5だろうが関係ないわけで、要は業務が滞りなく進めばよいわけです。
そのため昔から受け継がれたスパゲッティコードを地道に解き明かし、新しく出てきた要件を今までのコードベースを壊さずにバグなしで追加していく、
もとからあったバグについては、その他の数百万行のユニットテストもないコードに影響なしで修正を施す、といった技能が必要になります。
こう考えると意外と希少なスキルなんだな・・・と思えるかもしれません。
clearcaseよりもsubversionの方が100億倍導入も運用も簡単だと思うんだけど品管どうなってんの？
ClearCaseご存知な方がいるんですね！一から作る製品だとSubversionのほうが簡単かもしれません。ただ、ClearCase専用の
社内ツールがいくつかあり、そのツールで出力した情報を社内資産として持っているという理由があったりします。
例えばお客さんから「この機能がバグってるっぽい」というクレームを受けた際、その機能周辺の情報をそのツールから検索し、
コードレベルで再発防止策を関係部署総出で練った上でお客さんに回答する、という運用フローになっています。
そのため、Subversionに変えるためには開発陣の一存では無理で、品質保証部やマネージャー層など全ての知識のアップデートが
必要になり、そこまでコストをかけて説得して回る必要はあるのか・・・という話になってしまうわけです。
ただ、社内の生産性を向上させるのが目的の部署としてはSubversionやGitを社内に浸透させたがっているのも事実で、
新規プロダクトなんかはGitを使っていました。ただしGitHubはプロキシでアク禁されているだけでなく、サービス名名指しで使用禁止
になっているので、相当の理由がない限り使えないかと思います。
主任クラスでも1000万円近くもらえるのか。すごい。
1000万という数字に興味のある方が多かったので参考までに書いておくと、等級ランクというものが存在して管理職を除く最上位のランクに
なると2人の子持ち、賃貸住まい、標準評価で大体900万になるという感じです。年功序列だが部署ごとに違うというイメージで、
研究所だと20代で到達する一方、利益を上げていない事業部や間接部署だと定年間際まで到達しない人も多い、ぐらいの感じです。
平均では30代中盤ぐらいでしょうか。
ちなみに私の場合は基本給は33万程度ですが、そこに裁量労働手当と住宅手当、家族手当がついて月給で50万を超えるぐらいでした。
ボーナスは個人評価よりも部門業績に大きく左右されるのですが、部署が最高評価の場合は夏冬とも150万以上でした。
最後の最後のダイバーシティについては、ダイバーシティを勘違いしているように思う
cat filename.jurina
print "Hello world";
public class filename{
public static void main(String[] args){
System.out.println("Hello world");
}
}
と出力するプログラムをjurinaと名付けるとする
cat filename.jurina
int i=1;
print i;
public class filename{
public static void main(String[] args){
int i=1;
}
}
Javaに置き換えて出力するだけのJava プリプロセッサである
言いたいことVMを解析して、OPコードを吐くコンパイラを作ろうとしていたが
在学期間的にろくに引き継がれねぇ情報．
サポート切れのIPA，PHP，Apacheでうごくubuntu 12.04のオンボロサーバ，構築方法がよくわからん古代の遺物
クソ見てえなシステムリプレースしたいが金も入らねぇし，時間も食いたくねぇ．研究に時間を使わせろ．
サバ缶の俺は今日もサービスが止まったらsudo rebootとsudo service restartしかしねぇ．
WindowsのLAMP環境でソフトを作ってこれサーバで動かせない？とか言ってくる同期，良いけどいっしょにDockerかVM導入しよ！
