タグ

ブックマーク / qiita.com (106)

  • メインフレームの異常処理 - Qiita

    はじめに この記事では、メインフレームでは異常時の処理でどのようなことをやっているのか、また、Linuxの異常処理との違いなどについて話してみようと思います。 この記事を書くに至った直接的なきっかけは、とある人からリクエストがあったからです。が、日ごろからメインフレームの異常処理の考え方については、PCサーバーやクラウドによるシステムがメジャーになった現代であっても、参考になることは多いと感じていてはいました。 筆者は今でこそLinux Kernel周りの仕事をしていますが、20年ぐらい前のころはメインフレームのOS開発部隊に配属されていて、メインフレームのとあるコプロセッサのドライバを書いたりしていました。この際、その異常処理における考え方を体験する機会が多々あり、当時のその経験が20年後の現在でも大いに役にたっていると感じていたからです。 そもそもメインフレームは、これまで長年にわたっ

    メインフレームの異常処理 - Qiita
    yugui
    yugui 2024/04/03
  • Chromium のメモリ管理 (Oilpan) - Qiita

    はじめに 前回の PartitionAlloc の記事 に続いて、PartitionAlloc と双璧をなす Chromium のメモリ管理 Oilpan について紹介します。 文中に出てくるデバッガー コマンドは、以下のエクステンションに含まれています。 GitHub - msmania/chromium-debug: Debugger extension for Chromium https://github.com/msmania/chromium-debug Oilpan 概要 Chromium プロジェクト公式のページはこちらです。 Blink GC Design https://chromium.googlesource.com/chromium/src.git/+/master/third_party/blink/renderer/platform/heap/BlinkGC

    Chromium のメモリ管理 (Oilpan) - Qiita
    yugui
    yugui 2024/02/29
  • ネット上に氾濫する自己組織化マップ(SOM)の情報を俺が整理する【随時更新】 - Qiita

    【こちらの記事は新しい情報を見つけ次第、更新していきます。また皆さんからの「こんなのもあるよ!」も大歓迎です!】 はじめに 皆さんは自己組織化マップもしくは自己組織化写像(Self-Organizing Maps: SOM)と呼ばれる手法をご存知でしょうか?多変量データの可視化などに使われるアルゴリズムで、現在の機械学習やデータ解析ブームの遥か昔から使われてきました。 しかし、私が思うにSOMは非常に「初見殺し」な手法です。SOMについて学ぼうとする人の多くは、ネット上のあらゆる種類の情報に惑わされ、用途に対してあまり適切な説明がされていないテキストで学んでしまうことも少なくありません。その理由は大きく2つあります。 二つの解釈があり、それぞれで適切な運用方法も異なる SOMには脳機能のモデル化というサイエンス的な側面とデータ解析という工学的な側面があります。元々は前者の発想で考案されたも

    ネット上に氾濫する自己組織化マップ(SOM)の情報を俺が整理する【随時更新】 - Qiita
  • Terraform職人のためのOpenTofu入門 - Qiita

    この記事は クラウドワークス Advent Calendar 2023 シリーズ1 の 4日目の記事です。 はじめに 「父さんな、Terraform職人やめてお豆腐職人でっていこうと思うんだ」と言いたいだけの @minamijoyo です。 2023年8月HashiCorpはこれまでMPL2のOSSライセンスで公開していた主要製品をBSL(Business Source License)に変更することを発表し、Terraformはv1.6.0からOSSではなくなりました。 このライセンス変更を受けて、OSS版のTerraformを求める人たちで、MPL2時点のコードベースからforkしたOpenTofuの開発が進められています。 HashiCorpのBSLは、実質的に競合他社の商用利用に制限をかけたもので、ほとんどの一般的なユーザに直接的な追加の制限はありませんが、間接的にTerrafo

    Terraform職人のためのOpenTofu入門 - Qiita
  • Ruby | case と === の歴史 #ruby - Qiita

    概要 Ruby の case 文と === の歴史について 昔の case 昔の Ruby には String 化症候群 というものがあったそうです。 ※参考資料(ruby-list 10525) case の内部では no.to_s =~ 1.to_s のような比較をしていた。 しかし、何でも文字列で比較するのはおかしいということで変更することになったが、 文字列以外に =~ を利用するのも気持ち悪いので新たな演算子を利用することに。 そこで === の登場。 現在へ・・・ 現在の case 現在の case 文は内部比較に === を利用しています。 これによって、クラスに合わせた比較処理を実現し、 case をポリモーフィックに利用することができます。 サンプル String#=== るりま | String#=== 文字列の内容で比較します。 サンプルコード %w(hoge hig

    Ruby | case と === の歴史 #ruby - Qiita
    yugui
    yugui 2023/08/09
  • 悪名高きスワイプ広告を解析する - Qiita

    この記事の概要 ユーザーから嫌われている広告の1つに「スワイプ広告」というものがある。 誤タップをしやすいことが理由だが、あまりにもこの広告だけ誤タップするため調べたところ 実は誤タップしたように見せかけて意図的に広告先に遷移させる広告であるということがわかった。 スワイプ広告とは、左右にスワイプすると画像がついてくるタイプの広告である。 スワイプ広告とは スワイプ広告とは、主にアフィリエイトサイトで見られる広告形式の一つである。 ユーザーは指で画面上の広告を左右にスワイプすることで、広告画像を切り替えることができる。 スワイプによるインタラクティブ性を活かし、複数のメッセージやメディアを使い、魅力的な広告体験を提供することが特徴である。 なぜ悪名高いのか しかし、スワイプ広告はユーザーから嫌われている。その理由は、誤タップを誘発しやすいからである。 誤って広告をタップして画面が遷移してし

    悪名高きスワイプ広告を解析する - Qiita
    yugui
    yugui 2023/08/07
    ユーザー: 時間を食われてイラッとくる, 広告主: 偽りのクリックに過大な支払を要求された挙げ句にブランドに傷が付く, まともな代理店: CTR負けして不利になる; 誰も得しない。ad networkが禁止しないのが謎
  • エンジニアのための刑事事件対策まとめ - Qiita

    こんにちは。モロと申します。 実は数年前警察のお世話になり、数年裁判等をやって、昨年晴れて無罪放免となったのですが、そういえばその後どこにも情報をまとめていなかったことに気が付きました。 正直にいうとまったく気の進まない作業ですし、数年間これにかかりきりだったこともあり「わざわざまとめなくても誰でも知ってることでは……?」みたいな気持ちもあります。 とはいえ冷静に考えると大抵の人は一生関わり合いになることのない知識で、お世話になった界隈に対して何も残さないのも不義理という感じがしたため遅ればせながら筆を執らせていただきます。 はじめに 当記事は、実際に警察のお世話になり、数年間弁護士の方にご指導いただきはしたものの、あくまで法律の専門家でも何でもない一エンジニア(というか多少エンジニアリングをかじったデザイナー)によるもので、第三者による監修等もなされていません。 実体験に基づいて少しでも

    エンジニアのための刑事事件対策まとめ - Qiita
    yugui
    yugui 2023/05/30
  • 非エンジニアサイドに技術的負債や設計を説明するノウハウ - Qiita

    こんにちは、リファクタリングが大好きなミノ駆動です。 この記事は READYFORアドベントカレンダー2022 、10日目の記事です。 これはなに? ろくに設計せずにシステム開発を進めると技術的負債が蓄積し、変更が難しくなってしまいます。 しかし設計を推進しようにも、周囲が設計is何を知らないと、なかなか理解を得られません。特にビジネス側や経営側はプログラムの内部構造を知らないわけですから、輪をかけて説得が困難です。 この記事は、ビジネス側や経営側など、非エンジニアサイドに対して技術的負債や設計を分かりやすく説明するための例えや手法をまとめたものです。 私が非エンジニアサイドへ説明するとき実際に活用しているもので、聞き手からも「分かりやすい」と好評を得ております。 この記事のゴール 以下を知ることがこの記事のゴールです。 技術的負債や設計について、非エンジニアサイドに理解を促すノウハウ ユ

    非エンジニアサイドに技術的負債や設計を説明するノウハウ - Qiita
    yugui
    yugui 2022/12/14
  • パスキー導入時のRelying Party側の考慮事項的なもの - Qiita

    記事は Digital Identity技術勉強会 #iddance Advent Calendar 2022 の11日目の記事です。 最近いろいろ盛り上がってきているパスキーについて、実際にサービスに導入するときに気になりそうなポイントをまとめてみようと思います。 あくまでパスキー調べてる個人の意見です!それはちがくね?みたいなのあったら、コメントください 背景 既存の状況・問題点 今までのFIDO認証は、基的にCredentialはAuthenticatorの外にはでない、Single-Device Credentialと呼ばれるものでした。そのため、セキュアではあるものの、Authenticatorを紛失した場合のリカバリが難しく、サービスの利用にあたってFIDO認証の利用を必須化することは難しい状態でした。 特にコンシューマー領域では、「Authenticatorを複数台持って

    パスキー導入時のRelying Party側の考慮事項的なもの - Qiita
  • セキュリティーチェックシートという闇への防衛術 - Qiita

    といった感じです。(この例、下で問題例として取り上げるため、実はおかしなチェック内容にしています。) "No.~基準"までがシートに記載されていてます。回答する発注先企業は"Yes,No,N/A"を3択で✅をつけ、備考欄にNoやN/Aの理由のほか、注記を記載できます。こういう項目が20~500項目あるExcelのシートに、発注先企業の回答担当は自社の状況、対応を確認しながら、ひたすら記載してゆくわけです。 知ってる人は知っているが、知らない人はぜんぜん知らない 最近参加したエンジニアがぞろぞろいらしたカンファレンスで、私が 「……あの セキュリティーチェックシート ってあるじゃないですが、あの 面倒なアレ です。アレにこの規格を採用するよう書いてあったら、各企業に規格の採用が広がるかもですね。あはは。」 と話したことがありました。その瞬間、 嫌なことを思い出したのか顔を曇らせたり苦笑いをす

    セキュリティーチェックシートという闇への防衛術 - Qiita
  • イラスト生成AIに対するよくある誤解 - Qiita

    イラスト生成AIに対するよくある誤解 目次 イラスト生成AIに対するよくある誤解 目次 はじめに 注意事項 AIは既存のイラストを切り貼りしている/コラージュしている 解説 ベクトルについて 厳密には「切り貼り」も間違いではない AIイラストは既存のイラストの模倣である 解説 AIにひらめきは存在しない 解説 人間のイラストレーターを守るために、AIが描いたイラストを見分けるAIを作るべき 解説 AIで生成されたイラストは画質(解像度)で見分けられる 解説 イラスト生成AIは、学習元のイラストに酷似したイラストを生成する 解説 AIイラストを無断で学習しており違法 解説 AIイラストを学習させるのは無条件で合法 解説 AIが生成したイラストには著作権が存在しない 解説 AIを使えば狙ったイラストを簡単に生成できる 解説 おわりに 参考文献 更新履歴 はじめに Twitterを眺めてい

    イラスト生成AIに対するよくある誤解 - Qiita
    yugui
    yugui 2022/10/20
  • CRDT (Conflict-free Replicated Data Type)を15分で説明してみる - Qiita

    CRDTについて勉強したので纏めてみました。15分くらいでざっとわかったつもりになれる感じで纏めてみたつもりです。 全体スライド Slideshareのスライドが埋め込めなかったので、↓からアクセスしてくださいm(-_-)m 下記はスライドの講演の書き下しのようになっているので、スライドだけ見るんじゃなくて、スライドを見ながら文章を読み進めたい方向けです。 CRDTとは 今回は、CRDTというデータ構造について紹介します。CRDTはそもそも2011年にSSS(Stabilization, Safety, and Security of Distributed Systems)という国際会議で、INRIA(フランス国立情報学自動制御研究所)のMarc Shapiro博士によって発表された、比較的新しいモノです。 CRDTは"Conflict-free Replicated Data Type

    CRDT (Conflict-free Replicated Data Type)を15分で説明してみる - Qiita
  • ソート可能なUUID互換のulidが便利そう - Qiita

    UUIDは重複しないIDを生成する手段として便利ですが、特にversion4(乱数によるUUID)を利用する場合は一意性を得るのと同時に乱雑さも得ることになりますので、UUIDに順序性を求めることができません。 UUID - Wikipedia https://ja.wikipedia.org/wiki/UUID UUID(Universally Unique Identifier)とは、ソフトウェア上でオブジェクトを一意に識別するための識別子である。UUIDは128ビットの数値だが、十六進法による550e8400-e29b-41d4-a716-446655440000というような文字列による表現が使われることが多い。元来は分散システム上で統制なしに作成できる識別子として設計されており、したがって将来にわたって重複や偶然の一致が起こらない前提で用いることができる。 UUIDだと実現できない

    ソート可能なUUID互換のulidが便利そう - Qiita
    yugui
    yugui 2022/02/09
  • なぜエンジニアが作る画面はダサいのか…?「理由」と「対策」を徹底解説【エンジニア向け画面デザイン講座】 - Qiita

    なぜエンジニアが作る画面はダサいのか…?「理由」と「対策」を徹底解説【エンジニア向け画面デザイン講座】UXUIDesignUIデザイン画面設計 1.はじめに エンジニアの私がデザインを気で勉強した結果、デザイナーとエンジニアはそもそも思考が大きく違っているということがわかりました。 今回は「それ」をデザインに苦手意識のあるエンジニア方にも理解してもらえたらと思い、わかりやすくまとめてみました。 2.アプリの画面デザインを考えてみよう まず、こんなアプリを考えてみてください。 フィットネストレーナーが使うアプリ トレーニングルームでお客様とお話しながら使う 端末はタブレット そして 会員の個人情報確認 前回までのトレーニング状況の確認 次回の予約受付 といったことをします。 使える情報としては、こんな感じです。 あなたならどう画面デザインをするか、もしお時間があったら考えてみてください。

    なぜエンジニアが作る画面はダサいのか…?「理由」と「対策」を徹底解説【エンジニア向け画面デザイン講座】 - Qiita
    yugui
    yugui 2021/12/10
  • GAE Flexible Environmentでアプリケーションのログを出力するためにやったこと。 - Qiita

    GoogleAppengine Flexible Environmentでのログ出力 皆さん、アプリケーションを作るときにはログはアプリケーションサーバ上のストレージに吐き出してますか〜?? GAE/go (Standard Environment)ではgoogle.golang.org/appengine/logを利用すればよしなにログビューアーに出力してくれ、ログのフィルタなどもかんたんに行なえ、「なんて素晴らしいんだ!!」と感動したことだと思います。 しかし、GAE/FEでは何もせずともログビューアに出力してくれるというわけではありませんでした。 色々苦労して期待通りに出力するところまでできたので、いろいろ調査したことを含め、いつか誰かの役に立つかもしれないので細かく書いてみようと思います。 ログ出力作戦(第一世代) 最初に考えたログ出力方法としてはStackDriverLoggin

    GAE Flexible Environmentでアプリケーションのログを出力するためにやったこと。 - Qiita
  • Echoを使ってGAE/Go1.12(第二世代)でいい感じにログを出す - Qiita

    概要 GAE第二世代+Go v1.12でechoサーバーを構築する(2019年度版) ではこんなこと書きました。 上記の通り、もう google.golang.org/appengine は使えなくなりました。 代わりに、標準のlogパッケージを使えばいいみたいです。 (省略) うん。こいつは楽ですね。 はい、こんな感じで表示されます。 たしかに表示はされるのですが、以前のGAEログとくらべて非常に貧弱です。このログの出力で開発をすすめるのにはちょっと不安がありました。 AppEngineの第二世代からは、規則にのっとってログを出力する必要があるようです。 https://cloud.google.com/appengine/docs/standard/go112/writing-application-logs ただちょっとそれを独自実装するのは面倒だなーって思ってて、探したところありま

    Echoを使ってGAE/Go1.12(第二世代)でいい感じにログを出す - Qiita
  • StandardSQLのLinterを作りました - Qiita

    概要 StandardSQL(BigQuery)のSQL Linter/Formatterを作りました. 需要はあんまりなさそうですが、せっかくなので内容について少し書いてみます. コードはこちら https://github.com/shigeru0215/sqlint モチベーション 仕事で結構BigQueryのSQLを書くことがあるのですが、メンバによって細かい書き方が違ったのでチーム内でルールを決めました. 理由は、主に見やすさのためです. 例えば、以下のような感じです. select /* 予約後はすべて小文字 */ a /* インデントは4つずつ */ , b /* 改行のカンマは行末ではなく行頭にする */ from table1 as t1 inner join table2 as t2 on t1.x = t2.y /* fromで一段下げ, onでも一段下げる */ w

    StandardSQLのLinterを作りました - Qiita
  • 「分析SQLスタイルガイド」をかなり真面目に考えた - Qiita

    目次 なぜSQLのスタイルガイドが重要なのか この記事の目的 この記事の対象者 分析SQLスタイルガイドの指針 基ルール 命名規則 インデントルール 別名ルール joinルール クエリ分割ルール ⭐ コメント欄で「いや私はこう思う!」という意見をたくさんいただきました!ぜひそちらも御覧ください!(決して揶揄ではないです) なぜSQLのスタイルガイドが重要なのか SQLはプログラミング未経験者でもとっつきやすい言語と言われ、エンジニアや分析を業としていない人でもSQLを使う機会が増えてきていると思います。 そんなSQLですが、こちらのブログでも指摘されている通り、一般的なスタイルガイドが定まっていません。スタイルガイドとはコードの書き方マナーようなもので、どこで改行するか、空白はいくつ入れるか、大文字を使うかなどの諸々を指します。 もしスタイルガイドが無いとこんな事が起こります コードに

    「分析SQLスタイルガイド」をかなり真面目に考えた - Qiita
  • MacOS で opensc-pkcs11.so がうまくいかないとき - Qiita

  • C++標準化委員会、ついに文字とは何かを理解する: char8_t - Qiita

    C++ Advent Calendar 2018 この記事はC++ Advent Calendar 2018 15日目の記事です。 14日目: VTKライブラリ 16日目: C++のエラー処理との付き合い方 当初見積もりよりも大幅に長い記事となり、投稿したのは12/22で1週間遅刻です。すみません。 お知らせ cpprefjpにchar8_t型追加について解説を書きました。ぎゅぎゅっとコンパクトに、また査読を受けて中立的な表現で書いていますので、よければどうぞ。 UTF-8エンコーディングされた文字の型としてchar8_tを追加 - cpprefjp C++語リファレンス 追記 全ての開発者が知っておくべきUnicodeについての最低限の知識 - GIGAZINE Unicodeについて簡潔にまとまってるいい記事を見つけました。 Caution この文章には以下の要素が含まれます。苦手

    C++標準化委員会、ついに文字とは何かを理解する: char8_t - Qiita