タグ

思考方法と戒めに関するtaketsのブックマーク (6)

  • フローチャートの力を思い出そう

    一つ,後悔していることがある。 今年の6月29日,「オブジェクト倶楽部 2006夏イベント」に参加した。オブジェクト倶楽部は,永和システムマネジメントの社員有志が中心になり,オブジェクト指向の実践/研究/発表を目的として作ったグループ。夏と冬に定期的にイベントを開催している。2006夏イベントで6回目となる。 このイベントで,スターロジックの羽生章洋社長が講演した「仕事で必要なことはフローチャートで学んだ」というセッションを受講した。同じ時間帯の裏番組でとても魅力的なセッションがあったのだが,あえてこちらを選択した。羽生氏のプレゼンテーションのうまさをよく知っていたからだ。案の定,おもしろかった。羽生氏がタブレットPCを使ってその場でどんどんフローチャートを書いていく。講演の資料はこちらで公開されているが,これだけではとても伝わらないライブ感があった。 講演の内容はノートにメモしたし,講演

    フローチャートの力を思い出そう
    takets
    takets 2006/08/02
    - フローチャートこそ基礎
  • 英語で書かれたマニュアルが読めないという以前に:佐野裕のサーバ管理者日記:ITpro

    "上級システム管理者"を目指す者にとって、英語で書かれたマニュアルを読解することは必須のスキルですが、実際の現場では、「僕は英語が全然読めないので勘弁してください」という悲鳴に近い声がよく聞こえます。 その人たちの行動を見ていると、英語のマニュアルを読まなければどうしても先に進めないシチュエーションに遭遇すると、多くの場合、ネット上からマニュアルを落としてきて、それをそのまま自動翻訳機にかけようとします。ふむ、彼らは英文マニュアルを日語のレベルで対処しようとしているわけですね。しかし、皆さんも経験があるかと思いますが、英日翻訳は多くの場合意味不明な翻訳結果を返すので、結果としてこのアプローチは失敗に終わることが非常に多いです。 ということは、このアプローチは、もし自動翻訳機の翻訳精度が上がれば解決する問題でしょうか。私は違うと思っています。 英語が読めないという彼らに、日語のマニュアル

    英語で書かれたマニュアルが読めないという以前に:佐野裕のサーバ管理者日記:ITpro
    takets
    takets 2006/07/24
    - ネットで答えを偶然見つけてもそれは理解じゃない。マニュアル当たれ
  • 不思議なISBN-[結] 2006年5月 - 結城浩の日記

    目次 2006年5月31日 - 作業ログを書くために大切な、たった一つのこと / 2006年5月30日 - プログラミング言語の勉強日記 / 2006年5月28日 - 今日の一日 / 2006年5月24日 - 多忙 / 2006年5月22日 - 新連載「簡単実装で学ぶWeb技術2006」 / 誤植 / 2006年5月20日 - 失敗 / 2006年5月19日 - 掲示板spam / 2006年5月18日 - 誤植 / 2006年5月17日 - JSON::Hatchet / 2006年5月16日 - CGIでブラウザのキャッシュを無効にする / 2006年5月15日 - 仕事 / 2006年5月12日 - タイプタイプ / 2006年5月11日 - 仕事 / 2006年5月10日 - タイプしながら考える / 2006年5月8日 - 書きながら考える / 2006年5月5日 - 数学姉 /

  • コーディングや設計で難所に出くわした時にすること - higepon blog

    仕事趣味でコードを書いているとき、設計をしているときに難所に出くわすことがあります。 そんなときに僕が意識的に心がけていることを紹介します。 もっと良い方法があったらぜひ教えてください。→皆様。 難所に出くわす前に「もうすぐ難所だな」と気づいているときは、すでに冷静な状態で心構えができています。 この場合はきちんと対処ができることが多いです。 何度も考えがループしていたり、難しすぎて他の事に逃避しているときは集中力がないか、難所にさしかかっているサインなので、難所の場合は以下の5つを順番に試しています。 絵を描く 人に言葉にして説明する 思考の流れをテキストにする 散歩する 次の日に持ち越す 絵を描く 設計やコーディングに関して、分かっていることを絵や図にあえて描いてみます。 分からないところは箱を描いて中に? とでも書いておけば良いです。 絵を書く過程で、自分がどこが分かっていないかが

    コーディングや設計で難所に出くわした時にすること - higepon blog
  • はてなに入った技術者の皆さんへ (jkondoの日記より)

    最近はてなの社内では新しい技術を勉強したり、フレームワークや言語を移し変えようかという話も出ていたりして活気が出てきています。技術者も10人を超えて、色々な考え方をする人同士が刺激を与え合いながら切磋琢磨していて素晴らしいなあと思います。そういう中で、僕が技術について思う事を少しまとめてみました。 アウトプットを出す 新しい技術を習得したり、時間を掛けて作り上げた結果は、何かのアウトプットとして出さなければほとんど意味がありません。知識や結果を自分の中に残すだけで終わるのは、それを活かしてサービスを作りたくさんの人が使えるようにする事に比べると驚くほどちっぽけな仕事です。 また、3日間で作り上げた素晴らしい仕組みをそのまま1週間寝かせてしまうのは、4日目に他の人が使えるようにしてから1週間を過ごすことに比べると随分見劣りしてしまいます。 当たり前ですが、どれだけ素晴らしい仕組みを作っても、

    はてなに入った技術者の皆さんへ (jkondoの日記より)
  • 川村渇真の「知性の泉」

    | トップ扉 | 思考支援 . ネット革 . UI考房 . 設計技術 . シス開発 . 道具活用 | 自己紹介 | | 最近更新 | 思考方法 . 議論手法 . 説明技術 . 知能教育 . □□□□ . □□□□ | 著作更新 | | 総合目次 | 社会進歩 . 市民運動 . ジャナ革 . 未来社会 . 一流仕事 . 組織構築 | 独り言? | | 補助索引 | 心の階段 . □□□□ . 芸術奥覗 . 残り物達 . リンク集 . 脳ぐちゃ | 推奨用語 |

  • 1