サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
円安とは
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つの会社で働き続けるのが普通でした。実際、富士
2022年10月1日から働き始めた株式会社カウシェを11月30日付けで退職します。1984年4月1日に社会人として富士ゼロックス(現在は、富士フイルムビジネスイノベーション)で働き始めてから8社目の会社でした。12月からの予定は、未定です。 雑誌記事・翻訳・講演・技術教育この一年間の成果は次の通りです。 WEB+DB PRESS Vol.134 出版社/メーカー: 技術評論社発売日: 2023/04/22メディア: Kindle版 メルペイとカウシェの2社で私自身が推進してきた開発手法を特集1「実践API設計」で解説しています。一年前にカウシェに入社した時点では、gRPCに基づくバックエンドサービスのAPI仕様は全く記述されていませんでした。現在は、この一年間で新規に追加されたエンドポイントでAPI仕様が記述されているだけでなく、過去の技術的負債もかなり返済され、E2Eテストも整備されてい
私が「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つは記入する 全く質問が
2018年6月1日から働き始めた株式会社メルペイを9月30日付けで退職します。4年4か月勤務したことになります。1984年4月1日に社会人として富士ゼロックスで働き始めてから、7社目の会社でした。10月1日からは、新たな会社でソフトウェアエンジニアとして働き始めます。 週4日勤務「ソラミツ株式会社を退職します」でも書きましたが、リコーを退職してからは、基本的に週4日勤務をしてきました。メルペイでも、金曜日は欠勤するか有給休暇を使うなどして、週4日勤務をしてきました(週4日勤務で働くことに関して、入社前に合意してもらっていました)。10月からの会社では、週4日勤務の雇用契約で働きます。 初めてのウェブサービス開発富士ゼロックス、富士ゼロックス情報システム、リコーの3社で合計31年7か月を過ごし、富士ゼロックスでのワークショテーション開発を除くと、その多くは、デジタル複合機のソフトウェア開発に
2018年6月1日に株式会社メルペイに入社して、4年が過ぎました。入社当時は、定年が60歳と聞いていたので、1年半の勤務だと思っていましたが、実際の定年は65歳であり定年まであと2年半です。 ソフトウェアエンジニアにとって重要な能力と(私は考えるが)、身に付けるのが難しいのが現実だと、この4年間で再認識したのは次の三つです。 開発の最初にAPI仕様をきちんと書けるソフトウェアエンジニアは少ない テストファースト開発を行っているソフトウェアエンジニアは少ないか、いない Tech Blogなどの執筆で、読み手を意識して、分かりやすい文章を書く、ソフトウェアエンジニアは少ない API仕様については、このブログでも何度か書いています(「API仕様を書く」)。テストファースト開発についても、「テストファースト開発」を書いています。分かりやすい文章については何も書いていないですが、「伝わる技術文書の書
エンジニアが集まって、LTを行ったり、20分から30分程度の発表を平日の夜に行うというのは、いつ頃から広まっているのか定かではありませんが、この10年間で確実に広まってきています。さらに、コロナ禍により、オンライン開催も加わり、広く行われるようになりました。 一方、Advent Calendarといったtech blog(技術文書)を公開することも多く行われています。企業内の開発で得た知見を、オンラインで説明しながら話したり、tech blogとして公開することは、今日のIT業界では、当たり前のように行われています。これらは、すべて外部へ向けての発信です。 外部発信することで、その企業の技術力を発信することにもなり、エンジニアを惹き付けることにもなります。私自身もTech Talkで話をしたり、tech blogを書いてきました。このような情報発信は、今後も多くのIT企業やスタートアップで
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
この本で、著者のRobert Martinも、次のように述べています。 この10年間の間に この業界では多くのことがありました。1997年当時、テスト駆動開発などという言葉は誰も聞いたことがありませんでした。ほとんどの人にとって、単体テストというのは動作をひとたび『確認』したら捨ててしまうものでした。苦労してクラス メソッドを書き上げ、それらをテストするためのその場しのぎのコードをでっちあげていたのです。 『Effective Java』で有名なJoshua Blochは、この本の中のインタビューで、次のような会話を行っています。 「デバッグの話をしましょう。あなたが追いかけた最悪のバグはどのようなものでしたか」 それに対して、Joshua Blochは、 「最初に勤めた会社で私が開発したソフトウェアですね。ソフトウェアのデバッグに1週間半費やしました」 という話をしています。 1週間半費
ソラミツを退職して、メルペイに入社したのが、2018年6月1日でした。ちょうど4年前です。 入社前の面談で、週4日勤務(金曜日は休み)を希望したのですが、雇用形態としてはそのような制度はないということで、正社員として採用されました。ただし、金曜日は欠勤としたり、有給休暇を使ったりして休んでよいということで、入社しました。メルペイのサービスを最初にリリースする前の2か月ほどは、金曜日に働いたことはありますが、それ以外は金曜日は欠勤か有給休暇で休んでいます(欠勤すると所定労働時間に達しないので、不足分は給与が減額されます)。 技術教育と技術書の翻訳金曜日は、主に複業としての技術教育(Java言語教育やGo言語教育)や技術書の翻訳などを行ってきました。もちろん、単に休むこともあります。副業としてのソフトウェア開発を行っているエンジニアも多いですが、ソフトウェア開発は締め切りがあったり、デバッグが
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章「ラムダパラメー
2018年6月にメルペイで働き始めて、今年は2年目でした。ちょうど一年7か月働いたことになります。今年一年間は、Backendのマイクロサービスの開発で、ずっとGo言語とVimでプログラミングしていました。昨年は、5月は全く仕事をせずに休みだったのと、メルペイに入社してしばらくはAPI仕様ばかり書いていたので、振り返ってみると最後に一年間プログラミングした年は2008年だと思います。 リコーに勤務していた8年間(2009年9月〜2017年8月)では、現場のソフトウェアをレビューすることはあっても、自分でプログラミングすることはほとんどありませんでした。 一年間プログラミングし続けたと言っても、月曜日から木曜日までなので、40代の頃と比べると時間的には少なかったです。また、40代に行っていた複雑なマルチスレッドプログラミングと比べるとそれほど複雑なプログラミングは行っていないです。 基本的に
(私自身のテスト駆動開発については、こちらにまとめてあります) 一年以上、メルペイでウェブサービスの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 ── リソ
1978年4月、大学一年生で初めてのプログラミングをFORTRANで学びました。それから、今月末で丸41年が過ぎたことになります。今と違って当時は、プログラミングは大学の計算機センターに行かなとできませんでした。当時の九州工業大学の計算機センターは、幸いパンチカードではなく、TSS(Time Sharing System)の端末を使ってプログラミングできました。でも、自分の学科(情報工学科)のさまざまなコースの演習は違っていました。 コンパイラの授業では、パンチカードを使ってPL/Iでプログラミングしました。パンチ室が3階で、計算機室が4階だったので、自分が書いたコンパイラのコードである7百枚ぐらいのパンチカード(つまり、700行のソースコード)を持って3階と4階を行ったり来たりして、デバッグして完成させました。 CPUの内部を学習する授業では、APLで動作が記述されている英語の教科書でし
ソフトウェアを書いて、手作業でテストする手法とは異なり、テスト駆動開発ではいくつかの規律が求められます。その中で、「テスト駆動開発の経験(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ページを開く