並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 40 件 / 771件

新着順 人気順

MVCの検索結果1 - 40 件 / 771件

  • 良いコードとは何か - エンジニア新卒研修 スライド公開|CyberZ Developer

    CyberZ CTO室のメンバーの森 (@at_sushi_at) です。 先日、株式会社サイバーエージェントの2021年度 エンジニア新卒研修でコードの品質に関する講義を行いました。 そこで話した内容とスライドを完全公開します。 45分の内容のため、かなり長いですが、個人的にぜひ一読して欲しい内容になっています。 はじめに こんにちは、森 篤史と言います。2019年度入社で今年で3年目になります。株式会社CyberZのOPENREC.tvというプロダクトでAndroidアプリチームのリーダをやっています。 最近はプログラムを書く仕事以外に、次世代マネジメント室という全社横断組織でDevelopers Blogの改善プロジェクトを実行したり、CyberZ CTO室で組織活性化に取り組んでいます。 あと、2019年度の未踏スーパークリエータにも認定されました。 メインの仕事としては、入社して

      良いコードとは何か - エンジニア新卒研修 スライド公開|CyberZ Developer
    • ChatGPTを最強の学習ツールにする方法 - Qiita

      質問のコツ 質問内容は抽象的な言葉よりも具体的な言葉を選ぶようにすると、回答の精度がより上がります。 回答内容に対して、更に質問を繰り返して深掘りしていくと理解度が高まり効果的です。 「あなたはプロのエンジニアとして振る舞って下さい」などと最初につけるとよりそれっぽくなります。 文章が長くて途中で終わってしまう場合は、「続き」と入力すると続きからの回答をしてくれます。 わかりやすく解説してもらいたい時は「小学生でもわかるように解説して下さい」などとつけるとわかりやすい回答が返ってきます。 「私はプログラミング初心者です」など自分のレベル感を付けると、レベルに応じた回答になります。 「コードブロックだけで返事をしてください」とつけるとコードだけで回答してくれます。 ロードマップ(カリキュラム)編 まずは、目標に向けてどういった勉強をすべきかというロードマップ(カリキュラム)を提案してもらいま

        ChatGPTを最強の学習ツールにする方法 - Qiita
      • エンジニア向けチートシート集 - Qiita

        Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 今回はエンジニア向けのチートシート集のまとめを紹介していきます。 チートシートを利用することで 作業効率が上がる 概要が掴みやすい 学習にもなる といった恩恵が得られます。 ただし前提として毎回コードを書くたびに「チートシート集でカンニングすればええや」と思うのではなく「最初はチートシートでカンニングしつつ徐々に体で覚えていく」ことを意識して使うことが大切です。 最終的にはチートシートは見ずに「自分の使える技術」として定着させるための道具だと思って使ってください。 この記事の対象者 エンジニア初心者~中級者 作業効率を上げたい

          エンジニア向けチートシート集 - Qiita
        • 技術選定/アーキテクチャ設計で後悔しないためのガイドライン - Qiita

          Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 本稿は、ソフトウェア開発を進める際に直面する様々な技術的な意思決定やライブラリ・フレームワーク・XaaS等を選択し正しく活用していくのかについての考え方をサポートすることを目的としています。「すべてにおいてこのようなワークフローを通じて検討すべきである」という主張ではありません。読者の抱える問題領域に応じて、必要な箇所を取捨選択するための1種の考え方を提供するものです。 そもそもアーキテクチャ・技術選定に時間をかけるべきか まず第一に伝えておきたいことは、技術選定やアーキテクチャ設計に常に慎重であるべきではないということです。

            技術選定/アーキテクチャ設計で後悔しないためのガイドライン - Qiita
          • 【図解】初心者が知っておきたいサーバ周りの仕組みの話 - Qiita

            Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? ※2021年 3月28日 更新※ たくさんの方にご一読いただき、ありがとうございます。お読みいただいた方からご指摘を賜った点をもとに記事を修正いたしました。修正・追記箇所は末尾をご確認ください。 サーバ周りの仕組みについて、初心者でも最低限知っておくべきだと感じた内容を整理しています。 ここでいう「最低限」とは、プログラミング言語を勉強し、何かしらアプリケーションを作成して、ユーザが利用可能な状態にし(デプロイ)、公開するうえで必要になる知識のことです。 「サーバ」とは何か ユーザの要求(リクエスト)に応じて、**サービスを提供(レスポ

              【図解】初心者が知っておきたいサーバ周りの仕組みの話 - Qiita
            • 株式会社リクルート エンジニアコース新人研修の内容を公開します!(2023年度版) | Recruit Tech Blog

              こんにちは! 2023年度エンジニア新卒の、吉田です。 株式会社リクルート 新卒エンジニアコースでは、部署への配属前に、BootCampと呼ばれる新人研修を行っています。 本日は2023年度の研修の内容を、実際に受講した新卒の立場から紹介させていただきます。 研修の内容については毎年反響をいただいていますが、今年度も一段と進化し、より充実した研修でした。 ページ下部に研修資料を公開していますので、ぜひ研修の雰囲気を感じ取っていただけると嬉しいです。 研修の概要 エンジニアコースの新人研修は、配属後にスピード感を持って成長できるようになることを見据え、 「さまざまな技術領域の講座を受け、興味関心を広げて、知らなかった好奇心に出会う」 「現場で求められる『仕事への取り組みスタンス』をつかむ」 「気軽に相談できる仲間(同期)をつくる」 の3点が目的とされています。 今年度は、入社前に行われたスキ

                株式会社リクルート エンジニアコース新人研修の内容を公開します!(2023年度版) | Recruit Tech Blog
              • システムの複雑さはどこから来るのか – 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
                • SIerで幸せな技術キャリアを築くために - Qiita

                  Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事はNTTコムウェア Advent Calendar 2021 20日目の記事です。 NTTコムウェアの古西です。AI・データサイエンス推進室で技術マネージャをしています。 システムインテグレーター、略してSIerは、顧客のためにITシステムやサービス・ソリューション・プロダクトを開発・運用する会社です。一部自社サービスがあるものの、特定の顧客企業に対してシステムを提供することが多いです。 ネット上では 「SIerはオワコン」1と言われることもありますが、私自身は入社のときに 「人と技術を仲介する仕事がしたい」 と言って仕事をしは

                    SIerで幸せな技術キャリアを築くために - Qiita
                  • ブラックフライデー&サイバーセール開催! Udemyでは何を買う? 編集部の2021年イチ押しトピック10選 - はてなニュース

                    新型コロナウイルスの影響で、リモートワーク(テレワーク)やオンラインでの学習といった働き方・学び方の大きな変化は2021年も続いています。そんな2021年もあとわずか。やり残したことや学び残したことはありませんか? オンライン学習プラットフォーム「Udemy」では、2021年11月19日(金)~2021年12月1日(水) の間、年間最大のセール「ブラックフライデー&サイバーセール」 を開催します! 対象の講座がなんと1,200円から購入可能になります。 ブラックフライデーセールは11月19日(金)~11月26日(金)、サイバーセールは11月29日(月)〜12月1日(水)の開催です。11月27日(土)〜11月28日(日)はセール対象外なので、ご注意ください。 講座は買い切りなので、おトクなこの期間に気になる講座を購入しておいて、時間ができたときに自分のペースで学んでみるのもいいかもしれません

                      ブラックフライデー&サイバーセール開催! Udemyでは何を買う? 編集部の2021年イチ押しトピック10選 - はてなニュース
                    • プログラマーのための原則(2 万字) - Qiita

                      Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 今でも語り継がれる「原則」は、それだけ価値のあるコンセプトです。 歴史を振り返ることは、失敗を防ぐための効率の良い方法になります。 👑 DRY (Don't repeat yourself) 「同じことを繰り返すな。」 Andy Hunt と Dave Thomas の著書『達人プログラマー』(1999 年)で提唱された原則で、プログラミングに関する最も重要な原則といっても過言ではありません。 DRY 原則だけでなく、どんなデザインパターンやベストプラクティスでも、同じ処理が重複することは基本的に許されていません。 これには

                        プログラマーのための原則(2 万字) - Qiita
                      • Railsを主戦場としている自分が今後学ぶべき技術について(随筆) | うなすけとあれこれ

                        Rails の問題は Rails のベストプラクティスがフロントエンドのベストプラクティスの邪魔になるどころか全く逆方向で相反してる点です。DHHの思想がフロントエンドと根本的に逆行してる。そういう人が作るフレームワークなのでwebpackerの抽象化を根本的に間違ったりする。 — prev.js (@mizchi) December 1, 2020 昨日もリプライで少し書いたけど、DHH自体が直近のHeyの開発でも明確にJavaScriptというものを触れないようにすることを是としているような主張をしているので、DHH wayが色濃く反映される以上この状態はもう避けられない気がしている — potato4d / Takuma HANATANI (@potato4d) December 1, 2020 Railsがフロントエンドの最先端をゆく人々1から良く思われないのは事実として。 Vie

                          Railsを主戦場としている自分が今後学ぶべき技術について(随筆) | うなすけとあれこれ
                        • Smart UI パターンが再評価される世界 - id:onk のはてなブログ

                          設計ナイト2020 を受けて、今どんなアーキテクチャを選ぶべきかという話をしたくなったのだ。 kichijojipm.connpass.com 設計ナイトで高ぶった結果1時間コースの発表資料が完成したので供養場所を探しています。聞いてくれ!!!— Takafumi ONAKA (@onk) 2020年11月1日 お前誰よ 2000年代前半に SI 2000年代後半にブログ、SNS 2010年代にソーシャルゲーム 2020年代に UGC サービス をやってきた人間。数百万〜数億行のデータ、月間数千万〜数十億 imp 程度を主戦場にしています。 今日の話 DDD と PofEAA から学ぶパターン/アンチパターン Rails によって発見された、密結合で速く走れるソフトウェア 今求められているアーキテクチャ 昂ぶって 15,000 字ぐらい書いてしまった。 DDD と PofEAA から学ぶパ

                            Smart UI パターンが再評価される世界 - id:onk のはてなブログ
                          • データベース中心の設計になってしまう問題と闘う - laiso

                            『手を動かしてわかるクリーンアーキテクチャ 』の第二章の冒頭に登場する話題に共感したので紹介。 従来の多層アーキテクチャでは、データベースを中心にアプリケーションの 開発が行なわれます。この場合、Web 層はドメイン層に依存し、ドメイン層は 永続化層、つまり、データベースに依存することになります。そうなると、す べてのものは永続化層上に構築されることになり、その結果、いくつかの要因 が絡まり合って、問題が起きやすくなります。 手を動かしてわかるクリーンアーキテクチャ ヘキサゴナルアーキテクチャによるクリーンなアプリケーション開発 20p 手を動かしてわかるクリーンアーキテクチャ ヘキサゴナルアーキテクチャによるクリーンなアプリケーション開発 作者:Tom Hombergs,須田 智之インプレスAmazon 著者によれば、機能開発をデータベース中心に設計すると、ドメイン層と永続化層の密結合が

                              データベース中心の設計になってしまう問題と闘う - laiso
                            • 開発人生25年で学んだ7つのソフトウェア原則(翻訳)|TechRacho by BPS株式会社

                              概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Seven things I know after 25 years of development 原文公開日: 2025/01/27 原著者: zverok 日本語タイトルは内容に即したものにしました。 本記事は、私が2024年9月にEuRuKoカンファレンスで行ったキーノートスピーチを大まかに記事化したものです(スピーチの動画はこちらです)。残念ながら録画という形での登壇でしたが、それでも大変光栄なことでした。このテーマは私にとってとても重要なので、テキストで読みたい方のために、本記事で少々手を加えた形で公開することにいたしました。 私はかれこれ25年にもわたってソフトウェア開発に携わってきました。 そのうち20年間はメインの言語としてRubyを用いてきました。 私のRuby言語への貢献や、その他オープンソースへの貢献について

                                開発人生25年で学んだ7つのソフトウェア原則(翻訳)|TechRacho by BPS株式会社
                              • 独力でWebサービスを開発・構築できるフルスタックエンジニアへのロードマップ─幅広いスキルを「Udemy夏のビッグセール」で学ぶ! - はてなニュース

                                ※ この記事はUdemyメディアにも掲載されています。下記のリンクよりお読みください ▶️ 独力でWebサービスを開発・構築できるフルスタックエンジニアへのロードマップ─幅広いスキルをUdemyで学ぶ! ※ Udemy「夏のビッグセール」とはてなによるプレゼントキャンペーンは終了しました。記事で紹介しているフルスタックエンジニアのスキルは、引き続きUdemyの講座で学習できます。 Webで新規サービスを立ち上げる際に、UIからインフラ周りまで一人で面倒を見られるエンジニアは、少人数のスタートアップでなくとも非常に頼れる存在です。どんな課題に直面しても技術力で乗り越える、そんなスキルフルなエンジニアに憧れる方も多いでしょう。 この記事では、フロントエンドのプログラミング(JavaScript周辺)からサーバーサイド、インフラ、さらに開発手法まで、Web開発で必要になるさまざまなレイヤーのフル

                                  独力でWebサービスを開発・構築できるフルスタックエンジニアへのロードマップ─幅広いスキルを「Udemy夏のビッグセール」で学ぶ! - はてなニュース
                                • WASMとRustはVue.js/React.jsを打倒するのか? - JSへの侵略の歴史

                                  はじめに 「Typescriptの次はRustかもしれない」という記事がバズってるのを見かけました。 なかなか面白くて、PAとしてのWASMとRustを比較している記事です。ちょうど最近「レガシーおじさん、SPAを始めてみた。そして限界を知る」でも書いた通り最近SPAに手を出してみたのですが、いろいろやろうとするとSSRのためのBackend for Frontend (BFF)等が必要になるとわかり「これJSでやる必要なくない?」とも感じていたのでちょうど良かったです。 こういうのを見るとRIAやGWTのように似たアプローチで廃れた技術や、登場が早すぎたMeteor、今も頑張ってるMSのBlazorなど色々頭をよぎります。といわけで歴史を俯瞰する意味でHTML + JavaScriptとそれ以外の技術のせめぎ合いの歴史やMSのBlazorやRustのyewなどWebassemblyを使う

                                    WASMとRustはVue.js/React.jsを打倒するのか? - JSへの侵略の歴史
                                  • 実はDDDってしっくりこないんです - タオルケット体操

                                    DDD失敗パターン集 DDDという方法論それ自体に対する僕の立場はあんま好きじゃない寄りのフラット(といいつつほぼ忘れかけている)なんですが、過去何度もDDDでプロジェクトが爆死するのをみたり、爆破してしまったり……というのを見てきたので供養したいとおもいます。 メンバーの大半がDDDを知らない 「えっ!? ドメイン駆動を知らずにDDDを?」 「出来らぁっ!」 DDDを知らずにDDDをする、という前提がすでに禅問答じみてる気がしますが、たぶん一番よく見かける失敗パターンなんじゃあないでしょうか。 どういうことかというと、オニオンとかレイヤードとかクリーンなアーキテクチャのモジュールの命名ルールと構造を採用(採用できているとは言っていない)しただけの状態です。 私見ですが、アーキテクチャというのはメンバー全員がそれを理解できていない限り*1即破綻します。 理解できない人はどこに処理を書いてい

                                      実はDDDってしっくりこないんです - タオルケット体操
                                    • Claude Codeに保守しやすいコードを書いてもらうための事前準備やガードレール - くらげになりたい。

                                      Claude Codeを使いはじめて、いろいろ試してるけど、 なかなかいい感じのコードを書いてくれないな〜と思い、 いろいろ調べてみたときの備忘録(*´ω`*) えいや、でコード生成してくれるけど、 あとで自分で変更したり、保守したりするときに大変なので、 自分がいいとおもう感じに生成してほしかったりする。。 ドキュメントとサンプルコード大事... 事前準備やガードレール一覧 このあたりを用意しておくと、よさそうな感覚 プロジェクトに関するドキュメント(メモリ/コンテキスト: CLAUDE.md) lint/format/自動テストの設定&実行コマンド サンプルコード or テンプレートリポジトリ このあたりは任意、あるとより安心・便利 git-secrets Git Hooks(pre-commits) DevContainer Git Worktree ※おまけ ドキュメント大事・カー

                                        Claude Codeに保守しやすいコードを書いてもらうための事前準備やガードレール - くらげになりたい。
                                      • ソフトウェア設計・アーキテクチャの学び方 - Qiita

                                        Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに この記事はHow to Learn Software Design and Architecture | The Full-stack Software Design & Architecture Mapを翻訳したものです。 翻訳がおかしい箇所などあればご指摘頂けるとありがたいです。 元記事の著者: Khalil Stemmler(@stemmlerjs) 設計、アーキテクチャ、フロントエンド、ブロックチェーンに興味ある方是非Twitter(@show_clements)フォローしていただけると嬉しいです! 設計に関する記事

                                          ソフトウェア設計・アーキテクチャの学び方 - Qiita
                                        • 実践! Typescript で DDD - マイクロサービス設計のすすめ - Leverages Tech Blog

                                          対象読者 マイクロサービス化を検討しており、実際に作る場合の構成を参考にしたい。 ドメイン駆動設計について、基本的な用語の知識がある。 TypeScript を多少触ったことがある。理解がある。 はじめに こんにちは。エンジニアの吉村です。 現在、弊社が運営する teratail というサービスに携わっており、CakePHP で動作しているモノリシックな既存サービスをマイクロサービスに移行するというプロジェクトを進行中です。 この記事では、実務を通して得た知見として、マイクロサービス化によりどんな恩恵があるのか、具体的にどのような構成で実装をしているのかについてご紹介します。 TL;DR マイクロサービスのバックエンドサービスの実装に焦点を絞って、ドメイン駆動設計 + オニオンアーキテクチャをベースに設計をしました。 本記事では、具体的に「ユーザ新規登録処理」の実装をする場合を例にとり、実

                                            実践! Typescript で DDD - マイクロサービス設計のすすめ - Leverages Tech Blog
                                          • フロントエンドとSPA職人の目指したものの歴史と概略

                                            年末年始にフロントエンド論みたいな記事をいくつか見たが、僕ら古のSPA職人がやってきたフロントエンドという職域と目指していたものが失伝しかけている気がするので、ここに時代ごとに何を考えていたか、雑に書き殴る。 注意点として、 2004から始まるが、自分がプログラミングを始めたのが2010, 業務としてコードを書き始めたのが 2012 なので、解像度が高いのはそれ以降になる。 tl;dr 2004: 動き出す HTML 2011: 構造化のはじまり 2015: 贅沢品としてのSPAとコミュニティ分化 2017: 貧者のSPA 2019: 守破離としてのパフォーマンス 2004: 動きだす HTML AJAX の時代。要は XMLHTTPRequest で取得したコンテンツに応じて、動的書き換えをDOM書き換えを行うこと。今では名付けるほどでもない操作だが、HTMLが静的なものをやめたことは、

                                              フロントエンドとSPA職人の目指したものの歴史と概略
                                            • SIerで幸せなキャリアを築くために 50歳の私が感じた、若手に意識してほしい3つのこと

                                              「NTT Tech Conference」は、NTT グループのエンジニア有志が開催するカンファレンスです。NTT グループ各社が開催するイベントとは異なり、NTT グループのエンジニアたちがやりたいこと・話したいことを通じて、エンジニア同士が技術交流するためのイベントです。ここで登壇したのは、NTTコムウェアの古西孝成氏。「SIerで幸せな技術キャリアを築くために」というタイトルで、SIerとして幸せなキャリアを築くための心構えについて、話しました。全2回。前半は特に若年層に意識してほしいことについて。 自己紹介 司会者:次のセッションは「SIerで幸せな技術キャリアを築くために」というタイトルで、NTTコムウェアの古西さんに発表をお願いします。古西さん、よろしくお願いします。 古西孝成氏(以下、古西):はい、よろしくお願いします。NTTコムウェアの古西です。「SIerで幸せな技術キャリ

                                                SIerで幸せなキャリアを築くために 50歳の私が感じた、若手に意識してほしい3つのこと
                                              • ソフトウェア設計の Why & What & How | Wantedly Engineer Blog

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

                                                  ソフトウェア設計の Why & What & How | Wantedly Engineer Blog
                                                • Webフルスタックエンジニアになるためのチェックリスト

                                                  Webフルスタックエンジニアになるためのチェックリスト Zennでの投稿にあたって この記事は、2020/03/22に自分のgithubリポジトリで公開していた内容を、Zennのgithubリポジトリ連携機能を用いて一般公開したものです。 投稿にあたって、Zennの記事連携フォーマットに準拠する以外の修正は加えておりませんので、一部Zennというプラットフォームの方針や雰囲気に合わない内容などあるかもしれません。あらかじめご了承ください。 はじめに 日本のWeb開発業界で「フルスタックエンジニア」になるために必要な知識を、個人的経験からまとめました。 フルスタックエンジニアの定義ですが、ここでは、 企業で開発リーダー/テックリードとして、Webブラウザアプリケーションを前提としたサービスの立ち上げからリリース、運用まで面倒を見られる。 というロールと仮定し、前提条件としては、どちらかという

                                                    Webフルスタックエンジニアになるためのチェックリスト
                                                  • プログラミング文体練習

                                                    レーモン・クノーの『文体練習』から着想を得て執筆された本書は、1つの課題を異なるプログラミングスタイルで実装し、さまざまなスタイルの特性やスタイルが生まれた歴史的経緯などを解説します。本家の『文体練習』は、「バスの中で起きた諍いと、その張本人を後で目撃した」という内容を、公的文書風、宣伝風、業界用語風など、99の異なる文体で表現したものですが、本書は、「単語の出現頻度をカウントして多いものから出力する」という課題を、40のスタイルで実装しています。リソース制約が大きかった時代の方法から、オブジェクト指向、純粋関数型、リフレクション、並行処理、ニューラルネットワークまで幅広いスタイルを扱い、マルチパラダイム言語Pythonの威力と魅力を感じられる構成となっています。 訳者まえがき 第2版 まえがき 第1版 まえがき 序章 第Ⅰ部 歴史的スタイル 1章 古き良き時代:アセンブリ言語 2章 Fo

                                                      プログラミング文体練習
                                                    • VSCodeのGitHub Copilotが色々便利になっていた件

                                                      はじめに 知らない間にGitHub Copilotが結構進化していたので、それらの内容を紹介します。 GitHub Copilot Chatは知っていたのですが、単なるChatGPTみたいな会話機能を追加しただけだと思っていました。 要約 右クリックメニューや#fileのようなコマンドが登場し、それを入力するだけでChatに見てほしいコンテキストを伝えることができるようになった。 ファイル単位だけでなく、選択した行やブロックに限定することもできる。 テストコードや新しいプロジェクトをコマンド一つで生成できるようになっている。 推薦の候補も複数を同時に比較できるようになった。 一度に最大10個くらい出る上、タブで保管できる。 ターミナルや編集中のファイルからコマンド一つでChatを立ち上げることができる。 特別なプロンプトを入力しなくても、開いた場所の文脈を読み取ってくれる。 右クリックメニ

                                                        VSCodeのGitHub Copilotが色々便利になっていた件
                                                      • ソフトウェアアーキテクチャ入門

                                                        はじめに 今回の記事では、ソフトウェアアーキテクチャの入門的な内容を解説する。 対象とする読者 ソフトウェアアーキテクチャを勉強するエンジニア アーキテクチャに関して全くわからない初心者 タイトルで気になったひと ソフトウェアアーキテクチャとは? ソフトウェアのアーキテクチャは、システムの主要なコンポーネント、それらの関係(構造)、およびそれらがどのように相互作用するかを記述する。ソフトウェアのアーキテクチャとデザインには、品質属性、人間のダイナミクス、デザイン、IT環境など、多種多様な寄与要因が含まれる。アーキテクチャは、品質、保守性、パフォーマンス等のような全体的な成功に影響を与える重要な決定を含む。 ソフトウェアアーキテクチャの主な目的は、アプリケーションの構造に影響を与える要件を特定することだ。良好なアーキテクチャは、技術的な解決策を構築する際のビジネスリスクを削減し、ビジネス要件

                                                          ソフトウェアアーキテクチャ入門
                                                        • Next.js+microCMS+Vercel面白い - ゆーすけべー日記

                                                          Next.js と microCMS と Vercel が面白い。それぞれ面白いし、組み合わせるとさらに面白い。なにせ、メディアサイトがデプロイも含めて 2 時間で出来る。 Next.js + microCMS + Vercel すごいな。メディアサイト(中身スッカスカだけど)がものの 2 時間でデプロイまでできた。 https://twitter.com/yusukebe/status/1435708770705760256 ということで、メディアサイトを作りながら、Next.js と microCMS と Vercel の面白さをまとめる。 2 時間で作るメディアサイト 例として「ラーメンまとめ!」というメディアサイトを作ってみる。このサイトには ラーメン屋 ラーメン屋のまとめ記事 の 2 つの種類のコンテンツがある。「ラーメン屋」が「名前」「場所」「ラーメン写真」というプロパティを持

                                                            Next.js+microCMS+Vercel面白い - ゆーすけべー日記
                                                          • ミラティブのサーバサイドをGo + Clean Architectureに再設計した話 - Mirrativ Tech Blog

                                                            こんにちは、テックリードの夏です。 今年4月にCTOからテックリードに肩書が変わり、ガリガリコードを書くようになりました。 背景については、こちらをご覧ください。 www.wantedly.com 普段はプロダクト側の機能開発と、サーバ側の基盤開発を半々ぐらいの割合で仕事しています。 一口にサーバ側の基盤開発といっても定義が曖昧なのですが、基本的にはこんな感じのタスクをやっています。 インフラコストの最適化 不正なアクセスからの防御 障害の再発防止 新技術の導入やアーキテクチャの整備 今回はこのうち「新技術の導入やアーキテクチャの整備」の中で、サーバサイドをGo + Clean Architectureで再設計したことについてお話したいと思います。 背景 ミラティブは2015年春頃に開発が始まり、同年8月にサービスがリリースされ、2020年8月で5周年を迎えました。 その過程で組織やプロダ

                                                              ミラティブのサーバサイドをGo + Clean Architectureに再設計した話 - Mirrativ Tech Blog
                                                            • 【2024年版】エンジニア必見 生産性があがるチートシート集 - Qiita

                                                              1. 生成AIチートシート もはやエンジニアの必須ツールとなってきた生成AI。ペアプロやエラー対応などプログラミングに関わるところから、ビジネス判断におけるブレスト相手として、日常の些細なタスクにまで対応する強い味方です。またそれら生成AIを応用したAIエージェントやワークフローを用いたプロダクトなどの開発も日進月歩で進んでいます。 本パートでは、日々進化する生成AIを最大限に活用できるよう、多種多様な生成AIを一覧化して網羅したものから、それらの利用方法・プロンプトエンジニアリングにまで踏み込んだチートシートを集めました。 プロンプトエンジニアリング ソフトバンク - ChatGPTから高度な回答を引き出すプロンプト文例集 業務に使えるプロンプトが幅広く掲載されており、実用的です! マイナビ - プロンプトエンジニアリング・チートシート マイナビから公開されているチートシート。役割の設定

                                                              • Reactチームが見てる世界、Reactユーザーが見てる世界

                                                                Reactはシンプルなサイトから複雑なアプリケーションまで、非常に幅広く採用されている人気のフレームワークです。OSS化から10年以上の歴史がありながら、昨今もReact Server Componentsなど革新的なアイディアを我々に提案し続けています。 一方で、React Server Componentsへの批判的意見やBoomer Fetching問題などを見ていると、Reactチームと一部Reactユーザーの間には意見の相違が見て取れます。この意見の相違はそれぞれが置かれた状況の違いから生じるもの、つまり「見てる世界が違う」ことに起因してると筆者は感じています。 本稿では「Reactチームの見てる世界」を歴史的経緯を踏まえながら考察し、Reactの根本にある思想やコンセプトに対する読者の理解を深めることを目指します。 要約 ReactはMetaの大規模開発を支えるべく開発され、シ

                                                                  Reactチームが見てる世界、Reactユーザーが見てる世界
                                                                • [翻訳] Shopifyにおけるモジュラモノリスへの移行 - Qiita

                                                                  Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? こんにちは、食べログシステム本部長の京和です。 本エントリでは Shopify の Engineering Blog から、Kirsten Westeinde による「Deconstructing the Monolith: Designing Software that Maximizes Developer Productivity」を翻訳して掲載します。 食べログではユーザーや飲食店に価値を届けるスピードを最大化するべく、マイクロサービス化などをはじめとしたこれまでの組織やアーキテクチャを刷新するための取り組みを始めています。しか

                                                                    [翻訳] Shopifyにおけるモジュラモノリスへの移行 - Qiita
                                                                  • 個人開発で月1万円を稼げるようになった話。 - Qiita

                                                                    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに こんにちは。こんばんは。おはようございます! 今回は個人開発話でも書いてみようと思います。個人開発で月1万円を稼げるようになるというのは僕にとって1つの目標でした。同じように月1万円稼げるようになりたいぞ〜!という人もいるかもしれません。そういう人にこの記事が少しでも参考になればと思っています。 そして、実際にこの記事を読んで「個人開発をスタートした!」「眠らせてたアプリをバージョンアップした!」などのアクションにつながったとしたら、それが一番嬉しいです。 ちなみに僕はiOSアプリを開発しているので、iOSアプリによった話がメ

                                                                      個人開発で月1万円を稼げるようになった話。 - Qiita
                                                                    • データベースと向き合う決意 | フューチャー技術ブログ

                                                                      秋のブログ週間の9本目のエントリーになります。この企画もこんなに書く人が出てくるように育っていいですね。 「中間層を増やして柔軟性を高めるのがソフトウェアの歴史」 これは大学時代に2つ上の先輩が言っていた言葉です。例えばマシン語を直接書くのではなく、アセンブラで書けば、変換(コンパイル)の手間はかかりますが、他のCPUへの移植はしやすくなります。高級アセンブラと名高いC言語を使えばさらに移植性は上がります。C言語で書かれたVMを使う言語、例えばJava、Python、Rubyなんかはさらに移植性は上がります。 ストレージもそうです。最終的にストレージはビット列を保存するものですが、それにOSのファイルシステムというレイヤーがあり、そこにスキーマで管理されたデータを入れるDBMSが乗っかり、SQLなどの問い合わせ言語でデータ取得できるようにします。DBMSを挟むことで、レプリケーションでバッ

                                                                        データベースと向き合う決意 | フューチャー技術ブログ
                                                                      • ユニットテストってもう言わない! CI/CD時代のテスト分類に最適なテストサイズという考え方

                                                                        はじめに 以前からユニットテスト/単体テストという言葉は使いづらい、と感じており今回も旧Twitterで「テストを実行時間ベースで分類する良い言葉ないかなー」と呟いていたところ、「テストサイズのSMLって考え方があるよ」と教えて戴きました。 だいたいは教えてもらったt_wadaさんの記事にすべて書いてあるのですが、自分の整理も含めて動画にしたので、その補完記事となります。 TL;DR 単体テストのバベルの塔は既に崩壊 CI/CDでの継続的テストには時間ベースのテスト分類が重要 UT/IT/E2EではなくSMLによるテストサイズがCI/CDには合う それは単体テストか結合テストなのか? 自動テスト、手動テストに関わらずテストの分類として単体テストと結合テストという言葉は一般的です。 ITQBではTest Levelsという言葉で定義されていますし、以下のようなV字モデルの対応表はみんな知って

                                                                          ユニットテストってもう言わない! CI/CD時代のテスト分類に最適なテストサイズという考え方
                                                                        • 「AWSクラウド設計完全ガイド」はクラウドを扱うエンジニアにとって必読書になりそう説. - Lean Baseball

                                                                          「AWSクラウド設計完全ガイド」早速読みました&オススメかつ一部のエンジニアは必読書にしてもいいと思いました! ...という, 現役のエンジニア・システムアーキテクトおよびSREである私の読書感想文エントリーとなります. 良い本でした, B5サイズでちょっと大きい. 私の前職の同僚たち(それも社内で本当に強い連中*1)の共著で最初から期待しか無かったのですが, その期待値をめっちゃ超えてきた(ただし読み手として注意も必要, 後述します)のですごく良かった*2です, 紙もですがKindle(電子書籍)もすぐ買いました. AWSクラウド設計完全ガイド 作者:アクセンチュア 戸賀 慶/福垣内 孝造/竹内 誠一/浪谷 浩一/澤田 拓也/ 崎原 晴香/浅輪 和哉/村田 亜弥日経BPAmazon 何が良かったか一言で言うと, 「タイトル通り『AWSの設計ガイド』として成立しているかつ, Google

                                                                            「AWSクラウド設計完全ガイド」はクラウドを扱うエンジニアにとって必読書になりそう説. - Lean Baseball
                                                                          • 【Github Copilot】設計書があるなら、全部Copilotに実装させよう(途中経過)

                                                                            ウォーターフォールモデルに則った大規模開発で設計書があるなら、全部Copilotに実装させよう!をコンセプトに、どうすれば設計書をインプットに、Github Copilotが大規模開発の品質に沿ったコードを生成してくれるか、を日々模索しています。 まだまだ課題はあるものの、少しでも開発の役に立てばと思い途中経過を公開します。 このドキュメントでは、現時点での設計書からCopilotを用いて実装を生成する手順の紹介、使用するツールの紹介、工夫したポイント、現時点での課題について記載します。 こんな人に読んでほしい Github Copilotしか使えない環境にある方 Github Copilotをコードの説明や、単純なメソッド生成をさせる程度にしか使用していない方 期待したコードが生成されず、使わなくなってしまった方 前提 今回生成対象とするのは業務レイヤの実装です。Webアプリケーションで

                                                                              【Github Copilot】設計書があるなら、全部Copilotに実装させよう(途中経過)
                                                                            • レイヤードアーキテクチャ - kawasima

                                                                              POSAでの定義 レイヤードアーキテクチャを、体系だって書いたのは「Pattern-Oriented Software Architecture, Volume 1, A System of Patterns」だろう。まずはその原典に立ち返って、レイヤードアーキテクチャとは何かをみてみる。 コンテキスト ソースコードの変更がシステム全体に波及させたくない。それが1つのコンポーネントに閉じられ、他に影響を与えないようにすべきだ。 インタフェースは安定している。標準化団体によって規定されている場合もある。 システムの一部は交換可能である。コンポーネントはシステムの他の部分に影響を与えることなく、実装を入れ替えることができる。 現在設計しているシステムと同様の下位レイヤの課題をもつ他のシステムを、将来構築することがあるかもしれない。 理解のしやすさと保守性のために同じ責務はグルーピングしておきた

                                                                                レイヤードアーキテクチャ - kawasima
                                                                              • Claude Code に全部賭けて個人開発(モバイル、ウェブ、拡張機能)を自動化した話 - 5万円吹っ飛んだ実録

                                                                                Claude Code に全部賭けて個人開発(モバイル、ウェブ、拡張機能)を自動化した話 - 5 万円吹っ飛んだ実録 ベータテスト申込み 一緒にテストしませんか? (iOS と Andriod で各10名限定でβテスト公開しています!モバイルブックマークアプリ探している方是非是非!) Product Hunt ← Product Hunt で一位目指します!応援よろしくお願いたします! 💸 まず衝撃の事実から... 全部で 5 万円くらい気づいたら吹っ飛んだよ!(Claude Code の従量課金で) iOS, Android, Web, Chrome拡張機能, Go の全てをClaude Codeに90%くらい書かせました。 正直、最初は「Claude Code ってどのくらいコストかかるんだろう?」と軽い気持ちで始めたのですが、気づいたら請求額が 5 万円を超えていました。でも結論か

                                                                                  Claude Code に全部賭けて個人開発(モバイル、ウェブ、拡張機能)を自動化した話 - 5万円吹っ飛んだ実録
                                                                                • 【バックエンド】駆け出しエンジニアが目指すジュニアレベルのエンジニアとは【2024年版】 - Qiita

                                                                                  Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに こんにちは。 普段はフロントエンドの開発をメインでやっておりますmamiと申します。 最近バックエンドの方の勉強や、少しずつですがDB設計やAPI作成などの業務もやらせてもらえるようになったので、自分のエンジニアとしてのレベル感や、この先目指すべき道筋を明確にしたいな〜という思いでこの記事を書いております。 これは自分のための記事であると同時に、同じように駆け出し中のエンジニアさんや、ミドル層を目指す手前のエンジニアさんにも刺さる内容になっているかと思います。 今、自分がどのようにキャリアアップしていくべきなのか、どのような道

                                                                                    【バックエンド】駆け出しエンジニアが目指すジュニアレベルのエンジニアとは【2024年版】 - Qiita