アンゴラで生まれた彼はフランス、ブラジルを経て、カナダのオンタリオ州オタワに移り住んだ。高校ではバスケットボールをしており、アメリカンフットボールを始めたのは最終学年になってからであった。東アリゾナ・ジュニアカレッジへ入学、NFLで10シーズンプレーしたことのあるビル・カリーが彼のゲームテープを見たことから、カリーがヘッドコーチを務めるジョージア州立大学に転校、2シーズンディフェンシブタックル、ディフェンシブエンドで先発した。2010年には51タックル（7ロスタックル）、5サック、2ファンブルフォース、2011年には38タックル（9ロスタックル）、5サック、1ファンブルリカバー、1ファンブルフォースをあげた。2012年、アトランタで行われたリージョナル・コンバインに参加した。同年のCFLドラフト3巡でウィニペグ・ブルーボンバーズに、2012年のNFLドラフト6巡でオークランド・レイダーズに指名された。ジョージア州立大学の選手がNFLドラフトで指名されたのは彼が初めてであった。2013年、第2週のジャクソンビル・ジャガーズ戦でNFL初サックをあげた。10月23日、レイダーズがマーテズ・ウィルソンを獲得した際に解雇された。レイダーズでは控え選手として、18試合に出場し、13タックル、1サックをあげた。同年11月1日、ジーノ・アトキンスが故障者リスト入りしたシンシナティ・ベンガルズと契約したが、カナダ国籍の彼に就労ビザが下りなかったため、契約はNFLより無効となり、ベンガルズは彼の代わりにキーストン・ランドールと契約していた。11月21日にベンガルズと改めて契約を結び、ランドールの代わりにロースターに加わった。
1947年のGATTは、第22条及び第23条において紛争解決について規定していた。しかしこれらの規定は基本的な枠組みは規定していたが手続きの詳細については規定しておらず、事案ごとに締約国団が決定していた。初期においては作業部会により行われたこともあったが、後に小委員会（パネル）に付託して検討を行うのが一般化し、DSUにおいても踏襲されている。DSUは、東京ラウンドで合意され1979年11月28日に採択された「通報、協議、紛争解決及び監視に関する了解事項（Understanding regarding notification consultation, dispute settlement and surveillance）を受け継ぐとともに問題点とされていた部分について改善がされている。この主要な改善点は次のようである。１従来、パネルの設置、パネルの報告の採択等の決定においてコンセンサス方式（全員の意見の一致による方式）が取られていたため、一方の当事国のみが反対しても決定が行えず、手続きが進行しなかったものを改めて①パネルの設置②パネル報告及び上級委員会の報告の採択③対抗措置の承認にあたっては全員一致の反対がない限り提案されているものが採択されるというネガティブ・コンセンサス方式によることになった。２　各手続きに期限がないために遅延が発生していたため、紛争解決手続の各段階にタイム・リミットを設けた。３　1947年のガットの時代、ガット（一般協定）のほか各種東京ラウンド協定が存在し、それぞれにルールの判断基準、処理機関が存在しいわゆるフォーラム･ショッピングの問題が生じていたものを手続の共通化、統一化を行った。４　ウルグアイ・ラウンドの交渉において米国を除く各国は、米国の1974年通商法第301条による一方的対抗措置を封じ込めたいとの狙いがあり、交渉の結果①WTO協定の利益の無効化、侵害についての救済はDSUによること②DSUによらない義務違反の認定の禁止③義務違反の認定をされた国が違反を解消しない場合の対抗措置は紛争解決機関の承認を要する、となった。
Eclipseは他のJavaで記述されたIDE（JBuilderやSun ONE Studioなど）と比べて動作があきらかに軽快である。この軽快さはGUIツールキットにJava標準のSwingやAWT (Abstract Window Toolkit) を使用せず、Eclipse独自のGUIツールキットであるSWT (Standard Widget Toolkit) を採用していることで得られている。SWTの位置づけはSwingではなくAWTに対応するが、AWTとSWTの違いは、AWTがオペレーティングシステム (OS) あるいはウィンドウシステムレベルの描画操作をネイティブメソッド群というレイヤ（つまりCあるいはC++で書かれたJNIメソッドのDLL・共有ライブラリエントリ）で抽象化し、それをさらにJavaのAPIで覆い、インタフェースが二重に重ねられているのに比べ、SWTではネイティブのウィンドウシステムのAPIとJNIメソッドがほぼ一対一に対応するように定義されており、JNIの層が量的・質的に非常に薄い、ということである。言い換えると、ネイティブのウィンドウシステムのAPIレイヤと、JavaのGUIツールキットクラスライブラリとしてのレイヤの間のセマンティックギャップを埋めるのに、AWTではCコードとJavaコードの両方を使用するのに対して、SWTではCの部分が僅少でありJavaコードが実質的に主体である。AWTにおいて、下位層のウィンドウシステムのAPIをOSを越えて共通のものにみせかけるための、DLLのエントリとして定義されるインターフェース層は、積極的な存在意義が無く、見通しを悪くしており、2回のセマンティクス変換が効率を悪くする可能性があり、柔軟性にかけ、拡張性に劣る。またJNIを使ったCコードというのは単なるCコードよりもはるかに可読性が悪く、デバッグも難しく、開発効率は極めて低い。SWTではこのセマンティックギャップ吸収、つまりネイティブレベルの機能とJava APIの間の機能マッピングロジックが見通しよくJavaのみで記述されている。またSWTでは問題の切り分けも容易である（AWTではソースの無いDLL中のエラーは基本的にデバッグ不能。SWTでは生じた問題をネイティブAPIを呼び出す等価なCコードに書き換えることができ、問題の切り分けが容易）。AWTとSWTのどちらが速いのかは実は良くわからないが、見た目や機能上の制約から現時点でAWTでアプリケーションを書くことはほぼありえない。したがって実用的な意味でSWTと速度比較すべきなのはSwingであり、その比較においては明らかにSWTの方が軽快であるし、アプリケーションがそれを実証している。※注 J2SE1.4登場前の話。ハードウェアアクセラレーションが施されるようになった1.4.1以降はVMの高速化とJNIが相対的にネックになってきたSWTより快適な場合もわりと多くなってきた。SWTはEclipseとは独立して、単独でJavaアプリケーションから利用することもできる。