天才プログラマーの「締切に対する考え方」に、感銘を受けた。
わたしは、ビジネスノウハウ本が嫌いだ。大嫌いだ。 個人で効率化できる部分なんてかぎられているのに、「お前が努力すれば成果を出せる」的なのが気に食わない。 それなら先に、ムダな会議を減らせって話だ。 ……というひねくれ者のわたしだが、とある本に出会って、自分でもちょっと戸惑うくらい感銘を受けてしまった。 どうやらわたしは今まで、”2流”のビジネス書しか知らなかったらしい。 Windows95の基礎をつくった天才プログラマーが語る、3つの仕事術 わたしが手に取ったのは、『なぜ、あなたの仕事は終わらないのか』という本だ。 ふだんこういった本はあまり読まないけど、kindle Unlimitedで読めるし、評価が高かったから、気まぐれでダウンロードしてみた。 著者は中島聡氏。 1960年北海道生まれ。早稲田大学高等学院、早稲田大学大学院理工学研究科修了。 高校時代からパソコン系雑誌『週刊アスキー』
Visual Studioでペアプロ環境を実現する「Live Share」が、テキストチャットとボイスチャット機能を統合へ
マイクロソフトは、Viual Studioファミリーでリモートでもペアプログラミング環境を実現する「Live Share」の新機能として、テキストチャットとボイスチャットをプレビュー公開することを明らかにしました。 Live ShareはVisual StudioやVisual Studio CodeなどのVisual Studioファミリー製品間をネットワークで接続し、ペアプログラミング環境を実現する機能です。インターネット経由でも機能するため、物理的に離れた場所であってもリモートでペアプログラミングを行うことができます。 今回発表されたのは、このLive Shareにテキストチャットとボイスチャットを統合する、というものです。現在のLive Shareは1つのソースコードを2人で同時に編集することはできても、プログラマ同士の会話は別に電話やチャットツールなどを用いなければ行えませんでし
プログラミングの命名規則ガイドラインを規定するオープンソースプロジェクト「NamingConvention」
◆ NamingConvention https://namingconvention.org/ 紹介 「NamingConvention」は、プログラミング命名規則のガイドラインを作成・収集・維持するオープンソースプロジェクトです。 「C#・Git・Java・PHP・VueJS・Python」が、現在作成進行中です。 Gitの章には、ブランチ名やコミットメッセージ、プルリクのネーミング規定が記載されています。 例えば、ブランチネームだと必須や許可と一緒に例文も記載されています。 プログラミング言語（Java）だと、このようになっています。 推奨のネーミングというより、キャメルケースなど、最低限準拠すべき形式が書かれています。 プログラミング版wikipediaになるような、熱量高いコミュニティが続いて欲しいです。 ◆ NamingConvention https://namingconv
無料で読めるITまんが 2019年版
ネット上にはたくさんのIT系のコンテンツがあふれています。そのほとんどは文章として書かれていますが、一部にはマンガの形で面白く分かりやすくしたものもあります。 ここでは、マンガ化されたITコンテンツを集めてみました。毎年夏の恒例企画、ITまんがの2019年版です。 今年のトピックは新着マンガの1つ目と2つ目で紹介している、AWSとレッドハットが自社製品の解説をしているマンガです。企業向けのビジネスが中心のこの2社がマンガという手法を使ったことは注目に値するでしょう。また3つ目と4つ目で紹介している、すがやみつる氏のマンガは懐かしい思いで読む読者も多いのではないでしょうか。 もしここに掲載していないITまんがをご存じでしたら、Twitter（@publickey）などで教えてください。毎年更新する予定です。 2019年版の新着ITまんが New! 七転び八起きのAWS開発日記 新米プログラマ
2019夏、先輩が若手に贈る「お世話になった技術書60選」- 入門からガチまで – | DevelopersIO
「この本にはお世話になったなぁ〜」 「今でもたまに読み返してます」 「マジでめちゃめちゃ影響受けた」 「そう、こいつが俺のエンジニア人生を変えやがったんだ...」 ↑「こんな本を紹介してください！」と社内チャットで投げてみたら、すんごいことになったのでそのリストをシェアさせていただきます。 ※推薦理由はあくまで推薦者による個人的な意見や思い入れたっぷりなので、それを踏まえてお楽しみください。 目次 アプリケーション/プログラミング ドメイン駆動設計 Java言語で学ぶデザインパターン入門 Pro Git BINARY HACKS Effective Java リバースエンジニアリング―Pythonによるバイナリ解析技法 なるほどUnixプロセス ― Rubyで学ぶUnixの基礎 リーダブルコード メタプログラミングRuby 第2版 Head First デザインパターン テスト駆動開発 C
VSCodeを使いこなすための一歩、コードを書く時に知っていると便利なショートカットのまとめ
Visual Studio Codeでコードを書く時に知っていると便利なショートカットを紹介します。コードを書く時に自分がよく実行する操作のショートカットを覚えておくと、作業効率は格段にアップします。 21 VSCode Shortcuts to Make Coding Faster and More Fun by jsmanifest 下記は各ポイントを意訳したものです。 ※当ブログでの翻訳記事は、元サイト様にライセンスを得て翻訳しています。 はじめに VSCodeで利用できるショートカットのいくつかを見逃しているかもしれません。すべての人がすべてのショートカットを調べて、より速くコードを作成し、より多くの人に役立つショートカットを見つける時間があるわけではありません。 この記事では、より高速なプログラマーになるためのお気に入りのショートカットをリストアップしました。これらのショートカッ
プログラマーを30年間やってきた経験から学んだことまとめ
プログラマーにとって「どうすればより効率よくプログラムを組み上げられるのか」は常に頭を悩まし続ける問題の1つとなっていますが、その道のエキスパートであるエンジニアのジュリオ・ビアソンさんが30年間ソフトウェア開発に携わってきた経験から学んだことについてブログにまとめています。 Julio Biason .Net 4.0 - Things I Learnt The Hard Way (in 30 Years of Software Development) https://blog.juliobiason.net/thoughts/things-i-learnt-the-hard-way/ ビアソンさんは多数ある「学んだこと」を以下の3つに大きくわけてまとめています。 ◆ソフトウェア開発について ◆チーム・仕事について ◆個人的なことについて これからプログラマーになろうとしている、あるいは
【まとめ】これ知らないプログラマって損してんなって思う汎用的なツール 100超 - Qiita
2019/06/11追記: これは2012年の投稿です。なぜかはてなブックマークで拡散されていますが、内容は時代にそぐわなくなったものもあるのでご注意ください。 これ知らないプログラマって損してんなって思う汎用的なツールのコメントに寄せられたツールを分類分けしてみました。 解説は、ほぼコメントに寄せられた内容のコピペです。 URLのみの記述は公式サイト(か、ほぼ公式サイトと化しているサイト) 公式サイトとは別に、ページタイトルだけでツールを説明しきっているページへのリンクも付けておきました。類似ページが複数ある場合は、はてブのブックマーク数が多いものを選びました。 知らないツールもあるので、分類がいいかげんなところもあると思います。何か気づいたらコメントください。 解説が不十分なツールについても、補足（コピペで本文に取り込める体裁だとありがたい）を頂けると助かります！ 元ネタの投稿は現在進
【まつもとゆきひろ氏 特別講演】20代エンジニアのためのプログラマー勉強法のまとめ 2019/3/30 - Qiita
予想していた技術的な勉強法というより、エンジニア、ビジネスマンとしての生き方や、成功するための方法論を20代に向けてMatzさんが伝えてくれたのでまとめます。(自分なりの解釈も少し入ってます) とてもためになる講演でした。個人的には特に前談2、3、4、5、6がためになりました！！ Matzさんありがとうございました! 講演内容 前談1. テクノロジーとは人を幸せにするためのもの 前談2. 若いうちから頑張ろう 1.学生と社会人の"勉強"の違い 2.なぜ勉強するのか？ 3.勉強についてのTips(what, where, when, how) 4.とにかくアウトプット 5.成功するためのTips 6.最後に３つのアドバイス ※Ex)で書いている具体例はMatzさんが使われたものをそのまま使ってます。 前談1. テクノロジーとは人を幸せにするためのもの 本来人を幸せにするためのテクノロジーが人
プログラミングできる人とできない人との間の深い溝 - masatoi’s blog
どうしてプログラマに・・・プログラムが書けないのか?を読んでいて出てきたので出展の一つを訳してみた。Separating Programming Sheep from Non-Programming Goatsの和訳。 プログラミングというものには向き不向きが強く出るということはわりと知られていると思うが、このエントリではプログラミングができるかできないかは比較的簡単なテストによって、プログラミングの訓練を始める前の段階で分かると主張している。どうしてプログラマに・・・プログラムが書けないのか?では、そもそもこの事前テストをパスしていないような人達までプログラマとして応募してくると言っており、その判定法として有名なFizzBuzz問題を挙げている。 追記（2019/2/28) 注意： なおこの論文はしばらく前に著者の一人によって撤回されたようです Camels and humps: a r
今、最も面白い職種は「プロダクトマネジャー」だ――及川卓也氏が説く、DX時代のIT業界サヴァイブ術：外の世界とのタッチポイントを増やせ！ - ＠IT
2025年、IT業界が変わる 経済産業省は2018年9月、デジタルテクノロジーによる企業価値の創出を目指す「デジタルトランスフォーメーション（DX）」に関する調査報告「DXレポート ～ITシステム「2025年の崖」克服とDXの本格的な展開～」を発表した。 「『DXレポート』では、デジタルで新事業を始める場合には情報システムの内製が重要になると指摘しています。この指摘が受け入れられるなら、SI企業も変わっていくはずです」と及川卓也氏は言う。 及川卓也氏 早稲田大学理工学部卒業後、日本DECに就職。営業サポート、ソフトウェア開発、研究開発に従事し、1997年からはMicrosoftでWindows製品の開発に携わる。2006年以降は、GoogleにてWeb検索のプロダクトマネジメントやChromeのエンジニアリングマネジメントなどを行う。2015年11月、技術情報共有サービス『Qiita』など
上級プログラマってどんな本読んでるの？中堅プログラマがマウンティング取られないための名著8選 - 世界が幸せで在ります様に
この記事を読もうと思ったということは，あなたはそこそこできるプログラマ，あるいは社内でも自他ともに優秀と認められるほどの実力者かもしれません． ただし，そんな状況でも業界で名が知られる優秀な人や社内の上級プログラマと対峙した時身構えてしまい相手の不思議な理論に屈服してしまう経験はありませんか？本気でプログラミングをすれば互角，あるいは言語によっては自分の方が明らかに上だと自負できる状況にもかかわらず． そんな中，そこまで優秀そうに見えないのにうまくマウンティングを回避しているプレーヤーを見たことはないでしょうか？ 彼らと自分は何が違うのか？ 簡単に言えば，知ってるコンピュータ科学の量と，何らかの物事に対して同調するのではなく先駆者的にそれを宣言することです．それを少しでも発揮できる名著をこれからご紹介します． ※安心してください，日本語の書籍だけ紹介します． Coders at Work
元SE、現・会社役員の父が教えてくれた、「35歳プログラマー定年説」に抗う方法【五十嵐悠紀】 - エンジニアtype | 転職type
明治大学 総合数理学部 先端メディアサイエンス学科 講師 五十嵐 悠紀(@yuki_igrs) 2004年度下期、2005年度下期とIPA未踏ソフトに採択された、、『天才プログラマー/スーパークリエータ』。日本学術振興会特別研究員(筑波大学)を経て、明治大学総合数理学部の講師として、CG/UIの研究・開発に従事する。プライベートでは三児の母でもある 実家に帰ってきて、父と話をしていた時のこと。50代半ばに差しかかろうとしている父が「最近、プログラミングをしているんだ」と言い出しました。 わたしの父は現在、会社役員をしていますが、もともと技術畑の人間で、専門はCADシステムでした。わたしが今研究している分野と非常に近い分野です。わたしの博士時代の指導教官は、父と20年来の仕事仲間だったりもします。 現場から離れて久しい父が、なぜまた突然プログラミングを始めたのか。今回はわたしが企業勤めの父か
プロのエンジニアに必要なものとはなんだ？『Clean Coder』に学ぶ信頼獲得のメソッド【今こそ読み解きたい名著】 - エンジニアHub｜Webエンジニアのキャリアを考える！
プロのエンジニアに必要なものとはなんだ？『Clean Coder』に学ぶ信頼獲得のメソッド【今こそ読み解きたい名著】 プロのエンジニアならば、必ず有する周囲からの厚い信頼。しかし、信頼とはどのように獲得すればいいのでしょうか。名著『Clean Coder』から、エンジニアらしい信頼獲得の術を学びます。 数多くの開発者から支持を受け、読み継がれてきた名著。そこには読み継がれる理由があります。 名著には、内容・ボリュームともに充実した書籍が多く、概要に目を通しただけで本を読んだつもりになっていたり、腰を据えて読む時間がなく「積ん読」してしまいがち。「エンジニアが絶対読むべき書籍●選」といった記事をブックマークするだけで読んだつもりになっていないでしょうか。 ポイントを押さえつつ内容を深掘りし、名著の根底に流れるエッセンスを開発に活かしましょう。 アプリエンジニアの池田 惇（@jun_ikd）で
【2017年8月】先輩エンジニアに聞いた信頼できる書籍まとめ - Qiita
はじめに 今期より、自分のいる会社で社内報を発行することとなり、 その中で現役エンジニアからリアルな声を収集しています！ そのうちのひとつとして掲載したのが「エンジニアが選ぶ良書まとめ」。 今回は、社内だけで公開していた良書の情報をこちらでも備忘録としてまとめておきます。 2017/09/4 追記： 本投稿を公開したことで予想以上に反響があり、良書とは？を改めて考えさせられました。 社内のアンケートでは、新人に読んでほしい本、手元にあると便利だと思う本、という趣旨で 集計したので、「良書」という意味では人それぞれ捉え方が違うのかな、と思いタイトルを変更しました。 ヒアリング対象 エンジニア向けの書籍はたくさんあるものの、技術書をはじめ、どれも比較的高価ですよね・・・。 バージョンupしたら使い物にならない書籍もあるし、学習にはお金も時間もかかる！ なので、書籍購入を失敗しないように、要領よ
入社からの半年間でコードレビューで指摘されたことのまとめ - 30歳からのプログラミング
実務未経験でプログラマとして入社して半年以上が経った。 コードレビューで指摘されたことを備忘録としてまとめておく。 自分なりにまとめたものなので、レビュアーが言いたかったこととニュアンスや解釈がずれている可能性はある。 初歩的な内容ばかりで我ながらうんざりする。 せっかく優秀な同僚ばかりなのだからもっと高度なことを学びたいが、こういう初歩的なことが出来ないのが俺の現状なのだから、仕方ない。 そもそもPullRequestを送ったこともなかったわけだし。入社初日は、一人でPullRequestの出し方を練習していた。 それを考えればまあ、こんなものだろうか。 当たり前のことをちゃんと当たり前に出来るようになって、早く、次のステージに進みたい。 PullRequest(PR) PRのタイトルは分かりやすいものに。必要に応じてチケットの番号なども入れる。 コミットやPRは出来るだけ粒度を細かくす
プログラマをクソコードで殴り続けると死ぬ - megamouthの葬列
ここにクソコードがある。 誰が作ったかはわからぬ。それが、どのような経緯でクソコードとなったのか、 あるいは、最初からクソコードであったのか、それらは全てクソコード自身が知るのみである。 ファーストコンタクト ある日、営業からシステム案件を打診されたので見積もりして欲しい。というメールが来る。 とある企業の既存システムに機能を追加する簡単な案件ですが、なななんとソースや仕様書をご支給いただけます！ と、それはサンタにプレゼントが貰えると信じて疑わぬ子供のような真っ直ぐなメールである。 ソースコードが入った圧縮ファイルを受け取ったプログラマは、早速、コードを読んでみる。 そのシステムが本当にいいコードで書かれているかを判断するには時間がかかるが、 クソコードであるかはおおよそ30分でわかる。 インデントがタブとスペースどちらかに統一されていないとか、フレームワークの誤用があるとか、またはフレ
ある文系プログラマがテックリードを任されるまでに学んだこと ── 最前線で生き延びる4つの戦略 - エンジニアHub｜若手Webエンジニアのキャリアを考える！
ある文系プログラマがテックリードを任されるまでに学んだこと ── 最前線で生き延びる4つの戦略 コンピュータサイエンスの専門教育を受けず、20代半ばで本格的なプログラミングを始めた文系エンジニアが、いかに学び、考え、生き延びてきたのかを伝えます。 こんにちは。白山（@fushiroyama）と申します。現在は新聞社のデジタル事業部署で、モバイルアプリ開発のテックリードをしています。 自分のエンジニア人生を振り返ると、これまでの道のりは決して平坦ではありませんでした。コンピュータサイエンスの専門教育を受けず、本格的にプログラミングを始めた年齢も23、4歳と決して早くありません。 そんな自分が、いかにして開発チームのリーダーを任せてもらえるまでになったか？ 考えてみると、次の4つの戦略で生き延びてきたようです。 自分だけの居場所を見つける 必要な知識を効率的に取捨選択する 他のエンジニアに差を
新人プログラマのうちに身に付けたい習慣、考え方（この半年で学んだことと反省） - Qiita
新人プログラマのうちに身に付けたい習慣（この半年で学んだことと反省） はじめに 半年よりちょっと前に未経験からプログラマになりました。 プログラマと言っても、この約半年間はほとんど研修を受けさせていただいていた感じなので、偉そうなことは言えません。 しかし、この約半年で反省したことや学んだことを自戒の念も込めて、まとめました。 主体的に学ぼう 能動的に自ら学び、自走しましょう。 新しい技術を学ぶということは非常に楽しいことです。 すごい先輩方は大抵、新しい技術を身につけるためにその技術を学ぶことを「その技術を勉強した」というよりも、「その技術を使って遊んでみた」と表現している気がします。つまり、必要だからしょうがなく学ぶのではなく、半ば趣味として新しい技術で遊んでいたら、身についたーという感じでしょう。 教えてもらって学ぶという姿勢ではなく、自ら楽しいから学ぶ(=その技術で遊んでたら身につ
コピペするプログラマに足りないもの 〜 プログラミング脳の鍛え方 | Social Change!
長くなったので先に三行でまとめておこう。 コピペするプログラマが生まれるのは教育の問題ではないか（仮説） 文法は学んでも処理の流れから考えることは教わっていない（根拠） ロジックを訓練するには脳内プログラミングが良いのでは？（提案） 少し前に私のMediumで、こんな記事を書いた。タイトルが言葉足らずだったおかげで、少し話題になった。「量産型プログラマを撲滅したい」 今回の記事では、この中で書いたコピペするプログラマがなぜ生まれるのか、どうすれば良いのか、考えてみたい。 どうすれば見分けられるのか 書いたプログラムを説明させてみれば、その人が、ちゃんと考えて作れる人か、コピペでしか作れない人か、すぐにわかる。自分の書いたプログラムの流れを説明できるということは「わかって書いた」ということだ。わかっていなければ説明できない。 「わかって書く」という一見すると当たり前のことができない人もいる。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
