Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
難しいプログラムでは自分がいままで書いたコードが正しく動くと信じて残りのコードを書く必要がある | by Rui Ueyama | Medium
Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
小さいライブラリを採用する - mizchi's blog
僕がJavaScriptでライブラリを選定する際、迷ったら小さいものを使う。その理由について。 前提 前提として、枯れた環境で大きいフレームワークができるのは理解できるし、メリットも大きい。あるいは言語それ自身と区別できないぐらいに発達したフレームワークに依存するのも理解できる。RubyにとってのRailsとか、ErlangのOTPとか(いや、これは詳しくないけどそうなんだろうなっていう予想なんだけど)。 危険信号 今のJS界隈は動きが早すぎて、何に依存するのも危ない。とくにフレームワークと銘打たれたものは、でかすぎてどれも危険信号を放っている。 数年後、廃れてしまったフレームワークで開発し続けるのは、僕個人としてもあまり関わりたくないし、現場の離職リスクとして数字に出るだろうし、採用後の教育コストの問題になる。だいたいそういうものは元の設計者もいなくなるものだ。プロダクトの死を意味する。
ソフトウェアエンジニアリングにおける認知バイアス5つ | POSTD
人間の論理は、私たちがプログラミングして毎日使っているマシンの論理とは違って完璧ではありません。人間は間違えますし、悪い精神的習慣を確立してしまいますし、エンジニアとして成功するための能力に悪影響を及ぼす認知バイアスをたくさん持っています。ソフトウェアエンジニアとして定期的に目にする一般的なバイアスのうち5つを見ていきたいと思います。 1. 根本的な帰属の誤り 根本的な帰属の誤りは、個人の行動を説明するにあたって、気質的または個性的な面を重視しすぎて、状況的な面を軽視しすぎる傾向を言う。対応バイアスとも。 （参照） これは私のお気に入りの認知バイアスです。”至る所で”見られるからです。道で誰かに行く手を遮られると、その人を完全に嫌なヤツだと思ってしまいますが、自分が同じことをしてしまう時は、相手が見えていなかったとか、会議があって遅刻できなくて急いでいたといった理由があります。誰かがバグを
プログラミングとは何なのか - hitode909の日記
会社でボードゲームしてる人たちがいる。 僕はボードゲーム苦手で、たまにやっても全然勝てない。 将棋とかイメージすると、こっちがこういう手を出すと相手はどうするか、そしてその次は、というのを予測すればよいのだけど、なんかそれがめんどうで、なんでこんなこと考えないといけないのか、とか考えだしてくたびれてしまう。 ずっと論理的に考えるのが苦手で、すぐめんどうになってやめてしまう。 普段、仕事や遊びでソフトウェア作ってるのだけど、よく考えると、ソフトウェアの動作が論理的なだけで、ソフトウェア作るのは勘でできる。 ソフトウェアが正しく動くかどうかは論理的に決められて、電卓アプリなら計算結果が狂ってたら間違っているけど、その電卓アプリがどのように作られたか、には正しさはない。逆立ちして作っても、猿にタイプライターを渡して作っても、計算結果合ってれば良い。 過去のデータとか経験によると猿に書かせるのは効
日本語で読める IT名文書 三選 - naoyaのはてなダイアリー
pplog の方に書いたけど、別にブログに書けばいいかと思い直したので投稿。Slack でチャットしてて、なんとなくこれ面白いよ URL を共有する機会があったので適当に選んだもの。 伽藍、バザール、ノウアスフィア、おなべ(3) http://www.artonx.org/diary/20120411.html#p01 artonさんがノウアスフィアの開墾についてわかりやすく書いてるもの。原文はちょっと長くて読むのが大変だけど、こっちは分かりやすいし、面白い。OSS の構造がなんかわかったきになる、すごい。 Steve Yegge の Google とプラットフォームに関するぶっちゃけ話を訳した http://anond.hatelabo.jp/20111018190933 (前編) http://anond.hatelabo.jp/20111018192953 (中編) http://a
クソコードに対する怒りとコードレビューにおける人格攻撃について | おそらくはそれさえも平凡な日々
デキるプログラマだけが知っているコードレビュー7つの秘訣 7つの秘訣の1〜5は本当にそのとおりだと思います。 「怒り」って言葉を使っているところはなかなか画期的だと感じた。というのも僕は前から「人格攻撃に思われて」しまうような、コードで人を殴るようなことをしてしまう人が出てきてしまうのは何故かということを考えた時に、そこには「コードに対する怒り」があるからだろうなと思っていたからである。怒りがあるからこそ強く指摘しすぎてしまうことが起こりうる。 「怒り」というのはつまり「感情」である。であれば、「その『怒り』はコードに向けられたものであり、書いた人に対してのものではないので、その人に対しての攻撃ではない」というのは、理屈ではかろうじて通るかもしれないが、書いた人の「感情」的には通らないこともあることは理解したほうが良いと思う。 じゃあ怒らなければ良い、という話にはしたくなくて、どうしても怒
Big Sky :: Rob Pike のプログラミングに関する5つの掟
« git で pull-request を clone する設定が覚えられないので alias 書いた。 | Main | Vim で peco する「veco」書いた。 » 掟1 プログラムが時間を費やす箇所がどこにあるのかは知り得ない。ボトルネックは意外な場所で発生するため後知恵で批判してはならないし、ボトルネックがどこにあるか証明出来るまではスピードハックを入れてはいけない。 掟2 測定しよう。測定し終えるまでは、さらにはコードの一部分が残りのコードの支配的な量とならないならばチューニングを行ってはいけない。 掟3 凝ったアルゴリズムは、n が小さいときに低速となり、通常 n は小さい。凝ったアルゴリズムは大きな定数を有する。n は頻繁に大きくなり得ることを知るまでは凝ったアルゴリズムを得てはならない。 (n が大きくなる場合であっても、まず掟 2 を行いなさい） 掟4 凝ったアル
ある中級プログラマの告白 | POSTD
私は中級レベルのプログラマです。 基本を理解するのは得意です。過去の失敗をきちんと分析できるくらい経験を重ねていますし、もっと知るべきことは山ほどあることも分かっています。 特筆すべきは、自分で身につけるべきことを知ったうえで、それを吸収しようと積極的かつ精力的に取り組んでいる点でしょう。 プログラマとしての能力は平均的なものに過ぎないと、心から納得するまで時間がかかりました。今では、よく理解できないままに誰かの意見を受け売りする必要など感じていません。知らないことがあっても、それを他人に悟られるのは怖くありません。 でも以前は違いました。信じられないかもしれませんが、私はかつてプログラミングの達人だったのです。 自分の能力を誤って評価していたのは、比較的孤独な環境でスキルを学んだためでしょう。当時はコンピュータを持っていることさえ、ちょっと特別なことでした。使い方を知っているとなれば、な
毎朝5時に起きてコードを書くソフトウェアエンジニア - higepon blog
毎朝5時に起きて出勤前にコードを書くという習慣を始めた。2週間経ったのでまとめてみようと思う。この記録が小さい子持ちの30代パパ・ママエンジニアに役立つとうれしい。多分独身で若い人には役に立たない。 始める前に抱えていた問題 好きなコードを書きたい。勉強したい。そう思っても以下の理由により以前とは比べられないほどに時間がとれなくなってしまった。 子供に可能な限り時間を使いたい。結果的に自分の時間は減る コードを書く自由時間が極端に少ない 1人になれる時間がほとんど無い 家で10分以上集中できない。こどもが遊ぼう！って誘ってくるとか 子供に話かかられたり質問されたら出来る限り応えたい とにかく疲れやすい 以下のような典型的な1日。 朝は 6:30 頃に早起きの息子に起こされる。1人で起きて絵本などを読める歳だが、静かに起きることは稀だ。トイレに行きたいとか。何かが見つからない。何だかんだで同
Shibu's Diary: コードを書くときに心がけていること
渋日記@shibu.jp 渋川よしきの日記です。ソフトウェア開発とか、ライフハックを中心に記事を書いていきます。 コードを書き続けるためにやってること(by Voluntas) なんか流行っているので乗ってみます。 趣味コード 趣味とはいっても、暇つぶしだったり、流行りもののチュートリアルに触って「おれ新しい◯◯やってみたぜ」みたいなのは極力しないようにしてます。仕事で必要になった時に、仕事の時間の中で集中的に学ぶ方が学習効率が高いので、趣味時間の活用という意味ではもったいないですよね。幸い、まったく未知の基礎的な内容というのはほとんど出会わなくなってきて、新しい技術といっても、既存の知識を土台にして、軽く検索すればOKなことがほとんど。ということで、趣味といっても、将来の仕事で役に立ちそうな種となる可能性のあるものを作るように心がけています。実際に種になるかどうかは運次第なので、命中率に
programming - コードを書き続けるためにやってること - Qiita
プログラミングの生産性を上げるには - Cside::Private とても面白かったのでマネしてみた。人それぞれあると思うので自分のスタイルを。 といっても、かなり不真面目なので参考にはならないと思う。 1 . README.rst を書く まず最初に何がしたいのか、どんなことをしたいのかを書く 概要、ゴール、実装方法、使用ライブラリ、TODO などを書いていく そして README.rst に擬似コードを書き始める コンパイルが通る必要は無い コメントもガンガン書いていく とにかく issues とか使わず全て README.rst に書いていく 一通り出来てきたら Trello にタスクを移す 2 . 擬似コードでプロトを書く コードを書いてみないと分からない事が多いのでまずはコードを書く よく iPhone でコードを書いているのだが、オレオレ言語で書いている Erlang っぽい
プログラミングの生産性を上げるには - 聞かれてもいないことを喋る
Yak Shaving の誘惑に打ち克つ ソフトウェアを作っている途中で、「これを作るのを効率化するためには ○○ が必要だ」と思い、本来やっていた作業の手を止めて ○○ を作り始めてしまうことは往々にしてある。 しかしその作り上げた ○○ が最終的に本当に（長期的にみて）効率化に役立ったケースは、自分の経験からいって 10 個のうち 1 つくらいではないかと思う。 効率化のための努力をするなということではない。大事なのは、アイデアを寝かせることだ。 人はゴミみたいなアイデアでも、気付かずにこれこそが素晴らしいアイデアだと信じこんでしまう。自分の考えたアイデアには愛着が湧くものだ。 そのアイデアが本当に優れているかどうか客観的に判断するには時間が必要だ。最低でも 1 晩、できればもう 2, 3 度は同じ必要性を感じてから作るのがいい。 1 回しか必要性を感じたことのないものをその場の勢いで
Evan Priestley 氏がどうやってプログラミングを学んだかを教えてください - Knoh (ノウ) | The Knowledge Hub
本人による回答です。Evan Priestley 氏は知る人ぞ知る、Facebook を代表する (元) エンジニアの一人です。Facebook には 2007 年から 2011 年の間に在籍していました。 手短かに言えば: 何年もの歳月の賜物というか。ぼくはただひたすらプログラミングが大好きで、(フェイスブックで働いていた) 過去４年間、ほとんど他のことをしていない。その前も２.５年ほどプログラマーとして働いていたし、そのさらに前も６年くらい趣味でプログラミングをしていた。ぼくは高校も大学も中退しているので、それで空いた時間もプログラミングに費やした。つい最近フェイスブックを辞めたけど、未だに起きている時間のほとんどはプログラミングだ。 もっと詳しく言えば: 月並みだが、ぼくはちっちゃい頃からコンピューターが好きで、我が家にあったヤツで（最初はMac Plusで途中からIIsiになった）
技術の進歩は「螺旋」である。 @ t_wada さん社内講演 - >& STDOUT
先週、新卒技術研修の一環として @t_wadaさん にご講演を頂きました。 題して「この先生きのこるためには」*1。 第一線のエンジニアとして素晴らしい薫陶の数々を授けて下さいましたので、渋谷や六本木の会社さんもオファーしてみたほうがいいですよ。ホント。 エンジニアはアーティストとしての側面も持つので、ファーストクラスの方の考え方に早いうちから触れておくことは、数年先の彼らの在り方に少なからず良い影響を与えるはずだ、という考え*2に基づくおふたりめの社外講師です。おひとりめは当時非公開でしたが、時効になってましたら教えてください。 新卒研修とはいうものの、社食のカフェテリアを全開放した形で既存社員にも受講してもらいました。正直、私も含めた既存社員のほうがよっぽど直接の教育効果は高かったんじゃないかと思いましたが、それはそれとして。ご講演の中でのいくつかの気づきを共有します。 技術の進歩は「
開発トレンドは「スマホの外」へ。それでもプログラマーのやることは1つ【連載:中島聡】 - エンジニアtype | 転職type
UIEvolution Founder 中島 聡 Windows95／98、Internet Explorer 3.0／4.0のチーフアーキテクトを務めたエンジニア。NTTに就職した後、マイクロソフト日本法人（現・日本マイクロソフト）に移り、1989年、米マイクロソフトへ。2000年に退社後、UIEを設立。経営者兼開発者として『CloudReaders』や『neu.Notes+』、教育アプリ『neu.Tutor』といったiOSアプリを開発する。シアトル在住。個人ブログはコチラ 今回は、エンジニアtypeが展開している特集「New Order～融合の先を拓く者たち」に関連して、編集部から「ソフトとハード、ネットとリアルが融合する時代の歩き方」をテーマにしてほしいというリクエストがあったので、私見をまとめてみました。 この連載でも何度か取り上げたように、一昨年末くらいから、わたしはウエアラブル
HRTの原則 〜ソフトウェア開発はバーでしっとり語り合うように 〜 : 小野和俊のブログ
「HRTの原則」という言葉をご存知だろうか。 これは書籍 Team Geek ―Googleのギークたちはいかにしてチームを作るのか で紹介されている言葉であり、本書ではほぼ一冊すべてをかけてこのHRTの原則とその実践方法とを様々な角度から紹介している。 1. 謙虚(Humility) 2. 尊敬(Respect) 3. 信頼(Trust) の3つの価値が大切にされており、エンジニアとしてもチームや組織、顧客との対話においてこれらの価値を重んじていくことが成功につながる、というものである。 あらゆる人間関係の衝突は、謙虚・尊敬・信頼の欠如によるものだ Team Geek p.15 プログラマとして成功するには、最新の言語を覚えたり高速なコードを書いたりするだけではいけない。プログラマは常にチームで仕事をする。君が思っている以上に、チームは個人の生産性や幸福に直接影響するのである。 Team
Railsアプリつくった - ✘╹◡╹✘
最近APIサーバ用途でRailsアプリを1個つくったので振り返る。 概要 接続元はiOSやAndroidアプリとか、Webブラウザとか、別のWebアプリケーションとか。1ホストあたり秒間数百リクエスト、平均応答時間10msぐらい。Rails 4.1.0.rc2、Unicorn、Nginxを使ってる。正直Railsは全部入りで重いイメージがあったので何となく平均50ms以内程度であれば良いところだろうと思ってたけど、意外と速い。多分そもそもサーバの性能が良いんだと思う。実装時に気を付けたことは普段の開発と特に変わりない。いつもは大勢でワイワイ開発するものに少し手を加えるということが多いんだけど、今回は珍しく自分一人でつくったから目が行き届いてたのかもしれない。DBへの問合せの効率に気を配るとか、Rubyでの処理の無駄を省くとか、アプリケーションのプロセスに無駄なコードを読み込ませないとか、計
気づいたらプログラマになってた話
@mizchi / Quipper 自己紹介 @mizchi- 竹馬 光太郎 ソフトウェアエンジニア / Quipper まず名古屋方面へ 自分について よく燃えるブログ うるさいTwitter 経歴 2008 大学入学(文系) 2012.3~ Aiming ゲームエンジニア(フルタイム) 2013.9~ Quipper ソフトウェアエンジニアに中途転職 2014.3 学部6年生で大学卒業 来年度から業界3年目の新卒？？？？ それはさておき 大学時代にやってたこと 最低出席日数を確保し、 サークルへも入らず、 バイトもせず、 家にこもってTwitter 家にこもってゲーム 家にこもってプログラミング独学 ↑ これの話する 当時(2008年)のTwitter ほとんどエンジニア みんなリテラシー高い(非エンジニアもすごい) なんか楽しそうだしプログラミングやってみるか 大学以前のプログラミン
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
作りたいものを作るには結局大量のコードを書かないといけないことについて - Qiita
Hammock Driven Development - Rich Hickey
