タグ

2021年8月18日のブックマーク (21件)

  • ブログ: 良いプログラマは借用し、優れたプログラマは盗む

    Stack Overflowのブログより。 コピー・アンド・ペースト(コピペ)は危険な場合がありますが、不注意にソフトウェア開発を行うと、ソフトウェア開発の多くの側面でも危険が伴います。この投稿では、コードのコピーがソフトウェアの開発にとって実際に何を意味するのか、良いコードの盗用が何を意味するのか、そして間違ったコピーの落とし穴について見ていきます。 BY ライアン・ドノヴァン プログラマの間では公然の秘密ですが、ここStack Overflowの回答の一部として投稿されたサンプルコードの中には、番のコードになってしまうものもあります。もしかしたら、質問をしたことで、完璧なforループを手に入れたかも知れません。もしかしたら、あなたのアプリケーションにぴったりの正確なasync awaitの実装がすでにあるとする素晴らしい答えを見つけたかもしれません。 DEV Community 👩

    ブログ: 良いプログラマは借用し、優れたプログラマは盗む
  • 再考 - ドメインサービス  - まっちゅーのチラ裏

    自分が大規模システムで組むアーキテクチャは基的にはCleanArchitectureを踏襲しているが、その中の構成要素であるドメインサービスだけは少し独自(?)の解釈をしていて、書籍などでよく見る ビジネスロジックを持つが、状態をもたない 複数の集約にまたがる処理を書く場所 という責務の他に、外部システムへの委譲処理だったり、共通UseCaseのような責務も持たせている。 これは、自分が「xxService」という命名にトラウマがあり(何でも置き場になりがち)、単なるServiceだとコントローラやらプレゼンターやら、どこから呼ばれても違和感がない様に見えてしまうから、とりあえずDomeinServiceへ寄せている経緯がある。 ※ここで語るのは、あくまで大規模想定で、小さいシステムならこんな事を意識する必要はないはず。 ※あくまで自分の考えで、一般的ではない可能性があることをご了承くだ

    再考 - ドメインサービス  - まっちゅーのチラ裏
  • プロダクトにドメイン駆動設計を適用するためにはじめたこと - ContractS開発者ブログ

    こんにちは。最近Slackのカスタム絵文字作りにハマっている友野です。Holmesでサーバーサイドエンジニアをしています。 Holmesが提供するホームズクラウドは、今年8月にサービスローンチ3周年を迎えました! これまでの支持に感謝し、これからも長く使ってもらえるようにプロダクト改善に取り組んでいます。そのひとつとして、ドメイン駆動設計(以下、DDDと表記します)適用に関する取り組みについてご紹介します。似たような状況や同じ課題を持つ誰かの一助になれば幸いです。 背景と現状 まずはじめたこと 戦略的モデリング そして、戦術的な設計 採用するパターン2つ ドメインモデルを反映したオブジェクトを置くパッケージの作成 既存テーブル構造に依存しないRepository+Adapterパターン ふりかえり まとめ 最後に 背景と現状 ホームズクラウドはPMF(Product Market Fit

    プロダクトにドメイン駆動設計を適用するためにはじめたこと - ContractS開発者ブログ
  • JavaScript入門: 基礎知識をGIFアニメで分かりやすく解説 -総まとめ

    JavaScript QuestionsのLydia Hallie氏の「JavaScript Visualized」シリーズすべての翻訳を完了したので、まとめて紹介します。 JavaScriptエンジンの仕組みをはじめ、イベントループ、スコープチェーン、プロトタイプ継承、非同期処理、ジェネレータ関数、Hoisting(巻き上げ)など、GIFアニメを使用して詳しく解説しています。 シリーズ7すべてと、プラス1として楽しく学べるクイズもあります。 JavaScript イベントループの仕組み JavaScriptでエラーの原因となるHoisting(巻き上げ)の仕組み JavaScriptのスコープチェーン・変数参照の仕組み JavaScriptエンジンの仕組み JavaScript プロトタイプ継承の仕組み JavaScriptのジェネレータ関数とイテレータの仕組み JavaScript

    JavaScript入門: 基礎知識をGIFアニメで分かりやすく解説 -総まとめ
  • GitHubと併せて使うと便利なツール - it-engineer’s blog

    Monaco Markdown Editor For GitHub GitHubMarkdownを書くときにテキストエリアがVS Codeみたいになるブラウザ拡張 chrome.google.com 機能としては Markdownとコードスニペットのシンタックスハイライト Tabでインデント、Shift+Tabでインデントの戻し マルチカーソル F11でフルスクリーン フルスクリーンモードでは、十分な領域があればプレビューを表示 etc github1s GitHubのリポジトリのURLに1sを追加するだけで、VS Codeでリポジトリを読むことができるサービス 例えば、VS Codeのリポジトリ https://github.com/microsoft/vscode を見たい場合は、 https://github1s.com/microsoft/vscode を開くだけ。 なんだけど、

    GitHubと併せて使うと便利なツール - it-engineer’s blog
  • Go言語の記述の迷いどころについて

    この記事はGoのコードをいくらか書いていてもっとGoらしい書き方に興味を持ってからみてね!(Go初見で読んでも響かない内容です) Goは「シンプルで迷いなく書ける」というのが売りではあるのですが、 実際書き始めると、「あれ?これどうやって書くほうがいいの?」ってポイントにちょくちょく巡り合います。そのようなポイントを思い出しながら今思うベターな書き方を紹介しようと思う。 err変数束縛について err変数の受け取りを複数回繰り返していると「:=」だけで書けないという状況に出会うでしょう。 err := funcA() if err != nil { ... } err := funcB() // <- コンパイルエラー: "no new variables on left side of :=" if err != nil { ... }

    Go言語の記述の迷いどころについて
  • 過大評価されるDDD(ドメイン駆動設計)

    この記事は、著者の許可を得て配信しています。 Is Domain-driven Design overrated? ドメイン駆動設計(DDD)は、システムのモデリングと構築のための優れたガイドラインを提供する大変便利なアプローチですが、それ自体が目的ではなく、目的のための手段です。その概念は有効ですが、それを使うことだけに限定すると、その一方で多くのことを失うことになります。つまり、実際にはDDDの先にも人生があるということです。 最近、「DDD は過大評価されている」というクリックベイトなタイトルの記事を投稿したところ、皆様からかなり注目を集めました。今回の記事は、社内やソーシャルメディア(TwitterやHacker Newsなど)で受けたフィードバックを取り入れて、前回の記事に内容を加えたものとなっています。また、私の考えにもう少しニュアンスを加えたかったので、あまり過激なものにはし

    過大評価されるDDD(ドメイン駆動設計)
  • システムの複雑さはどこから来るのか – Out of the tar pitを読む - Uzabase for Engineers

    Uzabase Saas Product Divisionフェローの矢野です。 この記事は、Rich Hickey(プログラミング言語Clojure作者)のプレゼンテーションSimple Made Easyへと繋がっていく、Ben MoseleyとPeter Marksによる「Out of the tar pit」というシステム設計について論じた論文の内容について説明したもので、ユーザベースのSaas Productでのテック発表の一つとしてプレゼンしたものを、ブログとして再度まとめたものです。プレゼン自体は25分くらいでしたので、おそらくこの記事の方がプレゼンよりも詳しいと思います。 ソフトウェア危機 ソフトウェアは質的に複雑 ソフトウェアの複雑さはどこから来るのか? 複雑さは、別の複雑さを産む 複雑さを分類する 当に必要な複雑さと、そうでないものがある どうやって複雑さを扱うのか

    システムの複雑さはどこから来るのか – Out of the tar pitを読む - Uzabase for Engineers
  • ソフトウェア設計の Why & What & How | Wantedly Engineer Blog

    こんにちは、開発チームのアーキテクトをやっている竹野(@Altech)です。先日、新人研修でソフトウェアの設計について話す機会がありました。 ソフトウェアの設計というのは関連する領域が広いため、どうしても断片的な理解になりがちです。そこで、早い段階で全体像を感じてもらうために、ソフトウェア設計の Why と How と What を1時間でまとめて話すというちょっと意欲的なコンセプトで研修を行いました。今回は、その内容を記事にしました。 この研修のねらいはじめにソフトウェアの設計について書かれた情報は世の中に多いですが、その情報の多くは How であり、それだけを読んで適切に使うことが難しいと感じています。その直接的な理由は、How に対しての What、How / What に対しての Why が語られることが少ないからです。 ただ、How だけを知っていると、それは当に問題を解決して

    ソフトウェア設計の Why & What & How | Wantedly Engineer Blog
  • 「顧客の声を聞かない」とはどういうことか

    「もし私が顧客に何がほしいかを聞いていたら、彼らは『もっと速い馬がほしい』と答えただろう」という自動車王フォードの名言があります。またユーザー中心のはずのUXデザインで「顧客の声を聞かない」「ユーザーは当に欲しいものを言葉にできない」という言葉を聞くことがあります。どうすればよいのでしょうか。欲しいものを訊くのではなく、行動の目的を訊くことで、ユーザーの当のニーズにたどりつくことができます。Read less

    「顧客の声を聞かない」とはどういうことか
  • TDD研修 by t_wada さん を開催しました - Classi開発者ブログ

    こんにちは。エンジニアの原です。 先日、「テスト駆動開発」の翻訳者として知られるt_wadaさんこと和田卓人さんをお招きして、テスト駆動開発ワークショップの第1回目をオンラインで開催しました。 今回はその様子をお届けします。 日は Classi 株式会社様にお招きいただき、1日コースの TDD ワークショップをオンラインで行いました。参加される皆様のレベルが高めなので反転学習の要素を取り入れた研修を設計しましたが、予想以上に効果があったと手応えを感じています。ご参加くださいました皆様、ありがとうございました!— Takuto Wada (@t_wada) December 15, 2020 きっかけ Classiでは毎年外部講師をお招きして勉強会を行っています。 新卒研修を行う中で、「テストコードを実装する際の勘所」をどう伝えようかという話があり、第一人者のt_wadaさんをお呼びして研

    TDD研修 by t_wada さん を開催しました - Classi開発者ブログ
  • 社内勉強会で専門的技術力を高めるには

    ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog サイトオペレーション部に所属している大津と申します。普段CDNとNode.jsサポートの仕事をしていて、第9代黒帯(ヤフー内のスキル任命制度/ネットワーク・セキュリティ)に任命していただいています。1 先日ヤフー社内で黒帯LT会が開催されました。お題目は事前に指定された「専門的技術力を極めるための極意」ということで、10分ほど話をしました。しかし、これまでみたいにセミナールームで大勢の前で話すわけではなく、最近代わり映えしない自宅デスクからのオンラインLTは、正直勝手が違いました。時間配分もミスって中途半端に終了です。と思いきや数日前、このYahoo! JAPAN Tech Blog担当者から「いやー、よかったですよ。そのネタ書

    社内勉強会で専門的技術力を高めるには
  • tigの使い方とオプションをまとめた - iberianpigsty

    CUIなGitクライアント。 普段使いのツールだが、社内勉強会の際に改めて調べた。 色々と便利なオプションがあった。 tigの特徴 Gitクライアント CUI マルチプラットフォーム tigのいいところ 軽い インストールさえされていればX動いてなくても使える ログのツリー見て、diff見て、編集のワークフローが快適 vim likeに使える インストール Linux/Windowsの人(apt使えるなら) sudo apt-get install tig Macとか brew install tig 基的な使い方 ターミナルでtigとタイプで起動 h押せばヘルプ出る qで閉じる vim likeなキーバインド j, kで上下移動 /で検索 コミットログ見るとき ブランチの枝分かれが見やすい Enterで分割して、左がコミットログ、右がDiffが見れる Diff見ながら<C-n>(nex

    tigの使い方とオプションをまとめた - iberianpigsty
  • Dockerイメージ分析ツール「dive」を利用してDockerイメージを軽量化する - 🤖

    はじめに Docker イメージサイズは小さければ小さいほど、Push と Pull の高速化につながり嬉しいです。 docker historyによってイメージレイヤーごとのサイズは分かりますが、どのレイヤーのどのファイルのサイズが大きいかは分かりません。 $ docker history maven:3-amazoncorretto-11 IMAGE CREATED CREATED BY SIZE COMMENT eb8a5bbcd061 12 days ago /bin/sh -c #(nop) CMD ["mvn"] 0B <missing> 12 days ago /bin/sh -c #(nop) ENTRYPOINT ["/usr/local/b… 0B <missing> 12 days ago /bin/sh -c #(nop) COPY file:2bbb488dd73

    Dockerイメージ分析ツール「dive」を利用してDockerイメージを軽量化する - 🤖
  • プロダクトマネジメント入門: 失敗しないプロダクトの作り方を学ぼう

    Founder Customer Fitこのセクションについて解決したい課題を見つけよう顧客を決めようリーンキャンバスを書こうミッションを決めようCustomer Problem Fitこのセクションについてペルソナを立てよう共感マップをつくろうカスタマージャーニーマップをつくろう課題仮説を整理しようプロブレムインタビューをしようProblem Solution FitこのセクションについてPEST分析をしようフックモデルを定義しようプロトタイプをつくろう解決策仮説を整理しようソリューションインタビューをしようSolution Product Fitこのセクションについて名前をつけようユーザーストーリーマップをつくろうMVPを構築しようMVP仮説を整理しようMVPインタビューをしようProduct Market Fitこのセクションについてグロースサイクルを定義しよう利用規約をつくろうプロ

    プロダクトマネジメント入門: 失敗しないプロダクトの作り方を学ぼう
  • Goを学ぶときにつまずきやすいポイントFAQ | フューチャー技術ブログ

    他の言語になれた人が、初めてGoを書いた時にわかりにくいな、と思った部分はどういうところがあるのか、難しいポイントはどこか、という情報を自分の経験や、会社の内外の人に聞いたりしてまとめてみました。まだまだたくさんあるのですが、多すぎるのでまずはこんなところで。コンテナで開発することがこれからますます増えていくと思われますし、その時にコンテナとの相性が抜群なGoをこれから使い始める人もどんどん増えていくと思います。 Goは特に言語のコアをシンプルに、何かを実現するときはそのシンプルな機能を組み合わせて実現しよう、というコンセプトです。つまり、他の言語で実現したいこと・できていることに比べて、Goは組み合わせ(イディオム)でカバーする領域が広くなります。そのあたりのとっかかりになる情報を提供することが、これからGoを触る人にとってつまずきを減らすことになると思います。 Go Conferenc

    Goを学ぶときにつまずきやすいポイントFAQ | フューチャー技術ブログ
  • 開発体験(DX)改善について知るために2021年1Qに読んだリソース - kymmt

    ここで開発体験(DX: developer experience)はおおむね次の記事で説明されている概念とする。digital transformationではない。 DX: Developer Experience (開発体験)は重要だ - Islands in the byte stream 2021年になり、担当するWebサービスDXの改善を任務とするチームに所属しはじめた。こういうチームができるぐらいなので、開発体験を悪化させるという感覚を開発者に与える課題はいくつかわかっている。それらを一つ一つ解決していけば、改善業務をある程度は進められそうだと考えてはいた。一方で、あくまで各開発者の感覚に依存して課題を把握していることが多いので*1どれぐらいよく/悪くなっているかはわかりにくく、改善がどの程度Webサービスのビジネスそのものに影響するのかというのもぼんやりとしていた。 こうい

    開発体験(DX)改善について知るために2021年1Qに読んだリソース - kymmt
  • モノレポについての誤解 - Misconceptions about Monorepos: Monorepo != Monolith を翻訳しました | Graat(グラーツ)-グロース・アーキテクチャ&チームス株式会社

    モノレポについての誤解 - Misconceptions about Monorepos: Monorepo != Monolith を翻訳しました unsafe:このドキュメントは、モノレポについて書かれた記事 Misconceptions about Monorepos: Monorepo != Monolith (https://blog.nrwl.io/misconceptions-about-monorepos-monorepo-monolith-df1250d4b03c) を、筆者であるVictor Savkin氏の許可を得て翻訳したものです。 複数のプロジェクトを同一のリポジトリで運用する モノリシックリポジトリ(モノレポ)― この記事では、モノレポを使う際によくある誤解とその対策、モノレポが持つ当の課題と利点がまとめられています。モノレポはガチガチの「一枚岩(モノリス)」

    モノレポについての誤解 - Misconceptions about Monorepos: Monorepo != Monolith を翻訳しました | Graat(グラーツ)-グロース・アーキテクチャ&チームス株式会社
  • 情報ではなく経験をアウトプットすること - 余白

    調べれば大抵の情報は誰でも手に入る今日このごろ。特に技術的な情報はオープンソースで一次情報へのアクセスは容易になった。 それと同時に繰り返し言われるアウトプットの重要性。 しかし、ブログやLTなどでアウトプットしても、「もっと質のいい情報があるのに自分がアウトプットする必要があるのか」「逆にノイズになるだけじゃないか」というような考えになってしまう人もいるのではないか。 そんな架空の声にお応えして、それでもなおあえて、一次情報ではない「あなたのアウトプット」の重要性を伝えてみようと思う。 実際にやる人は多くない 定量的なデータがあるわけではないが、直感的に共感してもらえるだろう。 ある技術や手法が話題になったとして、それを情報として知っている人はこの時代いくらでもいる。 だが、それを実際にその手でやったことがあるというだけでかなり群衆からは抜きん出た経験を持つことになる。 ましてやそれをや

    情報ではなく経験をアウトプットすること - 余白
  • DDDで複数集約間の整合性を確保する方法(サンプルコードあり)[ドメイン駆動設計] - little hands' lab

    株式会社ログラスの松岡です。 記事では、DDDに関する疑問で頻出な、複数集約間の整合性を確保する方法について、具体的なコードを交えて紹介します。 実装方法は、主に以下の3つに分かれます。 ユースケースで複数集約に更新をかける ドメインサービスを使用する ドメインイベントを使用する 目次 目次 集約の定義について 題材とする事例 実装方法1. ユースケースで複数集約を更新する メリット・デメリット 実装方法2. ドメインサービスを使用する メリット・デメリット 改善案 実装方法3. ドメインイベントを使用する ドメインイベント作成に制約をつける メリット・デメリット まとめ 集約の定義について詳しく知りたい方は 現場での導入で困ったら 集約の定義について 集約自体の説明については、記事では割愛します。詳しくは下記の書籍「集約」の章をご覧ください。 little-hands.booth.p

    DDDで複数集約間の整合性を確保する方法(サンプルコードあり)[ドメイン駆動設計] - little hands' lab
  • Dockerfileのベストプラクティス Top 20

    文の内容は、2021年3月9日にÁlvaro Iradierが投稿したブログ(https://sysdig.com/blog/dockerfile-best-practices/)を元に日語に翻訳・再構成した内容となっております。 Dockerfileのベストプラクティスのクイックセットをイメージビルドに適用することで、セキュリティ問題を防ぎ、コンテナ化されたアプリケーションを最適化する方法を学びます。 コンテナ化されたアプリケーションやマイクロサービスに精通している人なら、自分のサービスがマイクロサービスであることに気づいているかもしれません。しかし、脆弱性の検出、セキュリティ問題の調査、デプロイ後の報告や修正など、管理のオーバーヘッドがマクロな問題になっています。 このオーバーヘッドの多くは、セキュリティをシフトレフトし、開発ワークフローの中で可能な限り早く潜在的な問題に取り組むこ

    Dockerfileのベストプラクティス Top 20