優秀なプログラマーになるためのコツ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
死ぬまでエンジニアでいたい - seri::diary
理想の死に方は、前夜にOSSのリポジトリにPRを出して、翌朝には机で突っ伏して死んでて、最期に出したPRのコメント欄がr.i.p.で溢れている。そんな状態。 なんて話を冗談めかして飲み会ですることがある。*1が、本人は割と本気で死ぬまでコードを書いていたいと思っている。 年金がもらえそうにないので生涯働かないといけないみたいな主張を最近各種メディア界隈でよく見る。しかし、それとは別に、体が元気なら死ぬまで働き続けていたいものである。定年で悠々自適におとなしくできる気がしないし、それに、エンジニアとしてならリモートでも働きやすいし、数十年後にはさらにそれに適した社会になっているとも思われるし。 死ぬまでエンジニアでいる。それはおそらく難しい。 40歳を超えた辺りで、現場を離れてマネージャーとかIT芸人とかCTOとか技術顧問とか、そにかく違う肩書で働くようになる人がたくさんいるを見てもわかるよ
ニュージーランドのプログラマが毎日定時で帰れる本当の理由｜NZ MoyaSystem
僕がニュージーランド（以下、NZ）でプログラマになることを目指した大きな理由は「とにかく残業したくなかった」からだ。 日本を離れた2014年当時はワークライフバランスをめぐる機運も今ほど高くはなかった。また、5年半のシステムエンジニア生活の間、多くのプログラマが失敗プロジェクトに巻き込まれ長時間労働を余儀なくされ、業界を離れていくのを数多く目にしてきた。という事情があり、 「日本でプログラマになっても残業地獄に放り込まれる可能性が高い。ならば、残業しないのが当たり前の社会に行けば、毎日定時で帰れるだろう」と考えたのだ。 その狙いは見事に当たった。今ではプログラマとして楽しく働きながら、残業ゼロ生活を実践できている。 しかし最近、ふと考えた。 僕が毎日定時で帰れるのは、NZが残業しないのが当たり前の社会だから、ではない。それは半分正解で半分間違いだ。 NZのプログラマが毎日定時で帰れるのには
新入社員のうちに学びたい７つのこと
こんにちは、らくからちゃです。 普段、Togglというツールを使って作業実績の収集を行っております。 Web上からも、実績情報が整理出来てなかなかいい感じです。先日、作業実績のメンテナンスを行うために、サイトにアクセスし、ぶらっと開発ブログを覗いてみたら、なかなか良い記事を見つけました。 7 Things I Learned That Made Me a Better Programmer - Toggl Blog 記事のタイトルは『より良いプログラマーになるために学んだ７つのこと』となっており、プログラマーに向けた内容の記事です。特に突飛なことや斬新なことが書いてあるわけではありませんが、プログラマーだけでなく他の業種でも役に立ちそうな内容でした。 ちょうど新入社員が働き始める時期ですし、補足（蛇足）もつけながらご紹介したいと思います。（翻訳はGoogle先生におまかせしました） 1.問
サービス終了のお知らせ - NAVER まとめ
サービス終了のお知らせ NAVERまとめは2020年9月30日をもちましてサービス終了いたしました。 約11年間、NAVERまとめをご利用・ご愛顧いただき誠にありがとうございました。
消えたプログラマの残したものは - megamouthの葬列
システム開発の佳境に、開発メンバーが突然出社しなくなってしまう。 携帯にも連絡がつかず、3日ほど音信不通になったので、さすがに心配になった上司が大家と共に自宅を訪れると、夕日が差し込む部屋の真ん中に、当の本人が何の表情も浮かべずにただ座っていたりする。 そういう事は大して珍しいことではないので、ある程度経験のあるIT業界人なら、同僚が「消えて」しまってもそれほど驚くことはない。 プログラマというのは、とかく「消えて」しまうものなのだ。と彼らは思っている。 「消えた」プログラマは、意識的にしろ無自覚にしろ自分の人生をちょっとばかり台無しにしながら、プロジェクトに虚無の穴を空けるわけだが、そうした「工程の穴」は他のメンバーが残業したり、派遣会社から来た代替の人員が埋めてしまったりする。ビジネス的には人月で数えられた我々の「数字」などというものはちょっとした帳尻あわせでなんとかなってしまうらしい
『the alchemist russian roulette full lp』｜best guide for online roulette payout|easy roulette online･Bad Sobernheim Stadt|Berkenthin|free roulett online
Lauf the alchemist russian roulette full lp Ich liebe [diese] Tiere so sehr!Bei so vielen Emotionen für Pandoras Meeressäuger und große Anteilnahme bei der Wal-Jagd Dresden tiroler roulette um geld spielen Anstatt bei seinen Pflegekindern Judith und R,winstar farm sterling ma welded wire fence stakes trailblazer gaming club objective return to green acres who played mr ellison russian roulette 2 F
プログラマとして生き残るためのサバイバルガイド - Qiita
プログラマは何でも作ることができる最強の生物ですが、ひ弱です。 プログラマは電源があるところでしか生きていけません。 数年毎に大災害が発生する日本の現実を考えると、電源確保を発電所に任せていてはいつ仕事を失っても文句は言えません。 プログラマとして生き残るためには、自らの力で電源を確保する能力が必要です。 ということで今日は発電の話をします。 数ある発電方法の中でもソーラー発電は最も手軽で安価にはじめられます。個人で行う発電としては一番現実的だと思います。 ソーラー発電装置は4万円程度あれば一式揃えることができます。パソコンを充電する程度であればこれで十分です。 ソーラー発電の基礎知識 私は普段 Rails プログラマとして働いていますが、発電や電気に関する知識はありませんでした。 そこで次の本で勉強することにしました。 わがや電力 〜 12歳からとりかかる太陽光発電の入門書 表紙にもある
手を動かせるプログラマの市場価値が高まる理由 〜 この10年間で起きた４つの環境変化 | Social Change!
プログラミングができるITエンジニア人材の市場価値は、以前と比べて非常に高まってきているように感じる。そこで求められている人材とは、自ら手を動かすことで問題解決をするナレッジワーカーとしての「プログラマ」である。 決して、仕様書通りにコーディングだけする職種のことではない。それは以前に書いた。ソフトウェアエンジニアの目指す道 〜 ナレッジワーカーとしてのプログラマ 今回の記事では、この10年間で起きた市場や環境の変化から、手を動かせるプログラマの市場価値が高まってきた背景について、そして、これから求められるITエンジニアの姿について考えてみた。 12年前の転職市場で求められていたスキル 私が30歳を過ぎた頃、今から12年前（2004年頃）の話になるが、その当時に転職しようと少し調べたことがある。自分の年齢と経験をもとに探した応募要項で求められるスキルは、マネジメントであり大規模プロジェクト
既婚プログラマの時間捻出術
2024/6/5のアーキ部で話したスライドです。 Stratified Designの目的を中心に、そのメリットを考えてみます。
老いた職業プログラマはその後どうなるのだろう？(ライフプラン的な意味で)
自分が歳をとった結果、プログラマが老いるとどうなるのか、というのは割と身近にも見かける事や自分の事を考えたりする事で、リアルにイメージする事は出来るようになった。 そこで思うのは、引退生活的な物へのパスはどうなってるのだろうか？という事。 自分はまだ30代だが、そろそろ40歳である。 そして40代の前半が恐らくプログラマというものが普通に働いていける、という事は納得出来ている。 以前は30歳定年説とか35歳定年説とかあったが、今となっては、40の時点ではまだ定年は無かろう。 一方で55くらいからは厳しいかなぁ、という気もする。 その辺のプログラマもちょこちょこ見かけるようになったが、完全に戦力外になっている。 プログラマ上がりがなんだか良く分からないようなレポートみたいなのとかを書く仕事にありついている場合はちょこちょこあるが、どれもあまり需要が大きいようには見えない。我らがそのくらいの年
Javaプログラマであるかを見分ける10の質問-回答編 - やさしいデスマーチ
想定を超えた反応がありましたので、予定はしていなかった回答編をお送りします。ですが、正確な解答を書いても面白くないので、これをネタに面談をした場合に、自分ならどんなポイントを持って選考するかをまとめてみました。 はじめに このエントリーの質問の意図は「優れたJavaプログラマ」を見つける事ではありません。「最低限のスキルを持った戦力が欲しい」という状況です。したがって、優れた指摘をしてくるのであれば超したことありません。設問について議論が発生するならば、この設問を投げる必要がなかったということです。 Javaを詳しく知っている人からすれば間違いでは？曖昧な質問では？と感じる設問があるのは確かです。しかし、優秀な人をテストしたい訳ではないのです。したがって、正確性とか厳密性については求めません。「だいたいあっている」ならば前提条件である「中堅プログラマの補充」の条件を満たすからです。 中堅プ
[技術書]プリンシプル オブ プログラミングを読んだ - atuweb 開発ブログ
プリンシプル オブ プログラミング3年目までに身につけたい一生役立つ101の原理原則 上田 勲 出版社：秀和システム 発売日：2016-03-23 サブタイトルは 3年目までに身につけたい一生役立つ101の原理原則 です。 ソフトウェアエンジニアリングの「正道」を知り、「良いコード」を書けるエンジニアに成長しましょうというものですね。 ソフトウェアエンジニアリングに有効な情報がぎっしり詰まっており、「自分も3年目くらいまでに読んでおきたかったわー」「そしたら もっと近道できたわー 」というのが率直な感想です。 良いコードを書く プリンシプルとは プリンシプルとは、プログラミングの指針となる「前提」「原則」「思想」「習慣」「視点」「手法」「法則」のことです。これらは、歴史の審査を受けて生き残った、よいプログラミングのためのエッセンス（「普遍的」「定説的」「本質的」な知識）です。 P.4 まえ
![[技術書]プリンシプル オブ プログラミングを読んだ - atuweb 開発ブログ](https://cdn-ak-scissors.b.st-hatena.com/image/square/6b2b9efe4e3085b97c8d00791813ef62bed1035a/height=288;version=1;width=512/https%3A%2F%2Fatuweb.info%2Fimages%2Feyecatches%2Fengineer_life_lg.png)
よりよいプログラマになる10の黄金則 - YAMDAS現更新履歴
10 golden rules for becoming a better programmer | codeshare.co.uk .Net Web Developer Blog by Paul Seal この手の記事には食傷気味だが、学ぶべき教訓には学んだほうがいいわけで、果たしてここではどんな10個のルールが示されているのか。 同じことを繰り返さない（コードのリファクタリングの勧め） 変数には、それがどんな型かではなく、それが何のためにあるか分かる名前をつける メソッドには、それが何をするか明確に分かる名前をつける マジックナンバーや文字列リテラルは使わない 可能であれば、メソッドはそのアプリの他の部分に依存性を持つことなくテストできるよう書く 助けを求めるのを恐れない（やってることを他人に説明するプロセスが問題解決につながることもある） ボーイスカウト・ルールに従う（バグのあるコー
プログラマ向け：自分の強みや得意分野を見つける方法 - give IT a try
質問：あなたの強みや得意分野は何ですか？ プログラマのみなさんに質問です。 あなたの強みは何ですか？ 胸を張って「任せとけ！」と言える得意分野はありますか？ これはソニックガーデンの採用面談でよく聞かれる質問です。 僕もときどき採用希望の人と面談（という名の雑談）をすることがあるのですが、この質問に対して「はい、私はxxが得意です！」と即答できる人はかなり少ないです。 まあ、入社を希望する段階でいきなり「これが得意です！任せてください！」と言うのはかなり勇気がいりますよね。 下手に偉そうなことを言って、あとから「なんだ、大したことねーな」と思われたくない、という不安もきっとあるでしょう。 僕もかつては即答できなかった 何にせよ、即答できない気持ちはよくわかります。 実際、ソニックガーデンに入社した当時の僕もそうでした。 しかし、入社してから3年ほど経ってみると、いつの間にか僕にも得意分野（
システム障害と僕達はいかにして戦えば良いのか、障害対応について考えた - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? IT界隈でエンジニアしていると、よく出くわすのが障害対応です。できれば会いたくないという人が多いと思うんですが、僕はけっこう好きです。障害対応。どこに原因があるのか調査をして、バランス良くベターな対応をしたときの楽しさは、プログラミングとはまた違ったものがあります。探偵っぽい感じが面白いですよね。もちろん、障害が発生しない状況を作るのが一番です 弊社では数多くのWebサービス／アプリを運営しているので、過去様々な障害対応をしてきました。その際に、解決までどんな道筋を僕がたどるのかを振り返ってまとめてみました。これが大正解なんてことはなく
プログラマにとっての悪夢とは？ | Yakst
本番だけでバグが発生し、ローカルでは再現できないか発現しない。 バグの発生確率が低いが、無視できるほどではない。 バグの原因が、高負荷時にのみ起こる競合状態に影響される。 バグの原因がわからない。 バグの原因になるコードを書いたのは自分ではないが、修正する責任がある立場にいる。コードを書いた人間は退職して会社にいない。 バグの原因となる問題が、99.9%の信頼性を持つどこかのライブラリーで、それだけに最後に確認するところだった。 多数の人間がデバッグしようと何年も頑張ったが、誰も成功しなかった。 何年にもわたって実行した後にのみ起こる論理的エラー。 デバッグには自分の何も知らない分野での経験が必要。 バグの修正のスケジュールに余裕がない。 自分の首がかかっているのでバグを無視できない。 Stack Overflowがダウンしている！ Stack Overflowに行って自分が答えが欲しいと
既存のコードを参考にして新規にコードを書く事の光と闇 - 文系プログラマによるTIPSブログ
恐らくこれは開発現場であるあるな出来事だと思います。 今回のお題は「既存コードを参考にして新規コード書く」事についてです。 あなたが部下または外部の方に作業依頼をする時、どんな風にコードを書いたらいいかを事前に説明しますね。その時「この辺に書いてある既存のコードを参考に書いて下さい」と言ったりしますよね。 もしくは特に書き方の方針を伝えない場合は、依頼された側が「既存のこの辺のコードを参考に書きます、書きました」と言ったりします。 「参考」とは この言葉のポイントは「参考」という部分にあります。実はこの「参考」には光と闇が潜んでいるのです。 何故ならこの「参考」は、大抵の場合は「ほぼコピペ」を意味しているからです。 ☓ 「既存のコードを参考にする」 ◯ 「既存のコードをコピペする」 「ほぼ」と言っているのは、数カ所違うだけのコピペの場合が多々あるためです。 ほぼコピペのメリット 周りのコー
中の下のエンジニアを脱出するための仕事術
2. 自己紹介 ● 門田 矩明(かどた のりあき) ● 株式会社CyberZ 「F.O.X」 プロダクトマネージャ兼エンジニアマネージャ ● JavaエンジニアでFWはほぼSpring固定。JSもJavaと同じぐらいには好き。 ● 前職はSIerで、某レーベルのFCサービス作ったり、新卒就活サイト作ったり、 某出版社の楽器検索サイト作ったり、FXの取引＆周辺システム作ったりとか。 ● 2012年にサイバーエージェントに入社。 Amebaで複数のスマホ向け新規サービスにエンジニアとして参加しつつ、 (運良く)いくつか開発責任者したり、技術ボードやったりしてた ● スマホ広告周りの開発がやりたくなって、2014年にCyberZ 異動。 4. 中の下のエンジニアの特徴 ● 一通りの開発に関する経験はしている ● 降ってくるタスクは大体こなせるし、こなせる自信はある ● 職場では中堅エンジニアだし
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
"プロのプログラマ"を目指す初心者が最初に読むべきたった一冊の本
