Life is beautiful: 私のとっておきのプログラミングスタイル
404 Blog Not Found の「LiveCoding に学ぶプログラミングの三原則」を読んでいたらどうしても書きたくなったので。あくまで私のスタイルなので、参考にするもしないもご自由に。 1. スタードダッシュでできるだけはやくめどをつける 学生時代から夏休みの宿題は７月中に終わらせていた私とすれば、ラストスパートよりはスタートダッシュで勝負する。どのみち、どこかで思いっきり頑張らなければならないのであれば、締め切り間際ではなく、スタート間際に頑張るべきというのが私のポリシー。十週間のプロジェクトであれば、最初の二週間が勝負。そこで八割がたのめどをつけておき、後は流す。最初の二週間がめどが立てられなければ、十週間で完成できる可能性は低いと考える。常にそういう姿勢でいれば、締め切りぎりぎりになって致命的な欠陥が見つかって痛いめにあったり、本当は大幅な設計変更をすべきなのに応急処置で
分裂勘違い君劇場グループ - 劇場管理人のコメント - 有能なプログラマの特徴を思いつくまま列挙してみる
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
プログラマの権利宣言
Jeff Atwood / 青木靖 訳 2006年8月24日 企業は開発者に給与として60-100kドル支払いながら、ひどい作業環境と汚い使い古しのハードウェアによって彼らを損なっている。信じられない話だ。そんなのはビジネス的に理屈に合わない。ところがそういうのをどこでも目にする。ソフトウェア開発者が成功するために不可欠なものを与えていな い企業がいかに多いかは驚くばかりだ。 そこでプログラマの権利宣言を採択し、成功に不可欠な基本的なことを否定する企業からプログラマの権利を守ることを提案する。 すべてのプログラマは2つのモニタを持つ権利を有する 下落する液晶ディスプレイの価格と、遍く存在するデュアル出力ビデオカードのことを考えるなら、開発者を1つのディスプレイに制限するのはばかげた話だ。ディスプレイを2つにすることによって得られる生産性の利益については、今では十分に説明されている。開発者の
小野和俊のブログ:プログラマー風林火山
アプレッソというベンチャー企業の CTO を務めて6年と2ヶ月になる。変化の激しいベンチャーに比較的長い期間身をおいていたので、社内外のいろいろなタイプのエンジニアと仕事をしてきた。 あるエンジニアが参加することで開発チームが短い期間で大きく変わったこともあったし、開発チームのメンバーが15人いた頃よりも、お互い補い合えるエンジニアが5人くらいの頃の方が成果が出たりすることもあった。 そういう経験を重ねていくにつれ、私の中では、スターエンジニアと呼べる人たちの持っているものについての、いくつかの類型ができてきている。今まで一緒に仕事をしていく中で本当に心強かったのは、最近エンジニアのキャリアパスの議論でよく言われるような財務のわかるエンジニアとか営業もできるエンジニアではなく、あるいは人と異なるユニークな能力を身に付けようとしているエンジニアでもなかった。ではどういうエンジニアが、というこ
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%フルスクラッチで書いていた人はいませんでした。たいていは関数単位でコピーし、それを適宜書き換えるというやり方をしていました。学校のテストでは反則もいいところですが、大人の世界ではこ
ネットの時代には「知識量・記憶力」よりは「適応力・応用力」の方がずっと大切
先日の「習作UI: 縁日の金魚を再現してみた」というエントリー。特に深い意味もなく作ったのだが、ソフトウェア・エンジニアを目指す学生さんのためにひとこと付け加えておきたいのは、この業界で本気で成功しようと思ったら、この程度のプログラムは、シミュレーションの専門家でなくともサクッと作れるように自分を鍛えておかなければいけない、ということ。 この業界で働きはじめると、担当した仕事によって、データ解析・Java・３D・シミュレーションなどのある特定の分野のプログラミングの経験を積むことになる。そういった経験を通して特定の分野を深堀りしてエキスパートになるのはおおいに結構なのだが、往々にして落ち込んでしまうのが「ボクはJavaのエキスパートだからRubyではプログラムは書かない」、「シミュレーションのことならそれに詳しいエンジニアがいるんだからその人に頼んで」、「今からFlashを勉強している時間
議事録のプロ
システム構築の現場は，人と人とのコミュニケーションの場でもあり，ヒアリングや報告などさまざまな目的の会議がたくさん開かれる。そこで問題となるのが「議事録」だ。会議の議事録の取り方を観察していると，実に様々な流儀・方法を目にすることができる。 時々見かけるのが会議をすべて録音して，後日，誰かがほとんど1日費やして聞きなおしてすべて書き出すというもの。出来上がった議事録は数ページに及び，それを関係者に配ったとしても誰も見ようとはしない。それほどに冗長な議事録ではなくても，議題ごとに誰が何と言ったかについて克明に記述された議事録はよく目にする。 第一話で登場したIさんは要求定義ヒアリングのプロであるだけでなく，議事録のプロでもある。Iさんに「議事録の書き方はどうしたらいいか」と尋ねると，「決まったことだけ書いてください。それ以外は基本的にいらないといっていいでしょう」と言い切る。 会議の場では様
プログラマの生産性を少ない努力で高める１０の方法*ホームページを作る人のネタ帳
今回は元記事と私の観点は少し違います。 元記事： Simple Productivity: 10 Ways to Do More by Focusing on the Essentials 元記事はプログラマの事をさしていませんが、見れば見るほどプログラマ向けの記事かと思います。 現在日本では殆どのWEB製作に関わる人が、あれもこれもしなければならない状況にあります。 html 各種プログラム FLASH デザインなど等。 これらを、勉強もしなければならないし、作成もこなしていかなければならない。 そんなときに役に立つ、これは少ない努力で、なるべく多くの生産性を生む方法です。 １０の方法は以下に。 １）頭をスッキリさせてください 出来れば一日１時間ほどの休憩をとってください。 情報の収集などもやめ、出来ればコミュニケーションもストップし、一人になりましょう。 その時、あなたにとって重要な事
できる開発者になるための7つの習慣 - builder by ZDNet Japan
Sun Microsystems Asia-PacificのスタッフエンジニアであるLee Chuk Munn氏によると、アプリケーションを書くことは本を執筆することに似ているという。 「私はさまざまなプログラミング言語を学んできた。しかし、どんな言語を使ってプログラムを書いているかは問題ではない。書く物語がよいものでなければいけないのだ」Lee氏はZDNet Asiaの電話インタビューでこう答える。ソフトウェアのプログラミングでは27年の経験を持つベテランのLee氏はSunのソフトウェア部門で働いており、社内の開発者やJavaやSolarisを使用している個人ソフトウェア開発者のネットワークを指導している。 彼はこう続ける。「プログラミングは解決策の一つの表現にすぎない。プログラミングの多くを構成するのは、問題を理解して認識し、助けを得ることだ。この考え方はすべてのプログラミング言語にお
Geekなぺーじ : 良いプログラマの見分け方
「How to recognise a good programmer」という記事がありました。 良いプログラマを見分けて雇用するためのTIPSが書いてありました。 原文前半では、Paul Graham氏が書いている「The 18 mistakes that kill startups, 日本語版:スタートアップを殺す18の誤り」というエッセーに書かれている「90年代のE-コマースで多くのベンチャーを失敗させたのが質の悪いプログラマであるが、プログラマではない起業家には良いプログラマと悪いプログラマを見分ける術がない。」といった内容に対して反論すると書いています。 見分け方をまとめると、以下のようになるそうです。 流石に全ての項目を満たすような人は少ないそうですが、どれか一つでもあてはまる項目があれば、それは良いプログラマなのかも知れないそうです。 原文には、詳細な説明があるので興味のある
「作っては壊す」過程があってこそ良いものが作れる
iPhone用の「はてな人気エントリーリーダー」、そろそろ形になってきたのだが、作ってみていろいろと発見した部分もあったので、全面的にクラス構成を見直し、大幅に書き直した。 HTTPで通信をしているコードが二カ所に分かれていたので、それをDataOverHTTP/XMLOverHTTPという二つのクラスにまとめ（XMLOverHTTPはDataOverHTTPのサブクラス）、はてな独自のRSSフィードを読んでいるコードから一般的なRSSフィードを扱うコードをくくりだしてRSSFeed/RSSFeedLoaderという二つのクラスにまとめて、あとで別のアプリケーションで再利用することを可能にした。それに加えて、各種ローダーに非同期通信をさせる主体をController（HotEntryViewController）からModel側（HateneHotEntry）に移すことにより、難解になりが
アキバ系!文京区本郷四畳半社長: 0を1にする力と1を10にする力
東京都文京区本郷でとあるCMS開発会社を営む社長のブログ。さっきまで「越後のCMS問屋」だったのですが、会社が新潟に移転したと勘違いされたようなので変えました。 モバイル、ゲーム、フィード、Ajax、Flash、ハイテクグッズあたりのはやりモノが好きです。 最新作「メルルーの秘宝」がドワンゴから提供中 週刊アスキーで「2045年の週刊アスキーをつくる」連載中 最近になって、思い出したことがあります。 誰が言ってたか忘れてしまいましたが、「0を1にする能力と、1を10にする能力は違う能力だよ」という言葉です。 小室哲哉あたりだったかもしれません。 凄く能力があるプログラマーがいたとして、プログラマーの評価というのはどのようにされるべきでしょうか。 ・バグの少ないコードを書く ・最適化されたコードを書く/またはコードの最適化が上手い ・保守性/拡張性の高い設計をする ・コードを書く
プログラマーの義務宣言 : 404 Blog Not Found
2007年04月13日07:30 カテゴリArt プログラマーの義務宣言 Objection, Your Honor! プログラマの権利宣言 すべてのプログラマは2つのモニタを持つ権利を有する すべてのプログラマは高性能なPCを持つべきである すべてのプログラマはマウスとキーボードの選択の権利を有する すべてのプログラマは快適な椅子を持つべきである すべてのプログラマは高速なインターネット接続を持つべきである すべてのプログラマは静かなる仕事環境を持つべきである すべてのプログラマはVGAモニタで作業する術を学ぶべき 君たちはどうやってLinuxやFreeBSDをラックマウントサーバーに仕込むんだい? Xがないと手も足も出ないなんてことないだろうね。 できればさらにシリアルコンソールで作業する術も学ぶべき。私は一度海外の顧客が壊してしまったSunのFirmwareをリモートで修復したことが
Getting Real by 37signals
Heads up! This page uses features your browser doesn’t support. Try a modern browser like Firefox or Chrome for the best experience. sidebar#close mouseup->tweet#update input->tweet#update keydown->tweet#update scroll@window->tweet#update" data-bookmark-id="/gettingreal"> P��� ���� Getting Real The smarter, faster, easier way to build a successful web application Start reading →
まさかの日記:MSの某氏との会話ログ
コンピュータサイエンス系の人たちの間では、サーチのテクノロジーで人気があるのはリリバンシー、次はバーティカルサーチ。 他の要素としては、クローリングとインデキシング、クラウド系というところらしい。 サーバをグリッド化（やや死語だな）して、、みたいなのは、コンピュータサイエンスというよりはエンジニアリング。 昔、シックスアパートの某Perlギークの人と話をしたとき、「自分はエンジニアリング系じゃないんで、、」と言っていた。そのときはエンジニアリングという言葉の定義がよくわからなかったけど、なんとなくわかってきたかも。 あ、全文検索とかマイニングとかも面白いといっていた。まあこれは要素技術だけど。Luceneを作った人が別で作ってる奴が結構良いって。なんだろ。SolrかHadoopか。 あと、エンタープライズサーチ。例えばメール。誰がどんな単語を多用しているかをサマリーしたり、検索させたり。
ペーパープロトタイピング事例集 | 秋元@サイボウズラボ・プログラマー・ブログ
実際に動的なウェブサイトを作ってしまう前に、紙上でデザインや部品の配置、画面遷移などを確認するペーパープロトタイピングという設計技法があります。書籍もありますね。 ペーパープロトタイピング 最適なユーザインタフェースを効率よくデザインする そのペーパープロトタイピングの事例を集めたページというのがありました。たとえば次のこれは、2000年5月31日にスケッチされたtwitterのプロトタイプです。当時はstat.usという仮名で、これによるとtwitterはLiveJounal(ブログサービス)とAIM(インスタントメッセンジャー)から最初の着想を得てから実装まで5年以上の間があったことになりますね。 FlickrのPlacesページやVimeoなどのペーパープロトタイプの写真も紹介されています。 こちらは韓国のポータルサイトDaumのAjaxウェブメール開発時に行なわれた、ペーパープロト
OBB vs AABB - Radium Software Development
This domain may be for sale!
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
