ソフトウェアアーキテクチャ・ハードパーツ - Forkwell Library #12 での発表資料です https://forkwell.connpass.com/event/265858/ 動画: https://www.youtube.com/watch?v=6eCiC8oISYc #Forkwell_Library
こんにちは。モノタロウの八木(t_yagi)です。 モノタロウのECシステムは創業から20年以上ずっと動き続けており、絶え間なくビジネスを支え続けています。 その間、周囲のIT技術も大きく進歩してきました。 そんな中、開発者が増えたり機能も拡張され続けた結果、当初はさほど問題にならなかった開発に関する課題が浮き彫りになってきました。 今回はそんなレガシーな開発環境にモダンなIT技術を取り入れることで「当時は出来なかったことを現代の技術で実現する」を書きました。 流行りのモダンな技術がイケイケだから乗り変えるといったような輝かしいものではなく、長年積まれ続けてきた課題が現代の技術だから解決できたという時代の恩恵にうまく乗れるかを率直に記事にしています。 どうするとデメリットを抑えながらメリットを得ることができるか読んでいただける人に少しでも感じ取っていただければ嬉しいです。 サーバアプリの開
「禅とオートバイ修理技術」これら2つの間にどのように関係があるのかまるで見当が付かず、タイトルだけ聞くとキワモノのようだがWikipediaによるとアメリカでは一番良く売れた哲学書とされている。 海外のエンジニアのブログを読み漁っていた時にオススメされていたのでKindleで買って読んだのだが想像以上に良かったのでメモを残したい。と言ってもwikipediaで説明されている内容を改めて説明しても面白くないのでソフトウェアエンジニアとして響いた部分を引用して僕の感じた事を書き連ねていく。 大都市の重工業地帯に一歩でも足を踏み入れてみれば、そこにはその全てが存在している。テクノロジーである。正面には有刺鉄線を施した高い塀が立ちはだかり、門は常に閉ざされ、「立入禁止」の札が掛かっている。そしてその向こうの薄汚れた大気の中には、金属や煉瓦で造られた醜い建物が立っている。その目的は不明であり、またそ
(6/22 注:書き足りないと思っていた箇所を補って加筆修正しました) エンジニアのbonotakeです。Ideinに入ってかれこれ3年以上経ちますが、Ideinでブログ記事を書くのは初めてです。 今日は、ソフトウェア設計の全く新しい考え方について書かれた "The Essence of Software" という本の紹介をしたいと思います。 この本の著者はMIT教授でソフトウェア工学の世界的な研究者であるDaniel Jacksonです。形式手法Alloyの発明者、と言ったほうが通じる人には通じるかもしれません。形式手法とは、ありていにいえば、数理論理学を駆使してソフトウェアに潜むバグを論理的に駆逐する手法です。 (個人的な宣伝ですが、彼の書いたAlloyの本を以前翻訳して出版しました。) そんな彼が昨年11月に新著を出版したというので、ほぼその日に買いました。……ですが、本を開いてみる
経済産業省は「ソフトウェア管理に向けたSBOM(Software Bill of Materials)の導入に関する手引」を策定し公開したことを明らかにしました。 SBOMは日本語では「ソフトウェア部品表」とされます。あるソフトウェアがどのようなソフトウェア部品によって構成されているのかを示す情報がまとまったデータのことです。 ほとんどのソフトウェアは単独で成立しているわけではなく、オープンソースを始めとする多数のライブラリやコンポーネントなどのソフトウェア部品に依存しています。そのなかのいずれかに脆弱性が発見されればドミノ倒しのように他のさまざまなソフトウェアに影響することは必至です。 例えば2021年末に発覚したJavaライブラリ「Log4j」の脆弱性は、非常に幅広いJavaのソフトウェアに深刻な影響を与えました。 多くの産業や社会インフラにおいてソフトウェアの存在が欠かせなくなってい
Microsoft での勤務経験を持ち Stack Overflow の創業者でもある Joel Spolsky によるエッセイ集。 Joel は自身が運営するウェブサイト Joel on Software で多数の記事を公開しており、その一部を掲載したのが本書。 ひとつひとつの章がかなり短い(長いものでも 20 ページくらい、短いものだと 4 ページほど)ので気軽に読めるし、各章は独立しているので興味のある部分だけ読むこともできる。 技術そのものについて解説している技術書ではなく、ソフトウェア開発やソフトウェア産業についての著者の考えが書かれており、 Paul Graham の『ハッカーと画家』にテイストが近いかもしれない。 無料で公開されているエッセイ集をまとめたもの、というのも『ハッカーと画家』に似ている。 本書に収録されているのは 2000 年から 2004 年に書かれた記事なので
こんにちは。中山(id:yoichi22) です Software Designに連載させていただいております「Pythonモダン化計画」では、モノタロウの社内事例から読者の皆様のお役に立ちそうな取り組みを紹介させていただいています。のですが、社内でも隣のチームがやってた取り組みを記事で初めて知ることもあって、私も読者として楽しませてもらっています。隣の執筆者さんありがとうございます。 今回は、運用にまつわる監視とログの話題です。本記事の初出は、Software Design2022年1月号「Pythonモダン化計画(第6回)」になります。過去の連載記事は以下を参照ください。 第1回 Software Design連載 2021年8月号 Python製のレガシー&大規模システムをどうリファクタリングするか 第2回 Software Design連載 2021年9月号 「テストが無い」からの
Beginners who want to get into the software field often get programming and software engineering mixed up. These are not the same thing. Programming is a part of software engineering. Software engineering on the other hand, encompasses so much more than programming. Software engineering is the process of starting with a problem, designing a way to solve that problem, and then delivering a software
前回の記事に更に返事を頂いた。応酬が全部長文なのでこの記事から読み始める人は「まとめ」から読んで興味が湧いたかどうかで全文を追うか検討して欲しい。 sasakill.substack.com まさか本当に返事が貰えるとは思っていなかったが、実に興味深く、かつ知見として共有すべき事が書いてあったので「いつまでそのネタ擦ってんだよ」と突っ込まれるのを覚悟の上でさらなる返事をまとめる。 kumagiさんは「アテンション・エコノミーが最高であるとは思っていないが、市場の競争によって良い体験が生まれていることは認める」というもので、一方私は「アテンション・エコノミーの影響力が強くなりすぎていて、それ以外の良い体験の可能性を押しつぶしている」ととらえている。 これは確かにそうで40億回/日の再生数のうちどれだけが真にユーザーの利益になったかどうかについて僕は何らコメントできる立場にない。全ユーザーが全
Photo by charlesdeluvio on UnsplashWhy Should We Care About Design PatternsSimply put, design patterns help us solve problems by creating a reusable solution that we can use as a template for our software. That being said, design patterns aren't algorithms and you can't paste them into the code base. They give you a template of sorts, but if misused some patterns may cause additional complexity an
こんにちは! CData Software Japan リードエンジニアの杉本です。 大変ありがたいことに、最近あるSaaSを提供する会社さんから「リリース前のAPIを触ってみてフィードバックをくれませんか?」と依頼を受けました。 私は以前こんな記事 を公開するほど、APIどっぷりな人間なのですが、数多くの SaaS APIを触ってきてよく考えることがあります。 それは SaaS APIというサービス・プロダクトそのものを成長させる上で、もっとも重要なことは「顧客・デベロッパーが、そのAPIをどれだけスムーズにキャッチアップできるか?」という点に尽きるのではないか? というものです。 以下のグラフはAPI管理ツールを提供するSmartBearのAPI調査において、APIドキュメントで最も重要な要素とは何か? というアンケート結果のランキングですが、ExamplesやAuthenticati
こんにちは。モノタロウで開発を担当している河本です。2021年7月から2022年2月に技術評論社様で発刊されている Software Design にモノタロウにおけるPython大規模開発に関する取り組みを連載させていただきました。そして無事に8か月分の雑誌連載を完遂することができました。ここでは、雑誌連載プロジェクトの体制やスケジュール、成功させるために取り組んだことについてご紹介します。 Software Designの記事の再紹介 連載のきっかけと狙い プロジェクト体制 スケジュール プロジェクトを成功させるために取り組んだこと さいごに Software Designの記事の再紹介 全8回の連載のテーマは「Python」、「大規模」、「レガシー」の3本柱でした。 連載してきた記事は以下になります。 第1回 Software Design連載 2021年8月号 Python製のレガ
This is our 200th episode, so I wanted to do something special. Everyone loves to complain about the poor quality of Japanese software, but today I’m going to explain exactly what went wrong. You’ll get the whole story, and I’ll also pinpoint the specific moment Japan lost its way. By the end, I think you’ll have a new perspective on Japanese software and understand why everything might be about
新年あけましておめでとうございます。モノタロウでエンジニアをしております大西です。本年もよろしくお願いいたします。 本年もMonotaRO Tech Blogでは社内の様々な取り組みを定期的に更新して参りますので、お時間の空いた際にお読み頂けると嬉しく思います。皆様のお役に少しでも立つことができれば幸いです。 今回は、リリースにかかる時間の増加や、リリースに関する作業の属人化を体制変更によって解消した経緯と、大規模な開発体制におけるリリース作業や監視業務でのエラーやアラートの管理方法についてご紹介します。 本記事の初出は、 Software Design2021年12月号「Pythonモダン化計画(第5回)」になります。 過去の連載記事は以下を参照ください。 第1回 Software Design連載 2021年8月号 Python製のレガシー&大規模システムをどうリファクタリングするか
こんにちは、辰巳です。 第3回は「スナップショットテスト」をテーマにお送りします! 「組織が拡大する中で、十分な設計情報がない状況でも、複雑に改修が積み重なったソフトウェアをいかに安全かつ正確に変更できるか?」 本記事では、数多くの大幅なシステム変更の経験を経て、この課題に対してモノタロウがいま実践しているグッドプラクティスを紹介します。 本記事の初出は、 Software Design2021年10月号「Pythonモダン化計画(第3回)」になります。過去の連載記事は以下を参照ください。 第1回 Software Design連載 2021年8月号 Python製のレガシー&大規模システムをどうリファクタリングするか 第2回 Software Design連載 2021年9月号 「テストが無い」からの脱却 スナップショットテストの可能性を追求する モノタロウは、事業者向けの間接資材を販売
ソフトウェアエンジニアリングを支える組織のように職人の集まった組織には、無意識に持っている「好き嫌い」の性向がある。 これをハビトゥスという。 これは「好き嫌い」であるので、思ったまま口にすると独善的に聞こえ、幼稚な印象を与えてしまう。 このような「好き嫌い」という性向に基づいて、習慣的な行動がうまれ、それが同じような性向を持った人々を引き寄せるようになる。 この習慣的行動は、当初から合理的に説明可能なものばかりではない。 そうであるがゆえに、「当たり前」だと感じるものしか、取り入れられない。 そのため、当たり前の距離、常識の距離が遠くなればなるほど、 文化資本を組織に身につけにくい。 一方で、当たり前の距離を縮めることに成功した企業は、 徐々にエンジニアが事業部門に溶けていくことになる。 当然、衝突もあるが、融和も果たす。 これは水と油が溶け合っていく現象 「エマルション」に似ている。
技術部でRubyインタプリタの開発をしている笹田です。コロナの影響で、リモート勤務などに移行し、新しい生活スタイルを満喫されている方々がたくさんいらっしゃるんじゃないかと思います。ただ、私は以前から自主的に自宅勤務することが多かったので、正直生活がぜんぜん変わっていません。 さて、家で私が何をしているかというと、Ruby 3の準備です。その中でも、数年取り組んできた Ruby で並列処理をするための仕組みである Ractor の開発をしています(以前は Guild というコードネームで呼んでいました)。Ractor という名前は、Ruby の Actor みたいな意味で付けました。Erlang とか Elixir で有名な Actor model というアレです。厳密には、Actor model でよく言われる特性をすべて備えているわけではないのですが、並列で動く Ractor を複数作る
Web開発の歴史の復習の仕方 悲報: WEB+DB PRESSが休刊 22年以上続いていたWEB+DB PRESSが休刊するそうです。Software Design、WEB+DB PRESS共に年間購読していたのですが、とても残念です。 日本語と英語、少し中国語の技術書を普段から読み漁っているのですが、本ほどガッツリでなく、ブログよりはちゃんとバリデートされた上でトレンドをおさえた雑誌文化は割合日本的で、他の言語圏だとあまりない文化だとも感じています。 技術評論社からでているSoftware Design、WEB+DB PRESSなのですが、Software Designの創刊が1990年11月で、WEB+DB PRESS Vol.1が2000年12月で10年の差があります。 どちらかというとSoftware Designがインフラ&バックエンドでWEB+DB PRESSがバックエンド&ク
As someone makes more money, expenses once considered luxuries can suddenly become seen as necessities: It’s called lifestyle creep. In the world of software development, we can suffer from a similar affliction: stack creep. Where hardware limitations once restricted developers to a minimalist approach, increased processing power, memory, and storage have led many down a more maximalist path. It’s
リブセンスでデータエンジニアをしている富士谷です。 Software Designのデータベースに関連する特集記事を再構成した「データベース速攻入門 ~モデリングからSQLの書き方まで」が、2023年3月に発売されました。 gihyo.jp リブセンスがSoftware Design 2017年11月号に寄稿した「データ分析に効くSQL50本ノック」が、内容を更新して再掲載されました。 今回、再掲載にあたって、「SQL50本ノック」の内容の更新を私が担当しましたので、簡単に紹介します。 SQL50本ノック 「SQL50本ノック」は、SQL、特にSELECT文の演習問題集です。 PostgreSQLをDockerで立ち上げて、もっともシンプルな例から実行し、WHERE句、LIMIT句などを一つ一つ体験し、最後には、移動平均といった高度な文法を習得する事ができます。 これを読めば、SQLを使っ
TL;DR 正しく設計するとキャパシティは常にカツカツになる これはpyspaアドベントカレンダーの8日目の記事です。前日はShibukawaさんです。 世はクラウド時代、ソフトウェアはひとたび作られたら何億回実行されても摩耗するものではないので、どんな間抜けなロジックであろうと動く以上は別のどこかで瑕疵が出てくるまで使い倒されるのは日常茶飯事である。 サービスを負荷の前提の上に定義する クラウドより前の時代においてサービスを支えるマシンは「ロードアベレージが1.0を超えてなければとりあえずOK、超えたらマシンを増やして負荷を分散する」というノリのベストプラクティスがよく言われていたがそれはサーバ資源の確保にそれなりに時間がかかる時代の常識であって、クラウド時代でサーバは分単位で確保できるようになった。 クラウドの利点としてその即時的なスケーラビリティが常套句として使われて久しいが、これは
When people in the software industry talk about “architecture”, they refer to a hazily defined notion of the most important aspects of the internal design of a software system. A good architecture is important, otherwise it becomes slower and more expensive to add new capabilities in the future. Like many in the software world, I’ve long been wary of the term “architecture” as it often suggests a
この記事の初出は、Software Design2022年3月号「設計方針から変えていく、モノリシックなアプリの過去と未来(最終回)」で、加筆修正されています。過去の連載記事は以下を参照ください。 第1回 Software Design連載 2021年8月号 Python製のレガシー&大規模システムをどうリファクタリングするか - MonotaRO Tech Blog 第2回 Software Design連載 2021年9月号 「テストが無い」からの脱却 - MonotaRO Tech Blog 第3回 Software Design連載 2021年10月号 スナップショットテストの可能性を追求する - MonotaRO Tech Blog 第4回 Software Design連載 2021年11月号 Robot FrameworkでE2Eテストを自動化する - MonotaRO Te
Hard disagree with most of the 20 items. 1. Writing software is difficult, tedious and needs real work. No silver bullet libraries, no methodology, no framework, no IOT, no amount of unit tests will get the work done faster. 2. Developers collect tools, libraries and pet technologies and make projects go over their time and budget by doing it. 3. Code should encapsulate algorithms and not be struc
tl;dr 前半をサイバー脅威インテリジェンスの理論、後半をハンズオンの形式で全6回の連載をしてきました 連載は現実のインテリジェンス業務をなるべく反映させたものであり、戦術脅威インテリジェンスがアウトプットの中心になります 実態のよくわからないバズワードに飛びつかず、企業は自組織の体制と世の中の脅威を正しく理解するところからはじめましょう はじめに 本稿は前回の記事「無名のセキュリティエンジニアがたった2本のブログ記事からSoftware Designで連載をすることになった (非技術編)」の技術的内容部分を抜き出したものです。未読の方は先にそちらの記事を参考にしていただいた方が、内容を理解しやすいと思います。 blog.nflabs.jp 前回に引き続き @strinsert1Na です。事業推進部の Defensive チームで脅威インテリジェンスの生成やソフトウェアの開発をしていま
概要 ・現代Webフロントエンドにおける難しさは何によってもたらされるのか ・Webフロントエンドと「ドメイン」の関係について ・Webフロントエンドを「設計」することについて ・Webフロントエンドにおけるアーキテクチャ考察 参考資料(スライドにも記載) ・エリック・エヴァンスのドメイン駆動設計 ・Eric Evans(著)今関 剛(監訳)和智 右桂、牧野祐子(訳) ・Clean Architecture 達人に学ぶソフトウェアの構造と設計 ・Robert C. Martin(著)角 征典、高木 正弘(訳) ・未来を作った人々 - ゼロックス・パロアルト研究所とコンピュータエイジの黎明 ・Michael Hiltzik(著)エ・ビスコム・テック・ラボ(監訳)鴨沢眞夫(訳) ・オブジェクト指向のハードコア ・https://www.zerobase.jp/salon/2019/05/25/
マイクロソフトは9月21日、Bethesda Softworksの親会社であるZeniMax Mediaを買収することで合意したと発表した。買収金額は、現金で75億ドル(約7840億円)とのこと。 Today is a special day… We are THRILLED to welcome the talented teams and beloved game franchises of @Bethesda to Team Xbox! Read the full announce from @XboxP3: https://t.co/Jn0HcTJ9Mi pic.twitter.com/iQVutgT6zq — Xbox (@Xbox) September 21, 2020 ZeniMax MediaはBethesda Softworksのほかに、Bethesda Game Stu
Stop using frameworks for everything. Just stop. You don’t need a framework to write good code and deliver products. Don’t get me wrong, frameworks are useful, but they are all-consuming and hide the application. So if you shouldn’t depend on frameworks what should you do instead? Clean architecture. More specifically, there are some patterns you can follow to better architect your application and
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く