覚えたら書く

IT関係のデベロッパとして日々覚えたことを書き残したいです。twitter: @yyoshikaw

Mac - 余白無しでスクリーンショットを撮る

Windowsをメインで使っている人間なのでMacでの操作や動きに戸惑うことが多々あります。

で、今回は画面のスクリーンショットを撮る時の動作に関してです。

スクリーンショットを撮るパターンとしておおよそ以下の3パターンになると思います

  • 画面全体のスクリーンショットを撮る
  • 範囲を自分で選択して、画面の一部のスクリーンショットを撮る
  • 特定のウィンドウやダイアログのみを撮る


各スクリーンショットを撮るには以下の操作をします

パターン 操作
画面全体のスクリーンショット shift + command + 3 を押す
自分で範囲選択した画面の一部のスクリーンショット shift + command + 4 を押す
その後にマウスで撮影範囲をドラッグする
特定のウィンドウやダイアログのみ shift + command + 4 を押す
その後Space bar(スペースキー)をクリックして、Enterを押す

上記は、キーボードのキーの同時押しで基本的に実現する方法ですが、
Spotlight検索で "スクリーンショット" と入力して、スクリーンショット.app を起動して、各スクリーンショットを撮ることもできます。

f:id:nini_y:20200405135602p:plain


ウィンドウのスクリーンショットの余白

Windowsとスクリーンショット撮影の操作方法操作で違いがあるのは当然だと思うのですが、
"特定のウィンドウやダイアログのみ" のスクリーンショットを撮った時だけ周りに余白領域が付いてくるというのが、Windowsとかなり違います。
自分の場合は、この余白は不要と感じるケースしかありません。。。

以下はSafariのウィンドウのスクリーンショットを撮った例ですが、撮影した画像にきっちり余白領域まで含まれてしまっています。(以下はプレビュー.appで表示しています)

f:id:nini_y:20200405140024p:plain

この余白領域をどれだけの人が必要としているのかよく分かりませんが、私は不要です。


ウィンドウのスクリーンショット撮影時に余白が含まれないようにするためにはTerminalで以下操作をすることで可能です。

$ defaults write com.apple.screencapture disable-shadow -boolean true
$ killall SystemUIServer

実際の実行例は以下の通りです。(上の内容とほぼ何も変わりませんが。。。)

yukiMacBook:~ yuki$ defaults write com.apple.screencapture disable-shadow -boolean true
yukiMacBook:~ yuki$ killall SystemUIServer


これを実行したあと、ウィンドウのスクリーンショットを撮ると以下のようになります。(プレビュー.appで表示しています)

f:id:nini_y:20200405140919p:plain

無事に、ウィンドウのスクリーンショット撮影画像に余白が含まれなくなりました!


補足

ちなみに余白をつけるように戻す場合は以下のいずれかの操作を行います。

$ defaults delete com.apple.screencapture disable-shadow
$ killall SystemUIServer
$ defaults write com.apple.screencapture disable-shadow -boolean false
$ killall SystemUIServer

MacBook - キーボードのファンクションキーをデフォルトでONにする

Touch BarではないモデルのMacBook Proでファンクションキー(F1, F2, F3 ...)を有効にする方法です。

どのモデルもそうなのかは不明ですが、例えば MacBook Pro のキーボードで F1, F2キーを押すと
F1, F2キー(ファンクションキー)としての動作ではなく、画面の明るを変更する動きになります。

ファンクションキーとして動作せる場合は、 Fnキー + F1キー という感じで Fnキーを押しながら操作する必要があります。

例えば、日本語のカタカナ変換をするときに、Windowsでは F7キーを押して変換することがありますが、
MacBook Proのデフォルトの状態では、Fnキー + F7キー を押す必要があり 若干面倒に感じます。

こういった際に、キーボードのファンクションキーをデフォルトで有効にしておきたくなります。
その際には以下のような手順で設定を行います。


設定手順

アップルメニューから「システム環境設定」を開きます

f:id:nini_y:20200405185223p:plain


システム環境設定の中から「キーボード」を選択します

f:id:nini_y:20200405110946p:plain


「キーボード」タブ内の "F1、F2などのキーを標準のファンクションキーとして使用" にチェックを入れます

f:id:nini_y:20200405111033p:plain


これで設定完了です


補足

システム環境設定の「キーボード」の設定へは、
Spotlight検索で "キーボード" や "keyborad.prefPane" と入力して移動することもできます。

f:id:nini_y:20200405111350p:plain

ルーティングプロトコル - IGP

「インフラ/ネットワークエンジニアのためのネットワーク技術&設計入門 第2版」を読んでおります。
まだ読んでる途中ですが、めちゃくちゃいい本だと思います。とにかくわかり易いです。
普段プログラミングがメインでインフラ(ネットワーク)と縁遠い人も読んでみる価値あると思います。


この本でなくてもネット上に情報はあると思いますが、
本書籍に書かれているルーティングプロトコルの IGP(Interior Gateway Protocol, 内部ゲートウェイプロトコル) について記録しておきたくなったので、ここにメモしておきます。


ルーティングテーブル

ネットワークのルーティングを司っているのがルーティングテーブルで、このルーティングテーブルをどうやって作るのかがネットワーク層のポイントとなる。
ルーティングテーブルの作り方は大きく分けて 静的ルーティング動的ルーティング の二つがある。

  • 静的ルーティング
    • 手動でルーティングテーブルを作る方法
    • 一つ一つ宛先ネットワークとネクストホップを設定する
    • 管理もしやすいので、小さなネットワーク環境のルーティングに適している。
  • 動的ルーティング
    • 隣接するルータ同士で自分の持っているルート情報を交換して、自動でルーティングテーブルを作る方法
    • ルート情報を交換するプロトコルを ルーティングプロトコル という
    • 大きなネットワーク環境や構成が変わりやすいネットワーク環境であれば動的ルーティングを使用した方がよい
    • 宛先のどこかに障害が発生した場合も、動的に迂回ルートを探してくれるため耐障害性も向上する


2種類のルーティングプロトコル

ルーティングプロトコルはその制御範囲によって以下2種類に分けられる

  • IGP(Interior Gateway Protocol, 内部ゲートウェイプロトコル)
  • EGP(Exterior Gateway Protocol, 外部ゲートウェイプロトコル)

この2つを分ける概念が AS(Autonomous System, 自律システム)
ASは一つのポリシーに基づいて管理されているネットワークの集まりのことで、例えばAS=組織(ISP, 企業, 研究機関, 拠点) のような感じでとらえると良い。
AS内を制御するルーティングプロトコルが IGP, ASとASの間を制御するルーティングプロトコルが EGP。


IGP

色々なIGPが存在するが、現在のネットワーク環境で使用されているプロトコルは RIPv2(Routing Information Protocol version2), OSPF(Open Shortest Path Fast), EIGRP(Enhanced Interior Gateway Routing) のどれかと考えて良い。

これらを説明する上でのポイントが ルーティングアルゴリズムメトリック の二つ。

  • ルーティングアルゴリズム
    • どうやってルーティングテーブルを作るかのルール
    • ルーティングアルゴリズムの違いが収束時間(ネットワーク上のルータがすべてのルートを認識している状態(収束状態)になるまでにかかる時間)や適用規模に直結する
    • IGPのルーティングアルゴリズムは ディスタンスベクタ型リンクステート型 のどちらか
      • ディスタンスベクタ型は、距離(ディスタンス)と方向(ベクタ)にもどついてルートを計算する
        • ここでいう距離とは宛先に行くまでに経由するルータの数(ホップ数)を表し、方向は出力インターフェースを表す
      • リンクステート型は、リンクの状態(ステート)に基づいて最適ルートを計算する
        • 各ルータが自分のリンク(インターフェース)の状態や帯域、IPアドレス等色々な情報を交換してあってデータベースを作り、それをもとにルーティングテーブルを作る
  • メトリック
    • 宛先ネットワークまでの距離を表している
      • ここでいう距離とは物理的な距離ではなく、ネットワークにおける論理的な距離


RIPv2 / OSPF / EIGRP

先にも書いた通り、現在のネットワーク環境で使用されているIGPのルーティングプロトコルは、RIPv2, OSPF, EIGRP のどれか。

RIPv2 OSPF EIGRP
ルーティングアルゴリズム ディスタンスベクタ型 リンクステート型 ディスタンスベクタ型
(ハイブリッド型)
メトリック ホップ数 コスト 帯域幅+遅延
更新間隔 定期的 変更があったとき 変更があったとき
更新に使用する
マルチキャストアドレス
224.0.0.9 224.0.0.5 (ALL OSPF ルータ)
224.0.0.6 (ALL DR ルータ)
224.0.0.10
適用規模 小規模 中規模〜大規模 中規模〜大規模

RIPv2

  • 最近ではあまり見られないが、古い環境にたまに残っている
    • そこからOSPFやEIGRPに移行することがある
    • 新しく作るネットワークでこのプロトコルを使用する必要性は無い
  • RIPv2はルーティングテーブルそのものを定期的にやり取りしあうことで、ルーティングテーブルを作る
  • 動きはとても分かりやすいが、ルーティングテーブルが大きくなればなるほど余計な帯域を消費し、収束にも時間がかかるため大規模なネットワーク環境には不向き
  • メトリックにはホップ数を使用している
    • ルータを経由すればするほど遠いという扱いになる
    • 途中の経路の帯域が小さくても、ホップ数が小さいルートを最適ルートとしてしまうため難がある


OSPF

  • RFCで標準化されているルーティングプロトコルということもあって、マルチベンダのネットワーク環境ではOSPFを使用することが多い
  • OSPFは各ルータがリンク状態や帯域、IPアドレス、ネットワークなど色々な情報を交換しあって「リンクステートデータベース(LSDB)」を作る
    • そこから最適なルート情報を計算し、ルーティングテーブルを作る
  • (RIPv2は定期的にルーティングテーブルを送りあっているのに対して、)OSFPは変更があったときにだけ更新がかかる
    • 通常時は Helloパケットという小さなパケットを送信して、相手が正常に動作しているかどうかだけを確認しているため、必要以上に帯域を圧迫することがない
  • LSDBが大きくなりすぎないように、ネットワークをエリアというものに分けて、同じエリアのルーだだけでLSDBを共有する
  • メトリックに使用するコストは、デフォルトで「100 / 帯域幅(Mbps)」に当てはめて整数値として算出され、ルータを超えるたびに出力インターフェースで加算される
    • したがって、ルートの帯域が大きければ大きいほど最短ルートになりやすい
    • 学習したコストが全く同じだった場合は、コストが同じルートを全て使用してパケットを運び、ルートの負荷分散を行う
      • このような動作を ECMP(Equal Cost Multi Path) という。ECMPは耐障害性の向上だけでなく、帯域の拡張も兼ねることができ、多くのネットワーク環境で使用されている
    • コスト算出の式は、100Mbps以上のインターフェースで同じ値になってしまうため、最近は分子の値を 100 よりも大きくするのが一般的


EIGRP

  • Cisco独自のルーティングプロトコル
    • そのため、CiscoルータやCiscoのCatalystスイッチで構成されているネットワーク環境でしか使用できない。使用できる環境であればかなりの力を発揮する
  • 最初に自分の持つルート情報を交換してそれぞれでトポロジーテーブルを作り、そこから最適なルート情報だけを抽出し、ルーティングテーブルを作る
    • この部分は、RIPv2に似ているが、EIGRPは変更があった時だけ更新がかかる
    • また、通常時はHelloパケットという小さなパケットを送信して、相手が正常に動作しているかを判断する。この部分はOFPFに似ている
  • メトリックはデフォルトで「帯域幅」と「遅延」を使用する
    • 帯域幅は「10000 / 最小帯域幅(Mbps)」の式に当てはめて算出する。宛先ネットワークまでのルートの中で最も小さい値を採用して計算する
    • 遅延は「マイクロ秒 / 10」の式に当てはめて算出する。ルータを超えるごとに出力インターフェース分を加算する
  • 「帯域幅」と「遅延」を足して256をかけたものがEIGRPのメトリックとなる
  • EIGRPもデフォルトの動作はECMP
    • メトリックが全く同じであれば、そのルートを全て使用してパケットを運び負荷分散する



関連エントリ

Java 6 - String#substringによるメモリリークの可能性

(もともとQiitaに書いていたものを、ここに移動させました。)


※以下Java 6までの問題です。Java 7では解決されています


String#substring は新しい文字列を new String で生成するにも関わらず切り出し前の文字列を内部(のchar配列)で保持してしまっています。

本内容は通常は意識する必要はありませんが、巨大な文字列をsubstring操作する際はメモリリーク等につながる場合がありますので注意が必要です。
(String#splitにも同様の問題があります)

String s1 = "0123456789";       // -> s1内部のchar配列は {0, 1, 2, 3, 4, 5, 6, 7, 8, 9}

String s2 = s1.substring(5);   // -> s2内部のchar配列は {0, 1, 2, 3, 4, 5, 6, 7, 8, 9} ({5, 6, 7, 8, 9}ではない!)

System.out.println(s2);         // -> "56789"
// 対処方法1
String s3 = new String(s1.substring(5));
// 対処方法2
String s4 = s1.substring(5).intern();

「CODE COMPLETE 完全なプログラミングを目指して(下)」 第20章 ソフトウェア品質

「CODE COMPLETE 完全なプログラミングを目指して(下)」 の 第20章 ソフトウェア品質 で気になった部分の抜粋です


ソフトウェアの品質改善技術

  • 組織によっては、その場しのぎのプログラミングが横行している。ボロボロのコードをまき散らし、プログラムを素早く完成させるGloba Garyタイプのプログラマの方が、すばらしいプログラムを書き、正しく動くことを確認してからリリースするHigh-Quality Henryタイプのプログラマよりも褒められる。このような組織では、プログラマが品質を最優先事項と考えないのは当然だ。

  • 開発中のソフトウェアの技術的な特性を制御するのがガイドラインである。

  • ソフトウェアエンジニアリングプロセスの管理の一つに、「最も価値の低い」段階で問題を特定するということがある。つまり投資が少なく、問題を修正するためのコストが最も少ない段階で問題を特定するのである。

開発プロセス

  • ソフトウェアの品質向上を妨げる重大な障害の1つは、変更が管理されていないことである。

  • 評価によって品質保証計画が成功したかどうかが明らかとなり、プロセスを既定の方法で調整し、改善の余地があるかどうかを確かめることができる。

  • 複数のケーススタディでプロトタイピング方式と従来どおり仕様から順に開発する方式とを比較した調査結果がある。この結果からプロトタイピングの方が優れた設計を生み、ユーザーのニーズをよく見たし、保守性を向上させることがわかっている。

目標の設定

  • プログラマは指定された目標に取り組むが、それには目標が何かを知らされていなければならない。


ソフトウェア品質改善技術の相対的な効果

  • ソフトウェアの欠陥検出のもっとも一般的な方法である単体テストと統合テストの欠陥検出率の標準値は30~35%に過ぎない。
    • プロジェクトの開発者が欠陥の排除率をどうしても引き上げたいのなら、様々な方法を組み合わせる必要があることが強くうかがえる。

欠陥検出のコスト

  • ほとんどの研究でインスペクションはテストよりも欠陥検出のコストが低いという結果が出ている。

欠陥修正のコスト

  • 欠陥がシステムに長くとどまればとどまるほど、それを排除するコストは高くなる、したがって、欠陥を早期に発見する検出テクニックには修正コストを抑える働きがある。

ソフトウェア品質の原則

  • ソフトウェア品質とは、品質を改善すると開発コストが低くなることである
  • コーディングのやり直しにかかる時間を減らすことが、生産性と品質を向上させる最善策なのである。
  • ほとんどのプロジェクトで最も時間のかかるアクティビティは、正しく動作しないコードのデバッグと修正である。デバッグとそれに伴うリファクタリングなどの修正作業は、従来の単純なソフトウェア開発サイクルにおいて約50%の時間を占める。エラーを予防してデバッグを減らせば、生産性は向上する。したがって、開発スケジュールを短縮する最も明らかな方法とは、製品の品質を向上させ、ソフトウェアのデバッグや作業のやり残しにかかる時間を減らすことである。



関連エントリ