達人の技芸を継承する方法はこの世に存在するか？ - give IT a try
前回投稿した「技芸(アート)における経験の重要性」というエントリを改めて読みなおしてみると、「誰も第二の倉貫さんにはなれない」とか、「妻と同じパンは誰にも焼けない」とか、見方によっては救いのない印象を与えたまま終わってしまったのが、ちょっと残念だったかな〜と感じました。(自分の書いた文章ながら) まあ確かに、達人の技芸を完璧に継承することは不可能だとは思います。 ですが、ちょっとでも近づいたり、達人の心意気や考えは取り入れつつ、その人独自の路線で進化(深化?)させたりすることは可能なんじゃないかとも考えています。 ちなみに、プログラマであれば、以下の2冊にそれらしきヒントが見つかるかもしれません。 (というか、久々に本棚から引っ張りだして読んでみたら、前回のエントリに結構内容がかぶっていました。別に意識して書いてたわけじゃないんですけどね) ソフトウェア職人気質―人を育て、システム開発を成
メンタルに強いとか弱いとかない - まつたけのブログ
メンタルに強いとか弱いとかないんじゃねえか、っつー話をしてみます。 メンタルに強い弱いの差はない メンタルに強いとか弱いとかないんじゃねえか、って言っておきながら泣き言から入るんですけど、最近僕ブログ書きすぎだと思うんですよね・・・。いや、読んでくれてる人にしてみたら「知らんがな」って話なのはわかるんですけど、自分でもドン引きしながら記事を書きまくってたりします。 今ブログ始めて２ヶ月弱なんですけど、１ヶ月やってみた時点でたしか「もう飽きたし疲れたからそろそろやめる」みたいなことを書いたような記憶もなきにしもあらずなんですよね。。。でもそのあとでなにがあったのか自分でもはっきりとはわからないんですけど、単純に慣れたというのとは違う感じで突き抜けたというのか、今までうざかったいろんなことがほとんど気にならなくなっている自分に気づきました。そうなるとブログを書くのが楽しくて楽しくて。。。なにか
Object design rough talksへ行ってきました - 虎塚
金曜の夜、Object design rough talksへ行ってきました。Twitterのハッシュタグは #ObjectDesign でした。 Object design rough talks on Zusaar http://www.zusaar.com/event/5037004 面白かったトークの抜粋と感想を書きます。 t_hysshさん「オブジェクト指向レッスン」 内容 『TohughtWorksアンソロジー』から引用したオブジェクト指向で実装するためのルールと、林さんが独自に考えられたルールの紹介でした。 感想 こういったルールは、チームでコーディング方法を統一することを目的とするなら機能しそうだなぁと思いました。 また、林さんは、実際に仕事でチームに適用したところそこそこ上手くいったとおっしゃっていたので、オブジェクト指向を理解している人が、そうでない人のコードをレビュー
ツール寄りのサービス開発側が提供すべきはレールであってカスタマイズではない - kony.cc
サービスのことを考えるうち、いろんな人の要望や欲求に答えたくなり、いろんな機能を盛り込もうとしてしまう。 そういうときにはYAGNIの精神に立ち返ればいいんだけど、それ以上に意識した方がいいのは「ユーザーはいい感じにして欲しい」のであって「自分の手であれこれ調整したい」わけではないということだと思う。 カスタマイズできることは機能を提供する側からするとすごく楽で、必要そうなものはとりあえず何でもかんでも追加することができてしまう。 ただそれはユーザーからすると「時間をかけてカスタマイズする」という余計な手間が増えるだけで、非常に辛い(もしかすると無駄な)時間を浪費することになってしまう。ユーザーはあくまでも「自分の苦痛を取り除いてくれる便利な仕組みを手軽に、かついい感じに使いたい」だけだったのに。 例えば、カスタマイズが好きなプログラマでさえ、エディタのカスタマイズと維持にはけっこう苦
ROSとRTMの違い：モデルベースなシステムエンジニアリングの視点から | ysuga.net
どうも．ysugaです．ちょっと気づいたことをメモしておきますね． どうも仕事ではROSの方が使用頻度が高くなっていますが，個人的にはRTM (RTミドルウエア) 支持派なので，読む方はそういう視点で書いてることを気に留めて読んでくださいね． 1. はじめに さて，RTMとROSの基本的なことについては，このウェブサイトの入門記事の最初の内容を読んでもらうとして，すこしモデルベースな行程でロボットシステムを作ろうという視点から比べてみた話です． 結論的には，ROSはモデルベース開発には向いてないかも・・・間違ってたら教えて！・・・という結論．今後に期待してますけど． モデルベースシステム開発というのは，OMGが推奨している開発行程のスタイルで，SysMLという規格に乗っ取った形でドキュメントを作っていって，そこから自動生成を使ってシステム開発を進めていきましょう．という話． これをROSで
技術の進歩は「螺旋」である。 @ t_wada さん社内講演 - >& STDOUT
先週、新卒技術研修の一環として @t_wadaさん にご講演を頂きました。 題して「この先生きのこるためには」*1。 第一線のエンジニアとして素晴らしい薫陶の数々を授けて下さいましたので、渋谷や六本木の会社さんもオファーしてみたほうがいいですよ。ホント。 エンジニアはアーティストとしての側面も持つので、ファーストクラスの方の考え方に早いうちから触れておくことは、数年先の彼らの在り方に少なからず良い影響を与えるはずだ、という考え*2に基づくおふたりめの社外講師です。おひとりめは当時非公開でしたが、時効になってましたら教えてください。 新卒研修とはいうものの、社食のカフェテリアを全開放した形で既存社員にも受講してもらいました。正直、私も含めた既存社員のほうがよっぽど直接の教育効果は高かったんじゃないかと思いましたが、それはそれとして。ご講演の中でのいくつかの気づきを共有します。 技術の進歩は「
なぜなぜ分析は、危険だ | タイム・コンサルタントの日誌から
「なぜなぜ分析」は、品質管理や労働安全管理などの分野で、よく用いられる手法だ。発生した問題事象の根本原因を探るために、「なぜ？」「なぜ？」とくりかえして掘り下げていく。この問いかけを“5回はくりかえせ”と、よく指導しているため、別名「なぜなぜ5回」とも呼ばれる。元々、トヨタが発祥の地であり、トヨタ生産方式の普及とともに、他の業界や分野でも使われるようになった。 図は、トヨタ生産方式の生みの親である大野耐一氏の著書から一例をとって、図示したものだ。工場内のある生産機械が故障してとまったとき、「なぜ機械は止まったか？」の問いに、「オーバーロードがかかって、ヒューズが切れたからだ」と答えただけでは、じゃあヒューズを交換して再起動すればいい、という答えしか出てこない。 しかし、なぜオーバーロードがかかったのか？→ (2)軸受部の潤滑が十分でないからだ、とほりさげ、 さらに (3)潤滑ポンプが十分組
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
