プログラマ業界の二分化 - きしだのHatena
プログラマの業界は、同じソフトウェアを作るという作業でありながら、大きく２つの形態にわかれています。 小売業界が、コンビニやデパートなど、同じモノを売るという作業でありながら全く違う形態があるのに近いです。 この分化は、2010年ごろのGREE/DeNAの人材獲得合戦で明確に形ができたように思います。 なので、もう5年たって、定着しつつある感じでしょうか。 その２つの形態というのは、労働集約型の業界と、知識集約型の業界です。 労働集約型はSIで多い多人数開発の業界で、知識集約型がサービスで多い少数精鋭型の開発です。 知識集約型の業界は、最初こそちょっとお花畑すぎる感じもありましたが、最近は落ち着いてきており、徐々に経済的に均衡するところに収束していくと思います。それでも比較的めぐまれた労働環境ではあり続けると思います。ただし、常に勉強が求められる業界ではあります。 問題は労働集約型の業界で
20 Tips for becoming a better programmer
1. There should be only one single exit point to each method (use if-else whenever needed). 2. When using if-else, make sure to place the shorter code snippet in the if: if (cond) { } else { ... ... . . . } 3. Do not throw exceptions if you can avoid it, it makes your code much slower, if you feel like throwing something and then catching it – go play ball with your dog. If you don’t have a dog ge
俺の考えるプログラマー35歳定年説 - komagataのブログ
おはようございます。高熱を出したまま35歳、アスキーコードで言えば#歳になりましたkomagataです。 間違えてて去年書くはずだったプログラマー35歳定年説について。（その来年がきたよ～、見てる〜？ ＞ 俺） パッピーバースデートゥーミーフロム俺 - komagata 「フィジカル、メンタルで衰えてくる」とか「マネジメントへの参加要求が強まり自然にプログラミングから遠ざかる」とか「求められる成果の総量が上昇するのでしかたなく」という面も確かにあると思います。 しかし、 「平均的なキャリアプランなんぞ知ったことか。こっちは大手町辺りに派遣されてスーツで一生デスマ案件でJavaを書き続ける覚悟は完了してるんだよ！」 という我々にとっては関係ありません。にも関わらず我々が長文を書いてしまうのはなぜでしょう？ それは「誰も見てなくても関係ない」「真理鉱山に篭って一生続けられる」はずのプログラミン
全プログラマーが知るべきレイテンシー数
Latency numbers every programmer should know — Gist L1キャッシュ参照 0.5ナノ秒 分岐予測失敗 5ナノ秒 L2キャッシュ参照 7ナノ秒 Mutexのロックとアンロック 25ナノ秒 メインメモリー参照 100ナノ秒 Zippy[Snappy]による1KBの圧縮 3,000ナノ秒 1Gbpsネットワーク越しに2KBを送信 20,000ナノ秒 メモリーから連続した1MBの領域の読み出し 250,000ナノ秒 同一データセンター内におけるラウンドトリップ 500,000ナノ秒 ディスクシーク 10,000,000ナノ秒 ディスクから連続した1MBの領域の読み出し 20,000,000ナノ秒 パケットを、カリフォルニア→オランダ→カリフォルニアと送る 150,000,000ナノ秒 Jeff Dean著(http://research.googl
langturn.com is coming soon
is a totally awesome idea still being worked on. Check back later.
プログラマがやってはいけない97のこと - Cube Lilac
プログラマが知るべき97のこと改変シリーズ第4弾．抜粋元のメインは，#やってはいけないプログラマーのNG まとめ - Togetter，および twitter 検索 - #やってはいけないプログラマーのNG です．また，プログラマが体験するべきではない50の危険なこと - Life like a clown からも一部抜粋しています*1．尚，登場する人名は適当な仮名に変更しています． 今回は，タイトル通り「プログラマがやってはいけないこと」に絞ってみました（プログラマが受ける理不尽系は除外）．尚，過去のプログラマが知るべき97のこと改変シリーズは最後に一覧を列挙しますので，併せてお楽しみ下さい． 全角スペース使う インデントにタブと空白が混在 変数名や関数名でスペルミス 変数名が女の名前 char aznable; 浮動小数を等値比較 三項演算子の数行に渡る多重ネスト 同じシステムの中で複
Cooking for Geeks
TOPICS Make/Electronics/DIY 発行年月日 2011年09月 PRINT LENGTH 424 ISBN 978-4-87311-509-2 原書 Cooking for Geeks FORMAT PDF 料理の味はさまざまな化学反応によって決定されます。その原理を知ることで、自分で作る料理はより美味しくなり、他の人が作った料理を深く楽しむことが可能になります。 本書『Cooking for Geeks』は、ギーク、エンジニア、プログラマのために書かれた料理の基本を学ぶ書籍です。食材の味と風味の組み合わせ方から、熱の加え方の違いが食材に与える影響、またパンやお菓子にとって最も重要な空気を含ませる方法など、料理の科学的な仕組みを詳細に解説し、さらなる応用や独自の新しいアイデアを生み出すための基礎を提供します。 さらに簡単なものから本格派まで100を超えるレシピと、科学
エンジニアとして大成したいならやってはいけない48ヶ条 - レベルエンター山本大のブログ
いろんなエンジニアを見てきて、成功パターンはそれぞれだけれど 失敗パターンはだいたい決まっている。以下、アンチパターン。 成し遂げるのではなく、中途半端で満足する。 自分の責任と考えず、人のせいにする。 よりよくしようとせず、現状維持を良しとする。 仕事を中心においていない。 自分の特徴を構築していない。同世代と比べてさしたる特徴がない。 生活習慣を重視しない。日々の積み重ねに価値をおいていない。 与えられたチャンスに乗っからない。やる前から怖じ気づく。 アウトプットの質にこだわらない。 自分を分析していない。強み弱みを問われても答えられない。 刺激よりも、平穏を求める。変化に弱い。 行動よりも熟考を優先する。考えた末に行動しない。 現在の仕事の進め方に疑問を持たない。既存踏襲が正しいと思っている。 チームへの貢献よりも、自分の仕事の進捗を優先する。 焼き畑農業的な人間関係。信頼の構築では
Metaleks General Surgeon
If you want something done, you may as well do it yourself. Right? Ever hear that expression before? Only the thing is; not everyone is cut out for DIY work. And they are certainly not cut out for tripping wires. Because that would leave you without a roof over your head. Well, yeah, that could happen. But it doesn’t. And it doesn’t need to. It doesn’t happen to me because I’ve got a handyman in m
今年35歳になるので、エンジニアの35歳定年説というやつについて書くぞ - developer’s delight
エンジニア35歳定年説。IT業界で働く人なら一度は聞いたことがある言葉なのではないかとおもいます。誰が言い出したのか知りませんが、この言葉は非常にタチが悪く、言葉だけが一人歩きしていて多くの人が「35歳くらいになると能力・体力の低下により新しい技術についていけなくなり、引退を余儀なくされる」という解釈をしているようです。しまいには妙な拡大解釈でこのようなエントリまで書かれる状況です。僕の認識をどんぴしゃで書いてくれているエントリがないので、自分の経験を少し書いてみたいとおもいます。僕が「エンジニアは35歳が定年」という言葉を初めて聞いたのは、新卒で就職したソフトウェア開発会社でした。僕が就職したのは、法人顧客のための業務システムを開発している、いわゆるSIをやっている会社でした。ある日、会社の先輩に「この業界、エンジニアで飯を食っていけるのは35歳までだから、よく将来のこと考えておいたほう
プログラマという職業は「ふつう」の人には厳しくないか - ukstudio
最近、実はプログラマという職業が「ふつう」の人には厳しいなーと思っていたりする。 業務外にコードを書いたり、技術書などを読むというのは素晴らしいことだと思う。けど、会社側がもし「業務時間外にコードを書いたり、技術書を読んだり、勉強会に参加しなさい」と言ったら、それは業務時間外労働と変わらないと思う。個人のたのしみとは別に会社側がそれらを求めたらそれは業務だ。 しかし、僕が思うにはそういう業務時間外に自主的に勉強をしないと、正直いってまともな品質なソフトウェアを作るのは難しい。 例えば良書と言われているものは結構な数あり、ある程度経験がありそれらの本を読んだことがある人は「プログラマならこの本は読んでおくべき」という本をいくつかあげたりもするだろう。けど、それらをいつ読むのか。業務時間内にそれらをじっくり読んだり、実際にコードを書いたりする時間があるところはないだろう。そうなると自分のプライ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
長文日記
プログラマと付き合う