サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
デスク環境を整える
yshibata.blog.ss-blog.jp
2023年12月1日から働き始めた株式会社令和トラベルを3月19日付けで退職します。1984年4月1日から社会人として働き始めてから9社目の会社でした。9社の中で最も在籍期間が短かった会社となります。 私自身は、今年の11月で65歳になります。ウェブサービスの業界で働き続けるとしたら、API仕様ファーストおよびE2Eテストによるテストファースト開発を経験するエンジニアを増やしていければと思っています。もちろん、私自身もソフトウェア開発を続けたいのは以前と変わりません。しかし、私自身が正しいと思わない方法でソフトウェア開発を続けたくなかったので退職することにしました。 API仕様ファーストとその仕様をテストする自動テストを(テストファースト開発で)整備しながら開発をするというのは、私自身はウェブサービスのバックエンドサービス開発に従事してから始めたことではありません。API仕様をきちんと記述
「API仕様ファースト開発」という用語は、私自身が雑誌「WEB+DB PRESS Vol.134」の特集1「実践API設計」を執筆する際に考えた造語です。 全く新規にサービスを開発する場合の開発順序は次のようになります(記事の題3章の図1)。 図1 API仕様ファースト開発での開発順序 これは、私自身が初めてメルペイで担当して、一からマイクロサービスを開発したときの開発順序です。そして、その後、チーム移動により別のマイクロサービスの開発へ移動したり、カウシェへ転職したりした際に、最初に導入したのはE2Eテストフレームワーク(記事の第4章「E2Eテストフレームワークの構築」)でした。 そして、API仕様の技術的負債(エンドポイントの仕様が書かれていなくて、それをテストするE2Eテストもない状態)を返済するために、次の開発順序(記事の第5章の図1)を自分自身も行い、他の開発者達にも行ってもらう
一か月前に「株式会社カウシェを退職します」を書きました。その時点で12月からの勤務先は決まっていませんでしたが、12月1日より株式会社令和トラベルで、嘱託社員契約でバックエンドエンジニアとして働きます。 勤務形態週4日(月曜日〜木曜日)勤務です。週4日勤務は、2017年9月から続けている勤務形態です。 オフィスは渋谷(カウシェの新たなオフィスの近く)ですが、基本的に自宅からフルリモートで働きます。実は、1年2か月在籍したカウシェには、入社前にオフィスへ行ったことはあるのですが、在籍期間中は一度も出社しませんでした。 9社目11月で64歳になり、令和トラベルで社会人になって9社目となります。 富士ゼロックス(1984年4月入社) 日本オラクル ジャストシステム 富士ゼロックス情報システム リコー ソラミツ メルペイ カウシェ 私の世代は定年まで1つの会社で働き続けるのが普通でした。実際、富士
私が「WEB+DB PRESS, Vol.134」の特集1「実践API設計」の中で使っている用語「E2Eテスト」は、一般的な書籍で述べられているE2Eテストとは若干異なります。 どのように違うのかをウェブサービスのバックエンドのサービスで説明します。新たに図を起こすのが面倒なので、すでにある記事「マイクロサービスの開発とテストファースト/テスト駆動開発」からそのまま引用します。 この図では、「加盟店管理用APIマイクロサービス」が複数のマイクロサービスに依存しています。 一般的なE2Eテストとは一般的な書籍では、テストピラミッドにおける頂点にあるE2E(End-To-End)テストは、「加盟店管理用APIマイクロサービス」およびそれが依存するすべてのマイクロサービスを何らかの環境(たとえば、Docker、あるいは開発用のクラウド環境)にデプロイして「加盟店管理用APIマイクロサービス」をテ
4月に発売された「WEB+DB PRESS Vol.134」で特集1「実践API設計」を執筆していますが、そこから部分的に紹介します(目次は、こちらです)。 第1章「優れたAPI仕様とは何か --- よくある問題と記述すべき事柄」の冒頭で次のように述べています。 今日、多くの企業がWeb サービスとしてさまざまなサービスを提供しています。Webサービスは、iOS、Android、ブラウザといったフロントエンドと、それらに対して機能を提供するバックエンドサービスから構成されます。バックエンドサービスが提供するさまざまな機能はAPI (Application Programming Interface)として定義され、フロントエンドから呼び出されます。フロントエンドは、バックエンドサービスが提供する機能を使ってユーザーへ提供する機能を実現します。 定義されたAPI を介することで、フロントエン
2021年は研修を行わなかったのですが、今年は、『Effective Java 第3版』研修をリクルート社向けにオンラインで開催します。過去の研修の反省から、今回は受講生の条件を絞っています。条件と言っても、以下のように当たり前のことです。 Javaでの開発経験があること 『Effective Java 第3版』は、初心者向けの本ではありませんので、この条件を付けなくてもよいように思われると思います。しかし、過去には、経験がない人が申し込まれていたというのがあり、今回は明確にしました。 追加条件研修では『Effective Java 第3版』を6回に分けて、毎回指定された範囲を読んで予習してもらいます。そして、不明点をGoogle Driveで共有されている質問表に事前に記入してもらいます。今回の研修では、さらに以下の条件を付けることにしました。 毎回、質問は最低3つは記入する 全く質問が
Amazon.co.jpではまだ先行予約できませんが、私にとって通算20冊目となる翻訳本が8月上旬に発売されます。 『Go言語による分散サービス ― 信頼性、拡張性、保守性の高いシステムの構築』 ISBN:978-4-87311-997-7 280ページ(予定) 出版月:2022年8月 価格:3,200円(税込:3,520円) 原著はこちらです。 目次は、次の通りです 本書への推薦の言葉 はじめに 第I部 さあ始めましょう 1章 レッツGo 2章 プロトコルバッファによる構造化データ 3章 ログパッケージの作成 第II部 ネットワーク 4章 gRPCによるリクエスト処理 5章 安全なサービスの構築 6章 システムの観測 第III部 分散化 7章 サーバ間のサービスディスカバリ 8章 合意形成によるサービス連携 9章 サーバディスカバリとクライアント側ロードバランス 第IV部 デプロイ 10
2020年2月18日から在宅勤務(WFH:Work From Home)を始めて、ちょうど一年が経過しました。この一年間、一度も会社には出社していませんし、最も大きな出来事は、2020年6月20日(土)に急性心筋梗塞で緊急搬送され、カテーテル治療で一命を取り留めたことです。 急性心筋梗塞になる以前と以降では、同じ在宅勤務であっても大きく変わりました。心筋梗塞になる前は、朝食後に仕事を始めて、昼食、そして夕方には仕事を終えるという生活でした。 6月27日(土)に退院してからは、週に2回か3回の心臓リハビリテーションで午後1時から4時まで外出するようになりました。心臓リハビリテーションがない日は、朝食後1時間ほど経過してから自宅でエアロバイクを30分行い、その後、シャワーを浴びるという生活を送っています。11月からは心臓リハビリテーションも週に1回となったので、自宅でのエアロバイクが主となって
私にとって、18冊目となる技術書の翻訳本です。再出版も入れると通算で21冊目となります。初めての翻訳本が2000年12月に出版された『Javaリアルタイム仕様』ですので、Java関連の書籍としては10冊目となります。 この本の原著はJava 12までカバーしていたのですが、プレビュー言語機能やAmberプロジェクトに対して解説されていた内容はこれから出るJava 14までに変更されているものがあります。 言語仕様の変更部分については、この本の原著が執筆された時点と、日本語への翻訳時点では異なっている部分が多くなっており、日本語版では、必要な修正、削除、追加を訳者の判断で行っています。また、日本語版では必要に応じてJava 13および14へ言及したり、訳注を付けたりしています。 言語仕様に関しては、以下の説明が行われています。 var(第1章「ローカル変数での型推論」と第5章「ラムダパラメー
(私自身のテスト駆動開発については、こちらにまとめてあります) 一年以上、メルペイでウェブサービスのbackendのマイクロサービスを開発していますが、組み込み系のソフトウェア開発と異なり、短期間に新たな機能を開発してリリースすることが求められます。2週間のスプリント単位でリリースしていますが、一つのスプリントで数個の機能を開発することも普通になっています。現在は、ウェブブラウザのフロントにAPIを提供しているあるマイクロサービスを担当しているため、機能の追加は、既存のAPIの仕様変更だったり、新たなAPIの追加だったりします。 開発順序現在担当しているマイクロサービスは、その開発の当初から私自身が関わっていたものでないため、既存のコードを調査して理解する必要がある場合が多く、開発はおおまかに次の順序となります。 既存のAPIの仕様の記述の変更、もしくは、新たなAPIの仕様の記述 既存のA
振り返ってみると私自身がまだ40歳であった2000年の初めからほぼ20年間複業をしてきました。1984年に社会人になって、1999年までは会社での開発業務という単一の仕事をしていたのですが、2000年からは主に次の三つです。 会社での開発業務(マネジメントや社内コンサルティングも含む) 技術教育や講演 技術書の執筆(雑誌の記事を含む)や技術書の翻訳 1. 会社での開発業務1984年4月に富士ゼロックスに就職してから、6回の転職を経て現在はメルペイで働いています。社会人となってからは、自分で実際にソフトウェア開発をしている時期もあれば、開発のマネージャをやっていることもありますが、現在は、毎日Go言語でbackendのサービス開発をしています。 社会人となってから、実際に自分でコードをほとんど書いていないかったのは、日本オラクル、ジャストシステム、富士ゼロックス情報システム(FXIS)での最
(「API仕様を書く(4)」からの続き) RPCの実装も通常のライブラリを作成するように「防御的プログラミング」を必要とします。すなわち、以下の状態に正しく対処する必要があります パラメータ値不正 呼び出し順序不正 設計ロジックの誤り 最初の二つは呼び出した側の誤りのですので、そのような不正呼び出しに対して、どのようなエラーを返すかを記述する必要があります。三つ目は設計ロジックの誤りです(これらの三つの詳細な説明については、『API設計の基礎』の「第3章 防御的プログラミング」を参照してください)。 gRPCのprotoファイルの例として、https://grpc.io/docs/guides/ には次のようなサンプルが掲載されています。 // The greeter service definition. ① service Greeter { // Sends a greeting ②
「API仕様を書く」として私自身の過去の経験を書いたものを読みやすく並べてみました。 API仕様を書く(1) API仕様を書く(2) API仕様を書く(3) API仕様を書く(4) API仕様を書く(5)ー gRPC protoファイル ー API仕様を書く(6)ー gRPC protoファイル(2) ー API仕様を書く(7) ちょうど同じような内容が『A Philosophy of Software Design』に書かれていました。 関連する章は、第12章「Why Write Comments? The Four Execuses」と第15章「Write The Comments First」です。第12章では、コメントを書かない理由として多くのソフトウェアエンジニアが挙げる理由について反証しています。第15章ではコメントを最初に書くことの有用性を説いています。ここでのコメントは、私
出版までに間違いをできるだけ少なくするように出版社も含めて努力をしていますが、どうしても誤字脱字だけでなく、技術的間違いを見落とすことがあります。 「ソフトウェアエンジニアの心得」と題した講演や教育では、「技術書には間違いがあると思って読んでください」と話しています。そして、技術的間違いだと思ったら、出版社や著者に問い合わせてくださいとも話しています。技術的間違いに関しては、大きく分けて次の二つに分類されます。 確かに技術的に間違っている 読者の知識不足あるいは勘違いにより間違いではない どちらであっても、問い合わせて損することはありません。技術的に間違っていたら、著者や出版社から感謝されますし、著者によっては正誤表に名前を掲載して、感謝してくれます。正誤表に名前を掲載してくれる例としては、『The Go Programming Language』の正誤表(こちら)があります。まれですが、
きちんとしたAPI仕様の作成能力「API仕様を書く」でも述べていますが、振り返ってみると、ソフトウェアエンジニアとしては、プログラミングできることに加えて、書いているソフトウェアのAPI仕様をきちんと書く能力を身に付けることも重要です。 きちんとAPI仕様を書く際には、次の視点が求められます。 そのソフトウェアを使う人達が提供される機能を理解し、間違いなく正しく使えるかという視点 将来保守する人達の理解を助けるという視点 1. は機能の説明だけでなく、防御的プログラミングの視点を盛り込んだ仕様が書かれている必要があります。2. は説明するまでもなく、将来保守する人達が仕様を理解できる必要があります。 仕様が書かれていない場合、作られたソフトウェアは技術的負債となります。そのようなソフトウェアの仕様を理解するには、実装のコードを読んで理解する必要があります。ライブラリやマイクロサービスのAP
継続的な学習習慣ソフトウェア技術は、発展し続けているため、非常に興味が尽きない領域です。そのために継続して学習を続ける必要があります。継続的な学習習慣の重要性については、何度も述べている(継続的学習)ので、ここでは別の視点で話をします。 本の買いすぎに注意新たなソフトウェア技術に興味を持って学習する、あるいは今使っている技術を深く知るために学習するときに、私自身は書籍を購入することがほとんどでした。技術書の電子版を購入できるようになったのはいつ頃だったか思い出せませんが、2009年ぐらいまでは紙の本を購入していました。 紙の本、電子版のどちらであっても、新たな技術を学び続ける上での問題点は、本を買いすぎることです。読むつもりで技術書を購入するのですが、結局ほとんど読まなかった技術書の数の方が、読んだ技術書の数よりも圧倒的に多かったと言えます。つまり、読まない本に多くのお金をつぎ込んだことに
新たなプログラミング言語への取り組みソフトウェア業界は停滞することなく、常に発展してきました。さまざな問題を解決するために、さまざまなプログラミング言語が登場してきましたし、これからも登場してくると思います。登場するすべてのプログラミング言語に取り組み、スラスラとその言語でコードを書けるようになるのは難しいと思います。したがって、私を含めて、多くのソフトウェアエンジニアは、書いたことがあるとしても、スラスラと書ける言語とそうではない言語に分かれると思います。 スラスラと書ける言語は、日々のソフトウェア開発で使ってきた結果として、指が自然と動くということです。そして、日々のソフトウェア開発で使うプログラミング言語は、バイブル本(「プログラミング言語のバイブル本と言語仕様」)を通してきちんと学ぶべきです(あるいは自己学習すべきです)。その理由としては、以下のことが挙げられます。 毎日使っている
特集1「実践API設計」の構成が分かるように目次を作成してみました。 第1章 優れたAPI仕様とは何か 特集のはじめに APIとは フレームワークや標準ライブラリのAPI仕様 企業内でのAPI仕様 優れたAPI仕様とは 理解が容易 変更が容易 テストが容易 API仕様でよくある問題点 API仕様が書かれていない エラーの記述がない 自動テストが存在しない API仕様に書くべきこと サービスの概要の説明 個々のエンドポイントの説明 エラーの説明 パラメータの不正値 誤った順序での呼び出し 認証と認可のエラー そのほかのエラー まとめ 第2章 gRPCにおけるAPI仕様の書き方 gRPCとは API仕様をどこに書くか サービスの概要の記述 個々のエンドポイント(RPC)の説明 エラーの説明 パラメータの不正 InvalidArgument ── 不正なパラメータ値 NotFound ── リソ
ソフトウェアを書いて、手作業でテストする手法とは異なり、テスト駆動開発ではいくつかの規律が求められます。その中で、「テスト駆動開発の経験(6)」で述べたことの一つが「不具合が発生した場合、必ず再現テストを書く」です。 不具合への対処は次のようなステップとなります。 不具合が発生した際に、その原因を調査します(「デバッグの科学的手法」) その不具合を再現させるテストを作成します(不具合が存在するために失敗するテストです)。 テストが失敗するのを確認します。 不具合の原因を取り除いて修正します。 テストが成功するのを確認します。 マルチスレッドプログラミングでは、原因の調査および再現テストを書くことが非常に困難な場合があります(「マルチスレッドプログラミングにおける重要な4要件」)。その場合の再現テストは、普通の再現テストとは異なる工夫が必要になります(詳細については別の機会に書きたいと思いま
4年ほど前に「テスト駆動開発の経験」と題して記事を書いています。 テスト駆動開発の経験(1) テスト駆動開発の経験(2) テスト駆動開発の経験(3) テスト駆動開発の経験(4) テスト駆動開発の経験(5) 1978年に大学でプログラミングを始めてから、(「テスト駆動開発の経験(1)」に書いてあるように)2003年まで、私自身はテスト駆動開発を経験したことがありませんでした。 1990年代までのソフトウェア業界では、自動実行するテストを書いて資産として残していく習慣はありませんでした。手作業によるテストと目視確認というのが普通に行われていたのがソフトウェアのテストでした。テストコードが書かれたとしても、テストコードを手作業で実行し、目視確認が終わったら捨てるということが行われていました。実際、同じようなことを、Martin Fowler、Robert Martin、Joshua Blochが
次のページ
このページを最初にブックマークしてみませんか?
『柴田 芳樹 (Yoshiki Shibata)』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く