サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
Switch 2
snoozer05.hatenablog.jp
翻訳を担当した書籍『ソフトウェアアーキテクトのための意思決定術 リーダーシップ/技術/プロダクトマネジメントの活用』(インプレス)が明日2024年12月11日に発売となります。 本書は、2023年12月に出版されたSrinath Perera 著『Software Architecture and Decision-Making: Leveraging Leadership, Technology, and Product Management to Build Great Products』(Addison-Wesley Professional)の全訳となります。 ソフトウェアアーキテクトのための意思決定術 リーダーシップ/技術/プロダクトマネジメントの活用 作者:Srinath PereraインプレスAmazon 著者は、Apacheのオープンソース開発者として20年以上のキャリアを
翻訳を担当した書籍『スタッフエンジニアの道ー優れた技術専門職になるためのガイド』(オライリー・ジャパン)が来週(2024年8月26日)発売となります(電子書籍はオライリー・ジャパンのサイトでの販売となります)。本書は、2022年にO'Reilly Mediaより刊行されたTanya Reilly著『The Staff Engineer's Path: A Guide for Individual Contributors Navigating Growth and Change』の全訳となります。 スタッフエンジニアの道 ―優れた技術専門職になるためのガイド 作者:Tanya Reillyオライリー・ジャパンAmazon 本書は、技術専門職としてのキャリア成長に必要な考え方やスキルを、20年を超えるキャリアを持ち、現在も現役で上級技術専門職を務めている著者が、自身の経験をもとに整理・解説し
翻訳を担当した電子書籍『Ruby on Rails パフォーマンスアポクリファ』が発売となりました。 書籍は以下から購入できます。 Ruby on Rails パフォーマンスアポクリファ 本書は、2020年に出版されたNate Berkopec著『The Ruby on Rails Performance Apocrypha』の全訳です。原書は訳書と同様、著者の販売サイトで自主出版の電子書籍として出版され、現在はKindleストアでも販売されています。 The Ruby on Rails Performance Apocrypha The Ruby on Rails Performance Apocrypha: A starter guide to making Rails apps faster and more scalable (English Edition) 作者:Berkope
2024年6月29日(土)にHOKKAIDO x Station01をお借りしてえにしテック15周年記念カンファレンスを開催しました。 当日はたくさんの方々にお越しいただき、おかげさまで、とても特別な15周年を迎えることができました。参加いただいた皆さま、あたたかいメッセージをいただいた皆さま、登壇いただいた高橋さん、角谷さん、大場さん、平鍋さん、美味しいコーヒーを出していただいた猫廼舎さん、運営をつつがなく取り仕切ってくれたメンバーのみんなに感謝します。ありがとうございました。 正直、まだあの場がなんだったのかをきちんと飲み込みきれておらず、きちんとした総括はできない感じなのですが、何かを書いておかないと先に進めない気がしているので、一旦カンファレンスのことを書き残しておこうと思います。 15周年の節目、何をしたいかと考えて出てきたのは、一番に初心に返って勉強会がしたいなという気持ちでし
技術顧問先で、一生懸命コードに向き合っているプログラマーになりたての方から、次のような質問をもらいました。 最初に面談した時、1年後にいいコードが書ける、上手に書けることを目標にしましたが、 先日スクール時代の同期(それぞれRubyの会社で働いている)と話したところ、会社ごとにレビューの仕方やコードに関する基準がさまざまなようで、良いコードとはなんなのか疑問に感じました。「いいコード」とは、みたいな部分で島田さんの考え方をお聞きできたら嬉しいです。 この質問にぼくは次のような回答をしたのですが、「この質問が来たら他の人はどんな回答するんだろうな」に興味があるので、ここにしたためておきます。もしよかったら「若者にこれを聞かれたら自分ならこう答える」をコメントなどで残していってもらえたら嬉しいです。 とても大事な疑問を見つけられたんだなあと思います。 「良さとは何か」ということに向き合う必要の
翻訳を担当した書籍『ソフトウェアアーキテクチャメトリクス―アーキテクチャ品質を改善する10のアドバイス』(オライリー・ジャパン)が明日(2024年1月24日)発売となります(電子書籍はオライリー・ジャパンのサイトでの購入となります)。本書は、2022年10月に出版されたChristian Ciceri, Dave Farley, Neal Ford, Andrew Harmel-Law, Michael Keeling, Carola Lilienthal, João Rosa, Alexander von Zitzewitz, Rene Weiss, Eoin Woods 著『Software Architecture Metrics: Case Studies to Improve the Quality of Your Architecture』(O'Reilly Media)の全
「急な売れ」を経験したわけでも、作家でもない。けれども、読んでいるとなんだか「心当たりのある」出来事がたくさん出てきて、胸がキュッとなる。そして、最後の4章で著者の「明日への繋ぎ方」をお裾分けしてもらいながら、自分の「明日への繋ぎ方」を考える。朱野帰子さんの『急な「売れ」に備える作家のためのサバイバル読本』を、僕はそんな風に読みました。 techbookfest.org 「急な売れ」や「作家のための」という言葉から、本書を自分とは無関係の本だと思われる方は多いだろうと思います。ですが、本書で語られる「急な売れ」を次のような状況だとイメージしてみたなら、どうでしょう。本書の印象が少し違って見える人はいるのでないでしょうか。 組織(やコミュニティ)内で立場が変わったり能力や名前などを認知されるなどした結果、いろんな人の期待や相談、依頼などが舞い込むようになった状況 本書は、そうした状況(すなわ
翻訳を担当した書籍『ソフトウェアアーキテクチャ・ハードパーツ ―分散アーキテクチャのためのトレードオフ分析』(オライリー・ジャパン)が本日(10月27日)発売となります(電子書籍はオライリー・ジャパンのサイトから購入できます)。本書は、2021年10月に出版されたNeal Ford, Mark Richards, Pramod Sadalage, Zhamak Dehghani 著『Software Architecture: The Hard Parts』(O'Reilly Media)を全訳したものです。 ソフトウェアアーキテクチャ・ハードパーツ ―分散アーキテクチャのためのトレードオフ分析 作者:Neal Ford,Mark Richards,Pramod Sadalage,Zhamak DehghaniオライリージャパンAmazon 本書は、『ソフトウェアアーキテクチャの基礎 ―エ
翻訳を担当した書籍『ソフトウェアアーキテクチャの基礎――エンジニアリングに基づく体系的アプローチ』(オライリー・ジャパン)が3月8日に発売されます。本書は、2020年1月に出版されたMark Richards, Neal Ford著『Fundamentals of Software Architecture』(O'Reilly Media)を全訳したものです。 www.oreilly.co.jp ソフトウェアアーキテクチャとは、ソフトウェアシステムの成功に欠かせない重要な土台です。そのためソフトウェア開発者には、効果的なアーキテクチャを実現するスキルが求められます。本書は、そうした効果的なアーキテクチャを設計、構築、維持するアーキテクトになるために必要なスキルや知識を、現代的な視点から整理して包括的に解説する書籍です。 ソフトウェアアーキテクチャの定義から、アーキテクトの役割、モジュールや
翻訳を担当した書籍『ユニコーン企業のひみつ―Spotifyで学んだソフトウェアづくりと働き方』(オライリー・ジャパン)が4月26日に発売になります。本書は2019年3月にPragmatic Bookshelfより出版されたJonathan Rasmusson著『Competing with Unicorns: How the World’s Best Companies Ship Software and Work Differently』の全訳です。 本書は、『アジャイルサムライ』(オーム社、2010年)の著者として日本でもよく知られている、Jonathan Rasmussonの3冊目の著作であり、ある時期のSpotifyに身を置いていた著者が、そこでの経験などを元にユニコーン企業のソフトウェアづくりと働き方について解説した書籍となります。 www.oreilly.co.jp 大規模な成
翻訳を担当した書籍『モノリスからマイクロサービスへ ―モノリスを進化させる実践移行ガイド』(オライリー・ジャパン)が12月26日に発売になります。本書は2019年11月にO'Reilly Mediaより出版されたSam Newman著『Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith』の全訳で、マイクロサービスアーキテクチャを解説した書籍として日本でも定評のある『マイクロサービスアーキテクチャ』(原題『Building Microservices』)の著者であるSam Newmanによるマイクロサービスを取り上げた2冊目の書籍となります。 O'Reilly Japan - モノリスからマイクロサービスへ 本書は、モノリスからマイクロサービスアーキテクチャへと移行するための実践的なガイドです
2020年11月5日から7日に開催されたスクラムフェス札幌2020で、招待講演を勤めました。 スクラムフェス札幌2020 運営の根本さんから最初に招待講演の打診があったのは、2020年の1月のことでした。うれしくはあったものの、正直最初は乗り気ではありませんでした。スクラムの集まりで招待講演をする資格があるとは自分に思えなかったし、なによりアジャイル札幌として今も活動している人たちの前で、ぼくが何を話せるだろうと考えたからです。 ぼく自身は2017年でアジャイル札幌の運営からは身を引かせてもらっていたし、フォーカスすべきものを絞った結果、アジャイル札幌の集まりに積極的に関わるということもなくなってしまっていました。彼らは活動を続け、積極的に外に出ていき、新しい人たちを迎え、アジャイル札幌として活動しているというのに。そんなぼくが、どの面を下げてみんなに何を話すのか、みんなの方がよっぽどその
構造は、凝集度が高く、結合度が低い場合に安定する - Larry Constantine 私たちプログラマーは、その仕事において、できる限り良いコードを書きたいと考えます。しかし、「良いコードとは何か」という問いに対して答えるのは、そう簡単ではありません。「良さ」を測るには、「何に対して」という軸が必要であり、その軸は一つではなく、さらには、コードを書いている状況に応じて、大事にすべき軸が変わるということも往々にしてあるからです。そうしたとき、私たちは何らかの尺度でもってコードを測って、そのときのコンテキストにおいて良い落とし所を定めます。 そのようなときに、コードの品質を測る軸としては、有名なものには「凝集性(Cohesion)」と「結合度(Coupling)」があります。ここでは、そのうちの「結合度」を測る指標の一つとして「コナーセンス(Connascence)」を紹介します。 コード
翻訳を担当した書籍『Design It! ― プログラマーのためのアーキテクティング入門』(オライリー・ジャパン)が11月25日に発売になります。本書は2017年にPragmatic Bookshelfより出版されたMichael Keeling著『Design It!: From Programmer to Software Architect』の全訳です。Pragmatic Bookshelfファンにはおなじみの「... It!」シリーズの一冊で、日本語で読める「... It!」シリーズとしては4冊目の書籍となります。 O'Reilly Japan - Design It! 本書は、設計スキルを成長させたいプログラマーに向けたアーキテクティングの入門書です。ソフトウェアアーキテクチャの基礎とデザイン思考の考え方から始まり、ソフトウェアアーキテクトとして、チームと共に優れたソフトウェアを
翻訳を担当した書籍『進化的アーキテクチャ ― 絶え間ない変化を支える』(オライリー・ジャパン)が8月18日に出版になります。原書は2017年に出版された『Building Evolutionary Architectures ― Support Constant Change』(O'Reilly Media)です。 O'Reilly Japan - 進化的アーキテクチャ 現代におけるエンタープライズアーキテクチャは、もはや静的な計画をあてにすることはできなくなっています。そしてソフトウェア開発エコシステムは、ツールやフレームワーク、技術イノベーションの流れと共に絶え間なく変化しています。こうした状況の中で、いったん構築したシステムを成長させていくには、さまざまな変化に適応しながら進化するアーキテクチャをシステムに組み込む必要があります。本書は、そうしたアーキテクチャを「進化的アーキテクチャ
拙訳『エラスティックリーダーシップ ―自己組織化チームの育て方』にコミットメント言語 (Commitment Language) というものがでてきます。コミットメント言語とは、簡単にいうと「言質を与える言い方」のことで、本書では「仕事では自分が何を行うかを言質を与える言い方で約束すべきである」という話で、このコミットメント言語というものがでてきます。 具体的にいうと、希望的な物言い(「したいと思います」「しようと思ってます」「やれると思います」)やコミットメントを表明しない言い方(「はやったほうがいいとは思っています」「やらないといけないとは思ってます」)をせず、やることを約束する言葉遣い(「〜します」)をするようにしましょうという話です。 ですが、実はここだけを切り取って読んでしまうと勿体なくて、著者のロイがコミットメント言語の章で伝えたい主旨は、単に言い方だけを変えなさいという話では
しばらく絶版になってしまっていた「達人プログラマー―システム開発の職人から名匠への道」が、オーム社から「新装版 達人プログラマー 職人から名匠への道」として復刊されました。原著をリスペクトした素晴らしい表紙とコンパクトな判型、訳もより読みやすく見直され、電子書籍としても手に入るようになり、とても価値のある復刊だと感じます。 オーム社から復刊した『新装版 達人プログラマー』、電子書籍版が紙の本に先行してもう発売している。本当に素晴らしい。『達人プログラマー』が帰ってきた。 / “新装版 達人プログラマー 職人から名匠への道 | オーム社 eBook …” https://t.co/sSWChIFpsO— Takuto Wada (@t_wada) October 19, 2016 「新装版 達人プログラマー 職人から名匠への道」は、Andrew Hunt と David Thomas によっ
デザインの伝え方 作者: Tom Greever,坂田一倫,武舎広幸,武舎るみ出版社/メーカー: オライリージャパン発売日: 2016/09/16メディア: 単行本(ソフトカバー)この商品を含むブログを見る 「デザインの伝え方」を読んで、「ソフトウェア開発とは創作とコミュニケーションの協調ゲームである」という Alistair Cockburn *1 の言葉を思い出しました。 「デザインの伝え方」は、製品やサービスのデザインに関わるようなデザイナーに向けて、デザインの実現に影響ある人々(ステークホルダー)とどのようにコミュニケーションしていったらよいかが書かれた書籍です。具体的には、そうした人たちにデザインを伝える際に気をつけるべきこと、コミュニケーションギャップの埋め方、必要な心構え、そして合意形成のテクニックなどが書かれています。 なぜ、上記のようなデザイナー向けの書籍から、前述の言葉
新しいプロジェクトのたびに、どうチームを作っていくかということを試行錯誤しています。つい最近やってみて、とても有効性を感じた試みに、チームを始める際にストレングス・ファインダーの診断結果を交換しあうというものがあります。 ストレングス・ファインダーとは、人の持つ34の資質の中から自分の中で優位を占める特徴的な資質5つを診断してくれる診断テストです。 ストレングス・ファインダーの結果は、互いの強みや特性を知るという、自律的なチームを作る上では必須だけれど難易度の高いコミュニケーションをとてもスムーズに行える良いツールだと感じています。しかし、現状はまだあまりそうした使われ方として十分には流通していなそうなので、ここで紹介します。 ストレングス・ファインダーについて ストレングス・ファインダーとは、企業コンサルや世論調査などを行っているギャラップ社が提供している診断テストです。オンライン上で質
先日、プログラマー的思考法を育む知育絵本「ルビィのぼうけん こんにちは! プログラミング」を翻訳された鳥井雪さんの話を聞く機会がありました。「ルビィのぼうけん」をどう作っていったかという内容で、子どもたちに実際に試してもらい、書籍を(表現やレイアウトなども含めて)つくり直していったというお話でした。 鳥井さんの話を聞いて思い出したのは「子どものUXデザイン ―遊びと学びのデジタルエクスペリエンス」という書籍です。「子どものUXデザイン」は、子ども向けのデジタルエクスペリエンスのデザインに関する書籍なのですが、知育絵本という分野も同じようにデザインしていくことが大事なのだろうということに感心しました。 そうした気持ちがあって、お話のあとで「子どものUXデザイン」のことを少し振ってみたりしたのですが、会場の雰囲気でこの書籍があまり知られていなそうな印象があり、勿体無いと感じました。そこで、広く
Pull Request を通して行うコミュニケーションに「レビュー」という言葉がつくことに違和感を感じるときがあります。 Wikipediaでコードレビューを引くと、「見過ごされた誤りを検出・修正することを目的として体系的な検査(査読)を行う作業 」とあります。もちろん、これを目的として行うやり取りもあるのですが、その手前の「コードや設計について議論し、もっと良い判断を探る」ために行うコミュニケーションもあると思います。むしろ、そちらのコミュニケーションをやりやすいことが、Pull Request というプラットフォームが提供する価値なのではと感じることが多いのが、違和感の元かもしれません。 2015年6月に O'Reilly から出版された「Discussing Design: Improving Communication and Collaboration through Crit
このページを最初にブックマークしてみませんか?
『snoozer05's blog』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く