タグ

2012年11月14日のブックマーク (5件)

  • Vim完全バイブル 第5章 複数ウィンドウの扱い - ぬいぐるみライフ?

    Vim完全バイブル」のメモの続きです。 今回はウィンドウを分割して複数ファイルを同時に表示したり、バッファを切り替えたりするためのコマンドをまとめます。 「第5章 複数ウィンドウの扱い」の内容は以下の通りです。 ウィンドウの分割 分割ウィンドウのサイズの変更 バッファ バッファ一覧の表示 編集バッファの切り替え ウィンドウの分割 以下のコマンドを使うと、Vimのウィンドウを分割して複数のファイルを同時に表示することができる。 ウィンドウ分割関連のコマンド :new [{file}]ウィンドウを横方向(上下)に分割し、新しくできたウィンドウで新ファイルの編集を開始する(new) :vne [{file}]ウィンドウを縦方向(左右)に分割し、新しくできたウィンドウで新ファイルの編集を開始する(vnew) :sp [+{command}] [{file}]ウィンドウを横方向(上下)に分割し、新

    Vim完全バイブル 第5章 複数ウィンドウの扱い - ぬいぐるみライフ?
    yossie09
    yossie09 2012/11/14
  • ソフトウェア開発者が読むべき IT系雑誌の一覧と,おすすめの読み方 - 主に言語とシステム開発に関して

    中級クラス〜のデベロッパにとって,フォローする事が望ましいIT系雑誌のリスト。 また,それらの読み方。 つまり,書店における立ち読みのポイントと,購入の判断基準。 (1)Web+DB PRESS (2)Software Design (3)日経Linux (4)日経NETWORK (5)日経SYSTEMS (6)日経ソフトウェア 補足 なぜ雑誌なのか? 読者層としては, 主にWebアプリの開発をチーム内でリードするエンジニアやアーキテクトを想定。 (1)Web+DB PRESS 雑誌のホームページ http://gihyo.jp/magazine/wdpress この雑誌の読み方: 「特集」は無条件で精読する。 「プログラミング言語の記事」は,下記の点に注目して把握する。 言語の癖や特色,他の言語と差異化するファクター その言語から,あるサービスを利用するためのAPIの存在 バージョンアッ

    ソフトウェア開発者が読むべき IT系雑誌の一覧と,おすすめの読み方 - 主に言語とシステム開発に関して
  • 開発者のスキルチェック集 - 主に言語とシステム開発に関して

    エンジニアのスキルレベルをチェック&フォローするための,チェックリスト集。 学ぶべき項目を整理してあるので,判定だけでなく学習のためにも使える。 チェックリストには,2種類ある。 レベル判定用のチェックシート・質問集。(※面接や,タスクの振り分け時に利用) 各種IT技術について,初級・中級で押さえるべきポイントを網羅した,学習項目やノウハウのリスト。(※教育や研修のために利用) いずれも,開発チームの技術力の底上げのために活用できる。 このようなチェックリストを活用する事によって,以下の事柄が達成される。 低スキル者のために開発プロジェクトがリスクを抱え込む,という事態を回避できる。彼らを教育するためのリソースを短縮できる。 断片的な知識が散乱している状態であっても,それらの知識を体系的に整理し直して「知識のインデックス」を持たせ,抜けや漏れをなくすことができる。そうする事により,各メンバ

    開発者のスキルチェック集 - 主に言語とシステム開発に関して
  • やはり T.class や new T() をしなくてもよい。 - happynow’s diary

    Nagise氏の「ぶっちゃけるとT.class やnew Tしたいケースは設計が悪いのだと思う。」という言葉の通りなのか、 Javaのジェネリクスで,T.class や new T() ができず悩んだ話 (型パラメータのインスタンス化に関し、フレームワーク設計からケーススタディ) - 主に言語とシステム開発に関して の記事で取り上げられているフレームワークの設計には、おかしなところがある。 当記事には その共通の性質は,BaseEntityに記述される。 とあるが、この点がおかしい。 この共通の性質というのは実はデータベースに関わる物理情報を管理するものである。 通常の DAO(Data Access Object)パターンでは、物理情報はDAOオブジェクトが管理する。 しかし、問題のフレームワークでは、データベースに関わる物理情報が ビジネスオブジェクトであるエンティティクラスで管理され

    やはり T.class や new T() をしなくてもよい。 - happynow’s diary
  • Javaのジェネリクスで,T.class や new T() ができず悩んだ話 (型パラメータのインスタンス化に関し、フレームワーク設計からケーススタディ) - 主に言語とシステム開発に関して

    Javaのジェネリクスで,型パラメータ T のインスタンスが欲しくなったことはあるだろうか? 昨今のオブジェクト指向プログラミングにおいて,ジェネリクスは必須の基文法だ。 扱う対象のクラスが抽象化されて汎用的になりつつ,なおかつ型安全性が確保される。 そのおかげで,処理の重複や分岐をコーディングする必要が無くなり,コード量が驚異的に削減される。 そういう基的な原則を踏まえると, 「型パラメータのインスタンスが欲しい」 というシチュエーションは,Javaのジェネリクスの来の導入目的に真っ向から逆らう。 なぜなら,ジェネリクスは型を抽象化して透過的に扱えるようにするための機構なのだから, せっかく抽象化した物をわざわざ具体化してどうするというお怒りを生む事になるのだ。 頑張って詳細なクラス情報を「T」でパラメータ化して具体性を隠ぺいしたにも関らず, その T に対して .class で具

    Javaのジェネリクスで,T.class や new T() ができず悩んだ話 (型パラメータのインスタンス化に関し、フレームワーク設計からケーススタディ) - 主に言語とシステム開発に関して