新連載として「オブジェクト指向の再定義」を開始する。特に最近の アジャイル開発の動向から、オブジェクト指向を見つめなおしてみたい、とい う動機だ。なおこの連載は、最近の本、セミナー、blog、私信メール、そして 実践から感じていることを、新発想として提示していこう、という意気込みで あり、まだ業界としての定説に至っていない、もしくは至りつつある内容が中心である。ぜひみなさん、読んだ感想をフィードバックして、平鍋に連載の勇気をください。
過酷な労働条件を受け入れるプログラマというのは、ダンピングをしています。 つまり、労働力の不当な安売りです。 本来、プログラマは、サービス残業を強要されたら、それを拒否すべきです。 あらかじめ無理なスケジュールだとわかっているプロジェクトも、拒否すべきです。 安い賃金で働くことも拒否すべきです。 それらを拒否せずに、受け入れるプログラマが多いから、他のプログラマまでそれらを受け入れなければならなくなるのです。 もちろん、見積もり段階では十分な余裕を見ていたのに、予想もしないトラブルが発生して残業や休日出勤する分には仕方がありません。 しかし、はじめから無理なことが分かっているプロジェクトを引き受けるのは、話が別です。 もし、ほとんどのプログラマが、無理なスケジュールのプロジェクトを拒否するのであれば、無理なスケジュールのプロジェクトを拒否することで会社をクビになることも昇進で不利に扱われる
「ヱブ弐点零デ、マツシユアツプ」とか言ってる場合じゃないんですよ。Nintendo DSのカートリッジ自作ハックくらいしろと。OSカーネルやコンパイラを書けと。 本職のプログラマを名乗るなら、「珠玉のプログラミング」を読んで問題を解いて欲しい。Perl/PHP/Ruby/Pythonしか書けないようでは、本物のプログラマと呼びにくい。JavaとLispとC/C++(まあ、いまならC#ですかね)も覚えてほしい。ちなみにWrite Great Codeも良いらしいです。 本書でいうグレートコードとは「高速・コンパクトかつ、リソースを無駄使いせず、可読性に優れ、保守が容易で、一貫したスタイルに従った、系統的に設計され、拡張性に富む、十分にテストされ、確実に動作し、ドキュメントが整備されている」コードです。 つまり、要点としては、コンピュータ・サイエンスとソフトウェア工学は、みっちりおさえてこそ、
「Ten reasons why every programmer should learn C」という記事がありました。 個人的な感想ですが、何と無く言いたい事はわかる気がしました。 ただ、多少誇張している(言い過ぎ/嘘)かなと思いました。 あと、恐らくLinuxとオープンソースなどを念頭において書いているんだろうなと思いました。 ちょっと言いすぎ感も漂う内容でしたが、面白かったので訳してみました。 誤訳や勘違いなどが入っている可能性があるので、詳細は元記事をご覧下さい。 以下訳です。 全てのプログラマはC言語を学ぶべきである。 C言語を学ぶ事により得られる利点は無視できないほど大きい。 C言語を学ぶ事により、仕事の機会に恵まれるだけではなく、コンピュータへの理解が深まる。 1) C言語は、C++やJavaと比べて低レベル(low level)な言語である。 低レベル言語を使ってプログラ
1. 割り箸を職場に常備する 草野球をやっていた人は子供の頃、怒られたことがあると思う。 打った後にバットを投げ出して走り始めてはいけないと。 いつも使うものは丁寧に扱いなさいと。 プログラマーがキーボードやマウスを油で汚すなんてことは言語道断である。 ポテトチップスや唐揚げ、スナック菓子などを直接手で食べてはいけない。 かならず割り箸を使って手を汚さずに食べる。 それがプログラマーとして最低限の作法。 XP な職場であればあるほどお菓子が用意されていたりするから、 なお要注意である。 文章を書く場合でも、ソフトウェアを開発する場合でも、 プレゼン資料を作る場合でも、 成果物のイメージが明確になっている場合には キーボード&マウスは極めて有効なデバイスだ。 だが、構想を練っている段階やアイデアを膨らませている段階では、 紙とエンピツでアナログなやり方をする方が圧倒的に仕事が進む。 これは誰
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"> 0��]�U P7�]�U Getting Real The smarter, faster, easier way to build a successful web application Start reading →
1960 年生まれ,独身フリー・プログラマの生態とは? 日経ソフトウエアの人気連載「フリー・プログラマの華麗な生活」からより抜きの記事をお送りします。2001年上旬の連載開始当初から,2007年に至るまでの生活を振り返って,週2回のペースで公開していく予定です。プログラミングに興味がある人もない人も,フリー・プログラマを目指している人もそうでない人も,“華麗”とはほど遠い,フリー・プログラマの生活をちょっと覗いてみませんか。 フリー・プログラマには上司がいない。私の場合には部下もいない。 1 日中寝て過ごしても,文句を言う人はだれもいない。まさにナイナ イづくしの結構な生活と思われるかもしれないが,それに甘えていて はお金は入ってこない。世の中はよくできている。 フリー・プログラマになるのは簡単だ。会社に辞表を出して「今日 から私はフリー・プログラマです」と言えばいい。だが,フリー・プ ロ
Landscape トップページ | < 前の日 2007-01-15 2007-01-17 次の日 2007-02-27 > Landscape - エンジニアのメモ 2007-01-17 ソフトウェア見積りを読了 当サイト内を Google 検索できます * ソフトウェア見積りを読了この記事の直リンクURL: Permlink | この記事が属するカテゴリ: [本] ソフトウェア見積り―人月の暗黙知を解き明かす スティーブ マコネル / Steve McConnell / 田沢 恵 / 溝口 真理子 / 久手堅 憲之 発売日: 2006/10 amazon で詳しく見る bk1で詳しく見る スティーブ・マコネルの『ソフトウェア見積り』を読了した。 『ソフトウェア見積り』は、ソフトウェア開発における工数や期間を見積もる方法について詳細に解説した本。見積もりについて学んだことのない私に
(島国としてのRuby) スピーカー Dave Thomas - Dave is a principal in The Pragmatic Programmers, LLC ( http://pragmaticprogrammer.com ) プロフィール Dave Thomas is a writer, trainer, and primarily a programmer. He's the author of 7 books, including The Pragmatic Programmer (with his partner Andy Hunt), Programming Ruby, and Agile Web Development with Rails. He first started using Ruby in 1998. He's the author of RDoc
今は昔、ひとりの駆け出しプログラマがいた。 その頃はCOBOLばかりで、しかも保守ばかりだった。そこで、独学で身に付けたCをやらせてもらえる仕事を奪ってきては書いた。スクラッチプロジェクトを見つける嗅覚だけは抜群だった。たいていは人手が足りず、新人でも歓迎されたからだ。 そこには優れた先達がいた。「スーパープログラマ」と呼ばれていた。 なぜ「スーパー」なんて修飾子がついたかというと、速いプログラムを早く書いたから。もちろん、「速い」とは少ないメモリ・小さいプログラムのことを指し、「早く」とは実装が早いこと。実際、彼らが書いたプログラムはサクサク動き、バグは簡単に見つけられた。 教えを請うと、先達たちは、おしなべてこういった。 最初に学ぶべきは、コンピュータサイエンス。特にアルゴリズムとデータ構造だ。実践的なコーディングテクニックよりも、まず基礎だ。これはコードを書きながらではなく、文献から
ネットワーク応用通信研究所 特別研究員。島根の田舎に住みながら国際的なオープンソース・ソフトウエアの開発に挑むプログラマ。家族6人で幸せな田舎暮らしを満喫している。バグと原稿の締め切りがなければもっと幸せなのに,と思いつつ,考えてみれば,それらがないならないで,別の困ったことがあるよなあと思う今日このごろ。 皆さんは「サピア・ウォーフ仮説」をご存じでしょうか。これは言語学における古典的な仮説の一つで,「人間の思考は使用する言語とそれに付随する文化に影響を受ける」というものです。もし仮に数字を3までしか持たない言語があったとすると,その言語を使用する文化に生まれ育った人間は3以上の数を認識できない,といったことです。言語学的にはこの仮説は否定されているようですが,日常生活の中では,この仮説が本当ではないかと感じる経験がたびたびあります。 例えば,私は年に数回海外に出張して講演をする機会があり
賃貸暮らしのわが家の地震対策【揺れから命を守る編】 以前のブログでも記載した、防災の優先順位に基づいて対策を進めています。まだ手をつけられていない部分もありますが、ある程度まとまってきたのでざっくりとご紹介していきます。 優先順位別に改善していっているため、今回は主に地震の揺れ対策がメインになります。…
ソフトウェア技術者のある一定の割合は深く深く技術に潜っていく。そしてそれは大きく3つの道へと分かれていく。 OS Hardware 言語 自分は「言語」タイプだった。高校生の頃いろいろな言語を触って、「BASICは違う」「PASCALは違う」となり、15歳で「自分で作ろう」と思った。その後おもちゃのような言語はいくつか作ったが、決意から15年を経て初めて作った本格的な言語がRubyだった、とのこと。 まつもとさんの基調講演をまとめた記事。上記引用以外にも色々示唆に富む内容が盛りだくさん、且つジョークが満載で面白かった。Yugui さん GJ です。 昔からよく日記は拝見しており、且つ YAPC::Asia などここ最近まつもとさんのスピーチを聴いたりする機会が結構ありました。まつもとさんは、Ruby を作ったという偉業がスゲーというのももちろんありますが、Geek でもありつつ常識人で且つ
悪態のプログラマとある職業プログラマの悪態を綴る。 入門書が書かないプログラミングのための知識、会社の研修が教えないシステム開発業界の裏話は、新人プログラマや、これからプログラマを目指す人たちへのメッセージでもある。 「プログラマ35歳定年説」という言葉がある(30歳説、40歳説もあるが、数字そのものはあまり問題ではない)。加齢によるスキルダウン、体力ダウンを連想させる言葉だが、むしろ、会社組織的な背景が強いようだ。 システム開発業界では、「彼はまだプログラミングしかできない」といった言葉をよく耳にする。つまり、この業界の中では、プログラミングは一般的に「簡単な仕事」とされているのである。本当はそんなに簡単なわけではないのだが、他の仕事はもっと難しいということだろう(※1)。 開発の仕事を、「簡単だとされている」順に並べれば、テスト、プログラミング、設計、要求分析というように、ウォーターフ
最近のシステム構築では仕様書をきちんと記述しないで、いきなりツールを使ってプログラムを作成することも多いようだ。否定する気はないが、駆け出しのころはしっかり自分の手で仕様書を書いた方がいい。 前回は、SEを目指している皆さんに向けて、仕事に取り組む姿勢の観点からアドバイスを書いた。今回は、SEに求められるより具体的な知識やスキルの向上に役立つ話を書いてみたい。 SEとして必要な知識やスキルは非常に広範にわたる。経験を積み、上級SEになってくればより経営的な知識が求められるが、最初のころは、システム構築に必要な知識やスキルが特に重要になる。今回は、システム構築における基礎的なスキルの開発方法を紹介しよう。 仕様書を書くこと 最近のシステム構築では、仕様書をきちんと記述しないで、いきなりツールを使ってプログラムを作成したり、システムを構築したりする手法が取られることも多いようだ。こういった手法
文化祭でカセットコンロ4台の上に鉄板2枚載せて焼きそばを作っていたらガスボンベが爆発、生徒15人負傷…私立豊南高校
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く