SoLA2-TechBlog

退屈な作業はプログラムに任せましょう!日々の作業に少し工夫を足すだけであなたの時間はもっとクリエイティブになる。

専門用語少なめ!GIT入門-コミットとステージング【基礎知識シリーズ】

f:id:gootor3030:20180828231813j:plain

概要

皆さんこんにちは、SoLA2です。

基礎知識シリーズ第5回目です。今回も引き続きGit入門ということで、コミットについて解説していきます。さあみなさんも結果にコミットしていきましょう。

コミットとは

あのRIZAPのCMでおなじみのフレーズをきっかけに「コミット」という言葉を知った方も多いかも知れません。Gitの世界で「コミット」とは、バージョン毎の記録を意味します。なので「結果にコミットする」をGit風に言うならば、「筋トレをして新しいバージョンの体を作りましょう」でしょうか(笑

コミットの中身

Gitでコミットはバージョン毎の記録であることは前述しました。では、何が記録されているのでしょうか。大きく分けて3つの要素が記録されています。

  • 変更情報(いつ、だれが、何を変更したか)
  • 備考(変更者のメッセージ)
  • システム管理用情報(リビジョン番号と、前バージョンのリビジョン番号)

コミットというとなんだか大それた感じがしますが、中身は割とシンプルですね。リビジョン番号というのは、コミット版のマイナンバーみたいなものです。実際には番号ではありませんが、すべてのコミットの中でひとつしか存在しないという点では同じです。

余談ですが、リビジョン番号は1から始まる連番ではなく、コミット内容のハッシュ値で管理されています。ただ一意の番号を振りたいだけなら連番にすればいいところ、なぜこのような面倒な仕様にしたのか。実はこれにはわけがあります。

前回の記事でリポジトリにはローカルリポジトリとグローバルリポジトリがあることを説明したと思います。バージョン管理を複数のリポジトリで行うことを分散型と呼びますが、分散型のようにリポジトリが複数存在すると困ることがあるのです。

リビジョン番号をそれぞれのローカルリポジトリで連番にしてしまうと、変更内容をグローバルリポジトリに反映する時に、リビジョン番号が重複してしまう可能性が出てくるのです。そのためこのような面倒な文字の羅列でリビジョン番号を一意にしています。

コミットするまでの流れ

実はGitの場合はファイル変更してからコミットするまでに、もう一段階手順が存在します。省略することも可能ですが、便利ですので積極的に使っていきましょう。

インデックスへの追加

実は、バージョン管理下にあるファイルを変更してもそれを直ちにコミット対象のファイルとして認識することはありません。変更したファイルの中からコミット対象となるファイルを選択する必要があります。この選択する行為をインデックスに追加(ステージング状態にする)と言います。

バージョン管理をしたことが無いと、なぜこのような冗長的な行為をする必要があるのかピンと来ない方もいるかも知れません。実はバージョン管理のしやすさを考慮すると、この中間地点が非常に便利(というより必須)に感じるようになります。

そもそもバージョン管理をする理由は、バックアップを取っておいて必要なときにすばやく前のバージョンへ戻すためでした。であれば、バージョン毎に「どのタイミングで取得したバックアップなのか」は明確であるべきで、更に言うと「戻りたいタイミングでバックアップをとっておく」べきなのです。

バージョンとはコミットのことでしたね?つまり「Aという修正」と「Bという修正」をして、それらを一括でコミットしてしまうと、戻れる地点が「AとBを修正する前」だけになってしまいます。AとBに関連性があればそれでいいのですが、全く別物だった場合は都合が悪いですね。

そこで、一旦「Aという修正」の該当箇所のみをインデックスに追加してからコミットし、その後「Bという修正」の該当箇所をインデックスに追加してコミットすることで、戻れる地点を「AとBを修正する前」と「Bを修正する前」に増やすことができるようになります。

コミットの粒度に関しては多すぎても少なすぎても良くありません。塩梅についてはある程度の目安はあるにしても、経験を積んで理解するしかありません。いずれにしろ確実に言えることは、インデックス(ステージング)という概念はGitにおいて非常に重要であるということです。

まとめ

今回はGitのコミットについて学びました。これで一人でバージョン管理する分には必要な知識が揃いました。次回は実際にファイルのバージョン管理をしていく流れをスクリーンショットを交えて紹介していきます。

ではまた。

専門用語少なめ!GIT入門-バージョン管理の必要性とリポジトリ【基礎知識シリーズ】

f:id:gootor3030:20180827002919j:plain

概要

皆さんこんにちは、SoLA2です。

基礎知識シリーズ第4回目です。今回のテーマはGit入門ということで、バージョン管理の必要性とリポジトリについて紹介します。Gitというと少し堅苦しくて使いたくないな・・・と感じるかも知れませんが、「ファイルのバージョン管理をしてくれる仕組み」と考えれば少しは興味が沸くのではないでしょうか?

バージョン管理とは

チームで開発をしたことのあるエンジニアであれば必要性について説明するまでも無いですが、実は「個人で開発をしている方」にとってもバージョン管理システムは有用なものです。

個人で開発していると、ファイル名の末尾に文言を加えたりしてバックアップを取った経験はありませんか?これは手軽にファイルをバックアップできる手段ですが、末尾に追加できる内容は精々バックアップ日時程度ではないでしょうか。

それに比べ、バージョン管理システムであれば、ほぼ無制限で備考を記録しておくことができます。さらに手動でバックアップしていると、どうしても「バックアップのし忘れ」という悲劇が起こり得ます。

そこで!ファイルの変更を自動で監視してくれるバージョン管理システムの出番というわけです。

Gitとは

Gitは、リモートで大規模なシステムを開発する際、「効率的にファイルのバージョン管理をするため」に生み出されました。具体的にバージョン毎に何を管理しているのかを下記に示します。

  • いつの更新なのか
  • 誰が更新したのか
  • どのファイルを更新したのか
  • ファイルのどこを更新したのか
  • どのような変更内容なのか
  • どのような備考を残したのか

上記の情報を参考に、現行のファイルを過去のバージョンに戻すことができます。要はファイル管理に必要な情報を効率的に残してくれて、必要に応じてバックアップ時点にファイルを巻き戻してくれるシステムなのです。

リポジトリ

上述したように、バージョン管理には様々な情報を保存しておく必要があります。その保存場所の事をリポジトリと呼びます。

基本的にバージョン管理する対象は何かのプロジェクト(ファイル群)であるケースがほとんどですので、プロジェクトのルートディレクトリ(一番上の階層に存在するフォルダ)配下をリポジトリで管理するように設定することで、プロジェクトのバージョン管理をします。

ローカルリポジトリとリモートリポジトリ

リポジトリには作業PC内のリポジトリと、オンライン上で管理しているリポジトリの2種類が存在します。

ローカルリポジトリ

ローカルリポジトリは実際に作業をするリポジトリを指し、自分専用のリポジトリです。基本的には作業PC内で管理します。

リモートリポジトリ

リモートリポジトリはネットワーク上で管理します。それぞれの作業は、ローカルリポジトリで行い、最終的な内容をリモートリポジトリに反映します。この場合リモートリポジトリの内容が常に正であるという考えが基本です。

このようなバージョン管理の方法を分散型と呼びます。分散型のバージョン管理を採用することでリモートで複数人が開発する際に、ファイルが前のバージョンに戻ってしまったり、バージョンが無造作に増えてしまうリスクを軽減できます。

SVNとの違い

バージョン管理システムでGitと同じくらいよく耳にするのがSVNです。Gitとの大きな違いはリポジトリの持ち方です。上記で説明したとおり、Gitはリポジトリを複数生成してバージョンを管理します。それに対してSVNはリポジトリ1つでバージョン管理する仕組みです。

そのため、チームで開発する場合はGitを使ったほうが無難です。個人の場合はどちらでもいいと思いますが、Gitを使っておけばソース公開するときも何かと便利ですし、私はGitをおすすめします。

まとめ

いかがだったでしょうか。今回はバージョン管理の必要性と、リポジトリについて学びました。バージョン管理は開発をする上で手間となるため適当にされがちですが、ファイルに何か会った場合に被害を最小限に押さえてくれる保険のようなものです。

次回は変更内容をローカルリポジトリへ反映する「コミット」について解説していきます。

ではまた。

【HTML基礎】SEのゆかりさんが淡々と解説する動画【floatと回り込み】

f:id:gootor3030:20180827040040j:plain

概要

皆さんこんにちは、SoLA2です。

現場でバリバリ働いているエンジニアのアナタ!bootstrapのグリッドシステムを利用してしまえばfloatなんていらんわ!とか思って、floatの知識が曖昧なまま、誤魔化したりしてませんかー?・・・何を隠そう私がそう思ってました。

なので戒めの意味も込めてfloatに関する記事を書こうと思います。今回は基礎知識シリーズ番外編です。毎回堅苦しいのもどうかと思ったので、今回は動画にしてみました。動画で見にくいコード部分は記事に載せておきます。

floatと回り込み


サンプルコード

HTML
  • float-sample.html
<!DOCTYPE html>

<html>
    <head>
        <meta charset="utf-8">
        <title>サンプル</title>
        <link rel="stylesheet" href="css/style.css">
    </head>
    <body>
        <header>
            ヘッダ
        </header>

        <div class="wrapper">
            <div class="mainContent">
                メイン
            </div>
            <div class="sideBar">
                サイドバー
            </div>    
        </div>

        <footer>
            フッター
        </footer>
    </body>
</html>
CSS
  • style.css
body {
    color: white;
}

header {
    height: 50px;
    background-color: red;
    margin-bottom: 20px;
}

.wrapper::after {
    content:'ここに挿入されてます。';
    color: black;
    clear: both;
    display: block;
}

.mainContent {
    float: left;
    height: 100px;
    width: 60%;
    background-color: green;
}

.sideBar {
    float: right;
    height: 100px;
    width: 30%;
    background-color: blue;
}

footer {
    height: 50px;
    background-color: black;
    margin-top: 20px;
}

まとめ

いかがだったでしょうか。今回はHTMLでややっこしいfloatについて学びました。最近はbootstrapなど便利なものがあるので、こういった基本的な事は忘れがちになってしまいますが、時々そういったものが使えないシーンに出くわすこともありますので、そういったときに恥を欠かないように抑えておきましょう!

ではまた。

専門用語少なめ!HTTP入門-URLとURI【基礎知識シリーズ】

f:id:gootor3030:20180823224524j:plain

概要

皆さんこんにちは、SoLA2です。

基礎知識シリーズ第3回目です。今回のテーマはURLとURIについてです。実を言うとシステム開発をする段階では、あまりURIやURLの知識が必要になることは無いのですが、見積り作成や、要件定義の段階でインフラエンジニアと相談する際に、抑えておきたい部分ではあります。

URIとURLについて

URIとURLってすごく似ていますね。実はURNなんてものもあったりします。これらの違いについて説明しようと思ったのですが、わかりやすい例えをしている記事があったのでそちらを御覧ください。
qiita.com

上記の記事にもあるように、URIはURLやURNの総称です。URLは対象の場所を一意に特定する、いわばインターネット上の住所ということですね。そのため、URLの事をアドレスなんて呼んだりもします。

URLを構成する要素

WEBアプリケーションを開発する上で、URLを構成する要素について理解する事は、必須となります。インターネットには無数のURLが所狭しと存在している訳ですが、これらURLは無秩序な文字の羅列というわけではありません。実際にいくつかURLを並べてみましょう。

いくつか共通点が見えてくると思います。まずURLの先頭から「://」までの区間ですが、上記の例では、全て「HTTPS」となっていますね。この部分はプロトコル(規約)を意味してます。ですので、上記の例にはありませんが、HTTPS以外にも、HTTPであったり、FTPなんかが存在します。

次に「://」以降最初の「.」まではホスト名を表しております。ホスト名は省略されることもあります。上記の例でいうと「著者TwitterのURL」はホスト名が省略されております。そして最初の「.」から「:」までの部分をドメインと呼んでおります。

・・・あれ?上記の例には「:」なんてないぞ!と思われるかも知れません。これはその次の要素であるポートが省略されているためです。ちなみにURLの最初の要素はプロトコルを表していることは前述しましたが、プロトコルが決まると、一般的に使用するポートも決まります。

この一般的に使用するポートの事を、ウェルノウンポートと呼びます。URI上で、ポートが省略されている場合は、ウェルノウンポートを使っていることを意味しています。

ポートは「:」から次の「/」までです。「/」以降はパスと呼ばれる部分で、サーバ内のどこに対象が配置されているのかを表しています。このパスで指定した場所にファイルが存在しない場合は404 NotFoundが返ってくるというわけです。

ドメイン名

ドメイン名は、インターネット上の場所を特定するためのものです。場所を特定するための名前なので、ドメイン名はインターネット上で一意の値となる必要があります。そのためドメインを新たに取得する場合は、ドメインを管理している組織に申請する必要があります。

余談ですが、ドメインは「.」を堺に右に行く程、範囲が大きくなります。一番右側はトップレベルドメイン(.comや.jpなど)と呼ばれます。日本の住所は最初に書く方が、範囲も大きいので違和感があるかも知れませんが、海外の場合は、右に行くほど範囲が大きくなるので、それが踏襲されたのでしょう。

ポート番号

サーバにもタワーマンションのように、多数のコンピュータがサーバの配下に存在するケースがあります。その場合、ポートはマンションの玄関を番号で表したものと言えるでしょう。通信はどの玄関から出てきて、どの玄関へ入るのかをポート番号で管理しています。

WEBアプリケーションの開発では基本的にウェルノウンポートを使うので、あまりポート番号を意識する必要はありません。とはいえ、セキュリティを考慮して一般とは違ったポートを使用する際や、ローカル開発環境でテストをする際に時々必要になる概念なので覚えておきましょう。

まとめ

いかがだったでしょうか。今回はURLとURI(とは言ってもほとんどURL)について学びました。少し細かい内容で、若干実践的ではなかったですが、インフラエンジニアと会話する際には、知らないとお話にならない内容なので、是非抑えておきましょう。

ではまた。

専門用語少なめ!HTTP入門-リクエストとレスポンス【基礎知識シリーズ】

f:id:gootor3030:20180823150448j:plain

概要

皆さんこんにちは、SoLA2です。

基礎知識シリーズ第2回目です。今回は、HTTPリクエストやHTTPレスポンスについて解説します。ふとした時にヘッダ情報を扱わなければならなくなり、苦戦するエンジニアも多いはず!そこで今回はそんなとき困らないように、実践で必要となる部分に的を絞って解説していきたいと思います。

HTTPリクエストとHTTPレスポンス

前回の記事でお伝えしたとおり、「ブラウザ(クライアント)」が「サーバ」に対して接続を要求するときに出すものをリクエスト、正確にはHTTPリクエストといいます。また、そのHTTPリクエストに対して「サーバ」が返すものをHTTPレスポンスと呼びます。

HTTPリクエストやHTTPレスポンスは、ぱっと見文字の羅列なのでとっつきにくいと思います。なので3つの領域に分けてしまいましょう。

HTTPリクエストのフォーマット

HTTPリクエストを3つの領域に分けると下記の3領域になります。

  • リクエスト・ライン(最初の1行)
  • メッセージ・ヘッダ(最初の1行を除く空白行より前の部分)
  • メッセージ・ボディ(空白行より後の部分)

最初の1行に記述されている部分は、リクエスト・ラインと呼ばれ、ここを見れば大まかに、どういったリクエストなのかを判断することができます。HTTPリクエストのリクエスト・ラインを更に細かく分けると、「メソッド」「URI」「HTTPバージョン」の3要素に分けることができます。

メソッドの種類

「メソッド」は「サーバにどのような動作をして欲しいのか」を伝えるための要素です。例えば、典型的なパターンとして「フォームに入力したデータを指定したURIのプログラムに渡す」といった動作がそれに該当します。

メソッドにはいくつか種類が存在しますが、数が多いので全ての種類を覚えるのではなく、代表的な4つを覚えておきましょう。この4つはRESTと呼ばれる設計思想を満たすアプリケーションを開発する際に必要となるものです。

  • GET:URIで指定した要素を取得します。
  • POST:URIで指定した場所に登録します。
  • PUT:URIで指定した要素を更新します。
  • DELETE:URIで指定した要素を削除します。

余談ですが筆者も、AWSの「Lmbda」と「API Gateway」を使ってサーバレスのアプリケーションを開発しようとした時、GETとPOSTしか知らなくて戸惑った記憶があります。サーバレスを選択肢のひとつにできると、お客様の要件と合致した場合は、コストを抑えることができるため提案の幅が広がります。

URIとURL

「URI」でなんぞ?「URL」に似てるなって思った方、鋭いですね。実際に「URL」は「URI」のことでもあります。正確には「URI」は「URL」よりも広義の意味で使われますが、現状は「URL」=「URI」と認識しておいて問題ありません。詳しくは次回の記事で解説します。

HTTPレスポンスのフォーマット

HTTPレスポンスを3つの領域に分けると下記の3領域になります。

  • ステータス・ライン(最初の1行)
  • メッセージ・ヘッダ(最初の1行を除く空白行より前の部分)
  • メッセージ・ボディ(空白行より後の部分)

最初の1行に記述されている部分は、ステータス・ラインと呼ばれています。HTTPレスポンスのステータス・ラインを更に細かく分けると、「HTTPバージョン」「ステータス・コード」「レスポンス・フレーズ」の3要素に分けることができます。

「ステータス・コード」と「レスポンス・フレーズ」

名前だけだとピンとこない人も、次の文言には見覚えがあるのではないでしょうか?

「404 Not Found」

指定したURLでページが見つからなかったときに、よく表示されるあれですね。実はこの文言こそが、「ステータス・コード」と「レスポンス・フレーズ」なのです。細かい話をすると、404が「ステータス・コード」で、Not Foundが「レスポンス・フレーズ」です。

システムの保守を担当しているエンジニアであれば、障害対応でお馴染みの「ステータス・コード」ですが、種類が非常に多いので、すべて覚える必要はありません。ですが、百の位がステータスの大まかな意味を表していることくらいは理解しておきましょう。

  • 100番代:単なる情報を返しています
  • 200番代:成功した旨を返しています
  • 300番代:さらなる処理を要求しています
  • 400番代:リクエストに誤りがあった旨を返しています
  • 500番代:リクエストの処理に失敗した旨を返しています

まとめ

いかがだったでしょうか。今回はHTTPリクエストとHTTPレスポンスについて学びました。これらの知識はネットワークエンジニアのみならず、デバックや障害対応をするエンジニアであれば知っていて損はない領域でしょう。

いざ必要になってから調べ始めると存外時間がかかるものです。真のエンジニアとして活躍したいのであれば、日頃からこういった知識に触れて、最低限の基礎知識は習得しておいたほうが良いと思います。

次回は、今回もちらっと登場したURIについてもう少し踏みこんだ内容を解説していきたいと思います。
ではまた。

専門用語少なめ!HTTP入門-プロトコルの概要について【基礎知識シリーズ】

HTTPってなに?

概要

皆さんこんにちは、SoLA2です。今回から初心者でも、現場でバリバリ働いているプロのエンジニアであっても、意外に忘れがちな、ITに関する基礎知識について掲載していきたいと思います。

記念すべき第一回は、「HTTP」について!「HTTP」とか「HTTPS」ってインターネットをしている人なら、よく目にする単語だと思います。でも意外にこの意味がわかる人って意外に少ないのではないでしょうか。

HTTPってなに?

そもそもHTTPはある言葉の省略したものです。どのような言葉だかご存知でしょうか。

「Hypertext Transfer Protocol」

ですね。知ってる!って方も多いかと思います。直訳すると、「ハイパーテキストをやり取りするための決まりごと」といった感じでしょうか。「ハイパーテキスト」ってなんやね!とツッコミを入れたくなる方もいるかも知れません。

ハイパーテキストも略語です。正式には「Hypertext Markup Language」と呼びます。つまり「HTML」のことです。今皆さんが見ているこのWEBサイトは基本的に「HTML」と呼ばれるフォーマットで記述されています。

話は戻りますが、この「HTML」をやり取りするための決まりごとが「HTTP」という訳です。

安全を考慮した通信

皆さんはインターネットで買い物をすることはあるでしょうか。私はよくAmazonを利用しています。本当に便利ですよね。家にいながら大体のものは手に入れることができる。素晴らしい。

ですが便利な半面、「不特定多数がアクセスするインターネット上に、個人情報を入力するのは一抹の不安がある」という方もいらっしゃるかと思います。そこで、そういった方でも安心して利用するための技術が、暗号化です。

「HTTP」に暗号化の技術を採用したものが「HTTPS」と呼ばれます。この「S」は「Secure」の略です。「HTTPS」はデータを暗号化してやり取りするので、第三者に読み取られにくいというメリットがあります。今後WEBサイトやWEBアプリケーションを開発するのであれば、基本的に「HTTPS」を使うようにしましょう。

プロトコル(決まりごと)

プロトコル

プロトコルという言葉は、エンジニアには馴染み深い言葉ですが、そうでない人からすると「ハイパーテキスト」に次ぐミステリーワードですね。日本語訳は「規約(決めごとや、約束事)」を意味します。

こういった規約が存在するのには理由があります。コンピュータは人間のように、曖昧なものを判断することが苦手です。加えてインターネットは不特定多数の人がアクセスするので、皆が無秩序にやり取りすると、いくら性能の良いコンピュータであっても混乱の元になります。

そこで皆が同じルールに則ってやり取りすることで、そこで交わされるデータのフォーマットに一貫性が生まれるため、曖昧なものを判断することが苦手なコンピュータでも混乱しないような工夫が「プロトコル(規約)」なのです。

サーバとクライアント

インターネットにアクセスする場合、一般的にそのユーザが操作する「ブラウザ(クライアント)」からホームページを公開している「サーバ」に対してリクエストを投げます。このように、インターネットと一口に言っても様々な機構から構成されています。

HTTPにおいて重要になる機構は、「サーバ」と「クライアント」です。この両者間でプロトコル(規約)に則ってデータをやり取りすることになります。

HTTPリクエストとHTTPレスポンス

上記で少し話題に出ましたが、「ブラウザ(クライアント)」が「サーバ」に対して接続を要求するときに出すものをリクエスト、正確にはHTTPリクエストといいます。また、そのHTTPリクエストに対して「サーバ」が返すものをHTTPレスポンスと呼びます。

まとめ

いかがだったでしょうか。今回は少し初級者向きの内容だったかも知れませんが、最近は優秀なフレームワークが存在するため、現役のエンジニアであってもこういった基礎知識を忘れてしまいがちです。

HTTPはWEBサイトやWEBアプリケーションを開発するための一番基礎となる知識ですので、時々立ち止まって気分転換がてら復習してみるのも良いかも知れません。

次回はHTTPリクエストやHTTPレスポンスについてもう少し踏みこんだ内容を載せていきます。
ではまた。

英語文書を読む時に便利なツールを作成してみた

皆さんは英語の文書を読むの得意ですか?・・・私は苦手です。できることなら全て日本語で済ませたい派です。知らない知識について記述されている物を英語で読むなんて・・・想像するだけでも頭くらくらしてきます。

ということで英語の文書を読む時に「あると便利だなぁ」と思ってたツールを作ってみました。ちなみに今から紹介するのは、Google翻訳の結果をシームレスに確認できるようにするツールですので、英語ができる方にとっては無用の産物かもしれません。

概要

本ツールの正体は簡易的なエクセルのマクロです。翻訳自体はGoogle翻訳で行っていますし、特徴と言えば「翻訳結果をVOICEROIDが音読してくれるかどうか」という部分ですね。

ちなみにVOICEROIDがインストールされていないPCで本ツールを利用した場合、音声は再生されませんがエクセルのシート上に結果を反映されるため、それを確認すれば少しは効率的に作業を進められるかと思います。

  • 利用言語:VBA(エクセル)
  • 動作環境:IE及び、Excel2016(マクロが動作すること)
  • その他:本ツール利用時、クリップボードを専有します。 ※今後の改修で改善したいと思っています。

利用想定シーン

私が個人的に英語の文書を読む時に必要な機能を詰め込んだツールですので、基本的にはその用途以外には向いていないと思います。英語学習の際に有効活用とかできますかね・・・?

ターゲット

IEしか利用できなくて、フリーソフト等のインストール(レジストリ書換する行為)が禁止されている環境で、効率的に英文書を読み進めたい人

外部仕様

本ツールはエクセル上で動作するマクロです。ですのでシート毎に説明していきたいと思います。

Google本屋君シート

f:id:gootor3030:20171112180447p:plain

こちらのシートが本ツールのメインになります。基本的な機能だけ利用するならこのシート以外は操作する必要がありません。このシートで提供する機能は主に以下の3つです。

  • Google本屋君マクロ開始ボタン
  • 連携システム「echoseika」の配布先リンク
  • 紹介動画のリンク
Google本屋君マクロ開始ボタン

シート右上に存在する「押す!」ボタンを押下することでマクロが起動します。起動後はクリップボード監視に関するメッセージダイアログが出現し、その後本体のダイアログが表示されます。

なお、起動時に「VOICEROID+ 琴葉茜」を起動しておくことによりツール起動のボイスを聞くことが出来ます。

連携システム「echoseika」の配布先リンク

本ツールではechoseikaを利用しております。VOICEROIDと連携するためのプログラムですが、参照設定の仕様上、VOICEROIDと連携する想定が無い場合でも、該当ファイルを配置する必要があります。

紹介動画のリンク

導入方法とか利用方法とかを動画で紹介しておりますので、よかったらご視聴下さい。
この記事の一番最後にも貼っておきますね。

設定シート

f:id:gootor3030:20171112194102p:plain

こちらのシートでは、茜ちゃんが翻訳結果を音読してくれる際の声色のプリセットを設定出来ます。お好みで、下の行に追加していって下さい。追加後は本ツールを一旦閉じて頂き、再び起動していただくことで反映されます。

翻訳シート

f:id:gootor3030:20171112194551p:plain

こちらはログ表示用のシートだと思っていただいて大丈夫です。A列に翻訳前の原文、B列に翻訳後の訳文を記録しております。

なお、VOICEROIDがインストールされていないPCで本ツールを使う場合はこのシートで翻訳結果を確認することになります。音声にて確認できない分効率は低下しますが、Google翻訳での操作が省ける点ではまだメリットがあるのかなって思います。

リリースノート

このシートは本ツールの機能とは全く関係ありません。リリースノートを私が記入しているものですので、必要に応じて確認してください。

デモンストレーション

以下の動画で本ツールのデモをしております。ぜひ御覧ください。
※2分4秒くらいから始まります。

とりあえずツールの概要については以上になります。
次回以降の記事で、内部仕様についてもう少し解説して、配布用にマクロ部分のリファクタリングが完了したらいよいよ配布していこうと思いますので、お楽しみに!