OmniAICreator/Qiita-1.07M huggingface dataset:
Java Silverつまりどころ(その１)

# つまりどころ〜

　　
こんにちは。

Java Silverを勉強していて、「うーん」と個人的につまったことをまとめます。
ちなみにまだ受けてません(来年ほんきだす)

## チェック例外・非チェック例外

### ◆チェック例外

　特徴１：コンパイル時にエラーになる

　特徴２：該当のメソッドでtry-catchか、throwを行う必要あり

　特徴３：上位のメソッドも更にtry-catchか、throwしている必要あり

　　
・親クラスが **Exception**
　**IOException と SQLException** 
　⇒ コードに誤りがなくても発生する可能性あり！
　⇒ (なので)try-catch,throwを強制させるようにする

### ◆非チェック例外

　特徴１：コンパイル時にエラーにならない

　特徴２：try−catch、throwを行っても通らない（書けるけど）


　　
・親クラスが **Error**
　**OutOfMemoryError と NoClassDefFoundError**
　⇒ どこでなるかなんて、判断できない、難しい
　⇒ (なので)常になりうるので、素直にプログラム終了させたほうがいい！

　　
・親クラスが **RuntimeException**
　**NullPointerException と IndexOutOfBoundsException**
　⇒ コードを適切に記述していれば発生しない
　⇒ (なので)間違ってたら、プログラム終了させた方がいい！

　　　　
　　
アウトプットして、ちしきを固めていくぞ〜。
【gloops Advent Calendar 12/1】gloopsで検知しているDBアンチパターンまとめ

はじめまして。
社内での月間目標の取り組みとして「Advent Calendar 2016」に社内エンジニアみんなで参加しよう！
ということで開始しました。
これから約1か月の間、gloopsをよろしくお願いします！

[【gloops Advent Calendar 2016】](http://qiita.com/advent-calendar/2016/gloops)

「[株式会社gloops](http://gloops.com/)」では、RDBMSとしてMicrosoft SQL Serverを採用しています。

今回は、Advent Calendar第一弾ということで、gloopsで検知しているDBデータのアンチパターン検出方法をまとめてみました。

# アンチパターンを検出する

大きく分けて2種類の方法で実施しています。

## ①トリガーで検知
データに法則性があるものについて、それ以外のデータが入った場合、エラーとして検出する。
（マスタデータの作成時チェック等に使用しています）
【メリット】
・INSERT,UPDATEのタイミングで動くので、検知が早い。
【デメリット】
・テーブル単位に設定するので、メンテナンスが面倒


### 例）日付の逆転が無いかをチェックする

```sql
CREATE TRIGGER [dbo].[tri_hoge] 
ON [dbo].[hoge_master] FOR INSERT, UPDATE 
NOT FOR REPLICATION 
AS 
BEGIN 
  IF (SELECT COUNT(*) FROM inserted) > 0 
  BEGIN 
    IF (	
	(select 
		COUNT(*)
	from 
		inserted
	where 
		(from_date > to_date))
	 > 0
	 ) 
    BEGIN 
	select 'to_dateがfrom_dateよりも過去日になっています！'
	raiserror
	( 'to_dateがfrom_dateよりも過去日になっています！' , 16 , 1 ) 
	ROLLBACK TRANSACTION;
    END
  END
END

```

エラー時出力

```
to_dateがfrom_dateよりも過去日になっています！
メッセージ 50000、レベル 16、状態 1
```

## ②定期チェックでメール送信
プロジェクトをまたいで横断チェックするもの等に使用しています。
エラー検出以外にも不具合のレポートであったり、各KPIデータ等もこの機能を使って配信するようにしています。

### 例) メールを送信する

```sql
CREATE TABLE #tmp_hoge_table
(
--アンチパターンや集計データをいれるテーブルを定義
)

--複数のテータベースに一括で実行する為、sp_MSforeachdbで実行
exec sp_MSForEachDB    '

USE [?] 
IF DB_ID() > 4 and DB_NAME() not like ''hoge%'' --対象のスキーマが決まってれば設定
   BEGIN
DECLARE @table_name varchar(200)
DECLARE @column_name varchar(200)

DECLARE TABLE_LIST CURSOR STATIC FOR
SELECT
''[''+OBJECT_NAME(object_id)+'']'',''[''+name+'']''
from sys.columns where name =''hoge_column'' and OBJECT_NAME(object_id)!=''hoge_table'' --カラムやテーブルがあれば指定

--カーソルをオープンし、取得したテーブル全てについてチェック
OPEN TABLE_LIST

FETCH NEXT FROM TABLE_LIST INTO @table_name, @column_name

WHILE @@FETCH_STATUS = 0
BEGIN

--送信するデータを作成して一時テーブルにinsertする
EXEC(''insert into #tmp_hoge_table select・・・'')

FETCH NEXT FROM TABLE_LIST INTO @table_name, @column_name
END

CLOSE TABLE_LIST
DEALLOCATE TABLE_LIST


END'

DECLARE @tableHTML  NVARCHAR(MAX);
DECLARE @count  int;

--テーブルに入った内容をメールで送信(HTML形式)
SET @tableHTML =
    N'<H1>タイトル</H1>' +
    N'<table border="1">' +
    N'<tr style="background-color: #336699; color: #FFFFFF;">'+
    N'<th>カラム1</th><th>カラム2</th><th>カラム3</th><th>カラム4</th></tr>' +
    CAST ( ( SELECT 
                    td = column1, '',
                    td = column2, '',
                    td = column3, '',
                    td = column4, ''
              FROM #tmp_hoge_table with(nolock)
              ORDER BY column1,column2 DESC
              FOR XML PATH('tr'), TYPE 
    ) AS NVARCHAR(MAX)) +
    N'</table>' ;

SELECT @count = COUNT(*) FROM #tmp_hoge_table
IF @count>0
BEGIN
	EXEC msdb.dbo.sp_send_dbmail
		@profile_name = 'mail',
		@recipients = 'xxx@hoge.com',
		@from_address = 'xxx@hoge.com',
		@subject = 'メールタイトル',
		@body = @tableHTML,
		@body_format = 'HTML';
END

DROP TABLE #tmp_hoge_table
```

送信されるメール
![image](https://gloops.qiita.com/files/d8cf080e-52ed-3dc9-283e-32b073c80b79.png)

後は①,②を量産！！機械でできることはどんどん任せます。
以上のような方法で、gloopsではSQL Serverを用いて機械チェックや日々の業務を行っています。
トランザクションとは何か

## イントロダクション

これは@kumagiが一人でトランザクション技術に関する話をまとめていくアドベントカレンダーである。
トランザクション技術は多岐にわたり、複雑に絡み合い、DBの中で巨大な密結合コンポーネントを生み出している。そのためその中身を語るアドベントカレンダーも完全に順序付けて章立てしていくのは難しい。そのため様々な側面から一日に読めそうな文量の記事毎にまとめてアドベントカレンダーとするので、~~25日も話題が持つのかはさておき~~必ずしも記事の区切りは技術としての区切りの良さとは関係がない。
しかも初めの数日はトランザクションが実現する並行制御の理論的側面についての整理を淡々と述べるので退屈になること請け合いだけれど、可能な限り図解しながら説明を尽くすのでわからない所は容赦なくはてブやTwitterなどで書いて貰えたら適宜加筆修正をするつもり。

アドベントカレンダーを書くにあたって参考にする教科書は
Jim Gray著のTransaction Processing: concepts and techniques
[![transaction_processing.png](https://qiita-image-store.s3.amazonaws.com/0/1716/5515de88-e105-2b20-1ae9-1fb33c0877cc.png)
](https://www.amazon.co.jp/dp/B016W7HLX8?tag=kumagi-22)
Gerhard Weikum著の
[![transaction_information_systems.png](https://qiita-image-store.s3.amazonaws.com/0/1716/26baac73-7067-b08b-b65b-7c7bd4853ee0.png)
](https://www.amazon.co.jp/dp/B01253U1BC?tag=kumagi-22)

の2冊を教科書とする。どちらも鈍器のように分厚い本である。それと適宜論文などを参照していく。
教科書を読み下して噛み砕いて説明している部分はこの2冊を読んで理解している人には不要と思われる。

データベースの文脈においてトランザクションとは「1つ以上の手続きを1つの単位としてまとめた操作」を言う。

複数のユーザーが同一のデータに対して同時に操作を行った場合、何の対策もしなかった場合容易に値への更新が衝突し、狙い通りの値にならない事態に見舞われる。

![conflict.png](https://qiita-image-store.s3.amazonaws.com/0/1716/d8752f08-6c74-275b-0c63-4f43c1d3d384.png)

この図では2人のユーザーが同時にxに1を足す操作をしに来たのだから、最終的にxの値は0から2へと増加していて然るべきだが1になってしまった。更新が1つ消えてしまった事になる。もっと複雑なケースを考えていけばさらに複雑な状況は容易に起こりうる。そういった状況にならないようにするためには個々のユーザが全員一人ずつ順番に操作しに来てくれれば良いのだが、性能上の理由からそうも言っていられない。特にこれからはマルチコア・メニーコアの時代である。

## トランザクションのインタフェース

トランザクション操作を投入したら個々のトランザクションをうまく並列に実行してくれる装置を考える。その装置からはそれぞれのトランザクション操作は `Read(x)` `Write(x, value)` `Abort()` `Commit()` の操作の列でありその裏でどういう意図が有ってそれらの操作を行うかは見えていない。 例えば`Read(x) -> 10` をした後に `Write(y, 100)` が実行されたからといってその`x`と`y`の値にどういう関係があるかはトランザクション装置からは見えない。関係があるかも知れないし無いかも知れない。それらのルールを短くまとめると以下になる。

- ルール1: `Read`が読む値もしくは最終状態の値は「初期状態」もしくは「その値に対して一番最近`Write`された」一つの値である
- ルール2: `Write`が書き込むのは、それまでに自トランザクションが行ったすべての`Read`から算出されたと仮定した何らかの値である。

文章では直感的ではないが、図に書くと先ほどの絵はこのようになる。

![hconflict.png](https://qiita-image-store.s3.amazonaws.com/0/1716/fcd0dd29-879f-1001-a575-79f29e49baaf.png)

左端の緑色が値の初期状態。右端の紫色が値の最終状態を表す。この様な図を便宜的に**スケジュール図**と呼ぶ事にする（正しい名称は僕が知らないだけで別にあるかも知れない）二つのトランザクションが`Read`と`Write`をそれぞれ実行しているが、Writeが衝突しておりルール1の「一番最近`Write`された」という部分に違反するので許されない。

## Serializable

複数のトランザクションが入り乱れて複数の値を操作する場合、得られた結果が正しいものであるかという基準が必要となる。そこで **スケジュールの等価性**という考え方を導入する。例えば

Tx1: Read(x) Read(y) Write(z)
Tx2: Read(x) Write(y)
Tx3: Read(z) Write(z)
Tx4: Read(z) Write(x)

という4つのトランザクションが並行に実行され、以下のようなスケジュール図を描いたとする。
![compl.png](https://qiita-image-store.s3.amazonaws.com/0/1716/3544fb3b-6cbd-8d2c-300b-55af43522f33.png)

このように複数のトランザクションの操作が複雑に入り乱れた場合、これが望ましい実行状態であるのかについて議論する事は自明ではないが。結果として**「あたかも個々のトランザクションを1つずつ順番に行ったかのように実行」（以後逐次実行と呼ぶ）**できれば良いので、逐次実行と比較して何らかの基準で一致していればそのスケジュールは正しいと言えるという基準があると良さそう、というのが並行制御の出発点である。

4つのトランザクションが何らかの順番で1つずつ(_Serial_に)実行されていった場合、トランザクションは4つなので4!=24通りの実行パターンがある。仮に**適当な順**で並行に4トランザクションを実行したとして、そのどれかと同じ結果を残すことができるならそれは_Serial_な実行と見做しても実際差し支えない。このように**並行な**トランザクションの実行が**Serial**な実行と同じ結果を残せる場合**Serializable**であると言う。

明日はトランザクションの正しさとして基本となるFSRについて説明する。
Zabbixのバージョンとサポート期間（2016年版）

それでは、今年もZabbixのAdvent Calendarにチャレンジしましょう！

初日は、Zabbixのバージョンについておさらいしておきます。

Zabbixを利用されている方はたくさんいらっしゃると思うのですが、時々、もうサポートが終了してしまったバージョンを新規に利用開始しようとされているのをお見かけします。
そこで、Zabbixのバージョン番号はどのように付与されていて、現時点での最新バージョンは何であるのかを多くの方にご理解頂ければということで、最初のテーマとして取り上げさせていただきました。

特に、長期間利用されることを想定されている方にお読み頂ければと思います。


# Zabbixのバージョン番号について

Zabixのバージョン番号は、「3.0.5」のように3つの数字をピリオドで区切って表現されています。

バージョン番号の頭の部分の数字2の部分、例えば、バージョン番号が「3.0.5」であった場合の「3.0」の部分を、「メジャーバージョン」と呼んでいます。
同様に、バージョン番号の最後の数字の部分、例えば、バージョン番号が「3.0.5」であった場合の「5」の部分を、「マイナーバージョン」と呼んでいます。

メジャーバージョンの数字の二つ目が奇数のバージョン、例えば2.1や2.3は、開発版のバージョンですので、次のバージョンの新機能を試してみたい方のみご試用ください。

サポート期間中は、リリース後、不具合や脆弱性の問題があった場合は、マイナーバージョンを上げて修正されたバージョンがリリースされます。
同じバージョン番号に、パッチを適用して対策するのではなく、新しいバージョンとしてリリースされるわけです。
例えば、3.0.5は、メジャーバージョン3.0のリリースのうち、3.0.5よりも前に確認された不具合や脆弱性の問題に対応したバージョンです。3.0.0から数えれば6回目のリリースとなります。

そして、同じメジャーバージョン間は、データベースのスキーマを変更しないなど、極力互換性を維持した状態でバージョンアップされるので、修正されたモジュールに入れ替えるだけで、バージョンアップすることができます。

それに対して、メジャーバージョンのバージョンアップ、例えば「1.8」から「2.0」とか、「2.2」から「3.0」というようなバージョンアップに関しては、データベースの変更が含まれる場合があるので、バージョンアップに時間がかかることも想定した上でバージョンアップを計画して実施するようにしてください。

万が一を考慮するのであれば、マイナーバージョンアップであってもメジャーバージョンアップであっても、きちんとバックアップを取得した上でバージョンアップ作業を行うことをお勧めします。


# Zabbixのリリースバージョン

Zabbixのバージョン番号を説明したので、具体的にそれぞれのバージョン番号が付与されたリリースについて説明したいと思います。

Zabbixのリリースの形態には、以下の2つの形態があります。

- LTS(Long Term Support)リリース
- ポイントリリース

LTS(Long Term Support)リリースというのは、名前からも想像できるかもしれませんが、長期間のサポートが提供されるリリースバージョンです。
それに対して、ポイントリリースというのは、次のLTSに向けて、随時新機能の追加や機能改善を行うリリースバージョンになります。
ポイントリリースは、新機能が使えるのですが、サポート期間が短いことに注意が必要です。


# 現在のサポート状況

現在の各バージョンのサポート状況は以下の通りです。

|バージョン|種類|リリース日|フルサポート終了|リミテッドサポート終了|
|:---------|:---|:---------|:---------------|:---------------------|
|1.8|-|2009年12月07日|-|2014年11月 **(終了)**|
|2.0|LTS|2012年05月21日|2015年05月 **(終了)**|2017年05月|
|2.2|LTS|2013年11月12日|2017年08月|2019年08月|
|2.4|ポイント|2014年09月11日|2016年02月 **(終了)**|2016年03月 **(終了)**|
|3.0|LTS|2016年02月16日|2019年02月|2021年02月|
|3.2|ポイント|2016年09月14日|2017年03月|2017年04月|

**※** 3.2の期限は、3.4が2017年03月にリリースされた場合

フルサポート期間内であれば、基本的には細かなバグであっても修正されてリリースされますが、その期間を過ぎてしまったリミテッドサポート期間では、致命的なバグ対応とセキュリティフィックスしか提供されなくなります。

リミテッドサポート期間が終了してしまうと、公式には、バグの修正はされませんし、脆弱性の問題が発覚しても修正されたバージョンはリリースされないでしょう。


# 今後の予定

現時点の予定では、2017年3月頃に3.4というポイントリリース、2017年9月頃に4.0というLTSがリリース予定になっています。

あくまでも予定ですので、変更される可能性がありますが、3.4がリリースされたら、3.2はその1ヶ月後までのサポートになりますし、4.0がリリースされたら、3.4はその1ヶ月後までのサポートになります。

ポイントリリースと呼ばれる3.2や3.4を選択して利用される場合は、次のバージョンがリリースされたら、速やかにバージョンアップしないとサポートが終了してしまうということにご注意ください。

先ほどの表と同様に埋めるとしたら、以下のようになります。

|バージョン|種類|リリース|フルサポート終了|リミテッドサポート終了|
|:--------|:---|:--|:---------------|:---------------------|
|3.0|LTS|2016年02月16日|2019年02月|2021年02月|
|3.2|ポイント|2016年09月14日|2017年03月|2017年04月|
|3.4(予定)|ポイント|2017年03月|2017年09月|2017年10月|
|4.0(予定)|LTS|2017年09月|2020年09月|2023年09月|


詳細は、以下のURLに記載されています。

Zabbix サポート期間とリリースポリシー
http://www.zabbix.com/jp/life_cycle_and_release_policy

# 最後に

2016年12月1日時点では、長期間利用することを想定するのであれば、Zabbix 3.0をお勧めします。

どうしても新機能を使用したいということであれば、Zabbix 3.2をご利用ください。
ただし、サポート期間が短いので、次のバージョンがリリースされたら速やかにバージョンアップをしなければならないということを覚えておいてください。


Zabbix Advent Calendarの2日目は池田さんよろしくお願いします。
下請けCOBOLERから抜けるための技術

下請けCOBOLERとして生きていた頃のノウハウ Advent Calendar 2016の初日の記事です。

プログラミング知識とはあんまり関係ありませんが、生きるための知識として大切なので、また、自分のコボラー時代を成仏させるために書き記していきます。


## 現状に満足していますか？

生きていくためのノウハウということになってますが、まずは抜けることを考えていきましょう。

もし、あなたの上の会社がとても優しくて、単価も上昇していって、残業すればその分お金がもらえてそのお金があなたのところに帰ってきてて居心地が良くて一生食っていけそうならそれでもよいのですが
自分の場合は230時間ぐらいの労働を5年ぐらい続けて、単価も上がらず、残業代もでず、トイレもエレベーターも渋滞してネットにもつながらないし、一日の遅れも許さないようなスケジュールの中で生きていくのがとことんいやになってました。
勤怠を会社に送っても大丈夫ですか？の一言もないし、何年も放置されて自社への怨恨や自分の頑張りで中抜き業者が潤っていることを知り、抜けたいの一心しかありませんでした。

もし、似たような境遇の抜けたいという人は参考にしてみてください。

##次は考えずに抜けよう
自分の場合新人のころからCOBOL現場一本だったためほかの言語を全然知らず、正直この現場抜けたらもう生きていく方法がないんじゃないかと思ってました。
COBOL現場の恐ろしいところは他では活かせない業務知識ばかりが増えて、汎用的なスキルがまったく身につかないことだと思います。
なのでそこでの不安が大きかったです。
とはいえ、今はpythonでwebエンジニアっぽいことをやっているので、正直プログラムなんてどうにでもなります。
とにかく自分の命を守るためにも早めに抜けましょう

## 抜けるための技術

まずは、もうまじ無理となったら<font color="Salmon">会社に相談しましょう。</font>
まともな会社なら話を聞いてくれるはずです。
話も聞いてくれない会社ならそこに居続ける意味もないでしょう。
会社を辞めれば抜けれます。
余談ですが、実際会社辞めるといって抜けておきながら実は会社辞めてなかったという人もいました。
会社辞めるので抜けますという手段も大いにありだと思います。

会社との交渉ですが抜けたい納得してくれないこともあると思うので、例えばJavaの勉強してるからJava案件つけますとか何とかいって<font color="Salmon">別の仕事に入れることをアピールしたほうがいいかもしれません。</font>

今はオンラインでプログラム書いて勉強できるみたいなサイトもありますし、インターネットでの資料も豊富なので個人端末に環境構築するというコボラーにとってハードでありえん無理な作業はできなくてもいいです。JavaだろうがphpだろうがC#だろうがrubyだろうが　if文やfor文なんて似たようなものでわからないことは絶対にないです。

##抜けるのには半年かかると思え
自分の体験ですが、もしあなたがその現場で重宝されている場合、抜けるのに半年以上かかります。
そのうえ、雇い主は <font color="Salmon">「抜けたいなら、別の人間育てなきゃならないので育つまで待ってほしいし、代替要員が育つまでいてほしいし、その間の代替要員の単価の半分を払え」</font>とか平気で言ってきます。

もし、自分が無能で契約解除されたとき、次の仕事に就くのに勉強しなきゃいけないからその間給料の半分を契約してた会社が払えとかふつう言わないですよね？

パートナー企業とか言って誤魔化してはいますが下請けなんて立派な上下関係です。


##会社をどんどん休め、遅刻しろ
自分の場合、とにかくもうモチベがなかったのでモチベのなさをアピールするためにどんどん遅刻してました。
責任感が強い方だったので会社には行ってて休むことはあまりありませんでしたが。
とにかく周囲にあいつは仕事は単金以上にできるかもしれないが、もう遅刻ばっかりでどうにもならん奴だからいなくなってもやむなしって思われてしまうのも良いかもしれません。



もし、あなたがどうしても抜けられず、そこでしか生きていけないとするなら、このadventcalendarの続きをご覧になってください。
Opalのすすめ

この記事は[Opal Advent Calendar 2016](http://qiita.com/advent-calendar/2016/opal)の一日目の投稿として書いています。

[Opal](http://opalrb.org/)というのはRubyからJavaScriptへソースコードを変換するコンパイラです。
RubyをJavaScriptに！ずいぶんキワモノ感がありますね。私も最初はそう思っていました。
しかし実際に使ってみると、割とRubyとして書けるということが分かりました。
RubyとOpalの違いについては別稿にゆずるとして、わたしがなぜOpalをすすめるのかについて書こうと思います。

一言で言ってしまうと、言語としてJavaScriptが好きでないというのが一番の理由なのですが、それならばAltJSというのも世の中には沢山存在しています。
そういえば数多くあったAltJSたちは今どうしているのでしょうか?私もかつてはRubyistらしくCoffeeScriptなぞ嗜んでいました。
ところが、ES6(今はES2015、ES2016などと呼ばれていますね)の出現により駆逐されていってしまいましたね。
たしかにES6はJavaScriptの欠点を補い大分マシになりました。CoffeeScriptのようなシンプルなトランスパイラに対してなら十分置き換えるメリットはあるでしょう。実際にES6は大分CoffeeScriptを参考にしているようですし。
それでも互換性のためにJavaScriptとしての言語仕様を壊すわけにはいかないでしょう。falsyな値の扱いや`===`の存在とかJavaScriptのダメなところを挙げはじめたらいまだに暗澹たる気持ちにさせられます。

それでもES6の出現から多くのAltJSが捨てられていきました。本当にAltJSは滅びるのでしょうか?
私はそうは思いません。私のような気持ちでJavaScriptつらいと思っている人はたくさんいるはずです。現にTypeScriptはいまだに勢力を振るっています。

さて、そんな中Opalです。Opalの他のAltJSと違うところはRubyというすでに普及している言語で書けるということです。
特にRubyは気持ちよく書ける、手に馴染む言語としてそのファンは多いです。もちろん私もファンのひとりです。
AltJSはJavaScriptをもっとマシな言語で置き替えようというものですが、OpalはRubyで書きたいということのほうが大きいと思います。
実際に私はフロントエンドもRubyで書けると気持ちよく書けるという経験を何度もしました。
そのひとつの例が[Hyalite](https://github.com/youchan/hyalite)というgemです。HyaliteはReactライクなVirtual DOMの実装ですが、これを使うとさくさくとフロントエンドを書けます。React自体、フロントエンドを大分書きやすくしましたが、JSXという特殊な記法を導入しなければならなかったのはJavaScriptの表現力が足りていなかったせいだと思います。(HyaliteではRubyのままショートハンドなメソッドを用意しています。)

そういうわけで個人的にあるいはRubyistにとってOpalは良いものだと思っているのですが、実際に使うにはあまりにもアンダーグラウンドすぎるのではという気もします。しかし、海外ではすこしずつOpalが盛りあがりつつあるように思います。
私は明日[RubyConf Taiwan 2016](https://2016.rubyconf.tw/)でOpalに関するトークをしますが、RubyConf Taiwan 2016の2日目にも[David Chang](https://2016.rubyconf.tw/#David Chang)によるOpalに関するトークがあります。
どちらもReactライクなUIフレームワークだったり、Isomorphic programmingに関する話題なので被っている感はありますが、OpalでIsomorphic programmingするということに関していくつかのアイデアが実装されています。

* [Menilite](https://github.com/youchan/menilite)
* [Volt](https://github.com/voltrb/volt)
* [HyaperMesh](https://github.com/ruby-hyperloop/hyper-mesh)

それだけ盛りあがっているということでしょう。
他にもOpalで動くさまざまなライブラリがあります。[awesome-opal](https://github.com/fazibear/awesome-opal)にまとまっているので見るとよいでしょう。

また、最近GitResolveがOpalを採用したというニュース([Deciding to Build an Isomorphic Ruby App with Opal](https://blog.gitresolve.com/deciding-to-build-an-isomorphic-ruby-app-with-opal-206befe93c8f#.5o4i54jv0))が飛びこんできました。

このように海外では注目されつつあるOpalですが日本ではさっぱりです。
私はこのアドベントカレンダーでOpalのことをいろいろ紹介して普及活動をしようと思っています。
Rubyは日本人が作った言語で日本でコミュニティーが盛んで、私もそのコミュニティーが大好きでRubyistになりました。
願わくば、Opalも日本でコミュニティーが盛りあがってこの技術を日本人がリードしていけるようになれたら良いなと思います。
[iOS]プッシュ通知用の PEM ファイルを自動生成

タイトルの通りです．
地味に面倒なあの作業をShell Scriptで自動化します．

## <i class='fa fa-flag fa-lg'></i>&ensp;自動化する部分
今回は，Apple developer のサイトでごにょごにょして，
以下のファイルを用意できたところから自動化して，
最終的にサーバ担当に渡す *ck.pem* ファイルを作成します．

```php
aps.cer // ごにょごにょしてできたSSL証明書
app.p12 // CSR作った時にできる秘密鍵を書き出したもの
```

(「ごにょごにょ」の部分はたくさん記事があるので割愛します．)


## <i class='fa fa-frown-o fa-lg'></i>&ensp;本来やること

本来ここからやらなければならないこと

- *aps.cer* ファイルを *aps.pem* ファイルに変換

`openssl x509 -in aps.cer -inform der -out aps.pem`

- *app.p12* の秘密鍵を *app.pem* に変換

`openssl pkcs12 -nocerts -out app.pem -in app.p12`

- (Option) *app.pem* のパスワード解除

`openssl rsa -in app.pem -out app_pub.pem`

- *pem* 結合！！

`cat aps.pem app.pem > ck.pem` **or** `cat aps.pem app_pub.pem > ck.pem`

- 接続テスト

`openssl s_client -connect gateway.sandbox.push.apple.com:2195 -cert aps.pem -key app.pem`

はい，大変ですね．
コマンド忘れちゃいますね．

## <i class='fa fa-smile-o fa-lg'></i>&ensp;Let's 自動化！

みんな大好き Shell Script で自動化していきます．
今回はパスワードの入力周りに力を入れてみました．

毎回入力するようにしてもいいですが，正直面倒ですよね？
そこで今回は，Expectという機能を用いて入力を自動化します．
Expectについては[こちら](http://qiita.com/ine1127/items/cd6bc91174635016db9b)の記事で色々書かれていたので割愛します．

スクリプトの最初の方で秘密鍵のパスワードだけ入力するようにします．

```bash
printf "Enter Password:"
read password
```

あとのコマンドは，この情報を元に自動入力します．

```bash
expect -c "
log_user 0
set timeout 1
spawn openssl pkcs12 -nocerts -out $privateKeyPem -in $privateKey
expect \"Password:\"
send \"${password}\n\"
expect \"Mac verify error: invalid password?\" {
  exit 1
}
"
```

スクリプト全体についてはコードを見てもらったほうが早いので，説明は省きます(汗)

## <i class='fa fa-file-code-o fa-lg'></i>&ensp;完成したもの
[Gist](https://gist.github.com/krimpedance/6e0f52ad4a51eece7ac96115e3d65bb2)に置いてあります．

## <i class='fa fa-pencil fa-lg'></i>&ensp;使い方
基本的なコマンドは以下の通りです．

```bash
$ ./pushCertificate.sh aps.cer privateKey.p12
```

オプション

```
-p : 出力されるファイルにパスワードをつける
-d : 開発用証明書を使用する
     (テストサーバの切り替え用)
```

## <i class='fa fa-paper-plane fa-lg'></i>&ensp;未来の仕事
- エラー処理を綺麗にしたい．(助けて)

## <i class='fa fa-sun-o fa-lg'></i>&ensp;おわりに
今回は，iOSのプッシュ通知使用時の面倒な作業を自動化してみました．
Shell Script は勉強すればするほど色んなことができるなーという印象です．
(正直使い方が正しいのかわかりませんが．．)
今後もっと色々なことに使用していきたいと思います．

スクリプトについては自由に使用改変してください．
致命的なミス等ありましたら，ご教授していただけると幸いです．
ErgoDoxから捉え直す21世紀のキーボード観

この投稿は :calendar: [ErgoDox Advent Calendar 2016](http://qiita.com/advent-calendar/2016/ergodox) の 1日目の記事です。

----

Advent Calendar初日ということで導入的な話をします。

これからErgoDoxについて語っていくにあたり、使ったこと無い人向けにも一体どんなキーボードなのかというところから解説したいと思います。

<img src="https://qiita-image-store.s3.amazonaws.com/0/117743/ede6be66-c652-999a-e0f3-09e4769d5f03.jpeg" width="600">


## キー配列の違い
ErgoDoxはまず左右セパレート型というところが大きく目を引くキーボードですが、格子型配列という特徴もあります。

エルゴノミクスを謳っているキーボードではセパレートだったり格子配列だったりすることは多いのですが、だいたいどちらか一方ということが多いです。両方とも実現しているのがErgoDoxならではというところではないでしょうか。

### 普通の
<img src="https://qiita-image-store.s3.amazonaws.com/0/117743/08880f96-2355-f2b4-4a3a-9466f6e878ff.png" width="600">

### ErgoDox
<img src="https://qiita-image-store.s3.amazonaws.com/0/117743/1c224d4e-5eaa-d626-1c1c-10271e4469c6.png" width="600">

## キーボードって要はどんな形？

従来のキーボードはタイプライターの名残りで斜め配置になっていて逆台形型のレイアウトで分かりづらいのですが、ErgoDoxのような格子型で左右対称のキー配列だと素直に見えてくるものがあります。

それはつまり、

- アルファベット26文字
- 記号4文字

で構成される**左右5列ずつ×3段の計30文字分**がキーボードの核となるメインの文字エリアであって、他はそれをサポートするオマケだということです。

<img src="https://qiita-image-store.s3.amazonaws.com/0/117743/0641e8a5-e2dd-0b07-56f1-4ad31daeda42.jpeg" width="600">

*断舎離の例*


## 周辺キーはどう配置されるべきか

その文字エリアの周りを各種修飾キーなどが取り囲んでいます。

ErgoDoxを買って最初に戸惑うのは**「右端キーの割り当てが足りない！」**というところじゃないでしょうか。従来のキーボード配置に合わせて設定しようとするとどうしてもキーが足らず、右端に二列必要とさえ思うかもしれません。

でもそれは忘れましょう。 :innocent: 

ErgoDox（というかMaltronやKinesis型）のような格子型配列からしてみれば、従来のものは斜め配置で空いているところに詰め込んでる形なので、そのへんは好きに配置し直せばいいんだと思います。

## :tools: 文字配列をどうカスタムするか考えていきませんか

セパレート格子型配列の何が良いかというと、タッチタイピングの指運びが素直に分かりやすくなります。ホームポジションから指をまっすぐ上げればその通りの数字が打てますし、`６`や`Ｂ`など距離的に左右どちらで押すべきか曖昧なキーも無く、セパレートなので左右の手の領域分担がはっきりしてます。

また、ホームポジションからタイプする際の指運びの効率を考えやすくなります。

<img src="https://qiita-image-store.s3.amazonaws.com/0/117743/cfda8ce0-6134-d205-e8b7-40d44c93faeb.jpeg" width="600">

:keyboard:  [QWERTY, Dvorak, and Colemak : MechanicalKeyboards](https://www.reddit.com/r/MechanicalKeyboards/comments/3669rv/qwerty_dvorak_and_colemak/)


現在キーボードといえば100年以上も前からある`QWERTY`配列が標準で、普通はそのまま使ってて特に不自由は無いです。ただ、ErgoDoxを使うならそこもカスタマイズできてしまうわけです。`QWERTY`以外のキー配列としては`Dvorak`が有名ですが、その他にも`Colemak`など21世紀的な新しい配列もいろいろあったりします。

それらはいったいなぜ変える必要があるのか、どこがどう改善されるのかというのもErgoDoxだと捉えやすいところです。

ErgoDoxはファームウェアを書き換えて独自のキー配列を設定できるので、キーボードを持ち歩けばどこの環境でも自分の好きな配列でタイプすることができます。なので、

**自分の理想のカスタム文字配列を追求して、日夜思いを馳せてみるのもいいんじゃないでしょうか？**

次回からはキーボードの歴史を振り返りながら、実際にキー配列を検討していく記事を複数回に分けて書いていきたいと思います。
仮想化以前に構築した自宅インフラをDockerとOpen vSwtichで何とかする話

# 要求
Dockerを用いて、常用するインフラをいざという時にすぐ再展開できるようにしたい。
しかも、既存のインフラとの運用を考えると、L2で地続きになっていてほしい。

# 導入前提条件
DockerとOpenvSwitchが動くこと。特にovs-dockerコマンドが動けば良い。

# 何故Docker+OpenvSwitchを使うのか
SoftEtherVPNやDHCP等に代表される、L2の疎通ができたほうが望ましいサービス群を一発展開するのに最適だった。
Ipvlanや、Macvlanも悪くはないが、特にSoftEtherVPNを利用する場合は、
コンテナ内へL2のプロミスキャスポートを設定する必要があり、要件を満たさない。

また、今後開発環境として個人的に利用するとしても、L2疎通が取れたほうが、
ネットワーク系のスクリプトを書いたときに、遥かに検証が容易となる。

* SoftEtherVPN
    * ローカルブリッジに必要
    * 利用しない場合、やけに接続性が高いだけとなりあまり旨味がない
* DHCP
    * DHCP Relay Agentによる中継も可能
    * Docker内にそのような仕組みを置くのは可能な限り回避したい

# 何故シェルスクリプトで展開するのか
[OpenvSwitchのDockerプラグイン](https://github.com/gopher-net/docker-ovs-plugin)のIssueが一年前から放置されている等、メンテナンスが行き届いておらず、動作が怪しかったりしたため、docker-composeの利用を断念した。そもそも、このプラグインを利用したしても、docker-composeの文法的にL2の挙動を記述する内容が見当たらないので、シェルスクリプトで展開する決意をした。

また、今度はOpenStackNeutronをDockerで利用する方法もあるが、オーケストレーションは不要なので機能過剰と判断、利用しないことにした。

成果物と最低限の説明だけ欲しい人は、[Github:fono09/infra_portale](https://github.com/fono09/infra_portale)をご利用ください。

# 構成
コンテナは、既存のインフラから見ても、L2で完全に独立したホストに見えるように展開する。
OpenvSwtichと物理スイッチへの接続はL2でブリッジされている。

![Untitled Diagram.png](https://qiita-image-store.s3.amazonaws.com/0/95389/6373e9e7-18b3-490a-1bc2-dca491f9e1ad.png)

# 基本的な作り方

## ネットワーク周り
1. 既存の物理ネットワークへの出口にプロミスキャスポートを用意する
2. Open vSwtichで仮想ブリッジを作る
3. 仮想ブリッジとプロミスキャスポートを繋げて既存のネットワークとL2疎通を取る

以上をまとめて

```bash
ip link set $IFACE promisc on

ovs-vsctl add-br $VSWITCH_NAME
ovs-vsctl add-port $VSWITCH_NAME $IFACE
```

## 各々のサービスに関して
1. Dockerコンテナを立てる
    * Dockerの標準ネットワーク不使用
    * 勿論、設定ファイルやオプションで一発動作するように
2. Open vSwtichの仮想ブリッジと接続

以上をまとめて

```bash
docker run -d --name $CT_NAME --net=none -v foo:bar alice/great-service
ovs-docker add-port $VSWTICH_NAME $CT_IF0 $CT_NAME --ipaddress=$CT_ADDR --gateway=$CT_GATEWAY
```

## 撤収時はただ逆の操作をします
1. DockerのコンテナをOpen vSwtichの仮想ブリッジから外す
2. コンテナを消す
3. 仮想ブリッジの撤収

以上をまとめて

```bash
ovs-docker del-port $VSWTICH_NAME $CT_IF0 $CT_NAME
docker rm -f $CT_NAME
ovs-vsctl del-br $VSWTICH_NAME
```

# 詰まりやすいところ
## ホスト再起動への耐性

* OpenvSwitch
    * 独自にデータベースを持っており再起動に耐える
* ovs-docker
    * 動作中のdockerを名前で引いた後PIDで追跡する為、再起動でPIDが変更され仮想I/Fが孤立するとCTIDで再追跡する仕組みがない
* docker
    * CTIDは固定されている

以上のように、ovs-dockerに再起動耐性がないので、systemdのUnitファイルを作成し、登録。
システム終了時にきれいに撤収するようしている。

## SoftEtherVPN
L2疎通をコンテナへ取れるようにすること。出来ていない場合、接続したクライアントは、
SoftEtherVPNのSecureNATにぶら下がってしまい、ルーティングが厄介に。
そもそも、既存のインフラとL2の疎通を取るという要求を満たせない。今回は、2つの仮想I/Fを利用した。
vim
## Samba
``id (username)``コマンドで利用ユーザーのUIDを把握して、設定に流し込むこと。
これを設定しないと、ユーザーは自分のファイルにアクセスできない。

## DHCP
コンテナを立ち上げた後、仮想I/Fを後付するので、ネットワークの立ち上がりを全く待たないイメージを引いて動作不良に悩まされた。
ネットワークが上がってくるのが間に合わない場合もある。
今回使用したイメージに含まれているシェルスクリプト、[chakphanu/docker-kea:master/src/starter.sh](https://github.com/chakphanu/docker-kea/blob/master/src/starter.sh)にあるように、
ネットワークの立ち上がりを待つ動作はなんだかんだで重要なので、イメージ作成時に考慮すべきだとは思った。
ffmpegでmp4をdemuxしたりmuxしたり

ネクストスケープ配信事業本部のAdvent Calendar 2016の1日目って事で、この先のハードルを上げない為にも
低空飛行で始めます。

## ffmpeg

動画配信の仕事をしていれば、必ず一度は使う事になるだろうこのツール。
個人的には、アウトプットされるmp4に癖が有ったりして余り好きでは無いのですが、有用なツールであるのは確かなので
局地的に使用しています。

## mp4をdemux

最近は配信方法にMPEG-DASHが使われる事が多いですが、世に出ているMPEG-DASHのプレーヤーのほとんどはmuxされたmp4の
再生に対応していないと思います。（自分は見たことがありません）

一方で配信システム側に納品されるmp4が必ずdemuxされているとは限らないわけで・・・
その様な時は、受け取った側でdemuxして映像トラックのみのmp4と音声トラックのみのmp4に分離してあげる必要があります。
そんな時に使えるツールの一つが、ffmpegです。

・最初のトラックを分離

```
ffmpeg -i some_muxed.mp4 -map 0:0 -codec copy some_first_track.mp4
```
・2番目のトラックを分離

```
ffmpeg -i some_muxd.mp4 -map 0:1 -codec copy some_second_track.mp4
```
こんな感じでコマンド実行すればdemux出来ます。

-mapに設定する x:x は、

```
ffmpeg -i some_muxed.mp4
```
でファイル情報を出力した際の

```
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'some_muxed.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    creation_time   : 1970-01-01T00:00:00.000000Z
    encoder         : Lavf52.62.0
  Duration: 00:00:52.21, start: 0.000000, bitrate: 2240 kb/s
    Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 1920x1080, 2108 kb/s, 24 fps, 24 tbr, 24 tbn, 48
tbc (default)
    Metadata:
      creation_time   : 1970-01-01T00:00:00.000000Z
      handler_name    : VideoHandler
    Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 126 kb/s (default)
    Metadata:
      creation_time   : 1970-01-01T00:00:00.000000Z
      handler_name    : SoundHandler
```
Stream #x:xの部分を設定します。

## mp4をmux

余り使う機会は無いと思いますが、ffmpegを使ったmp4のmuxの方法も書いておきます。

コマンドとしては、

```
ffmpeg -i some_muxed_0.mp4 -i some_muxed_1.mp4 -map 0:0 -map 1:0 -codec copy new_muxed.mp4
```
some_muxed_0.mp4のStream #0:0とsome_muxed_1.mp4のStream #1:0をmuxする、という処理になります。

## さて、

此処まで書いておきながら、自分はmp4のdemuxにffmpegは使っていなかったりします。
コマンドが長かったりするせいも有るのですが、経験上、出来てくるmp4の互換性に若干の不安があるからだったりします。

自分が普段使っているのはmp4boxで、mp4boxだとコマンドは

```
mp4box -single 1 some_muxed.mp4 -out some_track_1.mp4
mp4box -single 2 some_muxed.mp4 -out some_track_2.mp4
```
みたいになります。-singleの後の数値は、mp4から抜き出すトラックのIDになります。
他にも別なアプローチで、

```
mp4box -rem 2 some_muxed.mp4 -out some_track_1.mp4
mp4box -rem 1 some_muxed.mp4 -out some_track_2.mp4
```
こんな風にdemuxすることも可能です。
これは指定されたトラックIDをmp4から削除する形でdemuxを実現しています。

mp4boxはmp4boxで、トラックIDを予め知っていないと色々と不便なのですが・・・
トラックIDは必ずしも1から始まるとは限りませんし、MPEG-2 TSから変換されたmp4だとPIDがそのままトラックIDに
なっていたりする場合もありますから。

## と言う事で
ゆるーく低空飛行で始まったネクストスケープ配信事業本部のAdvent Calendar 2016、この先しばらくよろしくお願いします。
自分は、ぽつぽつと空いている日にゆるーく小ネタを投下していく予定です。
TOMLは人に優しい設定ファイル言語

この記事は[SRA Advent Calendar 2016](http://qiita.com/advent-calendar/2016/sra)の1日目の記事です。

アプリケーションを作っていると「設定ファイル」を使うことが多いと思います。
そんな時、どのような形式で設定ファイルを記述してますか？
私は今までJavaによる開発が多かったのですが、Javaでは一時期「設定ファイルはXMLで」というのが大流行りでフレームワークの設定ファイルはXMLというのが当たり前でした。
Javaには `java.util.Properties` というクラスがありプロパティファイルをサポートする機能があるのですが、

1. 単純な `key=value` という形式のため配列やXMLのような階層構造を持った設定には向いていない
2. 日本語を設定するにはUnicode表記にするために `native2ascii` で変換したりしないといけない

などの理由により、決して使い勝手がいいものではありませんでした。
ただ、２についてはIDEのサポートにより `native2ascii` コマンドを叩く機会はほとんどなくなりましたし、Java9からはUTF-8での記述が可能になるようなので実際に気にすることはなさそうです。


## XML
先ほども述べたように、Javaでは一時期XMLによる設定ファイルが当たり前の世界になっていました。
XMLは階層構造になった設定もOKだし、一つのキーに複数の値を設定することもできます。
ParserやJavaオブジェクトへマッピングするライブラリを使えば実装も楽でした。
*XMLの例（一部）*

```xml
<streetFighter>
  <characters>
    <character>
      <name>リュウ</name>
      <country>Japan</country>
      <specialAttacks>
        <specialAttack>波動拳</specialAttack>
        <specialAttack>昇竜拳</specialAttack>
        <specialAttack>竜巻旋風脚</specialAttack>
      <specialAttacks>
    </character>
    <character>
      <name>ガイル</name>
      <country>USA</country>
      <specialAttacks>
        <specialAttack>ソニックブーム</specialAttack>
        <specialAttack>サマーソルトキック</specialAttack>
      <specialAttacks>
    </character>
  </characters>
</streetFighter>
```

色々と長所のあるXMLですが、

* 記述量が多い
* 可読性が良くない
という欠点があります。

## JSON
次に、JavaScriptの世界では昔からよく使われ、最近ではRESTなどのWebアプリでもよく使われるJSONを設定ファイルとして使ってみてはという話です。
JSONは名前（JavaScript Object Notation）の通りJavaScriptではオブジェクトそのものを記述することができる形式のため、JavaScriptとの相性は抜群です。
また、XML同様階層構造や配列も表記できるため設定ファイルとしてもすぐれていると言えます。
*JSONの例（一部）*

```json
{
  "streetFighter": {
    "characters": [
      {"name": "リュウ",
       "country": "Japan",
       "specialAttacks": ["波動拳", "昇竜拳", "竜巻旋風脚"]
      },
      {"name": "ガイル",
       "country": "USA",
       "specialAttacks": ["ソニックブーム", "サマーソルトキック"]
      }
    ]
  }
}
```

XMLに比べるとかなりマシですが、やはり可読性はあまり良くありませんし、キーをダブルクォーテーションで囲まないといけないのも面倒です。
そしてJSONには**コメントが書けない**という大きな欠点もあります。

## YAML
次はYAMLです。
YAMLはJSONと似ていますが、JSONよりも記述量が少ないので設定ファイルとして非常にすぐれたものになっています。
*YAMLの例（一部）*

```yaml
streetFighter:
  characters:
    - name: リュウ
      country: Japan
      specialAttacks:
        - 波動拳
        - 昇竜拳
        - 竜巻旋風脚
    - name: ガイル
      country: USA
      specialAttacks:
        - ソニックブーム
        - サマーソルトキック
```

また、ネストはスペースインデント（タブはNG）という特徴を持っており、コメントを記述することもできます。

## TOML
最後にTOMLです。
YAMLは設定ファイルを記述するのに非常にすぐれた言語ですが、TOMLはYAMLよりもシンプルな言語仕様で、可読性も高い言語です。
*TOMLの例（一部）*

```toml
[streetFighter]
[[streetFighter.characters]]
name = "リュウ"
country = "Japan"
specialAttacks = ["波動拳", "昇竜拳", "竜巻旋風脚"]
[[streetFighter.characters]]
name = "ガイル"
country = "USA"
specialAttacks = ["ソニックブーム", "サマーソルトキック"]

```

他の言語と違い、キーに上位のキーも記述するためネスト時の可読性がとても高くなります。
また、上位のキー（ここでは「streetFighter」）を必ずしも書く必要がなく、上記の例は実は

```toml
[[streetFighter.characters]]
name = "リュウ"
country = "Japan"
specialAttacks = ["波動拳", "昇竜拳", "竜巻旋風脚"]
[[streetFighter.characters]]
name = "ガイル"
country = "USA"
specialAttacks = ["ソニックブーム", "サマーソルトキック"]
```

だけでよくなります。
TOMLは言語仕様がシンプルなこともあり、各種言語のパーサもたくさんあります。
今後、システム開発で設定ファイルを作成する時にはTOMLも選択肢として検討してみてはどうでしょうか。
vte.cx １年間の振り返り 〜真のサーバレスアーキテクチャとは〜

みなさん、こんにちは。お元気ですか？
今年もadvent calendarの季節がやってきました。

去年はこんな感じ↓でvte.cxの使い方とか、技術的な話を中心に紹介したのですが、今年はポエムとかエモい話を中心に書いていきたいと思っていますので、よろしくお願いいたします。

http://qiita.com/advent-calendar/2015/vtecx

といっても、vte.cxのユーザ登録は現時点で18人。このカレンダーに参加してくれる方はいそうにないし、去年手伝ってくれたtakeyamaも、開発者の一人であるteradaも今年は忙しくて書くことができません。

なので、頑張って私一人で書こうと思っているのですが、はっきりいって一人で２５日分書ける気がしません。
多分、中途半端になってしまうと思いますので、あらかじめご容赦ください。m(_ _)m

ということで、今年の総括の話に移ります。

#今年はどんな年だったか

去年の年末にリリースしたvte.cxは、インターネットのユーザ登録こそ少なかったものの、弊社のビジネスには大きな貢献をもたらしてくれました。

弊社のビジネスは基本的に受託開発(請負)です。
そりゃ、将来的にはvte.cxの有料課金モデルだけで食っていけたらいいなとは思っていますが、そんなの夢の話です。

しかし、実は私たちはこれでビジネスをすると腹をくくっています。請負においても、vte.cx/reflexworksを採用しなければ受けないと決めています。

そこで、どうやって自分たちのサービスでビジネスするかですが、一番効率的な方法はドックフーディングだと思っています。つまり、自分たちのサービスを受託開発でも活用するのです。

そしてこの１年間、ドックフーディングをしてきた結果、以下の三つの価値を得ることができました。

 * 本番システムでも実用に耐えるほどの品質を高められた。
 * 利用者の視点で新たな課題を見つけられた。
 * 自分たちの仮説が正しいと確信できた。

(´▽｀＠)σ 　:relaxed:

一つめと二つめはいわゆる「穴が空いたバケツ問題」に関係します。

品質が悪く使い勝手が悪ければ、ユーザを獲得したところで継続的には利用してくれないでしょう。ユーザの獲得よりも逃げられる方が多ければ獲得費用をドブに捨てるようなものです。

今年は実案件において何十人月もかけてテストすることができましたので、相当な品質強化につながったとは思います。でもまだまだ改善の余地があるので、今後も継続して品質向上に努めていかなければなりません。

#フロントエンドの開発の延長でサーバサイドも開発

そして、三つ目ですが、これはvte.cxのキャッチフレーズでもある「サーバサイドのAPIもフロントエンジニアが自由に作れるようなBaaS」によって、本格的な業務アプリケーションが作れるかという仮説の証明です。業務アプリケーションというのは、Web系のいわゆるSoE(Systems of Engagement)だけでなく、基幹システムのSoR(Systems of Record)の領域を含む話です。

サーバサイドの実装は大変です。サーバの導入・設定、テーブルの設計、O/Rマッピングの設計等々、やるべきことがたくさんあります。

これらをすべて簡略化してくれるBaaSによって業務アプリケーションをつくることができるかどうか。もしできれば大きな工数削減を期待できます。

これはサーバレスであるといいたいのですが、世の中でサーバレスアーキテクチャといえば、つまりLambdaであるということは百も承知しています。
これは、AWSが火を点けたバズワードです。
ちなみに、このムーブメントに乗っかろうとして、一所懸命アピールしているBaaSな人たちがいますが、思いっきり外している感はありますね。スルーされているのを見ると自分までなんだか切なくなってきます。

でも、敢えて言いたい。
真のサーバレスとはBaaSであると。

弊社には開発メンバーが私を含めて３名しかおりませんが、効率良く開発できたのも、生産性の高いvte.cxを利用したからこそだと確信しています。

強調したいのは、サーバサイドJavaScriptも含めてフロントエンジニアが慣れ親しんだ開発環境ですべて開発できるということです。

vte.cxでは、HTMLやCSS、JavaScriptといったクライアントのコードと一緒に、サーバのコード(JavaScript)も同時にDeployできます。実体は/serverフォルダにJavaScriptファイルがあるだけです。それを、gulpコマンドでデプロイするか、Githubに対してpushするとCircleCIが自動的にデプロイします。（[詳しくは、CircleCIで楽チン開発](http://qiita.com/stakezaki/items/76dbbd7f13c7c4878276)を参照してください。）

つまり、フロントエンドの開発の延長でサーバサイドも開発できるということです。

RailsやPHPなどのサーバの言語は必要ありません。RDBさえもいりません。必要なのは、JavaScriptだけです！まさに、これこそがサーバレスです。

フロントエンドの開発はサーバサイドに比べて楽しいと個人的には思います。
SI業界からWeb業界に転職したいと思っている技術者は多いと聞きますが、vte.cxを使えばフロントエンド開発の楽しさの延長でサーバサイドも開発できます。重厚長大なSoEのシステム開発であっても、ウォーターフォール開発であっても問題なく使えます。もう転職する必要はありませんね。

#たった10人のユーザは1000人に匹敵する

あとは、インターネットの多くのユーザにも、vte.cxの素晴らしさやメリットを感じてもらいたい。
今はたったの18人のユーザですが、私は悲観していません。
それは、以下の理由からです。

>あなたの直接のネットワークから得られる顧客には偏りがあるかもしれないが、それとは異なる、自分から二次以上の隔たりのある１０人の顧客が得られた場合、あなたのプロダクトは何らかの課題を解決できているということを意味するし、それらの顧客は次の９９０人とほとんど同じ性質を持っているので、そうしたアーリーアダプターとコミュニケーションすることで、プロダクトの本当の性質や顧客の課題をより深く理解できる。
たった１０人からの売上は、ビール一杯分の売上にしかならないかもしれないが、それは成功の兆候であるといえる。１０人の顧客を捕まえよう。

[マーケティングを捨てよ、サポートへ出よう　事例から見るスタートアップ初期におけるユーザー獲得](http://www.slideshare.net/takaumada/throw-away-your-marketing-rally-in-the-sales-and-customer-support)

インターネットユーザを増やすためにはまだ超えなければならない壁は多いですが、着実に自分たちが目指す新しいビジネスの方向へと前進している実感はあります。:relaxed:

では、また明日
最初は better SVN でよい・・・　そんなふうに考えていた時期が俺にもありました

# 前置き

git を覚えたい（覚えないといけない）けどよくわからないとか、慣れてなくて今の状態が把握できなくなったりリポジトリ破壊したりしてしまうという人に。

# 覚えてほしいこと

箇条書きですいません。

- git はリモートリポジトリのデータをローカルに複製する
    - リモートの内容がローカルの作業ディレクトリに直接取り込まれるのではなく、作業ディレクトリとは **別に** リモートの複製を持っている
    - また、例えば origin/master が指しているものはローカルに複製されたリモートリポジトリの master ブランチの内容であり、リモートリポジトリそのものではない。
        - 意味をわからず `git pull` を使っていると、わかりづらいし事故りやすい
- git のブランチは「枝分かれしているそれぞれの枝」のことを指すのではなく、特定のコミットを指す単なる「ポインタ」である
    - HEAD は、現在作業中のローカルブランチへのポインタ
    - コミットすると、HEAD が指しているブランチのみが進む
- [追跡ブランチ](https://git-scm.com/book/ja/v2/Git-%E3%81%AE%E3%83%96%E3%83%A9%E3%83%B3%E3%83%81%E6%A9%9F%E8%83%BD-%E3%83%AA%E3%83%A2%E3%83%BC%E3%83%88%E3%83%96%E3%83%A9%E3%83%B3%E3%83%81#追跡ブランチ)という概念を覚える
    - これをちゃんと覚えるまで `git pull` は使わない
- 普段使っているコマンドの「本当の意味」「省略しない形」を理解しておく、機械的に覚えない
    - 挙げていくときりが無いですが、例えば
        - `git checkout -b branch_name origin/branch_name` と `git checkout branch_name` の違いと使い分けかたとか
        - `git push origin :branch_name` でなぜリモートブランチが削除されるのかとか

この辺のことを理解すると、事故率が減るんじゃないかなと思います。

# 後書き

タイトルは、内容と関係ありそうでなさそうですけど、要するに他の VCS とは違うところがあるのだからその違いを意識しないとちゃんと使えませんよ、ということです。
Gebってなんぞ？ #gebAdvent 

# はじめに

このエントリーは、[Geb Advent Calendar 2016](http://qiita.com/advent-calendar/2016/geb)の1日目の記事です。今日は初日ということで、そもそもGebってなんぞ？　という話を書きます。
Geb Advent Calendar、まだまだ空きがあるので、TIPsや使用感など、なんでもいいのでご興味があれば是非参加よろしくお願いします。

# Gebとは？

ブラウザのオートメーションツールです。
Seleniumをご存知であれば、そのラッパーライブラリーといったほうがしっくりくると思います。Groovyで実装されており、Groovyの機能を活かした簡潔な記述でコードを書くことができます。
とても大事なことですが、`げぶ`ではなく<strong>じぇぶ</strong>と読みます

## 公式サイト
これです。
http://www.gebish.org/
ここからドキュメントやソースコードへのリンクもあります。

## 百聞は一見にしかず

というわけで、Gebで書かれたコードを見てみます。先述のサイトに載っているサンプルコードから引用します(これ以後のサンプルコードも、公式サイトから引用しています)。
下記はログイン処理の操作をするスクリプトです。

```groovy
Browser.drive {
    go "http://myapp.com/login"
     
    assert $("h1").text() == "Please Login"
     
    $("form.login").with {
        username = "admin"
        password = "password"
        login().click()
    }
     
    assert $("h1").text() == "Admin Section"
}
```

上記の内容は
1. `http://myapp.com/login` というURLに遷移して
2. 遷移先のページの`h1`に、`Please Login`という文言があるかを確認して
3. ログインフォームにユーザー名とパスワードを入力してログインボタンをクリックして
4. 遷移先のページの`h1`に`Admin Section`という文言があるかを確認する

という処理をしています。

Seleniumでテストの自動化にトライしたことがある方はわかるかもしれませんが、Seleniumでやろうとすると、これらの処理は意外とコードを書かなければなりません。
上記のサンプルだと出てきていませんが、もう少し複雑になると、ページや特定のエレメントのwaitなどを考える必要が出たりするので、記述も複雑になりがちです。

# Gebの良いところ

Gebでは、複雑になりがちなコードを簡潔に書くことができます。ざっとハイライトしていきますね。

## jQueryっぽいAPI

Seleniumを使っていて辛い事の一つは、エレメントの取得方法が冗長なことです。
Gebは下記のように、jQuery「っぽい」APIを用意しているので、エレメントの取得は楽になります。
例えばこんな感じ

```groovy
$("div.some-class p:first[title='something']")
$("h1", text: "All about Geb")
$("div").find(".b")
```

ここではさわりだけですが、もう少し詳しく見たい方は下記が参考になると思います。
http://qiita.com/itagakishintaro/items/1fa06904bd0a6de73ee2

## ページオブジェクトを標準装備

Seleniumのコードをメンテナンスしやすくする手法として、ページオブジェクトパターンというのがあります。
日本語だと下記のサイトにわかりやすくまとまっています。
http://softwaretest.jp/labo/tech/labo-292/

Seleniumですと、例えばJavaだと自分でページオブジェクトを表現するベースクラスを作って、それをここのページで継承して、ということが発生しますが、Gebは標準でページオブジェクトを装備しています。
そのため、自分でベースになるクラスを作る必要がありません。さらに、Groovyを活かして、よりページらしい表現ができるようになります。（例えば、ページのコンテンツになるものは文字どおり`content`という名のクロージャー内に記述するなど）

サンプルは下記の通りです。

```groovy
class LoginPage extends Page {
    static url = "http://myapp.com/login"
    static at = { heading.text() == "Please Login" }
    static content = {
        heading { $("h1") }
        loginForm { $("form.login") }
        loginButton(to: AdminPage) { loginForm.login() }
    }
}
```

最初は記法に戸惑うかもしれませんが、慣れると直感的で楽です。

## waitが楽

ブラウザ操作の自動化で、最も悩ましいのがwaitです。特にAJAXによる非同期なロードやアニメーションが普通になってしまった今では、waitが適切に入っていないととても不安定な自動化スクリプトが出来上がってしまいます。
そこでwaitの処理を描くわけですが、こちらもSeleniumだと少し冗長です。Gebだと下記の通り

```groovy
waitFor { 
    $("p.status").text() == "Asynchronous operation complete!"
}
```

`waitFor`でくくるだけ。簡単ですね。
上記のサンプルでは、エレメントのテキストが`Asynchronous operation complete!`となるのを待ってましたが、他にもエレメントの存在や、表示・非表示など、様々なものを条件にwaitをかけることができます。

# まとめ
Gebは簡潔な記述がウリです。特にjQueryっぽいAPIの提供や、ページオブジェクトの標準装備、waitの記述の簡潔さでブラウザの自動化を楽にしています。
まだ試したことがない人は是非この機会に試してみてください！

# 明日のエントリー
http://qiita.com/posaunehm さんのターンです！ Geb ＋ Spock な話 わくわく！
初心者向けrailsでの開発でちょっとした生産性を上げるtips

rails始めた頃から知っていたら幸せだったな的な、tipsをまとめてみました。
有名どころのgemでもediterの設定してちゃんと使っている人意外といないと思うので、
お役に立てたらうれしいです。

## コンソールを使いやすく
gem "interactive_editor"
REPL上でediterを呼び出して、書き込み実行できる。
そのSession内であれば前書いたものが残る。
コンソールで直接書くより、シンタックスやスニペットが使えて便利
![pryvim.gif](https://qiita-image-store.s3.amazonaws.com/0/31015/7a7c29de-5097-64c8-b2ec-8f0807cc90b6.gif)

gem "pry-rails"
デバッグ用のgemでpryは有名ですが、`.pryrc`設定しておくとちょい楽になります。
↓公開されているやつを参考に、コンソールで簡単にベンチマーク図ったり、コマンドの省略系を定義しておいたり、
コンソールで楽する設定を詰めておきましょう。

```ruby:.pryrc
# 例)
alias :r :require
alias :l :load
def bm(&block)
  Benchmark.measure &block
end
```

[公開されている.pryrcその１](https://github.com/JuanitoFatas/dotpryrc)
[公開されている.pryrcその2](https://github.com/pjg/dotfiles/blob/master/.pryrc)
[公開されている.pryrcその3](https://gist.github.com/stasbovanenko/3073389)


## エラー画面をカスタマイズ（有名どころ）
gem "better_errors"
gem "binding_of_caller"
![image](https://qiita-image-store.s3.amazonaws.com/0/31015/eb48e12e-c4cf-7b28-884c-b2e044e229d1.png)

```config/initializers/better_errors.rb
# ↓人それぞれ違うと思うので、グローバルのgitignoreに登録しとくといい
BetterErrors.editor = :mvim if defined? BetterErrors
```
![image](https://qiita-image-store.s3.amazonaws.com/0/31015/76cc00b5-e7af-cd51-9f02-0680af0ae2e8.png)

## viewの開発をちょっと楽に
gem "xray-rails"
cmd+shift+xでviewのパーシャルなどを可視化
クリックすることでそのファイルをエディタで開ける
![image](https://qiita-image-store.s3.amazonaws.com/0/31015/cf7893ca-a06a-bcbd-6bfc-25fb8971cbe3.png)
![image](https://qiita-image-store.s3.amazonaws.com/0/31015/7d485f66-b716-48ec-ef70-95fa0846a230.png)

## routesの確認を楽に
一旦テキストに吐き出してしまって、catでpecoに食わせればインタラクティブに絞り込みができて楽。
textに食わせておけばやり直しても早い。

```bash
rake routes > routes.text
cat routes.text | peco
```
![comand.gif](https://qiita-image-store.s3.amazonaws.com/0/31015/ff78fe14-974f-5a3b-006d-b0e34c60300d.gif)



## 各種よく使うコマンドを登録して呼び出し、編集できる仕組みを整えとくと楽
よく使うコマンドをテキストに書いておいて、pecoなどで選択し、
shellのedit機能で編集して実行などの仕組みを入れておくと楽。
↓zshでの設定

```zsh:.zshrc
# コンソールにある文字列を編集######
autoload -Uz edit-command-line
zle -N edit-command-line
bindkey '^x' edit-command-line
#############################

# pecoで選択したonelinerコマンドを表示########
# ↓適当なファイル(.fav_comand)などに書かれたものを選択できる
function peco-search-oneliner() {
  BUFFER=$(cat ~/.fav_command | sort | peco | awk -F"\t" '{print $1}')
  zle clear-screen
  zle beginning-of-line
}
zle -N peco-search-oneliner
bindkey "^g" peco-search-oneliner
########################################
```
![comand.gif](https://qiita-image-store.s3.amazonaws.com/0/31015/59ddea23-4d95-c651-7b2c-7b5300fb0f3c.gif)
TFUG（TensorFlow User Group）のご紹介

# はじめに

これは、TensorFlow Advent Calendarの1日目の記事です。

リリース直後の時期だったとはいえ、昨年の[TensorFlow Advent Canlendar](http://qiita.com/advent-calendar/2015/tensorflow)への参加状況が壊滅的だったことに比べると今年はTensorFlowは一気に盛り上がり始めた感があるのではないでしょうか？

タイムリーなものとしてV0.12において、[Windowsの正式サポート](https://developers.googleblog.com/2016/11/tensorflow-0-12-adds-support-for-windows.html)が入ったようです。その話を中心に[release note](https://github.com/tensorflow/tensorflow/releases)の内容を見ていってもけっこう面白いかと思いましたが~~時間がないよーなので~~、きっと後半の誰かが取り上げるだろうということで、TensroFlow自体のあれやこれやのお話を含めて他の方にお任せし、本記事では、TFUG（TensorFlow User Group）の紹介をしたいと思います。

TensorFlowとか機械学習はなんぞや、という方は適当にググっていただくか、下記の資料でも見てください。雰囲気はつかめると思います。

<img width="971" alt="DevFest.png" src="https://qiita-image-store.s3.amazonaws.com/0/1046/f815f4df-cf84-fe71-70f2-5fc8b56b0e2b.png">
[エンジニアとして知っておくと幸せになれる（かもしれない）機械学習とTensorFlowのこと](https://speakerdeck.com/rindai87/talk-about-ml-and-dl-for-happy-engineers-life)


# TensorFlow User Group(TFUG)のご紹介

## TFUGとは？
去る10/7に立ち上がったTensorFlowのユーザーグループです。色々あって発起人兼幹事をさせて頂いており、各所から温かい協力をいただきつつ、ゆるゆると運営させていただいています。やるからには、成功している[日本Androidの会](http://www.android-group.jp/)や[GCPUG](https://gcpug.jp/)みたいになるといいなぁと妄想しております。

## TFUG立ち上げのきっかけ的なもの
仕事柄、「ビッグデータブーム」「データサイエンティストブーム」を横で眺めていて何とも悲しい（というか虚しい）気持ちになっており、
今まさに起きつつある「人工知能ブーム」「深層学習ブーム」が二の轍を踏まないように少しでも何らかの形で貢献したいな、
と思っている所に、立ち上げませんか？とお声がけいただきました。ありがとうございます。

## TFUGのコンセプト
最初は何も考えていませんでしたが、関わっていただく方が徐々に増えてきている中で必要だな、と思い始めていまして、「内輪感を出しすぎず、初心者の方でも、気軽に難しげな深層学習とか機械学習の話をわいわいやりたい」。これにつきますね。

ギークでアカデミックな方は勝手に楽しんでくれると思うので、そういう方に適宜降臨いただきながら、これからAI的な何かをやりたいんだー、ちょっとやってみたけど困ってるんだー、という方にうまく利用頂けるようなグループにしていきたいなと思っています。

## 直近のミートアップ情報とその補足
- 10/12に[TFUG #1](https://tfug-tokyo.connpass.com/event/41273/)の開催しました
- 11/30に[NN論文を肴に酒を飲む会 #1](https://tfug-tokyo.connpass.com/event/44776/)を開催しました
- 12/7に[TFUG for Biz #1](https://tfug-tokyo.connpass.com/event/44318/)を開催します
- 12/3に[TFUG #2](https://tfug-tokyo.connpass.com/event/45950/)を開催します
- 12/20に[ディープラーニング・ハンズオン @ Google](https://tfug-tokyo.connpass.com/event/45679/)を開催します

という感じで分かって頂けるかもしれませんが

- いわゆる通常のミートアップである "**TFUG**"
- 通常のミートアップとは切り口を変えて、主にどうやったらTensorFlowをビジネスに活用できるかの情報交換の場にしたい"**TFUG for Biz**"
- この領域は動きが早いので論文を肴にワイワイやりましょうの"**NN論文を肴に〜**"
- 裾野を広げるための"**ハンズオン**"

という感じで、いくつかの切り口を作ってイベントを開催してみています。まだ開催していないイベントもありますが、今のところ参加希望者多数、な感じで、改めてこの領域の注目度の高さを感じているところです。

## やりたいこと
この領域はTensorFlow単体で簡潔していないことが多くて、やりたい事がたくさんあります。

GPU/FPGAとか、Android/iOSへのモデルの組み込みとか、分散学習とか、高レベルなインターフェースやAPIの話題とか、機械学習システムの開発手法の話とか、そもそも深層学習の数学的な話など、まあ色々あります。

1人では手がまわらないので、分科会的にどんどん何かやりましょうな人たちが立ち上がって来ると非常に良いな、と思っています。誰か手を挙げてください。どうぞどうぞと分科会をお任せしていきますよ。

## 終わりに
ロゴとか、サイトとか、運営体制とか色々不安定な状態ですが、来年以降も頑張って活動していきたいと思いますので、私にポジティブなフィードバックによるエネルギー注入をお願いします^^
Nimの簡単な紹介


Nim Advent Calendar 1日目の記事です。  
Nimは日本ではマイナーな言語だと思うので、まずは簡単な言語の紹介から書きます。

# Nimとは

Nimは、Pythonのような生産性と、Cのような実行速度を併せ持つことを目標とした言語です。  
既にベンチマークでも高速でコードの短さでも優秀という結果も出ています。 参考(<https://github.com/kostya/benchmarks>)  
他にも、RubyのようなDSL、Lispのような拡張性といった要素も重視しており、非常に自由度の高い言語になっています。

構文としてはPythonのようなインデントでブロックを作るタイプで、少々Rubyっぽいところもあったりします。

Nimの基本的な機能として以下があります。

- 静的型付
- 型推論
- GC
- template/macro
- Generics

Nimの他の言語にあまり見られない特徴的な機能としては以下があります。

- 項書き換えマクロ
- AST based overloading
- not nil
- ユーザー定義演算子
- firstclass iterator

他にも、C#やGo、C++から取り入れた機能などもあります。

- async/await
- defer
- template

利便性を追求するため、標準ライブラリが充実していたり、標準のパッケージマネージャ兼ビルドシステムとしてnimbleというものがあります。

Nimはシステムプログラミングとしての用途を重視しており、明確にC++を意識しています。  
システムプログラミング言語ではありますが、ソフトリアルタイム向けGCが標準搭載されており、GCの制御も可能となっています。

# 2016年のNim

2016年のNim関連の出来事を公式のニュースを参考に列挙します。

- Version 0.13.0 ~ 0.15.2 のリリース
- Bountysourceでの募金開始
- Nimコミュニティアンケートの実施
- 書籍 Nim in Action の発売決定

# まとめ

Nimは2016年でようやくバージョン1.0に向けた道が見えてきたように見えます。  
解説書籍であるNim in Actionの発売決定など、めでたいニュースも多く、今後も期待していきたいです。
Delphi で Android TV 開発 ～導入編～

これは [Delphi Advent Calendar](http://qiita.com/advent-calendar/2016/delphi) １日目の記事です。

# Android TV プロローグ
先日テレビを買いました！

> TV 名前は Bravia X9350D
> ごく普通の僕は、ごく普通にお金を払い、ごく普通に購入しました
> でもただひとつ違っていたのは、このテレビは AndroidTV だったのです！

ということで、Delphi で Android TV アプリを作る方法を紹介します。
（とはいえ、すごく普通の事です…）

#Android TV とは
Android 5.0 をベースにした TV 用の OS です。
TV とは別の世界に Android TV があるわけではなく、**Android TV の上**に全ての機能が実装されています。  

開発したのは Google ですが、開発パートナーとして Sony がテレビ部分に関してアドバイスをしたとのこと…

また、SoC については台湾 MediaTek が Google と共同で開発したそうです。

> [MediaTek、Android TV向けSoCとAndroid Wear向けSoCを発表](http://itpro.nikkeibp.co.jp/atcl/news/15/010800085/?rt=nocnt)

##メリット
* **Google Play からアプリをダウンロードして使える**   
これが最大にして唯一のメリットです。  
開発者目線でいえば、Android 開発のノウハウが使えるので、それは大きなメリットです。  
ただし、Android そのままではありません。  
違いについては後述します。

##デメリット
* **落ちる**  
Android なので普通に落ちます。むしろ落ちまくりです。  
テレビを観る事すら、ままなりません！  
* **寿命**  
Android ベースの OS なので常にバージョンアップしていく必要があります（セキュリティとかの問題で）。  
しかし、実際問題、大体２～３年前の端末は切り捨てられていきます。  
つまり、今までのテレビのように何年も何十年も使えるわけではありません！

##Android との違い
TV 用のため、いくつか変更されています。

###アプリに審査がある
リビングに置かれるという性質からか、Android TV 用のアプリは審査があります。
審査を通らないと Google Play に公開できません。

###ハードウェアが違う
テレビなので基本的にタッチパネルではないため直接的に UI を操作できず、操作はもっぱらリモコンのクリックになります。
そのため、UI のイベントは OnTouch ではなく OnClick に反応する様にします。
また、カメラやセンサーなどのテレビとして必要の無い機能もありません。
これらに留意して UI を構築しなければなりません。

###暗黙的 Intent があまり使えない
テレビなので基本的にテレビに要らない機能がありません。
たとえば、メーラーやブラウザがありません（※ただし Bravia には Opera が載っています）。
なので、Intent を使った呼び出しが失敗しうる事を考えながらコードを組まなければなりません。


#Android TV の開発
##開発者モード
Android TV のアプリを開発するにあたって、通常の Android と同じように開発者向けオプションを有効にせねばなりません。
これは非常に普通な手順です。

![qiita1.png](https://qiita-image-store.s3.amazonaws.com/0/12977/e84796b8-8629-2861-dc13-a3f19963c310.png)

##IPの取得
テレビとの接続には WiFi や有線 LAN を使うので IP を調べます。

![qiita2.png](https://qiita-image-store.s3.amazonaws.com/0/12977/043cb779-725b-9f9e-c4d1-dd0c6086c5e4.png)

##接続
ここまで準備ができたら adb を使って AndroidTV に接続します。
次のように adb connect を使います。

```bat
; xxx.xxx.xxx.xxx は TV の IP
adb connect xxx.xxx.xxx.xxx:5555
```

ポート番号 5555 は adb のデフォルトのポート番号です。

これで接続に成功するとあとは通常の adb に対する操作がすべて利用可能になります。
たとえば adb logcat なども普通に動作します。

#Delphi で開発

adb over WiFi で Android TV に繋がったら Delphi を起動してみます。
すると！
プロジェクトマネージャに、Android TV のデバイスが表示されているはずです。

![qiita3.png](https://qiita-image-store.s3.amazonaws.com/0/12977/56c203a7-0e68-d236-898e-a1a19e6a264d.png)


あとは、いつも通りプロジェクトをビルドして実行すると…

![qiita4.png](https://qiita-image-store.s3.amazonaws.com/0/12977/d760e3b3-e9ab-b416-219f-e662eb95e9c6.png)

無事動作しました！！！

ということで、導入編はここまで！！
サービス開発は9割が失敗する - 5つの診断パターンからみるサービス設計がうまくなるコツ（導入編）

こんにちは！

[株式会社LITALICO](http://litalico.co.jp/) CTOの岸田崇志です。
記念すべき『[LITALICO Advent Calendar 2016](http://qiita.com/advent-calendar/2016/litalico)』1日目の記事となります！
サービスを組み立てる話をしたいと思います。

# 1.はじめに
サービスを立ち上げの現場では戸惑うことが多いと思います。
特に初めての場合ははなおさらです。
サービスの企画を初めてやるときに、

- どうやっていいかわからない。
- やってみたものの何が正解かわからない。
- 正しい方向に向かっているのかわからない。

といったことはありませんか？

サービス開発で失敗する場合は、ひとつひとつの施策がうんぬんというよりも全体設計や進め方が原因になっているケースが多いです。
どの組織でも大体ハマるパターンは決まっているため、症状別にまとめてみました。

## タイプ別にみる失敗パターン
こんな経験や課題はありませんか？
あなたのチームはどのタイプですか？

* **行き当たりばったり症候群**
    - サービス設計を場当たり的に進めてきたため、うまくいかないときに何が悪かったかわからない
    - サービスをいくつか作っているが、どれも鳴かず飛ばずだ
    - 日々とても忙しいが、振り返ると何をやったか思い出せない
* **「世界取ってやるゼ！」症候群**
    - やっているうちに計画が壮大になり、収集がつかない
    - いきなり大きなサービスを作ろうとして、結果凡庸なものになってしまった
    - 焦るがゆえに機能を盛り込みすぎた
* **「俺とんでもないバケモノを生み出してしまったゼ！」症候群**
    - 他サービスを「参考」にしすぎて、キメラみたいなツギハギサービスになった
    - 参考にしたものの見た目は似ているが、むしろ本家より使いにくい **「劣化コピー」**になっている
* **サグラダ・ファミリア症候群**
    - 今の組織の開発力では開発が不可能なものを対象としている。
    - 開発スケジュールを見積もれていない
    - また、開発はできそうだが壮大な時間がかかりそう
* **自分探し症候群**
    - 作っているうちに何を作りたいか見失ってしまった
    - チームでコンセンサスをとることに時間がかかる
* **「事件は会議室で起きてるんじゃない！現場で起きてるんだ！」症候群**
    - ミーティングがやたらめったら多い
    - 仕様書やプレゼン資料がやたらめったら多い

上記にような症状に誰しも心当たりがある方もあると思います。

サービスの企画において知っておくべきルールがあります。
それを説明していきます。

## [ 本編はこちら >> 2.基本を理解しよう！ ](http://asagao.hatenablog.jp/draft/smgNO8OLeEBm6eS5sEGK2ThUkR0#2基本を理解しよう) 

※ 外部ブログに記載したのでAdventCalenadar用に一部転載しております。
[Symfony3]Symfony Best Practice 翻訳してみた

Symfony Advent Calendar 2016 第一日目の記事です。 http://qiita.com/advent-calendar/2016/symfony


## 経緯
- [Symfony Meetup #15](http://symfony.connpass.com/event/42799/)にて、Symfony Best Practiceがお題に上がったものの、Best Practiceをちゃんと読んだことがなかったので、読んでみたかった。
- [Symfonyユーザー会](http://docs.symfony.gr.jp/symfony2/best_practices/)の翻訳はSymfony2ベースだったのと、Symfony3の[日本語wiki](http://symdoc.kwalk.jp/)にも翻訳がなかった。
- せっかくなので、Symfony3で変更になった部分の確認がてら訳してみようと思い立った。

### [翻訳元](http://symfony.com/doc/current/best_practices/index.html)
2016/10/23時点のものを訳しました。

## 翻訳記事と各章の概要
### [第1章](http://hanahirodev.hatenablog.com/entry/20161028/1477665006)
Best Practiceの目的、対象読者、その精神についての説明です。
"Best"と銘打っていますが、「必ずしも従う必要はない」、「今動いてるアプリを無理にリファクタリングしてまで、適用させなくても良い」としているのが印象的でした。
また、「Symfony初心者でもわかるように/混乱しないように」するために配慮した書き方も意識されています。Symfonyに初めて触れる人も、一読していただければSymfonyの精神やコンセプトに触れることができます。

### [第2章](http://hanahirodev.hatenablog.com/entry/20161029/1477749264)
プロジェクトの作り方について。
いままでcomposerでインストールしてたけど、symfonyのインストーラー使ってねという話。
あとは、基本的なディレクトリ構成の説明。以降demoアプリベースで話が進むので、demoアプリと照らし合わせながら確認すると理解が深まります。

### [第3章](http://hanahirodev.hatenablog.com/entry/20161030/1477823413)
各種設定ファイルについて。`parameters.yml `と`config.yml `の使い分けと、設定をymlにもつか、アプリのコード内にもつかの考え方の違いなどが説明されます。

### [第4章](http://hanahirodev.hatenablog.com/entry/20161031/1477915910)
AppBundle内のディレクトリ構成の考え方とサービスクラスについて。基本的にはAppBundleにすべてまとめましょうと説明されます。

### [第5章](http://hanahirodev.hatenablog.com/entry/20161101/1478005770)
コントローラーについて。使った方がいい/良くないアノテーション、ParamConverter、EventDispatcherの紹介。この章で最も重要なのは、Symfonyの哲学(「thin controller and fat models」)が紹介されていること。

### [第6章](http://hanahirodev.hatenablog.com/entry/20161102/1478091790)
テンプレートについて。「テンプレートは`app/Resources`配下にすべてまとめましょう」と紹介されます。Twigエクステンションの作り方についても紹介されています。

### [第7章](http://hanahirodev.hatenablog.com/entry/20161103/1478176681)
フォームについて。FormTypeを共有するためのポイント(FormType内にボタンを書かない)、関心事の分離について紹介されています。

5~7章はSymfonyをつかってアプリを開発する人は全員読んだほうがいいと思います。

### [第8章](http://hanahirodev.hatenablog.com/entry/20161104/1478262896)
国際化について。複数言語に対応したアプリを作っている方は一読しておくと良いでしょう。
Symfonyでは、翻訳ファイルとTwigのtransフィルターだけで基本的な対応はできます。

### [第9章](http://hanahirodev.hatenablog.com/entry/20161105/1478335914)
セキュリティについて。ユーザーのなりすまし機能がサポートされているというのが驚きでした。

### [第10章](http://hanahirodev.hatenablog.com/entry/20161105/1478339765)
アセットについて。基本的にAsseticを使いましょう。というお話。
ただ、最近はSSRとかSPAとかあるし、Gulpとかつかてる人も多いので、これからどうなるのかしらと思った。

### [第11章](http://hanahirodev.hatenablog.com/entry/20161105/1478342428)
テストについて。というより「ファンクショナルテスト」の重要性が語られています。

## その他

４章くらいで気づいたけど、BestPracticeについては、Symfony2系とそんなに大きな変更はないみたいです。
Symfonyユーザーに限らず、このBestPracticeは設計に関する示唆に富んでいると思います。

明日は[qcmatsuoka](http://qiita.com/qcmatsuoka)さんです！
Confluence マクロ 解説；ページプロパティレポートとページプロパティ

#　はじめに
Confluenceはマクロを活用すると、とても便利なツールです。使い初めの方が困るのがマクロの習得でしょう。その中でもマニュアルを読んでも、良く分からないマクロを解説したいと思います。

# ページプロパティレポートマクロ と ページプロパティマクロ
このマクロは2つのマクロを組み合わせることで利用できるマクロになります。
ページの中で **ページプロパティマクロ** 内の表内の各項目を **ページプロパティレポートマクロ**で表示することができます。
<img width="373" alt="スクリーンショット 2016-11-27 13.36.39.png" src="https://qiita-image-store.s3.amazonaws.com/0/45733/2be80f07-6281-4ac0-20ce-9cf66f5d2b36.png">
ページプロパティレポートマクロはページ上で以下のように表示されます。
<img width="1110" alt="page.jpg" src="https://qiita-image-store.s3.amazonaws.com/0/45733/f6cb9e0a-45b2-5516-ae29-3e55fcc1cb65.jpeg">


# ページプロパティマクロの準備

ページプロパティマクロを挿入し、テーブルを設定するだけです。　その際に考慮すべきは各ページのサマリーの項目をあわせておくことです。
上記のスクリーンショットでは「適用日」、「主担当者」、「Slackチャンネル」を項目として設定しています。
ページプロパティレポートマクロ上で表示させるには、同一の**Label**でページを特定し、マクロレポート内で表示させます。

# ページプロパティレポートマクロの設定

ページプロパティマクロでは、先程設定した**label**を入力することでレポートが完成されます。　（例では "mis-release" というラベルにしています。）
<img width="847" alt="page.jpg" src="https://qiita-image-store.s3.amazonaws.com/0/45733/65f85aaf-8f74-63c7-a3d6-f50191dc9274.jpeg">

これで完成です。　表示させる項目、非表示させる項目など状況に応じてカスタマイズ

# このマクロの良いところ

各個別のページの中で詳細を検討しているときなどに、ステータスや担当者などをページプロパティマクロ内で書き込みを行い、ページプロパティレポートで俯瞰してみることができるので、全体把握が簡単にできるようになります。



色々使ってみてください。　　僕は基本的にこのマクロを多用しています。