タグ

kenichiiceのブックマーク (3,333)

  • MS-ERREF: Windows Error Codes - yohhoyの日記

    Windows OSのエラーコードに関するMicrosoft公式仕様書。HRESULT値/Win32エラーコード/NTSTATUS値を広範にカバーしている。 [MS-ERREF]: Windows Error Codes 関連URL HRESULT型からのエラーメッセージ取得 - yohhoyの日記

    MS-ERREF: Windows Error Codes - yohhoyの日記
    kenichiice
    kenichiice 2024/05/27
    「Windows OSのエラーコードに関するMicrosoft公式仕様書。HRESULT値/Win32エラーコード/NTSTATUS値を広範にカバーしている。」
  • 2023年に特にお世話になったC++ライブラリ8選 - Qiita

    たぶん2023年一番お世話になったライブラリです。 2022年まではsimdjsonをよく使っていたのですが、新規プロジェクトはGlazeばかり使っています。 開発が活発だし、ISSUEへの対応が速いのもありがたいです。 良い点 SIMDを利用していないのにsimdjsonやyyjsonと遜色ない速度で動作する 構造体やクラスだけでなくSTLコンテナもJSONとの直接読み書きができる 中間データに独自バイナリ形式を利用してさらに高速化できる いまいちな点 長い文字列が多いJSONデータの読み込みではSIMDを使っているライブラリに対して不利になる 最後のフィールドのカンマやコメントの読み込みに対応していない ストリーム的な処理はない(と思う) 代替ライブラリ 似たようなアプローチでSIMDを使ってさらに速いJsonifierというライブラリがあります。 純粋な速度を求める場合にはこちらを使

    2023年に特にお世話になったC++ライブラリ8選 - Qiita
  • Linuxでのプロセス置換 - Qiita

    はじめに 導入 Linuxで使うbash等のシェルには、様々な○○置換という機能がありますが、その中でも「プロセス置換」( <(コマンド) や >(コマンド) ) というのはなかなかイメージし辛いのではないかと思います。 ※特にコマンド置換 ( $(コマンド)や`コマンド` ) と名前が紛らわしいというのもあります。 これはパイプと機能的にも仕組み的にも近いものですので、この機会にパイプとの関連性も含め、仕組みを紹介したいと思います。 環境 bash,zsh共にプロセス置換の機能を持っていますが、以下ではbashを前提として仕組みを説明します。 なお、各動作確認は x86_64 WSL1(Win10)/Ubuntu18.04.2 LTS, bash4.4.19(1) で行っています。 プロセス置換の概要 利用目的 bash manページのプロセス置換の項にも説明はあるのですが、なかなかそれ

    Linuxでのプロセス置換 - Qiita
    kenichiice
    kenichiice 2023/12/11
    パイプとプロセス置換の違い
  • 【最終完全版】 bash/zsh 用オプション解析テンプレート (getopts→shift)

    オプション解析に使う getopts と shift bash/zsh 用オプション解析テンプレートとは、シェルスクリプトにどのオプションが指定されたのかを判定しやすくするためのスクリプトのテンプレートです。オプションとは下記の --version のようなハイフンから始まる指定です。 my-shell-script --version シェルに入力するコマンドに指定するオプションを解析する専用のコマンド getopts や getopt を使えば、その内部で様々なオプションを解析してくれることを期待してしまうのですが、実際は制限事項がかなり複雑にあり実用に耐えられません。詳しくは getopts や getopt をマスターするために他の方が解説された記事を参照してください。たとえば、getopts は ロング オプション に対応していません。また getopt は互換性に不安があります

    【最終完全版】 bash/zsh 用オプション解析テンプレート (getopts→shift)
    kenichiice
    kenichiice 2023/11/14
    よさそう
  • 設計ドキュメント腐る問題、Git管理で運用してみた結果 | フューチャー技術ブログ

    はじめにTIG真野です。 秋のブログ週間2023 の3目は、設計ドキュメントをGit管理して腐らせないようにがんばってみた話をします。 前段として6年前、「我々はいかにシステム開発におけるドキュメント腐る問題と戦えば良いのか」という記事を書いたのですが、その後の試行錯誤はどこにも残していないことに気づきました。普段のフューチャー技術ブログですとちょっと引け目を感じるテーマですが、秋の夜長を楽しむため読み物成分を多めに書くというテーマのこのブログリレーにピッタリな気がするため、この機会をお借りします。 ドキュメントも色々な種別があるかと思いますが、この記事では設計ドキュメントを指すことにします。設計ドキュメントは開発メンバーが参照するもので、ステークホルダーへの説明資料に引用して使うことはあれど、主目的は異なるという前提です。Design Docの場合もありますし、システム構成図、ERD、

    設計ドキュメント腐る問題、Git管理で運用してみた結果 | フューチャー技術ブログ
    kenichiice
    kenichiice 2023/11/02
    「Wiki管理は高速で腐っていった」
  • GitHub - mstange/samply: Command-line sampling profiler for macOS and Linux

    You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

    GitHub - mstange/samply: Command-line sampling profiler for macOS and Linux
  • GitHub - google/typograms

    Typograms (short for typographic diagrams) is a lightweight image format (text/typogram) useful for defining simple diagrams in technical documentation, originally developed here. See it in action here: https://google.github.io/typograms/ Like markdown, typograms is heavily inspired by pre-existing conventions found in ASCII diagrams. A small set of primitives and rules to connect them is defined,

    GitHub - google/typograms
  • 【C#】構造体(struct)を完全に理解する - Annulus Games

    今回の記事はC#における構造体(struct)について。 複合的なデータを扱う際、多くの場面ではクラス(class)が用いられるかと思います。しかし、パフォーマンスが重要な場面や、GCによる影響が大きいUnityなどでは、状況に応じてクラスではなく構造体を使用した方が良いこともあります。 近年はC#においてもパフォーマンスが重視されるようになり、構造体が用いられる機会も多くなっています。またUnityのDOTSにおいても、C# Job SystemやBurst Compilerに最適化されたコードを書くために構造体を多用することになります。 ここでは構造体に関する基礎的な知識から、クラスと構造体のメモリ管理について、そして実際に構造体を用いる際の注意や活用方法についても解説していきたいと思います。 ただ今回の記事、調子に乗って色々な内容を詰め込んだ結果、めちゃくちゃに長くなってます。そのた

  • GitHub - mapbox/earcut.hpp: Fast, header-only polygon triangulation

    kenichiice
    kenichiice 2023/06/12
    A C++ port of earcut.js, a fast, header-only polygon triangulation library.
  • 情報

    kenichiice
    kenichiice 2023/06/02
    わかりやすい!
  • GitHub - koute/not-perf: A sampling CPU profiler for Linux

    You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

    GitHub - koute/not-perf: A sampling CPU profiler for Linux
  • 【C#】クラス内の項目の書いていく順番を調べてみた - 狐好きぷろぐらまー

    こんにちは。 pregum_foxです。 結論はこちらです C#で開発されている方以外でも関係ある事だと思いますが、 皆さんはクラス内のフィールドやプロパティ、コンストラクタなどの項目をどの順番で書いていますか? 私自身、フィールドとそれを使用しているプロパティ、コンストラクタその後はメソッドを順番に書いていています。 しかしイベントや非同期処理が入ってくると、どの順番で使用する少し考えこんでしまうことがあります。 このような感じで考えてしまうことがあるので、最初に順番が決まって入れば、時間が短縮できそうだなと思い、この記事を書いた次第です。 まずはmsdnに項目の順番についての規約があるか探してみました。 調べたものは以下の通りです。 StyleCop1 の項目の順番のルール StyleCopAnalyzer2 の項目の順番のルール それでは調査結果を以下に記載します。 調査結果 残念な

    【C#】クラス内の項目の書いていく順番を調べてみた - 狐好きぷろぐらまー
  • C++の自明なメソッドが暗黙に定義されるか場合分け | Netsphere Laboratories

    (2017年6月) 新規作成。 C++ では、互換性の観点と開発の便宜のため, 暗黙にコンストラクタ (構築子)、代入演算子、デストラクタ (破壊子) が定義される。自明 (trivial) な特殊メンバ関数と呼ばれる。 開発者が陽に (明示的に) これらのメンバ関数を定義した場合、自明なメソッドは定義されない。が、ややこしいことに, 単に対応するメンバ以外にも削除されるものがある。 表としてまとまったものが見当たらなかったので、作ってみた。 特殊メンバ関数とコンパイラによる暗黙宣言 - yohhoyの日記 や, コンストラクタが暗黙に宣言されるとき、されないとき があったが、残念なことに、2017年6月現在, 誤りが含まれている。 下の表は、一番左の列のメンバを陽に定義した場合に、2列目以降のメンバが自明か削除されるかを示す。trivial は自明なメンバが暗黙に定義され、deleted

  • Windows アプリで UTF-8 コード ページを使用する - Windows apps

    UTF-8 文字エンコードを使って Web アプリと他の *nix ベースのプラットフォーム (Unix、Linux など) との最適な互換性を確保し、ローカライズのバグを最小限に抑え、テストのオーバーヘッドを減らします。 UTF-8 は国際化のためのユニバーサル コード ページであり、Unicode 文字セット全体をエンコードすることができます。 Web では広く使われており、*nix ベースのプラットフォームではデフォルトとなっています。 プロセス コード ページを UTF-8 に設定する Windows バージョン 1903 (2019 年 5 月の更新プログラム) 以降、パッケージ化されたアプリの場合は appx マニフェスト、パッケージ化されていないアプリの場合は fusion マニフェストの ActiveCodePage プロパティを使って、プロセスのコード ページとして UT

    Windows アプリで UTF-8 コード ページを使用する - Windows apps
    kenichiice
    kenichiice 2023/05/01
    マニフェストファイルを追加する「最近まで、Windows では、-A API よりも "Unicode" の -W バリアントを重視してきました。 ただし、最近のリリースでは、アプリに UTF-8 サポートを導入する手段として、ANSI コード ページと -A」
  • Webフロントエンドにおける網羅的テストパターンガイド

    こんにちは、テストが好きなsilverbirderと申します。Webフロントエンドのテストは実施していますか?ユニットテストやビジュアルリグレッションテストは広く知られていると思います。しかし、パフォーマンステストのためのテストコードはありますか?また、カオスエンジニアリングテストやアクセシビリティテストはありますか? 今回、私はWebフロントエンドにおける網羅的なテストパターンを調査し、その結果をここで紹介したいと思います。これらを理解することで、読者の皆さんが適切なテスト戦略を策定する際の参考になれば幸いです。 前提 今回、テスト対象として取り上げる題材は、TodoMVCというTODOアプリです。フレームワークとしてReactを使用しますが、紹介するテストパターンはフレームワークに依存しないものです。ただし、使用するライブラリはReactに関連しているため、その点についてはご了承くださ

    Webフロントエンドにおける網羅的テストパターンガイド
  • RFCの読み方

    こんにちは。技術開発室の伊藤です。 ハートビーツではメールサーバを自社で運用しています。そのメールサーバの移設を実施するにあたり、移設を対応するチームでさまざまなメールの仕様を理解しておく必要がありました。 メールプロトコルの仕様についてはRFC(Request For Comments)が発行されているため、メールに関するRFCを読んでまとめる勉強会を行いました。 その際にRFCを読むにあたって知っておくとよいことがいくつかあったので紹介します。 RFCとは RFCとはIETF(Internet Engineering Task Force)というインターネット技術の標準化を推進する団体やその他の団体が発行している、インターネット標準や技術提供の文書です。もともとは非公式な文書であることを明確にするため、Request For Comments(コメント募集)という名前にしていたようです

  • [ubuntu-jp:6602] Re: https://www.fujifilm.com/jp/ja 米国からアクセスしてると言われる

    kenichiice
    kenichiice 2023/04/05
    Firefoxのトラッキング防止機能について調べた
  • Webサーバーアーキテクチャ進化論2023

    はじめに 最近プログラマーとしてのキャリアに一区切りつけようと思っており、これまでのプログラミングの勉強の集大成となるブログを書きたくなったので書く。初めてプログラミングをして、フロントエンド開発をして、サーバーから値が返ってきたときは「どういう仕組みで値が返ってきたんだ?」と疑問に思っていた。ずっと理解したくて理解できていなかった。だからずっと勉強していた。そして最近になってようやく自分の言葉で説明できるようになった気がしたのでブログを書きたい。 2015 年版が自分の原点であり、この記事を書くモチベーションになった このような記事は実は過去に存在している。 FYI: https://blog.yuuk.io/entry/2015-webserver-architecture その記事はサーバーがどういう仕組みで動いていて、どのように進化し、2015 年に至るかを解説してくれた記事だ。自

    Webサーバーアーキテクチャ進化論2023
  • 福岡 Rubyist 会議 03 に登壇します。, Ruby の新しいバージョンがリリースされても自動で GitHub Actions の対象とするやつを作った, 羽田空港まで往復 - HsbtDiary(2023-02-15)

    ■ 福岡 Rubyist 会議 03 に登壇します。 もう今週末の開催となってしまいましたが、2/18(土)に福岡で開催される福岡 Rubyist 会議 03 で「Ruby のリリースを爆速にするための方法」というタイトルで登壇します。 https://regional.rubykaigi.org/fukuoka03/ https://fukuokarb.connpass.com/event/271949/ もう参加枠が 88/90 と、ギリギリになっていて、参加するか迷っているなら今すぐ登録してくれ!という状態です。Ruby のリリースの裏側の話やこうするともっとリリースサイクルを短くできるのでは?という話をする予定なので、この辺に興味がある方はぜひお越しください。 ■ Ruby の新しいバージョンがリリースされても自動で GitHub Actions の対象とするやつを作った GitH

    kenichiice
    kenichiice 2023/03/17
    「Ruby の新しいバージョンがリリースされても自動で GitHub Actions の対象とするやつを作った」
  • CSS設計における、すべてがコンポーネントであるという誤謬

    後日追記: WEB+DB PRESS Vol.133でさらに詳しく書いた。 BEMによってもたらされた、コンポーネントベースのアプローチでは、「ページはコンポーネントの集合によって表現されるべきであり、ページに含まれるのはすべてがコンポーネントである」と考える。しかしこれまでCSSを書いてきた経験から、これではデザイン意図をまともに表現することができないと感じ始めた。なぜなら、普通デザイナーはページのすべてがコンポーネントであるとは考えないからだ。 もちろんページの構成要素のなかには、明らかにそれが「コンポーネント」であると意識して作られたものもある。ただしそれは一部であり、全部ではない。「コンポーネントもあれば、コンポーネントではないものもある」という感覚のほうが普通なのだ。 典型的なUIライブラリにある、「ザ・コンポーネント」みたいなものだけではページは完成しない。例として、一貫してB

    CSS設計における、すべてがコンポーネントであるという誤謬