並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 40 件 / 601件

新着順 人気順

柴田芳樹の検索結果1 - 40 件 / 601件

  • 新人の方によく展開している有益な情報 - Qiita

    新人の方によく展開させていただいている有益な情報をまとめておきます。今後も展開することがあるかもしれないため情報をまとめております。 あらたな、有益な情報がありましたら、随時追加してまいります。 有益な記事・論文・書籍等を執筆・紹介していただいた皆様に感謝申し上げます。 ちなみに、本記事に記載されている情報は、お困りごと・お悩みごとをお聞きしたとき・気づいたときに、そのお困りごとに対して参考になりそうなものだけを展開していました。この情報を一気に展開していたわけではございません。 コードリーディングについて [1]ソースコードを読むための技術 https://i.loveruby.net/ja/misc/readingcode.html [2]派生開発推進協議会 関西部会 スペックアウトチーム,「派生開発におけるスペックアウト手法の提案」,派生開発カンファレンス2015,2015 http

      新人の方によく展開している有益な情報 - Qiita
    • 僕がソフトウェア開発を勉強し始めて3年間でやったこと - うさぎ組

      昨日、@irofさんと飲みながら自分を思い返すと「ちゃんとソフトウェア開発を勉強しはじめてから3年間たった」つまり「@bleisさんを知ってからこの5月でまる3年間たった」 それまでの僕はデザインパターンもオブジェクト指向がなんたるかも、バージョン管理もなにも知らなかった。 毎日言われたことをこなす仕事をして、変えたいけど誰も教えてくれないし、学び方すら教えてくれなかった。 それなりに努力してたけど、よくはわかっていなかった。 そんな状態から抜け出したのが3年前。このブログの先頭でも書いた。当時僕は21歳かな。(ちなみに就職したのは19歳のとき) →【このブログをはじめるきっかけ - うさぎ組】 この3年間でやったことをふりかえってみようと思いました。 ちょっとわかりにくいだろうけど、2009年5月からの12ヶ月周期で書いてみます。 こうやって振り返るのはあくまで僕のためであって、何かを誇

        僕がソフトウェア開発を勉強し始めて3年間でやったこと - うさぎ組
      • 勉強するとこんな人になりますよ - megamouthの葬列

        axia.co.jp どこかのエントリで呼ばれた気がした。 必要もないのに他人のエントリに乗っかるのは好きではないのだが、たまにはブログっぽいことを書かないと、と思ったので、軽く書く。 ある勉強したプログラマの末路 まず自分の話をしたい。 私は趣味で多数の求人サイトに登録している。 転職エージェントはうるさいので使っていない。 サイトに登録して、経験言語と年数にチェックを入れ、職務経歴書をサニタイズして(なんとこの用語は顧客を特定できないように「無毒化する」という意味で一般的に使われ始めている)掲載しているぐらいである。 ちなみにpaizaでもSランクを持っている。自慢にもならないし、求職活動に役立つわけでもないが、持っている。 こうして、現年収を正直に「200万」と書いておくと、スカウトメールがけっこうやって来るので、それらを暇つぶしに眺めるのである。 Webで年収400万超えるとこって

          勉強するとこんな人になりますよ - megamouthの葬列
        • Javaプログラマが知るべき9のこと - @katzchang.contexts

          はじめに ソースコードは設計であり、コードの記述は品質に直結するのは言うまでもない。ちなみに、プログラマにとって特に重要なのは保守性だ。コードは書いた直後から保守対象となるからだ。コードは要求文書の範囲で動けばいいと思っている人がいれば今すぐ、ソースコードをコピペして100klに増えるプラグインがいつの間にかインストールされる呪いをかけてあげよう。幸い、ここを読んでいる人にはそんな人はいないだろうと思うけれども。 ということで、コードの品質を下げる要因、すなわちシステム全体の品質を下げる要因となり、かつ使われやすいアンチパターンを挙げ、対策を検討していくことにする。対象は以下: 出力パラメータ 処理状態返却 意味のある配列 無意味な初期化 多すぎるtry-catch 暗黙の順序 コンパイラ警告の無視 過剰なコメント e.printStackTrace() 出力パラメータ メソッドの引数にオ

            Javaプログラマが知るべき9のこと - @katzchang.contexts
          • 伸ばすのが難しい能力: 柴田 芳樹 (Yoshiki Shibata)

            2018年6月1日に株式会社メルペイに入社して、4年が過ぎました。入社当時は、定年が60歳と聞いていたので、1年半の勤務だと思っていましたが、実際の定年は65歳であり定年まであと2年半です。 ソフトウェアエンジニアにとって重要な能力と(私は考えるが)、身に付けるのが難しいのが現実だと、この4年間で再認識したのは次の三つです。 開発の最初にAPI仕様をきちんと書けるソフトウェアエンジニアは少ない テストファースト開発を行っているソフトウェアエンジニアは少ないか、いない Tech Blogなどの執筆で、読み手を意識して、分かりやすい文章を書く、ソフトウェアエンジニアは少ない API仕様については、このブログでも何度か書いています(「API仕様を書く」)。テストファースト開発についても、「テストファースト開発」を書いています。分かりやすい文章については何も書いていないですが、「伝わる技術文書の書

              伸ばすのが難しい能力: 柴田 芳樹 (Yoshiki Shibata)
            • 達人出版会:技術系電子出版・電子書籍

              探検! Python Flask Robert Picard, 濱野 司(訳) BareMetalで遊ぶ Raspberry Pi 西永俊文 なるほどUnixプロセス ― Rubyで学ぶUnixの基礎 Jesse Storimer, 島田浩二(翻訳), 角谷信太郎(翻訳) 知る、読む、使う! オープンソースライセンス 可知豊 きつねさんでもわかるLLVM 柏木餅子, 風薬 Blenderでアニメ絵キャラクターを作ろう!トゥーンレンダリングの巻 夏森轄 サイバーセキュリティの教科書 Thomas Kranz(著), Smoky(訳), IPUSIRON(監訳) ゲーム作りで楽しく学ぶ オブジェクト指向のきほん 森 巧尚 ブランドスイッチの法則 田中 宏樹 Blenderでアニメ絵キャラクターを作ろう!モデリングの巻 夏森轄 R/RStudioでやさしく学ぶプログラミングとデータ分析 掌田津耶

                達人出版会:技術系電子出版・電子書籍
              • 2014年に読んだ技術書で良かったもの - うさぎ組

                概要 新刊にかぎらず、今年読んでいて「あー、良書だなー」って思ったものをあげています。これ、ダメじゃないの?とか、あー、やっぱりこれいいよねっていうコメントもらえると嬉しいです。 基本は、.NETにおけるWeb APIやFW開発でQA * POな人が思う良書です。今年は技術書より論文、言語仕様書、実装を読んでいることが多かったので、去年の半分の30冊くらいしか読んでいないかな。 開発チーム系 エッセンシャル スクラム 作者: Kenneth S. Rubin出版社/メーカー: 翔泳社発売日: 2014/08/01メディア: Kindle版この商品を含むブログを見る スクラムなんとなくわかっているんですけど、自分以外の状況よくわからんしなー、進め方変じゃないかなぁっていうときに、読むとめっちゃ参考になります。 組織パターン 作者: James O. Coplien,Neil B. Harri

                  2014年に読んだ技術書で良かったもの - うさぎ組
                • オブジェクト指向はコードを複雑に読みにくくする - きしだのHatena

                  「オブジェクト指向するとプログラムが読めなくなるから禁止」のような話は昔からあって、新しい技術についてこれない人を揶揄するようなニュアンスで使われていましたが、実際にはこれはオブジェクト指向迷路にうんざりした現場での率直な意見だと思います。 オブジェクト指向は、まじめにやるほどプログラムを読みにくくするという性質をもっています。 ※ 使い方次第というコメントついてますが、だからこそちゃんと性質をしっておく必要があると思います。 オブジェクト指向の代表的な指針を3つあげると次のようなものがあります。 オブジェクト同士の連携としてプログラムを組む 単一責務の原則 インタフェースと実装の分離 まず、オブジェクト同士の連携でプログラムを組むと、コードが飛びまくって追いにくくなります。そして単一責務の原則により、小さいクラスが大量に生成されて、追いにくさがさらにあがっていきます。 ダイクストラ先生が

                    オブジェクト指向はコードを複雑に読みにくくする - きしだのHatena
                  • 僕は僕にどういう教育を授けたか - 怠惰を求めて勤勉に行き着く

                    まえがき 会社の若い子に「情報系出身でもないのに一体どうやって勉強してきたんですか?」と聞かれたのでランチを食べながら「こんな本読んだ。これもタメになった。あ、これもタメになった」とKindleを広げながらリストアップした。思い返せばたくさん本を読んだ。その中には役に立ったものもあれば時間の無駄だったものもある。すると「あ、役に立った本だけ抽出したら有益かもしれないな」と思ったのでエントリにする。 僕は文章を簡潔に分かりやすくまとめる才能が致命的にないのでこのエントリもげっそりするほど長い*1が、2017年も暮れなのでここはひとつ日本酒でもかっ喰らいながら自分の人生を振り返ってみようと思う。 無理やり要点をまとめるならば、 TCP/IPの知識 Linuxの知識 なにかひとつプログラミング言語 なにかひとつGUIシステムの理解 アルゴリズムとデータ構造 強運*2 を身につけたらどんなに低く見

                      僕は僕にどういう教育を授けたか - 怠惰を求めて勤勉に行き着く
                    • ソフトウェアの複雑さに立ち向かう1つの哲学 :『A Philosophy of Software Design』 を読んだ - こまぶろ

                      あけましておめでとうございます、になるはずだったのですが、後から読んだ『Googleのソフトウェアエンジニアリング』の方を先に記事にしたので新年2本目の更新です。 ky-yk-d.hatenablog.com さて、本題。最近のお気に入りポッドキャストであるe34.fmで激賞されていた『A Philosophy of Software Design』を読みました。初版は2018年に出ていて、今回は2021年に出た第2版を読みました。 スパゲッティコードを想起させる装丁 A Philosophy of Software Design, 2nd Edition (English Edition) 作者:Ousterhout, John K. Amazon scrapbox.io どんな本? 書籍のテーマはソフトウェアの複雑さです。複雑さとは、システムを理解したり変更したりするのを困難にさせるも

                        ソフトウェアの複雑さに立ち向かう1つの哲学 :『A Philosophy of Software Design』 を読んだ - こまぶろ
                      • 新人さんにすすめる有益な技術書達 2022春 - Qiita

                        はじめに 以下おすすめする技術書達です。分類に迷うものありつつ、流行り廃りあるかもなので2022春と書きました。 技術書達 基本 プログラムはなぜ動くのか プログラムはなぜ動くのか 第3版 知っておきたいプログラミングの基礎知識 | 矢沢 久雄 |本 | 通販 | Amazon 2000年代から推されている基本情報技術者レベルの本 イラスト図解式 この一冊で全部わかるWeb技術の基本 イラスト図解式 この一冊で全部わかるWeb技術の基本 | NRIネットコム株式会社, 小林 恭平, 坂本 陽, 佐々木 拓郎 |本 | 通販 | Amazon Webの全体像から、HTTPでやりとりする仕組み、さまざまなデータ形式、Webアプリケーションの開発、セキュリティ、システムの構築・運用まで、これからWebにかかわる人が知っておきたい知識をこの一冊で丸ごと解説! リーダブルコード リーダブルコード ―

                          新人さんにすすめる有益な技術書達 2022春 - Qiita
                        • 株式会社メルペイを退職します: 柴田 芳樹 (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)
                          • Javaのクラス宣言5種+α - プログラマーの脳みそ

                            Javaのクラス宣言には5種類ある。 トップレベルクラス・ネストしたクラス・内部クラス・ローカル内部クラス・匿名クラス(無名クラスとも言われる)の5種類だ。 今回はこの5種類のクラス宣言のおさらい。 トップレベルクラス これは普段使っているクラス。拡張子が.javaのファイルを作り、そのファイル名とクラス名を合致させなくてはいけない。そのjavaファイルのトップレベルに位置する。 ネストしたクラス 「ネストしたクラス」(Nested class)とはクラスの中にクラスがネストしている状態。トップレベルクラスの内側にstaticキーワードをつけてクラス宣言を行う。 public class Outer { public static class Nested { } } このネストしたクラスは、トップレベルクラスと同等の機能性を持つ。 クラス名はOuter.Nestedという名前で扱われるが

                              Javaのクラス宣言5種+α - プログラマーの脳みそ
                            • ソフトウェアエンジニアの成長カーブ(再掲載):柴田 芳樹 (Yoshiki Shibata):So-netブログ

                              「ソフトウェアエンジニアの成長カーブ」 最近良く話していることなのですが、社会人として働き始めた新卒の技術者は、最初の数年は成長していきます。与えられた業務を遂行しながら、そのための学習もしていくからです。しかし、2、3年すると開発業務をこなせるようになり、特に新たな勉強をしなくても、日々、会社に行って開発業務が遂行できるようになります。 この状態、つまり、継続した学習をしなくなった状態で、10年とか経過すると、ソフトウェアの世界は大きく変化している可能性があり、新たな技術が登場し、その人の技量は相対的に今度は低下しはじめます。しかし、この時点で、新たなことを学習するのは困難だったりします。学習する習慣が無いわけですから、勉強しろと言っても、「なぜ、休みの日に勉強しなければならないのですか」ということになります。 そのような人に対して、マネジメントは、その人ができる仕事を与えて、何とか仕事

                                ソフトウェアエンジニアの成長カーブ(再掲載):柴田 芳樹 (Yoshiki Shibata):So-netブログ
                              • 手動テストだけのソフトウェアは腐っていく: 柴田 芳樹 (Yoshiki Shibata)

                                この本で、著者のRobert Martinも、次のように述べています。 この10年間の間に この業界では多くのことがありました。1997年当時、テスト駆動開発などという言葉は誰も聞いたことがありませんでした。ほとんどの人にとって、単体テストというのは動作をひとたび『確認』したら捨ててしまうものでした。苦労してクラス メソッドを書き上げ、それらをテストするためのその場しのぎのコードをでっちあげていたのです。 『Effective Java』で有名なJoshua Blochは、この本の中のインタビューで、次のような会話を行っています。 「デバッグの話をしましょう。あなたが追いかけた最悪のバグはどのようなものでしたか」 それに対して、Joshua Blochは、 「最初に勤めた会社で私が開発したソフトウェアですね。ソフトウェアのデバッグに1週間半費やしました」 という話をしています。 1週間半費

                                  手動テストだけのソフトウェアは腐っていく: 柴田 芳樹 (Yoshiki Shibata)
                                • エンジニア専門職のグレードについて詳細な役割定義は必要か? - Kentaro Kuribayashi's blog

                                  様々な人々から、エンジニアに関する制度についてインタビューされる機会が増えてきた。その中で考えが整理されてきたパーツもあるので、せっかくなのでまとめておこうと思う。 ペバボのエンジニア職位制度のアップデートについてなどで書いている通り、ペパボはエンジニア専門職制度を制定し運用している。その前提として、専門職制度がどのような位置付けかというと、簡単に示すと以下の図の通りである。 この構造自体は特になんの変哲もない、わりと一般的な制度だといえるが、我々はこの中にひとひねり加えている。以下に説明する。 前提知識 ただし、その前に人事制度における前提的知識について述べておかないとならない。 社員格付け 昨今は「フラットな組織」「ネットワーク型組織」などというものも出てきているが、それはそれとして、一般に企業組織は、その構成員をなんらかの方法を用いて格付けしている。すぐに思い浮かぶのは、部長とか係長

                                    エンジニア専門職のグレードについて詳細な役割定義は必要か? - Kentaro Kuribayashi's blog
                                  • アプリケーションから例外を投げる派、投げない派 - Shin x Blog

                                    例外をどのような状況に投げるかもしくは投げないか、というのはわりと意見が分かれるところです。もちろん、プログラミング言語によっても異なりますが、同じプログラミング言語ユーザ同士でも様々です。 基本の考え方 ベースとしては、Effective Java の項目 39 にある下記の方針が参考になります。 例外的な状況の時にのみ例外を使う。 Effective Java 禅問答のような定義ですが、これには異論は無いでしょう。例外を正常フローで利用したり、制御構造に用いるべきではありません。 人によって異なるのは「例外的な状況」の解釈です。 例外的な状況 この「例外的な状況」の解釈は人によって異なるようで、これまでも議論になっていました。これまで聞いた解釈を乱暴に分けると以下の 2 パターンに分かれます。 1. アプリケーションから独自の例外を投げる派 ランタイムやミドルウェア連携などプラットフォ

                                      アプリケーションから例外を投げる派、投げない派 - Shin x Blog
                                    • スレッド・並行プログラミング/ マルチコア・並列プログラミングを学びはじめるためのN冊 - laiso

                                      読みたい本のリストを作ってる(いくつかは購入済み)。 なんかおすすめあったら教えてください。 でもこういうのってリスト作って仕事した気になって満足してしまう。 並列と並行 学びはじめる前なんだから当然よくわかってはいないんでけど、並列と並行処理の違いは以下で認識してる parallel と concurrent、並列と並行の違い - 本当は怖い情報科学 parallel と concurrent 、並列と並行の覚え方 - まめめも (追記) 孫引きなんだけど「コーディングを支える技術 171P」に「プログラミング言語の概念と構造」から引用した記述があった ここでは並行→プログラミング上の概念、並列→ハードウェアレイヤーの話となっていますね。 並列処理・並行処理がプログラミングに必要な理由 マルチコアを生かしたパフォーマンスの向上 大規模なデータの処理 GUIアプリケーションのユーザビリティ

                                        スレッド・並行プログラミング/ マルチコア・並列プログラミングを学びはじめるためのN冊 - laiso
                                      • 継続インテグレーションは強みではなくなった: 柴田 芳樹 (Yoshiki Shibata)

                                        Subversion/Gitなどを使用したソースコード管理、Jenkinsを使用した継続的インテグレーション、様々なxUnitフレームワークを使用した自動テストなどをソフトウェア開発組織として実践することは、今日では、その開発組織の技術的な強みではありません。 それらを実践しないことが、ソフトウェア開発組織の「弱み」なのです。また、組織としてそれらの実践を推進しない、あるいはサポートできないマネージャも「弱み」となります。さらに、大規模なソフトウェア開発組織においては、それらのためのインフラ整備をプロジェクトごとに立ち上げなければならず、サポート部門が存在しないことも弱みとなります。※1 ※1 プロジェクトを始めるごとに、ソースコード管理やJenkins用のサーバの調達、OSから様々なツールのインストールを一通り行うためには、それなりの時間を要します。したがって、バックアップをも含めて環境

                                          継続インテグレーションは強みではなくなった: 柴田 芳樹 (Yoshiki Shibata)
                                        • 「コンピューターの基礎は若い時に学んでいてほしい」 ソフトウェア開発組織が持つべきカルチャーとは

                                          日本CTO協会が主催の「Developer eXperience Day 2023」は、“開発者体験” をテーマに、その知見・経験の共有とそれに関わる方々のコミュニケーションを目的としたカンファレンスです。ここで登壇したのは、株式会社カウシェの柴田芳樹氏。45年の歴史から振り返ったソフトウェア開発とキャリアの変遷について発表しました。全3回。3回目は、柴田氏が影響を受けた出来事と、技術教育への取り組みについて。 米国駐在・Javaの登場・日本オラクルの社長の言葉…柴田氏が影響を受けた出来事 柴田芳樹氏:影響を受けた出来事について、ちょっと簡単に話をしていきます。 まず、初めてアメリカに駐在する時の送別会で、駐在経験のある先輩から、アメリカに行った時は「与えられた開発タスクをこなすと、さらに難易度の高い開発タスクが与えられるから注意しろ」と言われたんですね。 最初はピンと来なかったんですけど

                                            「コンピューターの基礎は若い時に学んでいてほしい」 ソフトウェア開発組織が持つべきカルチャーとは
                                          • 成長の場を求めないソフトウェアエンジニア?:柴田 芳樹 (Yoshiki Shibata):So-netブログ

                                            「ソフトウェア開発組織が持つべきカルチャー」と題して、過去に以下の記事を書いています。 継続した学習習慣 コンピュータの基礎を教える 共に学ぶ マネージャが勉強会を主催する プロセス中心ではなく、スキル中心 スキル向上に真剣に長期的に取り組む カンファレンスへ積極的に参加させる コードをレビューする Source Code Controlへ最低でも毎日コミットする ビッグバン・インテグレーションを避ける テストを自動化する ソースコードを調べる 自分で書いたコードを自分で見直す 知識教育だけではなく、良い行動パターンを促進する また、「コードレビューの視点」として、以下の記事を書いていいます。 Copyrightを書く 必要なエラー情報を付加する マルチスレッドプログラミングに注意する 言語仕様を確認する 独り言コメントは書かない 説明とコードが違っていないか注意する 知識の伝達の場 エン

                                              成長の場を求めないソフトウェアエンジニア?:柴田 芳樹 (Yoshiki Shibata):So-netブログ
                                            • quick sortよりも高速でmerge sortのように安定しているソートアルゴリズムtim sort [勘違い] - Islands in the byte stream

                                              <追記>ベンチマークプログラムに誤りがありました。ソート済のシーケンスに対してソートを掛けていました。ご指摘ありがとうございます>ak氏 そんな夢のようなソートアルゴリズムがあるのかというと、あるらしいんです。それがtim sortと呼ばれるアルゴリズムです。 画期的(?)なソートアルゴリズム「Sleep Sort」:濃縮還元オレンジニュース|gihyo.jp … 技術評論社 このあたりで拾ってきたネタですね。 merge sortを改良したアルゴリズムで、安定*1しており、しかも実行速度にも優れているとか。アルゴリズムの性能の評価は済んでいるらしく、CPythonやJDK7には既に導入済みのようですね。 ならば当然Perlのソートも…と考えるわけですが、まず評価のためにJavaのソースをC++にそのまま移植してみました。それがこれ(いちおうテスト済): https://github.co

                                                quick sortよりも高速でmerge sortのように安定しているソートアルゴリズムtim sort [勘違い] - Islands in the byte stream
                                              • Treasure Dataを支える(中の人に必要な)技術 - myui's memo

                                                Treasure Data(以下、TD)に入社して早2週間が経ちました。 入社してから、平成14年度IPA未踏ユース第1期で同期でスーパークリエイタであった西田さんがTDで働いているのを知りました。MapReduceやHadoopが登場した頃、「Googleを支える技術」という技術書*1でお世話になったのですが、いつの間にかTreasure Dataを支える人になっていたんですね*2。 Googleを支える技術 ?巨大システムの内側の世界 (WEB+DB PRESSプラスシリーズ) 作者: 西田圭介出版社/メーカー: 技術評論社発売日: 2008/03/28メディア: 単行本(ソフトカバー)購入: 47人 クリック: 1,166回この商品を含むブログ (374件) を見る TDではおかげさまで結構なペースでお客さんが増えていて事業規模拡大に備えて幅広い職種で人材募集中です。今回はTDのバッ

                                                  Treasure Dataを支える(中の人に必要な)技術 - myui's memo
                                                • 自己流オブジェクト指向プログラミング&Javaお奨め本2007年版 - カレーなる辛口Javaな転職日記

                                                  http://d.hatena.ne.jp/JavaBlack/20050909/p1の改訂.*1基本的に改訂版への差し替えと一部の新刊の追加程度になっている. お奨めのJava&オブジェクト指向プログラミング関連の書籍/参考文献リスト.初心者向け入門書や参考書から上級者向けの専門書まで,オブジェクト指向だとかJava言語とかの初心者〜中級者が学習をすすめる上での参考にすることを想定して作っている. 初心者向け勉強の手引き:http://d.hatena.ne.jp/JavaBlack/20070825/p1 オブジェクト指向プログラミング とりあえず初心者なら「オブジェクト指向プログラミング入門」「オブジェクト指向における再利用のためのデザインパターン」と,あと「リファクタリング―プログラムの体質改善テクニック (Object Technology Series)」くらいかな.ただしリフ

                                                    自己流オブジェクト指向プログラミング&Javaお奨め本2007年版 - カレーなる辛口Javaな転職日記
                                                  • Web API設計実践入門──API仕様ファーストによるテスト駆動開発

                                                    2024年7月25日紙版発売 柴田芳樹 著 A5判/208ページ 定価2,860円(本体2,600円+税10%) ISBN 978-4-297-14293-3 Gihyo Direct Amazon 楽天ブックス ヨドバシ.com 電子版 Amazon Kindle honto この本の概要 本書は,著者が1993年から約30年間経験してきたAPI仕様の作成,2003年から20年間経験してきたテストファースト開発/テスト駆動開発の知見をまとめたものであり,一般的なソフトウェア開発者が習得することが容易ではない事柄を,本書を通して学び,実践してもらうことを目的としています。 本書が提唱する「API仕様ファースト開発」はWebサービスにおける大域的なテスト駆動開発の実現に必要なものであり,また,API仕様ファースト開発を実現するにはテスト駆動開発が必要です。API仕様ファースト開発とテスト駆動

                                                      Web API設計実践入門──API仕様ファーストによるテスト駆動開発
                                                    • 2014年に出版された好みのIT関係本まとめ - Time Flies

                                                      2014年に読んだ本の中から主に2014年(及び2013年)に出版された自分好みの本をざっとリストアップする。 APIデザインの極意 Java/NetBeansアーキテクト探究ノート タイトル通りAPIデザインについて詳しく書かれた本。読者としてはJavaデベロッパを想定しておりJava特有のJDKのバージョン互換性やソースコード互換性に言及しているが、OOPの素養がある人なら読み進められると思う。なおカバーの隅には「※本書はプログラミングの初心者向けではありません。」などと書いてある。 APIデザインの極意 Java/NetBeansアーキテクト探究ノート 作者: Jaroslav Tulach,柴田芳樹出版社/メーカー: インプレスジャパン発売日: 2014/05/23メディア: 単行本(ソフトカバー)この商品を含むブログ (5件) を見る Javaエンジニア養成読本 [現場で役立つ最

                                                        2014年に出版された好みのIT関係本まとめ - Time Flies
                                                      • 初心者レベルの言い訳をしない: 柴田 芳樹 (Yoshiki Shibata)

                                                        出来上がったコードの可読性も含めた品質の悪さを、時間がなかったとかプロトタイプだからと言い訳する人がいます。スキルが高い人の場合は、同じ時間制約でも高い品質のコードを書きます。それは、ある程度無意識になるまで、訓練を重ねているからです。無意識になるまで意識して普段から活動するのです。 ソフトウェア開発ではないですが、熟練者と初心者の差を比較するために短時間でどれだけの成果が出るかを競うテレビ番組を時々見かけることがあります。必ず熟練者の方が量も質も圧倒的に初心者を凌駕しています。つまり、時間がなかったとかプロトタイプを言い訳にした時点で、経験年数に関係なく、初心者レベルだということです。 1988年に米国への赴任前の送別会で今は亡きS.Uさんに言われたのは、「与えられた仕事をこなして初めて次の難し仕事が与えられる」と言われたことがあります。逆に言えば、できないと判断されたら、仕事を与えない

                                                          初心者レベルの言い訳をしない: 柴田 芳樹 (Yoshiki Shibata)
                                                        • ITエンジニアの評価制度をどげんかせんといかん - ぐだぐだ言ってないでコードを書けよ、ハゲ。

                                                          私は宮崎出身ではありません。 目標管理シートドリブン開発はくそ - razokulover publog を読んで同意しました。 目標管理シートについて、私も感じる問題点と対策を挙げておきます。 (重複意見は抜いておきます) 事前にコミットするために目標の変更が利かない 表題のとおり。 ちょっとフィクションの話を。 半期の初めに目標設定をしました。 仮に「Ruby を業務で使えるレベルになる」とでもしましょう。 (この時点で別の問題もはらんでいるが、それは後述。) 少し勉強を重ねた1か月後、 Ruby が陳腐化しました。 実際 Ruby という言語自体のような手堅い目標であればいいでしょうが、 今さらそんな目標設定することはないでしょう。 登場したばかりの新しい技術を試してみることのほうが多いと思います。 しかしその技術は陳腐化する可能性があれば、 1か月後にもっといい技術が出てくる可能性

                                                            ITエンジニアの評価制度をどげんかせんといかん - ぐだぐだ言ってないでコードを書けよ、ハゲ。
                                                          • 実践API設計: 柴田 芳樹 (Yoshiki Shibata)

                                                            4月に発売された「WEB+DB PRESS Vol.134」で特集1「実践API設計」を執筆していますが、そこから部分的に紹介します(目次は、こちらです)。 第1章「優れたAPI仕様とは何か --- よくある問題と記述すべき事柄」の冒頭で次のように述べています。 今日、多くの企業がWeb サービスとしてさまざまなサービスを提供しています。Webサービスは、iOS、Android、ブラウザといったフロントエンドと、それらに対して機能を提供するバックエンドサービスから構成されます。バックエンドサービスが提供するさまざまな機能はAPI (Application Programming Interface)として定義され、フロントエンドから呼び出されます。フロントエンドは、バックエンドサービスが提供する機能を使ってユーザーへ提供する機能を実現します。 定義されたAPI を介することで、フロントエン

                                                              実践API設計: 柴田 芳樹 (Yoshiki Shibata)
                                                            • 「ベタープログラマ」を読んだ - Magnolia Tech

                                                              原著が出てたときから割と気になっていた「ベタープログラマ」を読んだ。 全体的な感想 第Ⅰ部はコードスタイルや、不要なコードの存在、テストコードを書く話など、非常に実践的な内容が多かった。 第Ⅱ部は割と考え方というか、思想的な話になっていって、第Ⅰ部をきちんと読んで危機感を持って行動を変えられる人であれば自然とそこに到達するのでは?と思った。 まずは第Ⅰ部をしっかり読んで、自分の置かれた環境との差異や、これから行動することを書き出す、みたいな読み方をすると良い。 第Ⅲ部以降は、もう完全に生き方というか、エンジニアとしての振るまいや、哲学の話になってくるので、一気に通読する、というより少し間を置いて拾い読みしながら読み進めて行くと良いかも。 流し読みしても全然役に立たないタイプの内容なので、読書メモは必ず書いた方がいいと思うし、書かれていることが万人にとって正解、といった類いのものでもないので

                                                                「ベタープログラマ」を読んだ - Magnolia Tech
                                                              • Java 歴 23 分の Ruby エンジニアが Effective Java を読んで感動した話 - scramble cadenza

                                                                イントロ 例外処理を書くことはよくやっているのだけれど、その時の主軸となる考え方について、今までなんとなくで行っていた部分が多かった。 毎回考えるポイントは例えば以下のような疑問。 どこのレイヤーで、どこまで例外処理を行えばよいのだろうか? どの例外をキャッチし、どの例外を伝搬させればよいだろうか? 前提条件をチェックし、失敗した場合、例外を出したほうがよいか、nil, false を返すほうがよいか? 例外をどういう単位でラップさせるのが良いだろうか? 例外をチェインし過ぎると却って煩雑になる気がする。どうすれば良いのだろうか。 しかし、この辺りの話って、API の設計だったり、仕様の影響もあるので、都度対応が異なってしまうもの。 したがって抽象化して理解することが難しく感じた。 とてもよく使ってるし、とても大事な事なことなのに。 そんな今更な事で悩んでいた時に、Effective Ja

                                                                  Java 歴 23 分の Ruby エンジニアが Effective Java を読んで感動した話 - scramble cadenza
                                                                • 初心者でもほぼ無料でJavaを勉強できるコンテンツ10選 - paiza開発日誌

                                                                  Photo by waferboard こんにちは。谷口です。 プログラミングをこれから学ぼうとしている方や、これから研修や実務に入る新人エンジニアの皆さんの中には「Javaを学習したい」という方も多くいらっしゃるかと思います。 Javaは、1990年代前半にサン・マイクロシステムズ(2010年オラクルにより吸収合併)でジェームズ・ゴスリン、ビル・ジョイらによって開発されました。 Java開発の求人は、これまでは金融関係のシステム(ATM等)などの比較的大規模開発案件が中心でしたが、近年ではAndroidのネイティブアプリ開発も増えてきています。 Javaを習得できれば、Webサービスだけではなく組み込み系やデスクトップアプリなど、大小さまざまなシステムで活用できます。OSに依存せず、ライブラリも豊富なので開発の幅が広く、有名なサービスではTwitterやEvenoteでもJavaが使用さ

                                                                    初心者でもほぼ無料でJavaを勉強できるコンテンツ10選 - paiza開発日誌
                                                                  • StringBuilderを使ったクソコードはどこまで遅いか - きしだのHatena

                                                                    ※ 4/9 11:25 いろいろ計測しなおしてます。こちらも参照 Javaで文字列連結する場合には+演算子よりもStringBuilderを使うべき、という話があるのですが、よく sb.append("[" + data + "]"); みたいなコードをみかけて、あんまり意味ないなーと思ったりします。 あと、 sb.append("title:"); sb.append("[" + data + "]"); みたいに、+演算子を使った一行の式にして sb = "title:" + "[" + data + "]"; としておけば「title:」と「[」はコンパイル時点で最適化されたのに、ってコードもあります。 ということでTwitterで Javaでの文字列連結は+を使うべき、ってやったほうが、StringBuilder使ったsb.append("[" + data + "]")みたいなク

                                                                      StringBuilderを使ったクソコードはどこまで遅いか - きしだのHatena
                                                                    • ソフトウェア開発組織が持つべきカルチャー(まとめ): 柴田 芳樹 (Yoshiki Shibata)

                                                                      2011年に主に書いた「ソフトウェア開発組織が持つべきカルチャー」を表にしてみました。評価列は、みなさんの組織ではどうかを振り返って記入してみてください。 ソフトウェア開発組織が持つカルチャーが、個々のソフトウェアエンジニアに大きな影響を与えるということで、一連の記事を書きますとした「まえがき」に相当するのが次の記事です。

                                                                        ソフトウェア開発組織が持つべきカルチャー(まとめ): 柴田 芳樹 (Yoshiki Shibata)
                                                                      • APIデザインの極意 - ✘╹◡╹✘

                                                                        APIデザインの極意 Java/NetBeansアーキテクト探究ノート 作者: Jaroslav Tulach,柴田芳樹出版社/メーカー: インプレスジャパン発売日: 2014/05/23メディア: 単行本(ソフトカバー)この商品を含むブログ (4件) を見る API設計は難しい "良い"APIを設計するのは難しく、APIの良し悪しを定量的に観測することは難しいとされている。後方互換性や拡張性、不具合の発生率などで曖昧に推し量ることはできるが、これは良い、これは悪い、とはっきり決め付けることは出来ない。そもそもAPIから「これ」と呼べるある側面を切り出すことも難しいと言える。また、APIの設計技法を学べる機会は多くないとしている。物事を感覚として認識することはできても、それを表現し他人に伝え信じてもらう方法を持たない場合が存在する。 API設計を芸術的取り組みにしてはいけない API設計の

                                                                          APIデザインの極意 - ✘╹◡╹✘
                                                                        • 文系学部生がSIerに入社してから読んだ本メモ - ギークに憧れて

                                                                          2013-04-01 文系学部生がSIerに入社してから読んだ本メモ 基本情報技術者連続不合格から一人前のエンジニアを目指す: 文系学部生がSIerからの内定までに心掛けたこと ちょっと前にこんなコラムが話題になって、心の中で「燃えろ〜よ燃えろよ〜」とか言いながら読んでたけど、よく考えたら自分も就活してた時は全然コード書いた事無かった。この人は何か思う所があって記事を書いたのだと思うし、少なくとも炎上狙いでは無い気がする。 4月から自分みたいに未経験だけどエンジニア目指したいって人もいると思う。そういう人はとりあえずTwitterとかGitHubで凄いエンジニアを追っかければいいと思うけど、最低限の教養として本読まなきゃダメっていうのはある気がする。とりあえず自分が読んでみて良かった本をメモ。 でも本読むのは最低ラインでその倍くらいコード書いてコード読まないと成長ないと思う。 心構え

                                                                          • 『プログラミング言語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言語研修では翻

                                                                              『プログラミング言語Go』翻訳作業が終了しました: 柴田 芳樹 (Yoshiki Shibata)
                                                                            • 2018年のアウトプットまとめ - t-wadaのブログ

                                                                              2018年は公私ともに忙しい年でした。このエントリを書いている時点でもう年が明けてしまいましたが、1年のふりかえりとして、またある種のポートフォリオとして、1年間のアウトプットをまとめたいと思います。 手元のスケジュールを確認したところ、講演/ワークショップを53回、インタビュー/対談/Podcast出演を5回、社内読書会ゲスト参加を3回、執筆、増刷作業を6回、主要OSSプロダクトのリリースを3回行っていました(小さなモジュールはカウント外)。これらが2018年のアウトプットです。 新作登壇(6回) 私は再演が多い講演者で、登壇依頼のほとんどは既存の講演/ワークショップの再演です。それでも2018年に新しいテーマの講演をいくつか行いましたので、それら「新作」がアウトプットの筆頭となるのではないかと思います。 技術選定の審美眼(2月15日) 2月15日に「技術の進化の歴史は振り子ではなく螺旋

                                                                                2018年のアウトプットまとめ - t-wadaのブログ
                                                                              • 達人出版会

                                                                                探検! Python Flask Robert Picard, 濱野 司(訳) BareMetalで遊ぶ Raspberry Pi 西永俊文 なるほどUnixプロセス ― Rubyで学ぶUnixの基礎 Jesse Storimer, 島田浩二(翻訳), 角谷信太郎(翻訳) 知る、読む、使う! オープンソースライセンス 可知豊 きつねさんでもわかるLLVM 柏木餅子, 風薬 R/RStudioでやさしく学ぶプログラミングとデータ分析 掌田津耶乃 データサイエンティストのための特徴量エンジニアリング Soledad Galli(著), 松田晃一(訳) 実践力をアップする Pythonによるアルゴリズムの教科書 クジラ飛行机 スッキリわかるサーブレット&JSP入門 第4版 国本 大悟(著), 株式会社フレアリンク(監修) 徹底攻略 基本情報技術者教科書 令和6年度 株式会社わくわくスタディワール

                                                                                  達人出版会
                                                                                • 『Android アプリ開発のための Java 入門』 を公開しました - ひだまりソケットは壊れない

                                                                                  『Android アプリ開発のための Java 入門』 というものを Gist で公開しました。 Android アプリ開発の勉強会を行うときに書いたものです。 Java をちゃんと使いこなすために知っておくべき必要最低限のこと をまとめたつもりですので、Android アプリを開発したいけど Java はほとんど知らない、みたいな人に読んでいただければと思います。 もちろん Android アプリ開発とは関係なく Java を学びたい人にも適していると思います。 Android アプリ開発勉強会のために書いた Java の入門文書 「Android アプリ開発のための」 というタイトルではありますが、基本的には Android アプリとは関係のない Java の基礎となっています。 この文書は次の書籍を参考に書きましたので、よりちゃんと学びたい人は下の書籍をご覧ください。 プログラミング

                                                                                    『Android アプリ開発のための Java 入門』 を公開しました - ひだまりソケットは壊れない