サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
デスク環境を整える
yshibata.blog.ss-blog.jp
技術評論社の雑誌に書いた複数の記事をもとに、加筆・修正し、再構成して書籍にまとめて出版したのが2007年9月です。私がまだ47歳のときです。当時は富士ゼロックス情報システムで、開発部の部長をしながら同時に毎日C++でマルチスレッドプログラミングを行っていました。 「現役続行に必要な七つの力」として次の項目を挙げて解説しています。 論理思考力 読みやすいコードを書く力 継続学習力 コンピュータサイエンスの基礎力 朝型力 コミュニケーション力 英語力 現在は59歳で、今年の11月には60歳になります。1978年4月に九州工業大学情報工学科へ入学して、初めてコンピュータに触れ、Fortranでプログラミングを学んでから40年の歳月が流れました。 今日、上記の7つの力に追加するとしたら、「健康力」かもしれません。つまり、健康であることです。この歳になってくると、体の色々なところに問題が発生します。
最近は、企業が副業を解禁するしないという話題が目立つようになりました。今働いているメルペイ社では副業は禁止されていません。私自身は、技術雑誌の記事の執筆、技術書籍の翻訳、技術書の執筆などを2000年から副業としてやってきました。現在は、技術書籍の翻訳と企業向けの技術教育が中心です。 最初に副業を始めたのは富士ゼロックス情報システム社に勤務している頃で、就業規定に明確に兼業禁止規定がありました。しかし、技術系の活動に関しては、毎回社内で申請処理をする必要がありましたが、認められていました。 2008年9月にリコーへ転職したのですが、就業規則を何度読み返しても「兼業禁止規定」は書かれていませんでした。それでも、技術書の翻訳で社内申請をしようとしたのですが、当時の室長に「入社前からやっている活動であり、そのことは承知して採用しているし、申請するとそれを審査するために無駄に社内の工数が取られるので
以前、「デバッグを支える知識」として次の記事を書いています。 デバッグを支える知識 デバッグを支える知識(2) また、デバッグの科学的手法を「デバッグの科学的手法」で述べていますが、再度『ビューティフルコード』の第28章から引用すると以下の通りです。 1. プログラムの失敗を観察する 2. 観察と矛盾しない失敗の原因についての仮説を立てる 3. 仮説を使って予想する 4. 予想を実験でテストして、さらに観察する a. 実験と観察が予想を満たすなら、仮説をさらに精緻なものにする b. 満たさないなら、別の仮説を立てる 5. 仮説がこれ以上精緻にできなくなるまで、手順3と4を繰り返す。この「仮説」を立てるために必要なのが「知識」です。バグに直面したときには、仮説を立てるために必要な知識が不足していても、今日ではある程度ネットで調べて補えます。しかし、本質的な知識の欠如は、デバッグを阻みます。
Go言語で提供されているsync.Mutexは、再入可能(re-entrant)ではありません。それについては、『プログラミング言語Go』(p,306)には次のように書かれています。 Go のミューテックスが再入可能ではないことには正当な理由があります。ミューテックスの目的は、共有された変数のある種の不変式がプログラム実行中の重要な時点で維持されているのを保証することです。不変式の一つは、「共有された変数へアクセスするゴルーチンが存在しない」*2ですが、ミューテックスが保護しているデータ構造に特有の追加の不変式が存在するかもしれません。一つのゴルーチンがミューテックスロックを獲得したときには、そのゴルーチンは不変式が維持されていると想定するでしょう。ロックを保持している間に共有された変数が更新され、一時的に不変式が破られるかもしれません。しかし、ロックを解放するときには、秩序が回復されて不
(「API仕様を書く(6)ー gRPC protoファイル(2) ー」からの続き) きちんとしたAPI仕様を書いていない場合、そのAPIのテストコードは当然のことながら、正常ケースだけだったり、不正なパラメータが渡されたときにどのように振る舞うかは実装のソースコードを見ないと分からなかったりします。さらに、「エラー翻訳」(「例外翻訳」)を行っていない実装は、いつのまにか返されるエラーが変わってしまっていることも起こり得ます。 おそらく多くの大学ではAPI仕様の書き方も含めてAPI設計の教育は行われていないと思います。そして、社会人となってから、個々のソフトウェアエンジニアがAPIの仕様をどの程度記述するかは、その人が属したソフトウェア開発組織の文化に影響を受けると思います。 私自身、gRPCを用いたソフトウェア開発では、前職のソラミツが初めてでした。そこでは、protoファイルには何も仕様
私にとって17冊目の翻訳本になる『Effective Java 第3版』が今月末には書店に並びます。第2版がちょうど10年前です。第2版は、ジェネリックスを含めた大きな言語仕様の変更がJava 5で行われた後でした。今回は、Java 8でラムダとストリームという言語仕様の変更とライブラリの拡張が行われた後となります。 新たに追加された項目は以下の通りです(項目番号は、第3版の番号です)。 項目9 try-finally よりもtry-with-resources を選ぶ 項目21 将来のためにインタフェースを設計する 項目25 ソースファイルを単一のトップレベルのクラスに限定する 項目32 ジェネリックスと可変長引数を注意して組み合わせる 項目43 ラムダよりもメソッド参照を選ぶ 項目44 標準の関数型インタフェースを使う 項目45 ストリームを注意して使う 項目46 ストリームで副作用の
昨年の2月から原著『Effective Java Third Edition』の草稿のレビューが始まり、レビューが終わったのが11月で、昨年末には原著が発売されています。翻訳作業は、昨年の12月から始めて、すべての作業が今月初めに終了しました。今回も、翻訳および(索引作りも含めた)組版までLaTeXで行いました。 原著のレビューのときには気付かなかった多くの間違いは、翻訳作業を通してJoshua Bloch氏へ知らせており、原著の4th printing(第4刷)では修正されています(原著の正誤表は、こちらです)。 今回はもっと早く終わるかと思ったのですが、結局、約430時間を翻訳作業に費やしました。翻訳に先立っての原著のレビューは約42時間でした。 Amazon.co.jpでは、以下のように紹介されています。 Javaプログラマーにとって必読の定番書『Effective Java』の改訂
株式会社メルペイに入社して、3か月が過ぎました。1984年に社会人となってからさまざまなソフトウェア開発に従事してきましたが、今日でいうところの「Backend Engineer」というのは前職のソラミツ社で少しかじった程度でした。現在は、あるマイクロサービスの開発を担当しており、この3か月間の半分以上は、そのマイクロサービスのAPI仕様を書くことに費やしていました。マイクロサービスの通信は、gRPCで行いますので、API仕様はその.protoファイルにコメントの形式で書いています。 実装をほとんどせずにAPI仕様を書くということをいつ頃からやった経験があるのかと振り返って見ると、1993年から開発に従事したFuji Xerox DocuStation IM 200です。レイヤ構成のアーキテクチャで、最下位層はハードウェアを抽象化したAPIを提供するMCA(Machine Control
『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ページを費やして解説しています。 今日、マルチコアやマルチプロセッサ
2000年からJava言語研修を始め、2016年からGo言語研修を始めています。株式会社リコーに勤務した8年間での研修では、コース名に意図的に「基本技術習得」と付けていました。 「プログラミング言語Java基本技術習得」コース 「プログラミング言語Go基本技術習得」コース この研修コース名から、「初心者向け」コースと勘違いして受ける人が最初の頃はいました。しかし、初心者コースではありません。 「基本技術習得」と命名した意図は、次の通りでした。 業務でその言語を使ってソフトウェアを開発しているのであれば、コースの内容を最低限の基礎知識として学習して、ソフトウェアを開発してもらいたいその最低限のレベルというのが、Java言語であれば、以下の4冊を読んで、練習問題のプログラミングも行い、さらにいくつかのGUI課題をこなすというものでした。
JaSST Tokyo 2018の招待講演で話した資料(こちら)に書いてあることですが、今までの人生で私自身は、デジタル複合機コントローラソフトウェア開発を4回もアーキテクチャを変えて行いました。デジタル複合機の難しさは、ハードウェアからの非同期なさまざまなイベントとユーザからの様々なイベントを両方を上手く処理しなければならず、かなり複雑なソフトウェアとなります。 ソフトウェアエンジニアとして合計すると10年以上をデジタル複合機コントローラソフトウェアの開発に従事し、マルチスレッドプログラミングを行ったことになります。公開資料に詳細情報は含まれていませんが、資料にある「Take 3」と「Take 4」は、デジタル複合機コントローラソフトウェアを完全にテスト駆動開発で行うというものでした。 4回ともマルチスレッドプログラミング(厳密には、Take 4はマルチゴルーチン(goroutine)プ
一か月前に「ソラミツ株式会社を退職します」を書きました。その時点では6月からの勤務先は未定でしたが、6月1日から株式会社メルペイで「ソフトウェアエンジニア(Backend)」として働くことになりました。 通勤勤務場所は六本木ヒルズです。今までよりも乗り換えが1回増えるために、通勤時間はおそらく片道で15分ぐらい長くなるのではないかと思います(往復で3時間を超える?)。朝は今まで通り、自宅の最寄り駅の始発(初電)に乗車して、各駅停車で行く予定です(「通勤電車の書斎化」)。フレックス勤務でコアタイムは12:00〜16:00なので、今までのように出社前にスターバックスに寄って翻訳などの作業をせずに、そのまま出社して早めに帰宅するつもりです。 7社目1984年4月に富士ゼロックスに就職した頃には全く想像もしていませんでしたが、これで7社目となります。 富士ゼロックス 日本オラクル ジャストシステム
電子版は、すでに購入可能となっています。PDF版であれば https://www.informit.com/ から購入可能となっています。紙の本は、年明けのようです。 第2版に続いて、この第3版もレビューさせてもらいました。第2章から第12章までの原稿をレビューしました。レビュー用の第2章が送られてきたのが2月7日で、最終章である第12章が送られてきたのが11月25日でした。 日本語版は、私にとって17冊目の翻訳本になりますが、しばらくお待ちください。 英語版の正誤表は、こちらです。
ベタープログラマ ―優れたプログラマになるための38の考え方とテクニック 作者: Pete Goodliffe出版社/メーカー: オライリージャパン発売日: 2017/12/15メディア: 単行本(ソフトカバー) 間もなく発売されますが、先日紹介した目次に加えて、アマゾンでは以下のように紹介されています。 プログラマとしてのキャリアをスタートすると、構文や設計を理解するだけでなく、その他の様々な事柄を理解し習得する必要があると気づきます。 本書は、優れたコードを作りだし、人々と効率的に働く生産性の高いプログラマになるための考え方とテクニックを38のテーマで紹介します。 はじめに、コード1行1行の書き方、デバッグやエラー処理、コードの改善方法など開発現場でのコーディングを取り上げます。 次にコードを単純に保つこと、コード変更やテスト、リリースなどソフトウェアを開発する際の考え方や心構えを扱い
先週の金曜日のGo言語研修が終わって、懇親会(会社の食堂)まで時間があったので、『Java Puzzlers』をやってみました。 もう12年前の本で、現在は絶版となっています。発売された時に、日本でJavaOneが開催されていて、印刷されたばかりのこの本が販売された頃が懐かしいです。 ところで、Javaではパズルになるものが、Go言語ではそもそもコンパイルエラーになるものが多いです。その理由の一つは、異なる整数型の混合計算をGo言語が許さないことです。初めてGo言語に触れると、その点がちょっと煩わしく感じます。でも、パズルをGo言語で書くとどうなるかを知ると、言語の違いが分かってきて面白いです。 パズル2: 変革の時(Time for a Change) 次の文章問題を考えてみてください。 トムは、$1.10 するスパークプラグを購入するために自動車部品店に行きますが、財布の中にあるのは2
ベタープログラマ ―優れたプログラマになるための38の考え方とテクニック 作者: Pete Goodliffe出版社/メーカー: オライリージャパン発売日: 2017/12/15メディア: 単行本(ソフトカバー) 昨年の6月から翻訳を行ってきた本です。優れたプログラマになるために、どのようなことを心がけるべきかについて、ソフトウェア開発の様々な側面について説明されいます。 目次は、以下の通りです。 1章 コードを気にかける コードへの正しい取り組み方と態度を身に付ける 第Ⅰ部 you.write(code) 2章 見かけのよい状態を維持する コードの表現:レイアウトと名前付け 3章 少ないコードを書く 不必要なコードを書かない 4章 取り除くことでコードを改善する 死んでいるコードを見つけて取り除く 5章 コードベースの過去の幽霊 過去に書いたコードから学ぶ 6章 航路を航行する なじみの
今日(2017年8月31日)がリコーへの最終出社日です。2009年9月1日にリコーへ入社してから、主に行ってきたことを簡単にまとめます。 【業務関連】所属した開発組織の業務として行ったものです。 技術教育:2010年に延べ500名以上のソフトウェアエンジニアに対して、「ソフトウェアエンジニアの心得」「テスト駆動開発」「C++」「API設計の基礎」などの教育を実施しました。しかし、「教育と場」でも書いたように、今から振り返ってみると、単に「教育をした」と「教育を受けた」ということだけが残り、私が教えた内容を実際の開発の現場で指導する人がいないため、開発組織としてのレベルアップにはならなかったと思います。 Jenkins導入:2010年10月から行ったものです。当時デジタル複合機内で動作するJavaの開発環境やインテグレーション環境は、私の視点からはあまりにもお粗末でした。それで、FXIS時代
2009年9月から働き始めた株式会社リコーを8月31日付けで退職します。丸8年働いたことになります。現在57歳であり、定年退職までにはまだ2年と少しありますが、「セカンドキャリア制度」(早期退職制度のようなもの)の適用を受けて退職します。 8年間の会社での業務や退職理由については述べませんが、業務以外の私的活動の成果をまとめてみると次のようになります。 翻訳本(8冊):『アプレンティスシップ・パターン』『プログラミング原論』『Android SDK 開発クックブック』『プログラミング言語Goフレーズブック』『Objective‐C明解プログラミング』『APIデザインの極意』『Java SE 8 実践プログラミング』『プログラミング言語Go』 自著(2冊+α):『ソフトウェア開発の名著を読む 【第二版】』『プログラマー”まだまだ”現役続行』『API設計�の基礎』 Jolt Award読書会
2000年にclibと呼ばれるC++用のライブラリーを開発しました。それは、今でも富士ゼロックスのデジタル複合機で1000万行を超えるコントローラソフトウェア(*)と呼ばれる制御ソフトウェアで使われているライブラリです。メモリ管理機構とマルチスレッドプログラミング機構を統合したようなC++のライブラリです。 (*)http://www.atmarkit.co.jp/ait/articles/1507/06/news009.html clibは、私がそのAPI仕様をすべて設計し、実装は他の優秀なエンジニア2名に行ってもらいました。API仕様には、防御的プログラミングも含めて、メモリ管理機構での細かな動作仕様も書いていました。 このライブラリに関して、忘れないうちに一連のブログ記事として書きたいと思います。しかし、記憶は嘘をつきます。したがって、事実とは異なった私の記憶の嘘が含まれているかもし
コードカバレッジを品質基準としない「API設計の基礎」の3.8節「コードカバレッジと防御的プログラミング」では、次のように述べています。 テストコードによるコードカバレッジは、そのソフトウェアの品質を担保しません。コードカバレッジが100%だから、品質が高いとは限りません。バグがあるコードでも、テストでコードカバレッジを100%にすることはできます。 ある機能を持つモジュールを開発する場合、そのモジュールのAPI設計が重要になります。APIの仕様には機能や使い方はもちろんのこと、不正なパラメータの場合の振る舞いが記述されていなければなりません(参考:「API設計の基礎」)。 そして、テストコードとしては、その仕様を検査するテストを書くことになります。①適切なAPI仕様、②それに基づく適切なテスト、そして実装です。実装がテストに合格したら、コードカバレッジを計測するわけです。コードカバレッジ
発売日が2017年10月29日の予定になっていますが、英語版の『Effective Java, 3rd Edition』が予約注文可能になっています。
研修では、『プログラミング言語Go』を事前に読んで、質問をまとめてもらうと同時に練習問題を解いてもらいます。この予習は基本的に私的時間※に行ってもらいます。月に1日だけの業務中の研修では、質問への回答やディスカッション、および練習問題の解答の確認を行います。 ※ 予習がすべて私的時間なので、研修の受講は「希望者」だけです。 リコー勤務時の研修コースのタイトルは、「プログラミング言語Go基本技術習得コース」となっていました。これは初心者向けという意味ではなく、Go言語でプログラミングするのであれば最低限学んでおくべきことを学ぶという意味でした。
1999年に若手技術者に基本的なことを学んでもらうために、当時はこの英語版を利用して第1章「Style」と第2章「Algorithms and Data Structures」の早朝勉強会を海老名プライムタワー(海老名市)、KSP(川崎市)、岩槻(さいたま市)の3拠点で私が出向いて開催しました。その時に作成したのが「勉強会ノート」です。 勉強会ノート: http://www001.upp.so-net.ne.jp/yshibata/TPOP.pdf その後、日本語版が出版されました。 日本語版を使用して始めた社内教育が「プログラミング作法」教育です。当初は、以下の3部から構成される1日の教育コースでした。 「ソフトウェアエンジニアの心得」 コードレビューの重要性とコードレビュー・ガイドの説明 『プログラミング作法』の第1章「スタイル」の教育 4社※1でソフトウェア系技術者の新卒新人向け教育
Go言語に関する書籍を読んで、Go言語を学ぶ読書会を11月から計画しています。以下が概要です。 毎月第2土曜日の午後1:00〜午後5:00まで。 基本的に書籍を読んでいきます。事前に割り当てをして発表してもらうのではなく、当日、書籍を読んでいき、疑問点などがあれば参加者で議論をします。 場所は、横浜市内(みなとみらい)を予定しています。 最初の書籍は、『プログラミング言語Go』です。
「API設計の基礎」は37頁しかないですが、それを題材として勉強会をしたという人達から誤字・脱字を指摘していただき、修正したものをアップしました。 2009年に最初のドラフトを公開してからもう7年になります。さまざまなプロジェクトのコンサルテーション(レビュー)を通して分かるのは、「API設計の基礎」に書いてあることを部分的でもきちんと実践しているエンジニアやソフトウェア開発組織は非常に少ないということです。 「まえがき」に次のように書いています。 本書は、私自身がソフトウェア開発を行いながら学んだことをまとめたものであり、その内容には偏りがあるかもしれません。しかし、本書を通して、みなさんが私と同じような遠回りをすることなくソフトウェア開発をされることの助けとなれば幸いです。一人のエンジニアが遠回りするのはその人の問題で終わりますが、ソフトウェア開発組織が遠回りすることは、その組織に属し
長年行っているJava研修(Java 8研修も含む)はテキストとして『プログラミング言語Java第4版』や『Java SE 8 実践プログラミング』を使用しています。また、今年から始めたGo言語研修は『プログラミング言語Go』を使用しています。どのテキストにも、プログラミングの練習問題が豊富に含まれています。 基本的にプログラミングの練習問題は事前に解いてもらいます。そして、研修の場で解答の確認を行います。つまり、ソースコードを研修の場で開くわけです。私自身は事前に解答のソースコードを見ておくことはしませんので、研修の当日に受講生のソースコードを見ることになります。 練習問題であってもソースコードの可読性という視点でも分類はできますが、解答できているかというレベルで分類すると次のようになります。 全く解けていない 一見すると解いているように見えるけど、バグがある 練習問題が求めているものと
UUUM社の採用に関するブログ「優秀なエンジニアを採用するために面接で気をつけていること」でエンジニアの学習に関して次のように書かれています。 採用を決める時の一番重要なポイントは実力ですが、20代の若い方は将来性を期待して、ポテンシャル採用をすることもあります。 ポテンシャル採用で重要なのは、なんといっても向上心。 「いろんな技術を勉強したいんです」というのは誰でも言いますよね。 本当にそう思っているのであれば普段から勉強しているはずなので、中身をちゃんと理解できているのかを確認させてもらいます。 20代に関しては、現時点での実力が多少低くても採用します。 その代わり、しっかり勉強してもらって、ちゃんとした技術力を身につけてもらいます。 30代になってくると、やはり実力が求められます。 10年近くもエンジニアをやっていながら、技術的な知識の薄い人が多いのには驚かされます。 それだけ長い時
プログラミング言語Go 作者: Alan A.A. Donovan出版社/メーカー: 丸善出版発売日: 2016/06/20メディア: 単行本(ソフトカバー)
プログラミング言語Go 作者: Alan A.A. Donovan出版社/メーカー: 丸善出版発売日: 2016/06/20メディア: 単行本(ソフトカバー) 池袋のジュンク堂で「Goの設計思想を読み解く~実際の開発に活かすために」と題して、刊行記念イベントが開催されます。鵜飼さんとのトークイベントです。 開催日時:2016年07月06日(水) ~ 場所:ジュンク堂 池袋本店 鵜飼 文敏(Googleソフトウェアエンジニア) 柴田 芳樹(『プログラミング言語Go』訳者) 19:00開場 19:30開演事前予約が必要ですので、参加方法などの詳しい情報はこちらを見てください。
次のページ
このページを最初にブックマークしてみませんか?
『柴田 芳樹 (Yoshiki Shibata)』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く