x86-64機械語入門
この記事はx86-64の機械語を書けるようになるためのガイドとなることを目指します。読者はアセンブリー言語について既にある程度知っていることを想定します。 情報源 x86-64の機械語のオフィシャルなガイドはIntelのSoftware Developer ManualまたはAMDのAMD64 Architecture Programmer's Manualです。 Intel SDM: Intel® 64 and IA-32 Architectures Software Developer Manuals AMD64 Architecture Programmer's Manual, Volumes 1-5 このほか、Cから呼び出される関数を定義したり、Cの関数を呼び出すためには、呼び出し規約の知識も必要です。使用される呼び出し規約はOSに依存し、Unix系では主にSystem V ABI
「バニラ」の起源について
IBMのBookMasterでは、デフォルトを"vanilla"、特別な設定を"mocha"と呼んでいたらしい。 http://web.archive.org/web/20211224091337/ftp://public.dhe.ibm.com/printers/products/dcf/samples/B2H.HTM 「Chapter 6. Caveats and restrictions (what's supported and what's not!)」に以下の記述がある。 Conditional sections (.cs) and BookMaster's "vanilla" DVCF macros (.CONFIG and .WHEN) are supported, but not BookMaster's "mocha" DVCF macros (e.g. .USING,
シェルスクリプトでlsをパイプでつなぐのはなぜ悪いのか ～ ShellCheck: SC2010, SC2011, SC2012 とファイル名改行問題 - Qiita
シェルスクリプトでlsをパイプでつなぐのはなぜ悪いのか ～ ShellCheck: SC2010, SC2011, SC2012 とファイル名改行問題ShellScriptUNIXshellシェル芸POSIX はじめに シェルスクリプトで ls コマンドの出力結果（ファイル名一覧）をパイプで他のコマンドに渡して処理するのは推奨されません。ls コマンドを使ったコードを ShellCheck で検査するとおそらく問題があると警告が表示されるでしょう。ls を使うなという指摘自体には賛成なのですが SC2010、SC2011、SC2012 に書いてある理由については正しい説明がされていないと思っています。この記事ではなぜ ls の出力結果を他のコマンドにパイプで渡すのが悪いのか、ls を使わずに実現するにはどうしたら良いのかを解説したいと思います。一つ補足をしておくと、この問題は CLI コマ
The Definitive Guide on Win32 to NT Path Conversion
Posted by James Forshaw, path’ological reverse engineer. How the Win32 APIs process file paths on Windows NT is a tale filled with backwards compatibility hacks, weird behaviour, and beauty†. Incorrect handling of Win32 paths can lead to security vulnerabilities. This blog post is to try and give a definitive* guide on the different types of paths supported by the OS. I’m going to try and avoid di
約束は開発を遅らせる - Mitsuyuki.Shiiba
観測しようとすると、その観測が影響を与えてしまう感じで、おもしろい 自分の頭の中 この機能をチームで開発するのに、だいたい2ヶ月くらいかなぁと自分が頭の中で思っているとする。もし僕らの知ってる範囲ですべてが収まれば1ヶ月くらいで終わるかもなぁと思いつつ、まぁ、知らない範囲のことがあるだろうし2ヶ月くらいに思っておくのがいっか という感じ。6割ぐらいの自信 チームの中 チームメイトに「この機能いつ出せるかな？」って聞かれることはあんまりないと思うけど、もし聞かれたら「んー、2ヶ月くらいじゃない？もしかしたら、もうちょっと早くできるかもだけどね」ってそのまま頭の中を伝えると思う 聞かれることがあんまりないというのは、そもそも、チームでラフに見積もるから。Tシャツサイズとかストーリーポイントとかを使って「Mサイズだから2ヶ月くらいだね」って話をするだけで済む。「2ヶ月くらいだね」って言ったものは
マイナンバーカードの中身をOpenSCで覗いてみる - Qiita
前提情報・背景・注意事項 自分の頭の整理のためにマイナンバーカードの中身を調べたメモです これを参考にして試してみる場合にはうっかり自分の個人情報を公開しないようにご注意ください。 国から認可された団体以外、他人の公的個人認証の証明書を収集・記録することは制限されています 電子署名と暗号化の仕組みはここでは書きません。 私はMacBook pro masOS BigSur(バージョン11.3）、チップApple M1で試しています PCにICカードリーダーを接続し、マイナンバーカードが読み取り可能な状態となっている必要があります マイナンバーカード 公的個人認証とは 公的個人認証サービスとは、行政や民間のオンライン申請や届出、ログイン認証の際に、他人による「なりすまし」やデータの改ざんを防ぐために用いられる本人確認の手段です。 マイナンバーカードなどの中のICチップの中に電子証明書が記録さ
はじめに - アルゴリズムとデータ構造大全
はじめに このドキュメントは，主に競技プログラミングで出題される問題を解く際に利用できるアルゴリズムやデータ構造をまとめたものです．特定の問題にはあまりフォーカスしないため，問題を解く際の考察の仕方等の内容はありません．詳しく，正確に，分かりやすく書いていこうと思っています． このドキュメントは執筆途中です． 想定する読者 C++を用いたプログラミングに慣れている方を読者として想定しており，C++言語の仕様や，文法にはあまり触れません．また，計算量という用語についても説明しません．ただし，償却計算量など，計算量の見積もりが複雑なものについては必要に応じて説明します． コードについて このドキュメントで登場するコードは，可読性向上のため，以下のようなコードがファイルの先頭に記述してあることを前提としています．また，適切な問題を用いてコードの検証がなされている場合は，コード周辺にのように，検証
技術ようつべチャンネル集 - Qiita
役立つYouTubeのチャンネルまとめ 数学、物理、アルゴリズム、プログラミング、などなど自分が使う技術に役立ちそうだな、困ったときによく見たなと思うチャンネルを紹介する。 取っ掛かり、ハマりがち、コツみたいな物が拾える。数学がメイン。随時更新していくつもり。 当たり前だけどちゃんと本も読んで勉強するんだぞ。 背景 YouTubeは視聴する登録チャンネルの数が増えると、チャンネルが埋もれて発掘困難になりがち (chrome拡張でできるチャンネルのフォルダ分け機能は、ぽちぽち登録するのも面倒で、そのフォルダの中から掘り出すのも難しい) モチベが上がる(おべんつよしたい)チャンネルを探してるうちに湧いてくる、わんにゃんコンテンツ(だいちゅき)に流され一日が終わるため、 モチベが上がる有用なチャンネルにすぐにたどり着くために、よく使うQiitaに列挙しておくことにした Streamや大学専用サイ
SNES Development Part 1: Getting Started
I fell down the rabbit hole making a homebrew SNES game a few days ago, and since I couldn't find many good resources, I figured I'd write something of a tutorial. There are lots of resources out there for writing NES games, but way fewer for SNES games — I think there are a few reasons for this. First, the NES is much simpler than the SNES — this is true of both the NES hardware itself, but also
「1Byteが8bitに決まったワケ」についての長い話 まずは「バベッジの階差機関」から
いつものようにヘロヘロと仕事をしていると、突如担当編集の松尾氏からMessengerで「これに対するちゃんとした回答を書けるのは大原さんだなということで、また歴史物をお願いしたく」という依頼が飛び込んできた。 いやちゃんとした回答も何も、上のTreeで出題されたSEライダー氏が正解を出されているわけですが、歴史的経緯というか、ここに至るまでの話というのが長い訳で、その辺りを少し説明してみたいと思う。 ちなみに出題に少しだけ違和感がある（なぜ10bitがキリがいいと思うのか？）のは、筆者もこっち側の人間だからかもしれない。 回答の前に、その根底にある2進数採用の経緯 そもそも非コンピュータ業界の方からすれば、2進数がベースという辺りから違和感を覚えるのではないかと思う。実際、世界最初の計算機（≠電子計算機）とされる「バベッジの階差機関」（写真1）にしても、世界最初の電子計算機（※1）であるE
アクションゲームを爽快にする、ちょっとだけズルい調整メモ｜深津 貴之 (fladdict)
アクションゲームで爽快感を出すための、ちょっとしたズルのメモ。いろいろとプレイして見つけたやつ、思ったやつ。 ギリギリのジャンプをしたときの体験ジャンプで飛び移るとき。「ギリギリ届かない」かつ「キーを進行方向に倒している」場合、ユーザーの意図は「飛び移りたい」と類推される。キャラの座標を多少修正して、うまく飛び移れたことにする。次善策は、「壁にしがみつける」だが、爽快感は多少落ちる。 ギリギリで減速する体験走行時に「逆方向にキーをいれている」場合、ユーザーの意図は「急減速したい」と類推できる。キー入力の長さに応じて、摩擦係数をどんどん増やす。 ギリギリで踏みとどまる体験走行時にブロックから飛び出して落ちてしまうとき。「走行と逆方向にキーをいれている」場合、ユーザーの意図は「踏みとどまりたい」と類推される。よろめき演出で猶予時間を与えるか、急減速を可能とする。 ギリギリでジャンプが間に合う体
エンジニアはつらいよ。ミーム動画で遊ぶエンジニアたち - 中華IT最新事情
ネット上では、誰がオリジナルの作者なのかもはやわからなくなっているミーム画像、ミームGIFが出回っている。エンジニアたちは、このようなミームを拡散するのが大好きで、知乎などのQ&Aサイトに、そのようなミームを集めたまとめ記事が投稿されることがある。 誰の著作物かもはやわからなくなっているミーム ネット上にはミーム画像、ミーム動画が存在している。元々は誰かの著作物なのだろうが、改変されることを繰り返して、もはや原著作者が誰だかわからなくなっているような画像、動画だ。あるいは原著作者が、勝手に二次利用されることを容認、黙認しているものだ。 ミームとは遺伝子に対応するものとして、遺伝学者リチャード・ドーキンスが作った言葉。文化も遺伝子と同じように、模倣を繰り返しながら継承されていくというものだ。ミームは、ミミック（模倣）、メモリー（記憶）などの言葉から作った言葉だという。 エンジニアたちは自虐的
2019-03-06 「運用自動化」とは /20190306-operation-what-automation
「運用自動化の基本原則」シリーズの総論と位置付け、ssmjp 2019/03で発表した資料です。 # 運用自動化の基本原則シリーズ - 2019-03-06 「運用自動化」とは: https://speakerdeck.com/opelab/20190306-operation-what-automation - 2019-05-24 運用業務の「構造化」: https://speakerdeck.com/opelab/20190524-structured-operation - 2019-04-18 運用自動化の基本原則1 「引継ぎの原則」: https://speakerdeck.com/opelab/20190418-operation-automation-basis-principle-1 - 2019-05-24 運用自動化の基本原則2「平易化の原則」: https://sp
2019-03-06 ダメな「運用自動化」の3類型 + α /operation-automation-3-bad-model
ssmjp 2019/03での発表資料です。 「運用自動化の基本原則」シリーズの番外編と位置付けています。 # 運用自動化の基本原則シリーズ - 2019-03-06 「運用自動化」とは: https://speakerdeck.com/opelab/20190306-operation-what-automation - 2019-05-24 運用業務の「構造化」: https://speakerdeck.com/opelab/20190524-structured-operation - 2019-04-18 運用自動化の基本原則1 「引継ぎの原則」: https://speakerdeck.com/opelab/20190418-operation-automation-basis-principle-1 - 2019-05-24 運用自動化の基本原則2「平易化の原則」: https
「5人でユーザテストすればユーザビリティ上の問題のうち85%が見つかる」の元ネタ論文を解説する｜Mikio Kiura / ANKR DESIGN
Webサービスやアプリなど開発や運用に関わっている方であれば、こんなことを耳にしたことがあるのでは無いでしょうか？ 5人でテストを行えば、ユーザビリティ上の問題のうち85%を発見できるこれらは業界的にはある意味で常識ですが、色々話を聞いてみると、この常識の「出処」あるいは「根拠」ってあんまり知られていないようなのです。 もちろん、ちょっと知識のある人であれば、ユーザビリティ業界の第一人者であるヤコブ・ニールセン博士が提唱したというところまでは知識として知っているでしょう。しかしながら、その元ネタとなった論文を実際に読んだ人、あるいは85%という数字の根拠やその条件について理解されている方はどの程度居るのでしょうか。 ということで本記事では「ユーザテストは5人で85%」の元ネタである下記の論文について、解説、と言うとちょっと大げさかもですが、概要を紹介してみたいと思います。願わくば、この記事
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
\??\C:\ Question Marks in Paths
フリーで使える日本語の主な大規模言語モデル（LLM）まとめ
Blender→AE→PS→Unityでエフェクトを作る
きじとら猫がとても好きな人 on Twitter: "JAXAのALOS衛星のDSMデータと国土地理院の基盤地図情報を組み合わせれば，日本全国のそれっぽい3D都市モデルがどこでも無料で作れてしまう事に気が付いてしまった．．． データソースも書きやすくて，論文とかにも使いやすそうでな… https://t.co/iLWDToUXXH"
IMI 情報共有基盤 コンポーネントツール