サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
くら @mizunokura たとえ全角数字も全角スペースも通用しないプログラマでも、半角2つ・半角4つ・タブの三種類のインデントが混ざったソースを投げつけられると死ぬ。 2011-06-23 20:53:08
1 ：仕様書無しさん ：2011/05/14(土) 19:34:10.69 ぼくと契約してデスマプロジェクトに入ってよ！ 2 ：仕様書無しさん ：2011/05/14(土) 19:38:16.07 「まどかがPGになれば、マミよりずっと凄腕PGになれるよ」 「もちろん、どんな案件で契約するかにもよるけれど」 「まどかが産み出すかもしれない単価の大きさは、僕には測定しきれない。 これだけの資質を持つ子と出会ったのは初めてだ」 4 ：仕様書無しさん ：2011/05/15(日) 08:11:43.77 「僕はプログラマになってくれって、きちんとお願いしたはずだよ？」 「実際の状況がどういうものか、説明を省略したけれど」 「訊かれなかったからさ。知らなければ知らないままで、何の不都合もないからね」 5 ：仕様書無しさん ：2011/05/15(日) 08:27:13.83 |::::::::::
ロシアの研究者 A.P.Ershovは、プログラミングに必要な才能として、６つを挙げた。 これは、確かにそうだなと思った。才能は磨いていけるものと信じて、これらの才能を磨いていけるように、メモをしておく。 プログラミングに必要な６つの才能 第一級の数学者の論理性 エジソンのような工学の才能 銀行員の正確さ 推理作家の発想力 ビジネスマンの実務性 協同作業をいとわず、経営的な関心も理解する性向 第一級の数学者の論理性 出現するケースをもれなく拾いあげる能力 実行の条件を正確に決める能力 この能力を高めるための書籍 プログラマのための論理パズル 難題を突破する論理思考トレーニング 作者: Dennis E. Shasha,吉平健治出版社/メーカー: オーム社発売日: 2009/03/26メディア: 単行本購入: 21人 クリック: 412回この商品を含むブログ (63件) を見る論理トレーニン
まとめ第2弾。個人的には プログラマが知ろうが知るまいがどうでもいい97のこと -Togetter に期待していたのですが、これは 97 個揃えるのはちょっと無理ゲーのようです。尚、ここ最近の一連のまとめの元ネタは プログラマが知るべき97のこと です。類似ネタの プログラマが知るべきではない97のこと、プログラマが体験するべきではない50のこと も併せてどうぞ。 切りのいい数字とは 2進数です 片手で 31 まで数えられる 万能じゃない "パソコン"に強くない プログラマだからといって Office シリーズに精通してるわけじゃない あ、その作業は事務のお姉さんの方が得意だと思います カナ入力に変えたら必ずローマ字入力に戻しとけ プログラムの GC は得意でも部屋の GC は得意でない マルチスレッド処理は書けてもマルチスレッド処理はできないAmazon で買っているのは技術書だから
デリヘル嬢呼んだら昼の仕事はプログラマーだって言ってた。 中学卒業から3年働いてるとかで、昼の仕事でも手取りで20万くらいには稼いでたけど、都内で一人暮らしはきついとかでデリヘルを始めたとか。 デリヘルが儲かるから、会社は辞めて夜を本業にして副業程度にiPhoneアプリ制作をタラタラやるくらいにしようかと思ってるとか。 なんかクラクラしてきた。 一応18歳ってことになってるけど、信用はしてないんだが、二十歳を過ぎてるようには思えなかった。 その店はほぼ本番黙認の店で、咥えるのが面倒だからゴムつけて入れてって感じのギャルが多いんだが、その子は本番しない真面目な子だった。 献身的でいい仕事をしてくれた。 今の子の職業観ってどうなんだろう？ その子は極端な例だと思うんだけど、やっぱり俺の世代とはずいぶん違うんだろうな。ITが大卒の仕事だった時代が終わりつつあるのかな。
リアクティブプログラミングは、「時間とともに変化する値」＝「振る舞い」同士の関係性を記述することでプログラミングを行うパラダイムです。GUIなどのようにインタラクティブなシステムや、シミュレーションやアニメーションのようにダイナミックに状態が変化するようなシステムを宣言的に記述することができます。 これらの「変化する状態」や「外部とのやりとり」が支配的なシステムは、純粋関数型言語が、その強みを発揮しにくい部分でもあります。本稿では、リアクティブプログラミングが副作用を含む系を宣言的に記述することを可能にし、状態の管理という厄介な問題からプログラマを開放する可能性があることを示したいと思います。 （割と独自研究に基づく解釈ばかりなのでその点ご了承ください。あと例としてでてくるコードは、Pythonベースの擬似コードで具体的なライブラリに基づくものではありません。） WhyReactiv
昨日、人生の転機 -Rails で行こう！ の中で「ソフトウェア作りが嫌いだ」と言い切ってしまったことが引っかかっている。 私の職業生活でもっとも多くの時間を注いだのがソフトウェア作りだ。その作業に対して、実際のところ、好きとか嫌いとか一言で割り切れるはずがない。複雑な感情を持っているというのが正直なところだ。 私の職業プログラマのとしての最大の欠点は、ソースコードに対して強い美意識を持たずにいられなかったところだろう。生来の生真面目な性格が災いし、私の基準で美しいとはいえないソースコードを敵視しすぎた。 簡単な例を挙げよう。 うるう年を計算するアルゴリズムを考えてみる。うるう年とは、「4で割り切れて、かつ100で割り切れない年。ただし、400で割り切れたら、やはりうるう年」である。 def leap_year?(y) (y % 4 == 0) && ((y % 100 != 0) |
本の虫: 多くのプログラマは言語を表面的な理解だけで使っている一般のプログラマの多くは、プログラミング言語というものを、ごく浅い表面的な理解だけで使っている。これは、いわゆる「入門書」によるところが大きい。入門書は、言語をできるだけパターンで教えようとする。かくかくしかじかの場合には、とらとらうまうまのように書いておけばいい、などといった具合だ。 たとえば、配列の全要素や、aggregateの全メンバーをゼロで初期化したいとする。多くのC++プログラマは、以下のように書く事であろう。 int a[100] = {0} ; このコードは、正しく動く。配列aの要素は、すべてゼロで初期化される。しかし、C++という言語を考えた場合、{0}と書く必要はない。空の{}で十分なのである。 int a[100] = {} ; では何故、多くのC++プログラマは{0}と書くのか。それは、多くの参考書が、そのように書いているからに過ぎない。大多数のC++プログラマは、
SIerでプログラマ(PG)からプロマネ(PM)までやった僕が通ります。 ＰＭになりたくない症候群 - ベテランIT営業が教える「正しいITの使い方、営業の使い方」 - ZDNet Japan 一度でも失点をしたらそこからリカバリーすることが困難な立場に放り込まれるし、放り込まれたら現場の裁量で何とかするしかないというデフェンシブなやり方に起因する構造的なPM疲弊体質。確かにコレは、嫌悪される理由の１つにあると思います。ただ、それだけではないな、と。技能という側面で考えても嫌悪される理由があるのかな、と思いました。 要はPG→SE→PMというキャリアパス、についてですね。 色々な議論がありますが、何が問題かと言えばプログラマとして未来を奪い去ってしまう所が過多あるってことに尽きるように思います。技術は移り変わるわけですから、プログラマでありたいなら保有スキルが陳腐化しないようにしなくてはな
1リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
