実行時間の差は996倍以上。オンラインハッカソン最速コードの裏側に迫る！ - paiza times
2013年12月2日より2014年1月8日まで開催していたpaizaオンラインハッカソン（略してPOH![ポー！]）Vol.1「新人女子の書いたコードを直すだけの簡単なお仕事です！」で0.01秒を叩き出したコード(最遅コードとの差は最大996倍！ 詳しくは結果発表をご確認ください)はどんな過程で生み出されたのでしょうか？ 今回は前回の最速コード発表レポート（【結果発表】新人女子PGを最も助けたプログラミング言語とは？）に引き続き、最速コードの裏側に迫ります。 ※ちなみにこちらの野田ちゃん画像は、2014年1月17日に開催されたエンジニアサポートcross2014というイベントで等身大パネルとしてpaizaブースを盛り上げてくれました！ ■高速化のアプローチ 前回のレポートでもふれましたが、POH Vol.1はアルゴリズムに変更による計算量(オーダー)の改善による大幅な高速化と、定数倍高速化
なぜクライアントJavaScriptの単体テストを書くのが難しいか、考えてみた - mizchi's blog
ってsinonのスタブ漏れを探しながら何度目かわからない感じにキレてた。 とにかく仕事でJSのテスト書くのが辛いので考えてみる。比較的JSのテストに慣れてる自分ですら辛いのだから、世界はもっと辛いに間違いない。サーバーサイドのnode.jsの話ではない。 JavaScriptで完結しない 構造がHTMLの構造と密結合している。装飾や位置、表示/非表示はCSSによって制御されている。 クライアントJSはHTMLと密結合しており、CSSからビューは影響を受ける。それらがネットワークの結果を受け非同期に振る舞いを帰る。その最終的な値を取得するのが難しい。 もちろんサーバーサイドだってDBやネットワークという外部リソースを扱うが、モックの手法が確立しているし、局所的な複雑度は、JSの方がはるかに多い。 言語仕様が貧弱 mochaやjsmineはrspecを真似てるけど、本質的にJavaScript
Interactive tutorials - A tour of C#
Welcome to the introduction to C# tutorials. These lessons start with interactive code that you can run in your browser. You can learn the basics of C# from the C# for Beginners video series before starting these interactive lessons. The first lessons explain C# concepts using small snippets of code. You'll learn the basics of C# syntax and how to work with data types like strings, numbers, and bo
put.io
What we areWe fetch files from many public places at very high speeds, then put them into your digital stash. We are more like the remote version of the "/downloads" directory on your computer. We do the downloading for you and then we serve up the goods to your devices. What we are notWe are not a backup or syncing service like Dropbox or Google Drive where you upload your own stuff for safekeepi
テストファーストなGitワークフローについて - kazuhoのメモ置き場
Gitのワークフローに関する話題が、また盛り上がっているようなので、僕が好んで使っているワークフローについて書きます。 対象としているソフトウェアは、GitHubやGitHub Enterprise等を使って開発されている、リリースブランチを切らずにmasterにリリースタグを打っていくだけで十分な程度の、ウェブサービス（の部品）やオープンソースプロジェクトです。 まず、以下の２点を原則として考えています。 origin masterを壊さない origin masterの（1st parentをたどるツリー）にテストを通らないcommitを入れないよう努めます 変更の主題を常に明確にする 前者の理由は、masterをいつでもリリース可能な品質に保つためと(←12:44追記)git bisectするときに困らないようにするため。そして、これらの原則から、以下のようなワークフローで作業するこ
npm (node package manager)の菱形依存問題とdedupeと社内モジュールとJSX - kazuhoのメモ置き場
npmで色々コードを書いていると、以下のような依存関係ができてしまうことがある*1。 a +-- b <-- depends on c@1.0.x | `-- c@1.0.3 `-- d <-- depends on c@~1.0.9 `-- c@1.0.10このように「bが依存するc」と「dが依存するc」が異なるものになってしまうと、（２回cがロードされる分）プログラムが無駄に大きなものになってしまったり、（bとdがお互いで生成したcを使う場合に）片方で生成されたcのインスタンスをもう片方で「instanceof c」してもfalseが返ってきてしまう、などの問題が発生する。 この問題を解決するために、npmはsemantic versioningという枠組みとnpm dedupeというコマンドを提供していて、両者を使うことで、依存構造を以下のような形に変換して問題を回避することができる
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
