developmentに関するlepton9のブックマーク (6,131)
-
lepton9 2025/02/08
-
非開発職から Amazon Japan のソフトウェアエンジニアへ社内転職した話｜Yuki
はじめに2024 年 4 月に新卒で入社した Amazon Web Services Japan の Solutions Architect (SA) 職から、2025 年 2 月より Amazon Japan の Software Development Engineer (SDE) 職へ社内転職をします。 自己紹介や新卒で AWS に入社した理由については 、1 年前に投稿したこちらの記事をご覧ください。 先日アメリカの大学を卒業し、日本に帰国しました。 アメリカでのソフトウェアエンジニア新卒就活失敗体験記を書いたので反面教師にしてください！！https://t.co/y2FSDaDXJi — Yuki (@yuki_0206_cs) January 11, 2024 お断りこの社内異動について、誤解のないようお伝えしたいことがあります。AWS や SA（技術営業）という職種に対する不
-
Webサービスぶっ壊れ地獄、行きやすぜ！
はじめに なあジョージさんよ……あんた、いつもこう言ってたよな？ 「便利さとシンプルさ、それがユーザーも開発者も幸せにする秘訣だ」ってよ。 あたしゃな、その言葉に乗っかっちまった。ユーザーのため？ 開発を効率化するため？ そりゃあ立派なもんだ。でもな、それが「命取り」になることがあるんだぜ。 シンプルに作ったはずのサービスが、悪意ある奴らに好き勝手利用されて、時には「あたしの知らなかった地獄」を見せてくれる。越えたらいけない一線がある。そんな話を、今日はしようじゃねえか。 さあ、これがあたしらの舞台だ。 セキュリティの教科書には載らない、バグバウンティでも指摘されない、ニュースにもならない、「 現場のWebサービスぶっ壊れ地獄 」 ……教えてやりますぜ！！ 1. サインアップし放題からのクレカ決済し放題地獄 この地獄、知ってやがるかい？ 聞いてくれよ。ユーザーを簡単にサインアップさせる……
-
ソフトウェア開発の “見積り” と “計画” を混同するから話が噛み合わない｜mtx2s
“見積り” を作成した開発チームと、それを確認したビジネス担当者や経営者が、その内容を巡って対立することがあります。「見積りが大き過ぎる」「いや、これぐらいはかかりますよ」といったあのやり取りです。 これはおそらく、両者がともに “見積り” と “計画” を区別せず、混同しているから発生しています。見積り依頼を受けた時、開発チームが提出するものは、おそらく “見積り” です。しかし、ビジネス担当者や経営者が期待するアウトプットは “計画” なのです。 こうして “見積り依頼” という名のもとに、ソフトウェア組織に対立が日々生じているのではないでしょうか。 “見積り” と “計画” は別物見積り結果の「30人月」という数字（①）は、計画ではなく見積り工数です。そんなことは当たり前ですよね。 工数が明らかになれば計画なのか？それでは、30人月の開発を5人でこなすから「6か月」かかる（②）、とい
-
2025年版 DynamoDBを本格的に使いたい開発者のためのDynamoDB利用ガイド - KAKEHASHI Tech Blog
DynamoDBも当初はマネージドとしてシンプルでしたが要求が増えるにつえ複雑になってきました。 ＊ソフトウェアでは良くあることで、そして新しくシンプルなものが生まれ新しいサイクルが始まる モデリングなどはドキュメントを見ていただきつつ、この記事では間違えやすい抑えていただきたいポイントを解説します on-demandモードを使う 初期設定はprovisionedモードになりがちですが固定料金を取られます。また、トラフィックが読めないとき、増減激しいときもあるでしょう on-demandモードが無難です(2024/11/1から半額になりなおさら) CDKの場合、dynamodb tableV2を使うと初期設定でon-demandです provisionedになっているテーブルを探すならAWS Configを使えばアカウント横断で検索できます provisionedは上級者向け。地味に難しい
-
GitHub Copilot Workspaceが提供されて、僕たちの開発はどうなっていくのか - 理系学生日記
GitHub Copilot WorkspaceのTechnical PreviewがGitHub有償ユーザ向けに公開されました。GitHub Copilotを有償で利用している方は、すぐに使える状況になっていると思います。 僕も少しだけ使ってみたのですが、今後の開発プロセスを大きく変えていくだろうなという感触を持ったので、ではその「変わった先」というのがどういうものになると思っているのかを書いてみます。 GitHub Copilot Workspaceとは GitHub Copilot Workspaceの苦手なところ 僕たちのプロセスをどう変えるのか 課題はプロンプト生成 設計仕様とテスト工程の連携 では開発フローは？ 設計との向き合い方 GitHub Copilot Workspaceとは GitHub Copilot Workspaceを一言で言うと、AIを活用したコーディング支援
-
2024年に乗り換えた or 乗り換えつつある開発関連ツール - valid,invalid
2023年か2024年か記憶が怪しいものもあるが自分の中で"最近乗り換えたもの"ぐらいのノリで書いていく。レイトマジョリティの自覚あり。 JetBrains系エディタ（RubyMine etc.） → Cursor (移行中) 一番大きい移行。2024年末〜2025年始に移行を試み、今も手探り中。 www.cursor.com きちんと評価するためにPro planを契約した。 Cursor Tabの体験が圧倒的に良い コード補完は古くはTabnine、2022年からGitHub Copilotを経験してきたが段違いに感じる シンプルに補完内容が優れているだけでなく 複数行の変更、変更後の次の変更の提案などが高速で賢く "ワカっている" 感がすごい Composer (normal mode. not agent) がかなりまともなコード出力や修正提案をしてくれる 年始に新しいツールを書き
-
AIと個人開発したくなったらまずCursorで要件定義だ！
はじめに こんにちは！yasunaです！ 私は普段は会社員をしていてエンジニアではないのですが、趣味でプログラミングをしています！ 今回はAIの力をフル活用しながら個人開発アプリの要件定義を作るまでの流れを記録しておきたいと思います。 今回作ろうとしているアプリケーションについて 「TikTok台本作成支援システム」というアプリケーションを作ろうとしています。ユースケース図はこんな感じになりました。 この図を作るときに役に立ったのがAI搭載エディターのCursorです。 CursorはAIがコードを生成してくれるので、コードを書くのが苦手な私のような人でもAIとチャットしながらコードを書くことができます。 こちらの図もCursorでmdファイルを作成して図に変換しました。 これはPlantUML（プラントユーエムエル）という図表作成用のマークアップ言語です。 UML（Unified Mod
-
なぜスプリントレトロスペクティブでKPTをお勧めしないのか
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） みなさんこんにちは。@ryuzeeです。 KPT（Keep, Problem, Try）はシンプルで使いやすいフレームワークとして知られていますが、スクラムのスプリントレトロスペクティブで繰り返し（毎回のように）利用することはお勧めしません。 なお、KPT自体が有効でないと言っているわけではありません。スプリントレトロスペクティブで繰り返し利用することに対する問題提起です。 たとえば何らかの大きな取り組みの最後に行ったり、プロダクトゴールを達成したあとや四半期ごとに長めの時間をとって全体を見たりするときには有効なこともあります。 また、ずっと改善を繰り返してきて非常に練度や能力が高くなっているチームの場合も有効かもしれません
-
中間管理職のコツを教えるよ！
anond:20241019210554 上司として接されることに慣れない「上司として接しなくて良いよ」と部下に言うだけ 所詮は中間管理職の中のぺーぺーなのでお前らと一緒だとちゃんと伝えればいい（実際にそうだし） 評価するのも自分じゃ無いし、ただの時間管理してるだけの雑用係 偉い人扱いしなくていいからね、と伝えて同僚と同じように接して貰う あと、割といい加減に仕事しておいて、ミスしてたら「ごめん！間違えてたわ！」って言っとく そうすると上司として接してくれなくなるし、変な忖度なくなるので便利 これだけでチームはちゃんとまとまるしミーティングでギスギスすることもかなり減る ちなみにこういうミスにつけ込んでマウント取ろうとするような奴は仕事できないからさっさと別のチームに押し付けた方が良い 部下の仕事やメンタルケア部下の仕事のケアなんてやらんでいい 基本的には「自分でやれ」のスタンスで良いし、
-
良い仮説を評価する技術
『仮説行動』という書籍で扱っているトピックから、仮説の評価に関する内容を紹介しています。 💡関連スライド ・
-
「ドメイン駆動設計をはじめよう」の感想
1章 事業活動を分析する この章は事業活動を理解するためのドメイン駆動設計の考え方とやり方が解説されています。 感想 ドメイン駆動設計は事業活動と構造を理解するところから始まります。 理想的には設計者や開発者が業務全体を完全に理解したうえで設計や開発を進めることが望ましいです。 しかし、現実としては設計者や開発者がすべての業務を完全に理解することは極めて難しいです。 そこで重要となるのがコミュニケーションとなります。 業務エキスパートと密にコミュニケーションをとり、本来の意図を漏れなく汲み取ることがなにより重要になると思います。（どのようにくみ取るかは次章で解説されています。） この辺りはSIerとして参画する場合に特に必要とされると思います。 いかにステークホルダーを巻き込みながら業務エキスパートとの信頼関係を築けるかが、プロジェクトの成功を左右すると言っても過言ではないと思います。 2
-
うわっ…私のエディタ、ダサすぎ…？ナウなヤングにバカウケするCursor・VSCodeのイケイケ設定
はじめに メリークリスマス🎅 2024年も残りわずかということで、最後にネタ記事を投稿して年を納めたいと思います。 突然ですが、いつも使う開発環境こだわっていますか？ 自分は、一部の人たちにはVimを布教する熱心な信徒だと思われていますが、ただ布教するだけではその人にとって実用的ではありません。 個人的な観測に基づきますが、意外にもVimmerじゃない開発者は結構こだわりが薄かったり、エディタのテーマを変える程度だったりするので、今回は多くの人が使っているであろうCursorとVSCodeを対象とした実用的なカスタマイズ方法をご紹介します。 ただのカスタマイズ方法ではありません。ナウなヤングにバカウケするイケイケ設定です。 お断り
-
-
trapを使ったシェルスクリプトの終了処理のテンプレ（POSIX準拠） - Qiita
# 終了処理（$1: シグナル名） cleanup() { # 終了処理中に無視するシグナル（他に必要な場合は追加する） trap '' HUP INT QUIT PIPE TERM # ここに終了処理を書く : TODO # 自分自身にシグナルを再送信することでシェルスクリプトを終了する trap - EXIT "$1" [ "$1" = EXIT ] || kill -s "$1" $$ || exit 1 } # トラップするシグナル（他に必要な場合は追加する） for i in EXIT HUP INT QUIT PIPE TERM; do trap 'cleanup '"$i" "$i" done # ここより下に実際のシェルスクリプトの内容を書く : : 自分自身にシグナルを再送信しているところが特徴的だと思いますが、その理由についての解説がこの記事の内容で、POSIX 準拠で
-
ユーザー名をURLに含めるなら@始まりにするとよさそう
SNSなど、ユーザー名をURLに含めているサービスは色々ある。このZennもそうだ。ただ、考えることが多い。例えば以下の点だ。 システムで使いたい文字列をユーザー名に使われる可能性があるので、ユーザー名に使えない膨大な文字列のリストを管理する必要がある 実装に失敗すると、一部のユーザーだけ特別扱いするルーティングを独自実装する必要が出かねない 簡単な対応策としては /user/{ユーザー名} のようなURLの規則にすること これを採用しているサービスもあるが、見た目がダサいからか、あまり好まれていない印象がある ということで、現実的な解決策として @user_name みたいな@始まりのURLにする方法がある。 自分が知る限り、最初にこれをやったのはMediumだが、Mediumは現在サブドメインにするルールになったようで、いつの間にかこの形式を辞めてしまった。 実はTwitter（現X）
-
SBOM導入・運用の手引き | デジタル人材の育成 | IPA 独立行政法人 情報処理推進機構
想定読者 本書ではSBOMの導入・運用を主導する部門を主な対象読者として想定しています。また、SBOMを知らない組織をはじめ、導入に課題を抱えている組織、導入後に活用できていない組織など、幅広い組織層を対象としています。 本書の構成 第1章 背景と目的 第2章 SBOMの概要 第3章 SBOM導入・運用に関する基本指針 第4章 環境構築・体制整備フェーズにおける実施事項 第5章 SBOM作成・共有フェーズにおける実施事項 第6章 SBOM運用・管理フェーズにおける実施事項 第7章 まとめ Appendix ダウンロード SBOM導入・運用の手引き(PDF:3.0 MB) 更新履歴 2024年12月20日
-
アーキテクチャレベルで依存性を逆転させたら最高だった話
はじめに LITALICO の @katzumi です。 2020 年に LITALICO へ Join して以来、ずっとレセプト業務の開発に携わってきました。 レセプト業務は複雑なドメインゆえミスが許されず、さらに３年に一度の大きな報酬改定があり、ロジックが大幅に変わります。 その改定作業は情報公開から実装完了までの期間が約 3 ヶ月と短いです。また、年々複雑化するシステムに対応する必要があります。 その複雑な業務に立ち向かった内容を過去にも以下の内容で開発業務の記事を書いていました。 今年 2024 年は法改正の年になっており、取り組みの結果、その後どうなったのか？を振り返っていきます。 今回も壮絶だった法改正 私自身の大規模法改正の経験が今回で 2 回目となります。 チーム構成としては私ともう一名を除いて前回の 2021 年度法改正を経験したメンバーがいませんでした。前回は 3 種類
-
ペアプロが嫌すぎて会社を退職した話 - Qiita
📒ペアプロ・モブプロアンケート実施中 🖊️ あなたのご意見をお聞かせください。(2025/1/3 23:59まで） 回答結果は2025/1/6(月)にQiitaで公開いたします。 アンケートはこちらから（1分ほどで終わります） はじめに 巷ではペアプロ、モブプロがホットワードになっており、あたかも開発生産性を向上する特効薬のように取り上げられている印象を受けます。一方、この記事では、ペアプロ、モブプロ開発のネガティブな部分を考え、私の経験から感じたペアプロ、モブプロのアンチパターンとその改善策をご紹介します。 どんなアンチパターンを踏んでいたのか？ 勤務時間は100%ペアプロを実施（ソロプロ禁止） ソロプロは悪、ペアプロが最高というチームの雰囲気 フロー効率を過度に重視する姿勢 どうなったか？ ＋) 開発生産性およびデプロイ頻度は上がった ＋) 4keysなどの数値上の指標はすべてプラ
-
子育てしながら個人開発を続けるエンジニアのメモ - maru source
こんにちは丸山@h13i32maruです。 私は20年前の高専3年ごろに、当時ハマっていたオンラインゲームのツールをHSP（Hot Soup Processorって今も開発続いててすごい！）で作って、自分のホームページに公開していました。ユーザは自分以外だと2〜3人しかいませんでしたが、すごく楽しかった記憶があります。これが私の個人開発の原体験です。それから現在に至るまで個人開発を続けています。 ここ数年で特に気に入っているのは、Jasper（GitHub用のIssue/PRリーダー）やTrickle（自分のアクティビティを書き留めるサービス）です。今は開発していませんがOSSとしてESDoc（JSのドキュメンテーションツール）というものも作っていました。最近だとMTG Playbookというマジック・ザ・ギャザリング用のオールインワンアプリを積極的に開発しています。この20年で大小合わせ
公式Twitter
- @HatenaBookmark
リリース、障害情報などのサービスのお知らせ
- @hatebu
最新の人気エントリーの配信
キーボードショートカット一覧
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Copyright © 2005-2025 Hatena. All Rights Reserved.
設定を変更しました