タグ

開発と考察に関するloca1982のブックマーク (12)

  • 幸せなエンジニアになるための仕事術/まつもとゆきひろ&平鍋健児 - tmtms のメモ

    幸せ 平鍋: 1. 技術的な困難を達成。 2. お客様に感謝された。 最初は1だったけど最近は2。 まつもと: 理不尽な目に合わないこと。 思うようにツールが動かない→自分でつくる。 OSSは自分で手を入れられる。 平鍋: 自分一人の幸せじゃない。 プロジェクトが終わっても続く人間関係。 人のつながり。信頼。 まつもと: 通勤が3時間。理不尽→地方。 納得行かない変更が顧客から言われたくない 平鍋: エンジニアで不幸せな人へ。仕事は選べる。極端なこと言えば辞めればいい。 ワークライフ・バランス実現の戦略(例:地方に住むこと) 平鍋: 1995.子供を育てられるかを考えたときに自分の中での都会の価値がさがってきた。 田舎に帰ってから、世界のことを考えた。JUDE,アジャイルをやり始めた。 まつもと: 鳥取→つくば→島根 1997. OSSビジネスを始めようと声をかけてもらって島根へ。 理不尽

    幸せなエンジニアになるための仕事術/まつもとゆきひろ&平鍋健児 - tmtms のメモ
  • エンジニアがミーティングを嫌う理由 – バイリンガルの独り言

    エンジニアがミーティングを入れられる事を好まない事や、不機嫌になる事は英語圏や日を問わず知られているかと思います。実質、私の周りにもこういった傾向がありますし、職人的に秀でてる方ほどこの傾向が強いと感じています。さて、これはなぜでしょうか? 友人のtweetにPaul Grahamというプログラマ兼ベンチャーキャピタリスが書いた、Maker’s Schedule, Manager’s Scheduleという面白い記事へのリンクが貼られていたので、私なりに要約して紹介します。 二種類のスケジュール プログラマやライターがミーティングを嫌う理由は彼らが他の人間とは違う種類のスケジュールで働いているからであるとGraham氏は語っています。氏いわく、スケジュールには二種類あります。 Maker’s Schedule(物を作る者のスケジュール) Manager’s Schedule(管理する者の

    loca1982
    loca1982 2009/07/31
    時間の考え方がマネージャは時間単位、メイカー(プログラマ、技術者)は半日単位 / なるほど、すごくよくわかる
  • 悪「言語」身に付かず - 「書ける」と「身に付く」の間に : 404 Blog Not Found

    2009年07月26日15:30 カテゴリArtLightweight Languages 悪「言語」身に付かず - 「書ける」と「身に付く」の間に 習うきっかけは、これでいいと思う。 プログラミング言語を身につける唯一の方法 - ぼくはまちちゃん!(Hatena) たぶんこれかな… なにか作りたいものがある または なにかを作る必要がある なんて状況以外で、マトモにプログラミング言語を習得してる人って ぼくほとんど見たことないんだけど、みなさんはどうでしょう…! けど、これでは「身に付かない」と弾言しちゃう。 なんでそう言い切るか、というと、「作りたい」ものがあって、それを実際にその言語で「作った」のにも関わらず、全然身に付いていない言語が私にはあるから。 たとえば、shell script。 これとの付き合いは、perlよりも古い。にも関わらず、私は未だに shell script を

    悪「言語」身に付かず - 「書ける」と「身に付く」の間に : 404 Blog Not Found
    loca1982
    loca1982 2009/07/31
    「「やりたいことをやるのではなく、この言語で何か書くことそのものが今やりたいこと」に思わずなってしまう言語が見つかれば、もうプログラミングは一生ものなのではないか」
  • 何故「多重下請け構造」がなくならないかというと、お前らが営業をサボってるからだよ!! - 消毒しましょ!

    こいつもshi3zとかいうバカgeekと同じで、定期的にバカな持論を開陳しないと気が済まないらしいので、再度disることにするw ここにあるのは業界外の人間から見れば非常識極まりない戯言ばかりであり、それが何に起因しているのかと言えば、徹底した自己中心性と幼稚な甘えに他ならない。 この不景気をきっかけに、発注側のユーザ企業に変わってもらいたい。丸投げではなく、基、SIは自分たちで行い、手が足りない部分を技術のプロフェッショナルに手伝ってもらうやり方。 「SIerは、どうやれば生き残ることができるのか」を考えた末の結論が「この不景気をきっかけに、発注側のユーザ企業に変わってもら」うことだというのだから、相変わらず信じられないくらいのバカというか、空恐ろしいまでの甘えと幼稚さである。「多重下請け構造こそ、SI業界の最大の問題点」であるなら、さっさと自分で営業して仕事を取って来りゃいいだけの話

    何故「多重下請け構造」がなくならないかというと、お前らが営業をサボってるからだよ!! - 消毒しましょ!
    loca1982
    loca1982 2009/07/25
    ユーザ企業に変わってほしい点は色々あるけど自分達が努力することを忘れてはいけない、と読んだ / 営業も大切だね
  • プログラマーの開発速度は「はまる」時間の長さで決まる : 小野和俊のブログ

    プログラミングを始めてから今日に至るまで、 様々なタイプのプログラマーと開発を共にしてきたが、 驚くべき速度で高い品質のソフトウェアを作り上げるプログラマーには、 一つ共通の特徴があるように思える。 それは、「はまる」時間が極端に短い、ということである。 風のプログラマー」を指向しており、開発速度を重要視している。 例えば平成14年未踏ソフトウェア創造事業「PICSY」では、 発表直前に知人でプロジェクトリーダーの鈴木健にレスキュー隊として呼ばれて 2,3日でGUI全般と、クライアント/サーバー通信部分の設計と実装を終わらせたのだが、 このときなどは、大体の要件を口頭で聞いた後は、 ほぼまったく手が止まらずコードを書き続ける感じで開発をしていた。 「はまる」時間の長さは開発速度に直結するわけだが、 プログラマーが「はまる」場合にはある程度の傾向があると思うので、 今日は「はまる」プログラマ

    プログラマーの開発速度は「はまる」時間の長さで決まる : 小野和俊のブログ
  • LingrとRejawサービス終了のお知らせ:Kenn's Clairvoyance

    今回は残念なお知らせがあります。 5月末をもって、LingrとRejawの両サービスをシャットダウンすることになりました。いずれのサービスも、すでに新規サインアップは受付停止済み、5月15日までユーザデータのダウンロード依頼を受け付け、5月16日からは新規発言ができなくなり、5月末の完全停止までの間にデータをダウンロードしていただく段取りになります。 今まで支えてくださったユーザの皆さんには、このような結末になってしまい当に申し訳なく思っています。シャットダウンという最終決定を下すまでには多少の猶予をいただき、営業譲渡などでサービスを存続させる方法も模索していたのですが、受け入れ先を見つけることができませんでした。 2005年の夏にインフォテリアの100%子会社として操業を開始した米国法人のインフォテリアUSAですが、こちらもサービスの終了を見届けた後、6月中に解散・撤収することとなりま

    LingrとRejawサービス終了のお知らせ:Kenn's Clairvoyance
  • 新人プログラマーがプロのプログラマーとして独り立ちするための7つの条件 - ハックルベリーに会いに行く

    ぼくは以前にIT関連の仕事をしたことがあって、ぼく自身はプログラムを組めるわけではないのだけれど、何人かのプログラマーさんと一緒にお仕事をさせて頂く機会があった。その中で生まれて初めてプログラマーという職業の方と交流させて頂いたのだけれど、彼らはなかなかにユニークで特異な個性の持ち主たちであった。もちろんプログラマーと一口に言っても色々なタイプがいて、必ずしもひとくくりにできるわけではないのだが、共通していたのは好奇心が旺盛で新しい物好きだということだった。そして少々気難しい面がありつつも、基的にはポジティブで、明日に向かって色々なことを前向きに、精力的に取り組んでいる人が多かった。 そんな中で、特に親しくお話しさせて頂いたTさんというプログラマーがいて、この方もなかなかに個性的で、ご自分の意見や主張というものをはっきりと持っており、ITのみならず世の中に対しても一家言お持ちであった。そ

  • まつもとゆきひろ氏が語る「ビューティフルコード」セミナーに行って来た - LukeSilvia’s diary

    まつもとゆきひろが語る「ビューティフルコード」×「プログラマ35歳定年説」に行ってきました〜。今年初めて行ったイベントなのですが、とてもいいお話を聞くことができました。美しいコードとはどのようなものか、またそのようなコードを書けるようになるためにはどうすればいいのかというお話でした。 以下、まとめになります。僕のメモを元にしたので、まつもとさんが話された内容と多少ズレがあるかもしれません。 そもそもコードとは何か 「コードの美しさとは」という前に、そもそも「コード」とは何か。 ソフトウェアの作成はものづくりではない コードは工業製品ではない。コードは、車とかと同じ工業製品だと思われることが多く、例えば次のような勘違いがある。 日は「ものづくり」が得意だ。だからソフトウェアも「ものづくり」として取り組めばいい 車のように、ソフトウェアも部品をどんどんコピーして組み合わせばできる 違うよ!全

    まつもとゆきひろ氏が語る「ビューティフルコード」セミナーに行って来た - LukeSilvia’s diary
  • プログラミングハイウェイ - プログラマーの脳みそ

    プログラミング能力をつけるための高速道路を造りたいという話 - タムケンブログ Re: プログラミング能力をつけるための高速道路を造りたいという話 - タムケンブログ:Geekなぺーじ 実際、IT業界に身を置いていると教育機関の必要性を強く感じる。 情報工学科という学科を置く大学は数あるが、世の中に求められるのは実務としてプログラミングができる能力を持った人間だったりする。*1 情報工学科というのは座学が主体で実習が主体なわけではない。例えるならば、美大や音大のような、入学時に実技試験があり、在学中も実技を多く行うような、そういったカリキュラムの情報大学が求められている、と思う。*2 なんせ、情報工学出だろうが、情報系の専門学校出だろうが、文系大学出だろうが、新人で採るならひとしく無能だと思わなければならない。そんな出身校よりも、ホビーでプログラムするかどうかを問う方が当りの人材を引き当て

    プログラミングハイウェイ - プログラマーの脳みそ
  • プログラミングとアプリ開発の違い : 404 Blog Not Found

    2008年05月19日11:45 カテゴリYAPC::AsiaLightweight Languages プログラミングとアプリ開発の違い ああ、YAPC::Asia::2008のトリ、Perl Is unDeadを見せてあげたかったなあ。 プログラミングのジャンルと難易度(および Web プログラミング批判) - 黎明日記 だってそうだろ? 「 Web アプリケーション」なんてカッコイイ名前の割に、受け取ったデータを簡単に加工してデータベースに突っ込んで取り出して……それで終わりじゃないか。ビデオやスライドが上がるまでしばらくかかると思うので、とりあえずは以下をご覧あれ。 はてなブックマーク - タグ yapcasia2008 Simon Cozens - YAPC Asia and talking in Japan YAPC::Asia 2008 2日め - てきとうなメモ で、Sch

    プログラミングとアプリ開発の違い : 404 Blog Not Found
    loca1982
    loca1982 2008/05/31
    「プログラミングをしたいのか、自分が作ったプログラムを使わせたいのか。それが問題だ」
  • Joel On Software私訳 - なぜMicrosoft Officeファイルフォーマットはこんなにもややこしいのか (そしてその対処法を幾つか)

    訳してみた。あらためて、和訳はものすごく時間を要する作業だということがわかった。もうしないと思う。 注意:以下は意訳、適当訳、稚拙訳であり、誤訳を多々含んでいることは確実であり、Joel氏が当に以下のように述べているとは限りません。 なぜMicrosoft Officeファイルフォーマットはこんなにもややこしいのか (そしてその対処法を幾つか) Tuesday, February 19, 2008 先週、MicrosoftはOfficeのバイナリフォーマットを公開したが、このフォーマットは殆ど正気でないように見える。Excel 97-2003ファイルフォーマットは349ページのPDFファイルだ。でも待って、それで全部じゃない。このドキュメントには次の面白いコメントが書いてある。 それぞれのExcelワークブックは1つのcompound fileに収められている つまり、Excel 97-

    Joel On Software私訳 - なぜMicrosoft Officeファイルフォーマットはこんなにもややこしいのか (そしてその対処法を幾つか)
  • 理解することが書き直すことを意味するとき

    Jeff Atwood / 青木靖 訳 2006年9月18日 開発者に時間をどう使っているか聞いたなら、彼らはほとんどの時間コードを書いていると答えるだろう。 しかし、ソフトウェア開発者が時間を実際どう使っているか観察したなら、ほとんどの時間をコードの理解に使っていることがわかる。 ピーター・ハラムがこのことについて説明している。 どうしてコードを新規に書くより5倍もの時間をコードの修正に使っているのか? それは新規のコードはほとんどすぐに古くなるからだ。何か新しくコードを書く。コーヒーを飲んで一服する。すると突如として、コードは古いコードになっている。できたてのコードはせいぜい初期のデザインしか反映していないが、デザインの多くの部分は前もって現われるものではない。開発プロジェクトの多く が反復的開発手法を使っている。デザイン、コーディング、テスト、繰り返し。たくさんの繰り返し。すべてが新

  • 1