技術の進歩は「螺旋」である。 @ t_wada さん社内講演 - >& STDOUT
先週、新卒技術研修の一環として @t_wadaさん にご講演を頂きました。 題して「この先生きのこるためには」*1。 第一線のエンジニアとして素晴らしい薫陶の数々を授けて下さいましたので、渋谷や六本木の会社さんもオファーしてみたほうがいいですよ。ホント。 エンジニアはアーティストとしての側面も持つので、ファーストクラスの方の考え方に早いうちから触れておくことは、数年先の彼らの在り方に少なからず良い影響を与えるはずだ、という考え*2に基づくおふたりめの社外講師です。おひとりめは当時非公開でしたが、時効になってましたら教えてください。 新卒研修とはいうものの、社食のカフェテリアを全開放した形で既存社員にも受講してもらいました。正直、私も含めた既存社員のほうがよっぽど直接の教育効果は高かったんじゃないかと思いましたが、それはそれとして。ご講演の中でのいくつかの気づきを共有します。 技術の進歩は「
【翻訳】TDD is Fun - diskogs's diary
@solnicが、DHHの例の記事へのカウンター的な記事をポストしてまして、自分のために読んでみたらよい内容だと思ったので、翻訳してみました。翻訳ミスとかあると思いますが、、、すみませんです。。。 TDD is Fun Posted by solnic on Apr 23 2014 著 solnic 2014年4月23日 Today DHH published a blog post about TDD being dead (to him at least). It’s really not that surprising since from what I know (please correct me if I’m wrong) David’s experience is mostly based on building web apps with Rails. I get that
TDDは死んだ。テスティングよ栄えよ。 by DHH | 2014-04-24 - やっとむでぽん
DHHの"TDD is dead. Long live testing."を、訳してみました。 翻訳 やっとむ By David Heinemeier Hansson on April 23, 2014 著 David Heinemeier Hansson 2014年4月23日 Test-first fundamentalism is like abstinence-only sex ed: An unrealistic, ineffective morality campaign for self-loathing and shaming. テストファースト原理主義は禁欲のみを唱えた性教育のようなものだ。つまり、自己嫌悪に陥っている人に向けた、非現実的で効果のない、道徳教育のようなものだ。 It didn't start out like that. When I first disco
TDD is dead. Long live testing. (DHH)
By David Heinemeier Hansson on April 23, 2014 Test-first fundamentalism is like abstinence-only sex ed: An unrealistic, ineffective morality campaign for self-loathing and shaming. It didn't start out like that. When I first discovered TDD, it was like a courteous invitation to a better world of writing software. A mind hack to get you going with the practice of testing where no testing had happen
オープンソースは報われない仕事。でもやるんだよ。 - 平々毎々（アーカイブ）
Microsoftの中の人で、OSSとWeb技術を推進するScott Hanselmanが書いたブログ記事 "Open Source is a thankless job. We do it anyway." を勝手に翻訳。 オープンソースは難しい。 セキュリティは難しい OpenSSLの最近の "Heartbleed" バグに関する記事がたくさん出回っている。技術的な分析をすべて読んだら丸一日つぶれてしまうだろうが、 その中にこれはと思う見出しがあった。『OpenSSLはオープンソースの大きな問題を示している。資金不足、人員不足』だ。インターネットを織りなす基本の部分は、ほとんどの場合たった一人によるもので、あとはたくさんのボランティアだ。 〝魅惑的で気が遠くなるような事実とは、ネットワークインフラストラクチャにはこのように重大な部品が存在していて、インターネットの大部分で実際に動いてい
ツール寄りのサービス開発側が提供すべきはレールであってカスタマイズではない - kony.cc
サービスのことを考えるうち、いろんな人の要望や欲求に答えたくなり、いろんな機能を盛り込もうとしてしまう。 そういうときにはYAGNIの精神に立ち返ればいいんだけど、それ以上に意識した方がいいのは「ユーザーはいい感じにして欲しい」のであって「自分の手であれこれ調整したい」わけではないということだと思う。 カスタマイズできることは機能を提供する側からするとすごく楽で、必要そうなものはとりあえず何でもかんでも追加することができてしまう。 ただそれはユーザーからすると「時間をかけてカスタマイズする」という余計な手間が増えるだけで、非常に辛い(もしかすると無駄な)時間を浪費することになってしまう。ユーザーはあくまでも「自分の苦痛を取り除いてくれる便利な仕組みを手軽に、かついい感じに使いたい」だけだったのに。 例えば、カスタマイズが好きなプログラマでさえ、エディタのカスタマイズと維持にはけっこう苦
開発トレンドは「スマホの外」へ。それでもプログラマーのやることは1つ【連載:中島聡】 - エンジニアtype | 転職type
UIEvolution Founder 中島 聡 Windows95／98、Internet Explorer 3.0／4.0のチーフアーキテクトを務めたエンジニア。NTTに就職した後、マイクロソフト日本法人（現・日本マイクロソフト）に移り、1989年、米マイクロソフトへ。2000年に退社後、UIEを設立。経営者兼開発者として『CloudReaders』や『neu.Notes+』、教育アプリ『neu.Tutor』といったiOSアプリを開発する。シアトル在住。個人ブログはコチラ 今回は、エンジニアtypeが展開している特集「New Order～融合の先を拓く者たち」に関連して、編集部から「ソフトとハード、ネットとリアルが融合する時代の歩き方」をテーマにしてほしいというリクエストがあったので、私見をまとめてみました。 この連載でも何度か取り上げたように、一昨年末くらいから、わたしはウエアラブル
Big Sky :: golang で複数のエラーをハンドリングする方法
golangいまどき例外ないの頭おかしいって思ってたけどようするにgoroutineと例外がうまくいかないからgoroutineのほう取って例外捨てたってことかねえ。 — Urabe, Shyouhei (@shyouhei) April 15, 2014 FAQ に書いてあります。 Why does Go not have exceptions? - Frequently Asked Questions (FAQ) - The Go Programming Language We believe that coupling exceptions to a control structure, as in the try-catch-finally idiom, results in convoluted code. It also tends to encourage programme
オブジェクト指向分析設計の問題点とあるべき姿
Kenichiro Ota @oota_ken 満期の計算ならまだしも、金利やポジションの計算とかになるとよほどうまく抽象化しないとポリモルフィズムの恩恵にはあずかれなくて、しかし、そこまでの努力が本当に労力に見合ったものであるかというのが難しいところなのです。 2010-03-13 20:25:26 Kenichiro Ota @oota_ken もちろん、デリバティブや多通貨会計、外国為替みたいに本質的にオブジェクト指向とマッチングしやすい分野もあるわけで、やっぱりドメインごとに適用するテクノロジーは異なるという結論にならざろうえないのです。 2010-03-13 20:26:54 Masayoshi Hagiwara @masayh この時点でこの技術（OO）の限界を感じます。どんなに優れた技術でも扱いにくいものは適切とは言えません。デザインパターンの導入なくしていい設計ができないの
ソシオメディア | あるとよい機能はない方がよい
UXデザインのコンサルティングではよく品質優先度マッピングというものを行います。これは開発プロジェクトの上流工程において、実装を検討している機能をリストアップし、そのひとつひとつについて想定する利用者の割合や利用頻度の観点からグルーピングし、実装の優先度を決める作業です。 これを行う目的は、UIをできるだけシンプルに保つことにあります。ユーザーが求める機能をすべて盛り込むと、当然UIは複雑になり、誰にとっても使いにくいものになります。また蓋然性のバランスが取れていない要件はプログラムを複雑にし、バグが増える原因になります。 UIデザインにおけるパレートの法則（結果の大部分は全体の一部によって生み出される）は、「ユーザーの80%は全機能の20%しか使わない」というものです。その20%に注力し他の優先度を下げることで、製品の利便性は向上するはずです。 Core, Important, Nice
設定の仕様をドキュメントに書くのではなく、テストにしてしまう - $shibayu36->blog;
以前開発のドキュメントをどこに置くか問題 - $shibayu36->blog;という記事を書いた。まだよい方法はちゃんと考えられてないが、少しずつケースバイケースでいろいろな手法を試してみている。今回は設定項目の仕様のドキュメントという観点で考えたときに、テストを作ることで解決できないか、ということについて書く。 設定項目の仕様 例えば以下の様な設定があったとする*1。 [ { "blog_url" : "http://shibayu36.hatenablog.com/", "permission" : "public", "can_be_edited_by" : [ "shiba_yu36" ] }, { "blog_url" : "http://shibayu36-private.hatenablog.com/", "permission" : "private", "can_be_
システム屋としてのいろはをIBMに教えてもらった僕が今のIBMに思うこと - novtan別館
思えば、新人の頃の僕はIBMのプロジェクトと共にあった。当時、色んな意味でいい加減だった自社（今はそうでもない）ではなく、現場のIBMが僕を育ててくれた。プロジェクト管理の仕方、見積の仕方、顧客との交渉の仕方、そしてもちろん、技術を。 純粋に技術という点ではむしろ自社の先輩や自分自身の勉強がほとんどの部分もあったと思う。でも、サーバーとの付き合い方を色んな意味で学ばせてくれたのはやはりサーバーからアプリまで全部自分たちでやるというプロジェクトであったからだろう。 日本IBMの最近の営業施策を見るにつけ、日本ならではのハイコンテクストな関係を軽視しているように感じます。何十年と続いてきた手帳やテーブル・カレンダーの廃止、ユーザー組織やパートナー組織を支援する人員や予算の削減などは、確かに売上に直結するものではありません。しかし、こういう濃密な人のつながりやブランド価値を浸透させるための取り組
ソフトウェアを作るのは、意外と難しい
プログラマ同士で話している時には当たり前の事だけど、非プログラマと話すと意外と共有されてない事に、これがある。 ここ最近、プログラマでない人とソフトウェアを作る、という話が三回あった。 一度はその人の為にツールを作る、という奴。もう一つは私のアプリのデザインを一部変更する、という話で、けれどデザイナがソフトウェアのデザインやった事無い、という奴。もう一つはアプリの素人だけど、アプリのアイデアとかはあるからアプリが書けるようになりたい、という人に話をする、という奴。 ちゃんと作ったのは最初のツールだけで、残り二つは辞退したけれど、どのケースでもソフトウェアを作るというのは結構難しい、という事があまり共有されていない。 私は結構ソフトウェアを作るのは難しいから、XXXみたいな事が必要だ、というような提案をする。 例えば、リモートの開発はかなり困難で、メールのみでソフトウェアの振る舞いの話をしあ
ScaleOut | Supership
「ミライリアルの幸せを、デジタルの力で創る」ことを目指すSupershipグループの社内報です。日々の出来事、メンバーの働く様子や声、未来への想いなど、Supershipグループの”Be Super”なストーリーをみんなでシェアしていきます。
HRTの原則 〜ソフトウェア開発はバーでしっとり語り合うように 〜 : 小野和俊のブログ
「HRTの原則」という言葉をご存知だろうか。 これは書籍 Team Geek ―Googleのギークたちはいかにしてチームを作るのか で紹介されている言葉であり、本書ではほぼ一冊すべてをかけてこのHRTの原則とその実践方法とを様々な角度から紹介している。 1. 謙虚(Humility) 2. 尊敬(Respect) 3. 信頼(Trust) の3つの価値が大切にされており、エンジニアとしてもチームや組織、顧客との対話においてこれらの価値を重んじていくことが成功につながる、というものである。 あらゆる人間関係の衝突は、謙虚・尊敬・信頼の欠如によるものだ Team Geek p.15 プログラマとして成功するには、最新の言語を覚えたり高速なコードを書いたりするだけではいけない。プログラマは常にチームで仕事をする。君が思っている以上に、チームは個人の生産性や幸福に直接影響するのである。 Team
Railsアプリつくった - ✘╹◡╹✘
最近APIサーバ用途でRailsアプリを1個つくったので振り返る。 概要 接続元はiOSやAndroidアプリとか、Webブラウザとか、別のWebアプリケーションとか。1ホストあたり秒間数百リクエスト、平均応答時間10msぐらい。Rails 4.1.0.rc2、Unicorn、Nginxを使ってる。正直Railsは全部入りで重いイメージがあったので何となく平均50ms以内程度であれば良いところだろうと思ってたけど、意外と速い。多分そもそもサーバの性能が良いんだと思う。実装時に気を付けたことは普段の開発と特に変わりない。いつもは大勢でワイワイ開発するものに少し手を加えるということが多いんだけど、今回は珍しく自分一人でつくったから目が行き届いてたのかもしれない。DBへの問合せの効率に気を配るとか、Rubyでの処理の無駄を省くとか、アプリケーションのプロセスに無駄なコードを読み込ませないとか、計
Worse is worse
Worse is worse（悪いものは悪い） Jim Waldo 2003年12月9日 (Original article: Jim Waldo, Worse is worse. Japanese translation by Hisashi Morita.) 概要 "worse is better"に関する有名なエッセイは、誤解されているか、あるいは間違っているか、そのどちらかだ。我々が設計に関する主張でそれを引用するとき、我々は我々の顧客と我々の作品の両方をごまかしていることになる。私はこのエッセイを改めて取り上げ、考えてみたい。 最近、東海岸の技術者と西海岸の技術者の違いに関する記事を担当しているリポーターからインタビューを受けたことがある（そのとおり、この手垢のついた話がまた取り上げられているというわけだ）。そのせいでDick Gabrielの有名な"Worse is Bette
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ソフトウェアの負債を扱う
Hammock Driven Development - Rich Hickey
アジャイル×テスト開発を考える
