OmniAICreator/Qiita-1.07M huggingface dataset:
Cookieを使う

**はじめに**
***

Cookieの使い方が苦手なので、書きます。
AndoridはWebViewでCookieを使います。

**CookieSyncManager**
***
CookieSyncManagerはCookieの同期を管理できるクラスです。

```lang:CookieSyncManager
@Override
protected void onCreate(){
  // WebViewで使うcookieの準備
  CookieSyncManager.createInstance(getApplicationContext());		 
  CookieManager cm = CookieManager.getInstance();

  //Cookieの利用
  cm.setAcceptCookie(true);	

　//Cookieをセットしたり
  cm.setCookie(DOMAIN, cookieStr);
}
```
準備の処理をonCreate()に書く。
一度、createInstanceをせずにgetInstanceを呼び出しました。。
元々あるwebviewのCookieを別の場所で呼び出したりする処理をしようとしたんですね。。
多分。w
エラーになるので注意です。

```lang:CookieSyncManager
@Override
protected void onResume() {
　　super.onResume();
    CookieSyncManager.getInstance().startSync();
}

@Override
protected void onPause() {
　　super.onPause();
    CookieSyncManager.getInstance().stopSync();
}
```

この辺りは、お作法的な感じで覚えておきます。


**deprecatedされてる**
***
Android 5.0ではもうdeprecated されていました！
[こちら](http://developer.android.com/reference/android/webkit/CookieSyncManager.html)にものってますね。。
Cookieの情報をWebViewでも利用する以外に、Apache HttpClientと同期したりする処理もありますが
そのHttpClientも[Android6.0でサポートしない](http://developer.android.com/intl/ja/about/versions/marshmallow/android-6.0-changes.html)とのことなので、
この辺りは対応していく必要がありそうです。。

とはいえ、まだ多く出会いそうな処理なので、書いてみました！
twe-liteの通信距離が短い

# twe-lite DIP -- tocostickが10mも飛ばない

オフィス内で通信する分には、見通しで1kmも飛ぶんだからだいじょぶだろう、と油断していたら全然飛ばない。

壁を一枚挟むだけでギリギリで、直線距離にして10mも飛ばない。
受信できても安定せず、10sの間欠動作にしていても結構な確率で欠測が起きる。

10mぐらいで↓みたいな品質。2.4GHz帯で何か干渉している？Bluetoothとか？
うーんハードのデバッグは難しいのだけど、下記のような方針で切り分けをしていく。
プルアップ無効化しても消費電力が思ったよりも大きくて、5日ぐらいしか持たないそうだし、エナジーハーベスト版のFW焼いたらシリアル通信できずインタラクティブモードに入るときにエラーで何もできなくなるしで問題は山積している。


## 切り分け方針

- ドア、壁なしでオフィス内での通信距離測定
- アクティブなBluetoothなどがない深夜帯で測定

## twelite DIP --ドア -- 壁 -- tocostick 実測

```
  command = 0x81 (other)
  src     = 0x02
  payload = 15 01 27 81 00 66 9e 00 88 a0 00 0b f8 12 00 01 ff ff ff ff ff (hex)
  LQI       = 39 / -84.85 [dbm]
  time stmp = 546.500 [s]
  volt      = 3064 [mV]
20:55:37.524975
  DI1=0/1  DI2=0/0  DI3=0/0  DI4=0/0


  command = 0x81 (other)
  src     = 0x01
  payload = 15 01 30 81 00 68 d9 00 8a 70 00 0a e5 16 00 01 ff ff ff ff ff (hex)
  LQI       = 48 / -81.70 [dbm]
  time stmp = 553.750 [s]
  volt      = 2789 [mV]
20:55:41.172107
  DI1=0/1  DI2=0/0  DI3=0/0  DI4=0/0


  command = 0x81 (other)
  src     = 0x02
  payload = 15 01 21 81 00 66 9e 00 88 a2 00 0b fc 12 00 01 ff ff ff ff ff (hex)
  LQI       = 33 / -86.95 [dbm]
  time stmp = 546.531 [s]
  volt      = 3068 [mV]
20:55:47.585672
  DI1=0/1  DI2=0/0  DI3=0/0  DI4=0/0


  command = 0x81 (other)
  src     = 0x02
  payload = 15 01 1e 81 00 66 9e 00 88 a4 00 0b fc 12 01 01 ff ff ff ff ff (hex)
  LQI       = 30 / -88.00 [dbm]
  time stmp = 546.562 [s]
  volt      = 3068 [mV]
20:55:56.798990
  DI1=1/1  DI2=0/0  DI3=0/0  DI4=0/0


  command = 0x81 (other)
  src     = 0x01
  payload = 15 01 2d 81 00 68 d9 00 8a 79 00 0a e1 16 00 01 ff ff ff ff ff (hex)
  LQI       = 45 / -82.75 [dbm]
  time stmp = 553.891 [s]
  volt      = 2785 [mV]
20:56:11.290215
  DI1=0/1  DI2=0/0  DI3=0/0  DI4=0/0
```
英訳をはじめるときに気にしたい３つのポイント


[@pineapplecandy](https://twitter.com/pineapplecandy)と申します。

遅くなりましたが、
[技術英語や翻訳 Advent Calendar 2015](http://qiita.com/advent-calendar/2015/english_translation)の 20日目を書きます。

SE４年目、海外支社と英語を使って
PJのブリッジをしたり、通訳したりしています。

今日は、海外系SEとして英訳和訳を行う上で、
私が大事にしている３つのポイントを紹介します。

# ①英訳を始める前に和文を疑え

これは、英訳をお願いする日本人にもお願いしたいこと。
「あなたの日本語は、主語、目的語が明確になっていますか？」これに尽きます。

日本語はあいまいな言語です。
簡単に以下のような文章が書けてしまいます。

×:　データを投入する
   → Data is input ... ???? 
○:　**ユーザが** データを（csvファイルで）投入する
　→User inputs data (by csv file)
 
主語、目的語が明確にならなかったら機械翻訳もあいまいになるし、
読んでいる人（特に外国人）は？？？ってなります。

「誰が」「なにを」「どうする」が和文に含まれているのかを見てみてください。

# ②訳すテイストは既存のサイトを参考に

日本語であっても
マニュアルとWebpageではテイストは明らかに違いますよね。

訳すときにいきなりガリガリと自力で始めるよりも、
５分使ってもいいから既にあるものを参考に読み込みを
行った方が、最終的に効率は上がります。

使うべき語彙や、文型も違うので。。。

# ③ 第３者レビューを受けよう

①、②を頑張ったところで、所詮は私たちはエンジニアであり、翻訳家ではありません。

とはいえ、社内では自分が一番できる、翻訳に出す予算がない、<del>上司の英語力が皆無</del>など事情はそれぞれだとは思うので、
一概に言えないのですが、
あなたの組織に英語力が平均点以上ある人（TOEIC６００点以上）がいれば、
レビューを受けることを強くおススメします。
もちろん、頼まれたら、あなたがレビューしてあげてください。

メリットは、
1. 自分では、分かったつもりで書いた曖昧ポイントがわかる
2. 語彙力がアップする
3. 他人の書き味、テクニックを盗める

１，２はレビューイのメリット、３はレビューする時のメリットですね。
あと、単純に人に見せると思って書くと、
勝手に用語統一を意識したり、セルフレビューの精度が上がって
品質が上がります（笑）

ということで、少しは英訳和訳に悩んでいる技術者の皆様に役立てば幸いです。

#最後に
おススメは [@may_roma](https://twitter.com/may_roma) さんの
[添削! 日本人英語 ―世界で通用する英文スタイルへ](http://www.amazon.co.jp/dp/4255008183)を読んでみてください。
英訳あるあるや目からウロコの話もあって面白いですよ＾＾
PCB tree の設計

　[KiCad Advent Calendar 2015](http://qiita.com/advent-calendar/2015/kicad)の22日めの記事です。
　21日めは[nomper](http://qiita.com/nomper)さんでした。
***

2016/03/24 (追記)
注意書き
　プリント基板に含まれるガラス繊維は肌を傷つける場合があります。
　また今回の基板のとがった部分は危険です。
　取扱いにはご注意ください。
(追記終わり)

　今回は実際のプリント基板の作製例です。KiCadのテクニックや使い方は全く解説しません。KiCadの使い方は[kicad.jp](http://kicad.jp/)や[KiCad Advent Calendar 2015](http://qiita.com/advent-calendar/2015/kicad)の他の記事を参考にしてください。
##はじめに
今回の基板は、
1. LEDを光らせること
2. メロディICとブザーを用いてクリスマスソングを流す
の2点を目的とした基板です。

　LEDを点灯させるだけの回路を組むのに、いきなりプリント基板を作製しようと思うことはないと思います。しかしながら、簡単な回路でもプリント基板にすると以下のような利点があると思います。

- はんだづけするだけでよいので配線作業が楽(重要)
- 基板の形を簡単に変えられる(これも重要)
- 簡単な回路なのでCadの使い方の練習になる(?)
- 未完成のまま放置することがない（おそらく）

　単純な回路ではあるのですが、プリント基板を少し変わった形にした例として、Christmas PCB tree　(クリスマスツリー型基板)を紹介します。
　
#(Christmas) PCB tree
　すでにネット上ではたくさんの製作事例がありますが、木の形をしたプリント基板にLEDやブザーをのせたものです。クリスマスも近いですしクリスマスソングが流れるようにしています。

点灯例（試作品）
![IMGP0730.JPG](https://qiita-image-store.s3.amazonaws.com/0/105725/e4851588-df8c-949b-e529-723504957382.jpeg)

はんだ付けをすれば完成するという形にしています（マイコン不要、電源が供給されればOK）。
設計はBZR4022 版で行いました。

##回路図
![2015-12-17.png](https://qiita-image-store.s3.amazonaws.com/0/105725/63f1408f-788b-cf8e-c471-aa4d24048ba9.png)

　部品はすべて秋月電子でそろいます(2015年11月時点)。
**電源**
USBコネクタ（オス）
**発光ダイオード部分**
抵抗およびLED　(R1-R5)(D1-D5)
（イルミネーションLEDやキャンドルLEDを混ぜてもよい）
拡散キャップ
**クリスマスソングのメロディIC部分**
抵抗および赤色LED(D6)（ツェナーダイオードの代わり）
メロディIC（クリスマスソングメロディのもの）
ブザー
スライドスイッチ(メロディICのON/OFF)

**補足1**
　LEDの種類にもよりますが、LEDに3 mA程度の電流を流せば十分に明るいです。今回は抵抗値を以下のように設定しました。
赤色LED、黄色LED: 1 kΩ
青色LED、白色LED: 470 Ω
キャンドルLED(赤、黄): 1kΩ
キャンドルLED(白),イルミネーションLED: 470Ω

**補足2**
　メロディICの電源電圧は1.5V-3.0V程度だったと思います。5Vを直接加えないように注意しましょう。
　また、ブザーに直列に入っている抵抗は 1kΩです。

##パターン
![2015-12-17 (2).png](https://qiita-image-store.s3.amazonaws.com/0/105725/8d81287e-9e08-f424-2f86-01272d502035.png)
（設計例その１）

　クリスマスツリー用に基板外形を描きます。縦線、横線、対角線を使えば描けます。部品は表面実装品もいくつか使いましたが、表面実装品を使わないことも可能です（下図）。ブザーとUSB端子のフットプリントは自分で作りました。シルクが重なっていますが、ガーバデータを出力するときに、モジュールの値もリファレンスも出力しない設定で出力しました。

![tree_2.png](https://qiita-image-store.s3.amazonaws.com/0/105725/c5b98290-0af7-e98c-0738-9ca1b0394eba.png)
（設計例その２）

**補足**

- LEDやスイッチのフットプリントはすべてSIL-2,SIL-3で代用しています。
- メロディICはSIL-3に向きがわかるように半円を後から付け足しています。
- （※）SIL-2,SIL-3はスルーホールの径を直径1 mmに拡張しています。


##使い方
　お近くのUSBポートへ接続してください。それだけでLEDは光ります。スイッチをONにすればクリスマスソングが流れます。

##今後の電子工作
今回は単純に電源を入れれば光るという形にしていますが、たとえばArduinoなどのマイコンを用いてLEDの点灯順序を変えるなどすると面白いかと思います。

#おわりに
　LEDを光らせて音がなるだけの回路ですが、KiCadを使用した作品の一つとして紹介さしていただきました。
パームレスト（ハンドレスト，リストレスト）について

Dvorak Advent Calendar 22日目．

-----

## パームレスト（ハンドレスト，リストレスト）について

キーボードの手前に置くクッションの奴です．

\*本来は使わない事が望ましいとされていますが，敢えてここではパームレストをいくつか紹介します．

ELEC◯Mとかサン◯サプライで満足いく人はそれはそれでいいと思います．
ここでは個人的に世界3本指に入るであろうパームレストを紹介します（全て持ってます，使ってます）
（木製（竹）派，アルミなどの金属派，アクリル派などの人はごめんなさい．ここではソフトな奴しか出てきません．）


### GRIFITI WRIST PAD

![](http://www.grifiti.com/sites/default/files/imagecache/product_full/grifiti_fat_wrist_pads_01.jpg)


[GRIFITI](http://www.grifiti.com/)はガジェット系の小物を製造販売している会社です．
以下2つと違い，皮革製品でない化繊（ナイロン？）タイプのリストレスト（サイズはいくつかあります）
色々な製品の小物を出しているだけあってサイズ感，厚みなどは素晴らしいです．
少々汚れ易く，その汚れが落ちにくい面もありますがサイズ感と機能が本当に良く出来てます．あと，安い！

が…

使っているとボロボロと壊れてきます…これがなければ，No.1かもしれなかったのですが…
（毎日使って半年〜1年でボロボロ壊れてきました）


### Ducky Wrist Rest

![](http://www.duckychannel.com.tw/en/images/accessories/accessories_02.jpg)

[DuckyChannel - Keyboards Manufacturer and Computer Peripheral Professional Agent](http://www.duckychannel.com.tw/en/)

LEDでやたら光らせるゲーミングメカニカルキーボードを出しているメーカーDuckyのリストレスト．
皮革製品でミシン目ステッチも黒で塗られています．（赤もあるっぽい？）硬いです．壊れにくく，汚れにくい非常に強いやつです．

が…

とにかく入手困難！！
自分でもどうやって入手したのか忘れました（海外通販で買った事しか覚えてない）

革部分が（汗などで？）破けたと言う報告も海外ではあるようですが（一体どんな使い方をしたんだろう…）


### Filco レザーパームレスト

![](http://ecx.images-amazon.com/images/I/51mQbqFtGWL._SX425_.jpg)

2段階の段差が付いてます（上下逆に使う人が多い印象）
ステッチは白で日本でも簡単に入手できるのが良いですね．

…とか思ったら…もうAmazonでも売ってない…の？

[Amazon.co.jp： FILCO キーボード用パームレスト レザーパームレスト大サイズ(47.0cm) 本牛革製 ブラック FKBPR/B: パソコン・周辺機器](http://www.amazon.co.jp/dp/B000KJTP4S/)


海外では，このFilcoと上記Duckyが比較される事が多いですが，日本でリストレストの話になるとFilcoに落ち着く印象があります．（木製派，アルミ派，アクリル派などは無視）

革部分（上部）とゴム部分（下部）がぱっくり剥がれると言う報告もあり，実はチープな作りっぽい．


## どれもこれも一長一短

ジェルタイプはジェルが漏れて壊れますし，ゴムタイプは室温に影響を受け過ぎます．
ナイロン製は汚れが落ちにくく，汚れやすい，壊れ易い．
皮革タイプは長持ちしますが価格が高く，水に弱い．そして入手困難といったところ…


1番いいのはパームレストを使わずに快適に打鍵できる環境を整えることです．
ネットワーク系コマンドを使ってあれこれしてみる

この記事はファーストサーバのAdvent Calendar 2015の22日目用の記事です
http://qiita.com/advent-calendar/2015/firstserver

弊社ファーストサーバはホスティングを生業としているため

サポートの際はお客様のドメイン名から

IPアドレスやホスティング業者などを把握することは必須のスキルとなります。

これらは黒い画面でコマンドを打つことで調べられたりします。

一方、サポートチームには見た目はごく普通の主婦やOLの方も所属しており

お昼休みなどには旦那の愚痴や子育ての話をしていますが

サポートのお仕事中にはガチャガチャとコマンドを駆使したお客様の対応をしています。

ギャップがすごいので一度ご家族の方に見ていただきたいものです。

　今回はそんな主婦の方々から教わった

**「黒い画面でコマンドを叩いてドメイン名からいろいろ知る方法」**を振り返ってみようと思います。

今回は徒にラズベリーパイを使ってみましたが、手軽なWindowsでやるのが一番難易度が高いです。要注意。

# ラズベリーパイの準備

引き出しにしまったラズベリーパイを引っ張り出してきて準備をします。

![raz.JPG](https://qiita-image-store.s3.amazonaws.com/0/71261/c85d565d-a178-b8de-acb9-2c1b36227d42.jpeg)

小生の所有しているラズパイ(Pi2)には今回使用するコマンドがデフォルトでは使えないため

DNS系のパッケージをインストールして使用できるようにします。

```
$ sudo apt-get install dnsutils
$ sudo apt-get install whois

```
準備はこれだけです。

では弊社サービスである[Zenlogic](https://zenlogic.jp/)のドメイン名「zenlogic.jp」でいろいろ試してみましょう。

# ドメイン名からレジストラを調べる

ドメイン名からレジストラを調べるために`whois`コマンドを使います。
```
$ whois zenlogic.jp
```

![a.gif](https://qiita-image-store.s3.amazonaws.com/0/71261/fb930392-993b-946c-1001-66038a079f7c.gif)


うーん、ネームサーバの箇所に弊社ドメイン名サービスの「[Doレジ](http://do-reg.jp/)」の文字が見受けられますが、

レジストラ業者とは明示していないですね。失敗です

個人のドメイン名だと公開情報がレジストラのものだったりしてわかります。

![b.png](https://qiita-image-store.s3.amazonaws.com/0/71261/b214e924-4b26-a4c8-8aec-be931f86580c.png)


ま、あくまで目安にしかなりませんね。

また裏技的な方法としては**「GMO」といえば大体当たり**ます。

コンパ等でよく使われる「**血液型当てるね。うーん…Ａ型！**」よりは当たりますが、

この方法は素人は使わないほうが吉です。

気を取り直して次行きましょう。

# ドメイン名からDNSサーバを調べる

ドメイン名から使用しているDNSを調べるには「digコマンド」を使います。

上記`whois`でも調べられるのですが、

`+short`を付与するとスッキリした表示になるので使いやすいです。
```
$ dig zenlogic.jp NS +short
```
![c.png](https://qiita-image-store.s3.amazonaws.com/0/71261/26b4889c-ac04-c206-a054-32506d657836.png)

この場合は「[Doレジ](http://do-reg.jp/)」のDNSを使用していることがわかります。


# ドメイン名からWebサーバのIPアドレスを調べる

ドメイン名から使用しているIPアドレスを調べるには`dig`コマンドを使います。

こちらも`+short`を付与してスッキリした表示にします。
```
$ dig zenlogic.jp A +short
```
![d.gif](https://qiita-image-store.s3.amazonaws.com/0/71261/024c6eba-f24d-d1f3-aaee-31adb0098083.gif)


問題ないと分かりつつも、IPアドレスを晒すと罪悪感に苛まれますね…


# ドメイン名からホスティング業者を調べる

ホスティング業者を調べるには、IPアドレスに対して`whois`を行います。
```
$ whois 203.137.3.234
```
ただし、この方法でうまく取得できない場合があります。

そんな時は調べる対象のIPアドレスを管理するwhoisサーバを`-h`で指定してコマンドを発行しましょう。

whoisサーバは、IPアドレスの第一オクテット（IPアドレスの先頭3桁）単位で管轄しているようなので、

この[サイト](http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtml)を参照して問い合わせ先を変更しましょう。

「zenlogic.jp」のケースですと、IPアドレス先頭3桁は「203」ですので、参照先は「whois.apnic.net」を指定します

```
whois 203.137.3.234 -h whois.apnic.net
```
![e.png](https://qiita-image-store.s3.amazonaws.com/0/71261/d4bd45f3-de2e-6ee7-f473-c56069d64ad0.png)

APNIC(アジアのwhoisサーバ)からJPNIC(日本のwhoisサーバ)を経由して

「ファーストサーバ」の管理するホスティングにたどり着きました。

めでたしめでたし

# 最後に

ここまで出来ればあなたもスーパーハカーです。

憎いあンちくしょうのメールサーバや、気になるあの子のホームページの

IPアドレスやホスティング業者を調べて、驚かせてやりましょう。

また、世の中には「**ドメインを入れるとホスティング業者を表示してくれる**」

~~今回の投稿を無下にする~~とっても[便利なサイト](http://hostadvice.com/tools/whois/)があるので

今度、主婦の方々に教えてあげようと思います。
Androidアプリでgoogle画像検索する話

qnote Advent Calendar 2015 22日目を担当いたします。
11の倍数日担当のチャン・ジュン(日本人)です。
よろしくどうぞ

今回は画像検索して何かしたいな〜という話です。

##画像を検索する
とりあえず画像検索をするということで、画像検索APIの利用を考えたのですが思いのほか不便そうです。
検索範囲とか絞られちゃうと思い通りの検索結果は得られないですし…

そこで思いついたのが、
「普通にGoogle画像検索を利用すれば良いんじゃないの？」です。

[Google検索のパラメータ(URLパラメータ)一覧](http://www13.plala.or.jp/bigdata/google.html)を参考にしました。

```
http://www.google.co.jp/search?
```
の後ろに

```
tbm= isch
```

とつければ画像検索になります。
キーワードは

```
q=keyword
```
「+」接続で条件追加「-」接続で除外ができます。

他にも検索オプションがあるので必要に応じて使用してください。

###画像のURLを取得する

上記のURLを利用して検索結果を取得するとhtmlファイルが手に入るのでimgタグに入った画像のURLを取得します。
下記は取得したhtmlファイルから画像のURLを抽出する部分です

```
final String regex = "<img.+?src=\"(.+?)\".+?>";
Pattern pattern = Pattern.compile(regex);
Matcher matcher = pattern.matcher(response);

ArrayList<String> imageUrlList = new ArrayList<>();
while (matcher.find()){
    imageUrlList.add(matcher.group(1));
}

```
検索結果取得に関する通信系の処理については割愛します。

##画像を表示する
今回はノープランなので、取得した画像のURLを使ってGridViewで表示だけしてみます。

下記はGridViewにセットしたアダプターの一部です。
ここではVolleyのNetworkImageViewを利用しています。

```
@Override
public View getView(int position, View convertView, ViewGroup parent) {
    if (convertView == null){
        convertView = new NetworkImageView(mContext);
        ViewGroup.LayoutParams layoutParams = new ViewGroup.LayoutParams(200, 200);
        convertView.setLayoutParams(layoutParams);
        ((NetworkImageView)convertView).setScaleType(ImageView.ScaleType.FIT_CENTER);
        ((NetworkImageView)convertView).setDefaultImageResId(R.mipmap.ic_launcher);
    }
    ((NetworkImageView)convertView).setImageUrl(getItem(position), mImageLoader);
    return convertView;
}
```

__だがしかし20件しか取得できない！__

###limit/offset的ななにか

参考にしたサイトに記載された「num」オプションはlimitのようなものかなと思ったのですが、

```
num=0　　…　効く

num=100　…　効かない
```

ということで仕方ないので検索してみました。

[分散検索：Google vs Solr](http://lucene.jugem.jp/?eid=261)

こちらの記事によると

```
start=10　…　offset的なもの
```
ということで、取得件数は変えられなかったので画像のURLを取得してArrayListに入れた後、
必要数に達していない場合は再度リクエストを投げることにしました。

表示したい画像数が多い場合には、スクロール等をトリガーに追加取得とかの方が良いかもしれません。

##最後に

画像の著作権には注意しましょう！
提供された写真に困らない！ 写真あるあるベスト2を解決する方法


制作の現場で、提供された写真で困ることがよくあるかと思います。
今回は写真で困るベスト2を効率的に素早く解決する方法をご紹介します。

私もよく使うので、
困った時にぜひ使ってみてください。

#「横幅が足りない！！」写真あるある(１)#



提供された写真の横幅がたりなくて困ったことはありませんか？
webの現場では特に近年、大きな写真を使ったレイアウトも人気ということもあり、
わたされた写真データーでは幅があきらかに足りない！という、デザイナー泣かせなことが多々起きるかと思います。
もちろん一番は撮影時にカメラマンに写真をどう使用するかをきちんと説明し解決するのがベストですが、
カメラマンによってはwebの特徴を理解できず、キャンパス狭めな写真が出来上がってきてしまいます。


**そこで、 
緊急手段ですが「コンテンツに応じた塗りつぶし」を使って5秒で画像の幅を増やす方法を紹介します。**
##コンテンツに応じた塗りつぶし方法##

###こんな時にこの機能がおすすめ###
- 画像の幅（高さ）を増やしたい
- テキストを左or右に配置したい


1.足したい部分のカンバスを大きくします

<img width="750" alt="a1.png" src="https://qiita-image-store.s3.amazonaws.com/0/104401/91f9ddea-bdd4-8a8b-7356-3316fead2987.png">



2.「選択範囲」で透明部分を選択します。
3.「編集」メニューの「塗りつぶし」ダイアログボックスを表示し、「内容」に「コンテンツに応じる」を選択します
（ショートカットキーshift+F5）

<img width="750" alt="a2.png" src="https://qiita-image-store.s3.amazonaws.com/0/104401/a6ae4729-2b31-cef5-6b36-d160b30cf636.png">

4.完成！

<img width="750" alt="a3.png" src="https://qiita-image-store.s3.amazonaws.com/0/104401/9f3d8916-ada2-901a-762b-ed34bcd31f9b.png">

※必要に応じてさらにレタッチしてください!


#「えっ逆光！」写真あるある(2)#

プロのカメラマンに頼んだ場合は起きないですが、逆光写真って地味に困りませんか？
逆光の写真は、被写体だけマスクしてトーンカーブで調整することもできますが、
なかなか面倒なので、「シャドウ・ハイライト」で即座に解決。

##シャドウ・ハイライト方法##

###こんな時にこの機能がおすすめ###
- 逆光写真をさっくと修正したい


1.「イメージ」メニュー「色調補正」→「シャドウ・ハイライト」をクリック

<img width="750" alt="b1.png" src="https://qiita-image-store.s3.amazonaws.com/0/104401/615dec0a-d279-7794-5674-d93c110b175e.png">

2.「シャドウ・ハイライト」ダイアログボックスを開いたら、「シャドウ」の値を調整

<img width="750" alt="b2.png" src="https://qiita-image-store.s3.amazonaws.com/0/104401/0fcc2142-7673-921c-1ddd-9bb8892a5557.png">

3.完成！

<img width="750" alt="b3.png" src="https://qiita-image-store.s3.amazonaws.com/0/104401/62af7f5f-0c62-a541-291c-a7a1fa9de86a.png">
【FileMaker】TODOリストを作って改良していこう(7) ーおさらい


FileMaker Advent Calendar 2015のTODOリストシリーズ、今回で最後です。

今回は、おさらいです。

まず、[ヒアリング](http://qiita.com/tyuma/items/cb8cba65e6f6c187b6a9)をしました。
開発者の方は分かっていると思いますが、ユーザの要求はコロコロ変わるものです。
最初にヒアリングしたものは、リリースした時にはすでに形が変わっていることがほとんどです。
なので、ヒアリングの時には話し半分で聞いておき、開発期間に余裕を持つことをお勧めします。
「余裕」は、最初の要求が変更になったり追加になった時の分です。
絶対、ギリギリの予定を立ててはいけません。

そして、動作する[機種を選定](http://qiita.com/tyuma/items/839b60074cd54c365e60)しました。
何で動かすかで、FileMakerの場合はレイアウトの数が変わります。
レイアウトはコピーで作れますが、それぞれの機種(iPhoneやiPadなど)のサイズにリサイズするには時間が必要です。
動作確認やiPadでは動かない関数やスクリプトなどの確認や配慮も必要です。
時間が倍増します。

ヒアリングと動作環境が決まったら、さぁ開発！ではありません。
[業務設計](http://qiita.com/tyuma/items/8587ce3db285a6812839)でしたね。
業務はコンピュータ化されていないシステムです。
それをFileMakerを使ってコンピュータ化するということは、「業務＝FileMakerで構築したシステム」という形態になっていないとシステム化した意味がありません。
ここを端折って開発を進めると、出来上がってテストをしてもらった時に「全然違う」と言われてしまうのです。
それっていやですよねぇ。
なので、「おたくの業務はこうですよね」「これを今回FileMakerでやっていきますよね」ということを（UMLなどで）絵的に表し、お互いに理解をしていく必要があるのです。

そして、業務設計が決まったら、いよいよ[開発設計や本開発](http://qiita.com/tyuma/items/a863ec08fbe5a720a038)に入っていきます。
このシリーズでは開発設計についてさらっと書いてしまいましたが、開発設計では、共通で使う部品（関数）やエラー処理のやり方の共通化、コメントの書き方、など開発に必要な共通認識を合わせておきます。
必要であれば、これら開発設計方針を文書で残しておきます。
FileMakerの開発現場ではなかなかここまでやらないところが多々あるようですが、小さい開発現場だからこそコンパクトな開発設計を残しておき、開発者が退場し運用やメンテナンスの人が入った時の共通認識の資料として利用してもらうのです。
短期間開発が多いかと思いますが、ぜひ習慣化していきたいところです。

開発がひと段落し、いよいよ[ユーザにテスト](http://qiita.com/tyuma/items/cb720fa5245d8ff483e0)をしてもらいます。
「いよいよ」と書きましたが、できれば製作途中でステップ分けし、都度動かしてもらう時間をとってもらうと、最後の最後でどんでん返しがおこらないと思います。
テスト仕様書はここで初めて作る、もしくは作らない現場も多いかと思いますが、業務設計をした資料がテスト仕様書として活用できます。
「業務設計書＝テスト仕様書」を意識して設計書を仕上げられるといいですね。

ユーザは、動作確認をすると、「やっぱりここは。。。」ということが殆どです。
なので、[業務設計の範囲を超えない範囲で修正やバージョンアップ](http://qiita.com/tyuma/items/745fccb81af513589155)をしていきます。
「業務設計の範囲を超えない」ことが原則です。
開発はこの範囲で終わらせます。
そして、次回の開発に向けて、ユーザもあれこれ考えていくし、開発者側も「あそこをこうすると、お客様はもっと使いやすいかも」という提案をしていくことで、システムがスパイラルに良くなり大きくなっていきます。


実際、そんな風にうまくいくわけではありませんが、どちらも気持ち良くシステムを開発し使っていきたいと思う気持ちは一緒だと思います。
なので、できる限り疲弊しないシステム開発をFileMakerでもしていく必要があります。

Advent Calendarでも他の記事で書いたように開発環境を整えたり仕様書を残しておくなども気持ち良く仕事をする上で必要です。
開発言語に限らず共通概念だと思います。

来年度は私もいままでやってきたことを見直して、もう少し気持ち良くFileMakerで仕事をしていきたいと思っています。

これで、TODOのシリーズは終わりです。
W3Cとの関わりかた

## はじめに
私達がWebアプリケーションづくりに欠かせない数々の技術は
誰が仕様を決めているのか、そのプロセスや活動への参加の仕方などざっくりとまとめます。

## W3Cとは
正式名称：World Wide Web Consortium（ワールド・ワイド・ウェブ・コンソーシアム）という
Webに関する仕様を標準化する国際・非営利団体です。
HTML／CSS／JavaScriptといったWeb技術の仕様や指針を標準化するための
技術文書（Technical Report)を作成しています。

### 現在公開中の技術文書

自分の興味のある技術や日付、作業グループ（後述）などから検索できます。

[Tecnical Rrport](http://www.w3.org/TR/)

## 標準化のプロセス

標準化は以下のステータスの順番に行われます。
W3C勧告がFix状態ですが、勧告案の時点ではW3C勧告に移行する可能性が高く
将来のWebの動向をある程度予測できると言えます。
ちなみに、この標準化プロセスも2014年に見直されており、
Last Call Working Draft(最終草案)がCandidate Recommendation(勧告候補)に統合されています。


|ステータス|内容|
|:--|:--|
|Working Draft(WD): 作業草案|  コミュニティ（＝W3Cメンバーや公的機関、その他の技術系の組織など）によるレビューのために、W3Cの各作業グループ（Working Group）により発行される文書。 |
|Candidate Recommendation(CR): 勧告候補| 作業グループが持つ要件を満たし、すでに広くレビューを受けているため、勧告として承認されることが期待される文書。W3Cは勧告候補を発行することで、より広いコミュニティに対してシグナルを送って、実装も含めたレビューを実施してもらい、その情報を収集する。|
|Proposed Recommendation(PR): 勧告案|十分な品質があり、W3C勧告になり得ると、W3Cのディレクターから認められた文書。勧告案には、大量の修正を行うことはできない。|
|W3C Recommendation(Rec): W3C勧告|広範の同意を形成した後、W3Cのメンバーとディレクターの承認を受けた仕様・指針・要件の文書。W3C勧告の「Web標準」として広く活用できるようになった最終段階。|



また、結構重要かと思われるのは、廃止された草案やW3C勧告も公開状態で残ることです。
これを知っていないと、廃案になったものまで標準仕様と勘違いしてしまう可能性があるので注意が必要です。

***標準化しないもの、草案を破棄したもの、W3C勧告後廃止となったもの***

|ステータス|内容|
|:--|:--|
|Working Group Note, Interest Group Note (NOTE)|作業グループやインタレストグループ(後述)で、既に公開されたドキュメントに対する有益だが正式に標準化するつもりののないドキュメント（例えば、ある仕様についての邦訳ドキュメントがそれに当たる）。あるいは、W3C勧告になる前に破棄した草案|
|Rescinded Recommendation|W3C勧告が公表されたが、もはやW3Cが支持しなくなった勧告。勧告廃止。|

【ステータスのドキュメント上の表記例】
![html5.png](https://qiita-image-store.s3.amazonaws.com/0/17796/6d23a6e8-5b84-b306-09ff-4480a503f8e5.png "W3C勧告の表記例")

上記の他に、Editor's Draft(編集者草案)というのもありますが、これは、簡単に言えばWorking DraftやNoteになる前の非公式な状態を差します。


#### 参考URL
--------
[W3C World Wide (Web Consortium Process Document 6.1.1:Recommendations and Notes)](http://www.w3.org/2015/Process-20150901/#recs-and-notes)
[HTML標準仕様などを決める、W3Cによる勧告のプロセスとは？](http://www.buildinsider.net/web/htmltips/0001)

## 作業グループ(WG)とインタレストグループ(IG)とは
### 概要
作業グループ(WG)は一つの仕様を策定するための単位が作業グループです。
Working Draft以降の草案はこちらのグループが作ります。
インタレストグループ(IG)は、特に成果物は必要なく、広く技術に関する議論を行うためのグループです。
（インタレストグループに対する適切な訳が見当たらなかったので、そのままカタカナにしています）

|グループ|参加要件|活動内容|
|:--:|:--|:--|
| WG |W3Cを含む会員企業の従業員もしくは諮問委員会の代表が選出した人,招聘されたエキスパート(Invited Experts),W3CのCEO/ディレクター/インターン/従業員(The W3C Team)|成果物（例えば、勧告その他のグループの成果の技術報告書、ソフトウェア、テストスイート、およびレビューを追跡）の作成。|
| IG |上記＋メーリングリストに登録した人|主な目的は、一緒に潜在的なWeb技術とポリシーを評価したい人々を集めることであり、アイデアの交換の場。|

**ということは、IGならば誰でも参加可能**
IGでは主に、メーリングリストにて仕様策定前のWeb技術の議論や、その他のNoteを発行したりすることができます。

## どうしても日本語がいい人には

### ドキュメント
公式のドキュメントは英語のみですが、有志による邦訳はあります。
枯れた仕様であれば、多くの邦訳が出回っているようです。

[日本語翻訳集:W3C Japan](http://www.w3.org/2003/03/Translations/byLanguage?language=ja)

### 日本語圏用IG
数は少ないですが、日本語の使えるIGがあります。

[IG (INTEREST GROUP) について:W3C Japan](http://www.w3.org/japan/about-ig)

## W3C利用法の例
1. 自分の気になる作業グループのメーリングリストに登録して、最新の動向を追いかけてみる
	* リリースした機能と関係のあるW3C勧告が改版されていないかを確認するなど
* 挙動の異なるブラウザ間でどちらがW3Cに準拠しているのかを確認する
	* 修正すべきなのかどうなのか、という判断の一つの基準として使える
* メーリングリストで議論してみる


#### 参考URL

[W3Cメーリングリスト検索サービス:W3C](https://www.w3.org/Search/Mail/Public/)


## 終わりに
W3Cってなんだかはるか遠くの誰かがやってる感じがしていましたが、
いつもお世話になっていて、この業界にいる限り絶対に影響を受けるものなので
便利に活用して行ければよいと思います。

※予定とは違うタイトルでお送りしました。
【Swift】デフォルト引数を活かして堅牢なアプリケーションを作る

## はじめに
この記事ではデフォルト引数を使って「完全コンストラクタ」を実現するという事を書いていきます。

## 完全コンストラクタとは
完全コンストラクタとは設計パターンの一つで、初期化時に全てのプロパティーの値をセットするという考え方です。
オブジェクト指向の話で良く出てくる話題で、シンプルな考え方なので覚えやすいし使いどころの多い考え方です。

## 完全コンストラクタの例
User1が完全コンストラクタを利用している例です。
初期化時に全てのプロパティーがセットされている事が分かります。

```swift
// User1が完全コンストラクタに準拠している
class User1 {
    let name: String
    init(name: String) {
        self.name = name
    }
}
let user1 = User1(name: "名前")

// User2は完全コンストラクタに準拠していない
class User2 {
    var name: String = ""
}
let user2 = User2()
user2.name = "名前"
```

## 完全コンストラクタのメリット
完全コンストラクタの大きなメリットと思われる点は下の通りです。
安全性の向上と開発者への分かりやすさが大きなメリットになります。

### 1. 予期しない値の変更による不具合を避けれる
インスタンスの初期化位置と離れた所での値変更、メソッドの引数でインスタンスを渡したらメソッド内でプロパティー書き換えなどが該当します。
この辺りは見つけるのが困難なので可能なら避けたい所です。

### 2. 値のセットのタイミングによって起こる不具合を避けられる
メソッドがプロパティーの値を使う場合、プロパティーのセット前にメソッドを呼び出すと予期しない動きをする事があります。
完全コンストラクタを使えば値のセットが終わっている事が保証されるのでこういった不具合を回避できます。

私の場合はfontをセットする前にlabel.sizeToFite()を呼び出してしまう事が多いので、初期化時にfontもセットしたいと常々思います。

```swift
class User {
    var firstName = ""
    var lastName = ""
    var fullName: String {
        return firstName + lastName
    }
}
let user = User()
print(user.fullName) // 空文字になる
user.firstName = "First"
user.lastName = "Last"
```

### 3. クラスを使う人が分かりやすい
初期化の時にプロパティーで渡すので、クラスを使う人がどのプロパティーが必須かが分かりやすいというメリットもあります。
安全性向上とは別の切り口のメリットです。

## 完全コンストラクタが実現しずらくなる状況
このように良いことが多い完全コンストラクタですが、プロパティーが増えてくると維持するのが大変になります。
初期化時に値を渡すので、プロパティーを1つ増やした時にはこのクラスを使っている箇所全てに影響が出ます。
都度コンストラクタを増やせば回避できるのですが、プロパティーを増やす度にコンストラクタを増やし続けるのも非常に大変です。

そういった時に役立つのがSwiftのデフォルト引数です。

*そもそもプロパティーが増えてきたらクラスの分割を考えるべきだったりするのですが、チームの方針などで分割しにくい事も有り得るので今回はその辺りは置いといて考えます。

## Swiftのデフォルト引数
Swiftではメソッドがデフォルト引数を持つことができます。

```swift
func method(value1: Int = 0, value2: Int = 1, value3: Int = 2) {}
method(value2: 10)
```

それを使えばクラスの初期化は下のように書けます。
これならプロパティーが増えても既存のコードへの修正は最小限で済みますししプロパティーが増えても使う側は必要なものだけセットすればいいので非常に簡単です。

```swift
class User {
    var firstName: String
    var lastName: String
    var age: Int
    var prefecture: String
    var fullName: String {
        return firstName + lastName
    }
    init(firstName: String, lastName: String, age: Int = 20, prefecture: String = "東京") {
        self.firstName = firstName
        self.lastName = lastName
        self.age = age
        self.prefecture = prefecture
    }
}
// ageだけ省略
let user = User(firstName: "firstName", lastName: "lastName", prefecture: "神奈川")
```

## まとめとこの記事を書いたきっかけ
メソッドのラベルがあるおかげで堅牢なアプリケーションが作れるという話でした。

最後にこの記事を書こうと思った発端も少し話してみます。
記事を書くきっかけになったのは、メソッドのラベルでした。

Swiftのラベルとは下の例の`label`部分です。

```swift
func method(label value: Int) {
}
method(label: 1)
```

昔Objective-cを使った時にラベルが非常に冗長に感じていてあまり良い仕様とは思っていませんでした。
Swiftができた時も既存のライブラリとの互換性の為にラベルを実装された事で残念に感じていました。
しかし最近になってラベルがあるおかげで好きな位置のデフォルト引数を指定でき、それのおかげでメソッドでコンストラクタを最小限にできる事を知って非常に感動しました。

この記事がきっかけでSwiftのメソッドのラベルって結構面白いと思って頂けたら幸いです。

## 参考URL
https://codeiq.jp/magazine/2013/10/496/
http://fukuchiharuki.me/wiki/index.php?%E8%A8%AD%E8%A8%88%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3%2F%E5%AE%8C%E5%85%A8%E3%82%B3%E3%83%B3%E3%82%B9%E3%83%88%E3%83%A9%E3%82%AF%E3%82%BF
Serverless Frameworkを使いAWSで作った構成をオープンソースで公開してみよう

## 概要
[Serverless FrameworkでLambdaファンクションをプロジェクトごとに一括管理する](http://qiita.com/horike37/items/ab8c653383b1419ea78b)で書いたServerless Frameworkですが、作ったものをGithubで公開しておけば、他のプロジェクト(AWSアカウント)でも使用可能です。

- endopointとしてAPI Gateway
- プログラムロジックとしてLambda
- データストアとして、DynamoDBやS3

このあたりのサービスがServerlessではサポートされているのですが、これで自分なりのAWS構成を作っておけばオープンソースとして公開して配布できちゃうわけです。

イケてる構成を作れれば、皆が自身のAWSアカウント上でその構成を動かしてくれるかもしてません。これはオープンソース魂揺さぶられますよね。

ってことで、Serverless Frameworkで作ったAMIMOTO管理ツールで使ってるLambdaファンクション群をGithubで公開してみました。
[AMIMOTO MobileApp Lambda](https://github.com/megumiteam/amimoto-mobileapp-lambda)

## Githubへの公開方法
<img width="480" alt="21c6266f-f577-1865-ec70-3d1e7b185c7b.png" src="https://qiita-image-store.s3.amazonaws.com/0/65478/9f33edb9-630a-b9c8-2371-579359fb025e.png">
Serverless Frameworkを作るとこんなプロジェクト構成になりますが、モジュール名(mobileapps)以下をGithubにて公開するようにします。プロジェクトのルートディレクトリにはCredentialの情報や個別の環境設定が記述されているファイルがあるので、ここは公開しないように気をつけてください。

`.gitignore`はこんな感じでモジュール名配下に置きます
ログや環境依存のファイルやIDE等のファイルは排除。また`event.json`はローカルでLambdaを動かすための入力値を定義するものです。今回の場合はインスタンスIDを設定するため、各AWS環境に依存するので、排除してます

```
# Logs
logs
*.log
npm-debug.log

# Runtime data
pids
*.pid
*.seed
dist

# Directory for instrumented libs generated by jscoverage/JSCover
lib-cov

# Coverage directory used by tools like istanbul
coverage

# Grunt intermediate storage (http://gruntjs.com/creating-plugins#storing-task-files)
.grunt

# node-waf configuration
.lock-wscript

# Compiled binary addons (http://nodejs.org/api/addons.html)
build/Release

# Dependency directory
# https://www.npmjs.org/doc/misc/npm-faq.html#should-i-check-my-node_modules-folder-into-git
node_modules

#IDE Stuff
**/.idea

#OS STUFF
.DS_Store
.tmp

#ENV VARS
.env

#Local Setting
**/event.json
```

package.jsonはこんな感じです。serverless-helpers-jsとaws-sdkをインストールするようにします。

```json
{
  "name": "amimoto-mobileapps",
  "version": "0.0.1",
  "description": "Dependencies for a Serverless Module written in Node.js",
  "author": "me",
  "license": "MIT",
  "private": true,
  "repository": {
    "type": "git",
    "url": "git://github.com/"
  },
  "keywords": [],
  "devDependencies": {},
  "dependencies": {
    "aws-sdk": "^2.2.25",
    "serverless-helpers-js": "~0.0.3"
  }
}
```

こんな感じで準備したらあとはGitで公開してしまいましょう

## 他のAWSアカウントでの使用方法
まずは通常通りにAWSアカウントでIAMユーザを発行してServerlessをインストール。プロジェクトの設置まで行います。そしてそのプロジェクト内で以下のコマンドを発行するだけです。

```
$ serverless module install <GithubリポジトリへのURL>
```

これだけで、package.jsonの依存関係もすべて解決して必要なモジュールをインストールしてくれます。
あとはendpointやfunction,resourceをserverlessコマンドでAWS上にデプロイしてください

## フレームワークにロックインされないか
こんな疑問を抱く方もいるかなと思ったので書いておきます。結論から言うとロックインはされません。ServerlessはFrameworkという表記が良くない気がするのですが、Frameworkと言うより、開発環境という方が近いと思います。作ったものの実体はAWS上にリソースとしてデプロイしてしまえば、Serverlessを使わずとも操作が可能です。

あまり向かないなと思ったらやめてしまえばいいので、えいやと本番で使ってしまってもいいかもしれません。

## まとめ
AWSの構成がオープンソースとして公開できることろに冥利がつきますね。
今後作った構成はできるだけ公開できるように作っていきたいと思います。

それでは良いオープンソースライフを！
Mybatis Generatorでimmutableなクラスを生成

Mybatis Generatorでimmutableなクラスとなるように、コード生成をするやり方です。

# コンストラクタによるマッピング + setterなし

公式サイトでやり方はでていますが、constructorBasedにし、immutableにすると、コンストラクタのみがフィールドの値を設定できるようなクラスを生成するようになります。

http://mybatis.org/generator/configreference/javaModelGenerator.html

```lang:generatorConfig.xml
 <javaModelGenerator targetPackage="entity" targetProject="src\main\java">
    	<property name="constructorBased" value="true"/>
     	<property name="immutable" value="true"/>
 </javaModelGenerator>

 <table tableName="">
	 <property name="modelOnly" value="true"/> // モデルクラスと対応するxmlファイルだけ生成
     	 <property name="useActualColumnNames" value="false"/> //snake_caseのカラム名をcamelCaseのフィールド名にマッピング
</table>
```

# サンプル

例えば、id,nameというカラムを持つUserテーブルに対しては、次のようなxmlファイルとjavaファイルが生成されます。


```lang:UserMapper.xml
<resultMap id="BaseResultMap" type="entity.User" >
    <!--
      WARNING - @mbggenerated
      This element is automatically generated by MyBatis Generator, do not modify.
    -->
    <constructor >
      <arg column="id" jdbcType="INTEGER" javaType="java.lang.Integer" />
      <arg column="name" jdbcType="NVARCHAR" javaType="java.lang.String" />
    </constructor>
  </resultMap>
```

```lang:User.java
public class User{
    /**
     * This field was generated by MyBatis Generator.
     * This field corresponds to the database column User.id
     *
     * @mbggenerated
     */
    private Integer id;

    /**
     * This field was generated by MyBatis Generator.
     * This field corresponds to the database column User.name
     *
     * @mbggenerated
     */
    private String name;

    /**
     * This method was generated by MyBatis Generator.
     * This method corresponds to the database table FUNCTION_CODE_MASTER
     *
     * @mbggenerated
     */
    public FunctionCodeMaster(Integer id, String name) {
        this.id= id;
        this.name= name;
    }

    /**
     * This method was generated by MyBatis Generator.
     * This method returns the value of the database column User.id
     *
     * @return the value of User.id
     *
     * @mbggenerated
     */
    public String getId() {
        return id;
    }

    /**
     * This method was generated by MyBatis Generator.
     * This method returns the value of the database column User.name
     *
     * @return the value of User.name
     *
     * @mbggenerated
     */
    public String getName() {
        return name;
    }

```

# どういうときに使う？

コード値のテーブルやマスタ系など、いわゆる参照にしか使わないテーブルです。
意図しないタイミングで編集されたくないので、最初からimmutableにしておくて便利です。
表示させるときに何かしらの整形する場合は、そのためのDTOを用意するか、SQLで整形した結果をビューにして、そのビューからコード生成をさせるなどをしています。
Spring Bootでjavaクラスやテンプレートエンジンのホットデプロイ(オートリロード)

Spring Bootでホットデプロイとか出来るの？思って調べてたら、Springloadedなるものを使えば出来る、とあったので試してみました。
http://docs.spring.io/spring-boot/docs/current-SNAPSHOT/reference/htmlsingle/#howto-reload-static-content
 ※78.4 Reload Java classes without restarting the container　の所です

javaクラスやテンプレートエンジンに適用出来るみたいなのでまとめておきます。

# pom.xmlの設定
springloadedへの依存関係を追加します、以下のようになります。

```pom.xml
 <plugin>
         <groupId>org.springframework.boot</groupId>
         <artifactId>spring-boot-maven-plugin</artifactId>
         <dependencies>
                 <dependency>
                         <groupId>org.springframework</groupId>
                         <artifactId>springloaded</artifactId>
                         <version>1.2.0.RELEASE</version>
                 </dependency>
         </dependencies>
 </plugin
 ```

 Springloadedのバージョンは以下から任意のものを選んでください(最新版が良いかと思います)。
http://mvnrepository.com/artifact/org.springframework/springloaded


# Spring BootのVM引数の設定
 公式によると、上記pom.xmlの設定のみでOKみたいな感じですが、実際はこれをやらないとダメでした。

STSでプロジェクトを右クリック → 【Run As】 → 【Run Configurations…】 → 【Java Application】 → 【プロジェクト名】 → Argumentsタブ → VM arguments
に以下を入力

-javaagent:M2REPO/repository/org/springframework/springloaded/1.2.1.RELEASE/springloaded-1.2.1.RELEASE.jar -noverify
※M2REPOのところは各自のMavenローカルリポジトリのパスを指定します。
※1.2.1のところは利用するバージョンになります。

こうすることでSpringloadedが効きます。
以降はテンプレートエンジンのオートリロードについてです。

# Thymeleafテンプレートのオートリロード
application.properties(or YML)に以下を追加します。

```application.properties
spring.thymeleaf.cache=false
```

# FreeMarkerテンプレートのオートリロード
application.properties(or YML)に以下を追加します。

```application.properties
spring.freemarker.cache=false
```

# Groovyテンプレートのオートリロード
application.properties(or YML)に以下を追加します。

```application.properties
spring.groovy.template.cache=false
```

# Velocityテンプレートのオートリロード
application.properties(or YML)に以下を追加します。

```application.properties
spring.velocity.cache=false
```

2016/4/27 追記
Spring Boot1.3以上を使っている方は、Spring Loadedはもう開発が進んでないので使わない方がいいです。代わりにSpring Boot1.3から使えるSpring Dev Toolsを使った方がいいです。

<blockquote class="twitter-tweet" data-lang="ja"><p lang="ja" dir="ltr">やっぱりSpring Boot1.3以上ではSpring Loadedうまく動かないのでSpring Devtoolsに変えたら期待通りになった</p>&mdash; Kenichi Nagaoka (@ARS_2000) <a href="https://twitter.com/ARS_2000/status/727336663999909892">2016年5月3日</a></blockquote>
<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>

<blockquote class="twitter-tweet" data-lang="ja"><p lang="ja" dir="ltr"><a href="https://twitter.com/su_kun_1899">@su_kun_1899</a> Spring Loadedはもう開発進んでないので、使わない方がいいです。代わりに1.3から使えるDev Toolsを</p>&mdash; Toshiaki Maki (@making) <a href="https://twitter.com/making/status/717080310479867905">2016年4月4日</a></blockquote>
<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>

```pom.xml
<dependency>
	<groupId>org.springframework.boot</groupId>
	<artifactId>spring-boot-devtools</artifactId>
</dependency>
```
Bug Bounty Program


Bug Bounty Programとは、脆弱性を報告してもらうことで報奨金を払う制度のことです。

企業自身が行っていたりするものや、専門で脆弱性報告受付と報奨金の支払いを行う代行サービスがあったりします。

## 企業自身

+ [GitHub](https://bounty.github.com/)
+ [Google](https://www.google.com/about/appsecurity/reward-program/)
+ [United Airlines](https://www.united.com/web/en-US/content/Contact/bugbounty.aspx)
+ [mozilla](https://www.mozilla.org/en-US/security/bug-bounty/)
+ [サイボウズ](http://cybozu.co.jp/company/security/bug-bounty/)
+ [LINE](https://linecorp.com/ja/security/bugbounty/) (すでに終了済み)
+ ...


## Bug Bounty サービス


+ [hackerone](https://hackerone.com/)
 + Twitter
 + Yahoo
 + Square
 + DropBox
 + ...

+ [bugcrowd](https://bugcrowd.com/)
 + TESLA
 + Pinterest
 + heroku
 + ...

+ ...



海外の大きな会社やサービスでは普通になってきているようですが、日本では企業側での認知度が低いのと同時に、脆弱性を報告されることに対する嫌悪感的な部分もあるのかなと思ってしまいます。

報奨制度までいかずとも脆弱性受付窓口がある企業もまだまだ少なく、窓口がない企業に脆弱性の報告を行うと、日本の場合「不正アクセス禁止法」を根拠に逆に罪に問われる可能性もある、、なんて話も聞きます。

その意味では、もっともっと日本でもBug Bounty Programが普及すると、企業側も報告者側もハッピーになれるのではないですかね。

最近、日本でも初のBug Bountyサービスがはじまったようです。

+ [THE ZERO ONE](https://bugbounty.the01.jp/)

まだまだ始まったばかりのようですが、間違いや、おかしなところを指摘された時に、気持ち良く「ありがとう」と言える文化が広まるといいですね。
[OSX]プロセス間通信（Distributed Notifications）

<p>Mach由来だと思われるDistributed Notificationsについて調べてみた。OSXでは異なるアプリケーションに対して通知を送る事ができる。</p>

<p>通知を受け取る側（DistributedServer）のコードは以下のとおり。</p>

<pre><code>@implementation AppDelegate
- (void)applicationDidFinishLaunching:(NSNotification *)aNotification
{
    NSLog(@"%s", __func__);
    [self _registerForNotes];
}
 
- (void)_registerForNotes
{
    NSLog(@"%s", __func__);
    NSDistributedNotificationCenter *dnc = [NSDistributedNotificationCenter defaultCenter];
    [dnc addObserver:self
            selector:@selector(_handleDistributedNote:)
                name:@"DemoDistributedNote"
              object:nil];
}
 
- (void)_handleDistributedNote:(NSNotification *)note
{
    NSLog(@"%s Recieived Distributed Notification!:%@", __func__, note);
}
@end
</code></pre>

<p>通知を送る側（DistributedClient）のコードは以下のとおり。</p>

<pre><code>@implementation AppDelegate
- (void)applicationDidFinishLaunching:(NSNotification *)aNotification
{
    NSLog(@"%s", __func__);
    [self _postNotes];
}
 
- (void)_postNotes
{
    NSLog(@"%s", __func__);
    NSDistributedNotificationCenter *dnc = [NSDistributedNotificationCenter defaultCenter];
    [dnc postNotificationName:@"DemoDistributedNote"
                       object:nil];
}
@end
</code></pre>

<p>DistributedServerを起動した後に、DistributedClientを起動すると、アプリケーション間で通知が送られることが確認できる。</p>

ソースコード
GitHubからどうぞ。<br />
<a href="https://github.com/murakami/workbook/tree/master/mac/DistributedServer">https://github.com/murakami/workbook/tree/master/mac/DistributedServer</a> - GitHub<br />
<a href="https://github.com/murakami/workbook/tree/master/mac/DistributedClient">https://github.com/murakami/workbook/tree/master/mac/DistributedClient</a> - GitHub<br />

関連情報
<a href="http://amazon.jp/dp/0596004621">Cocoa in a Nutshell</a><br />

<iframe src="http://rcm-fe.amazon-adsystem.com/e/cm?t=bitz00-22&o=9&p=8&l=as1&asins=0596004621&ref=qf_sp_asin_til&fc1=000000&IS2=1&lt1=_blank&m=amazon&lc1=0000FF&bc1=000000&bg1=FFFFFF&f=ifr" style="width:120px;height:240px;" scrolling="no" marginwidth="0" marginheight="0" frameborder="0"></iframe>

【Cocoa練習帳】
<a href="http://www.bitz.co.jp/weblog/">http://www.bitz.co.jp/weblog/</a><br />
<a href="http://ameblo.jp/bitz/">http://ameblo.jp/bitz/</a>（ミラー・サイト）<br />
.NET4.6で末尾再帰するとしぬかもな話

超絶マイナーネタ。現在進行形のお話。

# C#で再帰する奴ー
.NETのx64JITには末尾再帰の最適化があります。
再帰してもコールスタックを消費しないすごいやつです。
これを全力で利用しまくったライブラリを書いてたんですが、そのときハマった話。

# こんなコード

```csharp
// ちょっとしたstruct
public struct AStruct
{
    public int Value;

    public AStruct(int x)
    {
        this.Value = x;
    }
}

// 末尾再帰する関数
private static AStruct RecA(AStruct a)
{
    //System.Console.WriteLine(new System.Diagnostics.StackTrace().FrameCount); // コールスタックのカウントだせるやつ
    return (a.Value <= 0) ? a : RecA(new AStruct(a.Value - 1));
}

// よびだすやつ
internal static void Main(string[] args)
{
    RecA(new AStruct(100000000));
}
```

.NETのtail-call optimizationを有効にするには、x64環境でReleaseビルドでコンパイルします。
実行すると、華麗に`StackOverflowException`で死にます。んんん、だめじゃん。

```csharp
// classにしてみた
public class BClass
{
    public int Value;

    public BClass(int x)
    {
        this.Value = x;
    }
}

// 末尾再帰する関数
private static BClass RecB(BClass b)
{
    //System.Console.WriteLine(new System.Diagnostics.StackTrace().FrameCount); // コールスタックのカウントだせるやつ
    return (b.Value <= 0) ? b : RecB(new BClass(b.Value - 1));
}

// よびだすやつ
internal static void Main(string[] args)
{
    RecB(new BClass(100000000));
}
```

これは正常に完了します。あれー？？？

# RyuJITのバグ？？？

```xml:App.config
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <startup> 
        <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.6.1" />
    </startup>
    <runtime>
        <useLegacyJit enabled="1" />
    </runtime>
</configuration>
```

`App.config`に`useLegacyJit`を追加して値を`1`にするとRyuJITの使用を無効化できます。
すると上のコードはAもBも正常に動くようになります。
これは一体……？

# まだ検証中なの
上のコードのそのまま動くやつをとりあえず[ここ](https://github.com/acple/RyuJIT-tail-call-recursion-problem)に置きました。
今はRyuJITの仕様とかissueとかを探ってるんですけど、英語が全く読めないので死んでます。
何か関連する情報があったらくださいおねがいします。
BPMとは

・BPMとは

BPM(Business Process Managment)とは、組織内の様々な業務プロセスの処理や仕組みを明確にして、業務の改善を通して理想的なプロセスに近づけていく経営手法である。

BPMを導入するメリットを考えると以下のようになる。
・複数の部署や担当者が関わる業務を自動化することがてぎる。
・業務システムを柔軟に変更することができる。
・業務の品質を一定にできる。

BPMはBPRと同様、理想的な業務プロセスに近づける改善活動でありよく似ている概念ではあるが、BPMには、PDCAサイクルが取り入れられており、継続的な改善活動を構築していくことに対して、BPRは根本的な改革を実施し一度で最適な方向に近づけることが主な違いである。

※
BPR ： Plan、DOのみ
BPMN ：Plan、Doだけでなく、Check、Actionも含む
Statistical search on the Semantic Web

# すごく大雑把なSemantic Webの説明
Semantic Webでは従来のHTML型の階層構造のwebページをやめて、RDF（主語<ノード> → 述語<エッジ> → 目的語<ノード>）というグラフ構造の形式でデータを全て表現する。

**Protein X** → activates → Protein Y（PPIデータベース（仮））
Gene X → is transcripted to → **Protein X**（転写データベース（仮））

といった、Protein Xに関する異なる情報が別々のデータベースに登録されていたとしても、グラフなので以下のように容易にマージできる。

Gene X → is transcripted to → **Protein X** → activates → Protein Y

これにより別々に開発されているバイオデータベースを統合できるため、知識を集積化できると考えられている。

指定された先は、webページだけではないため、Semantic WebはデータのWebと呼ばれる。

URLアドレスはURIと呼ばれる。

オントロジーはOWLという書き方をする。

各アクセスできるデータベースのことをSPARQL End Pointという。

各データベースへの横断的な問い合わせは、SPARQLという言語を用いる。

# Semenatic Web × データ解析
RDFによって、自分の興味があるデータを一挙に取得できたとして、そのデータで何をしたいのか、これまでのデータ解析ではできない何が実現できるのか、というのがその次の話としてあると思うのだが、それを言っている論文はまだそれほど多くない。

今後人工知能・機械学習などとからめて話される話題だと思うが、現状でそういった視点の論文が無いかと探していた時に、一つ面白そうと思ったのが、

[Statistical search on the Semantic Web, Bioinformatics, 24(7), 1002-1010, 2008](http://bioinformatics.oxfordjournals.org/content/24/7/1002.short)

という論文だった。

# Statistical search on the Semantic Webの概要

Semantic Webによって、あるタームに関連した情報が大量に取得される。

その中でも特に関係性が強いものだけにフォーカスしたい。

そこで、Fisherの正確確率検定の*p*値を算出し、*p*値の小さいものだけを使うという方法を考えた。

この考え方を、Genotype - Phenotype間の相関を見る"GWAS"（Genome Wide Association Study）になぞらえ"SWAS"（Semantic Web Association Study）と名付けた。

また、それを実装した問い合わせ言語をGRASQL（General and Rapid Association Study Query Language）というものを実装し、この言語を内部で走らせて、あるキーワードと関係する遺伝子名を返す[PosMed](http://omicspace.riken.jp)というシステムを別途開発した。

驚いたのは、2008年で既にこんなこと言ってたという点。BioHackathonで、Semantic Webをとりあげられ、各データベースの連携が試み始められたのが、2010年らしい([?](http://biosciencedbc.jp/gadget/rdprog_over/H25-s12_katayama.pdf))ことを考えると、かなり先取った論文だなという印象を受けた。

これを開発した人がたまたま同じ建物内にいたため聞いてみたところ、結果にノイズが多いらしいが（関係ないものもかなり有意になって検出される）、個人的に試みとして面白いなと思った。

# 参考
- http://bioinformatics.oxfordjournals.org/content/24/7/1002.full.pdf
- http://www.slideshare.net/tetsurotoyoda/ss-26884736
- http://biosciencedbc.jp/gadget/rdprog_over/H25-s12_katayama.pdf
- http://omicspace.riken.jp
RxJS の Observable で EventEmitter を扱う

この記事は [bouzuya's RxJS Advent Calendar 2015](http://www.adventar.org/calendars/1200) の 21 日目かつ RxJS Advent Calendar 2015 の 21 日目です。

# はじめに

いまさらながら Event を Observable で操作します。`Observable.fromEvent` とその簡単な例を書きます。

通常なら DOM の Event で使うところですが、ここまで Node.js で試してきたので `EventEmitter` を使います。どちらも `Observable.fromEvent` で対応できます。

# `Observable.fromEvent`

## EventEmitter の例

まず `Observable` を使わない `EventEmitter` の例を挙げます。

```js
import { EventEmitter } from 'events';

const emitter = new EventEmitter();

emitter.on('data', value => console.log(value));

emitter.emit('data', 'Hello, Event!');
// Hello, Event!
```

`EventEmitter.prototype.on` で event listener を登録します。ここでは流れてくる　`'data'` event の値を表示するようにしています。`EventEmitter.prototype.emit` で `'data'` event として `'Hello, Event!'` を流しています。

## Observable の例

次に `Observable` を使った `EventEmitter` の例を挙げます。

```js
import { EventEmitter } from 'events';
import { Observable } from 'rx';

const emitter = new EventEmitter();

Observable
  .fromEvent(emitter, 'data') // fromEvent(element, 'cilcked')
  .subscribe(value => console.log(value));

emitter.emit('data', 'Hello, Event!');
// Hello, Event!
```

`Observable.fromEvent` で `emitter` の `'data'` event から `Observable` instance をつくっています。`Observable.prototype.subscribe` は説明不要でしょう。

自然に読みかえられると思います。

### Observable の良い点

前述の `Observable` の例では 1 行増えただけで良い点が分かりづらいので、もうすこしいくつかの例を挙げます。

流れてくる文字のほかにそれを mask (`'*'` でつぶす) した文字を表示するようにします。愚直に書くとこんな感じでしょうか。

```js
import { EventEmitter } from 'events';
import { Observable } from 'rx';

const emitter = new EventEmitter();

Observable
  .fromEvent(emitter, 'data')
  .subscribe(value => console.log(value));

Observable
  .fromEvent(emitter, 'data')
  .map(s => s.split('').map(() => '*').join(''))
  .subscribe(value => console.log(value));

emitter.emit('data', 'H');
emitter.emit('data', 'He');
emitter.emit('data', 'Hell');
emitter.emit('data', 'Hello, Event!');
// H
// *
// He
// **
// Hell
// ****
// Hello, Event!
// *************
```

まず `Observable` の Operator を使えるのは良い点です。`map` や `filter` で event を変換したり不要なものを取り除いたり……この Advent Calendar で 10 日以上をかけても紹介しきれない Operator を使えます。

また interface が統一されるのも良い点です。今回は `EventEmitter` ですが、それが `element` になっても、同様に `Observable` として扱えるのは良い点でしょう。

ほかの良い点を示すためにもう一つ例を挙げます。

```js
import { EventEmitter } from 'events';
import { Observable } from 'rx';

const emitter = new EventEmitter();

const event$ = Observable.fromEvent(emitter, 'data');
const masked$ = event$.map((s) => s.split('').map(() => '*').join(''));

Observable
  .merge(event$, masked$)
  .subscribe(value => console.log(value));

emitter.emit('data', 'H');
emitter.emit('data', 'He');
emitter.emit('data', 'Hell');
emitter.emit('data', 'Hello, Event!');
// H
// *
// He
// **
// Hell
// ****
// Hello, Event!
// *************
```

実行結果は同じですが先ほどより随分と重複コードを減らしています。また mask された値を流す `Observable` に適切な名前をつけています。このように柔軟に分割できることで個別に `Observable` の動きを test することもできるでしょう。

# おわりに

実はまだ全体の 2/5 くらいで、続きを書いているのですが、長くなるので分割します。明日は `Observable.fromEvent` (`Observable.fromEventPattern`) の実装を読んでいこうと思います。
Ruby1.9系からRuby2.2に上げて困ったこと

# Railsは3.2系を使用

## Time.nowにstubを設定するところでエラー
* 書き方が[古いらしい。](http://blog.shinofara.xyz/archives/181/)下記のように修正してテストOK

```.rb
-      Time.stub(:now).and_return(Time.parse("2015-01-01 06:00:00 +0900"))
+      time_now = Time.local(2015, 01, 01, 6, 0, 0)
+      Time.stub!(:now).and_return(time_now)
```

## 使ってないparamがあると[warningが出るようになってる](http://stackoverflow.com/questions/6397078/when-did-assigned-but-unused-become-a-warning-for-ruby)

## クラス変数を取得できない(gem fogを拡張した時）
* <del>fogの[バージョン1.6.0](https://www.versioneye.com/ruby/fog/1.6.0)上げる？？ [1.19.0で直したみたい?](https://github.com/fog/fog/blob/v1.19.0/lib/fog/cloudstack.rb) [非推奨になっている？](https://github.com/dwilkie/carrierwave_direct/issues/121)</del>←バージョンあげても直らなかった。
* そもそもclass_evalを使ってFog::Cloudstackを拡張した場合、クラス変数取得[できないはず](http://d.hatena.ne.jp/k-sato_at_oiax/20100708/1278594826)
   * 自分の環境で試してみたところRuby1.9.2-p326,1.9.2-p330ではクラス変数を取得できた。Ruby1.9.3-p551では取得できなかった。
   * クラス変数を取得できる[メソッド](http://docs.ruby-lang.org/ja/2.0.0/method/Module/i/class_eval.html)が有った為それを[使用する](http://qiita.com/jkr_2255/items/887e080d4b72ea6bf060)

```
-    Base64.encode64(OpenSSL::HMAC.digest(@@digest, key, query)).strip
+    Base64.encode64(OpenSSL::HMAC.digest(class_variable_get(:@@digest), key, query)).strip
```

## true/falseがfrozenになっていた為、落ちていたテストの修正

# その他
## [ruby2.2に上げたらシンボルで値が取れなくなった](http://qiita.com/bbrubymm/items/8ca97d15a0c75d4a334a)
## [ruby2.2に上げたらwarning: circular argument reference - reflectionエラーが出る](http://qiita.com/bbrubymm/items/beab9ca83bcf51362765)
あるエンジニアの緩慢な死、あるいはエンジニア35歳定年説。

「エンジニア35歳定年説」が許されるのは小学生までだよねーとか思っていたら、実際にはそんな感じになってしまったあるエンジニアの半生を振り返ります。ご参考まで。

# 第一期

* サービスリリース前
* 自分でサービスをガリガリ作っている
* というかサービスを作ることしかしていない
* １日１６時間くらい仕事をしても、プログラミングしかしていないので疲れない
* 仕様の検討をしながら作るので、基本全ての時間は開発をしているという認識
* フルスタックエンジニアというある種の全能感を満喫する

# 第二期

* サービスリリース後
* 運用（ユーザーサポートなども含む）が入ってくるのでサービス開発のスピードが落ちる
* エンジニアを採用（業務委託含む）する
* 仕様の調整やコードレビューなど、開発以外の仕事が少しずつ増えてくる
* でもまだまだ自分が圧倒的にメイン開発者
* コードレビューやマージ、リリースは自分が全てやる
* システムの全体からディテールまでほぼ完璧に把握している

# 第三期

* サービスが軌道に乗ってきて、エンジニアをたくさん採用する
* とはいえ人事とかはまだ整っていないので、採用のオペレーションや面接などでかなり時間をとられるようになる
* コードレビューにもかなり時間をとられるようになる
* 自分のレビュー待ちがボトルネックになることがある
* レビュー、マージ、リリースを権限委譲しはじめる
* システムの全体像は把握しているが、ディテールに少しずつ自分が把握できていない部分が出てくる
* 自分より圧倒的に優秀なエンジニアが入ってきて、その人が書いたコードは正直よくわからないみたいなことも起こりはじめる
* とはいえまだまだシステムのコアの複雑な部分（別名：秘伝のタレ）は自分しか把握できていないので、そのあたりの改修は自分でやったりとエンジニアとしてのアイデンティティを保つことはできる
* 同時に、初期の実装が後から入ってきたエンジニアにdisられることが頻発する
* まだ自分が書いたコードが半分以上残っていて、ある意味メインエンジニア（というちっぽけなプライドにすがる）

# 第四期

* 一人ひとりの状態が把握できなくなってくるので、1on1を始めてみたり、目標設定や人事考課的なものが始まったり、そういったマネジメント的な何かに時間をとられることが増えてくる
* プログラミングをする時間がだいぶ少なくなってくる
* 自分のレビュー待ちがボトルネックになることがしょっちゅう起こるようになる
* 機能によっては自分がほとんど分からないケースが出てくる
* システムの全体像も油断するとよくわからない箇所が出てくる
* 自分が書いたコードが生き残っている部分もどんどん減ってくる
* 徐々に自分を「エンジニア」だということに自信がなくなってくる
* このあたりになると自分しか把握できていない部分はだいぶ少なくなってきて、そこだけが自分のエンジニアとしての存在価値になる
* 仕様について質問されコードを読んで答えたらコードリーディングをミスっていて嘘を教えてしまう、コードレビューで間違った指摘をしてしまうなどの事件が起こりエンジニアとしてのアイデンティティを喪失する
* 個人でサービス作ることでプログラミングから離れないようにしようと画策する、が、実際にはやらない
* マネジメントをするために何をすべきかがよくわからないが、実際にサービスを作ってきた知識と経験でなんとか凌ぐ

# 第五期

* 第四期に加えて、部門をまたぐ調整・問題解決や予実管理、会議の資料作成などでほぼ業務時間が埋まる
* システムの進化にキャッチアップすることが不可能になり、◯◯は△△さんが詳しいよ、といえるだけのポインタおじさんになる
* たまにコードを書いて、若手エンジニアにレビューで切られる、自信を喪失してますますコードから離れる、の負のスパイラル
* というか若手の方が優秀なのでマネジメントでバリューを出すしかない、と悟る
* が、マネジメントの道は長く険しい
* エンジニアが技術を学ぶように、マネージャーはマネジメントを学ぶことが必要だと思うようになる

# 第六期

* ポインタおじさんですらなくなる
* プログラミングもマネジメントも本質は同じだと思えるようになる、、、予定

# 第七期以降

https://qiita.com/shinichinomura/items/6841a1f9a8bda571af7c
[Cocoa]安全なプログラミング？

<p>Swiftは安全なプログラミングを提供！という話を聞くと少しモヤモヤしてます。なので、この手の話題に関わりたくないので、ちょっと、違う視点から。</p>

<p>Swiftでもpublicやprivateが指定できるようになりがっかりした側なのだが、そもそも、それで何をしたいのか？隠すためだというが、Swiftのようなインタフェース部と実装部が分かれていない言語では、丸見えじゃん！と思ってしまう。</p>

<pre><code>class Person {
    private var name = "名無しの権兵衛"
    
    func rename(newName: String) {
        name = newName;
    }
    
    private func secretWork() {
    }
}
</code></pre>

<p>では、C++はいいのかというと、privateなメンバーも、通常ヘッダーに記述するクラス定義で宣言しないといけないため、知りたくもない内部実装を見せられて、これもイマイチ。</p>

<pre><code> class Person {
    std::string name;
    void secretWork();
    
public:
    void rename(std::string newName);
};
</code></pre>

<pre><code>void Person::secretWork()
{
}
 
void Person::rename(std::string newName)
{
    name = newName;
}
</code></pre>

<p>それを考えると、Objective-C 2.0は自分にとって理想的だ。</p>

<pre><code>@interface Person : NSObject {
    NSString *name;
}
 
- (void)rename:(NSString *)newName;
</code></pre>

<pre><code>@interface Person ()
- (void)secretWork;
@end
 
@implementation
- (void)rename:(NSString *)newName
{
    if (name) [name autorelease];
    name = [newName retain];
}
 
- (void)secretWork
{
}
@end
</code></pre>

<p>ヘッダーには見せたいことだけが記述されている。素晴らしい。</p>

<p>ただ、Swiftに慣れると、インタフェース部と実装部のファイルが分かれているのが、煩わしく感じてしまう気持ちも否定できないが。</p>

関連情報
<a href="http://qiita.com/advent-calendar/2015/cocoa/">Cocoa Advent Calendar 2015</a><br />

【Cocoa練習帳】
<a href="http://www.bitz.co.jp/weblog/">http://www.bitz.co.jp/weblog/</a><br />
<a href="http://ameblo.jp/bitz/">http://ameblo.jp/bitz/</a>（ミラー・サイト）<br />
<a href="https://t.co/6P3h2jtbRk</a>note<br />
line monitor > 消費電流の計測 (151221) > WiFi使用時: 5.38V 350mA > 9.5時間はもちそうだ

line monitor
http://qiita.com/7of9/items/028556c5a819a6a8de96

```txt:動作確認
Raspberry Pi2 + raspbian
Anker Astro E1 (5200mAh)

```

http://qiita.com/7of9/items/df5480b0152b54f78250
の消費電流の計測の続き。

気になっていたWiFi使用時の計測。


## 条件

- 7セグメントLEDオン : IPアドレスの表示
- USBシリアルケーブル x 2
- WiFi接続 (PLANEXのGW-USNANO2A)
- 9600bpsで通信を続けている


Astro E1からPi2へのUSB接続の途中でCHARGER Doctorを挿して電圧と消費電流を計測したのが以下。

- 電圧: 5.35V から 5.38V
- 消費電流: 0.32A から 0.35A

有線接続の時は以下だった。

> - 電圧: 5.25V
> - 消費電流: 0.30A (300mA)

電圧が何故上がるのか理解していない。

消費電流は最大50mA程度上がっている。
5.38V * 50mA = 269mWの増加。

GW-USNANO2A が最大1.3Wというのからすると269mWは小さい。


## 動作時間の計算

0.35A (350mA)として計算

5200mAh * 0.64 / 350mA = 9.5h

0.64の係数は有線接続時の計測から得た値。

だいたい9.5時間はもちそうだ。