*（アスタリスク）がワイルドカードとして使われるまで - @ledsun blogを公開したところいくつか新情報をいただきました。 サマリ 1951年、スティーヴン・コール・クリーネが正規表現の閉包演算子として*を生み出す。 1965-1969年のどこか、Multicsに*をワイルドカードとして導入 1969~1971年あたり、デニス・リッチーがUNIXのglobにワイルドカードを導入 ケン・トンプソンとデニス・リッチーはMulticsプロジェクトに参加していたので、そこからワイルドカードをUNIXに輸入したようです。 *（アスタリスク）がワイルドカードとして使われるようになったのはMuliticsプロジェクトのどこかのようです。 DEC TOPS-10ルートもあるかもしれません。情報お待ちしております。 寄せられた情報 ちなみにglobを書いたのはKen ThompsonではなくDenn

みんな良いこと言うので、刺激を受けて考えたことを記録します。 生きてるだけで丸儲け ストレス対処法 撤退戦術 タスク殺すマシーン 人間に戻る儀式 運 技術力を身につける方法 車輪を再発明する 脱ゴールデンハンマー病 学習の助 優秀なプログラマとは？ おまけ 生きてるだけで丸儲け 優秀なプログラマーになるためのコツ · GitHub 優秀なプログラマーに「育つ」んだし、それには時間が必要 優秀なプログラマーになるということは、上記の通り長時間を要するということも踏まえると、メンタルヘルスにリスクがある環境に長時間暴露されることが不可避である 業界で長きにわたり活躍し続けている人というのは、それだけですでにひとかどの人物 すごく良いです。 優秀なプログラマになる前に、死んでしまっては元も子もありません。 生き延びることはなにより大切です。 幸か不幸か現状のIT業界はハードなストレスにさらされや

サマリ 謎のモチベーションの高まりにより技術同人誌を書いた 30部が1.5時間ではけた Re:VIEWで書いた 想定読者が勉強会の発表より広いのはおもしろい 書いたこと 「デバッグ最速理論」という薄い本を書きました。 最終的に表紙と奥付、裏表紙等を合わせて16ページになりました。 原稿はこんなです。 当初の野望は カラー表紙 32ページ オフセット（？）印刷 でした。 3月の執筆時間が思っていたより取れなかったので、執筆時間をギリギリまで稼ぐためにコピー本に倒しました。 深夜に、コピー機でガッションガッション印刷して、ホッチキスでバッチンバッチン留めて作りました。 「デバッグ最速理論」自体は、今のところ16ページで十分表現できています。 もうちょっとデバッグ初心者や非技術者に間口を広げようと思ったら、ページ数を増やして 導入章を増やしたり、図表を増やした方がいい気はします。 部数について

1on1ミーティングに備えるアンケート - しるろぐ を読みました。 大変参考になりました。お礼の代わりに、弊社のやり方を書きます。 前提条件 弊社は20人以下のSIerです。 受託開発や技術支援がメインです、プロダクトを中心とした面談ではありません。 インタビュワーとインタビュイーの組み合わせはプロジェクトに閉じていません。 総当たりで組み合わせています。 面談をはじめたのは退職者対策としてでした*1。 インタビュワーの負担が個人に偏らないように、ベテランエンジニアが全員インタビュワーになります。 やり方 人数 インタビュワーは6人います。ベテランエンジニア5人と営業1人です。 インタビュイーは8人います。 1年目は毎月、それ以外のエンジニアは2ヶ月に一回実施指定います。 組み合わせ もっとも長い期間面談をしていない組み合わせで実施します。 組み合わせは、モンテカルロ法で抽出します。 そ

d.hatena.ne.jp 椎葉さんの発表がぐっときた すごかった。 「失敗したチームメンバーがいた時に、笑ったらいかんよ」と説明すると言っていました。 「そこまでやるのか。やると意味があるのは想像できるけど、自分ではできない」という意味ですごかったです。 懇親会で聞いてみました。 実際の説明はもう少し丁寧に「悪気がなくても、思っているのとは違う伝わりかたをするので気をつけてね」 とするそうです。 なんでそこまでやるのか？ 「自分が抜けた後も、走る続けられるチームを作りたい」からだそうです。 自分とは立場が違うので無理して真似る必要はなさそうです。 （「チョットデキル人に訊け！」の話題と関係しています。） track8さんの発表が面白かった 想像できない使用環境に起因するバグをどうやって想像すればよいのか？という話でした。 純粋に楽しめました。 「チョットデキル人に訊け！」が興味深い 「

結論 事例：クラウドワークス クラウドワークスは発注者のためのサイト 中間業者中抜きへの期待 先人の失敗 絵や音楽 伝統工芸 価格維持力が失われる 中間業者が必要な構造 クラウドワークスの価格低下構造 受注者は増える 価格下げ圧が強すぎると市場は縮小 中間業者の機能1 参入障壁（受注者のフィルタリング） 中間業者の機能2 案件のバッファリング クラウドワークスさまへのご提案 参考リンク 結論 中間業者を中抜きは不可能。よりよい中間業者による代替えを目指そう 事例：クラウドワークス crapp.hatenablog.com にて、受注者側から見たクラウドワークスの問題点が挙げられています。 クラウドワークスは発注者のためのサイト クラウドワークスとは、そもそもエンジニアの為に作られたサイトじゃなく、むしろクライアント(発注者)がエンジニアを安く買い叩くためのサービスに過ぎなかった また 発注

プログラミングの学習曲線 プログラミングで世界を変えるということ 職業プログラマのすすめ Ruby on Railsの複雑度が問題？ プログラミング研修の限界 まとめ プログラミングの学習曲線 Ruby on Railsはプログラミングではない！ | それでも人は夢を見るの話です。 Ruby on Railsの有料講習を受けたが、受講前にイメージしていたプログラミングと、受講後の自信の能力のギャップに驚いている方の話です。 これは学習曲線の問題な気がします。 自分がプログラミングの勉強を始めた頃の話です。 入門書を読みながら、Perlをぽちぽち入力して掲示板CGI動かしてみました。 ですが、その次にどうすれば、イメージしているプログラミングに近づけるのかわかりませんでした。（その時は）挫折しました。多分、元記事の方も同じような状態なのだと思います。 一つの課題をクリアしたものの、次に何をす

RDB - DELETE_FLAG を付ける前に確認したいこと。 - Qiita 論理削除が云々について - mike-neckのブログ Kazuho's Weblog: 論理削除はなぜ「筋が悪い」か 流行っているので乗っかります。 結論 「データ制約の強力さと集合としての表現力を捨てながら、Relational Databaseを使うのはなぜか？」 論理削除フラグのデメリット 大体三つあると考えています。 ユーザーの言葉でない データ制約の弱さ 集合として認識できない ユーザーの言葉でない 私の経験上は、ユーザーから「論理削除」という言葉を聞いたことがありません。 次のような要件は、聞いたことがあります 社員が退職（・転属）する （売掛金の回収を諦めて）売上を打ち消す 「お知らせメッセージ」を公開日がくるまで非表示にする 既読メッセージを表示しない 保存期間が過ぎたアンケート結果をオペレ

咳マニアの集うイベント とてか03 にて発表してきました。 発表は「忍者式テスト」についてです。 忍者式テストは2004年頃に咳さんが発表されてから（咳さんチーム以外の）実施者が一人しか観測されていないテスト（開発？）手法です。 私が忍者式テストに取り組んだ経緯と、やってみてどうだったのかの感想をしゃべってきました。 Ninja Testing at Toteka03 from Nakajima Shigeru 関連資料 The Model-View-Controller (MVC) Its Past and Present ステートフルJavaScript ―MVCアーキテクチャに基づくWebアプリケーションの状態管理 MVP: Model-View-Presenter The Taligent Programming Model for C++ and Java MVCとかMVPとかし

刺激を受けました。 個人的な思いを書きます 後出しじゃんけんです。 寝言です。 価値観 「初期費用が無料だから私たちは本気です」という価値観はあまり好きではありません。 「斉藤浩司＠帯をギュっとね」メソッドや「苦しければ報われる欺瞞」に近いものを感じます。 お客にリスクを負ってもらって、それに報いる方がより本気のように感じます。 商売として お金は商売の血液 1000万円の資金を全額、保証金としてロックするのは商売として考えると微妙です。 商売お金をお客様とそのお客様と自分たちと協力会社と・・・の間を血液のように流す活動のことです。 バッファとして30%ほどをプールするのは良いですが、100%プールするのはいけません。 脾臓に血液を貯めても全身に巡らなければ死んでしまいます。 *1 気が長い 2,3年続かないとペイしない契約で、 成り立つのはファンドや保険などの数百〜万契約を束ねられる商売

忍者式テストを二週間くらいやってみた感想です。 忍者式を見習って毎日一時間手動受け入れテストの時間を確保してみた。 「受け入れテストを徐々に増やしていく」感覚が新鮮。 「受け入れテストはテストフェーズの最初に一度に作るもの」は思い込みだった。— ぎゃばん (@ledsun) 2014年6月27日 忍者式テストとは 那須のKent Beckと呼ばれる隠者が発明（発見？）したテスト手法。 特徴をあげると 毎日、手動でテストを行う テストをペア作業で行う 実施のたびにテスト項目を見直す テスト項目の粒度は受け入れテスト 初めてこの手法を知ったのは2005年だったと思います。 当時、自社開発ソフトウェアの結合試験の真っ最中でした。 「バグの発見漏れは減るだろうけど、どうやって導入すれば？？？」と、 使えそうなのに手が出せなく、もどかしい思いをしました。 導入方法の謎 何年経っても導入方法が分からな

我が輩のTDD体験を語る 背景 ここ最近のTDDに関する話の噛み合なさっぷりよ・・・ TDDは死んだ。テスティングよ栄えよ。 by DHH 【翻訳】TDD is Fun 【TDDを再定義したほうがいいって話だったのさ】UncleBob, Martinfowler, DHHのツイートまとめ TDDという名の幻想... 大きな疑問 業務でxUnit使ったテストファーストやってる人はいるの？ TDDは死んでないと言うても、業務でxUnit使ったテストファーストやってる人はいるの？ じゃあ、自分はどうなのか？自分語りをする。 前提 ここで話すTDD xUnitを使ったテストファースト 今回はそれ以外を話さない XPの第一版にはそれ以外の要素は書いてなかった。 俺はそう刷り込まれた。 一番大事だと思う要素から話す。 「これからインスピレーションを得たもっといい方法があるよ」って話は喜んで聞きます。

オブジェクト指向という言葉には オブジェクト指向分析(OOA) オブジェクト指向設計(OOD) オブジェクト指向プログラミング(OOP) の三つの意味があります。 オブジェクト指向初心者泣かせです。 ここではオブジェクト指向設計を説明します。 ソフトウェアの設計 ソフトウェアの設計には二つの側面があります。 作成するソフトウェアの共通部分を探し出しモジュール化する 作成するソフトウェアが将来変更される部分を抽象化し変更しやすくする 一つ目のモジュール化は構造化設計からある手法です。 オブジェクト指向設計で特に取り上げる点はありません。 ここでは二つ目の将来の変更のために抽象化することに重点を当てます。 オブジェクト指向設計 オブジェクト指向設計とは多態を実装する部分を決めることです。 多態とはオブジェクト指向言語を活用した次のものです。 変更可能な点に抽象クラス*1 （オブジェクト指向言語

技術者が1~3年目で成長するかは自習するかに依存してる。業務とは別に勉強する方法を叩き込めば誰でもそれなりに出来るようになる。 そんなわけで僕の所属している会社では年に5冊指定した本を読ませてレポートを書かせている*1。 なぜレポートを書かせるか 僕の所属している会社が採るような大学生は自習しない。分からないことや知りたいことがあっても本を買わない。業務をやるうちに実地で学べることはあるのだけど、実際に自分がやっていることが世間でどれくらいの位置づけなのか知っておくとなお良い。理想的な手法が使えているのか、それとも現場に合わせて翻訳して使っているのか。本に書いてあることと一致していれば普遍的なことなので覚えておけばいいし、書いていないことをやっているなら、下手をうっているか、現場に合わせた調整をしたかどっちか。そういうことを知っておくと違うプロジェクトに移ったときに同じ名前でちょっと違うこ

勉強会 最近よく耳にする言葉「リーンスタートアップ」が気になってLeanStartupNight - Eternal Rotation! - - DevLOVEに参加してきました。 本は未読。帰りにアマゾンで買いました。 今日の理解 ビジネスモデルの研究 リーンスタートアップは「ビジネスモデルの研究」。R&D（研究開発）のDのプロセスを整理したもの。 ビジネスモデルの仮説「ある人が抱えているある課題を解決すると儲かる」を検証する作業。 「商品を作る」から商売の一部だと考えがちだけど、あくまで研究開発。 アジャイルとの相似 リーンスタートアップ：仮説を机上だけでなく商品を作ってユーザに使ってもらって検証する。 アジャイル：設計を机上だけでなく実装してリリースして確認する。 どちらも繰り返し行うが、テーマ・領域が異なるので同じものではない。 図にまとめるとこんな。 感想 リーンスタートアップの

一人当たりの平均月間売上と、新卒月給と昇給をどう設定すると黒字になるか計算してみた。 結論 当たり前だけど、給料は一人当たりの売上で決まる。 月60万ではワープワ街道まっしぐら。100万円無いと年収500万に届きません。 貧乏 一人当たりの平均月間売上(万円) 60 新卒月給(万円) 20 年昇給ペース(円) 5000 10年目年収(万円) 294 普通 一人当たりの平均月間売上(万円) 80 新卒月給(万円) 25 年昇給ペース(円) 10000 10年目年収(万円) 408 高給取り 一人当たりの平均月間売上(万円) 100 新卒月給(万円) 30 年昇給ペース(円) 15000 10年目年収(万円) 522 仮定 計算にあたっての仮定 昇給ペースは一定*1 4年目からは個人の累積で黒字になること*2 1〜3年目の売上貢献度 1 30% 2 60% 3 90% 年収と人件費の倍率 2倍

残業の話題がとっても盛り上がっているので参戦。 残業を悪とするチームを作るだけでは全く足りない - Change The Worlds 残業をしない会社を作るために - GoTheDistance 残業を悪とするチームを作ろう - ひがやすを blog 長時間労働・サービス残業は自分の価値を下げ企業存続を危うくする | Act as Professional - hiroki.jp by HIROCASTER ここで考えるのはSIerにてエンジニアの残業を無くす方法です。残業を無くすには労働生産性を上げればよい。労働時間が月184時間以内で売上が今と変わらなければ、給料を上げない限り残業は無くなる。さてSIerにて労働生産性を上げるには？ サービス業としてのSIerの場合 二次請け以下の受託開発と人材派遣型のSIerはサービス業です。売上は労働時間単価の積み上げ、実にシンプルです。 売上

ツイッター向けのコンテンツフォーマットについて、IT系最強かあちゃんの呟きを例に解説してみましょう。 たかしへ たかしの書いたソースコード読みました。コメントにメソッドで実現したいことが書いてあり大変読みやすいです。設計上の判断も書いてあってとてもよいです。「○○しようと思ったけど、デメリット××があったからやめた。」というコメントは修正するときに大変役立ちます。— ぎゃばんぱみゅぱみゅさん (@ledsun) 3月 23, 2012 起承転結 ツイッターといば140文字制限が最大の特徴です。しかしその中にも起承転結があります。 たかしへ たかしの書いたソースコード読みました。 コメントにメソッドで実現したいことが書いてあり大変読みやすいです。 設計上の判断も書いてあってとてもよいです。 「○○しようと思ったけど、デメリット××があったからやめた。」というコメントは修正するときに大変役立ち

「僕が社内ライブラリを OSS 化すべきだと思う3つの理由 - 鳩舎」に、はてなブックマークでコメントをしたら、回答が返ってきたので再返信。公開には賛成です。変な理由付けが気に食わない。で、どうやって公開するか？ 自分でやればいい 「公開したいけれど責任は取りたくないです、上司さん代わりに取って下さい」ってお願いしたら、そりゃあ「メリットあんのかよ？リスクは？」って聞かれる。上司が責任を取らなくていい形で、公開すればいい。「OSS として公開するのはいいことだ」って覚悟が！「言葉」でなく「心」で理解できてれば公開するだけだッ！ 「許可を求めるな謝罪せよ」という話。厳密には、就業時間中に作成したソースコードの著作権は作成者だけのものではない。雇用者の合意を取らずに公開するのはグレー*1。だけどOSSライセンスで一回公開したらフォークは止められないので、既成事実化する。実害がなければ処罰のしよ

プログラマは勉強し続ける職業です。本を読みましょう。 誰に？ 対象とする人 仕事でWebアプリケーションの一部を作ったことがある 仕事でSQLを書いたことがある 対象としない人 一人でWebアプリケーションを作れる DBの論理設計ができる 5冊の本 デバッグルール 楽々ERDレッスン ノンデザイナーズ・デザインブック プログラムはなぜ動くのか 体系的に学ぶ 安全なWebアプリケーションの作り方 デバッグルール プログラム自体は書けるのに依頼された仕事をこなすのに諸先輩に比べると時間が掛かることがあると思います。掛かっている時間の内訳をみると、プログラムを書くことより書いたプログラムが動かなかった時の原因調査に時間が掛かっていることが多いです。何故時間がかかるのでしょうか？エラーメッセージでググって上手い事解法を引き当てるか、コードを適当に変更して正しく動くことを祈るぐらいしかできないからで