虚数の情緒、第１部独りで考えるために０章方法序説：学問の散歩道、読了 - 未来のいつか/hyoshiokの日記
数学の教科書をガッツリ読みたいプロジェクト (id:hyoshiok:20160312:p1) で最初に読む本は虚数の情緒―中学生からの全方位独学法にした。 中学生からの全方位独学法と副題がある。 1000ページを超える大著である。読む前からビビる。一気に流し読みにするというようなことはできない。途中で挫折した人もいる。一気に読むことができないなら、途中経過を日記に記すことにする。 数学の本は、読んで考えて理解して、読んで考えて理解することの繰り返しになる。読んでわからなければじっくり考える。じっくり考えてもわからなければもっと考える。それでもわからなければ、とりあえず、そこの部分はなかったことにしてもう少し先まで読む。そして考えて理解してを繰り返す。 理解したことをぼちぼちメモって自分の理解を確認する。メモを書いている時に疑問が湧くこともある。自分の理解が間違っていることに気がつくことが
エレベーターにパワーポイントはない。 There is no PPT in a elevator. - 未来のいつか/hyoshiokの日記
先々週は楽天テクノロジーカンファレンスだったので、enPiT PBLの土曜日の全体会議は欠席した。その欠席した会議にオブザーバーとしてJim Coplein (Copeと称する)が参加していて、それぞれのチームにフィードバックをしていたようだ。先日、楽天ハッカソンでスタッフをしていたら、ふらりとCopeが遊びに来ていて、ちょろっと雑談をした。 PBLのミーティングの感想を聞いた。 このPBLは約10週間でウェブサービスをチームで作るというもので、毎週土曜日にすべてのチームが集まって進捗報告をする。その会議では、今週やったこと、問題点、来週やること、デモなどを行う。そのミーティングにCopeが参加した。 各チームのGithub リポジトリのReadmeにはエレベータピッチが書いてある。最初にそのエレベータピッチを復習して、今週やったことなどを報告する。 エレベータピッチのテンプレートは下記に
SQLを作った人たち - 未来のいつか/hyoshiokの日記
リレーショナルデータベース管理システム(RDBMS)は言うまでもないことだけど、データベース管理の基礎中の基礎だ。NoSQLというRDBMSではないデータベース管理システムが出て来ているがそれもSQLがあってこそのNoSQLだ。 リレーショナルモデルはIBM E.F. Codd博士が提唱した。Edgar F. Codd - Wikipedia Codd博士は後にチューリング賞を受賞している。 http://en.wikipedia.org/wiki/File:Edgar_F_Codd.jpg そのデーターモデルを利用したデータベース管理システムのプロトタイプがSystem Rだ。IBM System R - Wikipedia 1974年ごろ発表された。 その成果の一つがSQLだ。誰でも使っているSQLはSystem Rの論文が発祥の地である。そしてその論文を読んでRDBMSを作った男がL
アジャイル開発手法特論が始まった - 未来のいつか/hyoshiokの日記
産業技術大学院大学のenPiTという講座で、永瀬さんと共同でやっているアジャイル開発手法特論の授業が今日から開始した。 この授業は事前学習科目という位置づけで、秋に開講予定のPBL (Project Based Learning) を実施するのにあたっての、前提となる知識やスキルをみにつける。ここでは座学でアジャイル開発手法を学ぶ。40人を超える受講者が集まって、昨年より遥かに多いのでちょっと大変かもしれない。昨年は10数人。琉球大学の学生さんもTV会議システムで遠隔地から参加する。TV会議システムの設定に手間取ってしまって、ご迷惑をおかけした。来週はもう少しうまくやりたい。 参加者のみなさんの自己紹介などを聞いた。各自、強い思いを持って参加されていて、その期待に答えるために全力投球をしないといけない。これからの半年間、楽しみである。 enPiT BizSysD – 産業技術大学院大学 e
詳細設計書ってよくわからない - 未来のいつか/hyoshiokの日記
わたしは、情報システムと呼ばれているものを作った経験がないので、よくわからないのだが、世の中には詳細設計書というのがあるらしい。 下記参照。 http://gm7add9.wordpress.com/2012/11/30/%E8%A9%B3%E7%B4%B0%E8%A8%AD%E8%A8%88%E6%9B%B8/ プログラムの詳細設計をやる人というのがいて、その人が書くらしい。あくまで自分には経験がないので、伝聞、想像でものを言っている。 プログラムの詳細設計というのは、プログラムへの要求仕様というのがあって、それを実現するために書くらしい。要求仕様というのは最終的な利用者が、こーゆーものが欲しいとか、こーゆーことができたらいいなということを、なんらかの方法で、なんらかの形でまとめたものらしい。 そんでもって、要求仕様を作る人と、詳細設計を作る人と、プログラムを作る人と、テストをする人と、
社内SNSを活性化するたった一つの方法 2011-08-25 - 未来のいつか/hyoshiokの日記
があれば苦労しないよね。 昨日EGM Summitなるものに参加した。ここでEGMとはEmployee Generated Mediaのことで、社内ブログ、掲示板、SNSのようなものらしい。 弊社はYammerというTwitterのようなものを社内SNSとして利用している。全社的に春頃から導入しているのだが、無償版を随分前から有志が勝手に導入して利用していた。 社内Twitter的なものとしてSalesforceのChatterというのを試験導入したのだが、まったく普及しなかった。閑古鳥がないていた。営業でSalesforceを日常的に使用している人ならともかく、つぶやくためにわざわざログインするということの敷居の高さを越えられなかった。 一方でYammerは、Twitter的な機能だけではなく、Facebook的にスレッドがまとまって表示されたり、likeボタンがついていたり、写真やファ
Innovation Sprint 2011 に参加した - 未来のいつか/hyoshiokの日記
Innovation Sprint 2011に参加した。コミュニティによる価値の創造の一旦を垣間見た気がした。http://innovationsprint.com/ みたままに記す。 川口さん(@kawaguti)がスクラムの父ジェフサザーランドと祖父野中さんを呼んでカンファレンスをしたいと考えているというのを聞いたのは勉強会カンファレンス2010の時だったと思う。おお、いいすね。と適当に答えていたと記憶している。平鍋さん、ピークワン代表の前田さんらが動いて野中さんをひっぱりだし、川口さんが、ジェフとコンタクトをとったようだ。*1 平鍋さんと楽天の田澤さんはIPAの非ウォーターフォール研究会（名前？）の縁で、正式（？）には平鍋さんから田澤さんへの依頼が夏頃にあった。すぐに田澤さん経由で、こんな話が来ているんだけどどうよと来たので、やりましょうよとノリで答えた。 わたしに出きることと言えば
勉強会カンファレンス2010に行ってきた - 未来のいつか/hyoshiokの日記
勉強会カンファレンス2010*1に行ってきた。そこでの感想など。 勉強会のメソッドは勉強会の数だけある。共通の問題もあればその勉強会固有の問題もある。それぞれの問題を出し合って、みんなでその解決策を議論するという方法は大変有効な方式だと再認識した。 最後のセッションで、岩切さんが、自分の困っていることをプレゼンしていて、そこからいろいろな議論が湧き上がってきて、非常に盛り上がったが、あんな感じのセッションがわたしにとって理想的な形だと思った。 岩切さんの困っていることというのは、ざっくり言うと、カンファレンスを開いても一列目、二列目の人たちは、笑いもしないし、ぴくりとも動かないし、隣の人といきなり話を始めて、何かを持ち帰っていこうというような感じの人がほとんどいない。それを聞きにくる人を巻き込んで、何かをしたい、だけど日本人だからそれができないかというと、DevLOVEなんかにいくと、とっ
テストを書くこととテストをすることの違い - 未来のいつか/hyoshiokの日記
会社でレガシーコード改善ガイドの読書会をやっていて、次回で読了だ。4月に入ってから週に1回くらいのペースでやっていて、2ヶ月半くらいかかった。途中、ゴールデンウィークや所用で開催しないこともあったので、１０回くらいで完走したことになる。 一人当たり、1章ないし2章くらいを担当して、その章に書いてあることを説明した後にみんなであーだこーだ議論をする。気になったことを質問したり、どうも良く分からないことをみんなで考えたりする。 テストがないコードはレガシーコードだ！というキャッチフレーズはわたしの心をとらえた。 参加者の皆さんとその価値観を共有できた事はうれしい。 現場での開発の実情をいろいろ教えてもらった。テストを書くことはあまり一般的ではないということにわたしは衝撃を覚えたのであるが、この読書会を通じて、テストを書かない開発というのがレガシーコードを作っている事に他ならないという共通の認識
自分にとっての情熱プログラマー - 未来のいつか/hyoshiokの日記
先日、情熱プログラマー読書会が楽天であったので、参加した。LT(Lightning Talks)で発表もした。発表スライド 情熱プログラマー 自分にとっての情熱プログラマーってなんだろうと考えた。 この「情熱プログラマー」という書籍は、ソフトウェア開発者の幸せな生き方という副題がついているのだが、純粋な技術書というよりもプログラマーにとっての自己啓発書みたいな位置づけの書籍だ。 ソフトウェア開発におけるプログラマという役割を取り替え可能な部品のような立場から見れば、プログラマはコストであり、どのようにしてそのコストを削減するかということになる。コストを安くするという考えで行けば年功序列的な賃金体系の中ではベテランより若いひとを使った方が安く上がる。数字でソフトウェア開発を見ていけば人月工数がすべてであり、開発コストは工数＊人月単価になる。 そのような立場で言えば人件費の高い日本で開発するの
楽天で角谷さんのお話を聞いた - 未来のいつか/hyoshiokの日記
解読アジャイルソフトウェア開発というタイトルでお話をしていただいた。*1 アジャイル開発の本質を角谷節で1時間あまり独演会してもらった。 Demystifying Agile Software DevelopmentView more presentations from Eiwa System Management, Inc. . ともかく映像を観てほしい。約1時間ちょっと、そしてその後に続く質疑応答も一緒に。 ソフトウェア開発における受託開発という立場ではない、もう一つのソフトウェア開発の現場が、自分のサービスを自分で作るという立場だ。 受託開発の場合はユーザー企業（発注する側）と開発する企業（受託する側）とがあって、時として敵対関係に陥る。一方の利益が他方の損というゼロサムゲームである。 自社開発の場合は、社内にユーザ部門と開発部門があったとしても、最終的にはユーザ部門の利益と開発部
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
