はてなキーワード: プログラミング言語とは
Akira Ransomwareは、近年特に注目されているランサムウェアの一つで、その動作は高度で多様な手法を取り入れています。以下に、Akiraランサムウェアの動作について詳しく説明します。
侵入経路
Akiraは主にフィッシングメール、リモートデスクトッププロトコル(RDP)の悪用、既知の脆弱性の悪用などを通じてシステムに侵入します。特に、未修正のソフトウェアやシステムの脆弱性を狙うことが多いです。
初期感染と展開
システムに侵入すると、Akiraはネットワーク内で横移動を試みます。これは、ネットワーク内の他のデバイスにも感染を広げるためです。横移動には、認証情報の窃取や利用可能なネットワーク共有の探索が含まれます。
ファイル暗号化の前に、Akiraはターゲットシステムの特定のディレクトリをスキャンし、暗号化対象のファイルをリストアップします。次に、強力な暗号化アルゴリズム(通常はAESとRSAの組み合わせ)を使用して、ファイルを暗号化します。
最近のバージョンでは、部分的な暗号化手法(インターミッテント暗号化)を採用することで、暗号化速度を上げつつ、検出を回避する手法が確認されています (Bitdefender)。
データの窃取
暗号化に加えて、Akiraは重要なデータを盗み出し、そのデータを公開することで二重に脅迫することがあります。これにより、被害者に対する身代金要求の圧力を強化します。
暗号化が完了すると、被害者のデスクトップに身代金要求メッセージが表示されます。このメッセージには、データを復号化するための手順と支払い方法が記載されています。通常、暗号通貨(ビットコインなど)での支払いが求められます。
特徴的な技術
RustとC++の利用
Akiraの一部バージョンはRustというプログラミング言語で書かれており、これによりコードの安全性が向上し、セキュリティ研究者による逆コンパイルが難しくなっています。また、C++で書かれたバージョンも存在し、多様な環境での実行が可能です (CISA)。
VMware ESXiの標的化
Akiraは特にVMware ESXi仮想マシンを標的とすることが多く、これにより企業の仮想環境全体に影響を与えることができます。
Akiraは単純なファイル暗号化にとどまらず、データ窃取やネットワーク内での横移動、他のマルウェアの導入など、多層的な攻撃手法を組み合わせています。これにより、攻撃の成功率を高め、被害者に対するプレッシャーを強化します。
学生さんに向けて、社会人5年目の黄コーダーとして知っておいて欲しいことをまとめるね。
以下、エンジニアの大部分が競プロerみたいな特殊な環境を除く。
長期的に考えるならば、競プロはさっさと止めて、ポートフォリオに書けるような個人開発やOSSコントリビューションに注力した方が遥かに良い。
君が家を建てるとして、トンカチさばきの早さを誇る大工と、建ててきた家の数を誇る大工のどちらに頼みたいか考えてみると良い。
トンカチを振るのが好きなことは否定しないが、それをもって評価されるのは学生の間だけだ。
(この辺はシステムの欺瞞もあると思っていて、新卒採用における評価基準の風向きが明らかに変わってるのに逆求人系の会社が未だにchokudaiに講演させてるのってどうなん?とは思う。)
元増田でも指摘されている通り、競プロerに良い印象を持っていない人はそこそこ存在する。
「◯◯コーダーです」と自分から言うのは控えた方が良い。誰も幸せにしない。
人は同じ文化圏に所属しない相手には冷酷だ。そして、文化圏の類似度は使っている言葉によって測られる。
何でもかんでも「にぶたん」「DP」に結びつけるのが面白がられるのは界隈の中だけだ。
ここで言う「方言」には、自然言語だけでなくプログラミング言語、つまりコードも含まれる。
競プロ対策本じゃなくてリーダブルコードを読め。あの本がプログラミングの世界の標準語だと思えば良い。
数年前の全盛期から比べれば、暖色を見ただけで即採用してくれるような企業は恐ろしいほどに減った。
そのようにして入社した君たち以前の代が十分な成果を挙げなかったり、彼らから嫌な思いをさせられた人が多いからだ。
だから、「月刊競プロは役に立たない」なんて冷笑してないで、一度立ち止まって「なぜ月刊レベルで競プロerが批判されるのか」を考えてみてほしい。
日本ではカルト的に流行っていた。サービスに例えるならmixiみたいなもの。
https://survey.stackoverflow.co/2023/#most-popular-technologies-language-prof
使い続けたいが47%、新しく使いたいが4.92%
アドテク界隈でブイブイ言わせていたのは過去の話。コミュニティーすら縮小している始末
https://survey.stackoverflow.co/2023/#most-popular-technologies-language-prof
利用者の割合は3.21%で、同じJVM言語のKotlinの9.7%に大きく差がある始末
使い続けたいが52%、新しく使いたいが3.18%
あと一つは?
これといって作りたいものは無いが、新しいことを始めたいのと、あんまりお金をかけずに気軽にに始められるから
テキスト通りに進めているつもりだけどできておらず、書籍名で検索とCHATgptに聞きながら同じ手順を3回繰り返してそれっぽい環境を作ることができた
原因が全く想像できないメッセージをみるたび、妄想のツヨツヨエンジニア(笑)がマサカリ投げてくる
「こんなこともできないの?」
とか言ってくる
エンジニア向けも質問サイトもおんなじことを婉曲に言ってるようにしか読めないから質問どころかユーザー登録するのも怖い
おすすめは…
1) プログラミング言語
2) オペレーティングシステム
このあたりかな
これが難しいなら…
4) デバイスドライバ
5) Webブラウザ
6) シェル
あたりもおすすめかなー
IT業界で、昔はSESで働いていて、大手によく客先常駐していた。どこも大手ばかりでノウハウはしっかり蓄積され、設計書なども充実していた。
SESを脱退し、そこそこ大手のIT企業の正社員になれた。しかし、そこはこれまでのSESで客先常駐していたような企業とは違い、あまり体制的には良くはなかった。
工数管理は基本中の基本であり、やらないIT企業はなかなかないだろう。しかし、当社は違った。
1日に何をしたのか、報告の義務はなく、ただ作業していればよかった。
工数管理とは、案件ごとに工数管理のための番号(工数番号)を振り、さらにその工数番号ごとに要件定義、基本設計、詳細設計、実装/単体テスト、結合テスト、総合テスト、などのサブ番号に分割して、工数を登録することである。
さらにセキュリティ教育などは個々の案件と無関係なことが多いので、維持管理用の工数番号が振られていることもある。
リリース後のトラブル対応なども工数を消費するので、それ専用の工数番号などもあったりする。
さらに、日々の工数を詳細に記載する日報のようなものも導入しているところが多く、どの作業に何時間作業したかを15分単位などで記載する。
工数管理のいいところは、作業をサボりにくくなることだ。作業効率が客観的に見えてしまうため、現実を突きつけられ、もっと頑張らなきゃ、と思う。
工数管理のだめなところは、とにかく面倒くさいことだ。当然だが、工数管理を行うための工数、は工数管理には入力できる枠はない。が、確実に無視できないレベルで工数を消費する。あとトイレなどにつける工数などもない。
しかし、活用されておらず、形式上だけ数字さえ入っていればそれでいい、というものだ。
その形式上すら煩わしいらしく、若手の意見をバリバリ言う人から、
・工数管理は全く意味がない。適当な工数を入力していても誰もチェックしていないのか、何も言ってこない。
・工数管理をしっかりすれば、1日に働いた時間がわかるのだから、勤怠システムは不要である。工数管理システムと勤怠システムを一本化すべきだ。
などの意見が出ていた。
そりゃあ工数管理が根付いてない企業に工数管理を行えばそうなるでしょう。
工数管理は業務に結びつくものではなく導入メリットは明確には測れない。しかし、めんどくささは圧倒的だ。
結果、工数管理システムは完全に廃れ、入力すらしなくても誰も何も言わなくなった。
つまり、当社はよく言えば従業員の意見が通りやすい、悪く言えば従業員のわがままが通ってしまう企業なのだ。
従業員の意見を尊重し、押し付けをせず、それぞれのルールを重んじる。良いことであるが、それでは業務は改善できない。
これまでもそこそこやれてるのだから、それを無視して新ルールを導入しても、組織が壊滅する可能性が出てくるだけだ。
工数管理は基本中の基本だ。どこもやっている。それすらも当社は従業員のわがままが通ってしまうのだ。
(まあ当社の工数管理はテキトーだからダメだったのであって、もっと厳密に管理して、日報なども義務化すれば、これまでサボってた社員もサボれなくなり、結果的に業務は改善していたと思うが。)
PDCAはPlan, Do, Check, Actionの頭文字を連ねたもので、つまり、まずは予定(Plan)ありき。予定がないと実行(Do)はしてはいけない。
実行した後は必ず振り返り(Check)を行いなさい。
当社もPDCAの概念はあるし、週報という形でそれを実現している。
しかしその概念は根付いておらず、週報以外ではPDCAは無視している。
つまり当社は、まずは実行があり、計画は立てることは必須ではない。多くの人は計画を立てない。
振り返りも当然実施しない。実行のみがある。Do, Do, Doである。
これは作業者レベルでそうであるし、案件レベルでもそうだ。案件はたしかに最後には振り返りの資料を作成する必要がある。しかし、これは単に作成しなきゃいけないから作成してるだけで、綺麗事をまとめた振り返りである。
本来は、まずは理想を語り、次に現実を語る。しかし当社は、過去をグダグダ言っても仕方ない、と理想を一切語らず、現実のみを語る。しかし振り返り資料には上司受けするような荒唐無稽な対策が記載される。
当社は、作業の前には計画ありき、などの文化は全く根付いていない。優秀な人間でも根付いていない。
私はただの平社員なので、それらについて指摘はできない。指摘したところで「じゃあどうするの?」と詰められて終わりだ。指摘するなら十分な資料の作成と具体的な対応策の準備、そして責任と人を動かすカリスマ性が必要だ。私にはそれらを準備してまで無駄に頑張る気はない。
と書かれていた。
本来は、業務改善は個々のチームだけの問題ではないので、上層部でマニュアル化してルール化すべきではないのか?
アイデアは個々のチームから出してもらっても良いだろうが、それを取りまとめて全体で取り組ませるのは上層部の役目ではないのか?
それをなぜ、個々のチームに依頼する?
業務改善といえばマニュアルの作成や設計書フォーマットの作成だ。
それは能力の低い人でもマニュアル通りに作業することで能力の高い人と同等の仕事をできるようにするためである。
しかし、当社はマニュアルを作る習慣はない。自分用のメモは作るが、維持管理に使えるマニュアルは誰も作らない。
フォーマットがあるだけで記載漏れがかなり減る。考慮漏れも減る。作業が具体化されるからタスクも細分化して記載できる。
当社には推奨するプログラミング言語はなく、推奨のフレームワークもない。
これらが共通化されていれば、開発者がいろいろなチームに参加しやすくなるし、別のチームの有識者に相談しやすくもなる。
こういった業務改善は本来は上層部が率先して枠組みを作るべきだ。しかしやらない。
上層部に知識がなく、やるとしたら雑な仕事しかしないから、やられると逆に困るのだが。
当社はとにかく従業員の声が大きい。強い。
業務改善などの施策を出しても、従業員が納得しないと続かない。
そういう文化を変えるのは並大抵のことでは出来ない。
環境が変われば人は変わるだろうが、そもそも環境を変えるには人を変えないといけない。だから変わらない。
仕事が回らなくなり死にかければ変わるかと思ったが、たぶん変わらない。
仕事の仕方を変えるくらいならきっと死を選ぶだろう。それくらい変わらない。
2024/05/15 10:48
工数管理すべきなのは、成果物ではなくサービスを提供する人なのかもしれない。例えばPMなど。
当社の開発チームは、開発者やPM以外にも、君必要なの?何やってる人なの?打ち合わせには参加してるけど、ただの工数食い虫じゃね?みたいな人もいるのです。
なるほど確かにその通りですね。
意固地になって謝罪を固辞し続けて大変申し訳ございませんでした。
僭越ながらわたくしめがフェミニストを代表して土下座で謝罪させていただきます。
その方法として古代中国より伝わる「三跪九叩頭の礼」で謝意を表させていただきます。
なお、冗長した記述を避けるためにプログラミング言語「COBOL」を用いることを予めご了承ください。
IDENTIFICATION DIVISION.
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
DATA DIVISION.
WORKING-STORAGE SECTION.
PROCEDURE DIVISION.
MAIN.
PERFORM 3 TIMES
DISPLAY "GUI"
PERFORM 3 TIMES
DISPLAY DOGEZA-CNT "KOUTOU"
DISPLAY "CHI"
END PERFORM.
DISPLAY "CHIRAI"
END PERFORM.
STOP RUN.
END PROGRAM SANGUIKIUKOUTOU.
御清聴ありがとうございました。
はい、JavaScriptによるコーディングはコンピュータサイエンスの一部と見なすことができます。コンピュータサイエンスは、情報とその処理に関する学問であり、プログラミングはその重要な要素です。JavaScriptは、ウェブページを動的にするための主要な言語の1つであり、ウェブ開発の分野で広く使用されています。したがって、JavaScriptを学び、それを使用してコードを書くことは、コンピュータサイエンスの実践的な応用の一部と言えます。しかし、コンピュータサイエンスはプログラミングだけではなく、アルゴリズム、データ構造、ネットワーク、データベース、人工知能など、より広範なトピックをカバーしています。それぞれが特定のプログラミング言語やツールを使用して探求されることがあります。JavaScriptはその一部であり、特定の問題を解決するためのツールとして使用されます。それはコンピュータサイエンスの一部であり、その全体ではありません。それでも、JavaScriptをマスターすることは、コンピュータサイエンスの重要なスキルを習得するための素晴らしいステップです。それはあなたが複雑な問題を解決するためのロジックとアルゴリズムを理解するのを助け、あなたの思考を開発するのを助けます。それはまた、あなたがウェブ開発の世界に足を踏み入れ、あなた自身のウェブサイトやアプリケーションを作成するのを助けます。だから、はい、JavaScriptによるコーディングは確かにコンピュータサイエンスの一部です!
はい、ブラウザの実装は確かに**コンピュータサイエンス**の一部です。以下に、その理由をいくつか挙げてみます:
1. **アルゴリズムとデータ構造**:ブラウザは、効率的な検索、ソート、データの格納と取得など、多くのアルゴリズムとデータ構造を使用します。
2. **ネットワーキング**:ブラウザは、HTTPやHTTPSなどのプロトコルを通じてインターネットと通信します。これらのプロトコルの理解と実装は、コンピュータサイエンスのネットワーキングの分野に直接関連しています。
3. **レンダリングエンジン**:ブラウザのレンダリングエンジンは、HTML、CSS、JavaScriptなどのコードを解析し、それをユーザーが見ることができる視覚的なウェブページに変換します。このプロセスは、計算理論、グラフィックス、プログラミング言語の理解を必要とします。
4. **セキュリティ**:ブラウザは、ユーザーのデータを保護するために、さまざまなセキュリティメカニズムを実装します。これには、暗号化、サンドボックス化、同一生成元ポリシーなどが含まれます。
これらすべての要素は、コンピュータサイエンスの基本的な概念に基づいています。したがって、ブラウザの実装は、その「サイエンス」の部分を明確に示しています。ブラウザの設計と実装は、これらの理論を実際の製品に適用するための実践的なフレームワークを提供します。それらは、問題解決、効率的な設計、そして最終的にはユーザーに価値を提供するための方法を探求します。これが、ブラウザの実装がコンピュータサイエンスである理由です。
とある雑記ブログを7年ほど前に見つけて、年に数回ほど訪れている
役に立つとか面白いなんてのは一切ない
あまりにも拙い内容なので俺しか読者がいないから不憫に思っているだけだ
そのブログは「ポケストは任天堂関連だから京都に多い」という意味不明な解釈を垂れ流して炎上していた
リリース直後だとしてもお粗末すぎる記事なので当時話題になっていたと思う
その後も知能指数が低いこたつ記事を連発したり、アンチや社会への不満を似たような文面で何回も投稿するなど、ちょっと不憫にも思えるくらい情けない記事ばかり書いてる
カテゴリーもその時の瞬間的な流行に乗っているだけにすぎず、特に深いものはない
唯一読まれていたのは遊戯王の記事だったらしいが、それも飽きてやめてしまっている
それなのにブログ自体は今年で9年目となり月1投稿は欠かしていない
そこは素直に良い点だと思う
問題は筆者の能力が著しく低く、せいぜい炎上記事でしかPVを伸ばせないことだ
びっくりするがあの文章力で短編小説家を目指しているといまだに言っている
何が目標かテーマは何か何ができるのか一切わからない、本当に謎なブログと筆者だ
どういう内容書くつもりだよ
改行する
<br>
右から左に動かす
おいHTML構文かよ
どこかの記事のコピペをしないだけましだけど、それでもプログラミングと題してHTMLなんだよ
今日日、小学生が授業で習うような超初歩的なことしかないていないし、しかも内容が超絶古い
しかもmarqueeって俺も知らんぞってググッたらとっくに非推奨扱いの化石じゃねーか
なんで古の手打ち掲示板でしか通用しなさそうなことをこの令和に?
炎上狙いだとしても、もっとこうさ、ちょっとバズりそうな要素を含ませるとかしようぜ
これがある程度PV稼いでいるブログに書いた珍記事だったら面白いけど、おまえのところの読者なんて俺くらいしかいないだろーが
センスのかけらを獄門疆に封印してきたような君がいくらやってもPV伸びんわ
かつてのポケゴーは題材がビッグネームだったからバズっただけで、プログラミングなんてものでどうにかなるもんじゃねーよ
「AIを使えばやりたいプログラミング言語のコーチがタダでしてもらえるんだぜ!」
くだらん。
昔のグーグルだったら「[プログラミング言語名] 勉強 やり方」でググったら最高にイカしたページにたどり着いた。
作りたいシステムがあっても「[言語名] [やりたいこと] コード」でググれば欲しかった情報がドンピシャでガッポガポ。
そんな黄金時代があった。
ADSLが世界をつなぎ始めた世界、ネットの海が光速で流れていなかった穏やかな時間。
あの頃、ネットの海から求めていた知恵を引き上げるのは今よりずっと簡単だった。
今のネットは汚れきったヘドロの塊であり素のまま飲めば猛毒となる巨大な汚水、まるで東京湾だ。
AIがやっていることはネット上に溢れた有象無象を濾し取って、少しだけ昔のインターネットに近づけるだけの作業でしかない。
昔はほんのちょっとした言葉の組み合わせでたどり着けた知識が、今や何百文字ものプロンプトを指定してようやくたどり着けるようになった。
「AIは賢いものとそうでないものの格差を広げるだろう」と語るものは物事の一面しか見えていない。
正解は「かつて、インターネットという空間は誰しもに開かれた無限の智慧が内包されていた。その知恵が一部の人間に独占される時代がやってきた」だ。
誰しもが賢く慣れる世界の方がいいに決まっている。
生まれついたIQの高低を義務教育を終えて十年二十年それ以上経ってもいつまでも擦り続けるような哀れな者達の戯言のなんと醜く濁ったことだろう、まるで東京湾だ。
fx趣味なもんでpinescriptとMQL4っていうプログラミング言語は分かるんやが、こいつらとは勝手が違いすぎて諦めた。いずれにせよ、英語は分かってた方がスムーズに打てて良い。
プログラミング言語で動的言語を嫌って静的言語こそ至高みたいな主張の人って結構みかけるんだけど、なんでみんな偉そうでマウント取ろうとしてるの?
パフォーマンス面での優位ならまだわかるけど主張は基本型がないことをディスってる
頭が良ければ脳内で整合性の取れるコードを書けるわけだから、コンパイラのサポートがなくても書けるほうが優秀なのは自明のはず
コンパイラにサポートしてもらわないとまともなもの書けないよというほうが能力としては劣ってる
劣っててコンパイラのサポートがほしいならそれでもいいんだけど、なぜ自分が無能だということを偉そうにアピールできるのかがわからない
自分頭悪いので静的言語じゃないと書けないんですーとか言われたらじゃあそういう言語使うかとなるけど、
動的言語とかゴミ使う価値ないとか、◯◯言語は消えるべき、とか言われたらお前の頭が悪いだけなのになぜそれに合わせる必要があるの?としか思えない