メカニカルなギミックが魅力的なスタンド『iZel』 | 100SHIKI
iPhoneやらアンドロイドやらさまざまなモバイル機器に対応したスタンドがiZelだ。 角度や幅などを自在に変えられるので、横向きだろうが縦向きだろうが、筐体の大きさがどうであろうが、大抵のものに対応している点が魅力だ。 また使わない時にはフラットな状態に変形できるので、持ち運ぶのにも楽だ。 実際にどういった具合に変形可能かはサイト上でぜひ見て欲しい。なかなか素敵なアニメーションで紹介してくれている。 モバイル機器を複数持っている人も多いだろう。こうした汎用的なスタンドはこれから需要が増すかもですな。
WebベースのIDEは主流になるか？
先日（2009年2月12日）Mozillaがコード編集用のWebベースフレームワークであるBespin(リンク)をリリースした。そしてその数日後にはBoris Bokowski氏とSimon Kaegi氏がヘッドレスな（GUIをもたない）Eclipseプラグインを使ったBespinサーバ(リンク) を実装した。EclipseConでのWebベースのEclipseワークベンチのプレゼンテーションや、WebベースのIDEでありRuby on Railsアプリのホスティング環境でもあるHeroku(リンク)のような製品のリリースがあったことからすると、WebベースのIDEはすぐにでも主流になりそうだ。 MozillaがBespin (リンク)で目指すのは、ディベロッパの生産性を向上させ、人を引きつけてやまないユーザエクスペリエンスを可能にし、オープンスタンダードの利用を促進するために、コード編集
Solving Common Layout Problems (The Java™ Tutorials > Creating a GUI With Swing > Laying Out Components Within a Container)
Trail: Creating a GUI With Swing Lesson: Laying Out Components Within a Container The Java Tutorials have been written for JDK 8. Examples and practices described in this page don't take advantage of improvements introduced in later releases and might use technology no longer available. See Dev.java for updated tutorials taking advantage of the latest releases. See Java Language Changes for a summ
)
MSDN ホームページ
2015 年 7 月 29 日より提供を開始した Windows 10 においても、Silverlight のブラウザー外実行をお使いいただけるほか、Windows 10 に搭載されている Internet Explorer 11 でのサポートは継続されます。 しかしながら、Microsoft Silverlight 5 は 2021 年 10 月 12 日にメインストリーム サポートが終了いたします。ただし、動作するブラウザーのサポート ライフサイクルが終了している場合がございますのでご注意ください。Silverlight のシステム要件は こちらからご確認いただけます。Silverlight のサポート ライフサイクルについての詳細は マイクロソフト サポート ライフサイクルでご確認いただけます。 関連リンク Silverlight の機能 | バージョン別機能比較表 | 開発者向け情
LRUCache、一定時間経つと消えるところまで。 - @katzchang.contexts
仕様変更その2まで対応。 Clockオブジェクトを導入 記事にしやすいよう、モッククラスをテストないに記述してるけど、分けた方がいい。 でも、Clock.SYSTEM_CLOCKは、interface Clock内に定義すべき。通常使うだろう、デフォルトオブジェクトがわかりやすいはず。 容量変更のメソッド（fixCache()）と時間でクリアのメソッド(deleteDeadCache())を分けた。 理由は、put/getメソッド内でのcache.putとcache.getとの前後関係を同じようにするため。 この一歩手前までは、fixCache()内に2行記述していた。そうすると、get時はget前に、put時はput後にfixCache()を呼ぶ必要があった。 これで、重複が出来た。が、どうやって取り除こうか。 生存時間と容量も、KeyHolderに移動。 これで、外側のオブジェクトはほ
LRUCache、仕様変更その１（事後の容量変更）まで - @katzchang.contexts
TDD Boot Campの課題の再挑戦です。 仕様変更その１（事後の容量変更）まで対応。ここまでは大して複雑にはならないのは、前回の通り。スナップショットとして。 ポイントは、キー管理を内部クラス"KeyHolder"に委譲していることか。put時の容量超過と、capacityを減らしたときのキャッシュ整理が一元化できている。ただ、「xxxer」的なクラスは、あまりいい匂いはしない。 テストコードは、アサーションを何個も重ねないよう気をつけてみた。1メソッド1アサートを厳守するのは難しいかもしれないけど、基本的には採用すべきな気はする。あとは、ヘルパメソッド"fillTarget"の記述を簡略化した。「テスト対象は主にキーであり、値はそれほど重要ではない」。 途中までは、前回と同様に、キー順序をテストするメソッドを入れていた。が、最終的に、KeyHolder#oldest()はテストコー
TDD Boot Campのコード - @katzchang.contexts
というわけで、晒します。 前半は@katzchang・@kozy4324のペア。後半は@katzchang・@yugoriのペア。 Eclipseは独自に履歴を持っているので、2パターンを引っ張り出してきました。クラス宣言部にカーソルを当てて右クリックからLocal History。たぶん20セーブくらいしか保持してないけど、たまに助かることもあります。 仕様変更直後くらい ということで、仕様変更直後くらいのセーブから。大体の時間で取っているので、REDな組み合わせかも知れません。 基本的には、テストコードは下に順に追加していっています。上にある項目から順に、プロダクトコードを作り込んでいったってことです。 第一の仕様変更（キャッシュサイズを変更できるようにする）まで対応済、第二の仕様変更（一定時間が経過したデータはキャッシュから消える）に対応しようとしたら、既存機能にバグの疑いがあり、バ
SI業界人は要チェック！！Subversionでのベンダブランチの運用手順。
外部から納品物に自分たちが手を入れるような場合や、他の人が作ったパッケージ製品を改造して提供するような仕事を管理する場合に使えるパターンです。つまり、SI業界には必須ともいえるパターンなはず。 レポジトリにvendorディレクトリを切っておき、その下でベンダから受領したブツを管理する。納品毎にバージョンtagをつける。そこから枝分かれさせたものを、自分のプロジェクトのサブディレクトリとして管理していく。こうやって管理することで、ベンダからの受領物を自分のプロジェクトにマージするときに、SVN力をいかんなく発揮させることができます。 参考：http://hide.xsv.info/tips/svnmanual/merge3/ 今更な人には今更だろうけど、今更じゃない人には今更じゃないよっていうのがこのセカイですので、もう気にしてません。サンタさん、僕はオトナになったよ…。 レポジトリの構成（
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
