タグ

ブックマーク / postd.cc (7)

  • 「フロントエンド開発者」の終焉 | POSTD

    元記事の著者より:この記事は主に北米文化で私が見たことを反映しています。 誰かに職業をきかれたら、私は「フロントエンド開発者です」と答えます(答えは相手によって変わることもあります)。10年か20年前は、自分の仕事に必然的に伴うものが何なのかは、かなり明瞭でした。インタラクション用にHTMLCSSを書き、JavaScriptも多少は書いていました。駆け出しの頃、PHPMySQLの作業に職務の大半を費やしていたとはいえ、フロントエンド開発者として見られる方が好きです(これに関しては、後に詳しく説明します)。この状況は、2010年の初頭に変わり始めました。JavaScriptが、重要で、非常に大きな存在になってきたのです。昨年の初め頃から、たくさんのフロントエンド開発者に会うようになり、あることに気付きました。フロントエンド開発者は、もはや、私が以前から知っているフロントエンド開発者ではな

    「フロントエンド開発者」の終焉 | POSTD
  • 私が書いた最速のハッシュテーブル – PART 1 | POSTD

    結局、やり出したら止まりません。私は以前、” I Wrote a Fast Hashtable(私が書いた高速なハッシュテーブル) “という記事と、それに次いで” I Wrote a Faster Hashtable(私が書いたより高速なハッシュテーブル) “という記事をブログにアップしましたが、今回ついに、最速のハッシュテーブルを書き上げました。これが意味するところは、ルックアップがどのハッシュテーブルよりも速いということです。それに加えて、挿入や削除も(最速とまではいかないまでも)非常に速く行えます。 秘訣は、探索回数の上限を設定したロビンフッドハッシュ法を使用することです。ある要素が、その理想的な位置からX数以上、離れた位置にある場合、テーブルを拡張することで、全ての要素が、その大きなテーブル内において、理想的な位置に近づくようにします。結果的に、このやり方は非常にうまくいきました。

    私が書いた最速のハッシュテーブル – PART 1 | POSTD
  • 高速なハッシュテーブルを設計する | POSTD

    (訳注:2016/9/28、頂きましたフィードバックを元に記事を修正いたしました。) はじめに 稿では、高速で汎用的なハッシュテーブルを作るために行う、設計についての多くの意思決定事項を紹介します。最終的に、私の emilib::HashSet とC++11の std::unordered_set の間のベンチマークが出来上がりました。もし、ハッシュテーブルに興味があって、自分で設計したいなら(どのプログラミング言語かに関わらず)、稿がヒントになるかもしれません。 ハッシュテーブル は、素晴らしい発明です。 ならし計算量O(1) ( O(√N)時間 )で、挿入、削除、検索を行うことができます。ならし計算量とは、ハッシュテーブルの計算に平均でO(1)の計算量がかかることを意味しますが、時々、これよりも多くの時間がかかる場合があります。具体的には、ハッシュテーブルに空きがない場合で、挿入の

    高速なハッシュテーブルを設計する | POSTD
  • WebkitがES6の機能を完備 : RegExpを例に、パフォーマンスのための取り組みを詳解する | POSTD

    r202125 の時点で、JavaScriptCoreが ECMAScript6(ES6)言語仕様 にある新機能の全てをサポートしました。ES6のあらゆる新しい機能が最新の WebKit Nightly と Safari Technology Preview で入手できます。モジュールの実装はありますが、Web用のAPIはまだできあがっていません。ES6で、JavaScript言語には非常に多くの優れた機能が追加され、JavaScriptCoreの開発に関わる人たちはJavaScriptの未来に興奮しています。新しいES6の機能を単に実装するだけでなく、ずば抜けたパフォーマンスを確実に実現しようと一生懸命です。しかしながら、今回は違う観点から論じます。とはいえ、ES6の機能の開発においては上記と同様に重要な点について、つまり、現在あるES5のWebサイト・アプリケーションと同じパフォーマン

    WebkitがES6の機能を完備 : RegExpを例に、パフォーマンスのための取り組みを詳解する | POSTD
  • 私がどのようにしてキーロガーをクラックし、最終的に第三者の受信トレイに行きついたか | POSTD

    (訳注:2016/9/28、頂きましたフィードバックを元に記事を修正いたしました。) ことの始まりは、あるスパムキャンペーンでした。画像1は、スパム向けに仕掛けた罠に最近引っかかった、疑わしいドキュメントファイルが添付されたメールです。文面の英語がとても稚拙なことに気付くかと思いますが、この稚拙さがメール受信者への警告サインとなります。 画像1:スパムサンプル 添付のファイルは、”.doc”のファイル拡張子を使っていますが、実際はRTF(リッチテキストファイル)ファイル形式で、特別に細工されたRTFファイルによるスタックオーバーフローの脆弱性が含まれています。この脆弱性は、CVE-2010-3333で文書化されており、”pFragments”の形をしたプロパティを扱う際にMicrosoft Word RFTパーサを攻撃するものです。これに対する修正モジュールは5年以上前にパッチされています

    私がどのようにしてキーロガーをクラックし、最終的に第三者の受信トレイに行きついたか | POSTD
  • ReactでTDD(テスト駆動開発)を始めよう : 環境構築からテスト作成、機能実装までの詳解ガイド | POSTD

    最小限の設定のTDD手法を使い、「何をテストすべきか?」から、よくある落とし穴の避け方まで、Reactコンポーネントをテストする方法を学びましょう。 導入 まず、 React を触ったことがあり、更にはいくつかのテストも書いた経験があるとしましょう。それでも、コンポーネントをどうテストするのが最善なのか、よく分からないかもしれません。どこから始めるのでしょう。具体的には何をテストすればよいのでしょうか。 いくつかのReactコンポーネントは簡潔過ぎて、そもそもテストが必要なのかすらはっきりしません。 AngularからReactに乗り換えた 人なら、テストには愛憎のような思いがあるかもしれません。 確かに Angular にはテストを支援するツールがたくさんありますが、同時にテストを書くのが難しくなる可能性があります。冗長ながら省略できない定型コードが多々ある上、 $digest の呼び出

    ReactでTDD(テスト駆動開発)を始めよう : 環境構築からテスト作成、機能実装までの詳解ガイド | POSTD
  • Web Componentsの現状 | POSTD

    Alex Russell が Fronteers Conference 2011 で初めて発表したWeb Componentsは、長きにわたり開発者の注目を集めてきました。その概念はコミュニティに衝撃を与え、発表以来、講演や議論のテーマとして多く取り上げられています。 2013年 Google は、Web Componentsをベースとするフレームワーク、 Polymer をリリースしました。その目的は、新規APIの動作を簡易的にチェックし、コミュニティからフィードバックをもらい、さらなる資金や評価を得ることでした。 導入から4年が経った今、Web Componentsは十分に普及している はず です。ところが実際は、”あるバージョン”のWeb Componentsに対応したブラウザは Chrome しかないという現状です。Polyfillがあっても、大半のブラウザでサポートしない限り、W

    Web Componentsの現状 | POSTD
  • 1