なぜオブジェクト指向方法論に代わる方法論が出ないのか - きしだのHatena
1990年代にオブジェクト指向分析・設計の方法論がめちゃ流行ったことがあります。 ただ、そのブームが終わって、後続となるような方法論が流行ることはありませんでした。 で、なぜなのか考えていたのですけど、オブジェクト指向方法論のウリは分析段階で出てきたオブジェクト(といいつつクラス)がコードにそのまま引き継がれるというものでした。ようするにオブジェクト指向方法論というのはコードのスケッチを書いて詳細化していくというものだったのです。 しかしながらこれは、スケッチとして書いた分析・設計が間違っていればコードも間違うわけで、強くウォーターフォールの性質をもつものでした。 結局のところスケッチの妥当性というのはコードを書かないと検証ができません。分析・設計段階で見出されたクラスが妥当かというのは、コード書かなければわからなかったのです。逆に、コードを書けば妥当かどうかわかります。であれば、最初から
『ソフトウェアアーキテクチャの基礎』は我々の海図たりえるか
こんにちは、クレスウェア株式会社の奥野賢太郎 ( @okunokentaro ) です。今回は、最近噂としてよく耳にしていた書籍『ソフトウェアアーキテクチャの基礎 ― エンジニアリングに基づく体系的アプローチ』（オライリー・ジャパン社、Mark Richards, Neal Ford 著、島田浩二 訳、2022 年 3 月発行）を読了したので、その書評をまとめようかと思います。 この書籍は、アプリケーション・アーキテクチャを構築、維持する「アーキテクト」になるために必要な知識を現代（2020 年代）の視点から整理し、包括的に解説することを目的としているらしく、まさに 2022 年に読むべき内容に仕上がっています。 書評者は何者か この書籍はよいものでした。ただし、かなり広範囲に包括的に書かれたものであったため、どういう経験や知識を持った人間が読んだかによって、その好みや評価は分かれるだろう
なぜシェルスクリプトで高度なデータ管理にSQLiteを使うべきなのか？ ～ UNIX/POSIXコマンドの欠点をSQLで解決する
なぜシェルスクリプトで高度なデータ管理にSQLiteを使うべきなのか？ ～ UNIX/POSIXコマンドの欠点をSQLで解決するShellScriptUNIXSQLitePOSIXQiitadelika 「利用者は数十億人！？ SQLiteはどこが凄いデータベース管理システムなのか調べてみた」の続きです。 はじめに 複雑な構造のデータを扱うのであればシェルスクリプトや Unix (POSIX) コマンドでデータ管理を行うのは避けるべきだと思います。解決不可能な問題が多いからです。しかしそれでも何かしらの理由でやろうと考える（やらなければいけない）のであれば SQLite を使うのをおすすめします。シェルスクリプトや Unix コマンドは行単位の単純なテキストデータをシーケンシャルにデータ処理するのが前提となっており、改行や空白が含まれるデータや複雑な構造のデータ扱うのは苦手です。またシェル
Re: Web3というテロリズム - Software Transactional Memo
えふしんさんに何の恨みも無いのだけれど わからないことを偉そうに書いて怒られて進化したいという芸風なので書いてみました。 Web3というテロリズム｜えふしん #note https://t.co/84SoYtIzDC — えふしん (@fshin2000) 2022年2月17日 というのだから技術的に正確なツッコミを入れて欲しいという事だと信じて書く。まさか後釣り宣言など来ないだろう。 Web3という言葉は、既存の権力構造に対する宣戦布告と考えれば、割と素直に受け入れられる。 ここは本当にその通りで「下剋上」の雰囲気感だけで業界が振り回されているのは見るに耐えない。権力構造を敵対視するあまり、本当に味方に付けるべきエンドユーザーの事がなおざりになっているとすら感じている。市場経済で世の中が動く中、エンドユーザーは確かな利益が無ければ動かないし、利益無しで人やお金を動かさせたら詐欺である。こ
なぜ、ソフトウェアプロジェクトは人数を増やしても上手くいかないのか - Qiita
はじめに ソフトウェアプロジェクトには不思議な性質があります。現状のスケジュールに課題を感じて、短くするために人員を投下しても、なかなか思い通りに短くならない。それどころか悪化してしまうことがあります。場合によってはプロジェクト自体が破綻して失敗してしまうことすらあります。 今回は、このようなソフトウェアプロジェクトに潜む直感に反する性質を数理的なモデルを介して理解していく試みです。ある種の思考実験としてお楽しみください。 宣伝 Qiitaさんとコラボ企画でアドベントカレンダーをつくりました。 DXをめちゃくちゃ改善した話を募集しています。 https://qiita.com/advent-calendar/2021/dx-improvement 10人の妊婦がいても1ヶ月で一人の子供は生まれない これは誰かの技術力やプロジェクトマネジメント力に欠陥があるのではなく、「人月の神話」で有名な
イーロン・マスクのロケット製造５つのステップがサイコーだった
イーロン・マスクが YouTube チャネルでスペース X のテキサス工場スターベースの中を歩き回りながらロケット製造や電気自動車について説明しているのを観た。ツイートしたこの件。 これがめちゃくちゃに示唆に富んでいて面白かった。この日のイーロン・マスクは饒舌で楽しそうなので、かなり魅入ってしまった。きっと彼はカンファレンスや会議室の中でインタビューを受けるよりも、工場でみんながロケット作ったり作業している場で語った方が情熱を込めていろいろ説明してくれるんだと思う。 この中で製造工程の話があって、これはロケット製造などの特定分野だけでなく、IT やその他の分野にでも当てはまる普遍的な知見だと思ったので意訳してみた。ざっとビデオを観て印象に残った部分だけを意訳した。あくまで大枠で言ってることをまとめただけなので、もし詳細に興味があればぜひビデオを観てイーロン・マスクの話を直接聞いて確認してく
ソフトウェアエンジニア、家を買う - hichihara note
最高の夏を迎える中庭 前回の記事投稿からだいぶあいていますが、あいかわらずGAFAではない会社でソフトウェアエンジニアをしています。今回は最近の個人的な大仕事であった家を買った話を書きます。ちなみにこの記事にソフトウェアエンジニア要素はほぼないので釣りタイトルになります、ただプロダクト設計やプロジェクトマネージャー的な感覚は必要になって非常に面白かったです。 注意事項: この記事は素人の個人的な意見や感想です、また家に関して何が一番良いかは人それぞれなのでそういった議論もしません。 なぜ家を買ったのか？ 子供の小学校入学前であることコロナ禍であることで決断しました。元々、自分や妻のキャリアや子供のことなども含め賃貸で暮らしてきましたが、子供も大きくなり小学校入学前には持ち家を買いたいなと漠然と考えていました。大体2年前くらいから都内で4LDKの戸建てやマンションを探していて、実際に買う寸前
ソフトウェア設計原則は変更容易性に通ず - Shin x Blog
色々な原則や方法論はあれど、つまるところいかに変更容易性を確保するかと言う話に帰結するのでは。極論すれは、正しく動いていて変更する必要が無ければどのような作りになっていても構わない。一方、Web アプリケーションを稼働し続ける上で全く変更しなくて良いということもない。— Masashi Shinbara (@shin1x1) 2021年5月30日 ソフトウェア設計、開発には多くの原則や方法論がある。例えば、DRY 原則や SOLID 原則、デザインパターンにレイヤードアーキテクチャ、クリーンアーキテクチャなどある。さらに DDD にも多くの原則や方法論が含まれている。これらを変更容易性を高めるための手段として原則や方法論を捉えるというのが本エントリの論旨である。 原則や方法論の捉え方 変更容易性 本質的な変更と副次的な変更 外部変更容易性と内部変更容易性 原則を適用する指針 さいごに 原則
プログラマーがドキュメントを書かない理由
この記事は、著者の許可を得て配信しています。 Why programmers don’t write documentation 最近ではずっとコードのドキュメンテーションに関連した記事を書いていたので、当然、私のMediumのおすすめ記事には「開発者がドキュメントを書かない本当の理由」という記事が表示されるようになりました。この記事では、ドキュメントを書くための優れたツールがないことが、ソフトウェアエンジニアが自分の作業や判断をドキュメンテーションする意欲を失わせる最大の原因について書いています。 私は普段、特定の記事を批判したりはしませんが、この記事には怒りを覚えました。このライターは図解ツールについていくつかメリットに関して述べてはいますが、全体的に誤解を招くような内容になっており、この重要な問題をより分かりにくくさせています。2つの図解ツールを比較して、どちらも不十分なツールである
日本のソフトウェア開発はなぜ世界から落伍したのか。中国人エンジニアの見方 - 中華IT最新事情
日本のソフトウェア開発はなぜ落伍したのか。中国のエンジニアの間でも話題になることが増えている。未来樹Aは、その理由をエンジニアの視点で解説をしている。委託開発が多い。システム開発の目的がイノベーションではなく、生産性の効率向上に留まっている。政府、地方自治体の案件が上位企業に集中するため、ベンチャーが育たないという理由を挙げている。 中国でも話題になっているCOCOAの件 日本でも話題になっているが、中国でも接触確認アプリ「COCOA」の件が、エンジニアの間で話題になっている。中国では、位置情報とQRコードを活用した健康コードが、2020年2月11日という早い段階で、アリババと杭州市によって開発され、1月ほどで他都市にも広まった。感染リスクが高いと判定されると赤になり、公共交通や店舗の利用ができなくなる。不便は強いられるが、それでも、生鮮ECやフードデリバリーが発達をしているため、生活はな
なぜその API は使われないのか？ API の活用を拒む3つの壁とその対策 - CData Software Blog
こんにちは！ CData Software Japan リードエンジニアの杉本です。 大変ありがたいことに、最近あるSaaSを提供する会社さんから「リリース前のAPIを触ってみてフィードバックをくれませんか？」と依頼を受けました。 私は以前こんな記事 を公開するほど、APIどっぷりな人間なのですが、数多くの SaaS APIを触ってきてよく考えることがあります。 それは SaaS APIというサービス・プロダクトそのものを成長させる上で、もっとも重要なことは「顧客・デベロッパーが、そのAPIをどれだけスムーズにキャッチアップできるか？」という点に尽きるのではないか？ というものです。 以下のグラフはAPI管理ツールを提供するSmartBearのAPI調査において、APIドキュメントで最も重要な要素とは何か？ というアンケート結果のランキングですが、ExamplesやAuthenticati
ソフトウェアのもっとも重要な品質は発展性 - ソフトウェア設計を考える
ソフトウェアでもっとも重視すべき品質は「発展性」なんだと思う。 機能要求や非機能要求は、時間とともに変化する。その要求の変化に対応してソフトウェアを発展させていける能力、つまり発展性こそがソフトウェアの価値を大きく左右する。 発展性に問題があり変化ができないソフトウェアと、発展性に優れ変化と成長を続けやすいソフトウェアの価値の差ということだ。 発展性の価値 顧客のニーズは変化する。また、市場の競合関係も変化する。そういう事業環境の変化にあわせて、ソフトウェアにも変化を続ける能力が求められている。 また、顧客のニーズや市場環境の変化がゆるやかだとしても、事業活動をすれば組織は経験を通じて学び成長していく。開発チームに限っても、ソフトウェア開発運用の経験を積むことで、開発の考え方とやり方にさまざまな学びと成長がある。そうやって学んだ知識を適切にかつ迅速にソフトウェアに反映できるほど、事業により
お客様から「日本にサマータイムを導入したいんだけど」と言われたらプログラマとしてどうすべきか？ - give IT a try
はじめに 東京オリンピックを2年後に控え、日本のIT業界に突然降って湧いた「日本でもサマータイムを導入するかも？」という問題。 この話、数日経てば「そんなのうそぴょーん」とか「すいません、前言撤回します」みたいなオチで終わるだろうと思ってたのですが、このブログを書いている時点ではそういう気配はなく、むしろ前向きに検討しているような雰囲気で「おいおいおい！」と思っております。 こんな「ピカーン💡いいこと思いついちゃった！」的なノリで突然サマータイムを導入するのが、技術的にどんなに無茶な話なのかは、他の専門家のみなさんが論じてくれているのでここでは書きません。 そのかわりに、もしこんな話が僕が勤めている株式会社ソニックガーデンの「納品のない受託開発」で巻き起こったら僕はどんな対応をするか、という思考実験をしてみようと思います。 前提知識：「納品のない受託開発」の開発スタイルについて 「納品の
Webアプリケーションフレームワーク導入時に考慮すべき22の観点 - Qiita
本記事では、 チームによる持続的に変更可能なWebアプリケーションの開発を目標に、フレームワーク導入時に考慮すべき22の観点を紹介する。 フレームワークによって特徴は異なるが、本番導入にあたって、考慮すべきポイントはあまり変わらないので、極力フレームワーク1に依存しすぎないよう配慮する。また、話をシンプルにするため、REST APIを提供するアプリケーションを題材とする。 前提 ソフトウェアのエントロピー ソフトウェアがエントロピー増大の法則を避けられないことを、体感している開発者は多いだろう2。普通にアプリケーション開発を続けると、開発スピードは鈍化し、品質は低下してバグが増え、開発者からは技術的負債への怨嗟の声が聞かれるようになる。エントロピー増大というフォースは極めて強力で、意思を持って立ち向かわなければ、容易にダークサイドに堕ちてしまう。 関心事の分離 大規模Webアプリケーション
ソフトウェア開発で学んだが使わなかったもの
開発手法など、一通り学んだが実際に使っていないものは多少なりあると思う。それらについて掘り起こしてみたい。 スクラム開発認定スクラムマスター研修には研修会場ホストという立場で数回立ち会った。認定外の研修も幾つか受講した記憶がある。書籍もそれなりに読み、Scrum Gathering Tokyoなどのコミュニティにも顔を出し、まあそれなりに色々考えて捉えてきた。でも、自分のチームでは使っていない。スクラム開発というアイデアに矛盾があるからだ。 そもそもスクラム開発ではチームの自律的な行動を良しとしており、それに対する”フレームワーク”を提供しているということになっている。イテレーション、バックログ、ふりかえり、デイリーミーティング（いまだに「朝会」って言ってる人いないよね？）、そしてそれらのお作法。誰が言ったかわからないが、それぞれの作者の意図を察するためには「守」が大事らしい。守破離の「守
ソフトウェアの複雑性は本質的な性質であって偶有的なものではない - プログラマの思索
「過剰と破壊の経済学-「ムーアの法則」で何が変わるのか」を気軽に読んでいたら、ブルックスの人月の神話の一節が書かれていて、今頃になって、すごく腑に落ちたのでメモ。 ブルックスの人月の神話の文章のうち、自分が理解できたことを、ラフなメモ書き。 以下は書きかけ。 【参考】 第0回：人月の神話とはなんなのか？（解説編）｜本気で読み解く”人月の神話” | GiXo Ltd. 第2回：銀の弾は無いけど、”銃”はあるよね｜本気で読み解く”人月の神話”（第16章） | GiXo Ltd. ソフトウェア開発とは、現実世界の複雑さをプログラムコードの難しさに置き換える作業だ - セカイノカタチ ソフトウェア開発でよく言われる「銀の弾丸など無い」とはどういう意味なのか本を読んでみた。 - 感謝のプログラミング 10000時間 【1】ソフトウェアの複雑性は本質的な性質であって偶有的なものではない。 「過剰と破壊
ドイツの受託開発会社を退職しました - WETな備忘録
2月末日付けで退職しました。退職エントリ書くつもりは無かったんですが、周囲から「公益性が高そうなので書け」というお言葉をいただいたのと、あと海外在住プログラマのキラキラ記事っておおいに生存バイアスかかってる気がするし、死にゆく者の事例も大事かな、と。 はじめに つらみは有りましたが、うらみは有りません。当初3年ぐらいかなと思ってたけど、この1年間の経験には大変満足しています。また、同僚各位にも深く感謝しております。Vielen Dank. I love you ;) 日本に帰る理由も、ドイツがつらいってのはだいたい3割ぐらいで、じつは2年前からゲノム解析のウェブサービス化とか生物学周辺のソフトウェア受託などの個人事業をやってて、そろそろそっちに集中すっかー、というのがマジな理由です。 tl;dr 自分を守るのは会社でも制度でもなく、自分。Noと言えなければ死ぬしかない。 自分に落ち度が無い
Sharedocs - 社内で使えるQiitaクローン
MOONGIFTはオープンソース・ソフトウェアを紹介するブログです。2021年07月16日で更新停止しました 強い組織を作るためにはナレッジの共有が欠かせません。個々人のナレッジに留まっていては同じ経験を繰り返すだけですし、何も培われていきません。問題はどこに書き留めるかです。かつてはWikiもありましたが、慣れないと使いこなせませんでした。 今回紹介するオープンソース・ソフトウェアはSharedocs、プログラマが使い慣れているであろうQiitaクローンです。 Sharedocsの使い方 Sharedocsのトップページです。 ログインしました。カラーリングは違いますが、UIはとてもQiitaに似ています。 新規作成画面です。ここのデザインは結構違います。が、プレビューの機能などはついています。 表示例です。記法はMarkdownが使えます。 ユーザページです。投稿数、ストック数などが確
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
一時期プログラミングのデザインパターンというものが大流行しましたが、現在ではどのように評価されているのでしょうか？
Eric Evans氏はドメイン駆動設計(DDD) は未完成だと述べた
