[出典] プログラマが知るべき97のこと 当サイトはオライリー・ジャパンによる公式なサイトではありません。 個々のエッセイは「CC-by-3.0-US」によってライセンスされています。
はじめに 僕がプログラミングを始めてから、もうすぐ12年になろうとしています。 この12年間、いろんな技術書を読んだり、仕事やプライベートでたくさんコードを書いたりしてきました。 最初に入ったSIerでは主にJavaを、前職の社内SE時代はC#をメインのプログラミング言語として使ってきました。 現在はRubyをメインで使っていますが、言語が変わっても、また何年経っても「これはあのとき学んだ知識が役に立ってるよなあ」と思う瞬間がときどきあります。 そこで今回はこれまでに読んだ技術書を一通り振り返り、「この本で学んだことは今でも役に立ってる」と思うものを17冊ピックアップしていきます。 おことわり (2014.09.29 20:00追記) このエントリのタイトルは「10年経った今でも役に立っている」という意味で付けています。「今から10年後まで役立つ」という意味ではありません。(紛らわしくてご
Javaプログラマやソフトウェア開発者として、私は「プログラマが知っておくべき…」というタイトルが付く記事から、多くのことを学びました。そういった記事は、特定のトピックに関する有益かつ詳細な情報を数多く与えてくれましたが、探し出すのが非常に困難でもあったのです。知識を探求する中でとても役に立つ記事を見つけたら、参考として何度も読み返せるようにブックマークしてきました。こういった記事を読むことは、どのプログラマにとっても有益になると思うので、私が集めた「 すべてのプログラマが知っておくべきこと 」を皆さんと共有する為にこれを書きました。 ここで紹介する記事は私が個人的にブックマークしたものです。「メモリ」、「Unicode」、「浮動小数点演算」、「ネットワーキング」、「オブジェクト指向設計」、「時刻」、「URLエンコード」、「文字列」などといった代表的なトピックについて載っています。このリス
2014年4月16日より2014年5月14日まで開催していたpaizaオンラインハッカソン(略してPOH![ポー!])Vol.2「女子大生とペアプロするだけの簡単なお仕事です!」で提出された最速コードはどのような高速化のアプローチでで生み出されたのでしょうか? POH Vol.2に登場した女子大生インターンプログラマの木野ちゃん(左のイラスト)にアルゴリズムを図解で教えるとしたら、どう教えるだろうか、という事で、今回は図解してみました。 今回は前回の最速コード発表レポート(【結果発表】女子大生プログラマの心を鷲掴みにした最強のコード8選)に引き続き、最速コードの裏側に迫ります。 ■高速化のアプローチ方法について 今回もPOH Vol.1 と同様に、POH Vol.2では計算量の改善による高速化を柱とするアプローチを想定して出題されました。基本は定数倍高速化によって想定解法よりも悪い計算量の
僕が使い始めた2008年頃と違って、現在はかなりRedmineが普及している。 ソフトウェア開発者だけでなく、製造業や製薬業、営業や事務、勉強会のタスク管理に使っている事例も多い。 最近特に目立つのが、初心者がRedmineを使っているものの、Redmineの良さを出し切れていない場面。 上記の資料では、「Redmineは、チームでチケットを消すゲーム」と定義して、わかり易く説明しているのがすごくいい。 アジャイル開発では、XPの計画ゲーム、Scrumのプロダクトバックログのように、ストーリーやタスクをチケット化して、イテレーション(Redmineならバージョン)単位にグループ化して、リリースしていく戦略を取る。 すると、チケット管理とは、チームでチケットを消すゲームなのだ、と感覚で分かるようになる。 この辺りの感覚は、40代以上の中年SEよりも、20代の若手PGの方がすぐに馴染んでくれる
「HRTの原則」という言葉をご存知だろうか。 これは書籍 Team Geek ―Googleのギークたちはいかにしてチームを作るのか で紹介されている言葉であり、本書ではほぼ一冊すべてをかけてこのHRTの原則とその実践方法とを様々な角度から紹介している。 1. 謙虚(Humility) 2. 尊敬(Respect) 3. 信頼(Trust) の3つの価値が大切にされており、エンジニアとしてもチームや組織、顧客との対話においてこれらの価値を重んじていくことが成功につながる、というものである。 あらゆる人間関係の衝突は、謙虚・尊敬・信頼の欠如によるものだ Team Geek p.15 プログラマとして成功するには、最新の言語を覚えたり高速なコードを書いたりするだけではいけない。プログラマは常にチームで仕事をする。君が思っている以上に、チームは個人の生産性や幸福に直接影響するのである。 Team
目次 はじめに 情報不安について 人の話を聞くこと 寝てから考えよう わ・ざ・と、ゆ・っ・く・り・、や・っ・て・み・よ・う ロビンソン式悩み解決法 驚き、最小の法則 むしょうに腹が立つあいつのこと あなたは、そのままでいいんです はじめからやり直したい症候群 人から信頼されるためにはどうしたらよいか トラブルがチャンス あなたはひとりではありません あなたのための聖書の言葉 ぜひ、感想をお送りください リンク集 更新履歴 はじめに 私はプログラマです。 プログラムを書いて生活の糧を得ています。 プログラマというのは精神的にも肉体的にも過酷な仕事だと思われています。 夜遅くまでディスプレイに向かい、 キーボードを叩き、ジャンクフードを食べながらバグをとる…そんな職業だと思われています。 確かにそういうところもありますが、プログラマも人間です。 不健康な生活を長いこと続けることはできません。
2. お前誰よ ところてん – http://twitter.com/tokoroten 大学時代 – – – – – 電子透かしの研究(B2~B4) コンシューマゲーム会社で9ヶ月のインターン(B3) 自然言語処理を利用したPhishing対策(B5~M2) 半導体計測器開発ベンチャーでバイト、C++と光学設計(B4~M2) IPA未踏ユース(M1)、学生ベンチャー起業(M2) 社会人 – 某通信会社の研究所(3年弱) – コンピュータウィルスの収集、分析 – クラウド、ビッグデータ関連の研究 – ドリコム(2年目) – インフラ → プロモーション分析 → アプリ分析 – 現在はソーシャルゲームのデータ分析 兼 企画含めた何でも屋 Copyright Drecom Co., Ltd All Rights Reserved.
This is why you shouldn't interrupt a programmer (なぜプログラマの作業に割り込むべきではないか) という4コマ漫画が話題になっていた。これは別にプログラマではなくても「わかるわかる」という感じの話。 コメントを見ると、だから作業を中断してもすぐ再開できるように自分の考えることをなるべく書き出すようにしているという人が結構多かった。なるほど。 今日は雨が降ったせいで予定が一つキャンセルになったことだし、ちょうどいい機会なので、文章で何かを書くということについて自分が思っていることを書いてみようとおもう。以前 Software Design のドキュメントの書き方特集みたいな号に似たような趣旨の話を寄稿したのだけど、「書く」というのは単に物事を忘れないようにするための行為に留まるものではなくて、自分の考えを整理するための道具なのだ、ということが
function myFunction() { var response = UrlFetchApp.fetch("http://www.google.co.jp/search?q=qiita"); var myRegexp = /<h3 class=\"r\">([\s\S]*?)<\/h3>/gi; var elems = response.getContentText().match(myRegexp); for(var i in elems) { var title = elems[i] title = title.replace(/(^\s+)|(\s+$)/g, ""); title = title.replace(/<\/?[^>]+>/gi, ""); Logger.log(title); } } [13-09-10 00:08:56:438 JST] Qiita [キータ
1986年生まれ。大分県出身。株式会社ZINEという会社とPLIMES株式会社という会社で生命に挑戦しています。 IT業界ではない人間の退職エントリは珍しいのではないか。 プログラマ界隈でよく見かける「○○(名だたる企業名)を退職しました」なんて目を惹くタイトルも、とりわけ出版業界では目にしない。文章を扱う仕事にも関わらず紺屋の白袴、医者の不養生、童貞汁男優、というわけである。 男として生まれたからには、やはり童貞汁男優のまま終わるわけにはいかない。文筆業のはしくれたるワレワレ編集者としては、生きた痕跡をもっとガシガシ書き記しておくべきである。というわけで、ぼくもはじめて退職エントリを書いてみようと思う。 技術評論社でのこれまで 4月30日に技術評論社を退職した。 技術評論社では入社以来1年半の間、Webアプリケーション開発のためのプログラミング技術情報誌、『WEB+DB PRESS』に携
2009 | 08 | 2011 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 2012 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 2013 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 2014 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 2015 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 2016 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 1
定期的にもやもやする なんか定期的にプログラミングの話が出てきて、そのたびになにやらもやもやします。 今回はそのモヤモヤを解消してくれそうな感じの記事があったので、その紹介と思うことをば。 プログラミングはそれ自体が目的であっていいって話。 とても理解できます。 プログラマって、もっと適当で良いと思うんですよね。 「理論的に」じゃなくて、もっと「感情的に」伝えたほうが面白いと思うんですよ。 ということで個人的には最初の方にあった以下の部分を広げて欲しいなぁ、とか思います。 僕がプログラミングをはじめたとき、何を思ってプログラミングをはじめたか思い出してみようとしたけど、よく思い出せなかった。 ただ漠然と感じていたのは、プログラミングは個人が現実的にこの世界に直接手を加えることができる手段の1つであり、それをやらないのは勿体無い、といったことだったと思う。たぶん。 どうも、プログラマを目指す
一口にJSerといっても、色々な分野の人がいます。あなたはどんなJSerになりたいですか? 方向性により学ぶべき事も変わってきます。目標を明確にしましょう。 というわけで、独断と偏見……というか主に偏見で三種類にまとめてみました。 追記: 「勉強法」とかタイトルに付けておきながら勉強法に触れてませんでしたので「勉強範囲」に修正しました。ひー。 三種類 アニメーションを作る人 アプリを作る人 サーバ側を作る人 基本的にプログラマ視点です。コーダー視点も最後に。 では、それぞれ見てみましょう。 アニメーションを作る人 Flashの代わりにJavaScriptやCSSを使う人。Flasherさんがシフトしてくる位置。 発注側が想定するJavaScripter。最近の携帯ゲームで需要がある。 お仕事 JSだけでなくCSSや画像を駆使して画面を描く。 UIだけならいなくても困る事はないけれど、UXま
…という題で、発表してきました。 さいたま開発勉強会 vol5です。 iOSのCore Graphicsと共通点の多いHTML5 Canvas。 iOSプログラムの経験がまるごと活かせるぜ!面白いものつくろうぜ! ということをお伝えしたく、実際に手を動かす場面を取り入れてみました。 実際に効果があったかどうかは…わかりません (^^;) 入門的な位置づけに仕上げてみましたので、iOSプログラマの方もそうでない方も、ぜひ触ってみてください。 iOSプログラマへ。HTML5 Canvasがおもしろい! from cocopon 練習用の「HTML5 Canvas スターターキット」はこちらから。 マウス・タッチイベント両対応のInputManagerが付属していますので、ぜひご活用ください :) CanvasStarterKit_100.zip
このブログを読んでいる、あなた、ねこ背になっていませんか? 「胸を張って背筋を伸ばす」というのは、ねこ背を治す方法として無意味です。腹筋や背筋などの姿勢を支える筋力が足りないからというのも間違っています。 ねこ背にならない立ち方、座り方というのがあるのです。それを知らないのが一番の原因です。 詳しくは「一般人の常識を覆す“ねこ背”の治し方がここにある「ねこ背は治る!」 」にて、衝撃を受けたポイントを書いています。 ねこ背に悩んでいるあなたに、ぜひ手にとって頂きたい1冊です。 リーダブルコード ハッカーは読むな。必要ない。 良いコードを書くために悩み、ミスもする普通のプログラマに読んで欲しい。 発売1週目で増刷が決定するほど、上半期に圧倒的な注目をされた書籍です。私も一押しです。 デザインパターンよりも、こっちの方が毎日使う知識なのです。 良いコードとは人間が最短で理解できるように書かれたコ
私はすばらしいコードを「エレガントなコード」と呼ぶ@HIROCASTERでございませう。 まず、はじめに。本書はハッカーは読まなくて良い。普通のプログラマに読んで欲しい。 デザインパターンやリファクタリングよりも、本書に書かれていることの方がプログラマは毎日考えて、意識してコードを書くのだ。 よって、普通のプログラマならば本書を読んでおきたい。普通のコードを書く人にオススメの1冊だ。 例えるならば、バク転や月面宙返りをする方法ではなく、日常的におこなわれる「歩く」という行動に着目し、姿勢良く、美しく、シッカリ、確実に歩くための方法が書かれている。 本書の目的は、君のコードをよくすることだ。 「良いコード」の定義とは、コードを読んだときに最短で理解できる様に書かれていることである。そう、本書は伝えている。 では、良いコードを書くための方法を具体的に学んだり、教えられたりしたことはありますか?
テストにはプロがいます。「お仕事」で開発する場合はQA(Quality Assurance/品質保証)部門という「テストのプロ」がテストします。 バグ修正におけるテスターの役割は極めて重要で、「プログラマの手元で任意に再現可能な状態に持ち込めれば、バグ修正は8割終わっている」と言っても本当に過言ではありません。詳細聞き出しに10時間、修正30分、修正確認テスト30分、なんてのも実務ではザラです。この場合、プログラマも11時間拘束される(=時給x11時間分のコストが掛かる)わけですから、バグ修正のコストは聞き出しに掛かるコストがほとんどを占めることになります。 (誤報告一発で万単位の金が簡単に吹っ飛ぶとも言える) まずそもそもの問題として「素人」がテストを行うと以下のような論外ケースが頻繁に起こります。上に行くほどクソです。 誤報告 実際に起こったことと、現象が違う、手順が違う、設定
プログラミング技術さえ身に付けば、プログラマとして一人前と言えるでしょうか? プログラミングを始めたばかりのうちは、プログラミング言語の習得や周辺の知識を得ることばかりに目がいきがちですが、それだけでは一流のプログラマになれません。(プログラミング言語を学びたいならこちら:写経で身につけるプログラミングの基本) プログラマとして成長するためには、プログラミング技術を学ぶだけではなく、良いソフトウェアを作るための良い習慣を身に付けることが大事になります。初心者のうちに良い習慣を身につけておけば、ただ知識を追い求めるのではなく地に足をつけた成長ができるはずです。 本記事では、私自身も先人たちから学んだプログラマが身につけたい3つの習慣について書いています。 自分で書いたすべてのコードを説明できるようになろう プログラミングは全て、明確な判断の結果です。if文を使うべきかどうか、どのAPIを使う
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く