実践API設計: 柴田 芳樹 (Yoshiki Shibata)
4月に発売された「WEB+DB PRESS Vol.134」で特集1「実践API設計」を執筆していますが、そこから部分的に紹介します（目次は、こちらです）。 第1章「優れたAPI仕様とは何か --- よくある問題と記述すべき事柄」の冒頭で次のように述べています。 今日、多くの企業がWeb サービスとしてさまざまなサービスを提供しています。Webサービスは、iOS、Android、ブラウザといったフロントエンドと、それらに対して機能を提供するバックエンドサービスから構成されます。バックエンドサービスが提供するさまざまな機能はAPI （Application Programming Interface）として定義され、フロントエンドから呼び出されます。フロントエンドは、バックエンドサービスが提供する機能を使ってユーザーへ提供する機能を実現します。 定義されたAPI を介することで、フロントエン
株式会社メルペイを退職します: 柴田 芳樹 (Yoshiki Shibata)
2018年6月1日から働き始めた株式会社メルペイを9月30日付けで退職します。4年4か月勤務したことになります。1984年4月1日に社会人として富士ゼロックスで働き始めてから、7社目の会社でした。10月1日からは、新たな会社でソフトウェアエンジニアとして働き始めます。 週4日勤務「ソラミツ株式会社を退職します」でも書きましたが、リコーを退職してからは、基本的に週4日勤務をしてきました。メルペイでも、金曜日は欠勤するか有給休暇を使うなどして、週4日勤務をしてきました（週4日勤務で働くことに関して、入社前に合意してもらっていました）。10月からの会社では、週4日勤務の雇用契約で働きます。 初めてのウェブサービス開発富士ゼロックス、富士ゼロックス情報システム、リコーの3社で合計31年7か月を過ごし、富士ゼロックスでのワークショテーション開発を除くと、その多くは、デジタル複合機のソフトウェア開発に
手動テストだけのソフトウェアは腐っていく: 柴田 芳樹 (Yoshiki Shibata)
この本で、著者のRobert Martinも、次のように述べています。 この10年間の間に この業界では多くのことがありました。1997年当時、テスト駆動開発などという言葉は誰も聞いたことがありませんでした。ほとんどの人にとって、単体テストというのは動作をひとたび『確認』したら捨ててしまうものでした。苦労してクラス メソッドを書き上げ、それらをテストするためのその場しのぎのコードをでっちあげていたのです。 『Effective Java』で有名なJoshua Blochは、この本の中のインタビューで、次のような会話を行っています。 「デバッグの話をしましょう。あなたが追いかけた最悪のバグはどのようなものでしたか」 それに対して、Joshua Blochは、 「最初に勤めた会社で私が開発したソフトウェアですね。ソフトウェアのデバッグに1週間半費やしました」 という話をしています。 1週間半費
伸ばすのが難しい能力: 柴田 芳樹 (Yoshiki Shibata)
2018年6月1日に株式会社メルペイに入社して、4年が過ぎました。入社当時は、定年が60歳と聞いていたので、1年半の勤務だと思っていましたが、実際の定年は65歳であり定年まであと2年半です。 ソフトウェアエンジニアにとって重要な能力と（私は考えるが）、身に付けるのが難しいのが現実だと、この4年間で再認識したのは次の三つです。 開発の最初にAPI仕様をきちんと書けるソフトウェアエンジニアは少ない テストファースト開発を行っているソフトウェアエンジニアは少ないか、いない Tech Blogなどの執筆で、読み手を意識して、分かりやすい文章を書く、ソフトウェアエンジニアは少ない API仕様については、このブログでも何度か書いています（「API仕様を書く」）。テストファースト開発についても、「テストファースト開発」を書いています。分かりやすい文章については何も書いていないですが、「伝わる技術文書の書
ソフトウェアエンジニアの成長カーブ: 柴田 芳樹 (Yoshiki Shibata)
最近良く話していることなのですが、社会人として働き始めた新卒の技術者は、最初の数年は成長していきます。与えられた業務を遂行しながら、そのための学習もしていくからです。しかし、2、3年すると開発業務をこなせるようになり、特に新たな勉強をしなくても、日々、会社に行って開発業務が遂行できるようになります。 この状態、つまり、継続した学習をしなくなった状態で、10年とか経過すると、ソフトウェアの世界は大きく変化している可能性があり、新たな技術が登場し、その人の技量は相対的に今度は低下しはじめます。しかし、この時点で、新たなことを学習するのは困難だったりします。学習する習慣が無いわけですから、勉強しろと言っても、「なぜ、休みの日に勉強しなければならないのですか」ということになります。 そのような人に対して、マネジメントは、その人ができる仕事を与えて、何とか仕事をしてもらいますので、「新たなことを勉強
専門書には間違いもある: 柴田 芳樹 (Yoshiki Shibata)
一冊の専門書を仕上げるというのは大変な作業であり、出版時に誤りが残っているのは普通です。たとえば、『The Go Programming Language』のErrata（正誤表）を見てみるとすでに20項目弱の訂正が掲載されています。 技術書の誤りに関しては、拙著『プログラマー”まだまだ”現役続行』に「専門書には間違いもある」として書いているものを引用しておきます。 専門書を読む際に注意しなければならないのは、たとえ専門家が書いていたとしても、誤植などの誤りがあるということです。そう思って読む必要があります。一冊の本を仕上げるという作業は、膨大な時間を要する作業であり、どうしても完全に仕上げることは不可能である場合が多いからです。つまり、説明が間違っている場合もあるということです。 さらに、たとえばサンプルコードなども、必ずしも適切でない場合もあると思って読むことです。よく、そのような間違
ソフトウェア開発が好きでないサラリーマンエンジニア：柴田 芳樹 (Yoshiki Shibata)：So-netブログ
ソフトウェア開発は、自分で考えて手を動かしてプログラミングして動くものを作ることを繰り返す訳ですが、そもそもソフトウェア開発という「物作り」を好きではないサラリーマンエンジニアが日本には多いのではないかと思います。 その理由は単純で、新卒新人でも中途入社であっても、自分で分析・設計から実装・デバッグまでするのが好きな人を採用していないからだと思います。たとえば、メーカーでソフトウェア開発部門に配属されるような新卒新人でも、大学ではほとんどプログラミングしたことがない人をメーカーは採用します。中途採用であっても、採用面接でプログラミングを伴う技術的な質問をほとんどしません。 その結果、企業の中には、本当にソフトウェア開発が好きなソフトウェアエンジニアと仕事だからというサラリーマンエンジニアがいることになります。そして、サラリーマンエンジニアは、そもそも好きではないので、業務がこなせるようにな
『Effective Java 第3版』の翻訳作業が終わりました: 柴田 芳樹 (Yoshiki Shibata)
昨年の2月から原著『Effective Java Third Edition』の草稿のレビューが始まり、レビューが終わったのが11月で、昨年末には原著が発売されています。翻訳作業は、昨年の12月から始めて、すべての作業が今月初めに終了しました。今回も、翻訳および（索引作りも含めた）組版までLaTeXで行いました。 原著のレビューのときには気付かなかった多くの間違いは、翻訳作業を通してJoshua Bloch氏へ知らせており、原著の4th printing（第4刷）では修正されています（原著の正誤表は、こちらです）。 今回はもっと早く終わるかと思ったのですが、結局、約430時間を翻訳作業に費やしました。翻訳に先立っての原著のレビューは約42時間でした。 Amazon.co.jpでは、以下のように紹介されています。 Javaプログラマーにとって必読の定番書『Effective Java』の改訂
言語仕様とメモリモデル: 柴田 芳樹 (Yoshiki Shibata)
『Effective Java 第3版』の第11章「並行性」（あるいは、第2版の第10章「並行性」）を内容を理解するためには、Javaのメモリモデル（memory model）を理解する必要があります。『Effective Java 第3版』の翻訳原稿による補講でも「メモリモデルとは何か」という質問がありました。 マルチコアやマルチプロセッサを前提としてマルチスレッドプログラミングを言語仕様として提供する言語では、メモリモデルは言語仕様の一部とも言えます。Javaであれば、『The Java Language Specification』の17.4節の「Memory Model」、あるいは、『プログラミング言語Java第4版』の14.10節 「メモリモデル:同期とvolatile」に書かれています。それぞれ、22ページと5ページを費やして解説しています。 今日、マルチコアやマルチプロセッサ
マルチスレッドプログラミングにおける重要な４要件: 柴田 芳樹 (Yoshiki Shibata)
JaSST Tokyo 2018の招待講演で話した資料（こちら）に書いてあることですが、今までの人生で私自身は、デジタル複合機コントローラソフトウェア開発を4回もアーキテクチャを変えて行いました。デジタル複合機の難しさは、ハードウェアからの非同期なさまざまなイベントとユーザからの様々なイベントを両方を上手く処理しなければならず、かなり複雑なソフトウェアとなります。 ソフトウェアエンジニアとして合計すると10年以上をデジタル複合機コントローラソフトウェアの開発に従事し、マルチスレッドプログラミングを行ったことになります。公開資料に詳細情報は含まれていませんが、資料にある「Take 3」と「Take 4」は、デジタル複合機コントローラソフトウェアを完全にテスト駆動開発で行うというものでした。 4回ともマルチスレッドプログラミング（厳密には、Take 4はマルチゴルーチン（goroutine）プ
株式会社メルペイで働きます: 柴田 芳樹 (Yoshiki Shibata)
一か月前に「ソラミツ株式会社を退職します」を書きました。その時点では6月からの勤務先は未定でしたが、6月1日から株式会社メルペイで「ソフトウェアエンジニア（Backend）」として働くことになりました。 通勤勤務場所は六本木ヒルズです。今までよりも乗り換えが1回増えるために、通勤時間はおそらく片道で15分ぐらい長くなるのではないかと思います（往復で3時間を超える？）。朝は今まで通り、自宅の最寄り駅の始発（初電）に乗車して、各駅停車で行く予定です（「通勤電車の書斎化」）。フレックス勤務でコアタイムは12:00〜16:00なので、今までのように出社前にスターバックスに寄って翻訳などの作業をせずに、そのまま出社して早めに帰宅するつもりです。 7社目1984年4月に富士ゼロックスに就職した頃には全く想像もしていませんでしたが、これで7社目となります。 富士ゼロックス 日本オラクル ジャストシステム
『プログラミング言語Go』翻訳作業が終了しました: 柴田 芳樹 (Yoshiki Shibata)
プログラミング言語Go 作者: Alan A.A. Donovan出版社/メーカー: 丸善出版発売日: 2016/06/15メディア: 単行本（ソフトカバー） 2015年4月20日から原著の原稿のレビューを始めて、レビューが終わったのが2015年9月5日でした。その間に、二回読み返しています。翻訳は2015年9月13日に着手し始めて、私のすべての作業が昨日（2016年5月8日）終了しました。今日、入稿となり印刷所での印刷の準備が始まりますので、予定通り6月15日刊行となります。 今回は、原著のレビューに98時間、翻訳に473時間を費やしたことになります。ちなみに『APIデザインの極意』は、翻訳だけでしたが500時間を費やしています。これは、私が私的時間に費やした時間であり、出版社の担当者やレビューアによるレビューを加えると多くの時間が費やされたことになります。また、社内のGo言語研修では翻
『Effective Java 第2版』の電子版（PDF）が発売になりました: 柴田 芳樹 (Yoshiki Shibata)
人気記事 伸ばすのが難しい能力（40,855） ソフトウェアエンジニアの成長カーブ（再掲載）（36,531） 初心者レベルの言い訳をしない（35,049） 継続インテグレーションは強みではなくなった（30,683） ソフトウェア開発が好きでないサラリーマンエンジニア（25,673） 成長の場を求めないソフトウェアエンジニア？（24,179） コンパイル時のワーニング（-Wallと-Werror）（２）（18,481） 株式会社メルペイを退職します（18,808） 株式会社リコーを退職します（16,826） 株式会社メルペイで働きます（16,553） 『Effective Java 第2版』は、やはり初心者向けではない（16,158） 正誤表 各書籍の正誤表はこちら 『Effective Java 第3版』（2024年5月11日更新） 『Go言語100Tips』（2024年4月21日更新）
成長の場を求めないソフトウェアエンジニア？：柴田 芳樹 (Yoshiki Shibata)：So-netブログ
「ソフトウェア開発組織が持つべきカルチャー」と題して、過去に以下の記事を書いています。 継続した学習習慣 コンピュータの基礎を教える 共に学ぶ マネージャが勉強会を主催する プロセス中心ではなく、スキル中心 スキル向上に真剣に長期的に取り組む カンファレンスへ積極的に参加させる コードをレビューする Source Code Controlへ最低でも毎日コミットする ビッグバン・インテグレーションを避ける テストを自動化する ソースコードを調べる 自分で書いたコードを自分で見直す 知識教育だけではなく、良い行動パターンを促進する また、「コードレビューの視点」として、以下の記事を書いていいます。 Copyrightを書く 必要なエラー情報を付加する マルチスレッドプログラミングに注意する 言語仕様を確認する 独り言コメントは書かない 説明とコードが違っていないか注意する 知識の伝達の場 エン
ソフトウェア開発と人事戦略（２）: 柴田 芳樹 (Yoshiki Shibata)
Java研修を長年続けてきて、近年、非常に進捗が悪くなっています。その理由を考えてみると、基礎的な事柄を知らないままソフトウェア開発に従事している人が増えているためだと思うようになってきました。 ここでの基礎的なこととは、一般的な「データ構造とアルゴリズム」、オペレーティングシステムに関する基礎知識、ハードウェアに関する知識です。それに加えて、デザインパターンに関する知識も欠如しているため、その都度、Javaとは関係ないことを説明しなければならいことが非常に多くなっています。 データ構造とアルゴリズムに関しては、基礎的なことを理解していない人が多く、ハッシュテーブルを説明したりO表記を説明できたりする人は皆無だったりします。オペレーティングシステムに関しても、仮想メモリをサポートするためのページングの仕組みを知らなかったり、Unixでのシステムコールを用いたプログラミング経験が全くなかった
初心者レベルの言い訳をしない: 柴田 芳樹 (Yoshiki Shibata)
出来上がったコードの可読性も含めた品質の悪さを、時間がなかったとかプロトタイプだからと言い訳する人がいます。スキルが高い人の場合は、同じ時間制約でも高い品質のコードを書きます。それは、ある程度無意識になるまで、訓練を重ねているからです。無意識になるまで意識して普段から活動するのです。 ソフトウェア開発ではないですが、熟練者と初心者の差を比較するために短時間でどれだけの成果が出るかを競うテレビ番組を時々見かけることがあります。必ず熟練者の方が量も質も圧倒的に初心者を凌駕しています。つまり、時間がなかったとかプロトタイプを言い訳にした時点で、経験年数に関係なく、初心者レベルだということです。 1988年に米国への赴任前の送別会で今は亡きS.Uさんに言われたのは、「与えられた仕事をこなして初めて次の難し仕事が与えられる」と言われたことがあります。逆に言えば、できないと判断されたら、仕事を与えない
継続インテグレーションは強みではなくなった: 柴田 芳樹 (Yoshiki Shibata)
Subversion/Gitなどを使用したソースコード管理、Jenkinsを使用した継続的インテグレーション、様々なxUnitフレームワークを使用した自動テストなどをソフトウェア開発組織として実践することは、今日では、その開発組織の技術的な強みではありません。 それらを実践しないことが、ソフトウェア開発組織の「弱み」なのです。また、組織としてそれらの実践を推進しない、あるいはサポートできないマネージャも「弱み」となります。さらに、大規模なソフトウェア開発組織においては、それらのためのインフラ整備をプロジェクトごとに立ち上げなければならず、サポート部門が存在しないことも弱みとなります。※1 ※1 プロジェクトを始めるごとに、ソースコード管理やJenkins用のサーバの調達、OSから様々なツールのインストールを一通り行うためには、それなりの時間を要します。したがって、バックアップをも含めて環境
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
柴田 芳樹 (Yoshiki Shibata)：SSブログ