はてなキーワード: データベースとは
ユーザー企業と言っても、総合商社とか、自動車系とか有名すぎるところはダメ。
不動産、サービス、メーカー。エンジニアを持たずにITの仕事の大半をコントラクターにやらせてるところがいい。
こういうところはたくさんある。当たれば上場企業にも入れる。
だいたい社内のIT部門がコントラクターの管理をしていて、IT部門の人ができるのはSQLぐらい。
コントラクターより社員エンジニアがやってくれたほうが安いし、信頼できる。
ということで、
「AWSみて。は?クラウド初めてなの?まあいいや。とりあえずググってやって」
「Pytyonできる?ちょっとできるんだね。クラスってなんだかわかるかい?よし、じゃあこのバッチ作って。」
「SQLかけるね?じゃあデータベース見てよ、最近なんか知らんけど止まるんだよ。え?どうやって見たらいいかって?
こんな感じでボンボン仕事くれる。上場企業に入れればホワイト確定。
採用されるわけねーだろって?
自分で学習してエンジニアになろうとしています。学習は完了しました。雇ってください」
と。
まあやる気ありそうだったし、希望給与も大したことなかった。上司と一緒にそいつを面接してこう言った。
「勉強するチャンスはあげます。こちらも教えます。でも仕事ができるようになるかどうかはあなた次第です。
仕事ができるようにならなかったら、あなたのやりたい仕事は回しませんよ?」
と言ったら。
で、面接通した。
(でも「バックグラウンドチェックだしたくない」と本人が行ったので辞退された。
うーん、前職で犯罪を犯した、とかでなければ雇いたかったが・・・
チェックで営業としての適性なんぞ見てもしょうがないし・・・)
ということで「フリーでやってますが限界なので正社員になりたいです」と受けまくればいいと思う。
ウエブディレクター、社内SE、何でもいい。ITに関われそうなら。
IDviewは、一般的には特定の分野やコンテキストに依存するため、詳細が書かれていないと具体的に何を指しているのかはわかりにくいです。ただし、一般的に「IDview」という名前が使われる場合、複数の用途が考えられます。
1. **セキュリティシステム**:個人認証やアクセス管理を行うためのシステム。たとえば、生体認証やスマートカードを利用してユーザーのIDを確認し、アクセスを制御するツールが考えられます。
2. **データベース管理システムや分析ツール**:特定のデータベースやシステム内のユーザーIDやその他の識別子を視覚化し、管理・分析するためのツール。
3. **ソフトウェア開発におけるモジュール**:特定のアプリケーションやプラットフォーム内で、ユーザーIDやその他の認識情報を表示するための機能やライブラリ。
具体的な情報がもっとあれば、より正確な説明ができると思います。もし特定の用途やコンテキストについて知りたい場合は、もう少し詳細を教えてください。
たとえば ↓
https://www.launchexcel.com/what-jobs-use-excel/
https://www.fdmgroup.com/news-insights/advanced-excel-skills
ジャップランドで起こりがちなことはアメリカでは無いのかAIちゃんに尋ねてみたらこう言ってたよ
ワイ: 質問: 2024年において、アメリカの大企業および中小企業の間で、より一般的なデータ管理の方法はなんですか? 検索して最新のトレンドを教えてください。 - 方法A:内部データベースからCSVファイルとしてデータをダウンロードし、Excelで修正してから、
ETLツール(例:Informatica PowerCenter、Talend Open Studio)、BIツール(例:Tableau Prep、Microsoft Power Query)、
または他のデータベース(例:OracleDB)などの他のシステムにインポートする。 - 方法B:Excelのステップをスキップし、内部データベースを他のシステムに直接接続する。 - 方法C:レガシーシステムや複雑なシステムには方法Aを使用し、その他のシステムには方法Bを使用する。状況やシステム要件に応じて使い分ける。 質問のポイント: - 大企業におけるExcelの使用:大企業はデータクリーニングのためにExcelを使用するのを完全にやめましたか?それとも、古いメインフレームシステム、ERPシステム、または特定の業務プロセスの問題のためにまだ使用されていますか? - 方法A、B、Cのシナリオ:各方法の具体的なシナリオと製品名を教えてください。 - 2024年におけるCSVファイルのダウンロード:2024年現在、ETL/BIツールやクラウドベースのDWHを利用できないどころか、Oracle Gatewayなどの接続手段も利用できないデータベースの使用は完全になくなりましたか?
もしそのようなデータベースが2024年にもまだ存在する場合、直接的なデータ連携が困難なため、CSVファイルでのデータ抽出が唯一の方法となることがあります。
企業は膨大なコストがかかるために移行を延期していますか?それともすでに段階的に対応していますか? - Excelを使い続ける理由: 内部データベースを他のシステムに直接接続した方がシンプルなのに、なぜ一部の企業はデータクリーニングのためにExcelを使い続けているのですか?
↓
2024年には、大企業の間でメソッドB(直接接続)へのシフトが顕著になっています。しかし、特定のシナリオに応じてメソッドC(ハイブリッドアプローチ)も採用されています。中小企業においても、直接接続の利便性と効率性が認識され、その採用が徐々に増加しています。しかし、リソースとコストの制約により、Excelを使用したデータクリーニングやハイブリッドアプローチが依然として一般的です。
使用状況: この方法は、中小企業、レガシーシステム、複雑なデータ構造を含むシナリオで依然として一般的です。Excelはその柔軟性と使いやすさから、データ操作のための多用途ツールとして広く使用されています。
シナリオ:
製品:
具体的なシナリオ:
使用状況: この方法は、大企業や技術に精通した中小企業の間でますます一般的になっています。直接接続を利用することで、データワークフローが効率化され、手動エラーが減少します。
シナリオ:
製品:
具体的なシナリオ:
使用状況: 多くの企業が、レガシーシステムや複雑なシステムにはメソッドAを、その他のシステムにはメソッドBを使用するハイブリッドアプローチを採用しています。この柔軟性により、既存の制約と近代化の努力をバランスさせることができます。
シナリオ:
製品:
具体的なシナリオ:
データ管理ツールの進歩にもかかわらず、Excelは大企業におけるデータクリーニングと操作のために広く使用されています。これは主に以下の理由によります:
ETL/BIツールやクラウドベースのDWHと直接統合できないシステムに対して、データをCSVファイルとしてダウンロードすることは依然として一般的です。企業は高コストと複雑さのために移行を遅らせることが多く、段階的に対処しています。
しかし、直接接続はより効率的で広く採用されており、長期的にはデータ管理におけるExcelへの依存が減少すると予想されます。
クラウドベースのデータ統合ソリューションの台頭により、データ収集、クリーニング、統合がAI/ML技術によって自動化され、手動作業が減少し、データの一貫性と精度が向上しています。AI/MLアルゴリズムは、異常検出、欠損値の補完、パターン認識などのタスクを効率的に処理し、データ品質を向上させます。リアルタイムデータ分析の利点が明らかになるにつれ、直接接続の採用が増加し、より迅速かつ正確なビジネス意思決定が可能になります。
データセキュリティ、コンプライアンス、およびデータガバナンスの重要性が増すにつれ、このトレンドは続くと予想されます。
大学内で何らかの問題事案があった場合に、学外に対して即座に公表しても何らメリットはない
正直に公表しても批判され責任を問われるだけだし、義憤にかられた関係者が外部へ告発しても
犯人さがしされて村八分というのは鹿児島県警をはじめ枚挙にいとまがない
正解は、学内で処分して外部には知らせず、関係者には徹底的な箝口令をしく
時間はすべてを押し流してくれる
2024年4月、東大の岩崎渉教授の研究室webサイトが消失した
岩崎渉氏は40代の若さで東大教授となった進化生態情報学・バイオインフォマティクスの気鋭の研究者である
これだけならサイト更新の処理を誤って全部消しちゃったとかのミスも考えられなくもない
しかし消失したのは研究室ページだけではなかった、先端生命科学専攻の教員一覧から名前が消され
研究者データベースのResearchmapからも岩崎渉氏の存在が抹消されていた
https://researchmap.jp/iwasakiw/?lang=Japanese
分野・教員一覧 | 先端生命科学専攻 東京大学大学院新領域創成科学研究科
https://www.ib.k.u-tokyo.ac.jp/faculty/
分野・教員一覧 | 先端生命科学専攻 東京大学大学院新領域創成科学研究科
https://web.archive.org/web/20231129161724/https://www.ib.k.u-tokyo.ac.jp/faculty/
https://www.u-tokyo.ac.jp/focus/ja/people/k0001_00249.html
バイオベンチャーの業績への影響がないか確かめるため日経が取材に入った
東京大・岩崎教授のサイト閉鎖、東京大が本誌取材にコメント:日経バイオテクONLINE
https://bio.nikkeibp.co.jp/atcl/news/p1/24/04/11/11790/
「研究不正ではない」との言質はとれたものの、調査中なのか研究室が募集停止したのは事実か
私はプロではないのでわからないので、間違っているのは当たり前だと思って読んでください。
個々人のエンジニアの能力がとかクレジットカードがとかは基本関係ないという話です。
(関係なくてもパスワードを使い回している場合は、同じパスワードを使っているサービスのパスワードはすぐ変えるの推奨)
私は長年社内システムの奴隷をやって参りました。現在のクラウドになる前のサーバも触って参りましたので、その辺りからお話しをさせてください。
サーバーというのは、簡単に言うとシステムを提供しているコンピュータです。
貴方が触っているコンピュータシステムのネットワークの向こう側にいます。この増田も増田のサーバーというのがいて、私たちにサービスを提供してくれています。
しかし、このサーバ、どんなイメージを持っていますか? でっかい黒い冷蔵庫?ちかちか光るロッカー? それともバーチャルのネットワークで画面上に写されるものでしょうか。
サーバーといっても、実4形態ぐらいあるのです。私もチョットワカルぐらいなので間違っていると思いますが、まずは理解する為に簡単に説明させてください。
と言う段階があります。
ニコニコ動画のサービスはどうかというと、色々な情報を得ると、④を使いながら③にする途中で、まだ②が残っている、ということのようですね。
これらの使い分けについてですが、最近は自社でサーバを持っていると自分たちで管理しなければならなかったりして大変なので、できるだけ②から③、できたら④に持っていきたいと言うのが世の中の流れです。それでも②はのこりますが、最小限にしていく方向。
現在は、②のシステムがだけがやられたように、セキュリティ的にも預けた方が望ましいと言われています。
今回も、自社で管理している部分が攻撃されました。特にクレジットカード情報が漏れていないと何度も言われているのは、そこを自社で管理せずに専門業者に任せていたことが大きいわけです。
この流れをまずは頭に入れましょう。
さて、メールを扱ってるサーバーと、売れた商品をバーコードでピッとして管理するシステムは全く別でどちらかがハッキングされたからといってもう一つもされるこことはありません。これは何故かと言うと、それぞれを細かくたくさんのシステムや仮想サーバに別けた独立なシステムになっているからです。
さらにKADOKAWAのようにサービスを外部に展開してる会社の場合、外部向けのシステムと内部向けのもの(バックオフィス)で必要な機能が異なるので、部署が異なるのと同じように違う仕組みになっているはずです。ただし、物理的にどこにサーバがあるかなどはあまり関係がありません。
しかし、こうなると小さなサーバがたくさんたくさんあると言う状態になって管理が大変です。
利用者の視点にしても、システムごとにログインするための情報が別々だと非常に使いづらいですよね。会社で部屋ごとに別々の鍵がついていて、じゃらじゃら鍵束を持って歩くような状態は面倒です。
すると、どうするかというと、これらをまとめて管理するシステムというものが作られます。
これを「システム管理ソフト」と「認証システム」といいます。これらが全体に対してユーザ認証や、サーバが正常に動いているかどうかの管理を提供する事で、たくさんのシステムの管理を効率化するのです。
企業の警備室に機能を集約するようなものです。ですが、ここが要になっていて、破られると全ての鍵が流出してしまうということになるわけです。
出てきた情報から見ると、この管理するシステムと認証するシステムがやられたと思われます。
また、その前の前段はVPNと言う仕組み(ネットワークを暗号化して安全に隔離するもの)が攻撃されて破られたのではないかと推測しています。
これは近頃猛威を振るっている攻撃で、業務用で多く使われているVPN装置の脆弱性(弱点)が狙われて、多数の問題が起きています。当然脆弱性を修正したプログラムは適用されていると思いますが、次から次へと新たなセキュリティホールが見つかる状況であり、匿名のアングラネットでは脆弱性情報が取引されているため、訂正版のプログラムが出る前の攻撃情報が用いられた可能性があります。(これをゼロデイ攻撃といいます) あくまでも推測ではありますが。
個々のシステムは独立しています。ですが、こうなってくると、今回はシステム全体が影響を受け、さらにどこまで影響が及んでいるかの分析が困難なレベルだと言われています。
ここまで広範囲に影響するとすると、管理と認証とVPNが攻撃を受けてやられたとみるべきでしょう。
また、ここが破られていると、クラウドシステムにも影響が及ぶケースがあります。
一時期「クラウド」というとストレージの事を言うぐらい、クラウドストレージが当たり前になって、自社運用ファイルサーバは減りました。これは今では危険と認識されているほかに、こちらの方が安く利便性も高いからです。
それ故に、クラウドストレージ、たとえばSharePoint OnlineやGoogleDrive、Boxなど外部のシステムに置くようになっています。
オンプレミスの認証サーバが破られているので、その認証情報を利用してクラウドにアクセスできてしまったものだと思われます。言わば、鍵を集めて保管してあった金庫がやぶられるようなもの。
通常、クラウドシステムはそんなに甘い認証にはなっていません。例えば多要素認証といってスマホなどから追加で認証すると言うような仕組みがあります。貸金庫に入るとき、自称するだけでは入れず、身分証明書とパスワードの両方が必要なうなものです。
また、日本企業なのに突然ロシアからアクセスされたりすると警報をだして遮断する仕組みがあります。
とはいえ、いちいちクラウドにアクセスする度に追加認証をしていると大変で、面倒クサいと言う声が上がりがちです。
そんなときに行われてしまうのは、自社のネットワークからアクセスするときは、認証を甘くすると言う仕組みです。
つまり、ネットワークは安全だという仮定の下においてしまうわけですね。自社の作業着を着ている人なら合い言葉だけで、本人確認なしで出入り自由としてしまうようなものです。
ところが今回は、ここが破られてしまって被害を受けている可能性があります。自社の作業着が盗まれているので、それを着られてしまったので簡単に入れてしまったようなもの。
また、社内システムからデータを窃盗するには、どのシステムが重要かを判断しなければなりませんが、クラウドサービスだと世界共通であるため、一度入られてしまうと慣れ親しんだ様子で好きなようにデータを窃盗されてしまうわけです。
上記のことを踏まえて、KADOKAWAの展開してるサービス自体や、そこに登録しているクレジットカードは「おそらく」大丈夫です。パスワードも「ハッシュ化」という処置を経て通常は記録されていません。
ただ、パスワードを使い回している方は、その事実とは別にそもそも危険です。パスワード変更をおすすめします。さらに、ハッシュ化をされていても、時間をかければ色々な方法でパスワードを抜き出す事も不可能では無いことも忘れずに覚えておきましょう。
しかし、単なるユーザー、お客さんではなく、KADOKAWAと会社として関わってる人や従業員、取引先で色々な書類等出した人は、既に情報が窃盗されていて、そこから今後も追加で情報が出回る可能性があります。
一方で、分かりやすい場所に保存されていたわけではない情報(システムのデータベース上にだけ入っていたものなど)は、センセーショナルな形で流出したりはしないのではないかと予想しています。
犯人が本当に金が理由だとするならば、データを分析するような無駄な事に労力を割かないためです。
腹いせで全てのデータを流して、暇人が解析する可能性はあります。
ありますが、犯人はコストを回収しようとするので、これらの情報を販売しようとします。売り物になる可能性のものをただ単に流したりもしづらいのではないかと思っています。
もちろん、油断はするべきではありませんし、購入者が現れるとすると購入者は具体的な利用目的で購入するため、より深刻な被害に繋がる可能性も残されています。
犯人が悪いからやられたのです。レベルが低いからとか関係ありません。
また、周到にソーシャルハッキング(オレオレ詐欺のようになりすまして情報を搾取するなどの方法)や、このために温存したゼロデイ攻撃(まだ誰も報告していない不具合を利用した攻撃)を駆使され、標的型攻撃(不特定多数ではなく、名指して攻撃すること)をされると、全くの無傷でいられる企業や団体は、恐らく世界中どこにも存在しません。
それは大前提とした上で、敢えて言うならば、どちらかというと、経営判断が大きいと思われます。
ニコニコ系のサービスと、KADOKAWAの業務システムと2つに別けて話しをしましょう。
ニコニコ系のサービスは、現在、クラウドにシステムをリフトアップしている最中だったと思われます。先日のAWS(クラウドサービスの大手企業)の講演会で発表があったようにです。
ですが、この動きは、ニコニコのようにITサービスを専門にする企業としては少し遅めであると言わざるを得ません。
これは何故かと言うと、ニコニコ動画というサービスが、日本国内でも有数の巨大なサービスだったからだと思われます。特殊すぎてそれを受け入れられるクラウドサービスが育つまで待つ必要があったと思われます。
それが可能になったのはようやく最近で、動画配信系はクラウドに揚げて、残りを開発している最中だったわですが、そこを狙われたという状態ですね。
ただ、厳しい見方をするのであれば、その前に、クラウドに移行する前に自社オンプレのセキュリティ対策を行っておくべきだったと思います。結果論ですが。
それをせずに一足飛びでクラウドに移行しようとしたというのだとは思います。確かに一気に行けてしまえば、自社オンプレに施した対策は無駄になります。コストを考えると、私が経営者でもそう言う判断をしたかも知れません。
KADOKAWAの業務システムですが、これはITを専門としない企業であれば、オンプレミス運用(②番)が多く残るのは普通です。
何故かと言うとシステムとは投資と費用なので、一度購入したら4年間は使わないといけないからです。そして自社向けであればそれぐらいのサイクルで動かしても問題はありません。
しかし、それ故に内部的なセキュリテ対策の投資はしておくべきだったと思います。
以上の様にエンジニアのレベルととかは関係ありません。基本的には経営者の経営判断の問題です。エンジニアに責任があるとすれば、経営者に対して問題点を説明し、セキュリティを確保させる事ができなかったと言う所にあるでしょう。
ですが、パソコンのことチョットワカル私として、想像するのです。彼らの立場だったら…自社グループに経験豊富なエンジニアがいて、一足飛びにクラウドへリフトアップができそうなら、既存の自社サービスのセキュリティ変更に投資はしないと思います。
逆に、パソコンに詳しくなく、自社部門だけでは対応が難しく、SIerの支援を受けつつやらなければならないと言うのならば、SIerは固いセキュリティの仕組みを付けるでしょうし、システムごとにSIerが異なることから自然とシステムは分離されていたでしょう。
そして減価償却が終わった者から徐々にになるので時間がかかることから、昨今の事情により、セキュリティ変更に投資をしてからスタートしたかも知れません。
ただし、繰り返しになりますが、犯人が悪いからやられたのです。レベルが低いからとか関係ありません。
(おそらくは)社内のシステム管理を、自社でできるからと言って一本化して弱点を作ってしまったのは不味かったと思います。
先ほど述べたように、高度化していく手口でシステムへの侵入は防ぐことが出来ません。
なので、システムは必ず破られると考えて、それ以上被害を広げないこと、一つのシステムが破られたからと言って他のシステムに波及しないようにすることなどを意識する必要がありました。
これは物理的な話しではなくて、論理的な話です。例えば物理的に集約されていてもちゃんと別けていれば問題ないし、物理的に分散していても理論的に繋がっていたら同じです。
すごく簡単に言えば、管理するグループを何個かに分けておけば、どれか一つが破られても残りは無事だった可能性があります。
とりあえず今まで出てきた内容からするとニコニコとかその他のKADOKAWAの外部的なサービスは人員的にも予算的にも全然関係ない感じ
そもそも競プロの範囲の中にデータベースってないんじゃないの?
「勉強してOracleちゃんと持ってます!」って言ってくれるような人じゃないとそいつのできる範囲での回答になるのはちょっと仕方ないと思う
次に、我々が解決したい課題そのものよりも、その周辺の競プロっぽい部分に勝手に取り組んで時間を消費することであった。あくまで例えばであるが、データベースに大量データをインサートする際のパフォーマンスが低くて困っていた、としよう。その issue を競プロ出身者に渡すと、大量データを取得する部分を高速化したり、インサートする前の前処理でデータをソートしたりして僅かな高速化を喜ぶのである。ボトルネックはインサート処理そのものなので、それ以外の部分を改善してもユーザーに届く価値はほとんど向上しない。やんわり指摘しても「でも以前よりは速くなっています」という返答である。同様に、何らかの issue を割り当てたときも、その issue の周辺からグラフ理論の問題に落とし込めるようなポイントを探し出し、改善して喜んでいた。カスであった。
こういう感じの自分の興味ある専門分野にだけ取り組む態度は、プログラミング以外の領域でやるとそれはもうボコボコのボッコボコに社会から叩かれまくって完全に心を折られるプロセスが必ず入るんだよね。
プログラミングだけは時代の流れに乗っちゃってるせいでそのプロセスが入ってない状態なんだろうな。
しかも最近はワークライフバランスとかハラスメント排除の社会的潮流が重なっているせいで、ボッコボコにすること自体が実行できない雰囲気になっている。
ワイ、国内では結構大きいインターネットサービスを提供する会社にいる。
この数年、一部で競プロ出身者を持て囃す傾向があるが、それは全く幻想であることを伝えよう。
ワイの会社に来た競プロ出身者(2人いる)には、システムのパフォーマンスが出てない部分を高速化してもらったり、なんやかんやで複雑化してしまった箇所を改善してもらったりなどを期待していた。(やけに抽象的なのは特定を防ぐためで、実際はもっと我々の課題は明瞭である。)
その競プロ出身者は、プログラミングの腕は一見一流だと思う。高学歴で学生時代から競プロに親しみ、何色が云々だとか、いくつかのコンテストで入賞したりしていた。パズル的な問題を解くには確かに強い人材だと思う。しかし、企業で使うにはあまりにカスすぎて、「企業に出張ってきて迷惑をかけるんじゃなく、部屋にこもって競プロやってろ」と思うに至った。
まず何よりも第一に、コードの品質があまりにひどく、見るに耐えないものだった。「これは可読性が低いコード、ということを本当に理解できないのか?」というレベル。コードレビューで「◯◯さん、あなたは賢いからこのコードでも問題ないと思いますが、他の多くの方は◯◯さんほど賢くないので、コードが長くなってもいいからもう少し意図を掴みやすいコードにしてもらえると助かります」のようなことを何度も何度も何度も何度も言った。でも変わらなかった。「自分のコードが正しい」「動けば良い」という発想から抜け出す柔軟性を全く持ち合わせておらず、控えめに言ってカスであった。
次に、我々が解決したい課題そのものよりも、その周辺の競プロっぽい部分に勝手に取り組んで時間を消費するという問題があった。あくまで例えばであるが、データベースに大量データをインサートする際のパフォーマンスが低くて困っていた、としよう。その issue を競プロ出身者に渡すと、大量データを取得する部分を高速化したり、インサートする前の前処理でデータをソートしたりして僅かな高速化を喜ぶのである。ボトルネックはインサート処理そのものなので、それ以外の部分を改善してもユーザーに届く価値はほとんど向上しない。やんわり指摘しても「でも以前よりは速くなっています」という返答である。同様に、何らかの issue を割り当てたときも、その issue の周辺からグラフ理論の問題に落とし込めるようなポイントを探し出し、改善して喜んでいた。カスであった。
人格はそこまでガチのカスというわけではなく、ある意味では無邪気な少年のようであった。ただそれは我々が求めている人材とは異なった。競プロ出身者一人だけこういう行動ならまだしも、我々は二人ハズレを引いている。言うまでもなく人材採用は大変コストがかかるので、今後わざわざハズレを引きに行くことはないだろう。もっとはっきり言うと、競プロ出身者を採用することは無い。
世間にはまだまだ「競プロ出身者はプログラミングに詳しいすごいプログラマである」という幻想があることだろう。しかし実際は、自分の好きな領域にのめり込んでいるだけで、宿題そっちのけでゲームをやっている小学生と似たようなメンタリティなのだ。
企業にプログラマとして雇われるなら、プログラムを書くだけでなく、もう少し大きい視点を持ってユーザーに価値を届け利益を上げなくてはならない。その重要な能力が欠如している競プロ出身者は採用すべきではないのである。
Q.
1つのCPUコアでの逐次処理を高速化することには限界があるため、コア数を増やし並列化させることで性能を向上させる必要がある、という考え方について、市販のサーバコンピュータとスーパーコンピュータで違いはありますか?
A.
この考え方に関して、市販のサーバコンピュータとスーパーコンピュータの間には基本的な違いはありません。両者とも、シングルコアの性能向上に限界がある中で、並列化によって全体的な処理能力を高めるという方向性を共有しています。しかし、その実現方法や規模には大きな違いがあります。 サーバコンピュータとスーパーコンピュータの並列化アプローチの比較 1. 並列化の規模 サーバコンピュータ: 数個から数百個のコアを使用 スーパーコンピュータ: 数万から数百万個のコアを使用 2. 並列化の方法 サーバコンピュータ: 主にSMP(対称型マルチプロセッシング)やNUMA(非一様メモリアクセス)アーキテクチャを採用 比較的少数のプロセッサを密結合 スーパーコンピュータ: 大規模な分散メモリシステムを採用 多数のノードを高速ネットワークで接続 3. 相互接続技術 サーバコンピュータ: 一般的なネットワーク技術(イーサネットなど)を使用 スーパーコンピュータ: 専用の高速相互接続技術(InfiniBand、Tofu Interconnectなど)を使用 4. ソフトウェアとプログラミングモデル サーバコンピュータ: OpenMPやpthreadsなど、比較的シンプルな並列プログラミングモデルを使用 スーパーコンピュータ: MPIなどの複雑な分散メモリプログラミングモデルを使用 ハイブリッド並列化(MPI+OpenMP)などの高度な技術も適用 5. スケーラビリティ サーバコンピュータ: 中規模までの並列化に適しているが、大規模になるとスケーラビリティに課題 スーパーコンピュータ: 極めて大規模な並列化に対応できるよう設計されている 6. 用途 サーバコンピュータ: ウェブサービス、データベース、ビジネスアプリケーションなど、比較的汎用的な用途 スーパーコンピュータ: 気象予報、宇宙物理学シミュレーション、分子動力学計算など、極めて計算負荷の高い科学技術計算
最近サービスインした対戦ゲームがそこそこ気に入ってて、その有志wikiみたいなやつを編集している。マイナーゲーだから企業wikiとかも立ってなくて公式からの情報提供もまちまちなので各人がデータを集めて記載してるんだけど、まだコミュニティとも言えないような規模なのに勝手にルールを制定しまくるヤツ(古代の言葉で自治厨)が発生していて閉口している。
類似作品で喩える(236入力を波動拳と呼ぶみたいなやつ)のはNGだの文章は文語体で統一すべきだの俗称の表記の是非についてどうこうだのくだらないことを議論と称したおしゃべりをしてはルールを作成してwiki中に貼り付けて「経緯について詳しくはこの議論を参照」とか言って議論()のリンクを張ってるんだが、その会話には二人か三人しか参加してないとかザラ。そんなだから普通に他ユーザーから嫌われはじめていて非難のコメントも飛んできておりしばしばレスバを繰り返している。
そのうえ本人はこれ当てたらダメージがいくつみたいな客観データの記載はほとんどやらず、キャラクター評価みたいな一番おいしいところ(そして誰でも思い込みだけで書けるところ)をポエム交じりに書き散らかしている。他人にあれこれ注文を付けるくせに自分が書く部分に「筆者は○○使いだが~」とか入ってるのがキショすぎる。不特定多数が編集できるwikiで筆者とか言われても誰かわかんねえよ。中途半端に匿名性に逃げながら自己顕示欲出してくるんじゃねえよ。内容も普通に低品質だし。こいつランクいくつだ?本当にこのキャラやり込んでるのか?
話がそれた。キショいのはまあいい。というか有志wikiなんてゴミがあってナンボで、むしろそのゴミを排除して自分のお気に入りのゴミで満たそうとする行為が容認できない。草の根活動的にやるwiki編集なんてもともと信憑性も正確性も低いもので、各人が好きに編集してその結果たまたま出来のいいデータベースになったりゴミの山になったりするだけの話だ。完璧なものを作りたいなら個人か企業でやるべきで、不特定多数の力に頼りながら船頭は俺なんて無法は許されるべきではない(管理者でもないみたいだし)。自己顕示欲や支配欲を満たしたいならこんな場末のwikiじゃなくて東京都知事選に出てほしい。心からそう思いながら俺は黙ってデータの追記だけやっている。
最近、角川書店のウェブサイトでランサムウェア攻撃が発生したらしい。ニュースで知ったとき、自分の知識不足を痛感した。ランサムウェア自体がどういうものかはぼんやりとは知っていたが、具体的にどんな被害が出るのか、どんな手段で対策ができるのかについてはほとんど情報がなかった。
まず、角川と言えば、自分がよく読んでいたライトノベルや漫画が思い浮かぶ。「涼宮ハルヒの憂鬱」や「とある魔術の禁書目録」など、多くの人気作品を出版している大手の出版社だ。その角川がターゲットにされるなんて、正直自分には驚きだった。ただのネット小説家やイラストレーターではなく、お金も人材もある企業だからだ。
情報によると、角川のシステムに侵入した犯人は、特定の重要なファイルやデータベースを暗号化してアクセス不能にしたとのこと。犯人たちは身代金を要求している。通常こうした場合、ランサムウェアの被害を受けた企業が支払う金額は数千万から数億円にもなるという話を聞いたが、角川のような企業がどれだけの負担を強いられるのか想像するだけで恐ろしい。
さらに恐ろしいのは、ランサムウェアに感染すると、その影響範囲が広がってしまうことだ。角川のサイトを訪れたユーザーの個人情報も危険にさらされるかもしれない。特に、自分も利用している「BOOK☆WALKER」などの電子書籍販売サイトでクレジットカードの情報を入力している利用者には大きな不安が残る。
一方、自分も含め、多くの一般ユーザーは「そんな大手企業ならしっかり対策してるだろう」という甘い期待を持っていたかもしれない。でも、この事件を通して感じたのは、どんなに大きな企業でも、情報セキュリティの脆弱性が存在すれば、一瞬で崩れる可能性があるってことだ。
そして、この件が解決するまでにどれだけの時間がかかるのか、どれだけの影響が出るのか、正直不安で仕方がない。自分の好きな作品たちが、こうしたトラブルの影響で読めなくなるかもしれないし、最悪の場合、出版も中止になるかもしれない。
この一件を通して、情報セキュリティの重要性を再認識したが、同時に自分がいかに無知だったのかもはっきりと自覚することとなった。これからは、もっと情報に敏感になり、適切な対策を講じていかなければ、同様の被害に自分も遭ってしまうかもしれない。
日本で発生するサイバー攻撃やシステムトラブルは、基本情報技術者試験(基本情報)や応用情報技術者試験(応用情報)の
しかし、多くの場合、経営層のセキュリティリスクに対する認識不足から、システム担当者の警告が軽視されてしまい、被害が拡大してしまいます。
一部の会社は基本情報や応用情報の資格の取得を指示しますが、ぶっちゃけベンダーの資格を取得することの方が有益だと思いませんか?
なぜなら、基本情報や応用情報の資格の範囲内のインシデントであっても、結局それらを未然に防ぐことができていないからです。
これは、現実的な対応に使用されるプロダクトやソリューションが実際には限られているにも関わらず、
基本情報や応用情報の資格ではベンダーを限定していないため、具体的な構築手順や操作手順が不足していることも原因の1つになっていると考えられます。
実際には、ほとんどの場合、Microsoft、AWS(Amazon)、Google、Cisco、Oracleの製品が使用されています。
これらのベンダー資格を取得することで、IT全般に関する理解を深め、システムの概念をしっかりと把握することができます。
適切な資格の範囲の知識と経験があれば、通常はシステム設計が可能となり、将来的なトラブルを防ぐことも期待できます。
正直、基本情報などはもはや要らんのではないでしょうか?
ネットワークに関しては、通常、Cisco製品だけではなく、他の製品も使用されます。
そのため、コストパフォーマンスを考慮すると、受験費用が安い国家資格であるネットワークスペシャリストの資格を取得するのも一つの選択肢だと思います。
この資格は、ネットワークに関する幅広い知識を提供し、特定のベンダーに依存しません。
↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓
近年、日本企業は深刻なサイバー被害やシステムトラブルに見舞われています。こうした問題に対し、基本情報技術者試験(基本情報)や応用情報技術者試験(応用情報)の資格取得が推奨されていますが、果たしてこれらの資格は本当に有効なのでしょうか?
実は、サイバー攻撃やシステムトラブルは、基本情報や応用情報の知識範囲内で事前対応可能なケースも存在します。しかし、経営層のセキュリティリスクに対する認識不足から、システム担当者の警告が軽視されてしまい、被害が拡大してしまうことも少なくありません。
さらに問題なのが、基本情報や応用情報の資格では、具体的な対策方法が十分に学べないという点です。現実的な対応に使用されるプロダクトやソリューションは限られており、資格試験ではベンダーを限定していないため、構築手順や操作手順が不足しているのです。
一方、ベンダー資格では、具体的な製品やサービスに関する深い知識とスキルを習得することができます。 Microsoft、AWS(Amazon)、Google、Cisco、Oracleなど、主要なベンダーの資格を取得することで、IT全般の理解を深め、システムの概念をしっかりと把握することができます。
適切なベンダー資格の知識と経験があれば、システム設計が可能となり、将来的なトラブルを防ぐことも期待できます。
上記以外にも、情報セキュリティに関するベンダー資格なども役立ちます。
ネットワークスペシャリストという国家資格も、ネットワークに関する幅広い知識を提供しており、特定のベンダーに依存しないため、コストパフォーマンスの高い選択肢と言えるでしょう。
特に、ネットワークに関しては、Cisco製品以外にも様々な製品が使用されています。そのため、コストパフォーマンスを考慮すると、受験費用が安い国家資格であるネットワークスペシャリストの資格を取得するのも一つの選択肢だと思います。この資格は、ネットワークに関する幅広い知識を提供し、特定のベンダーに依存しません。
結論として、基本情報や応用情報よりも、ベンダー資格の方が、サイバー攻撃やシステムトラブル対策に役立つと考えられます。
経営層は、システム担当者の警告を軽視せず、適切な対策を講じる必要があります。また、システム担当者は、ベンダー資格を取得することで、より高度な知識とスキルを身につけ、企業のシステムセキュリティを守っていくことが重要です。
anond:20240629090625 anond:20240629094425 anond:20240629095434 anond:20240629111451
行政データは普段は申請ベースで運用されてるけど法的判断基準は「実態」がどうであるかを見る。
相続等の際に夫婦としての実態があることを証明すれば行政データベース上で夫婦でなくても夫婦と認められる。
逆に夫婦としての実態がないなら婚姻届が出されていても夫婦ではない扱いになることもある。
で、夫婦の実態って何?となったときに姓は別なのを名乗っていてそれぞれの収入があって子供もいないみたいな状況はルームシェアとどう違うんだ?更に遠方に住んでいてめったに会わなくても夫婦としての実態があると言えるか?
まあそういう総合的な判断基準のなかで最低限は「互いに夫婦だと普段から周囲に主張している」あたりで、姓をそろえるのは「分かりやすい」夫婦としての実態だと言える。
同じ姓を名乗るのは実態を作る最低限の手間なんだよ。
多様な価値観を認めるなら一度もあったことなく会うつもりもない外国人と結婚するみたいなのも認めなくちゃならなくなるが、常識的にいって偽装結婚ってことはわかるでしょ。