タグ

仕事に関するnharukiのブックマーク (115)

  • Life is beautiful: 私のとっておきのプログラミングスタイル

    404 Blog Not Found の「LiveCoding に学ぶプログラミングの三原則」を読んでいたらどうしても書きたくなったので。あくまで私のスタイルなので、参考にするもしないもご自由に。 1. スタードダッシュでできるだけはやくめどをつける 学生時代から夏休みの宿題は7月中に終わらせていた私とすれば、ラストスパートよりはスタートダッシュで勝負する。どのみち、どこかで思いっきり頑張らなければならないのであれば、締め切り間際ではなく、スタート間際に頑張るべきというのが私のポリシー。十週間のプロジェクトであれば、最初の二週間が勝負。そこで八割がたのめどをつけておき、後は流す。最初の二週間がめどが立てられなければ、十週間で完成できる可能性は低いと考える。常にそういう姿勢でいれば、締め切りぎりぎりになって致命的な欠陥が見つかって痛いめにあったり、当は大幅な設計変更をすべきなのに応急処置で

  • 第2回 「締め切りは絶対に守るもの」と考えると世界が変わる | gihyo.jp

    「締め切りを守ること」の大切さ 今までたくさんの日米のエンジニア仕事をしてきた。その中には私よりも明らかに「賢いエンジニア」もいたし、ものすごい生産性でプログラムを作ってくれる「馬力(ばりき)のあるエンジニア」もいた。しかし、そんな中でも、私がものを作るうえで最も大切だと考えている「あること」をキチンとこなせる人は100人に1人もいなかった。その「あること」とは、「⁠常に締め切りを守れるように仕事をすること」である。 チームで仕事をする場合、どうしてもお互いが担当するタスク(=作業)の間に依存関係が生じる。そんなときに、どれか一つのタスクの完了の遅れが、ほかのタスクの完了に波及し、それがタスク間の競合を引き起こして全体のスケジュールがさらに遅れる、という事態はソフトウェア開発の現場ではよく見られる。そんな状況をできるだけ回避するには、プロジェクトに関わる人全員が、自分に割り当てられたタス

    第2回 「締め切りは絶対に守るもの」と考えると世界が変わる | gihyo.jp
  • LiveCodingに学ぶプログラミングの三原則 : 404 Blog Not Found

    2007年09月16日04:30 カテゴリArt LiveCodingに学ぶプログラミングの三原則 Mozilla24のLiveCodingの解説をやってきました。参加された方、お疲れさまでした。ほんと楽しかった。 言語もC++ありJavaありJavaScriptありActionScriptありPerlありとまちまちで、Editorもemacsありvimあり秀丸ありとまちまちでしたが、それでも全LiveCoderの共通項がはっきり見えたので、それを書き留めておきます。これらの共通項には私も含まれます。 コピペを恐れるな(don't be afraid to be a copycat) 参加者の一人として、100%フルスクラッチで書いていた人はいませんでした。たいていは関数単位でコピーし、それを適宜書き換えるというやり方をしていました。学校のテストでは反則もいいところですが、大人の世界ではこ

    LiveCodingに学ぶプログラミングの三原則 : 404 Blog Not Found
  • すごい物を見てもへこたれない人

    友人が、物凄く絵が上手いんだけどさ。 でも最初は下手だったんだよね。たいしてうまくない自分より下手だった。 でも急激に成長してる。今はもうホントに上手い。絵で仕事もしてる。 2chのスレでもよくある、「上手い人見て凹んで描けなくなった」とかいうやつ。自分も上手い作家さんとか見たりするとああいう気持ちになったり、年下なのに上手いのとか見るとホントへ込むんだけど、どうやら友人はそういうのが無いっぽい。前その辺語ってて判明した。 「できない」って思わないみたい。なんか。 すごい人見ると、即座に「そうなるにはどうすればいいか」「自分に何を+すればそうなれるか」「そして+する方法は何か」を考えてる。 だからすごい人を見たほうがモチベーションとか上がる。みたい。 目標が目に見えて分かるから寧ろ嬉しいらしい。 年下で上手いとか見ても、考え方が根から違う。自分は「年下でこんなに上手いとかマジ死ぬwwww

    すごい物を見てもへこたれない人
    nharuki
    nharuki 2010/07/16
    鶏口牛後なんかくそ食らえ。牛後上等!
  • カプコンに学ぶデスマーチにならない仕事術 - teruyastarはかく語りき

    ほんとにヤバくなってギリギリになるまで相談しない人々: 切込隊長BLOG(ブログ) Lead‐off man's Blog http://kirik.tea-nifty.com/diary/2010/03/post-1da9.html いつも予防線が突破されるので、いずれにせよ年がら年中修羅場になってるわけだが、 修羅場をこなしているうちに、常在戦場みたいな組織が出来上がって、 毎日ラットレースをしている敗戦処理のエキスパート軍団ができちゃう。 戦況だけ見ると実に見事に負けてるんだけど、 担当した局地戦だけはどうにかなっちゃってるというような。 そういう組織は、人が内部から壊れていく。になったり、病気になったりする。 まあ、発展性のない業務に長時間据えられて、 強いストレスに晒されながら安い給料で働くわけだからねえ。 一個一個のデスマーチは、マーチである限り終わりはあるわけだけど、 デス

    カプコンに学ぶデスマーチにならない仕事術 - teruyastarはかく語りき
  • きれいなソースコードを書くために必要な、たったひとつの単純な事 - よくわかりません

    「構造のきれいなプログラムを書けるようになるためにはどうすればいいのか?」という質問を受けたので、「はて?どうしているだろうか?」と考えてみました。あ、形式知にきちんとなっているようなテクニックみたいなもんじゃなくて、モノローグなので、あまり凝ったものは期待しないように。 http://blog.shibu.jp/article/28983162.html 自分なりにもっと凝縮版を。渋川さんが言っている事全体もその通りとは思うけど*1、もっと簡単で、しかも射程が広い、と自分が思っている事。 渋川さんはちょろっと触れてるだけだけど、自分はこれが最も基的で汎用的、かつ、ソースをきれいにする原動力となる上にバグをも減らしてコードの汎用性まであげる、コーディングのエンジンみたいなものと思ってる。それは、 「すべてに正しい名前を付けて、そして、正しい名前であることを維持する」という鉄の意志 クラス

    きれいなソースコードを書くために必要な、たったひとつの単純な事 - よくわかりません
  • 能力のない人へ - Chikirinの日記

    注意:このブログは“おちゃらけブログ”といいまして、笑い話が書いてあるブログですから、真に受けないように気をつけて下さい。 能力のない人へ アドバイス4つ アドバイス1)考える力のない人は、情報をため込みましょう 自分は考える能力が弱い、思考力がないと思う場合は、とにかく情報をため込みましょう。そして自分が手に入れた情報は安易に周囲に開示しないこと。まずはこれが大事です。 特に公務員の方などは、国民の税金で調査したデータの詳細を決して国民に開示してはいけません。そんなものを開示したら、自分と国民の間の差が、能力差ではなく「もっている情報の量の差」だとばれてしまいます。しかもその情報は、自分で集めたわけでさえなく、国民の税金により、天下りが何人もいるシンクタンクに依頼して集めたものだとばれたら、「なにそれ?」と言われてしまいます。ですから、絶対に情報は開示してはいけません。 アドバイス2)仕

    能力のない人へ - Chikirinの日記
    nharuki
    nharuki 2010/07/07
    能力のある人がこれらのアドバイス「も」実践したら最強、と読み取った。…ええ、これも皮肉ですよ??
  • 労働法とは?|知って得する労働法|職場の法律、身近な労働法をやさしく解説

    ■労働法とは? 【労働法という名の法律があるわけではない】 労働法という名称の法律はありません。 労働法は多くの労働関係法令の総称です。法令には次のようなものがあります。 労働基準法 労働者派遣法 男女雇用機会均等法 育児・介護休業法 職安法 労組法 など これらの元となるものに、民法の雇用契約に関する定めがあり、その元は日国憲法の基的人権の保障までさかのぼります。労働関係法律は奥が深いのです。 言えることは、ほとんどの法令が労働者を守るためにあるということです。裏を返せば、使用者もうまくその法令を使うことで、健全な職場を作ることが出来るということです。健全な職場は結果的に利益を生みます。利用価値大いにあり!ですね。 ここでは、骨子的な労働基準法から身近なものを選んで話していきたいと思います。 とくれば、やっぱり休暇についてでしょうか。休みはやっぱりたくさんほ

  • プログラマーが知っておくべきうつ病の知識 - aike’s blog

    少し前にITproにプログラマーは「こころの病」にかかる比率が高いという記事が載っていましたが、あらためて言われるまでもなくプログラマーがストレスで精神を病んで離脱するケースは自分の周りを見ても非常に多いです。こんな状況であればプログラマーに対する危険手当やプログラマー専用うつ保険とかあっても良いと思うのですがなかなか社会は変わらないようです。 このような状況に対抗するにはプログラマー自身が自衛のために知識を得ることだと思います。プログラマーの武器は知識であり、ハックする好奇心なのだから、あらかじめ十分な知識を身につけて不当なストレスに対して有利に戦いをすべきなのです。 1.判断力低下は想像以上に怖い うつで一番恐ろしいのは、気分が憂になることではなく、判断力が低下することです。 判断力が落ちるとどうなるかと言うと、自分が健康なのかどうか判断できなくなり、仕事を休むべきなのかどうかで判断

    プログラマーが知っておくべきうつ病の知識 - aike’s blog
  • 人脈を築くために一番大切なこと - GoTheDistance

    人脈というのは「人」の「脈」と書きます。つまり、これが意味する所は自分を中心して「人」が「脈をなしてつながる」ことで初めて人脈と呼ぶに相応しいものになります。 人脈を築くために一番大切なこと。それは、相手に何かを与えられる自分であるかどうかです。それ以外は全部二の次です。 2年ぐらい前になりますが、僕は前職のある営業部隊の担当役員の下で仕事をさせてもらったことがあり、その時に僕の年齢じゃまず会うことが無いであろうエグゼクティブな方々とお会いする機会に恵まれました。もちろん名刺も交換しましたし、ある程度メールのやり取りもしました。打ち合わせも重ねましたし懇親会とかもやらせてもらい、色々と勉強させてもらいました。 でも、仕事が終わればお付き合いはそれで終わってしまいました。 その時僕が感じたのは、人脈を築くってのは相手に与えられるものを持たなくちゃいけないんだ、ということです。相手に対して自分

    人脈を築くために一番大切なこと - GoTheDistance
  • エンジニアの技能レベル~ドレイファスモデル~

    エンジニアの技能レベル ~ドレイファスモデル~ 書籍「リファクタリング・ウェットウェア」から 1970年代のドレイファス兄弟による人間の技能の習得・極める過程についての研究結果 研究対象は、民間航空会社のパイロット、チェスの名人などのある分野の技術にきわめて高いレベルの習熟度を示した人々 技能ごとに評価するので、個人の生来持つ特性・才能ではない 5段階でモデル化

  • はてなブログ | 無料ブログを作成しよう

    パスタ習作#2 飽き性な性格なのに#1を書いた以降も意外とパスタ熱が冷めなかった。当たり前のことだが、基が分かってくると応用ができる。応用ができると自由度が増す。自由を手に入れると継続ができる。批評家の福尾匠が自身の日記に、小倉知巳のペペロンチーノのレシピはよくで…

    はてなブログ | 無料ブログを作成しよう
  • はてなブログ | 無料ブログを作成しよう

    来年も作りたい!ふきのとう料理を満喫した 2024年春の記録 春は自炊が楽しい季節 1年の中で最も自炊が楽しい季節は春だと思う。スーパーの棚にやわらかな色合いの野菜が並ぶと自然とこころが弾む。 中でもときめくのは山菜だ。早いと2月下旬ごろから並び始めるそれは、タラの芽、ふきのとうと続き、桜の頃にはうるい、ウド、こ…

    はてなブログ | 無料ブログを作成しよう
  • はじめての人に何かを教える時に心がけること - あと味

    先日投稿した正規表現の記事は、多くの人が見てくれて、はてなブックマークコメントなどで感想もいただきました。 反響をいただいたことで私自身いろいろ考えることがあり、パソコンインストラクター時代の経験と考え方をベースに、はじめての人に何かを教える心がけるといいなと思うことをまとめてみました。 対象者ははじめての正規表現を読んだ方です。もったいないけど、その方がよく伝わると思って割り切ります。 極論に走ってはいますが、今後はじめての人に何かを教える時には、ここに書いた内容を読み返したいと思います。 捨てる はじめての人に何かを教える時は、以下のことを捨てる必要があります。 正確な表現 例外 説明事項 正確な表現 知識があればあるほど正確な表現で伝えることにこだわってしまいがちです。 でもそこはぐっとガマン。 例えば、はじめての正規表現の中でメタキャラクタ、パーレンなどの正式名称を使って説明したら

    はじめての人に何かを教える時に心がけること - あと味
  • 未来の転職が、過去にさかのぼって現在の自分を有能にする - 分裂勘違い君劇場

    転職、すなわち中途採用の面接では、自分が過去に取り組んだ仕事について質問されます。 しかも、ごまかしがきかないよう、具体的な行動内容を、細かく聞かれます。 広く浅く訊くのではなく、何カ所か適当に選んで、狭く深く訊いていきます。 たとえば、エンジニアなら、過去に自分が開発したシステムにおいて、 なぜ、そのフレームワーク、ツール、ライブラリ、DBを使ったのか? 他に、どのようなフレームワーク、ツール、ライブラリ、DBが候補として 上げられたのか? 他の選択肢と比べて、どの様な短所と長所があるのか? なぜ、他の選択肢ではなく、それを選んだのか? 使う前に、どのように性能評価・検証したのか? なぜ、ある部分を汎用的に作り、別の部分をハードコーディングしたのか? なぜ、その設計だと、生産性が高く、トラブルのリスクやメンテナンスコストが低くなるのか? もっと低くできる余地として、どのようなものが考えら

    未来の転職が、過去にさかのぼって現在の自分を有能にする - 分裂勘違い君劇場