タグ

関連タグで絞り込む (13)

タグの絞り込みを解除

*資料とarchitectureに関するch1248のブックマーク (12)

  • どのレイヤー（層）でトランザクションを実装すべきか


    このように、層ごとに関心事の分離を行うことで、保守性の高い︵変更容易性や再利用性等︶アプリケーションを実現できます。 しかし、﹁トランザクション﹂においてはどうでしょうか。 トランザクションはビジネス領域においても、技術領域においても関心事がある内容です。 そういう曖昧なものは﹁ひとまず usecase 層に入れてしまえ﹂という方針になりがちです。 ですが、DB 固有の知識を usecase 層の関心事にしてしまっては、関心事の分離をするメリットが得られません。 そのため、関心事の分離を実現しつつトランザクション実装をする方法を模索してみました。 前提 1. クリーンアーキテクチャを採用している︵オニオンアーキテクチャやレイヤードアーキテクチャも含む︶ そもそもビジネス知識と技術知識を分離していないアーキテクチャを採用している場合、メリットは得られません。 そのため、オニオンアーキテクチャ
    どのレイヤー（層）でトランザクションを実装すべきか
    ch1248
    ch1248 2024/03/03
    いいですね
    リンク

  • ソフトウェア設計・アーキテクチャの学び方 - Qiita


    はじめに この記事はHow to Learn Software Design and Architecture | The Full-stack Software Design & Architecture Mapを翻訳したものです。 翻訳がおかしい箇所などあればご指摘頂けるとありがたいです。 元記事の著者: Khalil Stemmler(@stemmlerjs) 設計、アーキテクチャ、フロントエンド、ブロックチェーンに興味ある方是非Twitter(@show_clements)フォローしていただけると嬉しいです！ 設計に関する記事 ソフトウェアデザインとアーキテクチャは、DevOpsやUXデザインのように、コンピューティングの領域の中でも独自の研究分野となっています。ここでは、クリーンコードからマイクロカーネルまで、ソフトウェアデザインとアーキテクチャの幅広さを説明するマップを紹介しま
    ソフトウェア設計・アーキテクチャの学び方 - Qiita

  • Re: ブロックチェーンでそんなことはできない - Software Transactional Memo


    はじめに chike0905.hatenablog.com この記事は大変楽しく拝読したが、ブロックチェーン素人ながら気になる点がいくつかあったので指摘する。要旨は以下である。 タイトルで﹁できない﹂と言ってる割には﹁できるけど筋が悪い﹂だけに見える 研究中で結論が出ていないトピックを﹁できない﹂と呼ぶのは違うのではないか 文体が学術めいている割には用語の使い方がやや雑に見える ブロックチェーンに﹁不可能﹂な事にフォーカスすべき 浮足立つ界隈に対して問題提起するならば的を絞って指摘すべきで、容易に解決可能そうに見えてしまう批判はかえって混乱を招く恐れすらある ノードの独立性 各自で検証し、他のノードに依存するプロセスは本定義のブロックチェーンの動作の中には含まれない。 従って、他のノードに何かを問い合わせる必要もなく、信頼する第三者などは存在しない。 この部分はあまり正しく理解している人が
    Re: ブロックチェーンでそんなことはできない - Software Transactional Memo
    ch1248
    ch1248 2022/05/30
    例の記事への返信。
    リンク

  • ブロックチェーンでそんなことはできない - chike0905の日記


    概要 本稿は、突然ムシャクシャした筆者が自分の考えるブロックチェーンの定義と、世間で言われているブロックチェーンの特性および応用例を批判するものである。 本稿は筆者の見解であり、所属組織の公式見解ではない。 ブロックチェーンの定義 そもそもブロックチェーンとはなんなのか。狭義には、﹁ブロック﹂の﹁チェーン﹂であることから、以下の定義をしたい。 データが、当該データ直前のデータの暗号学的ハッシュ値を持つリスト型のデータ構造 ここでは、そのデータの中に何を保持するかは一切考慮しない。 データがハッシュ値で連鎖することによって、リスト中の任意のデータのみを書き換えると、ハッシュチェーンの整合性が失われ、書き換えが行われたことを検知可能なデータ構造であると定義する。 しかし、世間で﹁ブロックチェーン﹂に興味を持つ諸氏はこの定義だけではいささか狭すぎると感じるだろう。 そこで、狭義のブロックチェーン
    ブロックチェーンでそんなことはできない - chike0905の日記
    ch1248
    ch1248 2022/05/28
    わかりやすかった。NFTの固有性担保はブロックチェーンとP2Pは技術的には関係が無く、Ethereumから始まった非代替性トークンの機能を指すようだ。※Wikipedia含め各所で混乱が見られる
    リンク

  • コアを多数搭載するCPUは「POSIX」によって能力を制限されているとの指摘

    by Rudolf Schuba UNIX系のOSに共通する機能の呼び出し方法などを定めたPOSIXは、「POSIXに準拠するならばどんな環境でも動作する」ことを保証する規格です。POSIXは長年移植可能なアプリケーションの開発を支えてきましたが、システム管理者のチャールズ・フィッシャー氏は「POSIXがマルチコアCPUの能力を制限する要因となっている」と指摘し、「xargs」コマンドを例として具体的な説明を行っています。 Parallel shells with xargs: Utilize all your cpu cores on UNIX and Windows | Linux Journal https://www.linuxjournal.com/content/parallel-shells-xargs-utilize-all-your-cpu-cores-unix-and-

    コアを多数搭載するCPUは「POSIX」によって能力を制限されているとの指摘
    ch1248
    ch1248 2021/02/28
    なるほど
    リンク

  • サイバネティクスの周辺についての個人的雑感｜tenjuu99

    現象学者たちとサイバネティクス「サイバネティクス」なるものに興味を持った経緯としては、メルロ＝ポンティが『眼と精神』で一章まるごと使ってサイバネティクスを批判しているからでした。長いのですが引用します。 世界を名目的に定義すれば、世界とは私たちの操作の対象Xである、となろうが、そのように語ることは、科学者の認識のあり方を絶対視することであり、それはまるで、かつて存在し、また現に存在しているすべてのものを、たんに実験室に入るためだけに存在してきたかのように見なすことである。「操作的」思考はある種の絶対的人工主義となり、サイバネティクスのイデオロギーに見られるように、そこでは人間の創造活動は情報の自然的プロセスから派生したものとなってしまうが、じつは、そのプロセス自身、人間機械をモデルに考えられたものなのである。もしもこの種の考え方で人間と歴史を捉えようとするならば、そしてもし、私たちが直接的

    サイバネティクスの周辺についての個人的雑感｜tenjuu99

  • Appleを追い出されNeXTを立ち上げたスティーブ・ジョブズを間近に見ていたエンジニアたちの証言


    1985年にAppleを追放されたスティーブ・ジョブズ氏が創業した﹁NeXT﹂は教育用・ビジネス用のワークステーションのメーカーで、1996年にAppleに買収され、ジョブズ氏がAppleに返り咲くきっかけとなりました。NeXTが開発したオブジェクト指向型OS﹁NeXTSTEP﹂はその後のmacOSやiOSの基盤となっています。さまざまな質問に対して専門家が回答する質疑応答サイト﹁Quora﹂に投稿された﹁NeXTのエンジニアはどんな感じで働いていたのでしょうか？ジョブズ氏は普段から従業員と交流していたのでしょうか？﹂という質問に対して、当時を知るエンジニアたちが回答しています。 What was itlike to be a software engineer at NeXT? Did workers interact with Steve Jobs? - Quora https://
    Appleを追い出されNeXTを立ち上げたスティーブ・ジョブズを間近に見ていたエンジニアたちの証言
    ch1248
    ch1248 2020/11/30
    知らんエピソードが多くて面白いな。控えめだったり、反省が窺える発言がある。
    リンク

  • 自作OSとかLinuxカーネルについて役立った本 - Qiita


    はじめに なんらかの理由によってOSやOSカーネルに興味を持つ人は多々います。しかし、その次のステップとしてどんな本を読めばいいんだろうと思っている人はこれまたいっぱいいます。そこで、長年Linuxカーネルにかかわってきた筆者がこれまでに読んでよかったと思うものについてここの列挙しました。紹介するのは本だけであって、記事は省いています。もう一点、筆者が書いたものは省いています。OSそのものに興味を持った人は、その後に興味の方向が次のような二つに分かれることが多いと筆者は考えています。 オレオレOSを作りたい 既存のOSを改造したい この仮説をもとに、それぞれについて筆者がかつて真面目に読んだ本の中から﹁自作OS﹂および﹁Linuxカーネル﹂というキーワードでよかったものを挙げておきます。Linux以外の既存OSについては語れるほどの知識はないので書いてません。 筆者について 本の良し悪し
    自作OSとかLinuxカーネルについて役立った本 - Qiita

  • 技術的負債の返済プロジェクトが失敗する 11 のワケ - jfluteの日記

    ワケ一覧 序の口: フレームワークだけが負債だと思ってる 序二段: ビジネスサイドに理解してもらう努力がない 三段目: 技術で遊び過ぎてしまう 幕下: 太り過ぎアーキテクチャ 十両: 過去に目もくれず、現状だって見ない 前頭: 技術に詳しいだけでアーキテクト 小結: アーキテクトの知識と覚悟が足りない 関脇: スパンが長く、モチベーションが続かない かど番大関: スパンが長く、人の入れ替えでチグハグ 大関: アーキテクチャデザインはどこへ？ 横綱: 実は人間的負債だった 序の口: フレームワークだけが負債だと思ってる みんな、フレームワークが大好き。とはいえ、さすがにみんな、「フレームワークが古いことだけが負債」だなんて思ってないはずだが...なのに多くの人が、あたかもそのような振舞いと判断をしてしまう。潜在意識の Big Issue だから？ o 信用できないテストデータ も負債 o 現

    技術的負債の返済プロジェクトが失敗する 11 のワケ - jfluteの日記

  • 確率的に犠牲的 - steps to phantasien


    Martin Fowler が Sacrificial Architecture と言い出した時は驚いた。“変化を受け入れよ” はどこにいったの。書き直しはダメと自分の中の結論が出たのは随分前のことだけれど、ひさしぶりに考え直してみる。 Sacrificial Architecture の論拠として Martin Fowler はいくつかのインターネッツ企業を例にとっている。でも一般化するには偏ってないか。それにこれら企業が面していたのはごく限られた種類の変化だ: 彼らはもっぱら性能不足と戦っていた。 機能の変化に強いコードは柔軟性の裏で性能を犠牲にしがち。機能の変化を捉えることに先鋭化した従来の Agilityは性能要件の変化を必ずしもやり過ごせない。一方で存在感を増すスタートアップの世界では性能への期待が当たり前のように大きく変わる。だから Agile はあてにならない、堅牢なアーキ

  • ドメイン駆動設計読んだ - hitode909の日記


    ドメイン駆動設計というのはソフトウェア工学のおしゃれな本で，Kindleで買えたので読んだ．ドメインを軸に戦略的に設計しましょうという本．2週間くらいで読めて良い体験できてよかった． ソフトウェアを，ユーザーインタフェース，アプリケーション，ドメイン，インフラストラクチャという4つの層に分けて，一番重要なのがドメイン層で，ドメイン層にアプリケーションが存在し得る理由がある．銀行システムだったら，口座とか利子みたなやつがドメイン層で，口座がよくできてると銀行としてうまくいく．ATMのタッチパネルというのはユーザーインタフェースで，どんなにATM押しやすくても，ドメイン層に，口座という概念がなくて，ただのハッシュだったりすると，銀行を運営して金を儲けるとか，新たな金融商品とか作るのが困難になる．インフラ層は永続化とかするのだけど，インフラ層がいかによくても，意味ないデータを保存していては銀行倒
    ドメイン駆動設計読んだ - hitode909の日記

  • MVCの流れを簡単にまとめてみる - Qiita [キータ]


    理解しやすいように適当に遮ったり、言い切ってしまったところもあるがご容赦いただきたい。 MVCの登場 MVCは、SmalltalkのGUIライブラリのモデルとして登場した。 これはGUIアプリケーションを記述する際に、適切なモデル化を進めるのにとてもいい考え方だと思われていたし、実際にそうだった。 これはアーキテクチャパターンとして、それぞれがどのように依存するべきか、どこにコードを書くべきかということを端的に表している。 安定依存の原則というものがある。これは、要件が安定しているモジュールに依存し、要件が変動しやすいモジュールには依存しないようにするという原則だ。MVCアーキテクチャでは、GUIアプリケーションの安定関係をModel > View > Controllerの順でとらえている。データ処理や業務要件というのは安定しており、UIパーツもまた比較的安定している。それらを統合してア
    MVCの流れを簡単にまとめてみる - Qiita [キータ]
  • 1

お知らせ

もっと読む

公式Twitter

  • @HatenaBookmark

    リリース、障害情報などのサービスのお知らせ

  • @hatebu

    最新の人気エントリーの配信

はてなブックマーク

公式Twitter

はてなのサービス

  • App Storeからダウンロード
  • Google Playで手に入れよう
Copyright © 2005-2024 Hatena. All Rights Reserved.