仕事や趣味でコードを書いているとき、設計をしているときに難所に出くわすことがあります。 そんなときに僕が意識的に心がけていることを紹介します。 もっと良い方法があったらぜひ教えてください。→皆様。 難所に出くわす前に「もうすぐ難所だな」と気づいているときは、すでに冷静な状態で心構えができています。 この場合はきちんと対処ができることが多いです。 何度も考えがループしていたり、難しすぎて他の事に逃避しているときは集中力がないか、難所にさしかかっているサインなので、難所の場合は以下の5つを順番に試しています。 絵を描く 人に言葉にして説明する 思考の流れをテキストにする 散歩する 次の日に持ち越す 絵を描く 設計やコーディングに関して、分かっていることを絵や図にあえて描いてみます。 分からないところは箱を描いて中に? とでも書いておけば良いです。 絵を書く過程で、自分がどこが分かっていないかが
はじめに この記事は、mymy-mycompany分室の2005年10月に1ヶ月をかけて書いたものです。ブログだと後から参照するのが大変なので、ここにまとめておきます。また、ブログでは時間の都合で書けなかった話も追加していく予定です。 私の道具箱 ここ1ヶ月ほど、私的Webサイトプロジェクトなるものに参加しています。オープンソース方式ではなくて伽藍方式。以前、オープンソースのカンファレンスに出たときに、そこで発表していた学生が、ちらと「実はオープンソースよりも伽藍のほうがクオリティが高いものができると思っているんだよね~」と話していたのが、非常~に気になってはいるのですが、そのあたりは、各自のモチベーションと時間の取り方の違いでしょうね。オープンソースでもコミットする人数(アクティブな人)が限られていれば伽藍に近くなるし、伽藍にしてもうまくいかないプロジェクトごまんとあるわけなので。 で、
ネタ切れってわけでもないけど、今日は翻訳ネタ。10の理由も流行ってることだしね。 ネタ元はここ。 あなたはミスをするのだということを理解し、受け容れよう。物を作る前にこの点をはっきりさせよう。幸いなことに、ロケットのガイドソフトをJPLで開発しているような少数の例外を除けば、私たちの職業ではミスは滅多に致命傷にはならない。だから、学ぶべきだし、学ぶことができるんだ。そして笑い、前進するんだ。 あなたの書いたコードはあなたの分身ではない。レビューのポイントは、問題を発見すること、そして問題は見つけられるのだということを覚えておくといい。誰かが指摘してくれるときのために、コードを公開しないのは良くない。 あなたがどれだけ「空手」について知っていようとも、ほかのだれかがもっと知っているのだ。あなたが教えを乞えばだれかが教えてくれる。第三者からの情報を探して受け入れるんだ。特に、もう教えてもらうこ
目次 はじめに こころとからだ 休息は大切 睡眠 夜型と朝型 眠るための儀式 食事を味わう 心の健康 無駄を無駄にしない工夫 誠実に 記録と計画 仕事の見積り 文章を書く、プログラムを書く 文章の書き方 日々の生活 習慣の力を借りる メモの取り方 整理・整頓 道具 書物 文房具 自分との調和、他人との協調 複数の仕事のコントロール 他の人と仕事する 残りの話題 読者のみなさんからのフィードバック ぜひ、感想をお送りください 更新履歴 リンク集 はじめに このページでは、 結城が仕事をする上で心がけていること、 心がけようとしていることをご紹介しています。 こころとからだ 休息は大切 仕事について書くのに、 「休息」から書きはじめるのは変でしょうか。 けれども私はそうは思いません。 私は、よい休息がとれているときにはじめて 充実した知的生活を営むことができるからです。 逆に、休息がきちんとと
コンピュータの消費電力に対するパフォーマンスが今日のレベルから改善しなければ、マシンの運用に必要とされる電気代がハードウェア自体のコストを大幅に上回る可能性があると、Googleのあるエンジニアが警告を発した。 数千台ものサーバを動かすGoogleにとって、こうした状況は望ましいものではないだろう。 「消費電力あたりのパフォーマンスが今後数年間改善されずにいると、電気代がハードウェアのコストを容易に上回り、場合によってはその差が大きく開く可能性もある」と、Luiz Andre Barrosoは、9月に「Association for Computing Machinery's Queue」に発表した論文のなかで述べている。同氏は以前、Digital Equipment Corp.(DEC)でプロセッサを設計していたこともある人物だ。「コンピュータ機器の消費電力を抑えられなくなれば、地球環境
うちの会社でときどき仕事を外注の人にお願いすることがある。あるいは、うちの会社でしばらく働いてもらうことがある。そうすると、そういう人たちは「ああ、世間の職業プログラマは、こんなレベルで、こんな質の悪いコードを書いてやがるんだな」という局面に出くわすこともあるだろう。 「こんな奴でも食っていけるんだ」とか「世間のレベルとはこんなものなのか」みたいに一般化して認識する。下手すると自分のblogで「こんなコード許されていいのか」だとか「こいつバカス」とか愚痴を書いてやがる。「ほげほげテクノロジーを使いこなすのは、世間の職業プログラマには無理だろう」だとか書いてやがる。そんなの勘違いも甚だしいと思うんですよ。 あのね。仕事というのは、相手の実力の30〜40%で出来るものを与えるのが正しいマネージメントなのです。相手の力の80%〜120%を出さないと達成出来ないような仕事というのは、その人にお願い
最近はてなの社内では新しい技術を勉強したり、フレームワークや言語を移し変えようかという話も出ていたりして活気が出てきています。技術者も10人を超えて、色々な考え方をする人同士が刺激を与え合いながら切磋琢磨していて素晴らしいなあと思います。そういう中で、僕が技術について思う事を少しまとめてみました。 アウトプットを出す 新しい技術を習得したり、時間を掛けて作り上げた結果は、何かのアウトプットとして出さなければほとんど意味がありません。知識や結果を自分の中に残すだけで終わるのは、それを活かしてサービスを作りたくさんの人が使えるようにする事に比べると驚くほどちっぽけな仕事です。 また、3日間で作り上げた素晴らしい仕組みをそのまま1週間寝かせてしまうのは、4日目に他の人が使えるようにしてから1週間を過ごすことに比べると随分見劣りしてしまいます。 当たり前ですが、どれだけ素晴らしい仕組みを作っても、
2023-11-25 最新研究からわかる 学習効率の高め方 本書は、Amazon総合1位(無料)となった科学的学習法の本のWeb版です。 12万部のベストセラーとなった前著と同様、図とイラストを使って分かりやすく解説しています。 英語学習者・教師・受験生・小学生~高校生の親御さんに読んでいただきたいです。 全5巻… 2020-10-28 もし爆速プログラマーが大企業経営者になったら と思っていたら、「もし」が現実になっていた。 彼の名は小野和俊。 かつて日本中からスーパープログラマーたちの集まった「未踏ソフトウェア創造事業」で、プログラミング速度で他のプログラマーたちを驚かせたほどの爆速プログラマーである。 『諸君 私は… 2020-09-28 人生は、運よりも実力よりも「勘違いさせる力」で決まっている - 第一章 Amazonで1位 (心理学) この記事は、 『人生は、運よりも実力よりも
iPhoneの一般修理店は予約なしでも来店できる? 基本的には飛び込みで修理に行ってもOK iPhoneを置いていたソファにうっかりと腰かけてしまい、パネルを割ってしまった、こんな時はスマホの一般修理店へ行きましょう。画面割れは、スマホやタブレットの故障原因として非常に多いものです。予約なしで突然お店に行っても平気かしらと、不安に思う方々もいらっしゃるかもしれません。結論としては特に問題はなく、予約なしで訪問しても画面割れの修理はお願いできます。 ただし他のサービス業のお店同様、予約なしの場合、お店が混雑していると順番待ちをしなければいけないです。特に繁盛しているスマホ修理のお店だと、行列が店内で出来ており、予約なしだと、自分の順番が巡ってくるまで長時間待たされる可能性があります。平日の朝、昼なら利用客が少ない場合が多く、飛び込みでも比較スムーズに修理が頼めます。 予約は入れた方が時短に、
Landscape トップページ | < 前の日 2006-03-21 2006-03-22 次の日 2006-03-24 > Landscape - エンジニアのメモ 2006-03-22 SEの読書術 -「本質を読む」力を磨く10の哲学 を読了 当サイト内を Google 検索できます * SEの読書術 -「本質を読む」力を磨く10の哲学 を読了この記事の直リンクURL: Permlink | この記事が属するカテゴリ: [本] 「SE の読書術」を読了した。 - SEの読書術を読んだ理由SEの読書術―「本質を読む」力を磨く10の哲学 技術評論社編集部 発売日: 2006/02 amazon で詳しく見る bk1で詳しく見る 昨年末くらいから業務に押されて勉強する時間を作れていなかったが、今月に入ってやっと時間を作れるようになってきた。私にとって勉強の基本は読書にある。作れた時間を
特集 9割は、準備不足で大損! 「定年」の新常識 インフレで年金が目減りする時代がやってくる 2024年最新版! 解明「金持ち定年」への4つの分岐点 コラム◎ 高い役職の人ほど発想を変えよう! 定年女性の「理想の職探し」 目次詳細へ プレジデントストアへ 予約購読 2024年1月15日(月) 環境フォト・コンテスト / プレジデント「第30回 環境フォト・コンテスト2024」入賞作品を発表! 2023年1月13日(金) プレジデント / 環境フォト・コンテスト「第29回 環境フォト・コンテスト2023」入賞作品を発表! 2022年1月14日(金) 環境フォト・コンテスト / プレジデント「第28回 環境フォト・コンテスト2022」入賞作品を発表! 2021年2月8日(月) プレジデント読者のみなさまへお知らせ 2021年2月8日 2021年1月8日(金) 環境フォト・コンテスト / プレジ
Five excellent mind habits to develop Thursday, 15 September 2005 Want a more useful mind? Your mind is like a muscle, it can be trained to be stronger and more efficient. Here are some good ways to help you develop your brain into a better tool. I'm not saying they're easy, but they're definitely worthwhile. Never let a word pass you by From a university professor to a janitor, we all hear wo
現在のシステム開発という開発モデルを考えてみると、そのシステムを必要としており開発の依頼を発注する発注側と、実際の開発作業を請け負う開発側の間で、プロジェクトに対し契約を結んだ段階からシステム開発は始まる、というのが当たり前の話。そして、この当たり前と思われている関係でビジネスを続けると問題があるのでは、と考察したのが以前のエントリ、「ディフェンシブな開発*1」だった。 今回は、その当たり前だと思われているところについて、発想の転換を取り入れて考えてみようと思う。社会における通念や物事を大きく変えるためには、コペルニクス的転回が必要だからだ。 ノウハウを集約できないSI企業 まずこの「プロジェクト開始してからシステム開発を始める」という点について、ディフェンシブであるということ以外にも、SI企業として重大な問題点が隠されている。それは、IT技術に対するノウハウの蓄積に関する問題である。今の
トラブルと成長 ときどき思い出す、印象的な光景があります。 とある図書館で、中庭を眺めながら休憩していたときのこと、その中庭に親子が飛び出してきた。父親が勢いよく広場に向けて走りだし、2、3歳くらいの男の子がそれを追いかけていた。 次の瞬間、勢いあまって男の子は転んでしまった。真正面から顔面を打ちそうな勢いで転ぶ、かなり痛そうな転び方だった。私はそれを見て、次の瞬間に父親が男の子を起しに行くことを予想した。正確には「予想」というようなものでもなく、そうするのが当然だというイメージが私の頭にあって、反射的に思っただけだ。 実際には、父親は、男の子の方を振り向いて、満面の笑顔で、大きく手を広げてこっちにおいで、という仕草をした(距離があったので声は聞こえなかった)後、そのまま走って行ってしまった。生垣を曲がって広場に入ってしまったので、男の子の視界からはすぐに父親の姿は消えただろう。 男の子は
Aaron Swartz さんのエッセイ、“HOWTO: Be more productive” の日本語訳です。Aaron くんは、ティーンエージャーにして W3C のコア・ワーキング・グループのメンバーで、RSS 1.0 仕様書の共同執筆者のひとりとしても知られる、才気煥発のスーパーハッカーさんです。どうしたらより生産的な人生を送れるのかについて考察したこのエッセイは、2005年の末に彼のブログに掲載されたもので、多くの注目を集めました。プログラミングに限らず、クリエイティブな仕事をこころざすすべての人にとって有用と思い(日本語訳もまだ出てないみたいなので)、翻訳してみることにしました。「この翻訳について」で案内しているフォームから、ご意見・ご感想などもお寄せください。 「君がテレビを見てた時間をぜんぶ合わせれば、」そいつは言った「いまごろ長編小説の一本も書けてたはずだ」。これにはたし
システム設計者には詐欺師に対するときのような「疑り深さ」が必要だ。そのような姿勢によってしか探り当てられないタイプの要件が存在するからだ。その種の要件はしばしば重大で、捉えそこなうと痛い目に会う。 ◆システム要件の分類学 システム要件は、ユーザによって自発的に語られる場合と語られない場合とがある。ユーザが独自にまとめた要件定義書などは「語られた要件」の代表的なものだ。第三者がまとめたとしても、ユーザに一方的に語らせただけのものであればこれと似たものになる。しかし、そこに書かれたことを漏れなく取り入れるだけですべての要件をまっとうできると設計者が考えているとしたら、あまりに純朴過ぎる。 システム要件には、「語られていないけれども無視できないもの」も「語られているけれども無視すべきもの」も存在する。つまり、システム要件には「語られたか、語られなかったか」と、これに直交する「無視すべきか、無視で
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く