Stop following tutorials designed for beginners. Start working on projects that actually challenge you. Become a better engineer through deliberate practice.
The Software Pro's Best Kept Secret.
Stop following tutorials designed for beginners. Start working on projects that actually challenge you. Become a better engineer through deliberate practice.
Learn to Code – Grasshopper
Welcome to Grasshopper, the coding app for beginners Learning to code opens new doorscreates new hobbieslaunches new careersdevelops new skillsexpands your networkopens new doorscreates new hobbieslaunches new careersdevelops new skillsexpands your networkopens new doorscreates new hobbieslaunches new careersdevelops new skillsexpands your networkopens new doorscreates new hobbieslaunches new care
プログラマをクソコードで殴り続けると死ぬ - megamouthの葬列
ここにクソコードがある。 誰が作ったかはわからぬ。それが、どのような経緯でクソコードとなったのか、 あるいは、最初からクソコードであったのか、それらは全てクソコード自身が知るのみである。 ファーストコンタクト ある日、営業からシステム案件を打診されたので見積もりして欲しい。というメールが来る。 とある企業の既存システムに機能を追加する簡単な案件ですが、なななんとソースや仕様書をご支給いただけます！ と、それはサンタにプレゼントが貰えると信じて疑わぬ子供のような真っ直ぐなメールである。 ソースコードが入った圧縮ファイルを受け取ったプログラマは、早速、コードを読んでみる。 そのシステムが本当にいいコードで書かれているかを判断するには時間がかかるが、 クソコードであるかはおおよそ30分でわかる。 インデントがタブとスペースどちらかに統一されていないとか、フレームワークの誤用があるとか、またはフレ
あっと驚かせるJavaプログラミング(をやめよう） - Qiita
はじめに 驚き最小の原則（法則）という言葉があります。 Wikipediaの記事を引用すると http://ja.wikipedia.org/wiki/%E9%A9%9A%E3%81%8D%E6%9C%80%E5%B0%8F%E3%81%AE%E5%8E%9F%E5%89%87 ユーザインタフェースやプログラミング言語の設計および人間工学において、インタフェースの2つの要素が互いに矛盾あるいは不明瞭だったときに、その動作としては人間のユーザやプログラマが最も自然に思える（驚きが少ない）ものを選択すべきだとする考え方である。 要するに、使うときに「おやっ？」という驚きが少ないほうが良いプログラムであるといえます[1]。 [1]: どっちが驚きが少ないか迷う場面もかなり多いですが・・・ この記事では敢えて驚きの多いプログラムの書き方を紹介します。驚きの多いプログラムを読むとどんな気分になるか、
"Write Code Every Day" 1年 - すぎゃーんメモ
1年前のjava-ja.OSSで @t_wada さんの話を聴いた翌日から実践し始めた"Write Code Every Day"、どうにか1年間つづけることが出来た pic.twitter.com/scVbkZFZI9— すぎゃーん💯 (@sugyan) October 6, 2016 元記事 John Resig - Write Code Every Day 日本語訳 毎日コードを書くこと - snowlongの日記 この記事を読んだときは「へー」くらいにしか感じていなかったのだけど、 1年前の10月5日のjava-ja.OSSでのid:t-wadaさんの発表を聴いて、実際に身近な知っている人たちが実践しているのを知って、「よし自分もやってみよう」と始めたのがきっかけ。 OSS についてあれこれ from Takuto Wada www.slideshare.net 元記事で ブログ
SOLID Go Design | Dave Cheney
This post is based on the text of my GolangUK keynote delivered on the 18th of August 2016. A recording of the talk is available on YouTube. This post has been translated into Simplified Chinese by Haohao Tian. Thanks Haohao! This post has been translated to Russian by Artem Zinoviev. Thanks Artem! How many Go programmers are there in the world? How many Go programmers are there in the world? Thin
Peter Bourgon · Go best practices, six years in
(This article was originally a talk at QCon London 2016. Video and slides here.) In 2014, I gave a talk at the inaugural GopherCon titled Best Practices in Production Environments. We were early adopters at SoundCloud, and by that point had been writing, running, and maintaining Go in production in one form or another for nearly 2 years. We had learned a few things, and I tried to distill and conv
なぜひどいコードを書いてはいけないか - hitode909の日記
ひどいコードは何やってるか分からない ひどいコードが何やってるか分かっても、なぜそうなってるのか、そこを変えるとどうなるか分からない ひどいコードは新たな変更に耐えられず書き直されることになる ひどいコードを書き直すには、ひどいコードがどうなっているか理解し、どこを変えるとどうなるのか理解する必要がある ひどいコードはたいていひどいテストコードが支えていて、テストコードがあったとしてもひどいコードと同様の問題があり、頼れるものが何もない どんなにひどいコードでも、書いた人を憎んではいけない。たとえ自分の書いたコードだとしても、先輩の書いたコードだとしても、ソフトウェアとしてひどい物にはひどいと言っていくことが大切で、だからと言って人に向かってひどいと言ってるわけではない。 最高の仲間たちが日々変化する難しい問題に対処していいコードを書いたり、ときにはひどいコードを書いている、という😇的な
おはぎレビュー - パルカワ2
我々の世界では、人間が作ったおはぎをうんこでないかチェックすることを「おはぎレビュー」と言う。 おはぎを作っていたつもりがうんこを作っていた事は人間であればよくある。 それは大した問題ではない。問題なのは、作ったあとにうんこをおはぎとして出してしまうことである。なので、おはぎレビューが存在するのである。 「おはぎレビュー」は、様々なことを気をつける必要があるが、その中に互いを理解させよう・しようと努力をするというのがある。 レビュイーは、わざわざうんこを作る嫌がらせをしたいわけではない。知らぬ間にうんこを作ってしまったのである。 知らぬ間にうんこを作った人間（レビュイー）は、レビュアーから見るとただのうんこを「超うまくて最高のおはぎ」だと思っている。 なので、おはぎレビューでレビュアーに「メッチャ臭い最悪です。今すぐ捨てるべき臭いウンコ臭いマジ臭い」と言われると「そんなことない！！これはお
srclib
srclib is a hackable, multi-language code analysis library for building better software tools. srclib makes developer tools like code search and static analyzers better. It supports things like jump to definition, find usages, type inference, and documentation generation. srclib consists of language analysis toolchains (currently for Go, Python, JavaScript, and Ruby) with a common output format, a
実践的な設計って、なんだろう？
Devlove 名古屋 2014-5-18 DDD, Object Oriented Design, ドメイン駆動設計 オブジェクト指向設計
あなたも地域のコミッターに。Osc tokyo 2014 spring
オープンソースカンファレンス 2014 Tokyo/Spring 「あなたの住む街のコミッターになろう。オープンな技術で地域課題を解決する、Code for Japan セミナー」 で発表した資料です。
技術的負債という(非エンジニアにとっての)隠しパラメータが生産性100倍を起こす - mizchi's blog
元糞コードマイスターとしては、生産性については思うところある。 技術的到達深度が深い人じゃないとそもそもかけないコードってのももちろん存在して、その前提で10倍とか100倍になりうる話をする。 そもそもマイナスになる人がいるって話。 隠しパラメータをモデル化 エンジニアA:「週に10の成果を出して3の負債を生む人」を考える。この人は開発を止めてリファクタリングをすれば10-3 = 7の技術的負債を返却できるとする。 ここで正確には成果10には* aの係数が掛かっている。これはプロジェクト開始時1.0で、技術的負債が貯まるほど0に近づいて行く 次に、エンジニアB:「週に15の成果を出して10の負債を生む人」を考える(これにも係数aがかかる)。この人は見た目上は上の人の1.5倍速く成果を出しているように観測できるが、負債もたまりやすい。リファクタしても綺麗になりにくい。 これは割とエンジニアに
きっと何者にも成れないモジュールたちに告げる~静的解析、しましょうか~ - mixi engineer blog
たんぽぽグループのhirokiです。たんぽぽグループとはmixi内の「刺身にたんぽぽをのせる仕事をなくす」ことを目的とした技術者集団です。 「あれは、たんぽぽではない食用菊である」 「スーパーの生鮮食品バックヤードが片手間にやってるよ。」 というご批判・ご指摘をうけ、今後は「道路に片方だけの軍手を落とす仕事をなくす」ことを目的としていこうかなどの検討を重ねました結果、「細けぇこたぁいいんだよ。」という結論に至ったことをこの場を借りてご報告させていただきます。今後ともたんぽぽグループを御ひいきによろしくお願いいたします。 と、ご報告をさせていただいたところで、本題にはいります。 YAPC::Asia Tokyo 2011 先日Perlのお祭りことYAPC::Asia Tokyo 2011においてLTをさせていただきました。その資料のご紹介とちょっとした解説をさせていただきます。 静的解析、し
新人プログラマーに読ませて欲しいネーミングの大切さ - プログラマー幸福論
Photo from Kıvanç Niş ネーミングについてまじめに長文を書いてみました。もし、あなたの会社にネーミングに疎い新人プログラマーがいたら読ませてやってください。 ちなみに、この記事はシステム開発のネーミングについて書いています。また、このブログの特性上、英語でのネーミングを想定していますが、日本語のネーミングでも同様に考えることができると思います。 1. ネーミングの重要性 一般に、熟練のプログラマーほど、プログラミングにおける ネーミングに時間をかけます。それはなぜでしょうか。 あなたが付けたその変数名 data は、その時点では、自分のために付けた「目印的なもの」であったかもしれません。しかし、そのソースコードを引き継いだ担当者など多くの人が、その名前を見ることになります。 // データを取得する var data = getData(1); そしてその名前は、そのソー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
NerdyData