プログラミング技術さえ身に付けば、プログラマとして一人前と言えるでしょうか？ プログラミングを始めたばかりのうちは、プログラミング言語の習得や周辺の知識を得ることばかりに目がいきがちですが、それだけでは一流のプログラマになれません。（プログラミング言語を学びたいならこちら：写経で身につけるプログラミングの基本） プログラマとして成長するためには、プログラミング技術を学ぶだけではなく、良いソフトウェアを作るための良い習慣を身に付けることが大事になります。初心者のうちに良い習慣を身につけておけば、ただ知識を追い求めるのではなく地に足をつけた成長ができるはずです。 本記事では、私自身も先人たちから学んだプログラマが身につけたい３つの習慣について書いています。 自分で書いたすべてのコードを説明できるようになろう プログラミングは全て、明確な判断の結果です。if文を使うべきかどうか、どのAPIを使う
去年の年末、Facebookで以下の様な画像が流れてきて自分もついついシェアしたんだけど、久々に、というか、自分にとってのここ最近の課題をドンピシャで突かれたような気がして、しばらく頭から離れなかった。 出展: 中村 修治 - 中村 修治さんの写真アルバム | Facebook 「プロ」か「アマチュア」か、というのはこの際どうでも良くて、この図の、上の曲線が、目指すべきところだなって話なだけなので、とりあえずその話をまとめてみることにする。 けど、まぁ、だいたい、こういう話をまとめるのは苦手だし途中で面倒になってしまうので、以下サブセクションだけ先に作ってみたものの、ちゃんと書くかどうかわからない... が、まあ、いい！あと、なんかグダグダ書いてしまいそうだけど、結局、サブセクションのタイトルにしたことをこねくりまわしているだけです。 作ってみるまでわからない 何にも言えることだけど作って
何が「仕事」の中心かによって解釈が異なるのだと思う。でも、言っていることはほとんど一緒に見える。 Decent Point：仕事が遅い人の共通項 はてな匿名ダイアリー：精神論ではない仕事を速くこなす技術 1つ目のエントリーは主に未経験の事柄を学ぶ話が焦点。だから、「仕事」の中心が未経験な事柄を繰り返し行うことなのだろう。定型的作業じゃないものが仕事の中心なので、「未経験な事柄への対応力が弱いおよび自分なりのやり方が構築できない」＝「仕事が遅い」となっているのだと思う。2つ目のエントリーの仕事の定義は明確ではないけれども、創造力というキーワードや目的達成手段を自己決定できるという前提からすると定型的作業じゃないものが仕事の中心であるということでよいのだろうと思う。 1つ目のエントリーの3つのポイントは以下のとおり。「素直」かそうじゃないかは以下の振る舞いから他者が判断している事なので本質的で
おおいしつかさ 旅行とバイクとドライブと料理と宇宙が好き。 Ubie Discoveryのプログラマ。 ぼくは36歳です。けっこう大きなサイトで、RailsやJavascriptを書いたり、パフォーマンス改善したり、iPhoneアプリの開発でObjective-Cを書いたりしています。マネージメントはしていなくて、今でも普通にエンジニアとして働いています。 35歳定年説の35歳を超えてから1年以上が過ぎたところですが、昔のようにはいかなくなってきたところ、昔と変わらないところ、昔よりよくなってきたところなどがいろいろあります。年を取ってもエンジニアを続けたい人の参考になるかどうかわかりませんが、そういう人たちのためにぼく個人の体験をここに書いておこうと思います。 1.理解できるまで聞き返す 特に若い人たちとの会話で痛感するのですが、相手の言いたいことを一度で理解することが難しくなってきまし
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは、R＆D統括本部 開発推進室 セキュリティプラットフォーム技術 セキュリティスペシャリストの戸田 薫です。 今回は、私たちが普段からヤフーのシステムに対する入力にどのような注意を払っているのか、そのいくつかをご紹介致します。 入力とは? Webサイトを運営している場合、どのような入力があるでしょうか？ たとえば、Webサービスには、以下の入力があります。 Cookie URL GET/POSTのデータ ファイルのアップロード その他リクエストヘッダ そのほかにもいくつもあります。 環境変数 設定ファイル クローラが取得したデータ パートナー企業のAPIから取得したデータ（XMLやJSONなど） パートナー企業の入稿用 F
少し前に映画『ソーシャル・ネットワーク』を観ました。 映画を観た後3時間くらい興奮が収まらず、気を落ち着かせるまでに随分苦労しました。興奮もようやく収まりましたので（笑）、感想を書こうと思います。 なぜそんなに興奮したのか。 1人のプログラマが創ったウェブサービスが世界中に広がったことに対する、プログラマとしての共感。マーク・ザッカーバーグが会社を大きくし、金銭的に大きな成功を収めた事に対する、起業家としての共感。自分の境遇と重なるこうした要素が、他人事では無いストーリーとして、面白かったのです。 しかし、映画を観た他の人の感想を眺めるうちに、他の人が言及していない部分に自分が強く反応していたことに気付きました。「ウェブコミュニティ設計者」としての共感です。ザッカーバーグも自分も、「ウェブコミュニティ設計者」という同じ職業の人間だ！、と強く思いました。 世の中にウェブサイトと呼ばれるものは
今週は、野中郁次郎氏とジェフ・サザーランド氏というアジャイル開発手法「スクラム」の生みの親2人が基調講演を行った歴史的イベント「Innovation Sprint 2011」のレポートを2本公開し、たくさんの方に記事を読んでもらうことができました。 スクラムの生みの親が語る、スクラムとはなにか？ たえず不安定で、自己組織化し、全員が多能工である ～ Innovation Sprint 2011（前編） 重要なテクノロジーは10名以下のチームで作られた ～ Innovation Sprint 2011（後編） この記事きっかけに「スクラム」に興味を持ったという読者もおられたようで、そんな方のために（かどうかは分かりませんが：-）、「Innovation Sprint 2011」の実行委員長だった川口恭伸氏が「10分でスクラム」というスライドを公開しました。
完全に一致を作るための勉強法 たくさんのアクセスありがとうございました。 コメントもたくさん頂いてまして、それにお答えするのに「ブログでもつくろうかいな」とのぼせましたが、そんなテーマで続くわけもないので、やはりアノニマスダイアリーにしました。 【製作期間について】 まず、皆さん仕事しながらたった4ヶ月で！と褒めて頂いてますが、たったじゃないですよ。4ヶ月って。 仕事が終わって、毎日2～3時間。土日関係無くやると、多分300時間くらいになります。 専門学校の2年間の授業時間がこのくらいだったりするんじゃないですかね。結構長いです。 【モチベーションの維持について】 モチベーションを保つのがすごいというのも褒めてもらいましたが、私は一回やり始めると、意外に長く続きます。 コツがあるんです。 毎年、日々の単純作業が続かない新入社員が入ってきますが、そんな新人に言います。 「息をするように続ける
2010/12/07 「アジャイル」といえば、ソフトウェアの開発手法として近年注目を集めてきた。半年や1年といったプロジェクト期間で完成品を作る「ウォーターフォール型」ではなく、2週間程度の短いサイクルで、途中経過であっても実際に動くものを見ながら開発を進めるスタイルだ。事前にシステム要件を定義しづらい場合や、市場変化が激しい場合などに柔軟に対応できる。 アジャイルは開発スタイルの実践を指すが、これを受託開発の契約形態に当てはめようという企業が登場して注目を集めている。中堅SIerの永和システムマネジメントは2010年11月11日、初期費用0円、月額利用料15万円からという、まったく新しい契約形態による受託開発のトライアルサービスを発表した。永和システムマネジメントに話を聞いた。 こう語るのは永和システムマネジメントサービスプロバイディング事業部の木下史彦氏だ。アジャイルといえば、開発の方
前回から、11のネガティブ特性の3番目である「うっかりが多い、思慮が浅い」を説明している。11のネガティブ特性は以下の通りである。 先を読まない、深読みしない、刹那主義 主体性がない、受け身である うっかりが多い、思慮が浅い 無責任、逃げ腰体質 本質が語れない、理解が浅い ひと言で語れない、話が冗長 抽象的、具体性がない、表面的 説得力がない、納得感が得られない 仕事が進まない、放置体質 言いたいことが不明、論点が絞れない、話が拡散 駆け引きできない、せっかち、期を待てない 前回は、ソフトウエアベンダーF社に所属しているシステムエンジニアである二宮氏（仮名）の事例を紹介した。百貨店向けシステム開発プロジェクトにおける要件定義の際に、二宮氏は正論だが思慮の浅い発言をした。顧客は二宮氏の発言に怒り、プロジェクトは混乱して窮地に追い込まれた。 今回はその続きである。「うっかりが多い、思慮が浅い」
ノーベル化学賞に輝いた鈴木章・北海道大名誉教授（８０）は８日、産経新聞の取材に応じ、「日本の科学技術力は非常にレベルが高く、今後も維持していかねばならない」と強調した。昨年１１月に政府の事業仕分けで注目された蓮舫行政刷新担当相の「２位じゃだめなんでしょうか」との発言については、「科学や技術を全く知らない人の言葉だ」とばっさり切り捨てた。 受賞理由となった「パラジウム触媒でのクロスカップリング技術」は医薬や液晶など幅広い分野で実用化されている。それだけに鈴木さんは「日本が生き残るためには付加価値の高いものを作り、世界に使ってもらうしかない」と、科学技術の重要性を指摘した。 昨年の事業仕分けで理化学研究所の次世代スーパーコンピューターの予算が削られたことについては「科学や技術の研究はお金がかかる。研究者自身の努力や知識も大切だが、必要なお金は政府がアレンジしなければならない。（スーパー）コンピ
そろそろ話しても害はないと思うので昔話をしてみる。 ２年前ぐらいにCGMベースの生放送サイトをつくったときの話だ。 すでに生放送のシステムは１年前に運用開始していて、いろいろな番組をつくって配信していたのだが、自前で番組までつくるモデル（公式生放送）ではスケールして成立するビジネスモデルをつくるのが難しい。だから、もともとユーザが自分で生放送ができるサイトで勝負するというのが当初からの戦略で、１年間やっていた公式生放送は、成功できるユーザ生放送システムとはどう実装すればいいのかを探るためのプロトタイプという意味合いが強かった。 年末を目標としてサービスを立ち上げるという目標でユーザ生放送企画開発チームが発足したのは２年前の夏前ぐらいだ。開発期間が半年ぐらいしかなかったが、すでに公式生放送のシステムは１年ぐらい運用していてベースとなる技術は蓄積されていたのでそれほど不可能な目標ではなかった。
新人にソフトウェア開発の作業手順を教えていると、思いも寄らぬ質問を受けて戸惑うことが有る。例えば、先日はこんな質問を受けた。 「仕様書はどの程度まで書けばよいのですか？」 あまりにストレートな質問なので何と答えるべきか一瞬戸惑ってしまったが、考えてみれば仕様書の記載をどの範囲でどのような粒度でどこまで書くべきなのか？という基準は何も存在していないのだ。品質管理の規定に従ってレビューや照査・承認のプロセスは存在するものの、それは書いた後で行われるプロセスだし、ソースコードと違って「動作する」「動作しない」という明確な境界線も存在しない。内容にモレや矛盾が存在する仕様書は珍しくないし、書き手によって仕様の構成や内容が違うことも有るのだ。 しかし、実際問題として仕様書を上手に書く人はいるし、チーム内には失敗事例を元にまとめた仕様書ガイドラインも存在している。だから「完璧ではないけれど、それなりに
「バグ数には興味ないのだよ」――顧客が喜ぶテスト仕様書とは？：誰にでも分かるSEのための文章術（11）（1/2 ページ） 「提案書」や「要件定義書」は書くのが難しい。読む人がITの専門家ではないからだ。専門用語を使わず、高度な内容を的確に伝えるにはどうすればいいか。「提案書」「要件定義書」の書き方を通じて、「誰にでも伝わる」文章術を伝授する。 メーカーが機械を納入する際は、耐久試験や性能試験などの結果を添付して、問題がないことを顧客に確認してもらいます。同様にシステム開発においても、テスト結果を顧客に提示してシステムに問題がないことを確認してもらう必要があります。 今回と次回の2回にわたって、「テスト仕様書」の書き方と表現のポイントを説明します。 今回は、「顧客にとって良いテスト仕様書」とは何か、「顧客にとって良いテスト仕様書」にするためには何を記述すればよいのか、テスト仕様書のおおまかな
ソフトウェア開発の現場にいるベテランには、他の人の手本となるような達人もいるけれど、その一方で見習ってはいけない悪い見本の人も少なからずいる。その一例。 開発資料を作らない 「ソースコードを読めば分かる」「資料を書くのは労力の無駄」と豪語して資料を何も作らない。後からフォローする人は、そもそも何をやっているコードなのか？などコードの設計思想や背景を読み取れないので苦労する。 自分の立場を分かっていない 開発チームを良い方向へ導くとか、若手の指導を行うという積極的な態度に欠ける。チームへの協力的な姿勢が無く、組織のあり方とか、ビジネスの方向性といった視点を持っていない。 知識を共有しない 「自分の持っている知識は大したことない」と謙遜するそぶりを見せながらも、自分からは決して情報発信を行わない。他人の情報には文句を付けるのに、自分からは何も出そうとしない。 新しい技術に挑戦しない 歳をとって
メキシコ湾で4月下旬に爆発事故が起きた海洋油田からは米政府の推定で70万キロリットルもの大量の原油が流出、米ルイジアナ州などの沿岸はどす黒い原油で汚染された。油田の操業者である英石油大手ＢＰは、水深1500メートルの海底にある油井の噴出口をなんとか封鎖しようと様々な技術を動員したが、なかなかうまくいかず、7月中旬になってようやく原油流出が止まった。ただ、これも抜本的な解決策にはならないとの見方が多く、油井を完全に封印するまでは予断を許さない。 今回の事故は世界の海洋油田の事故としては最悪の展開になったが、エネルギー業界関係者の中には「いつか、どこかでこんな事故が起きると思っていた」と事故をある程度、予見していた人もいる。深海油田の開発、原油生産はそもそも地上の油田ほど簡単ではなく、水深が増す毎に幾何級数的に難度が増すからだ。人間が潜ることのできない深海では、何かのトラブルが発生してもすべ
WASForumに参加してきた。面白かった。なんとなく知っていたキーワードをちゃんと説明してもらって位置づけをはっきりすることができたし、今の流行りはどのあたりなのかを知ることができた。プログラムはこちら。Twitterの#wasfタグを使っていたらしい、それに関するつぶやきはTogetter：WASForumまとめにまとめられていた。 終始、高木さんがネタになっていたのは面白かった。そして、高木さんもそれを遠慮なく利用して、セッションハイジャックの実例を…。たのしいフォーラムでした。講演者のみなさま、開催者のみなさま、おつかれさまでした。 門林さん：オープニングセッション -「Webサイトを安全に使う秘技とユーザが直面する３つの危険」 ちょいとあおり気味のオープニングセッションだった。 松岡さん：国民のためのウェブサイトを運営するID認証の舞台裏 Yahoo JapanにおけるID認証周
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
