ディス オールド マン - megamouthの葬列
1 夜の街に降るはずだった雨は、この寒さで雪になってしまったようだった。 人材エージェント会社の営業を待っていた関口は、折りたたみ傘をさしていたが、風に巻き上げられた粉雪のいくつかは、彼の野暮ったいコートに吹き込んでしまう。 地下鉄の入り口から息せき切って営業の男がやってきた。時間ギリギリだ。 「急ぎましょう」 遅くなったのは自分のせいなのだが、彼は高そうな時計を一瞥すると早足に歩きだした。 「お電話でも言いましたが、どうも、難しいお客さんのようですから。関口さんも気をつけてください」 クライアントのオフィスに向かう道すがら、息を弾ませながら営業は言った。 どう気をつけろと言うんだ。関口は心の中で溜息をついた。 年度末の繁忙期に入ろうとしている中、大抵のエンジニアはすでに現場にアサインされていて、あぶれているのは自分のような40代以上のエンジニアなどの「訳あり」物件だけだ。 関口としては、
スタープログラマの幻影 - megamouthの葬列
最近久々に「スタープログラマ」という言葉を聞いた。 そういえば、私の中にもかつてそういう存在がいたなあ、と思い出した。 あえて定義することもないが、スタープログラマとは、先進的なOSSプロダクツを実装し、ブログなどでプログラミングを堂々と論じ、できれば単著の一つも書いているような人たちといったところである。 話の都合上、具体的な名前を出すが、高林哲氏、higepon氏、新山祐介氏などが、私にとってのスタープログラマであったし、少し時代を戻すとεπιστημη氏であるとか、賛否両論だとは思うが、やねうらお氏などの名前が挙げられるかもしれない。 スタープログラマというのは、駆け出しのプログラマやプログラム学習者にとっての目標であり、先輩であり、嫉妬の対象でもある。 彼らの言葉は絶対で、疑う余地もないことであり、私はそのプログラミングに対する思想を無条件に受け入れたし、彼らが使っているエディタや
ドイツの受託開発会社を退職しました - WETな備忘録
2月末日付けで退職しました。退職エントリ書くつもりは無かったんですが、周囲から「公益性が高そうなので書け」というお言葉をいただいたのと、あと海外在住プログラマのキラキラ記事っておおいに生存バイアスかかってる気がするし、死にゆく者の事例も大事かな、と。 はじめに つらみは有りましたが、うらみは有りません。当初3年ぐらいかなと思ってたけど、この1年間の経験には大変満足しています。また、同僚各位にも深く感謝しております。Vielen Dank. I love you ;) 日本に帰る理由も、ドイツがつらいってのはだいたい3割ぐらいで、じつは2年前からゲノム解析のウェブサービス化とか生物学周辺のソフトウェア受託などの個人事業をやってて、そろそろそっちに集中すっかー、というのがマジな理由です。 tl;dr 自分を守るのは会社でも制度でもなく、自分。Noと言えなければ死ぬしかない。 自分に落ち度が無い
プログラマの奇妙な待遇 - megamouthの葬列
クソ雑魚フリーWebエンジニアである私は、求人サイトが見るのが好きである。 自分のスキルや経験を登録しておくと、中年の私にさえスカウトオファーが来るし、そこで提示される最高年収を見てほくそ笑んだり、たちの悪そうな人買い企業がユーザー企業に常駐させるプログラマをかき集めようとあの手この手で自社の魅力を訴えてくるのは微笑ましい。 昔は冷やかしで面接にまで行ったりしたものだが、よほどの好条件が提示されない限り就職する気はないので、最近はさすがに自重している。 そういう悪趣味を通して知ったことだが、プログラマの募集要項において以下のような記載が増えてきている。 2台以上のディスプレイ支給 ハイスペックPC使用可 開発はGitHub、CircleCIなどの最新の開発環境を用意 バランスボールに座って仕事しています！ などである。 しかしこれは奇妙なことに思える。 バランスボールはともかくとして、プロ
Act as Professional |
プログラマは1日のほとんどを座った状態で生活している人がほとんどではないでしょうか？ この「座りすぎ」の毎日は病気のリスクを高くすることが明かになっています。 座りすぎは病気のリスクを高める この「座りすぎ」の生活は2型糖尿病、心血管疾...
プログラマという職業は「ふつう」の人には厳しくないか - ukstudio
最近、実はプログラマという職業が「ふつう」の人には厳しいなーと思っていたりする。 業務外にコードを書いたり、技術書などを読むというのは素晴らしいことだと思う。けど、会社側がもし「業務時間外にコードを書いたり、技術書を読んだり、勉強会に参加しなさい」と言ったら、それは業務時間外労働と変わらないと思う。個人のたのしみとは別に会社側がそれらを求めたらそれは業務だ。 しかし、僕が思うにはそういう業務時間外に自主的に勉強をしないと、正直いってまともな品質なソフトウェアを作るのは難しい。 例えば良書と言われているものは結構な数あり、ある程度経験がありそれらの本を読んだことがある人は「プログラマならこの本は読んでおくべき」という本をいくつかあげたりもするだろう。けど、それらをいつ読むのか。業務時間内にそれらをじっくり読んだり、実際にコードを書いたりする時間があるところはないだろう。そうなると自分のプライ
エンジニアの不安と壁 - naoyaのはてなダイアリー
このところ、KLab×はてな エンジニア応援ブログコンテストというのを開催していまして、エンジニア人生に関するちょっとした小話をブログに書いていただくと、内容によっては、シリコンバレーに行けたり、iPad が貰えるかもしれない。という企画です。「え、ブログ書くだけでシリコンバレー? 」 なかなか太っ腹な企画です。 よい機会なので、宣伝がてら、自分もちょっと、昔話をしてみたいと思います。 振り返ってみると、自分がエンジニアとして経験を積むなかで、「ここが壁だったな」と思うところがぼちぼちありました。それが何で壁に感じたのかといま改めて考えると、いずれも体系的な知識がなかったために、それを乗り越えるための指針がなかったというのが大きかったように思います。 きれいなコードを書くにはどうしたらいいんだろう? 負荷分散って、どうやるんだろう? 溜め込んだデータをうまく活用するには、どうしたらいいんだ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
プログラマが知るべきじゃない97のこと