タグ

プログラマに関するsasaplus1のブックマーク (46)

  • 優秀なプログラマーになるためのコツ

    You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

    優秀なプログラマーになるためのコツ
  • ドイツの受託開発会社を退職しました - WETな備忘録

    2月末日付けで退職しました。退職エントリ書くつもりは無かったんですが、周囲から「公益性が高そうなので書け」というお言葉をいただいたのと、あと海外在住プログラマのキラキラ記事っておおいに生存バイアスかかってる気がするし、死にゆく者の事例も大事かな、と。 はじめに つらみは有りましたが、うらみは有りません。当初3年ぐらいかなと思ってたけど、この1年間の経験には大変満足しています。また、同僚各位にも深く感謝しております。Vielen Dank. I love you ;) 日に帰る理由も、ドイツがつらいってのはだいたい3割ぐらいで、じつは2年前からゲノム解析のウェブサービス化とか生物学周辺のソフトウェア受託などの個人事業をやってて、そろそろそっちに集中すっかー、というのがマジな理由です。 tl;dr 自分を守るのは会社でも制度でもなく、自分。Noと言えなければ死ぬしかない。 自分に落ち度が無い

    ドイツの受託開発会社を退職しました - WETな備忘録
  • Webプログラマと数学の接点、その入り口

    フロントエンドのパラダイムを参考にバックエンド開発を再考する / TypeScript による GraphQL バックエンド開発

    Webプログラマと数学の接点、その入り口
  • エンジニアを定量化なんてしてはいけない - smellman's Broken Diary

    ネタ元: 「エンジニアをつくる」という理念掲げていたら、エンジニアが社内からいなくなった件 | 新田章太の「エンジニアをつくる」ブログ 話の発端は、 俺がDMTCについて知ってること,またそれに対する所感 - 職質アンチパターン がFacebookで話題になっていて、やばいなぁと思っていたら主催者もやばかったみたいな話。 内容自体ただヤバイんだけど、その中でも明確にツッコミを入れておきたい部分があった。 僕らの強みはDMTCを通じて、沢山のお客様とのつながりがあること このつながりを活かして、 国内外のIT企業で働くエンジニアのスキルを定量化しよう というひとつのテーマにいきつきました。 http://maximum80.me/archives/821 この部分についてFacebookで俺はエンジニアをバカにしてるって書いたけど、もうちょっと具体的に落としこもうと思った次第です。 ものさし

    エンジニアを定量化なんてしてはいけない - smellman's Broken Diary
  • 今までに経験した中で最悪の開発環境について書く

    なんとなく吐きだしてみる。老害の昔語りなので興味ない人はスルー推奨。 時は2000年代初頭、俺は最初に就職した独立系SIerから4次請けの派遣として某銀行の営業店システム開発に参加していた。 新卒で入社して、二つ目のプロジェクトだった。当時は最先端であったJavaでのプロジェクトということで、ずいぶんと喜んだことは記憶している。 1フロアが丸ごとプロジェクトルームとなっており、プロジェクト統括の事業部長が常に怒号をあげながらフロアを徘徊するなかで、15インチCRTディスプレイ(当然液晶なんかじゃない)がようやく置ける狭い机とパイプ椅子で、右も左もわからないまま、Excelで書かれた仕様書と向き合い、秀丸エディタ(当時はEclipseがまだ生まれていなかった)でジャバを書いていた。 デスマであったかというと、今思うとそこまでデスってはいなかったように思う。頻繁にリスケが行われていたのでプロジ

    今までに経験した中で最悪の開発環境について書く
  • 何故プログラマーは起業に追い込まれるのか

    自分はプログラマーで、多くのプログラマーと同じように、コードを書く行為そのものが幸せであり、いつまでもコードを書いていたいと思う。 だが30を越えて、今までいくつかの会社でサラリーマンエンジニアとして働いた経験を総合するに、 少なくともこの国でプログラマーで居続けるためには起業する以外の選択肢は無いのだという結論に至った。 良いコードを書くと出世してコードが書けなくなる普通にコードを書いて、スキルを磨いて、リリースを成功させていくと、やがて肩書きがついて雑務に振り回される日々が訪れる。 プログラマーにとって何よりも大事なのは連続した集中、それも出来るだけ長い時間だ。 昇進して部下が出来たり、質問される機会が増えたり、評価業務やら、上級職会議やら、採用面接やら、一つ一つは大した事が無くても、 出社時間は気が付けば断片化して切り刻まれ、一日に一時間続けて集中する事すら困難になってしまう。 もは

    何故プログラマーは起業に追い込まれるのか
  • SIerの問題点 - zyake_mk2の日記

    世間一般では、SIerは非効率、プログラマのスキルが酷い、ガラパゴス化している等、評判が悪く袋叩きにあっているようです。実際にはグローバル水準で戦える高スキル者はいるし、特に某親会社の人達はみな頭の回転が速いし、志が高いです。 一方で私の5年そこそこの短い経験の中でも、世間の評判通り、開発現場の信じられないような体たらくっぷりをたくさん見てきました。すごく立派な看板の裏でのしょぼい設計実装、ミス等 etc... (私も人のことを言えないですが・・・) そこで、私の見える範囲の世界で、どうしてこのような現状なのか考えてみました。 (私の見える範囲なので、他社だと全く状況は違うだろうし、他者には違った世界が見えているかもしれません。) SIerの問題点1. 技術力向上のインセンティブが少ない 恐らく最大の原因はこれではないかと思います。要するに、必死に技術力を磨くインセンティブが乏しいのです。

    SIerの問題点 - zyake_mk2の日記
  • 35歳定年説より怖いフルスタックエンジニアしか生き残れない未来とは - paiza times

    Photo by Joi 今回のpaiza開発日誌は片山がお送りします。 今後も技術(開発)を中心にエンジニアとしてのキャリアを歩んでいきたいなと考えている方向けに最近騒がれているフルスタックエンジニアとは何か、という事と、何故今後フルスタックエンジニアしか生き残っていけないのか?という事について書いてみました。 ■最近よく見かける【フルスタックエンジニア】とは何か? まずStackって何だろう?、というところで海外の記事などを読むと"LAMP stack"という言葉が良く出てきます。LAMPの場合、OSはLinux、WebサーバはApache、データベースはMySQL、プログラミング言語はPHP(もしくはPerlPython)という形で組み合わせたものの事を言います。つまりOS、Webサーバ、DB、プログラミング言語の組み合わせ≒積み重ね、なのでStackという事のようです。こういった

    35歳定年説より怖いフルスタックエンジニアしか生き残れない未来とは - paiza times
  • プログラムの生産性を高めるためになにを勉強するか - きしだのHatena

    用語は形式的なものではなく感覚的なものであることをお断りしておきます。 言語・フレームワーク・プラットフォーム まず最初に触れるものでとっつきやすい。何か使えないことには話になりません。多くの人が、勉強というとまずここ。 何かすでにつかえる人が新しく勉強することは、生産性をあげない。そのプラットフォームを初めて採用するときの準備が減らせる。どちらかというと仕事の選択肢を増やす感じですね。 深く知ることは、最適なコードを書きトラブルを減らしトラブルが起こったときの対策も早くなるので、生産性があがります。ただ、ある程度の深さ以降は生産性への寄与度がさがるので、その点では深くまで勉強する必要はありません。 プロダクトの使い方なので、プロダクトの寿命が勉強成果の寿命です。実際に使わないものの勉強は無駄になるし、使われなくなったら無駄になる。寿命もそう長くないです。 「プログラマは勉強してもすぐ使わ

    プログラムの生産性を高めるためになにを勉強するか - きしだのHatena
  • プログラマ業界の二分化 - きしだのHatena

    プログラマの業界は、同じソフトウェアを作るという作業でありながら、大きく2つの形態にわかれています。 小売業界が、コンビニやデパートなど、同じモノを売るという作業でありながら全く違う形態があるのに近いです。 この分化は、2010年ごろのGREE/DeNAの人材獲得合戦で明確に形ができたように思います。 なので、もう5年たって、定着しつつある感じでしょうか。 その2つの形態というのは、労働集約型の業界と、知識集約型の業界です。 労働集約型はSIで多い多人数開発の業界で、知識集約型がサービスで多い少数精鋭型の開発です。 知識集約型の業界は、最初こそちょっとお花畑すぎる感じもありましたが、最近は落ち着いてきており、徐々に経済的に均衡するところに収束していくと思います。それでも比較的めぐまれた労働環境ではあり続けると思います。ただし、常に勉強が求められる業界ではあります。 問題は労働集約型の業界で

    プログラマ業界の二分化 - きしだのHatena
  • 社会人としての成長は新卒での入社先で決まる – sumyapp

    こんにちは、sumyappです。今日も今日とて過激気味なタイトルを付けてみました。 しかしながら、私が当に感じていることですので、まじめに読んでいただければと思います。 まずはじめに、私の現在の社会的な職業ステータスは「株式会社アクトキャットの代表取締役」です。ただ、まだ大きい企業ではありませんし、イケてる会社と世間で騒がれているわけではありませんので、代表取締役という肩書に特に価値はありません。しかしながら、私が代表であること、私の会社の社内文化は私が作るということ、その上で、その社内文化に影響を与えている物が何なのかを記事で語ろうと思います。そのため、先に職業ステータスを書かせて頂きました。 私が常日頃考えているのは、優先度順に書くと下記の3つです。 顧客にとって最大限良い物を提供すること 書籍や勉強会への参加、人材育成などの投資については惜しまないこと ムダな物はつくらない、時間

    社会人としての成長は新卒での入社先で決まる – sumyapp
  • ITエンジニアのCAPの定理 - from scratch

    CAPの定理というのがある、 「ノード間のデータ複製において、同時に一貫性、可用性、分断耐性の3つの特性を同時に保証することはできない。」というもの。 説明をwikipediaにゆずると、 ・一貫性 (Consistency): 全てのノードにおいて同時に同じデータが見えなければならない。 ・可用性 (Availability): ノード障害により生存ノードの機能性は損なわれない。つまり、ダウンしていないノードが常に応答を返す。単一障害点が存在しないことが必要。 ・分断耐性 (Partition-tolerance): システムは任意の通信障害などによるメッセージ損失に対し、継続して動作を行う。通信可能なサーバーが複数のグループに分断されるケース(ネットワーク分断)を指し、1つのハブに全てのサーバーがつながっている場合は、これは発生しない。ただし、そのような単一障害点のあるネットワーク設計

    ITエンジニアのCAPの定理 - from scratch
  • 裁量労働制の会社で働く側の3つのルール - Yamashiro0217の日記

    ドワンゴ社の面白い制度について盛り上がってますね。 http://nlab.itmedia.co.jp/nl/articles/1308/28/news137.html さて、僕は合計で10年ぐらい、4社で、裁量労働制のある会社で働いてきたので、 僕が考える働く側のルールを書きます。 1. 成果を出す そりゃそうですよね。成果こそが裁量労働制のキモです。 逆に会社が成果主義が弱いのならば、 裁量労働制と相性が悪いので辞めましょう。 例えば、会議にちゃんと時間通りに出るってのも、 成果といえば成果です。 とはいえ、成果とは何か、誰がどう評価するのかとか考えだしたら悩みは尽きないですね 2. 見積もり技法を学ぶ 見積もりは当然自分で出しましょう。 え、「うちの会社は裁量労働制だってのにプロマネがスケジュール決める」 ??? そんな会社は辞めましょう。 自分で見積もりをなるべく正しく出せるように

    裁量労働制の会社で働く側の3つのルール - Yamashiro0217の日記
  • この夏インターン給料で買いたいおすすめ本 - hitode909の日記

    会社でLT大会があって,いまインターンが来てるので,3分で若者におすすめを紹介する活動を行った. を読みましょう 大学にいると教科書とかあって,教授もいて,勉強できるけど,社会に出たら教科書ないから,自主的に勉強する必要がある.仕事をしながら学ぶというのあるけど,それだけでは不十分だと思う.仕事してるだけだと,今持ってる技しか出せなくて,生まれ持った技術だけでどうにかすることになる.外科医は手術するのが仕事だけど,手術しかしてない医者いたら心配だと思う. 脳外科医が週60時間も執刀していたとして、そんな医者にかかりたいと思うでしょうか? かかりたい人はいないはずです。プロには、備えるための時間、知識と技術を高める時間がどうしても必要なのです。 プログラマが知るべき97のこと 長時間働かないだけでなくて,あいた時間で勉強しないといけない. ,会社で買ってもらえる制度あるけど,読んだ

    この夏インターン給料で買いたいおすすめ本 - hitode909の日記
  • 技術モヒカンに中指を立てる — hirokiky's blog

    技術モヒカンに中指を立てる モヒカンとは、技術的に優れている風を装い、勉強会などの会合で新参者に技術的に 正論と思われる論理を武器にして制裁を与える人種である。と、まぁここではそうしよう。 よくあるべんきょーかい、いべんとではマサカリを投げる、椅子を、斧を投げると言われる、 なんとも恐ろしい人たちである。ここでは、その人と、その界隈について。 まず、マサカリには中指を立てろ。自分の意見を否定されたからといって、 自分の意見を蔑ろにしてはいけない。正しく自分の意見を伝え、またモヒカンの伝えたい 真意を聞こう。学ぶものがあるなら学び、そうでなければ無視するがいい。 大衆に価値はない モヒカンをもてはやしている人間の大半は、そのモヒカンの真意にどれほどの価値があるのか 理解してない。大衆たるモヒカン信者はあなたの意見を封殺しようとするだろう。 だけど、大半はモヒカンの真意を理解してないので、論破

  • 2013 06-05-web-career-talk-at-coedo

  • コード転職やってはいけない6ヶ条とキラリ光る4ヶ条|【Tech総研】

    企業の第一線で働いているエンジニアに、直接実力を評価してもらい転職する。そういった「コードを書いて応募する」転職スタイルが人気を呼んでいる。この「コード転職」で失敗しないための6ヶ条と、高ポイントをゲットするための4ヶ条を紹介する。 転職活動といえば、履歴書を送り、人事を相手に面接をおこない、採用の可否が決まるもの。でも、エンジニアの実力はそれではわからない。そういった転職に対して、「当に、それでいいの?」と、思ったことはありませんか? そこで最近注目されているのが「コード転職」です。出された課題に対するプログラムを書き、企業の第一線で活躍するエンジニアがそのコードを判定する。あなたが、会社やプロジェクトに必要な人材かどうかを、現場の人間が判断してくれるわけです。 「実力はあるけど面接は苦手」「過去の経歴ではなく自分の力量を見てもらいたい」そういった人たちだけではなく、「これまで派手な仕

  • 【CodeIQ提供】「とにかくアウトプットをしまくれ!」- イケてるエンジニアに共通する、たった1つのポイント-ノート|U-NOTE【ユーノート】-イベントまとめプラットフォーム

    キャリアハック!Web系エンジニアの人が「どのようにスキルアップするべきか」を学ぶための勉強会が、6月5日(水)にCo-Edoにて開催されました。 今回のイベントはキャンセル待ちが出てしまうほどの人気イベントとなりました。 今回の勉強会は、イケてるWeb系エンジニアになる方法と、好条件で転職できるコードのポイントについて講演が行われました。さらに勉強会後半では、採用したくなるようなエンジニアになるために、どの点を意識すれば良いのかを実際にコードを書いて学びました。 この2時間に及ぶ白熱のイベント内容をまとめてお届けします。 また今回の勉強会のまとめ記事は、株式会社リクルートキャリアが運営する「CodeIQ(コードアイキュー)」のご協力で提供されています。 (当日の会場の様子) ■イケてるWeb系エンジニアに共通するスキルについて Webエンジニア・クリエイター系の求職者のキャリアコンサル

  • 自ら考え行動する社員に育つための3つの哲学 〜 若手の教育を任された上司や先輩にむけて | Social Change!

    Students and Teacher in a Classroom at Cathedral High School in New Ulm, Minnesota… / The U.S. National Archives 多くの会社で新社会人を迎え入れる季節になりました。若い人たちをどう育てるのか、企業にとってとても重要なテーマです。私たちソニックガーデンでも、毎年なんとか新卒社員を採用し、師匠のもとで弟子という形で教育しています。 私の考える教育方針の哲学はシンプルで「子供扱いしないこと」「育てるのではなく育つ」「守るのではなく見守る」というものです。 これは、私が様々な先輩や上司の元で働かせて頂いた中で感じたことを思い出して考えたものです。これから若手を育てなければいけない立場になった先輩や上司の人たちにとって参考になればと思い、それを記事にしてみました。 子供扱いしないこと 人は

    自ら考え行動する社員に育つための3つの哲学 〜 若手の教育を任された上司や先輩にむけて | Social Change!
  • 新人研修 - ギークに憧れて

    2013-06-23 新人研修 最近仕事で新人研修やってるのでそれについて。 JavaScriptの教材を作る 業務システムでもJavaScript大事になってきてるよーって事で、初学者用のJavaScript入門教材を作った。Excel方眼紙駆逐したかったのでSphinxで作った。誰もできる人いなかったっぽくて僕に丸投げされたのでやりたい放題やった。 Sphinxはファイル変更する度に自動ビルドさせたかったのでCoffeeScriptでビルドさせてた。 fs = require 'fs' exec = require('child_process').exec path = 'source/' console.log "start watch: #{path}" fs.watch path, (curr, prev) -> cmd = "make html" exec cmd, time