そろそろ「プログラマー35歳定年説」を徹底論破しとくか - 書架とラフレンツェ
世の中に流布している「プログラマー35年定年説」は、大きく以下の3つに分類できる。 プログラマーは激務なので、35歳を過ぎると体力低下のために続けられなくなる(体力低下説) プログラマーは常に新しい情報を吸収しなければならないが、35歳を超えると脳の働きが低下して新しいことを覚えられなくなるために続けられなくなる(学習能力低下説) プログラマーは35歳を超えると開発ではない業務を求められるようになるので、技術職としてのプログラマーのキャリアが途絶える(マネージメント原因説) 以下、ひとつずつ検証していく。 体力低下説 まず1つ目の「体力低下説」だが、これについてはそれほど深く考る必要がなさそうに思える。周知の通り気力や体力には個体差があり、若くても元気がないひともいれば歳をとっても元気なひともいる。また、35歳あたりの体力低下の原因としては、単純な加齢というよりも生活習慣の要因の方が大きそ
[D] スマホ3台持ち 5-5-6最強説を唱えたい
iPhone 6/6+発表当初は、でかいスマホありえないと激しく主張しつつも、最近はすっかりドデカNexus 6に慣れてしまい、手のひら返すように「ファブレット最高！」とか言ってたんですが、ついに私的スマホ活用法が、次の次元に進んだ気がしている今日この頃、その心境について語ってみたいなと思ってます。 結論から言いますと、しばらくDockに、刺さりっぱなしで待機していたiPhone 5sを現役復帰させつつ、更にiPhone5sを一台買い増し、Nexus 6と合わせてiPhone 5s黒、iPhone 5sゴールド、Nexus 6ブルーの5-5-6のスマホ3台体制が、今の僕のスペックです。 従来のドデカNexus 6一台体制との大きな違いは、iPhone 5s x 2が新規追加な訳ですが、個人的には、この5s二台運用はコロンブスの卵的発想というか、なぜ今まで気付かなかったんだと、自分を恨めしく
![[D] スマホ3台持ち 5-5-6最強説を唱えたい](https://cdn-ak-scissors.b.st-hatena.com/image/square/11ce4d91c808eef8c2d7e30f1121235ed1068ac2/height=288;version=1;width=512/https%3A%2F%2Ffarm9.staticflickr.com%2F8578%2F16075900353_76c420af1f_k.jpg)
向上心より危機感と地道さが残業を減らすのだ - 勘と経験と読経
残業削減などのコンサルティングで有名な小室淑恵さんのセミナーを聴き、著書「ほんとうの豊かさを手に入れる 人生と仕事の段取り術 (PHPビジネス新書)」を読んだのでその感想など。個人的には生産性向上は力を入れてきたテーマで「7つの習慣」から始まり「GTD」などのLifeHack系や手帳術の道も一通り歩んできたつもり。けれども、小室さんの説明は向上心に訴えるというより、危機感を持たせ、シンプルな方法で残業を減らすというものだ。こういった取り組みのほうが地道に効果が上がるのだと思ったことなど。 photo by Joriel "Joz" Jimenez これまでの生産性向上遍歴 割とまあ一通りという感じ。他にも色々読んだけれど、心には残っていない。 7つの習慣-成功には原則があった! 作者:スティーブン・R. コヴィーキング・ベアー出版AmazonはじめてのGTD ストレスフリーの整理術 作者:
とれるだけ仕事をとってはいけない : タイム・コンサルタントの日誌から
最初に、損益分岐点の説明からはじめよう。企業は、製品やサービスを売って売上を得る。しかし、世の中にタダの物はないので、そこには必ず費用（原価）が発生する。その費用が製品の販売数量に単純に比例する場合、企業は売上に比例した利益を得ることになる。この関係を図(a)に示す。横軸は、売上である。工場の視点から言うと、売上向上すなわち稼働率向上を意味するから、横軸は稼働率と見てもよい。縦軸は金額で、実線が売上高を、点線が費用を示す。費用は純粋に、売上高に比例する。これを変動費ともいう。売上に伴って、変動するからである。たとえば製品を作るのに必要な原材料の購入費がそうだ。あるいは、製品を加工するための外注費などもそうだ。 ところが、企業にはこれとは別に、売上高にまったく関係なく、固定的に発生する費用がふつうある。これを固定費という。その典型例は、設備機械の減価償却費である。あるいは、従業員の給料なども
OOじゃないDDDについて - うさぎ組
概要 モデリングについていろいろ - Togetterまとめを読んでいて、前にも何度か言ったことがあるけれど、もう一度言っておこうかー的な感じです。多分ブログには書いていませんでしたので。 端的に言えば、パイプ&フィルターパターンがアプリケーションドメインであるアプリケーションもあって、そういったものはオブジェクト指向より関数型的なほうがうまく適合する可能性もあるという話。 DDDとプログラミングパラダイムやプログラミングスタイルは直交するはずだ Eric Evansから提案されたDDDはクラスベースOOを主体とした実例が多かったわけですが、DDDという概念はOOを前提としていないと僕は捉えています。特に、ユビキタス言語、コンテキストの明示、モデリングと密接な開発といった部分は多くのソフトウェア開発において役立つと言えそうですし、おそらくはプロダクト開発全体でも言えそうです。 エンティティ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
