Webシステムにおける HTTPサーバ機能をどう用意するか？という問題に対して先人達の葛藤の歴史 | Raccoon Tech Blog [株式会社ラクーンホールディングス 技術戦略部ブログ]
こんにちは羽山です。 現代の Webシステム界隈は昔よりもはるかに洗練され、初心者からでも簡単に開発方法を学び作れる時代になっています。その反面で例えば Python なら WSGI や gunicorn、Waitress、uWSGI などが何のために存在しているのかが分かりにくいと思ったことはありませんか？Ruby の Rack、unicorn、puma だったり FastCGI など、いずれも Webシステムの構成要素として重要な一方で役割を理解しにくいのは事実です。 そこで今回は Webシステムが現代の形にたどり着くまでの先人達の葛藤の歴史を解説します。歴史を知ればこれらの仕様やプロダクトが何の役になっているかが分かるはずです。 前提 動的な Webサイト（＝Webシステム）を作りたいニーズはインターネット黎明期からありますが、ブラウザからのアクセスを適切に処理するには HTTPサー
![Webシステムにおける HTTPサーバ機能をどう用意するか？という問題に対して先人達の葛藤の歴史 | Raccoon Tech Blog [株式会社ラクーンホールディングス 技術戦略部ブログ]](https://cdn-ak-scissors.b.st-hatena.com/image/square/1de4f7647fc73bd264d932c4bca4a75a967a6b04/height=288;version=1;width=512/https%3A%2F%2Ftechblog.raccoon.ne.jp%2Fwp-content%2Fuploads%2F2024%2F05%2Fcloud-3406627_1280.jpg)
なんで今さら帳票エンジンを新規開発しているのか
yagisan-reports開発チームリーダーのterurouです。 デンキヤギでは yagisan-reports という「Webで使うことを前提とした」商用の帳票エンジンを開発しています（厳密にはyagisan-reportsはエンジン単体の製品ではなくクラウドサービスとして開発していますが、この記事では帳票エンジンとして記載しています）。 yagisan-reportsとは 「Webブラウザ単体で動作すること」にこだわっている帳票エンジン です。 2023年11月現在、アーリーアクセス版を提供しています。既に3社5システムで本番稼働しており、一番長いものでは3年ほど本番稼働を続けています。開発中のシステムも含めると、さらに数社あります。 元々はアーリーアクセス版の公開から早めにパブリックベータに移行する計画だったのですが、ありがたいことに早期から大口の導入相談が複数あり、こちらを優
実践要件定義入門 - 勘と経験と読経
最近ネットを見ていると要件定義入門的な記事とか、あと要件定義は不要みたいな記事が目についたので思ったことを書いてみる記事その２。ITシステム開発における要件定義に関するあれこれ。本記事には前編があります。 目次 要件定義以前 要件定義の進め方 IPAユーザのための要件定義ガイドをベースにする 決め過ぎない 機能を定義するのではなく、機能要件を定義する 関係者をすべて洗い出す 利用者マニュアルの目次が作れるようになっているか ビジネス要件定義 前提事項、制約事項とリスクを定義する 優先順位の決定を忘れずに システム化要件定義 不安定な要件を構造で支える おまけ：本記事の元ネタ 要件定義以前 要件定義というプロセスが本当に必要なのか、ということなどは以下の記事に書いたので省略。 実践要件定義入門以前 - 勘と経験と読経 要件定義の進め方 IPAユーザのための要件定義ガイドをベースにする 前編に
【レベル別】要件定義が学べるおすすめ本4選 - みんなのシステム企画
1. はじめよう! 要件定義 ~ビギナーからベテランまで（難度：★☆☆） 1-1. 本のポイント 要件定義のプロセスが平易な言葉で解説されている 内容がコンパクトで図解も多いため読みやすい 中級～上級エンジニアが初心に帰るためにも最適 1-2. 本の特徴 本書は、初学者向けにざっくりとした内容を具体的なアウトプットとともに学ぶことができる。 184ページとボリュームに物足りなさを感じそうだが、要件定義のプロセスと、プロセスごとの勘所がコンパクトにまとまっている。 ちなみに、本書は「要件定義のプロセスと勘所を知れる」という点で独立した書籍だが、著者が書いた下記2冊と合わせると、理解をより深められる。 ・はじめよう! プロセス設計 ~要件定義のその前に ・はじめよう! システム設計 ~要件定義のその後に 本書が有益だと感じた読者は、ぜひ上記2冊にも目を通していただきたい。 1-3. 本を書いた
Linux システムコール 徹底入門
Linux システムコールについて調べたことをまとめる。システムコールの仕組みを理解すると、 OS とアプリケーションがどのように連携して動いているのかを理解できるようになります。 システムコールは CPU に依存する処理が多いため、 x86_64 に絞ります。 検証環境]# cat /etc/redhat-release CentOS Linux release 8.0.1905 (Core) ]# uname -a Linux localhost.localdomain 4.18.0-80.11.2.el8_0.x86_64 #1 SMP Tue Sep 24 11:32:19 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux ]# cat /proc/cpuinfo | head processor : 0 vendor_id : GenuineInte
今さら聞けないログの基本と設計指針 - Qiita
はじめに 皆さんのログに対する理解はどんなものでしょうか？仕組みから設計方法まで完璧に理解しているエンジニアもいれば、なんとなく使用しているエンジニアも多いことでしょう。 ログとは、システムに着いてエラーや障害の発生、利用者による操作や設定の変更、外部との通信などを時系列に記録したものです。ログに関する理解を深めることで、複雑なシステム開発や運用が可能となります。また、AWS、Azure、GCPなどのクラウドサービスを利用している場合はシステムの開発が可能になるだけでなく、経費削減に繋がる可能性も考えられます。 本記事では、ログの基本を押さえるためにその設計方法について解説します。少しでも自信がない方は、ご一読ください。 ログを出力する理由は？ ログの基本や、ログの設計について解説する前にそもそもログを出力する理由を押さえましょう。大きく4つの理由が考えられます。 ・問題が発生した時に調査
１年以上インボイス制度対応をして、業務とシステムを踏まえて法整備がされるべきだと思った - SaaSベンチャーで働くエンタープライズ部長のブログ
受取請求書処理SaaSのプロダクトマネージャーとして、この1年以上プロダクトのインボイス制度対応を行ってきました。 請求書の受け取り、仕訳処理、支払処理などを行うB2BSaaSだったのですが、インボイス制度自体が非常に複雑で対応方法に非常に頭を悩まされてきました。 法制度自体が過度に複雑なため、業務もプロダクトの設計もユーザー体験も複雑にならざるを得ない点を感じました。 インボイス制度は増税観点で批判されることも多いのですが、業務自体の生産性やエンジニアの開発生産性にも影響を及ぼすと感じ、今回は法制度の複雑性に焦点を当てていきます。政治的な内容はあまり書くつもりはないのですが、昨今あまりに業務をおざなりにして法制度が作られることが気になるので課題意識を書いてみたいと思います。 インボイス制度とは インボイス制度によって業務負担が増える 適格請求書を逐一確認する業務負担が増える 適格請求書か
５年やって分かった要件定義に必須な５つのスキルとその上達方法 - みんなのシステム企画
「要件定義のスキルを上げたいけどどうしたら良いかわからない」 こんなふうに悩んだことはないだろうか。 要件定義ではかなり幅広いスキルが求められる。さらに要件定義の対象は毎回異なるため、具体的なレベルでスキルを言語化するのがかなり難しく、どうしてもスキル定義が「コミュニケーションスキル」や「ビジネス理解スキル」といった抽象的な言葉になりがちだ。 そこでこの記事では、要件定義を第一線で実行してきた私が、要件定義を構成するスキルを以下の５つに分解し、それぞれの向上のための方策も可能な限り具体化した。 ・論理的に物事を整理するスキル ・ビジネスの数字を理解するスキル ・業務のフローを理解するスキル ・要求を具現化するスキル ・要求を達成するために必要な機能を洗い出すスキル それでは一つずつ見ていこう。 １ 要件定義をするために必要な5つのスキル この章では、要件定義に必須なスキルとそれがなぜ必要な
「システム設計の面接試験」という本が良かった
皆さんこんにちは。株式会社ラクーンホールディングスで働いている川崎です。 最近「システム設計の面接試験」という本を読みました。 個人的にとても面白いと感じたので、オススメポイントと感想を共有します。 直近でシステム設計の面接を受けない方も、きっと読んで得るものがあると思います。 本の概要 システムの設計はシステムの機能や仕様、データのアクセスやセキュリティを左右するため、非常に重要だが、従うべき一定のパターンがないために、その習得は難しいと言われています。 一方で、システム設計自体がITエンジニアに日常的に求められる作業であるため、システム設計の面接試験は米国で広く採用されています。 本書では、「Webクローラ」「通知システム」「ニュースフィードシステム」「チャットシステム」「youtube」など実践的なテーマに沿って、システム設計の問題を出題し、その回答を解説することで、システム設計力を
プロダクトオーナーの考えるべきところ - kawaguti’s diary
プロダクトオーナー(PO)の考えるべきところ、もしくは「はまりがちな罠」について、いくつかのトピックを思いつくまま書き出してみました。悩めるPOさんの手助けになれば幸いです。 序盤戦、中盤戦、終盤戦の戦略 一番美味しいアイデアがでる可能性に備えるために 引き継ぎにはコストがかかるので人を追加すると遅くなる システムは利用者の数に従って情報が増えるので、リリース後が最も大変な時期になる システムはハーモニーなので、継ぎ足して別の人を追加すると繋がらない あ、よければアギレルゴの認定スクラムプロダクトオーナー研修もご検討ください。著名な講師が通訳付きで教えてくれます。 1. 序盤戦、中盤戦、終盤戦の戦略 「序盤で基礎を作って、作るスピードが上がってきたら、重要なところを作り、最後はウリになるものを作りこんでリリースする。」一見、良さそうに見える戦略ですが、これは結構危うい計画になりがちです。ユ
システム開発に銀の弾丸はないが「金の弾丸」ならある『人が増えても速くならない』
例えばソフトウェア開発において、 人が増えても納期が短くなるとは限らない 見積もりを求めるほどに絶望感が増す 納期をゴリ押すと、後から品質はリカバリできない これを見て、「だよねー」「あるあるｗ」という人は、本書を読む必要はない。 プログラミングは人海戦術で何とかならないし、「厳密に見積もれ」というプレッシャーは見積額を底上げするし、納期が優先されて切り捨てられた品質は、技術的負債として残り続ける。経験豊富なエンジニアなら、大なり小なり、酷い目に遭ってきただろうから。 だが、これらを理解できない人がいる。 要員を追加して、手分けしてやれば一気に片付くはず 厳密にやれば、見積りバッファーはゼロにできる 品質のことはリリース後にじっくりやればいい ……などと本気で考えている。これは、ソフトウェア開発とはどういうものか、特性を知らないからだ。こんな無知な人間が経営層にいたり、顧客の代表となった場
私がインフラ運用保守で意識して行っていること(コラム) - Qiita
～はじめに～ 運用保守は、手順書通りするだけの楽な業務と勘違いしていませんか？ 私は3年間運用保守(インフラ)に携わり、手順書作成や障害対応/調査、運用支援など様々なことを行ってきました。そんな私が思うに運用保守は、全くそんな楽な業務でありません。 運用保守は過信と油断をすれば、すぐに業務影響を出してしまいます。 構築設計段階でのお客様に影響を出すのとは、全く影響度合いが違います。 既に稼働しているシステムで業務影響を出すというのは、エンドユーザーへ多大なるご迷惑をおかけするということ、つまり絶対に許されません。 そんな状況にならないために、私が運用保守をする上で意識して行っていることについて書きたいと思います。 ～運用保守をする上で意識して行っていること～ 1. 簡単な作業や慣れた作業でも慎重に行う 私はどんな作業だとしても、過信や油断をせずに慎重を行うようにしています。 簡単または慣れ
AWSで障害に強いシステムを構築する方法 - Qiita
はじめに 2011年の東日本大震災、これから来ると言われる南海トラフ地震などの大規模な災害や事故に備えるために、災害復旧(DR)が可能なシステムと、その実現手段としてAWSを始めとしたクラウドが長年注目されています。 このDRに関連して、近年「レジリエンス」という言葉が注目を集めるようになりました。 レジリエンスとは、回復力、復元力、弾力などの意味を持つ英単語。IT分野では、情報システムがシステム障害や災害、サイバー攻撃などの問題に直面したとき、迅速に被害からの回復を図り正常な状態に復旧・復元する能力（の大きさ）をこのように呼ぶ。 https://e-words.jp/w/%E3%83%AC%E3%82%B8%E3%83%AA%E3%82%A8%E3%83%B3%E3%82%B9.html AWSでは、2019年8月に大規模障害が発生したことがあり、この時もAZ障害が起きた時に取り得る対策
モダンな要件定義手法「RDRA」をRPGゲーム風にカスタマイズして説明してみた - Goodpatch Tech Blog
この記事はGoodpatch Advent Calendar 2022 18日目の記事です。 ソフトウェアエンジニアの 池澤です。 ここ最近はテクニカルディレクションとして仕事に関わることが増えました。その中で要件定義を作ったりデザイナーとエンジニアの橋渡しをする機会が多く、メンバーみんなが同じゴールを認識して制作できるようなより良い要件定義方法はないものかと探していました。 今回はそんな中で見つけたモダンな要件定義手法の一つ、RDRA（ラドラ）について、理解しやすくなるコツやカスタマイズしている内容についてお話しします。 なお、RDRAの詳細解説をするととても書ききれませんので、RDRA本体の詳細については公式サイト等をご参照ください。 RDRA（ラドラ）とは？ 概要 RDRAのバージョン これまでの要件定義でよくある問題 期待される要件定義の姿 公式サイト おすすめの学び方 実際のRD
シェルスクリプトで安全簡単な二重起動防止・排他/共有ロックの徹底解説 - Qiita
はじめに シェルスクリプトで二重起動防止やロックをする方法を検索すると、いろいろな方法や書き方が見つかりますが、どれを使えばよいのか、本当に正しく動くのか、不安になりますよね？ ディレクトリ (mkdir) やシンボリックリンク (ln) を使った独自実装の例も見かけますが、エラー発生時や予期せぬ電源断、CTRL+C で止めたときなどでも問題は発生しないのでしょうか？ まず、ディレクトリやシンボリックリンクを使った独自実装はしない。これを肝に銘じてください。シェルスクリプトでのロック管理はとても難しく、一般的な排他制御の知識に加えて、シェルスクリプト特有の問題、シグナルやトラップ、サブシェルや子プロセスの問題、さらには特定のシェル固有の仕様やバグなどさまざまな問題に対処する必要があり大変です。独自実装の例では古いロックファイルが残ってしまい、それをいつどのタイミングで片付ければ安全なのか？
わかりやすいシステム構成図の書き方 - Qiita
わかりにくいシステム構成図とは こんなシステム構成図を書いてないでしょうか？ このシステム構成図のわかりにくい点が３つあります。それは 製品名は書いてあるが「役割」が書いていない データと処理が区別できない データの流れと制御の流れが区別できない の３つです。 わかりやすいシステム構成図 これら３つのわかりにくい点を改善したわかりやすいシステム構成図が↓です ポイントを解説していきます ポイント1. 製品名称ではなく「役割」を書く システム構成図には製品名称ではなくシステムコンポーネントの「役割」を書きます。 役割とは、例えば〇〇データや〇〇処理といったことであり、それを読むだけでシステムの動きを理解できる文字列です。役割をかかずに製品名称のみを書いてしまうと、その製品を知らない人が見たときに理解できません。例えば「Cloud Pub/Sub」という製品はGCPというパブリッククラウドの分
上場したばかりの企業などの成長を確認する上で、社員数などが増えているのかを確認する上で便利な日本年金機構の厚生年金保険・健康保険 適用事業所検索システム - ねこぷろ
今日は便利なHPの紹介です 上場したばかりの企業などの成長を確認する上で、四季報などの情報なども薄かったり少なかったりする中で、自分たちで情報を集めることは重要になってくると思います。 成長を確認する上で、社員数が増えるということは今後売上なども増えていくのではないかと推測できたりします。 社員数などが増えているのかを確認する上で便利な日本年金機構の厚生年金保険・健康保険 適用事業所検索システム www2.nenkin.go.jp 厚生年金保険・健康保険 適用事業所検索システム | 日本年金機構 ここで社名や住所などを入力すると 保険などがかけられているかが検索できます。 なので大まかな社員数などが確認できるので、投資する上で参考としているHPです。 www.nekopuro.com
決済システムの残高管理周りの DB 設計と戦略 - カンムテックブログ
エンジニアの佐野です。今日はカンムの決済システムでユーザの残高管理をどうやっているかについて書きます。 カンムの製品であるバンドルカードはプリペイド方式のカードです。ユーザによる入金、店舗での利用、運営事由の操作などによりユーザの残高が増減します。このような残高の管理について単純に考えると user_id と balance と updated_at あたりをもったテーブルを用意して balance と updated_at を更新していく方法があるかもしれません。しかしながらカンムでは残高を管理するテーブルを持たず、これらイベントの履歴のみで残高を管理しています。以下、本記事ではこれらユーザの残高が増減するイベントのことをトランザクションと呼びます。ここでは DB の Transaction Processing を意味しません。 本記事のポイントは 残高を管理をするテーブルは作らず、ト
システム開発でよくある「ごん、お前だったのか」現象と依存関係、そして汎用性の罠の話 | Raccoon Tech Blog [株式会社ラクーンホールディングス 技術戦略部ブログ]
株式会社ラクーンホールディングスのエンジニア/デザイナーから技術情報をはじめ、世の中のためになることや社内のことなどを発信してます。 マネジメント要求定義教訓ごんおま現象依存関係ツリー思考法カオスエンジニアリングフェイルファスト技術的負債 こんにちは、羽山です。 昔話には生きる上での数多くの教訓が込められています。今回は ごんぎつね からシステム設計・開発について考えてみましょう。 ごんぎつねの話はみなさんもご存じの通り、いたずらを悔いたごんぎつねが人知れず兵十という青年に贈り物を届けるも最後まで気づかれないまま火縄銃で撃たれてしまい、最後に「ごん、お前だったのか」となる話です。 さて、 達人プログラマー という書籍には 契約による設計(Design by Contract) という考え方が解説されています。 メソッドを契約として、 要求された以上のことも以下のことも行わない という考え方
![システム開発でよくある「ごん、お前だったのか」現象と依存関係、そして汎用性の罠の話 | Raccoon Tech Blog [株式会社ラクーンホールディングス 技術戦略部ブログ]](https://cdn-ak-scissors.b.st-hatena.com/image/square/3217596b6f99827b6c459e87b57424ec5d55842f/height=288;version=1;width=512/https%3A%2F%2Ftechblog.raccoon.ne.jp%2Fwp-content%2Fuploads%2F2021%2F05%2Fsystem_dependencies_1280.jpg)
perfを用いたシステムのボトルネック解析方法
背景システムの処理速度を改善するために、ボトルネック解析を行う必要があった。 ボトルネック解析の方法と、プロファイリングに使用したperfの使用方法に関して調査を行った。 記事の目的perfを使用し、ボトルネック解析を行う ここでは、perfの導入方法及び使用方法について記載する。 perfとはperf(Performance analysis tools for Linux)とはLinuxカーネル2.6.31以降で使用可能なLinuxの性能解析ツールである。 実行されているプロセス毎のCPU使用率やプロセス内で呼ばれている関数の割合などを調査できる。 利点gprofのように、プログラム作成時に専用のライブラリを入れたり、コンパイル時にオプションをつける必要がない フレームグラフにして、ビジュアライズできる 導入方法(Ubuntu編)Ubuntu16.04へperfを導入する手順について記
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
