Author:くるぶし（読書猿） twitter:@kurubushi_rm カテゴリ別記事一覧 新しい本が出ました。 読書猿『独学大全』ダイヤモンド社 2020/9/29書籍版刊行、電子書籍10/21配信。 ISBN-13 : 978-4478108536 2021/06/02 11刷決定 累計200,000部（紙＋電子） 2022/10/26　１４刷決定 累計260,000部（紙＋電子） 紀伊國屋じんぶん大賞2021　第３位 アンダー29.5人文書大賞2021 新刊部門 第１位 第２の著作です。 2017/11/20刊行、４刷まで来ました。 読書猿 (著) 『問題解決大全』 ISBN:978-4894517806 2017/12/18 電書出ました。 Kindle版・楽天Kobo版・iBooks版 韓国語版 『문제해결 대전』、繁体字版『線性VS環狀思考』も出ています。 こちらは１０刷

自動改札機の運賃計算プログラムはいかにデバッグされているのか？ 10の40乗という運賃パターンのテスト方法を開発者が解説（前編） ふだん何気なく使っている鉄道。改札を降りるときにICカードを自動改札にかざすと、「ピッ」という音と共に一瞬のうちに運賃を計算してくれます。けれど、複数の路線を乗り継いだり、途中で定期券区間が挟まっていたりと、想像しただけでもそこには膨大な組み合わせがあります。それでも運賃計算プログラムはわずか一瞬で正しい運賃計算が求められ、バグがあったら社会的な一大事にもつながりかねません。 爆発的な計算結果の組み合わせがあるはずの運賃計算プログラムは、どうやってデバッグされ、品質を維持しているのでしょうか？ 9月12日から14日のあいだ、東洋大学 白山キャンパスで開催された日本科学技術連盟主催の「ソフトウェア品質シンポジウム 2012」。オムロンソーシアルソリューションズ 幡

◯仕掛けのあるバスタブ 少女：わー、ちっちゃいお風呂。禁煙さん、それ何ですか？　ドール・ハウスの？ 禁煙：ああ、これ。ううん、教材。友達に作ってもらったの。 少女：小さい蛇口もついてるんですね。……教材って何の？ 禁煙：小学生に微分方程式を体験してもらう教材なの。 少女：ええっ、微分どころか方程式も習ってないんですよ。 禁煙：むかしシーモア・パパートって人も、数学をさんざん習わないと微分方程式にたどり着けないなんてダメすぎる、小さい子どもこそ味わうべきなんだ、といつも言ってたわ（それでＬＯＧＯってコンピュータ言語を作ったのだけど）。 少女：じゃあ、私にも分かりますか？ 禁煙：試しに遊んでみる？　デジタル表示が三つついているでしょ。 少女：はい。〈入る蛇口〉と〈出る蛇口〉と、あと〈バスタブ〉って書いてあります。 禁煙：〈バスタブ〉の数字は、文字通りバスタブに今入っている水の量を表してるの。〈

コンピュータ将棋を理解する上で、大事なことの一つにマルチコアというのがあります。皆さんのお手元のPCや最近ではスマホも当たり前のようにマルチコアになってきています。ところで皆さんがマルチコアと言っているものはどんなものなんでしょうか？ CPUというのは、コンピュータにとって頭脳と言えるものです。下の画像はCPUの一種類インテルCorei7です。皆さんはこういうものが幾つか繋がってマルチコアとなっていると想像してませんか？ CPU Corei7 画像のものは４コアCPU こちらより画像を引用 実はこの中にすべてのコアが含まれているます。中の画像を説明付きの画像を見てみましょう。中にCore（コア）と書かれた部分が４つ見られると思います。４コアと言われていても、別々に分かれているわけでもなく同じ基板上にプリントされているわけですね。 内部アーキテクチャ 共有メモリ（L3キャッシュ）が意外と大き

（2015/09/01追記：この記事は私がW社に在籍した2013年4月から2014年4月までの間の個人的な経験に基づくものです。就職の参考にされる方は、その後W社の社風や開発者の扱いに変化があったかどうか等についてご自身で最新の情報を得ていただければと思います。） （2019/08/17追記：社名を「W社」に置換しました。） 記事タイトルの通り、W社を退職したので、退職エントリを書く。 （最近雑文に対していろいろと予防線を張ることが流行っているらしいので、一応これもポエムだと書いておく。役に立つことは書いていない） 今日が最終出社日だった。 ちょうど 1 年ぐらい勤めたことになる。 2 社連続で 1 年で辞めたことで、自分が社会不適合者であることが誰の目にも明らかになってしまった。 これから先の人生の見通しは暗い。 その間に子供が生まれたのだが、不憫でたまらない。 いい話というのは、Goo

今日何気なく呟いたツイートが、見ていたら結構RT&favされていた模様で。 社会人が統計学とか機械学習を独習するには、いわゆる「落下傘方式」が良いと思う。必要な時にその項目だけ学んで実践する。その繰り返しで学問体系のマス目が埋まっていけば良し。あと、初めに体系立ったテキストを分からなくても良いので通読するのも良し。だいたいの地図が頭に入る。— TJO (@TJO_datasci) 2014, 3月 31 この後も色々補足で呟いたんですが、せっかくなので簡単にまとめたものを書いてみました。これから社会人で統計学や機械学習を学ぼうと考えている人の参考になれば嬉しいです。 あ、これはベタな言い方をすれば「データサイエンティスト（死語）になるにはどうしたら良いか」にもつながる話なんですが、ここではもっと広く「統計学や機械学習を使う仕事をしたいと思ったらどう独習するべきか」という話にしておこうと思い

私は、請負契約のプロジェクトでチームリーダーをかれこれ6、7年やっています。 いままで私が携わったプロジェクトは非常に苦しい思い出も多く、常に試行錯誤の毎日。 そして日々、小さな成功とそれより少し大きな後悔が交互するような開発者ライフを送ってきました。 私が所属している組織の利益の源泉はソフトウェア開発者をお客様の元へ請負常駐という形で送り出すというものですが、細々と社内で請負プロジェクトの開発を行っており、私は客先に出向いたり社内に戻ってきたりを繰り返しながら近年は概ね社内で請負プロジェクトのリーダーをやるという感じです。 私が携わってきたプロジェクトは規模も期間もお客様の業務要件も様々。 その都度まったく異なる事象との戦いで過去の経験が役に立たない場面も多く、苦悩と共に損失を出しつつ、たまには利益を出したりしながらこなしてきました。 技術的要件のプライオリティが毎回変わるため、ある時は

あれは、僕がデータベースを扱ううち最初から３件目のプロジェクトだった。 C++のソースが難解で火を吹いているという話で、自分は低スキルの若造。火にくべるには丁度良い程度のやる気と責任感をもっていた。折悪く別のプロジェクトが終了した直後だったもので投入されたのでした。 現場で『DBからデータを吸い出すツールかSQLを作ってくれ』といわれ話をきくと他社が作ったDB定義がすこぶる使いづらいという。 ER図やDB定義を見せてくださいと言ったのだけど、そんなものは無いという返事。 今ならもうここら辺で逃げ出すところですが、当時は『ふーん。』てなもんでそういうこともあるのかくらいの軽い気持ちで考えていました。 で、プロジェクトの資料をあさりまくって何とかDB定義のようなものも見つけDBのデータを調査し始めたのですが何かがおかしい。 機能の数に比して異様にテーブル数が少ないのです。 ふと周りを見ると、皆

「HRTの原則」という言葉をご存知だろうか。 これは書籍 Team Geek ―Googleのギークたちはいかにしてチームを作るのか で紹介されている言葉であり、本書ではほぼ一冊すべてをかけてこのHRTの原則とその実践方法とを様々な角度から紹介している。 1. 謙虚(Humility) 2. 尊敬(Respect) 3. 信頼(Trust) の3つの価値が大切にされており、エンジニアとしてもチームや組織、顧客との対話においてこれらの価値を重んじていくことが成功につながる、というものである。 あらゆる人間関係の衝突は、謙虚・尊敬・信頼の欠如によるものだ Team Geek p.15 プログラマとして成功するには、最新の言語を覚えたり高速なコードを書いたりするだけではいけない。プログラマは常にチームで仕事をする。君が思っている以上に、チームは個人の生産性や幸福に直接影響するのである。 Team

ソフトウェア開発の品質・効率向上に欠かせないレビュー。しかし、やり方を間違えているために、かえって逆効果になっているケースが多い。本連載ではソフトウェアレビュー研究の第一人者、森崎修司氏が豊富な現場経験と研究成果を基にレビュー成功のポイントを分かりやすくリアルに解き明かす。 なぜレビューがうまくいかないのか？ ソフトウェア開発の品質・効率向上が求められている今、ソフトウェアレビュー（以下、レビュー）の重要性はますます高まっています。商用開発では「要件定義」「設計書」「ソースコード」「テスト計画」「運用手順書」などを対象としたレビューが行われていますし、オープンソースソフトウェアのプロジェクトでも、ソースコードリポジトリへのチェックインの前にソースコードレビューを推奨したり、義務付けたりしています。 しかし、レビューは自由度の高い活動です。レビュー会議では本質的な欠陥や問題を指摘しても、欠陥

あなたが現役のエンジニアならば英語から逃れることは出来ない。エンジニアというプロフェッショナルな職業を選択した以上、自分の職業に誠実になるならば、学び続けなくてはならないし、その場合、英語を避けて通ることはできない。 まあ、50代以上で、もう引退だとか言う人であれば、ぎりぎり逃げ切るということは不可能ではないかもしれないが、それは現役エンジニアというカテゴリではないので、除外する。もちろん、50代だろうが60代だろうが現役であるならば英語から逃れることはできない。 少なくともインターネットの業界とかIT業界とかそーゆーところで飯を食っている人であれば、ほとんどすべての情報は英語でやり取りされていて、一次情報の質と量については英語のそれは日本語それを圧倒している。もし、そのような認識を持っていないとしたら、それはそれで相当ヤバいと思う。 もちろん英語を学ぶとか学ばないとかは余計なお世話である