さよならアーキテクチャ議論｜Seiji Takahashi@ベースマキナ
ポエム。 つまり？予算やチームのリテラシーに合わせて最速で作れて、チーム内で「俺ら高凝集低結合だなー」と思えるなら、アーキテクチャはなんでもいいと思えてきました。 前提・まだ割と収益が安定してないプロジェクトでの話です。お金があるなら好きにやりましょう。Go Bold。 ・DDDやクリーンアーキテクチャがダメとは言ってないです。むしろ自分は直近そこまで厳格ではないクリーンアーキテクチャでAPI書いてます。 ・以前こういうポスト書くくらいにはアーキテクチャのこと試行錯誤してました。 アーキテクチャ導入議論への疲労以前僕は、DDDやクリーンアーキテクチャを導入するという話が出ると積極的に顔を出すようにしていました。でも、最近は「導入しましょう」「既に適用してあるのでキャッチアップしてください」などの議論をするのに少し疲れてしまい、足が重くなったように感じます。もうおじいちゃんなので体力がないん
ソフトウェア設計の言語化スキルを磨くこと｜qsona
たとえば設計について議論するときや、コードレビューで指摘をするときに、「なぜその設計が良いと思うのか？」について言語化するのが上手だと、確実に良いことがあります。 言語化が上手にできるかが一つの壁なのではないか、と感じることもあります。後輩を育てたりチームをリードするような立場になると、特に必要性を感じるのではないかなと。 自分も、うまく言語化できたことですんなり議論を進められていると感じることは多いですし、逆に直感的な良さを言語化できなかったことで直感に反する方向に進んでしまい、結果よくなかったというような苦い経験もあります。 前提: ソフトウェア設計の良さは静的には決まらない良い設計・良いコードとは何なのか。という質問に一言で答えるなら、「保守性が高い」ことだと思います。つまり、今後の変更・拡張を、高速にバグが少なく行えるような状態が良い設計・良いコードです。(一般的にはこれで70%く
リモートワークの設計と運用 / または Discord + VSCode LiveShare がいいぞという話 - mizchi's blog
この記事読んで自分のリモートワーク経験からどうやるのが今一番良いだろうか、という話をずっと考えていたので、書き出してみました。 リモートワークをする人必読。組織パフォーマンスを左右する「デジタル心理的安全」とは？ | 未来を変えるプロジェクト by iX（アイエックス） 自分自身はフルタイムリモートとフリーランスでのリモートの2つの経験があります。 次の会社が申請すればリモート可というスタイルなのですが、自分がリモートワークする場合、働く環境に期待しているのはこういうことだ、というのを事前に宣言しておく目的もあります。 フルリモートではなく、部分的なリモートを想定しています。 リモートワークに期待すること リモートワークは、基本的には「うまく運用すれば効率が下がらない」というものです。リモートワークで効率が上がることもありますが、基本的にはある種の福利厚生、雇用競争力のためと割り切ったほう
RailsのControllerにApplicationService相当のロジックを書くのはありなしや？ - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
誤解を産んでいそうだったので追記します。ここでいうApplicationServiceというのは、いわゆるレイヤードアーキテクチャのアプリケーション層のApplicationServiceレイヤの話です。別の言葉だと、「Usecase層」とか言う言葉で呼ばれたりするアレのことです。追記おしまい。 Railsにおいては、ApplicationService相当のロジックをコントローラーに書いても良いものとする— 猫でもわかるしんぺい入門 (@shinpei0213) June 4, 2019 これについてです。 結論から先にいうと、ぼくは「正しい」と思っています（ただ、自分ではあまりやらず、ApplicationServiceに切り出しちゃいますが、これは好みの問題だと思っています）。 なぜ正しいと思うのか。それを考える際に、まずは「一般的に、なぜControllerとApplication
「UNIXという考え方」を読んだ - えいのうにっき
以前に、kabuという半分ネタのCLIツールを作ったことがあった。Goの手習いに、という目的もあったのだけど。 blog.a-know.me 今でも月に一度は使うくらいの（自分にとっての）便利ツールなのだけど、このコマンドについて、「コマンドとしてあるべき姿」といった観点で、同僚からいくつか指摘をもらうことができたことがあった（「ネタにマジレスだけど......」と前置きしつつとても丁寧に添削してくれた :pray: ）。 引数がない場合は標準入力から取ると良い いま標準出力に出してるようなメッセージは、標準エラー出力に出すと良い。そうすると他ツールとの連携がしやすくなる -verbose オプションを設け、それがonのときだけ出す、などとする 候補が見つからなかったときは、non zero exit statusで終わるのが綺麗 こうした指摘は大変ありがたい一方で、「そういう感性みたいな
「悪い方が良い」原則と僕の体験談｜Rui Ueyama
ソフトウェアの世界には「悪い方が良い」原則という有名なエッセイがある。キレイにレイヤ分けされた一貫性のある良いデザインよりも、一見手抜きの悪いデザインのほうが実は良いときもあるという話だ。この逆説的なデザイン原則を僕は身をもって体験したことがある。それについてちょっと書いてみようと思う。 僕はlldというリンカの現行バージョンのオリジナル作者だ。リンカというのはコンパイラと組み合わせて使うもので、実行ファイルやDLLを作るのに使用される。lldはプロダクトとしてはかなり成功していて、標準のシステムリンカとして採用しているOSがいくつかあったり、GoogleやFacebookなど皆が知っているような大規模サイトの中で広く使われていたりする。 現在のlldは2世代目で、第1世代のlldは僕がプロジェクトに参加する前から存在していたのだけど、数年前にそれを捨てて一から書き直すということになった。
プログラミング経験がない経営者のためのソフトウェア開発 11の事実 | Social Change!
今やどんなビジネスでもITが関係している。ITを支えているのはソフトウェアだ。あらゆるものがソフトウェアで実現される時代になった。そんな事業や生活に密接に関わるソフトウェアだが、その開発について知られていないことも多い。 とくに経営者がプログラミング経験がないことで、ソフトウェア開発のリーダーシップをとるときに的外れなマネジメントをしてしまうことがある。あまねく経営者がプログラミング経験があれば良いのかもしれないが、それは現実的ではない。 プログラミング経験がなくても、せめてソフトウェア開発の特性について知っておくと良さそうなこともあると思い、なるべく専門用語を使わずに本稿を書いた。 プログラミングは製造ではなく、設計である いまだにソフトウェア開発を、ビルや家屋の建築に喩える人がいるし、工場でモノを製造するようにプログラムが作られると思っている人もいる。 ここが間違いのもとだ。ハードウェ
エンジニア歴20数年の私が、設計書を書く際に心がけていること - Qiita
はじめに 時の経つのは早いもので、私がIT業界に身を置いて四半世紀になってしまいました。 その間、膨大な数の「設計書（仕様書）」を書いて来ましたが、未だに悩み・迷いは尽きません。 それでも、亀の甲より年の劫とも申しますので、私なりの経験則を「個人」と「チーム」の両観点でまとめてみました。 本稿のテーマは、「主に設計書を想定した、開発ドキュメントの書き方」です。 本稿で前提とする設計書は、ExcelやWordで書かれた、フォーマルな（≒納品物になりえる）設計文書、です。 したがって、自社サービス開発よりも受託開発、アジャイルよりもウォーターフォール、を前提として読んでいただいた方が、しっくりくると思われます。 ＜ご注意＞ 本稿の内容は執筆者独自の見解であり、所属企業における立場、戦略、意見を代表するものではありません。 個人的に心がけていること 当該文書の作成目的や位置付けを冒頭に記載する
ランキング設計はどうあるべきか？ その2｜深津 貴之 (fladdict)｜note
前エントリで論じられた、正しいランキング設計の考察の続き。第2回は、ランキングの収奪性、格差の固定性を軽減する手段を、具体的に論じてみる。 前回の記事へのTwitter上のフィードバックは、Togetterにまとめてある。こちらもご興味があれば、一読の価値がある。いくつか被ってしまったものもあるけれど、諸々の後半記事。 「ランキング」以外の名称を用いるこれはほぼ確定。ランキングという名前は、「noteとして競争原理を推奨する」という強いメッセージを発する。noteの全てのユーザーが、競争原理で動いているわけではないので、これは望ましくない。 おそらく最終的には「注目」「人気」などの名称を使うことになるかと思われる（「オススメ」はパーソナライズ用にとっておく）。また、「ランキング」という名称やスタンスをやめることで、後述するようないくつかの公平性のための施策を行う余地が生まれる。 時間による
スピード感のために品質を落とすということはチームの成長を諦めるということ - ネットの海の片隅で
サービスを開発していると、スピードが重視される。 そのこと自体にはまったく問題はなくて正当なことだと思っている。 ユーザーに対して一刻も早く価値を届けるためには必要なことだ。 そもそも、自分がいる Web 界隈ではこの点について異論のあるサービス開発者はあまりいないんじゃないかと思っている。 ただ、それを達成するための方法になると途端に意見が分かれはじめて、人によって重視することが全然違ってくる。 ある人は「スピード感が大事」と言い、ある人は「ちゃんと作ったほうがトータルでは速い」と主張する。 しかし、こういうときに意識される品質と速度についてのトレードオフは、実際には完全なトレードオフではないと思っている。 技術力のある人はある程度急いで作ったとしても一定以上の品質のコードを書くし、意図的に品質を落としたとしても速度はあまり上がらない。 逆に、技術力が高くない人が時間をかけて作ったとして
だんだん開発スピードが遅くなっていくのをどうやってとめたら良かったんだろう？ - Mitsuyuki.Shiiba
先日、モブプロをやってきた。その中で、モブプロとは別で、いくつか感じたことがあって、今日はその中のひとつを思い浮かんだままにメモ。 bufferings.hatenablog.com 要件を満たすプロダクトをより早く出す モブプロでTDDしながら、要件を満たすプロダクトをより早く出すことに集中してみた。例えば、第２ラウンドのお題はTDDBCなどでお馴染みの「自販機」。 「100円を入れてボタンを押すとコーラが1本買えること」 最初に「100円を入れてボタンを押すとコーラが1本買えること」と言われ。 assertThat(get(100), is("コーラ")); みたいなテストを書いて。 String get(int money) { return "コーラ"; } みたいな実装を書いた。爆速！ 「200円を入れてボタンを押すとオレンジジュースが1本買えること」 次に「200円を入れてボタ
DHH流のルーティングで得られるメリットと、取り入れる上でのポイント - KitchHike Tech Blog
はじめに こんにちは。KitchHikeエンジニアの小川です。KitchHikeでは主にサーバーサイドを担当しています。 少し前のものですが、「DHHはどのようにRailsのコントローラを書くのか (原文)」というすばらしい記事があります。Railsのコントローラ分割の(DHH流)ベストプラクティスについて解説した記事なのですが、私はこの記事に大変感銘を受け、KitchHikeのルーティング定義にもこのプラクティスを取り入れるようになりました。 本日はこのDHH流ルーティングを取り入れることで得られるメリット、実際の routes.rb でのルーティング定義のしかたについて紹介したいと思います。 DHH流ルーティングとは？何がうれしいの？ 詳しくは元記事を是非とも読んで下さい・・・なのですが、かいつまむと、ここで示されているのはたったひとつの単純明快なルールです。 コントローラはデフォルト
LINE DEVELOPER DAY 2016 開催のお知らせ « LINE Engineers' Blog
LINE株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。 LINEヤフー Tech Blog saegusa2017-04-16Yoshihiro was a network engineer at LINE, responsible for all levels of LINE's infrastructure. Since being named Infra Platform Department manager, he is finding ways to apply LINE's technology and business goals to the platform. こんにちは。LINEでネットワークやデータセンターを担当している三枝です。2017年1月にJANOG39で登壇する機会を頂きましたので、今回
仕様や実装方針の相談をPullRequestで行う取り組み - $shibayu36->blog;
これまで少し大きめな機能であれば、コードを書く前にまず仕様や実装の方針をissueのdescriptionにまとめ、それを先にレビューしてもらってから実装にとりかかるということをしていた。最近、その方針をそもそもrepositoryのファイルとして書いて、PullRequestしてレビューしてもらうようにしたら便利だったのでご紹介。 なぜコードを書く前に仕様や実装の方針をレビューするのか 前提としてなぜコードを書く前に仕様や実装の方針をレビューして欲しいのかについて書いておく。これはとにかく手戻りの量を少なくしたいという要求のためである。 実装に取り掛かろうとすると、実装の方針はいくつか思いつくが、どれが一番よいか迷うことはよくある。その場合に誰にも相談せず自分だけで判断し、コードを書いてからPullRequestを送った場合、もしその選択に重大なミスがあった場合全て書きなおさないといけな
綺麗なAPI速習会 - Qiita
Wantedly Engineer blogに本速習会資料を閲覧向けに再編しました！ ぜひご覧いただけると幸いです！ 本記事は、綺麗なAPI速習会@Wantedlyの資料として作成されたものです。 同時にこちらのコードも参照してください。 マイクロサービス 流行りのマイクロサービス、何がいいのか 各々自由な言語やArchitectureでサービスを立てられる 障害の影響が部分的 変化に強い 個別デプロイ etc... マイクロサービス化をすすめるにあたり、やりとりは全てAPIで行う 内部のAPIであっても外部に公開できるようなクオリティのAPIを作成し、それを元にサービスを作っていくことが重要 APIGatewayとBFF API Gateway Pattern 公式サイトより 「見た目はモノリシック、実装はマイクロサービス」 一箇所見に行けば全てのAPIを見つけられる 細かい権限管理も可
スマホゲーに「レア」がでてくる理由と、人間が「課金したゲーム」を消せない心理。海外コンサルが教える、ゲームに使われている7つの心理テクニック。 | アプリマーケティング研究所
スマホゲーに「レア」がでてくる理由と、人間が「課金したゲーム」を消せない心理。海外コンサルが教える、ゲームに使われている7つの心理テクニック。 今回は、ゲームコンサルタントのドリーさんによる「スマホゲームでつかわれている心理テクニック」の解説をまとめました。（資料等はドリーさんから翻訳許可をいただき掲載しています） ※ゲームコンサルタントのDori Adar（ドリー・エイダー）さん うまく出来ているスマホゲームでは、ユーザーが思わずアクション、課金してしまうような、心理的なテクニックがつかわれています。 もちろん、ゲーム開発者の中には、そういう「テクニック」が好きじゃない人もいると思うけれど、現実にそうなっていることは、認めざるを得ません。 今回の資料では、最近のカジュアルゲームでつかわれている、7つの心理テクニックを紹介していきたいと思います。 心理１「損失を回避したい」 まず一つ目は「
論理削除 Casual Talks #1 で「論理削除しない」という話をしました - moroのブログ
互いの前職での先輩後輩である @kenchan と企画した論理削除 Casual Talks #1で、「論理削除しない」という話をしてきました。 話す内容が各話者で面白いほどかぶっていたのでなかなか大変でしたが、普段から言っている「論理削除するな」「削除じゃないからちゃんと機能を設計しましょう」という内容を話してきました。 他の方の話も、かぶっているようで新しい視点もあって、いち参加者としてもたいへん勉強になりました。
RESTful#とは勉強会で(Railsでの)ルーティングの考えだし方の話をしました - moroのブログ
RESTful な設計って、ってマスタメンテ作るにはいいけどまともなサービス作れるの? という疑問に対して、結構やればアプリケーションできるので安心してください、という話をしました。 「独自研究」セクション以外はだいたいふつうに経験したことです。「独自研究」セクションはたぶん、今流行りのオーケストレイションレイヤをどうするかというところになるのかな、と。APIといいつつ、HTMLを返す話ばかりですが、これはAPIとHTMLをあえて区別せずそれは単にリプレゼンテーションが違うだけです、という意図でした。 転職してから初の社外発表が前職オフィスでやるというのが面白かったです。永和メンバーも結構たくさん会えてよかった。来てくださった方、開催をアレンジしてくださった方、ありがとうございました。
Webパフォーマンス管理の基本 1 - Qiita
はじめに Webパフォーマンスはパフォーマンスエンジニアリングの1つの分野 Webパフォーマンス管理は、Webサイトの非機能要求の性能や可用性を扱います。 専門用語では、コンピュータの登場と時期を同じくして登場したパフォーマンスエンジニアリングという分野に属します。 パフォーマンスエンジニアリング パフォーマンスエンジニアリングとは、Wikipediaでは以下のように記載されています。 Performance engineering encompasses the techniques applied during a systems development life cycle to ensure the non-functional requirements for performance (such as throughput, latency, or memory usage) w
Private Presentation
Private content!This content has been marked as private by the uploader.
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
