サイト利用規約の書き方

サイト利用規約は、ユーザーに承諾をえるためのボタンを押してもらわないと、契約とみなされない
サイト利用規約自体は書く義務が定められているわけじゃない。特定商取引法 や 個人情報保護法 などで、書く必要のあることがあるかも

注意したほうが良さそうなこと

個人情報保護法

何を収集するか、誰に提供するか、どういう目的で使うか、をすべて明示して、すべて承諾を取る

特定電子メール法

宣伝メールを送る場合は、オプトイン形式で許可をとってから送る

プロバイダ責任制限法

名誉毀損や著作権侵害があった場合、送信防止措置を取らないといけない

不正アクセス禁止法

不正アクセスからの防御をする努力義務がある。

信頼されたい場合、セキュリティポリシーを書いても良いかも？

不正指令電磁的記録に関する罪

http://www.moj.go.jp/content/000076666.pdf

バックグラウンドで行う処理は、プログラムの目的にあっていて、ユーザーに説明をして、まともなものにしたほうが良さそう

利用規約に書くことの例

禁止事項、免責事項、料金やポイント、は詳しく書く

http://www.itoh.fullstage.biz/webbusiness/topics/025.html

http://www.itoh.fullstage.biz/webbusiness/topics/020.html

商品紹介ページの作り方

売上 = 集客 x コンバージョン率 x リピート率
商品をカテゴリー分けする
.. な人には .. みたいに合ったものを紹介

ファーストビュー が良くないと、ユーザーがページをすぐ閉じる
「..する方法」「ついに公開！..」「あなたはまだ..をしていませんか？」
問題提起をして注意を惹く -> 動揺する内容を書く -> 解決策を提示する (※全部は説明しない)

キャッチコピーの下にベネフィットリスト
機能だけでなく、それを使ったユーザーの未来を想像できるようにする
商品を買わない事によるリスクも訴える

その商品が一番である事、条件が一番である事、を説明
作者の信用性の高さをアピール
お客様の声や感想

CTAボタンを矢印で目立たせる、「無料」「すぐに」、緑、オレンジ、大きめの目立つボタン
魅力的な価格、期間限定、特典を用意
価格をいくつか設定すると、真ん中あたりの価格が妥当だと思うようになる
１月、１日あたりの少額の方が試しやすい
入手する方法は詳しく説明

動画をおく
伝えたいことが強調されるデザイン
信頼性や安心感を与えるデザイン
高品質な商品画像、実際に使っているところ

Twitter, Facebook, Google+, Pinterest, はてブ のボタン

ロードマップ2

お絵描き訓練室

立体を幾何学的なものではなく、現実にあるものにする

採点アルゴリズム

１ラウンド分の結果をRT

演出

その他

ツールを普段から、出来る限り使う

紹介ページ、著作権の管理、利用規約
ペイントソフトの強化

AdSenseの貼り方

AdSense プログラムポリシー

https://support.google.com/adsense/answer/48182?hl=ja
「デジタルミレニアム著作権法 DMCA」に準拠した侵害の報告があれば対処しますと書いてある。
DMCAに従ってすぐに対処されるらしいので、気をつけたほうが良さそう。

「コンテンツガイドライン」に違反するコンテンツはダメらしい。
NGワード にあたるような文字列もダメらしい。

https://support.google.com/adsense/answer/1348695
広告について、プライバシーポリシーで説明しないといけないらしい。
即行で適当なもの http://nagat01.web.fc2.com/privacy.html を用意しておいた・・

広告の配置に関するポリシー

https://support.google.com/adsense/answer/1346295?hl=ja
基本的に、まぎらわしいもの、誤クリックが起きるもの はダメらしい。

http://adsense-ja.blogspot.jp/2013/03/flash.html
ゲームウィンドウからは 150px 離して広告を配置にするべきらしい。

http://adsense-ja.blogspot.jp/2012/03/adsense-faq.html?sourceid=aso&subid=ww-jp-et-asblog_2013-03-25&medium=link
ゲーム開始方法が分かりやすく、ゲームに関する説明が読める状態にするべきらしい。

プログラムの著作権

IBFファイル事件

http://www.itlaw.jp/IBF.pdf
IBFファイルは今で言う shell script に近いもの

1. 機械語に変換されないからプログラム著作物ではない
2. 決まりきった内容になるものなので、創作性がない
3. 別表現に書きなおされたものは、類似性を認めない

1 については、ソースコードは機械語にコンパイルされるもの、ではないので今はこの判断はくつがえされてそう。
2,3 については、そのとおりだと思う。

http://www.hanketsu.jiii.or.jp/hanketsu/jsp/hatumeisi/news/199302news.html
ＣＡＳＥツール、設計情報からソースコードを自動生成するもの
これは、メタプログラミングの一部な気がする
ソースコードの自動生成は、誰が実行しても同じだから、創作性がないと書かれている

http://www.indigobullet.com/info-d/programCopyright.html
現在は、バイナリ形式でもソースコードでコンパイル形式、スクリプト形式、どれもプログラム著作物になるらしい

http://nekoblog.katsubemakito.net/2012/06/javascript.html
しかし、創作性を証明するのが難しくなっているらしい

プログラムの著作権

他の著作物とは違う扱いがいろいろあるらしい
http://www.jpaa.or.jp/activity/publication/patent/patent-library/patent-lib/200706/jpaapatent200706_095-100.pdf
コンパイルは「複製」だから著作物にあたる、という事らしい。
「私的複製」は認められているし、著作権には「使用権」がないけど、
違法に入手したものを利用することは侵害になるらしい
技術的保護手段の回避は、CD、DVD、ビデオテープ などが該当するらしい

プログラムが生成したものの著作権

http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1074591555

1. プログラムに内蔵されている音に著作権がある
2. 民法には契約自由の原則があるので、プログラムが生成したものに対する利用規約を作ることが出来る

1 は http://www.jspa.gr.jp/copyright/ で、音色が創造的で独自の価値があれば著作権があると書いてある。

http://futabayanote.blog.shinobi.jp/%E6%9C%AA%E9%81%B8%E6%8A%9E/utau%E9%9F%B3%E6%BA%90%E3%81%AE%E8%91%97%E4%BD%9C%E6%A8%A9%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6%E3%81%A1%E3%82%87%E3%81%A3%E3%81%A8%E3%81%BE%E3%81%98%E3%82%81%E3%81%AB%E8%80%83%E3%81%88%E3%81%A6%E3%81%BF%E3%81%9F を読むと、音声素材に著作権がつくのはまずいので実演と考えて、著作隣接権が付くべきでないかと書かれている

2 は、契約が色んな場面で有効だということがわかった。

Open JTalk のコマンドのパラメータ

何も知らないので、正確性が何もない

パラメータ	初期値	範囲	正確でない説明
-s	auto	1 ~	サンプリング周波数
-p	auto	1 ~	フレーム周期、分析をする時間間隔
-a	auto	0 ~ 1	オールパス値、位相だけをバラつかせることで音が自然になるらしい
-b	0	0 ~ 1	ポストフィルタ値、統計モデルによる平滑化による音質劣化を緩和するらしい
-r	1	0 ~	話す速さ
-fm	1	0 ~	追加ハーフトーン
-u	0.5	0 ~ 1	有声/無声境界値
-jm	0	0 ~ 1	スペクトラム系列内変動の重み、統計モデルによる平滑化で失われる特徴量を考慮した音声合成をする時の重み
-jf	0	0 ~ 1	F0系列内変動の重み、F0は基本周波数のことらしい、F0に対して特徴量を考慮して音声合成する時の重み
-z	0	0 ~	音声バッファサイズ

結論

以上のような理解のまま、パラメータを変えまくって試してみた。

オールパス値は、低いとピーッという音に、高いとザーッという音になる
ポストフィルタ値を大きくすると、音が揺らぐ感じ
追加ハーフトーンも、音が揺らぐ感じ
有声/無声音は、大きくすると息がすぐに切れる
変動の重み が大きいとクリアな音声になる。大きすぎると乱れた感じになる。

このパラメータとは関係がないけど、たぶん辞書にある日本語の単語が続くほうが上手く分解して読んでくれるみたい。

結果、速度と声の明瞭さを少し下げて使うことにした。
>open_jtalk -x C:\open_jtalk\dic -m C:\open_jtalk\voice\mei_normal.htsvoice -s 48000 -p 240 -b 0.1 -a 0.55 -r 0.75 -fm 0 -u 0.2 -jm 0.5 -jf 0.5 -z 8000 -ow 1740.wav 1740.txt

Windows で Open JTalk を使う方法

ソフトウェアが 修正BSDライセンス、データが CC BY で公開されている音声合成 Open JTalk を Windows で導入する方法を調べてみた

主な道具

HTS voice: 訓練データ
hts_engine api: 訓練データから音声合成するエンジン
Dictionary for Open JTalk: 形態素解析に使う辞書
Open JTalk: 上記のものを組み合わせて音声合成するシステム

導入方法

OptnJTalk のビルドの仕方
http://neu101.seesaa.net/article/384051747.html

MMD-Agent mei の音声ファイルについて
http://kledgeb.blogspot.jp/2014/05/ubuntu-open-jtalk-3-mmdagentmeimei-mei.html

結論

Open JTalk のページから、OpenJTalk と 辞書 と 音声 をダウンロード
hts engine API のページから、hts engine API をダウンロード
OpenJTalk と hts engine API を nmake でビルド
open_jtalk コマンドで 辞書 と 音声 と読み上げるテキストを指定すれば音声合成できる
MMD-Agent mei のページの Sample Script をダウンロードして mei の音声が入手できる

Open JTalk や hts engine API は Makefile.mak を使って nmake で簡単にビルドできたり、
mei の音声はそのまま使える .htsvoice版が配布されていたり、
少し前はこの辺りがめんどうだったらしいことが、今は簡単になっているらしい

ソフトウェアライセンス の調査中

FStap という自作ライブラリは

Json.NET	MITライセンス
HtmlAgilityPack	MS-PL
NDde	独自のライセンス
F# Data	Apache License, version 2.0

というライセンスのものを使っている。

Interop.ShdocVw.dll は自動生成されるものなので特にライセンス無しらしい

ProvidedTypes-head.fs というのをコピペしているけど、
F# Data に含まれるものだから Apache License, version 2.0 が適用されてると考えていいのかな・・

Apache License, version 2.0
http://vividcode.hatenablog.com/entry/license/android-app-with-apache-license-2.0

MS-PL
http://blogs.msdn.com/b/shintak/archive/2013/02/26/10397157.aspx

NDde
http://ndde.codeplex.com/license

ソフトウェアのアイコンにCreative Commons ライセンスを使う場合

略称の意味

BY	作者、作品名、ライセンス を表示する
SA	派生物には同じライセンスをつける
ND	派生物を作らない
NC	商用目的で使わない

ライセンスは

• CC BY
• CC BY-SA
• CC BY-ND
• CC BY-NC
• CC BY-NC-SA
• CC BY-NC-ND

の6種類がある

ソフトウェアに Creative Commons ライセンスのアイコンなどを入れる場合

http://piro.sakura.ne.jp/latest/blosxom/mozilla/xul/2008-04-02_license.htm
元のライセンスの制限を外したライセンスでは公開できない
アイコンに SA がついている場合、ソフトも同じライセンスで公開するしかなくなる

http://stackoverflow.com/questions/8893135/using-cc-by-sa-music-in-a-closed-source-game
その国の著作権法で派生物とは何かにより、
CC BY-SA のコンテンツを利用したソフトウェア を CC BY-SA で配布するべきか決まるらしい。
日本の場合、派生物 は 二次的著作物 と呼ばれていて、それに該当するものは
「著作物を翻訳し，編曲し，若しくは変形し，又は脚色し，映画化し，その他翻案することにより創作した著作物をいう」
らしい。アイコンをそのまま使ったソフトウェアはこれに該当せず、「複製権」「公衆送信権」などの利用は、CC BY-SA で承諾されていると解釈できるような気もする。

結論

CC BY じゃないと、ソフトウェアに使用するには相当な制約を受ける。

アイコンの場合、苦労して作ってわざわざ公開した人が、
なんとなく SA や ND を付けてしまうと、
それは多くのケースで他人が利用できないし、
BY だけでも、派生物も含めて公開した本人の著作物で、著作権表示はしてもらえる。

参考

Creative Commons ライセンスのつけ方
https://wiki.creativecommons.org/Marking_your_work_with_a_CC_license

Creative Commons ライセンスのついたものの使い方
https://wiki.creativecommons.org/Best_practices_for_attribution

Creative Commons ライセンスの選び方
https://creativecommons.org/choose/

各ライセンスの説明
https://creativecommons.org/licenses/

SIL OPEN FONT LICENSE

http://scripts.sil.org/cms/scripts/page.php?item_id=OFL_web

CSS でのフォント指定について調べてみた

いろいろなフォントを表示してみる

Verdana	この行は style="font-family:Verdana" というスタイルシート指定をしています。
Lucida Grande	この行は style="font-family:Lucida Grande" というスタイルシート指定をしています。
Hiragino Kaku Gothic ProN	この行は style="font-family:Hiragino Kaku Gothic ProN" というスタイルシート指定をしています。
Hiragino Mincho ProN	この行は style="font-family:Hiragino Mincho ProN" というスタイルシート指定をしています。
Meiryo	この行は style="font-family:Meiryo" というスタイルシート指定をしています。
sans-serif	この行は style="font-family:sans-serif" というスタイルシート指定をしています。
serif	この行は style="font-family:serif" というスタイルシート指定をしています。
Segoe UI	この行は style="font-family:Segoe UI" というスタイルシート指定をしています。
Arial	この行は style="font-family:Arial" というスタイルシート指定をしています。
Helvetica	この行は style="font-family:Helvetica" というスタイルシート指定をしています。
Yu Gothic	この行は style="font-family:Yu Gothic" というスタイルシート指定をしています。

結論

丸っこい英文フォント「Verdana」

Mac用のフォント「ヒラギノ角ゴ ProN」
Windows用のフォント「メイリオ」
ゴシック体の総称「sans-serif」

という順番で指定してみることにした。

この行は style="font-family: Verdana, 'Hiragino Kaku Gothic ProN', Meiryo, sans-serif;" というスタイルシート指定をしています。

SEOについて調べてみた titleタグ、description編

titleタグ

titleタグは検索結果のタイトルとして表示される
長さは 数単語、フレーズ 程度
ユーザー と 検索エンジン に分かるように
各ページごとに違うものを書く
簡潔な説明を書く

meta name="description"

descriptionタグは検索結果の説明として表示される、されない時もある

長さは1文、2文、段落 程度

具体的にページの内容が分かるような要約をする

各ページごとに違う説明を書いたほうが検索する側には分かりやすい

数千、数百万のページがある場合は、各ページの内容に従った要約を自動生成してもいい

参考文献:

http://static.googleusercontent.com/media/www.google.com/en//webmasters/docs/search-engine-optimization-starter-guide.pdf