How to Do Code Reviews Like a Human (Part One)
Lately, I’ve been reading articles about best practices for code reviews. I notice that these articles focus on finding bugs to the exclusion of almost every other component of a review. Communicating issues you discover in a constructive and professional way? Irrelevant! Just identify all the bugs, and the rest will take care of itself. So I had a revelation: if this works for code, why not roman
The 10x developer is NOT a myth
Update: you can find a Spanish translation of this blog post here. Last night, I tweeted the following: I'm confused by the claim that "10x" or "rockstar developers" are a myth. Are star athletes, artists, writers, and, uh, rock stars, a myth? — Yevgeniy Brikman (@brikis98) September 29, 2013 I got tons of replies and questions, but Twitter is an awful medium for discussion, so I’m writing this bl
Programming as a Way of Thinking
The power of modern programming languages is that they are expressive, readable, concise, precise, and executable This article was published in Scientific American’s former blog network and reflects the views of the author, not necessarily those of Scientific American Programming has changed. In first generation languages like FORTRAN and C, the burden was on programmers to translate high-level co
id Software Programming Principles
id Software co-founder John Romero tells the early story of the game company in this GDC 2016 talk and lists the programming principles that guided them towards the rapid development of many games including Doom and Quake with a very small team. Some of these principles resembles today’s common Agile practices while others do not. I like them and id definitely had good results, so the principles s
Entertainment - MarketWatch
Japanese baseball player Shohei Ohtani agrees to record $700 million, 10-year contract with Dodgers Japanese baseball player Shohei Ohtani has set a financial record to go along with his singular on-field performance, getting $700 million to make a 30-mile move up Interstate 5 to the Los Angeles Dodgers.
Linus Torvalds - Re: What is acceptable for -ffast-math? (Was: associative law incombine)
Re: What is acceptable for -ffast-math? (Was: associative law incombine) To: <dewar at gnat dot com> Subject: Re: What is acceptable for -ffast-math? (Was: associative law incombine) From: Linus Torvalds <torvalds at transmeta dot com> Date: Tue, 31 Jul 2001 15:50:28 -0700 (PDT) cc: <gdr at codesourcery dot com>, <fjh at cs dot mu dot oz dot au>, <gcc at gcc dot gnu dot org>, <moshier at moshier d
持たないプログラマ
仕事で成果を挙げたいのなら、何かをオウンしろという。 たとえばモジュール。機能。ライブラリやフレームワーク。まとまったコードを書いて、あるいは引き取って、自分の持ち物にする。バクを直し、人のコードをレビューして、持ち場の面倒を見る。 何かをオウンするのが、自分はあまり好きでない。なにしろめんどくさい。 コードをオウンするのは家を買うようなものだろうか。持ち家に憧れローンを組む人はいる。コードの対価として重責を引き取る人もいる。気持ちはわかる。自分にも憧れがあった。でも今は月々の返済に追われない身軽さが勝る。我ながら気が弱い。 オーナーシップには副作用もある。自分の所有権を守りたい心理が働く。領土を壁で囲いたい誘惑に駆られる。執着と責任の磁場に包まれて正気と勇気を保てるのか。 何もオウンせず働くのは借家暮らし。あるいは居候。部屋をひとつ間借りする代わりに家主の仕事を手伝う。コードから虫を追い
Most important skill in software development
Here’s an insightful paragraph from James Hague’s blog post Organization skills beat algorithmic wizardry: When it comes to writing code, the number one most important skill is how to keep a tangle of features from collapsing under the weight of its own complexity. I’ve worked on large telecommunications systems, console games, blogging software, a bunch of personal tools, and very rarely is there
Rebuild: Aftershow 91: With PHP, Everything Is Acceptable (Naoya Ito)
Naoya Itoさんと、Slack, プログラミングの才能、コーディングの楽しさ、ゼノブレイドクロス、シドニアの騎士などについて話しました。 Show Notes 私では「Slackがどうして愛されているか」ということが説明できない いかにしてSlackは市場を席巻したか Slack is killing email Atlassian Acquires Team Chat Service “Hall” To Bring More Non-Technical Users To HipChat Hipchat Ad Channel and group notification preferences – Slack Jacob Kaplan-MossのPyCon 2015における基調講演: プログラミングの才能という都市伝説 Keynote - Jacob Kaplan-Moss - Py
INTEL コード & ダウンロード
Using Intel.com Search You can easily search the entire Intel.com site in several ways. Brand Name: Core i9 Document Number: 123456 Code Name: Alder Lake Special Operators: “Ice Lake”, Ice AND Lake, Ice OR Lake, Ice* Quick Links You can also try the quick links below to see results for most popular searches. Product Information Support Drivers & Software
7 ways to be a better programmer in 2014 - O'Reilly Radar
7 ways to be a better programmer in 2014 Great tips to help you sharpen your skills Coders make resolutions, no? If your to-do-better list is still empty, consider these ideas from other programmers to put to use in the New Year. Even the smartest folks have room to grow. The following excerpts are contained in the book 97 Things Every Programmer Should Know edited by Kevlin Henney. Check Your Cod
静的型付き言語プログラマから見た動的型付き言語 - あどけない話
およそ20年前にAlan Kay の講演をきいたことがある。印象に残ったのは、彼が引き合いに出した McLuhan の言葉だ。 I don't know who discovered water, but it wasn't a fish. (拙訳)誰が水を発見したかは知らないが、発見者が魚でなかったことは確かだ。 誰しも信念という水の中を泳ぐ魚のような存在だ。思い切って飛び跳ね空気に触れてみなれば、自分が信念という水の中にいることに気付かない。 ある手法の利点を語るには、その手法の欠点や、他の手法の利点や欠点とできるだけ客観的に比較しなければ説得力がない。ただ、これを実践するのは難しい。この記事では、客観的になれているか自問自答しながら、動的型付き言語と静的型付き言語について比較してみようと思う。 僕は静的な C 言語から、動的な Perl、Lisp、JavaScript を経て、現在で
タダ飯よりも素敵なものは - steps to phantasien
GitHub co-founder の Tom Preston-Werner (以下もじょ先生) が お仕事のコードも大半はオープンソースにしたほうがいい という話を書いている。 (@higepon の tweet で知った。) 同じような主張は、ビジネスとしてのオープンソースが隆盛を極めた 2000 年前後にもみられた。 時は流れ、今はソフトウェアそのものよりはアプリケーションやサービスをウェブ越しに売る時代。 ハイテク企業の前線もコード自身からデータやユーザの時間といったコード以外の部分に少しづつ軸足を移しつつある。 そうした企業は十年前とは異なる文脈でコードをオープンソースにしはじめた… というだいたいの背景を踏まえつつ読むと、もじょ先生の話は感慨深い。 もじょ先生はスタートアップの founder/CTO らしい立場でオープンソースの利点を説いている。 私はスタートアップ勤務でもな
GitHub時代のオープンソース・プロジェクトとの付き合い方
■ GitHub時代のオープンソース・プロジェクトとの付き合い方 GitHubへpull requestする際のベストプラクティスからmaster ブランチで pull request していいのは小学生までってこともないの流れを読んでいて、先日ruby-listであったRedmineのRuby1.9,Rails3対応の話を思い出した。あのときは投稿者は納得して、「GitHub時代のコントリビューションの仕方」みたいなものを理解してくれたようなのだけど、その上で「masterでパッチ作るな」的なお作法を生真面目に受け取りすぎて敷居を高く感じてしまわれても困るよなぁと思った。 そこで、「GitHub時代にフリー/オープンソース・ソフトウェア(以下FOSS)プロジェクトと付き合うための五ヶ条」的なものをまとめてみた。まぁ、そんな大それたものでもないけど。 1. 貢献しようと意気込まない FOS
私がソフトウェア技術者でもありつづける理由 : 404 Blog Not Found
2010年09月25日22:45 カテゴリLoveCode 私がソフトウェア技術者でもありつづける理由 一言でいえば、「自分に報い続けたいから」ということになる。 私がソフトウェア技術者をやめた理由 - Rails で行こう！私の職業生活でもっとも多くの時間を注いだのがソフトウェア作りだ。その作業に対して、実際のところ、好きとか嫌いとか一言で割り切れるはずがない。複雑な感情を持っているというのが正直なところだ。 以下に照らし合わせれば、その複雑な感情とやらそのものがお嫌いなのだろう。 私の職業プログラマのとしての最大の欠点は、ソースコードに対して強い美意識を持たずにいられなかったところだろう。生来の生真面目な性格が災いし、私の基準で美しいとはいえないソースコードを敵視しすぎた。 で、何をもって美醜を決めているかといえば、コルモゴロフ複雑性と、そこからの距離をお使いのようだ。 うるう年を計算
〈 SL 〉: 古参プログラマのアドバイス by Zed Shaw
Tuesday, May 04, 2010 古参プログラマのアドバイス by Zed Shaw Advice From An Old Programmer (Learn Python The Hard Way Release 0.2 のあとがき) この本を終えて、もしかしたらもっとプログラミングをしようという気になってくれたかもしれない。仕事にするなんてこともあるだろうし、ただの趣味っていうこともあるだろう。どんな理由であれ、プログラミングを続けると決めたなら、正しい道を選んで最大限の楽しみを得られるような選択をしたほうがいい。 オレはものすごく長い間プログラミングをしてきた。あんまり長いんでもう信じられないぐらいつまらない活動になっている。この本を書いた時点でもう20ほどのプログラミング言語を知っているし、新しい言語もその変態度合いによって１日から１週間ぐらいで学ぶことができる。でもこん
Pivotal Trackerの「Getting Started」を翻訳しました - Ruby x Agile
ストーリーベースの計画づくりのためのツール、Pivotal TrackerのGetting Startedのページを永和システムマネジメントの有志で翻訳しました。開発元であるPivotal Labsの許可を得たので公開します。どうぞご利用ください。 Pivotal Tracker: はじめかた Pivotal Trackerについて 永和システムマネジメントでは、まだ一部ではありますが、社内やお客さま向けのプロジェクトで3月頃からPivotal Trackerを使っています。Pivotal Trackerは kakutani が翻訳者のひとりである『アジャイルな見積りと計画づくり』の考え方をほとんどそのまま実装したようなとても素敵なツールで、プロジェクトにおける計画や見積りといったプロセスをアジャイルにしていくことを強力にサポートしてくれます。 現状は英語UIのみであるにもかかわらず、一緒
Bjarne Stroustrup "What Should We Teach New Software Developers? Why?" - Communications of the ACM
Computer science must be at the center of software systems development. If it is not, we must rely on individual experience and rules of thumb, ending up with less capable, less reliable systems, developed and maintained at unnecessarily high cost. We need changes in education to allow for improvements of industrial practice. Back to Top The Problem In many places, there is a disconnect between co
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
How I created HTTP Prompt and got 5000+ stars on GitHub
エンジニアtype 技術者のキャリアを考えるWebマガジン - 転職＠type
