https://jp.techcrunch.com/2014/12/09/20141208barack-obama-becomes-the-first-president-to-write-code/
例外 - Qiita Advent Calendar 2014 - Qiita
例外やエラー、それにまつわる各種言語の取り組み等を共有しましょう。 11月末までに書き手が集まらなかった場合は主催者による独りAdvent Calendarと化します。 集まらなかったので残念ながら独りAdvent Calendarと化しました。 追記 独りAdvent Calendarですが、以下の理由で頓挫しました。6日目以降はお好きにご活用ください。 http://qiita.com/Kokudori/items/3a953c00012408f76ab9#%E4%BE%8B%E5%A4%96-advent-calendar-2014%E3%81%AE%E7%B6%99%E7%B6%9A%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6
エンジニアの面接でコードレビューさせてる
（あんま多くないみたいだから多分すぐ身バレしそうだけど書く） エンジニアの面接で実際にコードを書かせる会社が最近は多いみたいだね。でもウチでは特に面接で書かせない。というか今まで書いてきた、関わってきたコードなんて書類で大体分かるでしょ？ それよりも、ウチではコードレビューをさせてる。 選考用にわざと少し突っ込みドコロの多いコード（30〜50行程度のコードを3〜4ファイル）を渡して、もちろんファイル構成自体へのレビューも含めて、どんな意見をその人が出せるかを問う。 レビュー用のコードは複数言語用意してて、一番得意な言語を選んでもらってる。 時間は1時間。資料と赤ペン、そしてネットに繫がったパソコンを渡して、いくらでもググってもらって構わない環境でレビューを紙に赤して貰う。 「コードレビュー」ってものに対しての認識だとか、コードを管理するための能力もある程度分かるし、すごく良い選考制度だと思
35歳がプログラマとしてきのこるためには（あるいはきのこらないためには） - 亀岡的プログラマ日記
スタッフ兼、一参加者として参加してきました。 プログラマ35歳定年説勉強会 - DevLOVE関西 | Doorkeeper 仙石さん、谷口さんのお話、かなり刺激を受けました。 エンジニアの心を持ちながら、ごくごく自然と、会社ではプログラミング一筋から徐々に離れていったお二人の経験談。でもそこに後ろ向きなところは一切なくて、「（詳細はぜんぜん違うとしても）こういうキャリアを積みたいなぁ」と、心から感じるものでした。 んで、まぁ個人的な感想です。 「35歳定年説」に思ったこと 最初に「35歳定年説」におもうことをざっくばらんに付箋に書いて、という流れだったので、そのとき書いたのは以下の様な話でした。 35にもなってただコードを書いているだけじゃダメだよ、という意味じゃないかな その年くらいには「+α」を探しておかないときっとだめなんだろうな、と。 最近ぼんやり考えていることを素直に言葉にした
プログラミングの勉強で重要だなとおもったこと
１、あらゆる意見について盲信してはいけないインターネット上ではとりわけ多いけれど、ある意見を適当に述べている人というのは多い。適当に述べている……とは、別に悪気があってそうなったわけじゃなくて、本人もよくわかっていないけど「なんかうまくいったからとりあえずブログに書いた」風のものがあるということだ。例えばブログに書いてあったソースをそのまま貼付けてコンパイルエラーになることがあるけれど、それには色々要因があって「本人がブログ上で書いたまま検証していない」「サイト上でレイアウトが崩れた」「環境が違う」等いろいろある。自分のわからないものに関しては「そうなんだ。まぁとりあえずそういうことにしておこう」ぐらいでいい。断定口調で「絶対こうだ」と書いている人も、間違っていることが多々ある。それは本でもそうだ。「ほんとうかなぁ？」と思ったら疑った方がいい。自分しか信じてはいけないし、その自分すら疑った
自分がプログラマになったときに、Webアプリケーション開発の独習で学びにくかったところをまとめる - Line 1: Error: Invalid Blog('by Esehara' )
はじめに 独学でプログラミングを勉強しても実務に通用しにくい理由 - 25歳ニートが35万円で上京を企むブログを読んだときに、僕自身もまた不安定労働から、ある程度「これだったら自分できそうだ」という気持ちで取り組み、独習のつもりで幾つものプログラムを書いたりしていた。だから、ニートからプログラマを目指して、社員として今頑張ってます、というのはすごく仲間意識を持ってしまうし、同じように頑張ってほしいという気持ちはある。 確かに、上の記事の趣旨自体、つまり「独習で学ぶことは、実務上でカバーできない部分がある」という側面があることは認めつつ、しかし、自分自身は独習したことが案外実務上で役に立っている部分もあり、その部分は明確にしたほうが、今後同じように独習して、今度プログラマを目指す人々において役に立つのではないか、と思うので、この記事を書こうと思う。 この記事で扱う「Webアプリケーション開発
プログラマとして30年以上の経験から得た教訓 | POSTD
私は、プログラマとして30年以上仕事をしてきた中で、学んだことがあります。そのいくつかを以下にご紹介します。もっと挙げることもできますよ。 実物を見せないと、顧客の希望は分からない。 このことは最初の仕事で学びました。顧客は、実物を見るまでは、何が本当に必要なのかがよく分かりません。言葉で長々と説明するよりも、機能検証のためのプロトタイプを提示する方が確実に役立ちます。 十分な時間があれば、あらゆるセキュリティは破られる。 現代社会において、セキュリティを保つことは信じられないほどの難題となっています。プログラマは常に完璧を求められますが、ハッカーは1回でもハッキングができれば成功なのです。 セキュリティが破られた場合、事前にその状況に備えた対策を講じているかどうかで結果が変わってくる。 最終的にセキュリティが破られることを想定する場合、その時に起こることに備えて対策を立てておく必要があり
あなたは全部知っていますか？プログラミングの業界用語30選 | POSTD
Stack Overflowは、私が学習に役立ててきた多くのオンライン・コミュニティと同じように、自然と厳しくなってきました。第一にこれは、自己防衛機能です。子どもが初めて学校や託児所に入ると広大な世界にさらされて、 髄膜炎菌症を発症 して日々くしゃみやせきを繰り返しながら成長するのと同じような免疫システムです。常に好ましいことだとは言い難いですが、生き残るためには必要なプロセスなのです。 2年前に投稿された、下記の質問のことを考えてみてください。 あなたが新しく作ったプログラミングの業界用語は何ですか？ あなたが作り、あなたの周りで使われるようになった、プログラミングの用語は何ですか？（他の人が真似して使っているのを聞いた、など）あなた独自の言い方が、職場内でのみ使われていたり、インターネット上で幅広く普及していたりすることもあるでしょう。 独自のプログラミングの用語、単語、言い回しを太
プログラマ歴12年の僕が選んだ「10年経っても役立つ技術書17選」 - give IT a try
はじめに 僕がプログラミングを始めてから、もうすぐ12年になろうとしています。 この12年間、いろんな技術書を読んだり、仕事やプライベートでたくさんコードを書いたりしてきました。 最初に入ったSIerでは主にJavaを、前職の社内SE時代はC#をメインのプログラミング言語として使ってきました。 現在はRubyをメインで使っていますが、言語が変わっても、また何年経っても「これはあのとき学んだ知識が役に立ってるよなあ」と思う瞬間がときどきあります。 そこで今回はこれまでに読んだ技術書を一通り振り返り、「この本で学んだことは今でも役に立ってる」と思うものを17冊ピックアップしていきます。 おことわり (2014.09.29 20:00追記) このエントリのタイトルは「10年経った今でも役に立っている」という意味で付けています。「今から10年後まで役立つ」という意味ではありません。（紛らわしくてご
コードのクリーンアップ - 技術的負債の返済に役立つ 9 つの戦術
技術的負債の返済に役立つ 9 つの戦術 David Laribee MSDN Magazine の 2009 年 12 月号では、技術的負債に取り組むために、問題を特定して主張を展開するためのアドバイスを書きました。簡単に言えば、近い将来に問題になりそうな負債を特定することが重要だと信じています。コードベースのほとんど触れられない部分で、価値ある技術を確立しても、明日の生産性向上の実現には役立ちません。 また、負債返済の重要性について経営陣からお墨付きを得ることの重要性を理解し、同じ理由から手堅い主張を展開するための基本ツールを用意してください。 では、利息の高い技術的負債を返済するうえで役立つ可能性がある戦術に話を移しましょう。技術的負債に対処する際に実績のある戦術はたくさんあります。難しいコードと争うためのパターン、ツール、および手法をすべて紹介すると、この記事にはとても収まりません。
例えば「写経」という言葉を避けてみる。 - 西尾泰和のはてなダイアリー
サイボウズ式「続・エンジニアの学び方」の第5回が公開されました。この回では、小崎さんが「どうしてコードを読もうと思ったのか」と、コードを読むために新しい言語を学ばなければいけない場合に「どうやって学ぶか」を聞きました。 ところで、小崎さんは自分の学び方を「写経」と読んでいて、僕もこの用語は自然に理解できるのですが、公開後のTwitterの反応を見ていると「写経と呼ぶことが嫌」もしくは「仏教での写経の印象で、内容を勘違いしている」という事例がいくつも見つかりました。 プログラミングの学習法としての「写経」という言葉は色々な書籍で使用されています。例えば「100人のプロが選んだソフトウェア開発の名著 君のために選んだ1冊」の70ページでは「まず写経することから始めた」というエピソードが紹介されています。また「改訂新版 コンピュータの名著・古典100冊」の99ページでは「技術書の内容にそって深い
クラスの命名のアンチパターン - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 昔から「名は体を表す」と言ひます。クラスの名前がクラスの果たす役割と一致してゐるかどうか常に考へ続けませう。 ImageInfo, AccountData, etc. Info って何やねん? Data って何やねん? ImageInfo って Image とはどう違ふねん?? FooInfo や FooData よりも好ましいかもしれない名前の例: FooAttribute, FooProperty, FooMetadata, FooDescription FooConfiguration, FooSetting, FooParame
プログラミング初心者が中・上級者になるための近道
初心者と中級者、上級者の違いとは何でしょうか？ 初心者は、 知識が少ない 開発したソフトウェアの数が少ない 中級者・上級者はその逆で、 知識が多い 開発したソフトウェアの数が多い その結果生まれる実質的な差は、 「初心者はかんたんなものしか作れないけど、中級者・上級者は難しいものを作れる！」 ということです。ですから、初心者が中上級者になるには難しいソフトウェアを作るのに役立つ知識を身につければ良いわけです！ 難しいソフトウェアとは、 ロジックが複雑で難しい 規模が大きい 性能要件が厳しい 納期が短い など、いろいろな難しさがあります。 これらのハードルに対抗する知識・技術について紹介します。 規模が大きいソフトウェアを作るための技術 規模が大きいソフトウェアを作るための技術には、以下のようなものがあります。 モジュール分割 アプリケーションアーキテクチャ フレームワーク プログラミング作
もし16種類のプログラム言語が武器になったら
By Lennart Tange 一口に「プログラム言語」といっても、その種類は多岐にわたり、それぞれ他にはない特徴や長所、短所を備えているものです。Floobitsでソフトウェアエンジニアを務めるビョルン・ティップリング氏は16種類の言語をさまざまな武器に例え、それぞれに備わっている個性を表現しています。 If Programming Languages were Weapons - science and tech post - Imgur https://imgur.com/gallery/huZRM ◆01：「C言語」 プログラムの基本ともいえるC言語は、アメリカの半自動小銃「M1ガーランド」とのこと。その理由は「古いが、信頼性は高い」から。 ◆02：「C++」 C言語の拡張版として誕生したC++は「ヌンチャク」に例えられています。その理由は「うまく使えば強大な能力を発揮するけど、
プログラミング学習手段としての写経について - 西尾泰和のはてなダイアリー
あるブログが「写経には効果がない」という趣旨のことを書いていて「何を言ってるんだ？」と思いじっくり読んでみたら、彼の言う写経は「動くとわかってる10000行のコードを何も思考せず作業として書き写すこと」を指しているようだった。「そんなわけないじゃん」と笑ってから「もしかして世の中は写経をそういう捉えてるのか？」と不安になった。 写経は自分の中にモデルを作るための行動で、他のもっと効率のよい方法と比べた場合の利点は「自分の中にモデルがなくても使える」点に尽きる。全く知識ゼロでいきなり「自分で考えて書く」ができる人はいない。考えるための材料となる知識をまず脳内に運び込む、それが写経だ。 写経の過程で大事なことは以下の3つだ。 1: 早く学びが得られるように、なるべく小さいコードで実験し、すぐに結果を確認する。 2: 疑問に思ったこと、考えたこと、気づいたことを書き留める。どうしてこういう書き方
橋本商会 » プログラムの写経
プログラミング初心者が写経する時に気をつけると良い事を4つ説明します。 画像はイメージです プログラムを勉強する時に、写経しろ（すでに完成しているプログラムを本から書き写せ）とか言われるが、ちょっと意識するとだいぶ違うと思う 1. 外から書け 例えば、1からnまでの数字を全部表示するプログラムがあるとする。 def run(max) 1.upto(max).each do |i| puts i end end run(10) これを写経する時、上から下に1行目から順に書くのではなくて、まず def run(max) end いちばん外側を書いて def run(max) 1.upto(max).each do |i| end end 中を書いて def run(max) 1.upto(max).each do |i| puts i end end こうなる。 上から書かないのが重要。プログ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
作りたいものを作るには結局大量のコードを書かないといけないことについて - Qiita
コードレビューの話
アジャイルサムライの次に読む技術書
コードレビューガイドライン #loupestudy
