APIを設計する前に読みたいガイドラインまとめ | NTT Communications Developer Portal
APIというのは主に外部の開発者が見ることになります。そしてその設計思想が彼らの思いとマッチしていないと使うのを嫌がられることになります。逆にエレガントで統一性のあるAPIは開発者を刺激し、使おうという姿勢に変えてくれます。 そこで今回は多くのAPIを提供している各社がリリースしたAPIガイドラインを紹介します。 interagent/http-api-design: HTTP API design guide extracted from work on the Heroku Platform API Herokuが実践しているAPIデザインガイドになります。ステータスコード、リソース、タイムゾーン、パスの付け方、バージョニングなど数多くの項目に渡って記述されています。 API開発指針 | EC-CUBE3 国産Eコマースシステム、EC-CUBE3におけるAPI開
開発効率を追い求めた実装プラクティス集
この記事は MICIN Advent Calendar 2023 の24日目の記事です。 前回はSaneさんの「データ基盤チームで社内インターンをやってみて」でした。 はじめに abekohです。MICINでMiROHAの開発をしております。 本記事では、書籍等から得た設計・実装パターンの知識や、実際にプロダクト開発で試して得られた経験などから編み出した、開発効率向上のためのWeb API開発のプラクティスを紹介します。 筆者が関わっているMiROHAは治験の業務支援を取り扱うプロダクトです。MiROHAの開発における特性として、以下のようなものが挙げられます。 治験業務に関するドメインが特有で複雑 前例が少なく、MVPを追求中。プロダクトのアプローチが頻繁に変わる 外部品質は高い水準が求められる これらの特性を意識して開発を促進させるために日々試行錯誤しております。 複雑なドメインに対す
テスト駆動開発のはじめの一歩｜t_wadaさんに聞く1人で始める自動テストのコツと考え方 - Agile Journey
アジャイル型の開発が導入されていない現場であっても、そして一人であっても、実践可能なアジャイルに関するプラクティスは存在します。 例えば、自動テストや、テストファースト、テスト駆動開発（TDD：Test Driven Development）です。ユニットテストフレームワークを使ってテストコードを書いて開発しながらテストを実行する「自動テスト」、実装の前にそのテストコードを書く「テストファースト」、テストと実装を繰り返しながらインクリメンタルに設計・開発を行うのが「TDD」。これらプラクティスのなかで、はじめの一歩となるのが自動テストですが、1人で実践するには、どこからはじめるか、どうテストを組み立てればよいのか、あるいは自分のテスト方法は適切なのか、不安を持つこともあるでしょう。 そこで本稿では、さまざまなチームや組織へのテスト手法の導入を支援し、精力的に講演や執筆などを行ってきたこの分
Google 、SalesforceのPMは、どう開発の難題に立ち向かう？ 強いプロダクト組織の考え方 | キャリアハック（CAREER HACK）
Google にてGroup Product Managerを務める徳生裕人氏、日本CPO協会・代表理事を務めるKen Wakamatsu氏が登壇。それぞれ複数の組織を見てきた観点から考える「強いプロダクト組織」の作り方とはーー。及川卓也氏によるモデレーションで行われたセミナーをレポートする。 ※2022年4月に開催されたクライス＆カンパニー主催「クライス汐留アカデミー」より『「強いプロダクト組織の作り方」～プロダクト組織作りの要諦となる採用と育成～』セミナーのレポート記事をお届けします。PM＝プロダクトマネージャーとして記載しています。 前半パートはこちら 後半パートはこちら Moderator クライス＆カンパニー 顧問 及川 卓也 MicrosoftにてWindowsおよびその関連製品の開発を担当した後、Googleに転職し、ウェブ検索やGoogleニュースのプロダクトマネジメントや
Webフロントエンドの開発効率を高く保つための考え方
これまでいろんな現場でWebフロントエンド開発をしてきて、メンテナンスしやすく効率の高いWebフロントエンド開発をする上で重要になる考えが自分なりにまとまってきたので記事にしてみます。 Worse is Betterという考え方 自分が見てきた中でWebフロントエンドの開発効率が落ちてしまう一番の要因は、きれいで理論的には優れているアーキテクチャを構築しようとしてそれ自体がもたらす複雑性を支えきれないというパターンです。 少し前にフロントエンドにClean Architecture（以下CA、あの同心円の図を指すのは誤用に近いですがここではそれに乗ります）を導入する記事が流行ったと思いますがあんな感じです。ああいったクラスベースでDIが重要となる設計手法はサーバーサイドのJavaでSpringを使うのとは違ってReactがサポートしているものではないため、CAの実現自体に高い設計スキルが必
「技術のスペシャリスト」になれないエンジニアのキャリアを考える - paiza times
StartupStockPhotosによるPixabayからの画像 こんにちは。倉内です。 エンジニアになったころは「とにかく手を動かし続けたい」「技術力で勝負したい」という方が多いのですが、実際ある程度働いてみると技術力だけで突破していくのは結構難しいことに気づきます。 尖った技術を武器にいわゆるスペシャリストとして生きていくことができる人はそう多くはなく、paiza利用ユーザー様からも「将来自分はどうすればいいだろうか…」という悩みをいただくことがあります。 エンジニアとしての市場価値を高めるには技術を磨くこと以外に、できることの幅を広げる、サービスやプロダクトの成長にフォーカスする、エンジニア経験を生かして転職する…など他の選択肢もあることを覚えておいてもよいでしょう。 そこで今回は、技術に全振りしないエンジニアのキャリア選択について考えてみたいと思います。 技術力オンリーで生きてい
なぜ今ソフトウェアテスト自動化に賭けるのか | chikathreesix
こんにちは、Autify CEOの近澤（@chikathreesix）です。 先日会社の紹介資料を公開しました。大変嬉しいことに多くの反響を頂いているのですが、会社の紹介資料には自動化に賭ける僕の熱い想いは詰め込めきれませんでした。そこで、なぜ我々が今テスト自動化に取り組んでいるのか、なぜテスト自動化がこれからの社会において重要なのか、改めてブログにまとめました。 テストの大半が未だに人手ソフトウェアテストとは、開発したソフトウェアが正しく動作するか検証する作業のことです。ですのでソフトウェアを開発するあらゆる組織において、テストを実施する必要があります。市場は非常に大きく、IT予算の1/3をテストに使っていると言われ、その額は130兆円にも登ります。 この作業ですが、未だにグローバルで見てもおよそ75%の企業が人手に大きく依存しています。人手のテストは当然人件費と時間が多くかかるわけです
Backlogを作ってるエンジニアが教えるBacklog活用術 - 開発チーム内外をつなぐ、課題管理の考え方 - エンジニアHub｜Webエンジニアのキャリアを考える！
エンジニアHub > 記事一覧 > Backlogを作ってるエンジニアが教えるBacklog活用術 - 開発チーム内外をつなぐ、課題管理の考え方 Backlogを作ってるエンジニアが教えるBacklog活用術 - 開発チーム内外をつなぐ、課題管理の考え方 プロジェクト管理ツール、コラボレーションツールとしてBacklogを採用しているチームは多いでしょう。多岐にわたる機能を利用できるツールですが、上手に使うためのアイデアと方法を、Backlogを生み出したヌーラボ社の中村知成さんが解説します。開発チーム内だけでなく、マーケやセールスなどを含めた、チームを横断した課題管理など、“中の人”ならではの知見をご紹介します。 株式会社ヌーラボの中村知成（ @ikikko ）です。Backlogの開発・運用全般のマネージャーを務めつつ、Backlogの導入・業務改善や、ソフトウェア開発現場の支援サービ
2年半のエンジニアリングマネジャー経験から学んだこと - valid,invalid
2017年6月〜2020年3月まで、Quipperという会社でEngineering Managerをやってみての振り返りです。 ここ数日こつこつと退職エントリを執筆していたのですがこのセクションが長くなりそうだったのと、単体で読まれても良さそうなので1エントリとして切り出しました。*1 マネジャーになった背景から失敗から学んだことから思いついたことをぐだぐだ書いていきますがはっきり言って個人の日記レベルなので野暮なツッコミはなしでお願いします。*2 というかこれは個人の日記ですよ〜。（ここまで防衛線） マネジャーになった背景 / 当初の役割 記憶が確かであれば2016年頃にQuipperにも評価制度が導入されたのですが、当時すでに世界に数拠点あったためCTO@Londonが全員を評価するのは難しくなっていました。可能な限り現地オフィスで現地メンバーを評価したほうが納得感も高い、ということ
Kibela開発における技術選択の指針を全部教える。必要十分に新しい技術を維持するための考え方 - エンジニアHub｜Webエンジニアのキャリアを考える！
Kibela開発における技術選択の指針を全部教える。必要十分に新しい技術を維持するための考え方 サービスの立ち上げや機能追加時には、どのような技術をどの観点から選択すればよいのでしょうか？ 自社サービス「Kibela」の実例を交えつつ、ビットジャーニーの井原正博さんがエンジニアと経営者の両視点から「技術選定」を考えます。 Yahoo! JAPANやクックパッドのエンジニアを経て、現在はビットジャーニーで代表を務める井原正博（@ihara2525）です。プライベートで超長距離のランを楽しむ傍ら、情報共有ツールKibelaの開発・運営を手がけています。 Kibelaについては、その立ち上げにあたってサービスを考えてリリースするまでのフローを以前に書きました。今回は、サービスの技術選定をテーマに、Kibelaを成長させるさまざまな段階でどのような選択を行ってきたか、具体例を交えながら紹介できれば
サービス開発初期の「時間を金で買う」技術
ウェブサービスをゼロから開発して徐々に規模を大きくしていく過程では、CI環境の準備などサービス開発を続けていく上で開発チーム自身が準備をしなくてはいけないツール群が多くあります。これらの問題は多くのチームで共通にみられることから、世の中には様々なSaaSツールが用意されています。優れたサービスはそれなりの価格設定がされているものですが、場合によっては有料サービスを利用することにより、チームがサービス開発に集中できる時間を増やすという戦略も取ることができます。この発表では、私自身が仕事やプライベートで使っている開発支援系のツールに関する紹介と導入する場合の考え方や検討事項などについてお話します。
git flow × Pull Request を使ってモダンな開発してみた - Qiita
はじめに この記事はgitflow&PullRequestの使い方を解説するというよりも、 使っている上で困ったことや、とまどったことの記録です！(ある程度使い方の流れもかいてますが) また、gitflowはリリースまでの流れを持っていますが、ここではfeatureブランチ作成〜developブランチマージまでしか触れていません。 導入予定なんだけど、使い方わからんよ〜という人はすでに優秀な記事がたくさんあるので、下のあたりのリンクをたどっていってくださいね〜 gitflowを使う準備 ▼gitflowって何？って人はこちら いまさら聞けない、成功するブランチモデルとgit-flowの基礎知識 ▼git-flowセットアップに関してはこちら http://chuross.hateblo.jp/entry/2012/12/30/021415 ▼自分はcentOS(Linux)にセットアップし
ソフトウェア開発で学んだが使わなかったもの
開発手法など、一通り学んだが実際に使っていないものは多少なりあると思う。それらについて掘り起こしてみたい。 スクラム開発認定スクラムマスター研修には研修会場ホストという立場で数回立ち会った。認定外の研修も幾つか受講した記憶がある。書籍もそれなりに読み、Scrum Gathering Tokyoなどのコミュニティにも顔を出し、まあそれなりに色々考えて捉えてきた。でも、自分のチームでは使っていない。スクラム開発というアイデアに矛盾があるからだ。 そもそもスクラム開発ではチームの自律的な行動を良しとしており、それに対する”フレームワーク”を提供しているということになっている。イテレーション、バックログ、ふりかえり、デイリーミーティング（いまだに「朝会」って言ってる人いないよね？）、そしてそれらのお作法。誰が言ったかわからないが、それぞれの作者の意図を察するためには「守」が大事らしい。守破離の「守
エンジニア立ち居振舞い：重箱の隅をつつかない - 面白コンテンツ探求日記
お題「エンジニア立ち居振舞い」 自分は重箱の隅をつつかないというのを意識してる。 重箱の隅をつつく問題はコードレビューの現場でよく聞く。レビューの場で所詮「書き方レベル」の指摘が横行してしまうというやつ。 誰しも綺麗なコードを追求したい気持ちはあると思うし、自分もそうなんだけど、あまり良くないなと思ってやらない事にしてる。理由は3つ。 時間の無駄 指摘される側の精神衛生上よくない そもそも意味ない 細かい指摘でも修正してマージするまでには結構時間がかかる。コードを直し、手元でビルド・動作確認し、pushしてCIを回し、「修正しました」と報告し、LGTMが付いてやっとマージできる。このプロセスが日に何度も発生すると確実に時間を食ってしまうし、Nitsな内容を何度も何度も受けると精神的にも疲弊してしまう。それで生産性が下がってしまえばもっと大きな問題になる。 こうした指摘をしたくなる時、「コー
DevOps スタータキットの公開 - メソッド屋のブログ
DevOps の概要、プラクティス、そしてそれに関するリソースを整理して自ら学習しやすいようにしてみました。DevOps の考え方、プラクティス毎に、ビデオとそこで使っているPPTを公開しますのでお楽しみください。 channel9.msdn.com docs.com docs.com 1. DevOps の歴史 DevOps を学ぶときに、海外と比べると日本の商習慣が異なるので、向こうで話されているDevOps の概要を聞いてもピンと来ないかもしれません。そこで、DevOps の歴史を7分程度で学べる動画を作成しました。 これで、DevOps が生まれきた背景が学べると思います。 docs.com 2. DevOps の概要 DevOps の歴史を知るとと、DevOps の概要がよりわかりやすいかもしれません。次のビデオをご覧ください。 docs.com DevOps プラクティス ビデ
Git（GitHub）の運用で気をつけていること - えいのうにっき
ある日、 PR の内容を見ずにマージすることを岡島（ピッチャーの）というらしい 笑った— いのうえ (@a_know) 2015, 9月 10 ということで、脳天気に笑っていたら、 @a_know むしろイキナリmasterリポジトリに直接pushするパターンですね！— そーだい＠初代ALF (@soudai1025) 2015, 9月 10 という話になり、そしてなぜだか、 @a_know push -fと同様、Gitの運用アンチパターンとかどこかに纏めがほしいですねー。 #ブログ待ってます— そーだい＠初代ALF (@soudai1025) 2015, 9月 10 というはなしになったので、本当に必要として頂いているのかどうかはともかく、 Git / GitHub でぼくやぼくの職場で気をつけていそうなことをまとめてみる。 もくじ もくじ GitHub Flow に沿って開発する 基本
俺が考える最強の新規サービス開発フロー - 小さなお城
インターネットサービスを想定した理想を書いてます。 エンジニアリングに特化した話ではなく、アイディアを思いついてからリリースするくらいまでの浅く広い話で、個人的な趣向であり、組織や環境によっては合わないかもしれません。 とりあえず、リーン・スタートアップとアジャイルサムライ−達人開発者への道−は、すごくいい本で勉強させていただきました。 アイディアを整理します 実現したいアイディアが解決するユーザプロブレム、提供する価値を整理します。 例えば、 ● ユーザプロブレム: お腹いっぱい美味しいものを食べたい！ ● 提供する価値 : 安くて美味しくて腹持ち良い食べ物屋さん アイディアの簡単なペルソナを想像します ペルソナとは提供するサービスの一番の顧客になってくれる人の人物像です。 例えば、 G太、小学1年生男児。体重40kg。 頭はおにぎりのような形をしており、10円ハゲがある。 小学校では
「これって、ドメイン駆動設計？」という資料を公開しました。 - GoTheDistance
いくら人の話を聞いてもピンと来ないし、DDD本を読んでも全然頭に入らないので、自分なりに解釈してまとめることにしました。よろしければ、どぞ。 これって、ドメイン駆動設計？ from Michitaka Yumoto www.slideshare.net ドメインからモデルを抽出→モデルの振る舞いと情報を定義→サービスに汎化させる、という流れを取っています。行間多めです。さーせん。 ドメインというのは、どうも2つの性質を持っている言葉のようだと思いました。 その世界で現状行われていること 行われていることに対する希望や不平不満からくる要求(関心事と言うらしい) 上記の定義がだいだいあってるとすると、「その世界で現在進行中の物事及びそれに付随する要求をキチンと実装できる設計にしようぜ」って話がドメイン駆動設計の総論で良いのでは、というのが１つ。 で、ドメイン(特にいまやってる物事)を抽象化す
ソフトウェア開発で得た教訓22箇条 | POSTD
1. 小規模なものから徐々に拡張していく。 私は日頃、新たなシステムを作るにせよ既存のシステムに機能を追加するにせよ、必要な機能すら殆ど持たないようなとてもシンプルなバージョンを作るところから始めるようにしています。そこから当初予定していた機能まで、段階的にソリューションを拡張していきます。私は初めから細部にわたって計画をできたことはありませんが、代わりに開発を進めていく中で新しく見つけた情報をソリューションに役立たせます。 私はJohn Gallの、この言葉が好きです。 “複雑なシステムというのは、往々にしてシンプルなシステムから発展したものだ。” 2. 同時に複数のものを変えない。 開発中にテストが失敗したとき、あるいは機能がうまく動作しなかったとき、1つだけ変更すれば、問題発見が格段に容易になるでしょう。言い換えるなら、短いイテレーションを行いなさいということです。1つずつ変更を行い
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
『流行のIT技術を追うのをやめたらプログラマとして成長した話』へのコメント
