なぜエラーを収集するのか バグ探し バグを見つけて潰していくため ユーザからのバグ報告の補助 ユーザに報告の負担をかけないため エラーを取得する 取得タイミング window.onerror Promise のエラー フレームワーク毎の特定のタイミング window.onerror window.onerror にメソッドを登録しておくことでエラー発生時にそのメソッドが呼ばれる。try-catch でハンドリングしていないエラーが流れてくる。

最初に学んだプログラミング言語を覚えています。2年生のとき必須であった情報クラスの授業でBASIC言語を学習していました。暗い蛍光灯の下、前かがみに机の前に座りながら、空気のこもった教室の壁際に並べられ、音を立てているIBMパソコンを我慢できずに見ていました。時は1997年のロシアです。誰の家にもコンピュータはありませんでした。先生がチョークで汚れた黒板に下記のように書きました。 他のクラスメートのきょとんとした視線同様にそこに書かれた訳の分からない「暗号文」に8歳の自分も視線を注いでいました。先生は『恐れる必要はありません』と。安心させようとやわらかい口調で言いました。この日までの数週間、彼女に授業でフローチャートを書かされていました。この時点で、既にポテトの皮むきやレゴの組み立ての「アルゴリズム」を詳細に設計することができていました。それでも黒板から睨み付けるラテン文字は異質でした。

fossBytesに3月28日(米国時間)に掲載された記事「Which Are The Most Loved and Most Hated Programming Languages｜2017」が、Stack Overflow Developer Survey 2017の調査結果を引き合いに出し、開発者に愛されているプログラミング言語と嫌われているプログラミング言語のトップ25を伝えた。愛されているプログラミング言語1位はRustで、これにSmalltalkとTypescript、Swift、Goが続いている。 嫌われているプログラミング言語トップ25は次のとおり。 Visual Basic 6 VBA CoffeeScript VB.NET Matlab Objective-C Assembly Perl Lua Hack Groovy Common Lisp Dart Erland P

このポストは、Why I Left Gulp and Grunt for npm Scriptsを筆者の許諾を得て意訳したものです。間違いがありましたら、ご指摘いただけると幸いです。 （以下、訳） 私はGulpとGruntが不要な抽象化レイヤーだと気づきました。npmのscriptsはとても強力で、そっちの方が便利だったりします。 例を挙げましょう 私はかつてはGulpが大好きでした。しかし結局のところ、100行ものgulpfileと大量のgulpプラグインを扱うハメになりました。Gulp上でWebpackやBrowsersync、Mochaなどを統合するのは本当にたいへんでした。なぜでしょうか？それは、プラグインによってはドキュメントが不十分だったり、APIの一部しか公開されていなかったためです。 これらを解決しようと思えばできました。しかしなんと それらのツールを直接使用すると不具合が

英語サイトでは、日本語のサイトでは絶対に手に入らないレベルの記事がわんさか読めます。今日はCodeProjectよりシステム構築をする上で知っておくべき深い知識を解説した記事を3行要約と共にご紹介します。 C#と.NETの記事 C#や.NETのかなりディープな記事たちです。日本語ではあまり見かけない深い部分まで知れます。 ■高パフォーマンスなクラスのデザイン方法 Performance Considerations of Class Design and General Coding in .NET - CodeProject ・クラスvs値型のメモリ使用の詳細 ・値型のGetHashCodeとEqualメソッドをオーバーライドする ・シールドクラスによりVirtualメソッドを避ける ・インターフェースのDispatchについて ・ボクシングを避ける ・for vs foreachはfo

営業やマネージャーにとって、現場にいるプログラマというのは扱いづらい存在である。 飲み会などで、普段の彼らを観察してみると。同じエンジニア同士で固まってボソボソとよくわからない話をして、控えめな声で笑っており、総じて温厚で、扱いやすそうな人々に見える。 ところが、仕事になると、彼らはなんやかんのと理由をつけて、スケジュールに文句を言い、プロジェクト途中のリクエストには素直に答えてくれず、あげくには遠回しな嫌味を言ってきたり、極端な場合には、その温厚な仮面を投げ捨てて、攻撃的な暴言さえ吐く事がある。 どうも彼らは我々の事が嫌いらしい、と感じている営業・マネジメント職の人もいるのではないだろうか？ 彼らの人格や価値観に問題がある可能性も否定しないが、このような感情的な齟齬は、多くの場合、あなた自身が彼らの「自尊心」を傷つけていることに気づいていないことが多い。 プログラマの自尊心 プログラミン

マプログという地図にメモが書けるというコンセプトで個人で作ったiOSアプリです。 マプログ Mocology仕事効率化¥250 売上の数字自体は2011/1/7にリリースしてからこれまでの合計で約85万円(ここから30%をAppleに引かれる)となります。 リリースから2年後には本業が忙しいのとDL数の伸び悩みからアップデートをやめてしまいました。ですので直近１年間だとほとんど売上もないまま放置状態です。 開発時期は2010年の秋くらいからおそらく1.5ヶ月くらいの工数かけて本業の傍ら夜な夜な黙々と開発してました。 このアプリ、2011年頃と今を比べると全然アプリ数が少ない時代だったこともあって、AppBankをはじめとする有名なアプリレビューサイトなどにもいくつか掲載していただいたり、 www.appbank.net Mac Fanという雑誌で紹介してもらったりしました。 www.fuj

人間の論理は、私たちがプログラミングして毎日使っているマシンの論理とは違って完璧ではありません。人間は間違えますし、悪い精神的習慣を確立してしまいますし、エンジニアとして成功するための能力に悪影響を及ぼす認知バイアスをたくさん持っています。ソフトウェアエンジニアとして定期的に目にする一般的なバイアスのうち5つを見ていきたいと思います。 1. 根本的な帰属の誤り 根本的な帰属の誤りは、個人の行動を説明するにあたって、気質的または個性的な面を重視しすぎて、状況的な面を軽視しすぎる傾向を言う。対応バイアスとも。 （参照） これは私のお気に入りの認知バイアスです。”至る所で”見られるからです。道で誰かに行く手を遮られると、その人を完全に嫌なヤツだと思ってしまいますが、自分が同じことをしてしまう時は、相手が見えていなかったとか、会議があって遅刻できなくて急いでいたといった理由があります。誰かがバグを

The latest news from Google on open source releases, major projects, events, and student outreach programs. Google runs millions of lines of Python code. The front-end server that drives youtube.com and YouTube’s APIs is primarily written in Python, and it serves millions of requests per second! YouTube’s front-end runs on CPython 2.7, so we’ve put a ton of work into improving the runtime and adap

これはなに？ はじめに AGCあれこれ Temporary I HOPEHOPEHOPE ASTRONAUT NOW LOOK WHERE YOU ENDED UP ふと気になりました いい時代ですね 1201&1202エラー なにそれ？ カ、カルマンフィルターだー！！！ カルマンフィルターの開発経緯 その他面白コメントアウト集 TRASHY LITTLE SUBROUTINES（つまんないサブルーチン） NUMERO MYSTERIOSO（神秘の数字） OFF TO SEE THE WIZARD COME AGAIN SOON HONI SOIT QUI MAL Y PENSE（悪意を抱く者に災いあれ）、NOLI ME TANGERE（私に触れるな） PINBALL_GAME_BUTTONS_AND_LIGHTS.agc おわりに 反省 参考文献 これはなに？ この記事はeeic Adv

WWDC（Appleの年次開発者会議）2016でティム・クックCEOが最後にとっておいたものが「Swift Playgrounds」。iPadがあればSwiftによるプログラミングを学ぶことができる無償のアプリだ。今秋にApp Storeで公開される。「iPadを使うことで、世界中の、数億の人たちがプログラミングを学べる」とクックCEOが話すと喝采を浴びた。 子どもたちがAppleの開発したプログラミング言語Swiftを使ってアプリの作り方を学ぶことができるソフトだが、iPadの中だけで完結できるというのが特徴。開発言語の基本を学べるだけでなく、コードをiPadの実機でフルスクリーン動作させ、検証することができる。iOS開発がmacOSのXcodeで行わなければならないのは変わらないが、基本的な学習はiPadでできるというわけだ。そして、エミュレーターではなく、実機の加速度センサーなどを使

A few hours after this morning’s big unveil, Humane opened its doors to a handful of press. Located in a nondescript building in San Francisco’s SoMa neighborhood, the office is home to the startu

米マサチューセッツ工科大学（MIT）は、DNAに作用し、大腸菌に新たな機能を追加する“細胞用プログラミング言語”を開発した。コンピュータでプログラミングをするのと同じ感覚で、テキストベースで設計するのが特徴だ。 グルコース濃度や酸素レベルに応じ、意図した反応を返すようにプログラムできる。デジタル回路を設計する言語「Verilog」をベースとし、DNAの各部位や役割、他の部分との連携など、遺伝子工学の知識がなくても設計可能だ。「高校生でも、望み通りのプログラムを組める」とうたう。 研究チームによる初回テストでは、60種類の回路をプログラムし、うち45個が正常に機能したという。ほとんどの回路は1種類の機能しか持たないが、異なる3種類の機能を持ち、優先度に応じて反応を返す回路も設計した。 従来、DNA回路の開発には数年を要したが、同言語を使えばボタンを押すだけで、すぐにテストでき、研究時間の短縮

めちゃくちゃにハマったからと言って、その問題は技術的難易度が高い訳ではないんじゃね？という話。 ここで言う「ハマる」とはなにかに夢中になって没頭することではない。バグとかエラーがあって、なかなか解決できなくてそのために時間を割かれてハマる、の「ハマる」。 先日、ハマった問題が解決した時の感情は「ついに解決したぞ」という安堵感と「しょーもないハマりポイント作りやがって、あのボケが！」という前任者への怒りが混ざった状態だった。 サイトのSSLの有効期限切れが２週間後にせまっていた。やる事は証明書の更新、新しい証明書をAWSのELBに入れること。ただこれだけ。しかしハマった。どうやってもELBから「あなたのキーは無効です」みたいなエラーメッセージが返ってきた。２年前にSSLを設定したエンジニアは退職してしまって、もう居ない。その前任者とほぼ同じことをすればOkなはずなのに、なぜかできなかった。

プログラムを独学で勉強している初心者です（２ヶ月くらい） ちょっとした疑問があり、質問させていただきます。 プログラムのサイトなどには、変数などの名称には英語を使うべきと書かれています。 これはなぜなのでしょうか？ はっきり言って、この風習があるために勉強で困っています。 勉強のためにサンプルコードなどを見ていても、英単語が並んでいると、 どれがプログラム特有の命令で、どれがプログラム記述者が自由につけた変数名なのかが わかりにくいのです。 変数は変数であることがはっきりわかったほうが便利だと思うのです。 プログラムに慣れている人にはそんな必要ないのでしょうが… 自分でコードを書く時には、あとから自分でわからなくならないように 変数名には必ず「h_」をつけるようにしています。 h_speed とか h_count とか。 英語にするべき理由と、初心者のうちだけでも変数がわかりやすくするよう

使用済みプログラムは、一旦ゴミ箱に捨てましょう。 物を捨てることには悪いイメージがつきまといます。再利用に異を唱えるのは勇気が必要です。しかし、再利用して良いのは、再利用による長所と短所を比べて、長所の方が大きいと判断した時だけです。段ボールを再利用することは、再利用しないことよりも本当に得なのか。それが問題です。 再利用にはコストがかかります。段ボールなら、運び、刻み、洗い、溶かさなくてはなりません。プログラムの再利用にもコストがかかります。とりわけ、違う人が使う場合はコストが膨らみます。 再利用しやすいように書くことはすでにコストです。後で使うならと汎用化しようとして、無駄に複雑化することは良くあります。サンプルコードとして使う程度の再利用ならまだしも、そのまま組み込むとなれば動く状態を維持せねばなりません。使う方にしても、使い方を覚えるコストがかかります。時間が経っていたり、作った人

僕は、プログラムをする上で変数や関数に良い名前を付けるのはとても重要と考えています。 というのも、良い名前を付ければ、それだけでそのコードがしたいことの説明になり、コメントと同等の働きをすることもあるからです。 自分がちゃんとそれをできているのかはさておき、僕は普段から、できれば読みやすくて分かりやすい名前を付けたいと思っています。他の人も読むコードであれば、できればプログラムでよく使われるような単語を利用して書いた方がより分かりやすいです。 ただ、よい名前を考えるのって、ちょっと面倒くさいんですよね。僕はこれまで、英語の辞書を利用して、考えたりしていたのですが、「何か、プログラムでよく使われる単語をまとめたものはないか？」と探したら、ドンピシャのものがいくつかあったので、それらをまとめて以下で紹介します。 photo by Michael Coté codic codic – デベロッパ