タグ

システムに関するWackyのブックマーク (7)

  • なぜ、組織のつくりとソフトウェアアーキテクチャは似てしまうのか - Qiita

    このエントリーは、Engineering Manager Advent Calendarの25日目、最終日の記事です。 はじめに 拙著「エンジニアリング組織論への招待」では、ソフトウェア自体の構造とソフトウェアを作り上げる組織の構造が似てしまうという「コンウェイの法則」についてたびたび引用しました。 この「コンウェイの法則」は、ある一定規模の組織で働いたことのあるエンジニアであれば、実感を持って捉えることができるのでしょう。 しかし、何故、どのような力が働いて、「組織構造」と「ソフトウェアの構造」が似通ってきてしまうのかと問われると説明の難しいものです。 拙著においては、ロナルド・コースの取引コスト理論をベースに、社内取引においても取引コストが存在し、その取引コストがソフトウェアの構造をも変えていくという説明を行いました。 記事は、さらに踏み込んで、組織やビジネスに働く力学と、システムで

    なぜ、組織のつくりとソフトウェアアーキテクチャは似てしまうのか - Qiita
    Wacky
    Wacky 2018/12/25
    “組織の構造とシステムの構造が相似形になってしまうのであれば、プラスの価値のある組織からは優れたアーキテクチャが生まれ、逆にマイナスの価値を持った組織からは技術的負債が生まれるようになるということが導
  • 本当は恐ろしい分散システムの話

    分散システムのFault Injectionの話 NTTデータテクノロジーカンファレンス2017で発表する際に用いたプレゼン資料 https://oss.nttdata.com/hadoop/event/201710/index.html Read less

    本当は恐ろしい分散システムの話
  • 処理速度の遅いcurrentTimeMillis() – 後編 | POSTD

    私は以前、Linuxでのシステムコールはとてつもなく高コストだと思っていましたが、この測定で、その考えが誤っていたことが判明しました。実際にはシステムコールにコストはかかりますが、例えば、L3キャッシュミス(100ns)に比べれば低コストです。 ただし、行われるアクションが短いとしても(TSCベースの gettimeofday 向けだから)、システムコールを避ける方が有利です。その場合は、vDSOの方が断然役に立ちます。私たちのケースでは、ほぼ3倍実行が速くなりました。 どうすればいいのか 最良の方法は、TSCタイムソースを持つWindowsまたはLinux以外では絶対にプログラムを実行させないようにすることです。それが不可能なら、純粋なJavaの中にいながらこの呼び出しを高速化する方法はなく、解決策は、 currentTimeMillis() があまり頻繁に呼び出されないようにすることで

    処理速度の遅いcurrentTimeMillis() – 後編 | POSTD
    Wacky
    Wacky 2017/10/24
    “Linuxでは、nanoTimeのパフォーマンスはTSCモードではほとんど十分ですが、HPETモードでは不十分です。”
  • ラズパイでケチケチ勤怠管理システム、Speeeが内製

    会社のオフィスの出入り口にある打刻機のカードリーダーにSuicaiPhone 7、Apple Watchをかざすだけで、従業員の出退勤時間が自動的に記録される。そんな勤怠管理システムを、Speeeが自社向けに開発し、2017年4月初めから運用を開始した。特徴は、打刻機に小型コンピュータ「Raspberry Pi」(以下、ラズパイ)を採用することで、機器のコストを大幅に下げた点だ。 いちいちWebページを開くのは面倒 Speeeは、Webマーケティングやインターネットメディアの運営を手掛けるIT系ベンチャー企業である。同社の以前の勤怠管理システムは、PHPで書いたWebアプリケーションだった。従業員が出退勤時にWebページを開きボタンを押して、出退勤時間を打刻していた。しかし、いちいちWebブラウザーを立ち上げてボタンを押すのは意外に面倒。毎日のこととなると、日常的に打刻漏れが発生していた

    ラズパイでケチケチ勤怠管理システム、Speeeが内製
    Wacky
    Wacky 2017/05/10
    “NFCを利用するための「nfcpy」というモジュールがPythonで書かれていたためだ。Felicaの固有番号をユーザー情報にひも付けることで、カードによる打刻を実現している。”
  • 読書メモ・詳解システムパフォーマンス 第4章/可観測性ツール - えいのうにっき

    「詳解システムパフォーマンス」の読書メモシリーズ・第3弾。 詳解システムパフォーマンスを読んでいる話・2章/メソドロジ 読書メモ - えいのうにっき 読書メモ・詳解システムパフォーマンス 第3章/オペレーティングシステム - えいのうにっき 詳解 システム・パフォーマンス 作者: Brendan Gregg,西脇靖紘,長尾高弘出版社/メーカー: オライリージャパン発売日: 2017/02/22メディア: 単行(ソフトカバー)この商品を含むブログ (1件) を見る この回はなんだっかの理由で輪読会に参加できなかったので、前回のような「輪読会の場での話題」みたいなのはなし。スミマセン。 感想 僕自身が システムエンジニア -> PaaS(GAE)エンジニア -> Web アプリケーションエンジニア -> セールスエンジニア(イマココ) 、というキャリアを踏んできたこともあってか、「システムが

    読書メモ・詳解システムパフォーマンス 第4章/可観測性ツール - えいのうにっき
  • 詳解システム・パフォーマンス 3章「オペレーティングシステム」輪読メモ - ゆううきメモ

    詳解システム・パフォーマンス 第2章「メソドロジ」メモ - ゆううきメモ の続き。今回は第3章「オペレーティングシステム」 システムパフォーマンス分析では、オペレーティングシステムとそのカーネルについての理解は必要不可欠だ。システムコールがどのように実行されるか、CPU がどのようにスレッドをスケ ジューリングするか、限られたメモリがパフォーマンスにどのような影響を及ぼすか、ファイルシステムは I/O をどのように処理するかなどのシステムのふるまいについて、あなたは頻繁に仮説を立て、それをテストすることになる。これらのふるまいを理解するためには、オペレーティングシステムとカーネルの知識を使わなければならない。 Brendan Gregg,西脇靖紘,長尾高弘「詳解システム・パフォーマンス」, オライリージャパン p.85 議論 章の内容をベースに議論

    詳解システム・パフォーマンス 3章「オペレーティングシステム」輪読メモ - ゆううきメモ
    Wacky
    Wacky 2017/04/16
    “epollはカーネル側でディスクリプタの状態をもつので、状態変化したものだけユーザー空間に返すことができる (エッジトリガ通知)。”
  • 1