OmniAICreator/Qiita-1.07M huggingface dataset:
ArduinoとProcessingでシリアル通信（2） ProcessingからArduinoに値を送ってみる


作業を開始する前に以下のことを確認してください。

* ArduinoはMacに接続されているか？
* Arduinoの電源ランプ（ONと書かれているLED）は点灯しているか？
* Processingのスケッチを実行していないか？
  * なにか実行していたら停止ボタンを押して停止しておこう

スケッチの入力は、最初はとりあえずコピペで。
うまく動いたら、コピペせずに手入力してもういちど実行してみよう。

# Arduino側

Processing側が起動しているとArduinoに書き込めないので、Arduino側から作業する。

## シリアルポートを選択する
![select_serial_port.png](https://qiita-image-store.s3.amazonaws.com/0/26038/e55081ae-64b0-b39b-d450-e1b9957b4cca.png "select_serial_port.png")

*/dev/tty.usbmodem1411* の部分は名前が実行するMacによって異なる

## Arduinoにスケッチを書き込む

```read_from_serial.ino
int val;

void setup(){
  pinMode(13, OUTPUT);
  Serial.begin(9600);
}

void loop() {
  if(Serial.available() > 0) {
    val = Serial.read();
    if(val == 1) {
      digitalWrite(13, HIGH);
    }
    else {
      digitalWrite(13, LOW);
    }
  }
}
```

「検証」をクリックして「コンパイル終了」と表示されたら、「マイコンボードに書き込む」をクリックしてArduinoに書き込む。

"L"と横に書かれているLEDが消灯していることを確認する。


# Processing側

## スケッチを準備する
シリアルポートの指定を前述の「シリアルポートを選択する」で選んだシリアルポートにあわせて書き換えるのを忘れずに。

```write_to_serial.pde
// シリアルライブラリを取り入れる
import processing.serial.*;

// myPort（任意名）というインスタンスを用意
Serial myPort;

int on = 0;

void setup(){
  // 画面サイズ
  size(128, 128);

  // シリアルポートの設定
  myPort = new Serial(this, "/dev/tty.usbmodem1411", 9600);
  myPort.write(0);
}

void draw() {
  if(on == 1) {
    // 背景色を白に設定
    background(255);
  }
  else {
    // 背景色を黒に設定
    background(0);
  }
}

void mouseClicked() {
  if(on == 0) {
    on = 1;
  } else {
    on = 0;
  }
  myPort.write(on);
}
```


## スケッチを実行する

▶ ボタンを押して実行する

Processingの実行画面をクリックするたびに背景の白黒が切り替わる。

* Processing実行画面の背景が白のときにLED(L)が点灯
* Processing実行画面の背景が黒のときにLED(L)が消灯

Processing実行画面をクリックして、LED(L)の点灯/消灯が切り替わることを確認する。
Swiftで新しい演算子を定義する


```lang:Swift


class MyNumber {
    var value = 0
    init(value: Int) {
        self.value = value
    }
}

let a = MyNumber(value:3)
let b = MyNumber(value:5)

infix operator ^-^ { }

func ^-^(lhs: MyNumber, rhs: MyNumber) -> MyNumber{
    return MyNumber(value: lhs.value + rhs.value)
}

// 結果は8
let c = a ^-^ b

infix operator ** { }

func **(lhs: Double, rhs: Double) -> Double {
    return pow(lhs, rhs)
}

// 結果は25
let d = 5.0 ** 2.0


```

使えるのは以下のものだけのようですね
/ = - + * % < > ! & | ^ . ~
Point Cloud Library (PCL)のviewerを正射影にする

======

キーボード
---

PCLViewerで`o`を押すと，透視投影と正射影が切り替わる．

- [r1788で取り込まれた](http://www.pcl-users.org/PCL-Visualizer-or-Cloud-Viewer-ortho-view-mode-td3170038.html)
- [実装はinteractor_style.cpp](https://github.com/PointCloudLibrary/pcl/blob/6b53ae24c451c8438a2283ad20f27ec2e91a8242/visualization/src/interactor_style.cpp)


コード
---
viewerからvtkにアクセス
- [manual_registration.cpp ](https://github.com/PointCloudLibrary/pcl/blob/71639c5618ea4fee9e4846a3f68232cf7100ca63/apps/src/manual_registration/)より

```c++:透視投影
viewer->getRenderWindow ()->GetRenderers()->GetFirstRenderer()->GetActiveCamera()->SetParallelProjection(0);
```

```c++:正射影
viewer->getRenderWindow ()->GetRenderers()->GetFirstRenderer()->GetActiveCamera()->SetParallelProjection(1);
```
(CentOS5,6)OpenSSL CCSインジェクションyumでの確認方法

CentOS5.xの場合
=====
https://rhn.redhat.com/errata/RHSA-2014-0624.html

~~~
$# yum info openssl
省略
Version    : 0.9.8e
Name        : openssl
Arch        : x86_64
Release    : 27.el5_10.3
~~~
27.el5_10.3であれば対応済み


CentOS6.xの場合
=====

https://rhn.redhat.com/errata/RHSA-2014-0625.html

~~~
$# yum info openssl
省略
Name        : openssl
Arch        : x86_64
Version     : 1.0.1e
Release     : 16.el6_5.14
~~~~
16.el6_5.14であれば対応済み

未対応の場合
====

~~~
$yum update openssl -y
~~~

OpenSSLを使っているサービスの再起動
====

安全のためにリブートしましょう

~~~
$reboot
~~~
CLGeocoderを使って郵便番号を住所に変換する

```objc
#import <CoreLocation/CoreLocation.h>

CLGeocoder *geocoder = [[CLGeocoder alloc] init];

[geocoder geocodeAddressString:@"100-0001" completionHandler:^(NSArray *placemarks, NSError *error) {
    CLPlacemark *placemark = placemarks.firstObject;

    NSString *prefectureString = placemark.administrativeArea;
    NSString *cityString       = placemark.locality;
    NSString *streetString     = placemark.subLocality;

    NSLog(@"Prefecture:%@", prefectureString);
    NSLog(@"City:%@", cityString);
    NSLog(@"Street:%@", streetString);
}];
```

正ジオコーディングは位置情報サービスの使用許可を求めるアラートが出ない。

郵便番号は以下のどの形式でもOK。

* 100-0001
* 1000001
* 〒100-0001
* 〒1000001

※追記
`1000001`
この形式だとうまく引っかからない場合があるので、頭に`〒`を付けておくと安全。
Scalaのパターンマッチングで謎の振る舞いの違い…?


大文字と小文字でなんで振る舞いが変わってくるんだろう…?

```scala
  sealed abstract class Things
  case object A extends Things
  case object B extends Things
  case object C extends Things

  def test1(things: Things) = things match {
    case A => println("A")
    case B => println("B")
  }                                               //> test1: (things: test.Things)Unit

  def test2(things: Things) = things match {
    case B => println("B")
    case A => println("A")
  }                                               //> test2: (things: test.Things)Unit

  test1(A)                                        //> A
  test2(A)                                        //> A
  test1(B)                                        //> B
  test2(B)                                        //> B
  test1(C)                                        //> scala.MatchError: C (of class test$C$)
                                                  //| 	at test$$anonfun$main$1.test1$1(test.scala:8)
                                                  //| 	at test$$anonfun$main$1.apply$mcV$sp(test.scala:22)
                                                  //| 	at org.scalaide.worksheet.runtime.library.WorksheetSupport$$anonfun$$exe
                                                  //| cute$1.apply$mcV$sp(WorksheetSupport.scala:76)
                                                  //| 	at org.scalaide.worksheet.runtime.library.WorksheetSupport$.redirected(W
                                                  //| orksheetSupport.scala:65)
                                                  //| 	at org.scalaide.worksheet.runtime.library.WorksheetSupport$.$execute(Wor
                                                  //| ksheetSupport.scala:75)
                                                  //| 	at test$.main(test.scala:6)
                                                  //| 	at test.main(test.scala)
  test2(C)
```

```scala
  sealed abstract class Things
  case object a extends Things
  case object b extends Things
  case object c extends Things

  def test1(things: Things) = things match {
    case a => println("a")
    case b => println("b")
  }                                               //> test1: (things: test.Things)Unit

  def test2(things: Things) = things match {
    case b => println("b")
    case a => println("a")
  }                                               //> test2: (things: test.Things)Unit

  test1(a)                                        //> a
  test2(a)                                        //> b
  test1(b)                                        //> a
  test2(b)                                        //> b
  test1(c)                                        //> a
  test2(c)                                        //> b
```
ArduinoとProcessingでシリアル通信（1） ArduinoからProcessingに値を送ってみる


作業を開始する前に以下のことを確認してください。

* ArduinoはMacに接続されているか？
* Arduinoの電源ランプ（ONと書かれているLED）は点灯しているか？
* Processingのスケッチを実行していないか？
  * なにか実行していたら停止ボタンを押して停止しておこう

スケッチの入力は、最初はとりあえずコピペで。
うまく動いたら、コピペせずに手入力してもういちど実行してみよう。

# Arduino側

Processing側が起動しているとArduinoに書き込めないので、Arduino側から作業する。

## シリアルポートを選択する
![select_serial_port.png](https://qiita-image-store.s3.amazonaws.com/0/26038/e55081ae-64b0-b39b-d450-e1b9957b4cca.png "select_serial_port.png")

*/dev/tty.usbmodem1411* の部分は名前が実行するMacによって異なる

## Arduinoにスケッチを書き込む

```send_to_serial.ino
void setup(){
  Serial.begin(9600);
}

void loop(){
  Serial.write(100);
  delay(1000);
  Serial.write(200);
  delay(1000);
}
```

「検証」をクリックして「コンパイル終了」と表示されたら、「マイコンボードに書き込む」をクリックしてArduinoに書き込む。


# Processing側

## スケッチを準備する
シリアルポートの指定を前述の「シリアルポートを選択する」で選んだシリアルポートにあわせて書き換えるのを忘れずに。

```read_from_serial.pde
// シリアルライブラリを取り入れる
import processing.serial.*;

// myPort（任意名）というインスタンスを用意
Serial myPort;

int x; //図形のX座標の変数を用意

void setup(){
  // 画面サイズ
  size(256, 256);

  // シリアルポートの設定
  // "/dev/tty.usbmodem1411" の部分を前述の「シリアルポートを選択する」で選択したシリアルポートにあわせて書き換える
  myPort = new Serial(this, "/dev/tty.usbmodem1411", 9600);
}

void draw(){
  // 背景色を白に設定
  background(255);
  
  // XY座標を(x,100)に設定し、
  // 幅50、高さ50の円を描画
  ellipse(x,100,50,50);
}

void serialEvent(Serial p){
  //変数xにシリアル通信で読み込んだ値を代入
  x = p.read();
  println(x);
}
```


## スケッチを実行する

▶ ボタンを押して実行する

Processingの実行ウィンドウに表示されている円が左右に動いていれば成功
ShellScript から ikachan を経由して色付きの通知を送るための知見

まず、IRCで色付きの文字列を出力するための特殊文字を理解する。

* https://github.com/banyan/string-irc/blob/master/lib/string-irc.rb#L4-L27

RFCを見るのも大変なんで、この辺を見て頑張る。

で、シェルでこれらの特殊文字を出す方法については、 `echo(1)` のマニュアルを見ると、 `-e` オプションでエスケープシーケンス（\）を認識させることができるのそうなので利用する。

`\000` みたいな表記で任意のコードポイントを出せる。ただし、8進法である。可読性のため以下のように関数を作っておく。

```bash
color_chr() {
    echo -en "\003"
}

end_chr() {
    echo -en "\017"
}

bold() {
    echo -en "\002"
}
```

任意の色を出すのはこんな感じ。

```bash
yellow() {
    color_chr; echo "8"
}

green() {
    color_chr; echo "3"
}

red() {
    color_chr; echo "4"
}
```

これを

```bash
notify_ikachan() {
    message=$( cat - )
    curl -s -X POST -d channel=$IKACHAN_CHANNEL $IKACHAN_HOST/join > /dev/null
    curl -s -X POST -d channel=$IKACHAN_CHANNEL -d message="$message" $IKACHAN_HOST/notice > /dev/null
}
```

こんな感じの関数に噛ませる

```bash
echo "$(red)Hello, $(green)cluel $(yellow)world.$(end_chr) normal $(bold)bold" | notify_ikachan
```

### 結果です

![result](https://qiita-image-store.s3.amazonaws.com/0/569/92f5da4b-deff-2655-0984-df67d4457d0f.png)

### まとめ

Jenkinsの結果通知〜とかシェルスクリプトでさくっとやりたい時はこんな感じで。さくっと感無いかもしれませんが...。
Luhn アルゴリズムでクレジットカード番号チェック

※　カード番号はすべて公式ダミー番号です。

```java

import java.util.*;
import java.lang.*;
import java.io.*;

class Main
{

	public static boolean hasExp(String cardNumber) {
		StringBuilder _cardNumber = new StringBuilder(19);
		_cardNumber.append(cardNumber);
		while (_cardNumber.length() < 19) {
			_cardNumber.append('0');
		}

		char[] charArray = _cardNumber.toString().toCharArray();

		boolean eve = true;
		int sum = 0;
		int index = 0;
		for (Character c : charArray) {
			index++;
			if (index == 19) {
				break;
			}
			if (eve) {
				sum += (Integer.valueOf("" + c) * 2) % 9;
			} else {
				sum += (Integer.valueOf("" + c));
			}
			eve = !eve;
		}
		Integer a = Integer.valueOf((sum % 10) + "");
		Integer b = Integer.valueOf(charArray[18] + "");
		return a == b;
	}

	public static void main (String[] args) throws java.lang.Exception
	{
		// Approved
		System.out.println(hasExp("4000000000000010"));
		System.out.println(hasExp("4000000000000028"));
		System.out.println(hasExp("4000000000000036"));
		System.out.println(hasExp("5100000000000016"));
		System.out.println(hasExp("5100000000000024"));
		System.out.println(hasExp("5100000000000032"));
		// Declined
		System.out.println(hasExp("4000000000000044"));
		System.out.println(hasExp("5100000000000040"));
		// PickUpCard
		System.out.println(hasExp("4000000000000069"));
		System.out.println(hasExp("5100000000000065"));
		// ReferToIssuer
		System.out.println(hasExp("4000000000000051"));
		System.out.println(hasExp("5100000000000057"));
		// Voided
		System.out.println(hasExp("4000000000000085"));
		System.out.println(hasExp("5100000000000081"));
	}
}
```
homebrewでOpenSSLを1.0.1hへ更新

![logo.png (240×240)](http://ccsinjection.lepidum.co.jp/assets/imgs/logo.png)
1.0.1hは **CVE-2014-0224** 対策版です。
早めに更新しましょう。
#バージョン確認
OpenSSL 1.0.1gです。

```bash
$ openssl version
OpenSSL 1.0.1g 7 Apr 2014
$ brew info openssl
openssl: stable 1.0.1g (bottled)
```
#まずhomebrewのデータベースを更新

```bash
$ brew update
```
更新できたか確認します。

```bash
$ brew info openssl
openssl: stable 1.0.1h (bottled)
```
更新できてます。
#OpenSSL更新

```bash
$ brew upgrade openssl
==> Upgrading 1 outdated package, with result:
openssl 1.0.1h
==> Upgrading openssl
==> Downloading https://downloads.sf.net/project/machomebrew/Bottles/openssl-1.0
######################################################################## 100.0%
==> Pouring openssl-1.0.1h.mavericks.bottle.tar.gz
==> Caveats
A CA file has been bootstrapped using certificates from the system
keychain. To add additional certificates, place .pem files in
  /usr/local/etc/openssl/certs

and run
  /usr/local/opt/openssl/bin/c_rehash

This formula is keg-only, so it was not symlinked into /usr/local.

Mac OS X already provides this software and installing another version in
parallel can cause all kinds of trouble.

The OpenSSL provided by OS X is too old for some software.

Generally there are no consequences of this for you. If you build your
own software and it requires this formula, you'll need to add to your
build variables:

    LDFLAGS:  -L/usr/local/opt/openssl/lib
    CPPFLAGS: -I/usr/local/opt/openssl/include

==> Summary
&#127866;  /usr/local/Cellar/openssl/1.0.1h: 429 files, 14M
```
#利用可能か確認

```bash
$ openssl version
-bash: /usr/local/bin/openssl: No such file or directory
$ which openssl
/usr/bin/openssl
```
ダメです。
`brew upgrade openssl`のログに

```bash
This formula is keg-only, so it was not symlinked into /usr/local.
```
とあったように、まだリンクされていません。
#homebrewでインストールしたOpenSSLを使うようにリンクさせる

```bash
$ brew link openssl --force
Linking /usr/local/Cellar/openssl/1.0.1h... 1139 symlinks created
$ openssl version
OpenSSL 1.0.1h 5 Jun 2014
$ which openssl
/usr/local/bin/openssl
```
これでOpenSSL 1.0.1hが利用可能になりました。
#Ruby再インストール
[homebrewでOpenSSLの脆弱性対策版を入れたのでRubyも更新させる - 別館 子子子子子子（ねこのここねこ）](http://d.hatena.ne.jp/riocampos+tech/20140408/ruby_reinstall_caused_by_openssl_vulnerability)

#ログ付き記事
[homebrewでOpenSSLを1.0.1hへ更新 - 別館 子子子子子子（ねこのここねこ）](http://d.hatena.ne.jp/riocampos+tech/20140606/update_to_openssl_1_0_1h)
SVNリポジトリをリビジョン番号付きでバックアップする

[特定の日付より新しいSVNリポジトリをバックアップする](http://qiita.com/drafts/c37506284cace77403df/)のリビジョン番号付きバージョン。

- `svnlook youngest REPOS_PATH`でリビジョン番号が取れる。
- `repos.123.svn.dump.gz`とかいうファイル名でダンプする。
- 既に同名かつ同リビジョンのダンプがあれば何もしない。

```shell-session:backup_svn.sh
ACCOUNTS=`ls -1 /srv/svn/`
for ACCOUNT in $ACCOUNTS; do
    SRC=/srv/svn/$ACCOUNT
    REV=`svnlook youngest $SRC`
    DST=/var/backups/svn/$ACCOUNT.$REV.svn.dump.gz
    if [ ! -e $DST ]; then
        time svnadmin dump $SRC 2> backup_svn.log | gzip > $DST
        echo "backup svn from $SRC to $DST r$REV: `ls -hs $DST`"
    fi
done
```
Ubuntu Server 12.04 to 14.04 メモ

Ubuntu Server 12.04を14.04にアップグレードした際のメモ。
※VirtualBoxで何度か試した結果のまとめ。

##アップグレード前の準備

###SSH用にポート1022を開けておく
アップグレード中にトラブルがあってSSHが切断したときのために、アップグレード中は代わりのポートを自動的に用意してくれるので、あらかじめファイアーウォールの設定を変えておく。

```
sudo ufw allow 1022
```
何も起こらなければ使わない。

###Apacheのsiteファイルに拡張子を付けておく
apache2.confの記述が `IncludeOptional sites-enabled/*.conf` となっているので、拡張子.confが必須になった。
拡張子なしで運用してた場合は、アップグレード前にリネームしておく。

```
cd /etc/apache2/sites-available
sudo a2dissite example.com
sudo mv example.com example.com.conf
sudo a2ensite example.com.conf
sudo service apache2 reload
```

その他、設定ファイルのディレクトリ構成も変わっているが、自分の環境では特に影響なかった。

###ApacheのOptionsの書き方を確認する
```Indexes```や```FollowSymLinks ```等の項目にプラス・マイナス記号を付けるときは、すべての項目に付けないとエラーが出るようになった。

例えばインデックス表示を禁止しようとして、```Options -Indexes FollowSymLinks MultiViews```のように書くと、構文エラーとなって以下のメッセージが表示される。

```
Either all Options must start with + or -, or no Option may.
```

「+-を全てに付けるか、1つも付けないか、どちらかにしてください」ということなので、以下のように、どちらかの書き方に修正しておく。

```
Options -Indexes +FollowSymLinks +MultiViews
```
```
Options  FollowSymLinks MultiViews
```

##アップグレード

```
do-release-upgrade -d
```

* 途中、php.iniを置き換えるか聞かれるので、デフォルトのまま現状維持(keep the local version currently installed)を選択。パッケージ標準の設定ファイルは`/etc/php5/apache2/php.ini.ucf-dist`に置かれる。
* 自分の環境では20分で完了。

##アップグレード後
アップグレード前に開けたポート1022を閉じる。

```
sudo ufw delete allow 1022
```

##Apache
バージョン：2.2.22 => 2.4.7

設定ファイルの構成が変わった。

* `/etc/apache2/sites-available`以下のファイルに拡張子.confが必要になった。
* defaultのDocumentRootが`/var/www`から`/var/www/html`に変更。自動的に`/var/wwww/html`が作成された。
* （よく分かってないが）index.htmlが勝手に`/var/www/html`に移動されてしまった。DocumentRootは`/var/www`のままだったので、インデックスが丸見えに。index.htmlが初期状態から変更されている場合は勝手に移動されない模様（？）
* [Upgrading to 2.4 from 2.2](http://httpd.apache.org/docs/2.4/upgrading.html)によると、アクセス制御の方法が変わって```Deny from all```等は非推奨になったようだが、[mod_access_compat](http://httpd.apache.org/docs/current/ja/mod/mod_access_compat.html)が有効になっているのですぐに修正しなくても大丈夫。アップグレードが無事に完了してから修正すればいい。

##MySQL
バージョン：5.5.37 => 5.5.37
変更なし？

##PHP
バージョン：5.3.10 => 5.5.9

* OPcacheが最初から有効になっている。APCを使っていた場合は更新後に動かなくなる。

php.iniの変更点

###削除された項目
register_globalsやmagic_quotes等、
元から推奨されてなかった設定なので影響なし。

```
y2k_compliance = On
allow_call_time_pass_reference = Off
safe_mode = Off
safe_mode_gid = Off
safe_mode_include_dir =
safe_mode_exec_dir =
safe_mode_allowed_env_vars = PHP_
safe_mode_protected_env_vars = LD_LIBRARY_PATH
register_globals = Off
register_long_arrays = Off
magic_quotes_gpc = Off
magic_quotes_runtime = Off
magic_quotes_sybase = Off
define_syslog_variables  = Off
```

###コメントアウトされた項目
```
;session.entropy_length = 32
```

###設定が変更された項目

```
short_open_tag = Off
html_errors = On
error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT // ~E_STRICTが追加
```

###追加された項目
PHP5.5.2で追加されたstrict sessions関連（[参考](http://blog.tokumaru.org/2013/08/php-5.5.2-strict-sessions.html)）

```
cli_server.color = On
session.use_strict_mode = 0
```

###スペルミス修正
PHP5.5.2で修正されたみたい。（[参考](http://git.php.net/?p=php-src.git;a=commitdiff;h=b8941a73cce0aacdb21f04528dc0dbc3c951ab92)）

```
mssql.compatability_mode = Off
　　　　　　　↓
mssql.compatibility_mode = Off
```
テストターゲットからアプリターゲットを参照する #Swift

https://twitter.com/clattner_llvm/status/474730716941385729

<blockquote class="twitter-tweet" data-partner="tweetdeck"><p>Namespacing is implicit in swift, all classes (etc) are implicitly scoped by the module (Xcode target) they are in. no class prefixes needed</p>&mdash; Chris Lattner (@clattner_llvm) <a href="https://twitter.com/clattner_llvm/statuses/474730716941385729">June 6, 2014</a></blockquote>
<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>

によると、SwiftのコードはXcodeのターゲット単位がモジュール＝ネームスペースとして扱われるようです。

そのためか、Swiftのプロジェクトでテストターゲットのテストクラスからアプリターゲット内のクラスを参照・使用するには以下のようにアプリターゲット名をモジュールとしてインポートする必要があります。

```swift
// アプリターゲット名が SampleApp とする。

import XCTest
import SampleApp

class SampleAppTests: XCTestCase {
    override func setUp() {
        super.setUp()
    }
    
    override func tearDown() {
        super.tearDown()
    }

    func testExample() {
        let model: Model? = Model() // defined in SampleApp target (module)
        XCTAssert(model != nil)
    }
}
```

ちなみに`import SampleApp.AppDelegate`のような特定のクラスを指定しても、それはモジュールではないとしてコンパイルエラーになります。
Yes, No を 0, 1 に変換する簡単なやり方

Yes, No みたいなカテゴリカル変量を、Yes の列、No の列にダミー変数みたいにわけて書き出したいときがあります。
[TJO さんのブログ記事](http://tjo.hatenablog.com/entry/2014/04/10/190203)のまさにこの状況なんですが。

![TJO.png](https://qiita-image-store.s3.amazonaws.com/0/2570/ef22343a-f027-2f4b-e403-5cda8fd2e551.png)


こんなときに便利なのが `nnet::class.ind` です。

```r
library(nnet)
yn <- c("Yes", "No", "No", "No", "Yes", "No")
class.ind(yn)
```

```:結果
     No Yes
[1,]  0   1
[2,]  1   0
[3,]  1   0
[4,]  1   0
[5,]  0   1
[6,]  1   0
```

一発で変換完了。便利。

やはりニューラルネット使うときは出力層をこういう風に変換したいときが多いからこんな便利関数があるんでしょうかね～。

以上です。
OpenSSL脆弱性(CVE-2014-0224)(Heartbleedより脅威？)のubuntuの対応

# OpenSSLに新たな脆弱性
[OpenSSLにまた重大な脆弱性、直ちにパッチ適用を](http://www.itmedia.co.jp/enterprise/articles/1406/06/news034.html)
[OpenSSLに再び脆弱性、MITM攻撃につながる恐れ](http://www.atmarkit.co.jp/ait/articles/1406/06/news037.html)
[OpenSSLの脆弱性CCS Injection(CVE-2014-0224)の攻撃が行われる恐れがあるパターンをマトリックス化してみた。](http://d.hatena.ne.jp/Kango/20140605/1401978480)

# ubuntuの対応

とりあえず、ubuntuのページをみる
[USN-2232-1: OpenSSL vulnerabilities](http://www.ubuntu.com/usn/usn-2232-1/)

手順があった
[Upgrades](https://wiki.ubuntu.com/Security/Upgrades)

## DeskTop(PCのこと)の場合
`Alt+F2`を押して、`update-manager`と入力。
あとは、更新して再起動で完了。

## Server(サーバー)の場合
以下を実行
```
$ sudo apt-get update
$ sudo apt-get dist-upgrade
```
たぶん、再起動必要。
```
$ sudo reboot
```

確認
```
dpkg -l | grep openssl
```

OSのバージョンごとの最終的に更新されるべきパッケージは、以下の下の方にあります。
[Update instructions](http://www.ubuntu.com/usn/usn-2232-1/)

ちなみに、以下の方法もちょこっと書いてありましたが、
`sudo dpkg-reconfigure unattended-upgrades`
利用中のサービスの再起動が入るので、すべての環境に適さないとあります。
特定の日付より新しいSVNリポジトリをバックアップする

SVNリポジトリの引越のためにバックアップのスクリプトを書いた。

関連リンク: [SVNリポジトリをリビジョン番号付きでバックアップする](http://qiita.com/61503891/items/1044cbfcb02d3895fb71)

### 要件

- サーバまるごと一気に飛び移る。
     - サーバ多重化して軟着陸？やりません（ｷﾘｯ）
- リポジトリは沢山ある。
    - 全てフルダンプはかなり時間がかかる。
    - 日時を指定してそれ以降に更新があったリポジトリだけ差分ダンプしたい。
- 日付の比較はどうするか？
    - SVNリポジトリのファイル更新日とバックアップファイルの更新日の比較は何か怖い気がする。
    - `svnlook date`を使うべし。

### メモ

- 日付処理には`date`コマンドが使える。
    - ただし、`date`コマンドはLinuxとUNIXとではオプションが異なるので注意する。
- SVNのリポジトリの日付の取得には`svnlook date`が使える。
    - ただし、これを`date`コマンドに食わせてもうまく解釈くれなかった。
    - Rubyの`DataTime`は食べてくれた。

### スクリプト

- SVNリポジトリをバックアップする。
    - バックアップには`svnadmin dump`に加えて`gzip`による圧縮を使う。
    - バックアップファイルが存在しない場合はバックアップを実行する。
    - バックアップファイルが存在する場合でも`TARGET_DATE`より更新日が新しい場合は上書きバックアップする。

```shell-session:backup_svn.sh
TARGET_DATE=`date --date '2014-06-05' +%s`

ACCOUNTS=`ls -1 /srv/svn/`
for ACCOUNT in $ACCOUNTS; do
    SRC=/srv/svn/$ACCOUNT
    DST=/var/backups/svn/$ACCOUNT.svn.dump.gz
    SRC_DATE=`svnlook date $SRC | ruby -e "require 'date'; puts DateTime.parse(gets).to_time.to_i"`
    DST_DATE=`date -r $DST +%s`
    if [ ! -e $DST ]; then
        time svnadmin dump $SRC 2> backup_svn.log | gzip > $DST
        echo "backup svn from $SRC to $DST: `ls -hs $DST`"
    elif [ $SRC_DATE -gt $TARGET_DATE ]; then
        time svnadmin dump $SRC 2> backup_svn.log | gzip > $DST
        echo "backup svn from $SRC to $DST: `ls -hs $DST`"
    fi
done
```

めでたし。
独書会 Scala IN DEPTH @大人の喫茶店 その2


# In this chapter

- Using the Scala Read Eval Print Loop
- Expression-oriented programming
- Immutability
- The Option class

# 要約

Scalaエンジニアが知っている必要があるいくつかのtopicsについての説明。

## Learn to use the Read Eval Print Loop (REPL)

- __REPL__とは、Scalaを動かせるインタラクティブシェル
- Scalaをインストールしてパスを設定していれば使える
- ターミナルで`scala`と入力して、REPLを起動する
- 出力は、`変数名: 式の静的な型 = 結果の値`と読み取る
- `結果の値は`、通常JVM内の全てのクラスで定義されている`toString`メソッドの呼び出し結果

### Experiment-driven development(EDD)

- テストやプロダクションコードを書く前に、REPLで試す、実験主導型の開発


### TDD

- テストコードを最初に書いてから、クラスの実装をする開発アプローチ。
- TDDの要素は、テストを通してAPIを定義すること。
- コンテキストで自分のコードを見ることができ、使いたいコードかどうかの感触を得れる。
- 厳密な型付け言語は、高度な表現ができるので、TDDを使う動的言語よりもずっと多くの問題を提示することができる。
- REPLを使うことは、テストを作る前にEDDがAPI定義フェーズを作ることができる。型システム内でAPIを試すことができるので。
- EDD開発は、API内で可能な限り有効な型を利用するために、型システムのREPL内で実験することを必要とする。
- 実験駆動デザインは、新しいメソッドやバグフィックスをするよりは、大きな機能やドメインを追加する時に必要になる。
- 実験駆動設計は、DSLを定義するときにも助けになる。
- DSLとは、特定のドメインを扱うための擬似プログラミング言語。
- DSLを定義するときの課題の一つは、効率的に型システムを使うことである。


## 式を考える

- __Expression-oriented programming__ (式指向プログラミング)とは、文よりも式を使うことを述べる時に使う用語
- 文は実行するもの。コードを実行する
- 式は評価するもの。つまり値を変えす
- 式は値を得るために評価るするコードブロック
- Scalaでは、いくつかの制御ブロックが式
- 制御が分岐であったとしても、各々の分岐は値を返す
- 例えばif節は、Javaの三項演算子と同じで値を返す
- Scalaでは、式から値を返さない文はほとんどない

## returnを使うな

- 式を使うポイントは、`return`文を使わないことを理解すること。
- 式は値を得るために評価するから、`return`は必要ない。

## Mutability

- immutablilityとは、オブジェクトまたは変数の不変の状態のこと。それはmutablilityの反対。
- mutablilityとは、ライフサイクルの中で変更したり変異したりするオブジェクトや変数の能力。
- 式にMutabilityな文を混ぜると、コードの明確性が減ってくる。これはimmutable codeを好む理由の一つになる。

# Rule

## 1. REPLで経験する

- ScalaはREPLツールを提供しているので、開発者は最終的なコードをコミットする前に色々といじることができる。
- Scalaのエコシステムで最も便利なツールなので、開発者はREPLで開発を開始できる。

## 2. 文ではなく式

- 多くのコードは1つの式の小さなメソッドとして書かれている。
- このスタイルはエレガントではないけど、コードの保守で役に立つ。


# 所感

- REPL推しが凄い
- EDDという新しいスタイル
- Functional programmingからいつの間にかExpression-oriented programmingに切り替わっていた。。。
- immutabilityを突き進めると、きっと`clone`メソッドではなくコピー関数が必要になるんだよね。
    - いちいち`new`しないといけない、そこだけが嫌かな。
slimでTumblrのテーマを書く


slim記法を使ってtumblrのテーマを書こうと思うと、slimのシンタックスで書けなくて不便だったので、簡単なヘルパを書いて誤魔化します。

別な応用例として、ちょっと改変すればWordPressやMovableTypeのテーマを作る時にMiddlmanのようなruby界隈の仕組みの恩恵が受けられるでしょう。

middlemanでslim使ってる前提で書きます。

```config.rb
# 適当な位置に以下の項目を追加します
require 'lib/tumblr_helper'
helpers TumblrHelper
```

```lib/tumblr_helper.rb
module TumblrHelper

  def tumblr_block(tag, &block)
    content = capture_html(&block)

    "{#{tag}}#{content}{/#{tag}}".html_safe
  end

  # capture_html というのを使っているが、Railsでは単にcaptureという名前が使われてる事もあるみたい。
  # 詳しくは content_tagの実装を追って下さい。
end
```

使い方は以下の通り

```tumblr.slim
body
  .main.container
    = tumblr_block "block:Posts" do
      article
		a href="{Permalink}" リンク
```
jQueryを使うべきところ 〜 JSおくのほそ道 #009

> **「jQueryいつ使うの！？」**
> **「今でしょ・・・？」**

こんにちはほそ道です。
というわけで今回からjQueryに取り組みます。

ですが、いきなり飛びつかない！
まずはライブラリを疑うところからはじめていきたいと思います。

昨今、とりあえずサイトにjQuery入れとけ的なアプローチだったり
ネイティブJSで書ける処理をわざわざjQueryで書いているような開発者を目にする事があります。
あえて始めに言わせていただきたい！

**JSライブラリを使う事のメリット/デメリットを強く意識しましょう！**
**ライブラリ使う前にネイティブJS書けるようになりましょう！**

[目次はこちら](http://qiita.com/setzz/items/ad9a9c99a4fda041a563)

# jQueryとは？

![スクリーンショット 2014-06-02 10.06.29.png](https://qiita-image-store.s3.amazonaws.com/0/39330/7f2266f6-0cad-3b4f-49a1-4cd5757790fc.png)


いつものごとく公式ページから拝借・意訳します。

- 高速・軽量・リッチなJavaScriptライブラリ。
- 様々なブラウザ環境で簡単なAPIからイベントハンドリングやアニメーションやAjaxがうまいこと実現できる。
- 多彩かつ拡張的で100万人以上ののJavaScript記述の世界をを変えた。

ほほぅ。高速という謳い文句は非常に気になりますが、他のライブラリとの比較でしょうね。

学習や調査の際には下記のオフィシャルリンクが使えるかと思います。

- [jQueryラーニングセンター](http://learn.jquery.com/)
- [APIドキュメント](http://api.jquery.com/)
- [プラグインレジストリ](http://plugins.jquery.com/)
- [jQueryのうたw](https://www.youtube.com/watch?v=VCkMeUHFql4&feature=kp)

# バージョン１系と２系の違い

現在の最新バージョンは２系が2.1.1、１系が1.11.1となります。
[ブラウザサポートページ](http://jquery.com/browser-support/)にサポート環境情報が載っております。

- ２系はレガシーブラウザIE6〜8をサポートしない。IE6〜8にサポートするなら１系を使用する。
- Node.js、ブラウザエクステンション、その他ブラウザ以外の環境では２系での仕様をサポートしている。

なるほど、まぁBtoCサイトなどは１系を使う事になるのでしょうね。

# ネイティブコードとの比較した際のメリット/デメリット

下記の様なメリット/デメリットを意識する事はとっても大事です。

- **メリット**
    - 記述量が減らせる(事が多い)
    - クロスブラウザ対応を意識せずに書ける
    - 拡張プラグインを使う事で少ない記述でリッチな処理が実現出来る

- **デメリット**
    - 高速を謳っているが、ネイティブJSとの比較では相当遅い
    - 裏側でどんな処理が行われているかを概ね理解していないと副作用が怖い
    - ネイティブJSが解らないのにjQueryでググったコードのコピペを繰り返すエンジニアの増殖

# パフォーマンス検証

jQueryを使う事でどれくらい遅くなってしまうのかいろいろ検証してみました。
フェアになるよう３回ほど実行して平均的な値を記述してます。

## jQueryロードのパフォーマンス

まずはロード時間の計測から。
ローカルファイルのjQueryを呼び出します。

|　| 1.11.1 | 2.1.1 | 1.11.1(min) | 2.1.1(min) |
|---|---|---|---|---|
| **FireFox** | 30ms | 25ms | 20ms | 23ms |
| **Chrome** | 55ms | 50ms | 33ms | 40ms |

勿論ネイティブJS使う場合はこのロード時間は0です。
読み込みのみで、実行は何もしなかった状態ですが仮に20回読み出すと１秒かかる訳で、
結構な時間がかかっている事が解ります。
やはりミニファイされた状態の方がパフォーマンスは良いですね。

## セレクタ処理のパフォーマンス

今度はjQueryとネイティブコードの処理を比較します。
DOM要素を相当回取り出してみます。ブラウザはChromeを使用します。
ネイティブ側は`document.getElementById('hosomichi')`を実行し、
jQuery側は`$('#hosomichi')`を実行します。

|　| 1万回 | 10万回 | 100万回 | 1000万回 |
|---|---|---|---|---|
| **ネイティブ** | 3ms | 13ms | 70ms | 580ms |
| **jQuery** | 30ms | 270ms | 2800ms | 27000ms |

圧倒的な差がつくことがわかりましたね！
「いやいや、こんな反復しないよ！」というご意見もあるかと思いますが
ほそ道は色々な処理の塵はきっちり積もると思ってます。
ちなみに以前、ほそ道の携わったプロジェクトではサイト表示の遅さにメンバーが頭を抱えており
ネイティブコードで書き直すよう伝えただけで後でめちゃ感謝された事がありました。。

# まとめ
というわけで、変にjQueryを用いる事で
jQueryを採用するときは下記の要素あたりを天秤にかけて最低限の判断は行う事が必要となるでしょう。

- **サイトパフォーマンス**
    - 多量の反復処理が走る可能性はないか？
    - ただでさえ画像等で重いページだったりしないか？
- **開発者スキル**
    - 必要な部分のみにjQueryコードを採用できる？
    - デザイナーが設定したjQueryをチューニング出来る？
- **プラグインの選別**
    - パフォーマンスは悪くない？
    - カスタマイズできそう？(やりたい事に対して「惜しい」プラグインは多いです)

今回は以上です。
次回はソースコードと格闘をする準備編として、
[Grunt管理されたjQueryを扱う](http://qiita.com/setzz/items/ed7ce8a443d5245f41a1)というTIPS的なものを紹介します。
Gruntとgulpを比較 〜 JSおくのほそ道 #008

こんにちはほそ道です。
[前々回のGrunt]()と[前回のgulp]()にてそれぞれの基本構造を掘り下げてみたので
２つを対比した感想を述べてみたいと思います。
なお、ほそ道の独断と偏見により書き連ねて参りますので
いずれかのツールのファンの方はお気を悪くされないでくださいませ。

[目次はこちら](http://qiita.com/setzz/items/ad9a9c99a4fda041a563)

# 概念図から比較する

- Grunt

![スクリーンショット 2014-05-25 2.30.09.png](https://qiita-image-store.s3.amazonaws.com/0/39330/7956c7f1-72e3-427e-78b0-9312445698b3.png)

- gulp

![スクリーンショット 2014-05-25 18.39.11.png](https://qiita-image-store.s3.amazonaws.com/0/39330/bfd0ee60-307b-f937-8dcc-468dca354bca.png)


結論、短時間での概念習得に関してはgulpの方が理解し易く、その気になればカスタマイズなども重くなく出来そうです。
gulpは手続型っぽくgulpコマンドのgulp.js内で何となくのシーケンスが把握できます。

図の単純な作成時間は「どうやってまとめよっかなー」的な検討時間も含め
Gruntは4時間ほどかかり、gulpは2時間ほどでした。
Gruntの方がオブジェクト指向的な抽象化が多く細かな責務を分担しており、読み解きに手こずったのが原因かと思います。
ただ、更に理解を深めていくと「よりフレームワーク的」である」Gruntのほうが扱い易いのかもしれません。

# 設定ファイルから比較する

- Grunt

```js:Gruntfile.js
module.exports = function(grunt) {
  grunt.loadNpmTasks('grunt-contrib-uglify');
  grunt.initConfig({
    uglify: {
      target1: {
        src: 'foo.js',
        dest: 'foo.min.js'
      }
    }
  });
  grunt.registerTask('default', ['uglify']);
};
```

- gulp

```js:gulpfile.js
var gulp = require('gulp');
var uglify = require('gulp-uglify');

gulp.task('default', function() {
  gulp.src('foo.js')
    .pipe(uglify())
    .pipe(gulp.dest('dest'));
});
```

ここでもGruntは`config`と`task`で細かな責務分担を行っており、タスクで使用する変数はコンフィグに持たせるポリシーですね。
Gruntfileで気になるのは設定が増えてきた場合に、
ひとつのタスクに対してinitConfigとregisterTaskの記述箇所が離れてしまい一覧性を損ねそうなのが億劫になりそうです。
対してgulpはタスク内にsrcやdestといった情報をそのまま突っ込んでます。
[gulp API リファレンス](https://github.com/gulpjs/gulp/blob/master/docs/API.md)をみても共通的な変数を持たせる仕組みは用意していないように見えます。
あと、gruntはタスクに対してプラグインの名前を指定する形式になっているので処理が定型化されているのも特徴でしょうか。
自作関数も定義できますが提携処理の途中にカスタム処理を挟むのは難しいんではないかと思います。
それぞれの特徴が見えてきました。

# で、どっちが美味いの？

これはもう、ぶっちゃけ好みの問題ですが、ほそ道の雑感を超バッサリまとめると

```text
Grunt:質実剛健、一途に尽くす努力家の忠犬。王貞治／須田開代子タイプ
gulp:ゆるふわでフットワーク軽めの野良猫。長嶋茂雄／中山律子タイプ。
```

「キミが触っていいのはこの範囲だけだよ！」などと
とチームの運用ルール等を細かくしたい場合にはGruntに軍配が上がるように思います。
感覚的にさくさくとタスクを組んだり弄ったりする場合にはgulpの方が自由度が高そうです。

ほそ道的にはビルドツールは毎日触るようなものではないのでライトで迷わない方が好きでありまして
その指向性からするとシンプルで、時にはカスタムもしやすそうなgulpを使いたいなと思いました。

今回は以上です。
次回からはしばらく[jQueryと徹底的に向き合ってみよう](http://qiita.com/setzz/items/f496f130fde47cbc1917)と思います。
gulpとの上手な付き合い方 〜 JSおくのほそ道 #007

こんにちはほそ道です。
前回は[Grunt](http://gruntjs.com/)を掘り下げてみましたが今回は別のビルドツール **gulp** を取り上げてみます。
複数扱う事で理解や幅が広がりますしね。
最終的には２つを対比したいと思いますので、前回同様に概要を探り、サンプルを作り、アーキテクチャを掘り下げてみたいと思います。

バージョンは下記です
gulp version 3.6.2
CLI version 3.6.2

[目次はこちら](http://qiita.com/setzz/items/ad9a9c99a4fda041a563)

# gulp概要
## gulpはどういう特徴があるんですかね？
読みは「ガルプ」のようです。「グイグイ飲む」という意味らしいです。

[gulpのgithub](https://github.com/gulpjs/gulp/blob/master/README.md)を見てみるとgulpは
「The streaming build system」
らしいです。streamingの部分がちょっと何言ってるかわかりません。

[gulpサイト](http://gulpjs.com/)を見ると下記のような売り文句ですね。

**「速い、高品質、習得が楽」**

のような事が書いてあります。
あとは「node.jsのstreamを活用してディスクへの中間ファイル書き込みを行わない高速ビルドが可能」的な事が書いてあります。
やっぱりstreamが出てきますね。

## streamって何ぞ？
うーむ。どうやらこのstreamがgulpのキモな匂いがするので調べてみました。
Node.jsには[stream API](http://nodejs.org/api/stream.html)というインターフェースがあり、I/Oの読み書きを部分的に行ったりしてデータ流れを止めずに効率的に扱う仕組みのようです。
要するにgulpはデータをNode.jsのstreamを効果的に使って処理するので高速性に優れているという事なんでしょうね。

# 動かしてみる

それでは実際に動かしてみます。前回同様ファイルのミニファイを行います。
gulpコマンドのインストールは`npm install -g gulp`で行えます。
プロジェクト作成のおまじないは以下の感じ。gruntの時と似てますね。

- プロジェクトの作成

```bash:bash
mkdir gulp_chase
cd gulp_chase/
npm install --save-dev gulp
touch gulpfile.js
```

- 設定ファイルの記述

```js:gulpfile.js
var gulp = require('gulp');
var uglify = require('gulp-uglify');

gulp.task('default', function() {
  gulp.src('foo.js')
    .pipe(uglify())
    .pipe(gulp.dest('dest'));
});
```

- 実行

```bash:bash
npm install gulp-uglify
gulp
```

gulpコマンド実行後にdest/foo.jsを見るとミニファイが成功しています。
ここで登場するpipe関数がstream的な実装らしいのですが、
streamについての詳細はいずれNodeの枠でやるかも、くらいの感じで今回は触れずにおきます。

# 奥の細道:gulpとの上手な付き合い方
## gulpの調べものでハマらない為のドキュメント活用
Gruntの時同様ドキュメンテーションはなるべくオフィシャルのものを活用するのがオススメだと思います。
ほそ道も英語が得意ではありませんがそこは **「Don't think.FEEL!!!」** くらいの勢いで頑張っていこうと思います。

- [gulp CLI ドキュメント](https://github.com/gulpjs/gulp/blob/master/docs/CLI.md)
- [gulp API ドキュメント](https://github.com/gulpjs/gulp/blob/master/docs/API.md)
- [プラグインリスト](http://gulpjs.com/plugins/)

## コアの動きを理解する
### 概念図作ってみた(シーケンス的な)

今回もやってみました。やって！TRYの心意気です。
今回はハッキリと処理順序がファイル間のシーケンシャルな動きで見えたので
シーケンス図っぽい方が理解しやすいと思い、そのようにしてみました。

![スライド1.jpg](https://qiita-image-store.s3.amazonaws.com/0/39330/2e908205-c0e3-3653-a4d0-a993ac2fc91b.jpeg)

### 解説・補足
- (1)gulpコマンドが実行されると`liftOff`モジュールというのを呼び出して実行環境の情報を集めます
- (2)取得した実行環境の中から設定ファイル`gulpfile.js`をrequireします
- (3)gulpfileはgulpモジュール(Gulpオブジェクト)を取得して、そこにタスクを登録します
- (4)gulpコマンドのモジュールはGulpオブジェクトを取得します
- (5)Gulpオブジェクト内のタスクからenv.argvに入っているコマンドラインパラメータで指定されたタスクを実行します
    - Grunt同様、CLIパラメータ無しの場合はdefaultというタスクが実行されます

おぉ、シンプルですね！
gulpはそんなにオブジェクト指向的な組み方はしてありませんね。Gulpオブジェクトに集約されます。
解説のボリュームもGruntの時と比べだいぶシンプルな感じになりました。

# まとめ
今回は以上です。ほそ道的なgulpとの付き合い方をまとめておきます。

- 公式ドキュメントはやっぱり大事！とくにGruntと比べると情報も少ないはずですしね。
- 本格的に使う場合はある程度Node.jsのStream APIについて学んでおくと良さそう。
- 設定ファイルも構造もシンプルで柔軟性が高い！逆にいうとテキトーに作っていくとチーム運用や大規模化に耐えられなくなる可能性があるのである程度考えながら作った方が良いでしょう。

今回は以上です。
いろいろとGruntとの違いも見えたので、
[次回はGrunt　VS　gulp](http://qiita.com/setzz/items/badaee6d0de448ba9770)的なトピックでやってみようと思います。
Homebrew で pip が DistributionError を出す場合の対処


## 現象
pip コマンドを実行すると、 `pkg_resources.DistributionNotFound: pip==1.5.4` のようなエラーが表示されて何もできない。

## 再現手順

1. Homebrew で Python をインストールする
2. 新しい pip がある状態で `pip install --upgrade pip` する

`brew install python` すると、

```
==> Caveats
Setuptools and Pip have been installed. To update them
  pip install --upgrade setuptools
  pip install --upgrade pip
```

のように表示されるのですが、この通りに pip をアップグレードすると pip が動かなくなります。
pip がアップグレードされたのに `/usr/local/bin/pip` が古いままになっている状態です。

## 対処

`python -m pip` で pip を起動できます。 `/usr/local/bin/pip` を削除して

```bash
$ rm /usr/local/bin/pip /usr/local/bin/pip2 /usr/local/bin/pip2.7
$ python -m pip install --upgrade --force-reinstall pip
```

もしくは

```bash
$ python -m pip install --upgrade --force-reinstall pip --no-use-wheel
```

をします。
後者の方法を利用する場合は、今後 pip や setuptools を upgrade する際は常に

```bash
$ pip install --upgrade --no-use-wheel pip setuptools
```

する必要があります。


## 原因

Homebrew と wheel の相性問題です。

Homebrew は Python をインストールする際に、 pip と setuptools を

```
/usr/local/Cellar/python/<version>/
```

配下にインストールし、 ```/usr/local/bin/``` に pip コマンドなどへの symlink を設置します。

そして、 `distutils.cfg` に `prefix=/usr/local` という設定を書き、通常 `pip install` などでインストールされるパッケージが `/usr/local/bin/` 配下にスクリプトが、 `/usr/local/lib/pytthon2.7/` 配下にライブラリがインストールされるようにします。

この状態で `pip install --upgrade pip` すると、 `/usr/local/bin/pip` スクリプトをインストールしたいのですが、そこにはすでに Homebrew が勝手に作った pip が感知しない symlink が存在します。

スクリプトをインストールしたい場所にすでに symlink があったときの振る舞いですが、 wheel からのインストールと tar.gz からのインストールで違っていて、 wheel の場合はインストールできずにスキップされ、 tar.gz からの場合は symlink のリンク先 (つまり Cellar の中身) を書き換えてしまいます。

最近の pip はデフォルトで wheel があるとそれを使うので、 Cellar 配下の古いバージョンの pip を使おうとするスクリプトに対する symlink がそのまま残ってしまい、起動できなくなってしまうのです。

wheel を使う場合と使わない場合で振る舞いが違うのは良くないとは思いますが、そもそも外部で勝手に作られた symlink に上書きインストールする場合の挙動に正解なんて無いので、 Homebrew は `pip install --upgrade pip` を許すなら最初から普通に pip をインストールするべきだと思います。

## 追記

pip と setuptools を Cellar 内にインストールするのをやめるように修正する Pull request を出しました。 https://github.com/Homebrew/homebrew/pull/29926

## 追記2

上記の PR は Homebrew の基本方針とあわないので却下されました。
そこで、 wheel を使ったインストール時にも wheel を使わない場合と同じように、スクリプトのインストール先にすでにシンボリックリンクが合っても（リンク先を）上書きするようにする修正を pip 側に PR し、先ほど取り込まれました。

次の pip (1.6.0) がリリースされて、 Homebrew の Python にバンドルされるようになったら、その次のバージョンからは普通に `pip install --upgrade pip` でアップグレードできるようになるはずです。

とは言え、 Celler の中と外で2つの pip があり、外にインストールするときに中のスクリプトを書き換えるという、到底スマートとは言えない状態です。
特に困ってるのでなければ、 pip のアップグレードは行わず、 Homebrew がアップデートされるのを待つことをお勧めします。

また、 Python のヘビーな開発者は、独自の方式のために無理やりなことをしている Homebrew よりも MacPorts や、 pyenv を使った自前ビルドの方がいいかもしれません。
`pip install --upgrade pip` は直りましたが、 `pip install --user ipython` とかは動かないままですし、パッケージング周りで他にどんな副作用があるかも解りません。
ELBでスパイクアクセスと戦う

多量のアクセスがあってリクエスト数がスパイクした場合、ELBのスケールして対応する。
しかし、あまりに急激でスケールが間に合わない場合はスケールするまで503を返すようになる。
スパイクアクセス時に503を返したくないといった場合の対応方法をまとめてみた。
間違いがあったり他にいい方法があったらツッコミ希望デス。

* 参照サイト
 * [[AWSマイスターシリーズ]Amazon Elastic Load Balancing (ELB)](http://www.slideshare.net/AmazonWebServicesJapan/20130612-aws-meisterregenerateelbpublic)
 * [AWS - Cross-Zone Load Balancing を有効にしない理由がない件 - Qiita](http://qiita.com/rch850/items/23c0743876ef5ab7bd30)

# ELBを(なるべく)利用しない

いきなりELBで勝負しない方法。
なるべくELB以外でアクセスを受けてELBにアクセスがこない、もしくは少なくするとサービスとしてのスパイクがあってもELBへの影響は少なくできる。
以下のようなS3との連携方法などでELBへのアクセスを減らす。

 * [AWSにおける静的コンテンツ配信パターンカタログ（アンチパターン含む） ｜ Developers.IO](http://dev.classmethod.jp/cloud/aws/static-contents-delivery-patterns/)
 * [CDP:Direct Object Uploadパターン - AWS-CloudDesignPattern](http://aws.clouddesignpattern.org/index.php/CDP:Direct_Object_Upload%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3)
 * [CDP:Web Storageパターン - AWS-CloudDesignPattern](http://aws.clouddesignpattern.org/index.php/CDP:Web_Storage%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3)

# ELBのPre-Warmingを利用する

AWSサポートにお願いしてELBをスケールしておいてもらう。
ビジネスもしくはエンタープライズサポートに加入していて、事前にスパイクが予想できることが条件。

# ELBのPre-Warmingを手動で行う

サポートにお願いせず、自らELBにリクエストすることによって予想されるスパイクに対してELBをスケールさせる。
自らのリクエストによるスケーリング中に予想されないスパイクが発生すると危険そう。

# ELBで利用するAZを増やす

ELBで利用するAZを増やすとELBのインスタンスが各AZに配置されてラウンドロビンされるのでアクセスが分散されるはず。
利用するAZが1つより2つ、2つより3つの方がELBインスタンスが増えてスパイクに強くなるはず。

![ELBRoundrobin.png](https://qiita-image-store.s3.amazonaws.com/0/16768/0f339f2b-429c-fa38-29f2-618c6ee00dcb.png)

# DNSラウンドロビンを利用してELBを複数紐付ける

Route53などでDNSラウンドロビン機能を利用して複数ELBを紐付ければアクセスは分散されるはず(各ELBの背後は同じEC2構成)。
運用面で管理するものが増えたりするデメリットがありそう。

![ELB-DNSRoundrobin.png](https://qiita-image-store.s3.amazonaws.com/0/16768/a9892927-149c-56a8-4fcb-826e98e4d02b.png)
FuelPHPで他のサービスのWebAPIを利用する



# 概要

FuelPHPで作成しているシステム内で、
他のサービスのAPIを利用したい場合の方法。

FuelPHPにあるパッケージを使って行う。


# WebAPIを利用する

以下のようにできた。
サンプルコードで叩いているAPIは、Slackのもの。
https://api.slack.com/methods/users.list

```php:fuel/app/tasks/test.php
<?php

namespace Fuel\Tasks;

class Test
{
    public function run()
    {
        // APIのトークン
        $token = '';

        // Request_Curlを生成
        // http://fuelphp.jp/docs/1.7/classes/request/curl.html
        $curl = \Request::forge('https://slack.com/api/users.list', 'curl');

        // HTTPメソッドを指定
        $curl->set_method('post');

        // パラメータを設定
        $curl->set_params(array('token' => $token));

        // 実行
        // $responseには、Responseインスタンスが入る
        // http://fuelphp.jp/docs/1.7/classes/response.html
        $response = $curl->execute()->response();

        // レスポンスコードチェック
        if ($response->status == 200)
        {
            // Formatクラスを利用して、JSONからPHPの配列に変換
            // http://fuelphp.com/docs/classes/format.html
            $data = \Format::forge($response->body,'json')->to_array();

            // 中身をチェック
            var_dump($data);
        }
    }
}
```

以下のコマンドで実行。

```shell
$ php oil refine test
```
OpenSSL CCSインジェクション脆弱性(CVE-2014-0224) の修正はyumに公開済み

本日話題のOpenSSLの脆弱性

* [OpenSSLにまた重大な脆弱性、直ちにパッチ適用を](http://www.itmedia.co.jp/enterprise/articles/1406/06/news034.html)

はOpenSSL 1.0.1hで修正されたと記載があります。
RH系のLinuxで`yum info openssl`コマンドを確認してみると、最新版は

```
Version     : 1.0.1e
Release     : 16.el6_5.14
```

であると表示されるはずです。
1.0.1eなので未対策かと思いきや、

* https://rhn.redhat.com/errata/RHSA-2014-0625.html

1.0.1e-16.el6_5.14にて対応済みとのこと。

```
# yum update openssl
```

で修正完了です。
ライブラリのアップデートなので、使用しているプロセスを再起動しましょう。多くの場合はApacheだけでしょうか。

```
# service httpd restart
```

今回はHeartBleedのときと違って鍵ペアの作り直しは要請されていないのでこれで対応完了です。

関連
--
Ubuntuの対策はこちら。
http://qiita.com/gosshys/items/5946d775052eda91fdc4
VMWare ESXiへの対策パッチが公開されました。適用方法はこちら。
http://qiita.com/yuba/items/705eac7251be0152b277
【質問】VisualforceでのjQueryの表記方法について

お世話になっております。

visualforceでのjQuery表記についての質問です。

下記のようなページがあるとします。
これはinputFieldに打ち込まれた値に100を追加した値がoutputFieldに即反映されて表示されるというページです。
javascriptを使用しています。
<code>```<apex:page >
　　<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.8.2/jquery.min.js" />
　　<script type="text/javascript">
　　　　function changeSample(form) {
    　　　　　　inputval = parseInt(document.getElementById( '{!$Component.form.pb.pbs.in}' ).value);
    　　　　　　outputval = document.getElementById( '{!$Component.form.pb.pbs.out}' ).innerHTML =  inputval + 100;
}
　　</script>
　　<apex:form id="form" styleClass="form" >
　　　　<apex:pageBlock id="pb" styleClass="pb" >
　　　　　　<apex:pageBlockSection id="pbs" styleClass="pbs" >
　　　　　　　　<apex:inputField value="{!input__c}" onchange="changeSample(this.form);" id="in" styleClass="in" />
　　　　　　　　<apex:outputField value="{!output__c}" id="out" styleClass="out" />
　　　　　　</apex:pageBlockSection>
　　　　</apex:pageBlock>
　　</apex:form>
</apex:page>```</code>

このコードで問題無く動作します。

・・・が、このjavascript部分にjQueryを使用したいのです。
なのでその部分を下記のように書き換えました。
<code>```<script type="text/javascript">
  $j = jQuery.noConflict();
  $j(document).changeSample(function () {
    inputval = parseInt($j('.in').val());
    $j('.out').html() = inputval + 100;
  }
</script>```</code>

すると、inputFieldの部分は問題無く動作しているよう（outputFieldの方だけを、jQuery表記ではなくすると、書き換え前と全く同じ動作になる為）なのですが、outputFieldの方は上手く動作しませんでした。

outputFieldの方は似たようなことを紹介しているサイトを参照しながら上手くいきそうなコードをいくつか試してみたのですが、どれも上手くいかなかったので、とりあえず失敗例のうちの１つを書き換えの例に挙げました。

お力を貸していただければ幸いです。
よろしくお願い申し上げます。
[u-boot]u-bootのcpコマンドを直した件

u-bootのcpコマンドが真面目に動いてなかったので直してみました。
u-bootはたまに動いてないコマンドがあるから困る...


(この記事は私がかいたhttps://gist.github.com/chromabox/5418925 の転載です)

```diff:cmd_mem_cp_fix.diff

diff --git a/common/cmd_mem.c b/common/cmd_mem.c
old mode 100644
new mode 100755
index 64dd76a..45478d5
--- a/common/cmd_mem.c
+++ b/common/cmd_mem.c
@@ -445,7 +445,7 @@ static int do_mem_cp(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
 #endif
 
 	bytes = size * count;
-	buf = map_sysmem(addr, bytes);
+	buf = map_sysmem(dest, bytes);
 	src = map_sysmem(addr, bytes);
 	while (count-- > 0) {
 		if (size == 4)
@@ -461,6 +461,9 @@ static int do_mem_cp(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
 		if ((count % (64 << 10)) == 0)
 			WATCHDOG_RESET();
 	}
+	unmap_sysmem(src);
+	unmap_sysmem(buf);
+	
 	return 0;
 }
```
 
 
 
・オチ
私が見た当時はgitにある最新のコードも直って無かったんですが、今みたら去年の5月に直されてました。

>
author	Masahiro Yamada <yamada.m@jp.panasonic.com>
Mon, 20 May 2013 21:08:08 +0000 (21:08 +0000)
committer	Tom Rini <trini@ti.com>
Fri, 24 May 2013 14:38:08 +0000 (10:38 -0400)
commit	53237afe5b64abe7b17fbfed958f3dc83f503ffa
tree	aa9ceb518a8bc908b40c6e34e05058765633ee5f	tree | snapshot (tar.gz tar.bz2)
parent	c28cbfa1a89cae2c0cb13144c8123345d61fdc87	commit | diff
cmd_mem: fix cp command
The "cp" command has not worked since
commit 0628ab8ec59834f98ede267edd21ddb8ba0bb57b,
because of the following lines, which set the destination
and the source to the same address.
buf = map_sysmem(addr, bytes);
src = map_sysmem(addr, bytes);
Tested-by: Tom Rini <trini@ti.com>
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>

この訂正ではお尻にunmap_sysmemが無かったのが気になるけど、さほど問題ではないんでしょう。
よかったよかった。
Packer で Docker イメージを作る

# Packer で Docker イメージを作る

- [Packer](http://www.packer.io/)
- [Packerを使ってChef/Puppet/AnsibleでDockerのイメージをつくる](http://deeeet.com/writing/2014/03/02/build-docker-image-by-packer/)

```
Packerを使えばDockerのイメージをDockerfileを使わずビルドすることができる
つまり，Dockerfileの特有な記述を使わず，今まで慣れ親しんできたChefやPuppet，Ansibleのようなプロビジョニングツールを使ってDockerのイメージをビルドできる．
```

とのことなので Dockerfile 書かなくても良いじゃん?
という。

## Packer サンプル試した

http://www.packer.io/intro/getting-started/build-image.html

のサンプル試してみる
このサンプルはEC2

```
$ packer build \
-var 'aws_access_key=XXXXXXXXXX' \
-var 'aws_secret_key=XXXXXXXXXX' \
example.json
amazon-ebs output will be in this color.

==> amazon-ebs: Creating temporary keypair: packer 538fe89a-d16c-59c9-7b95-9422d008f01e
==> amazon-ebs: Creating temporary security group for this instance...
==> amazon-ebs: Authorizing SSH access on the temporary security group...
==> amazon-ebs: Launching a source AWS instance...
amazon-ebs: Instance ID: i-609c5332
==> amazon-ebs: Waiting for instance (i-609c5332) to become ready...
==> amazon-ebs: Waiting for SSH to become available...
==> amazon-ebs: Connected to SSH!
==> amazon-ebs: Stopping the source instance...
==> amazon-ebs: Waiting for the instance to stop...
==> amazon-ebs: Creating the AMI: packer-example 1401940122
amazon-ebs: AMI: ami-fa0eff92
==> amazon-ebs: Waiting for AMI to become ready...
==> amazon-ebs: Terminating the source AWS instance...
==> amazon-ebs: Deleting temporary security group...
==> amazon-ebs: Deleting temporary keypair...
Build 'amazon-ebs' finished.

==> Builds finished. The artifacts of successful builds are:
--> amazon-ebs: AMIs were created:

us-east-1: ami-fa0eff92
```

## Packer の起動動作まとめ

EC2に適用した場合、作られるのは AMI イメージ。
EC2は出来るけど、イメージ作り終わったら terminate される。

不要な AMI イメージは削除する感じ。
EC2の起動はAMIイメージを元に自分で行う感じ。

流れとして、

1. Chef 用意する
2. Packer で AMI イメージ作る / Docker イメージ作る
3. AMI/Dockerイメージを起動する

って感じにできるぽい。

## Chef on Docker

- [DOCKER BUILDER](http://www.packer.io/docs/builders/docker.html)

```json
# docker-chef.json
{
  "builders":[{
    "type": "docker",
    "image": "phusion/baseimage",
    "export_path": "docker-image.tar"
  }],
  "provisioners":[
    {
      inline: [
        "apt-get -y install curl"
      ],
      "type": "shell"
    },
    {
      "type": "chef-solo",
      "cookbook_paths": ["cookbooks"],
      "run_list": []
    }
  ],
  "post-processors": [
    {
      "type": "docker-import",
      "repository": "skyriser/docker-test",
      "tag": "0.1"
    }
  ]
}
```

```
$ sudo -E packer build docker-chef.json
docker output will be in this color.
```

これだけで docker イメージできる。
packer っていう別のバイナリがいることもあるようなので注意。
フルパスで指定すると確実かもしれない。

```
$ sudo docker run -t skyriser/docker-test
```
Docker 使ってみた

# Docker 使ってみた

## Docker を理解する

Docker はLinuxコンテナを利用して任意のアプリケーションを簡単に実行できるように整備するためのツール群
VM に似ているけどコンテナを利用するの非常に軽量

- [今からでも間に合うDockerの基礎コンテナとは何か、Dockerfileとは何かDocker Meetup Tokyo #2](http://www.publickey1.jp/blog/14/dockerdockerfiledocker_meetup_tokyo_2.html)
- [私の Docker TIPS](http://qiita.com/mopemope/items/181cb6c6c6f7cf9bbaa9)

ベースとなっている LXC の概念と AUFS 周りは基礎なので理解しておくと良い

- [dockerfile.vim](https://github.com/ekalinin/Dockerfile.vim)

vim 使ってるなら Syntax 入れておくと良いです


## Docker が動くようにする

- [docker.io](https://www.docker.io/)

に従ってインストールすれば良い
デーモンが動いてないとダメなのでインストール直後にデーモンを起動することを忘れない


## 超基本的な流れ

- `Dockerfile` に構築手順を書いていく
- `docker build` でイメージファイルを作る
- `docker run` でイメージを起動する

これだけ


## Dockerfile を build

 - `RUN` は `build` する時に動くやつ
 - `CMD` と `ENTRYPOINT` は `run` する時に動くやつ

Rails だったら例えばこう

```
# Master image
FROM centos

# Use Epel
RUN rpm -ivh http://ftp.riken.jp/Linux/fedora/epel/6/x86_64/epel-release-6-8.noarch.rpm

# Install middleware
RUN yum -y update
RUN yum install -y which tar patch libffi-devel glibc-headers autoconf gcc-c++ glibc-devel patch readline-devel zlib-devel openssl-devel bzip2 automake libtool bison
RUN yum install -y libyaml libyaml-devel libxml2 libxml2-devel libxslt libxslt-devel

# Create user
RUN adduser docker

# Change user
USER docker
WORKDIR /home/docker
ENV HOME /home/docker

# Install rvm, ruby, bundler
RUN \curl -sSL https://get.rvm.io | bash -s stable
RUN /bin/bash -l -c "rvm requirements"
RUN /bin/bash -l -c "rvm install 2.0.0"
# ちょっとアレ
ENV PATH /home/docker/.rvm/gems/ruby-2.0.0-p481/bin:/home/docker/.rvm/rubies/ruby-2.0.0-p481/bin:$PATH
RUN gem install bundler

# Rails setup (with Bundler Cache)
RUN mkdir -p /home/docker/app
WORKDIR /home/docker/app
ADD Gemfile /home/docker/app/Gemfile
ADD Gemfile.lock /home/docker/app/Gemfile.lock
RUN bundle install
ADD . /home/docker/app

# この辺怪しくてアレ
RUN bundle exec rake db:create
RUN bundle exec rake db:setup

# Expose ports
EXPOSE 3000

# Run
ENTRYPOINT bundle exec rails server
```

```
Uploading context 1.146 GB
Uploading context
Step 0 : FROM centos
---> 0b443ba03958
Step 1 : RUN rpm -ivh http://ftp.riken.jp/Linux/fedora/epel/6/x86_64/epel-release-6-8.noarch.rpm
---> Using cache
---> 5d6639f413bc
Step 2 : RUN yum -y update
---> Using cache
---> a94bf0677fb9

...

```

それぞれのStepで「キャッシュ」していて、コマンドの順番を変えない限りキャッシュが生きる
勿論キャッシュを無効にすることもできる
Dockerfile を編集して build すると変更された箇所から構築がリスタートする
それまでの部分はキャッシュを使ってくれる


### ストップしたコンテナは随時削除


```
sudo docker rm $(sudo docker ps -a -q)
```

で起動してる奴以外削除できる
Docker 試行錯誤してるとどんどん不要なファイル貯まる
特に構築に失敗したやつはたまりやすい
ディスクスペースに注意

### イメージも随時削除

コンテナ以外にベースとなるイメージも随時削除する。
例えばディストリ変えて色々やったりするとイメージもどんどんたまる

```
sudo docker rmi $(sudo docker images | awk '/^<none>/ { print $3 }')
```


## Dockerfile を run

作成した Dockerfile を run コマンドにて起動する

```
docker build -t <REPOSNAME> .
```

シェルに突入 (interactive mode) したければ

```
docker run -i -t <REPOSNAME> /bin/bash
```
コマンド一つでMysqlを速くする

稼働中のシステムであっても下記のコマンドを実行するだけで再起動等必要はないので、非常にお手軽に出来る。

```mysql:mysql
mysql > set global innodb_flush_log_at_trx_commit = 2;
```

デフォルトではinnodb_flush_log_at_trx_commit = 1 になっているはず。
1に設定するとトランザクション単位でログを出力するが 2 を指定すると1秒間に1回ログファイルに出力するようになる。
そのため、マスターDBが落ちて別スレーブに切り替わる仕組みを導入していても1秒の間に発生したトランザクションは完全にもとに戻す事が出来ない。

マスターDBの死 = サービス停止 みたいに冗長構成を持たせていないのならばこの設定にしても問題はなさそう。

mysqlslapでベンチマークを測ってみた。
テストの内容としては20クライアントから計10万回のINSERT文を実行するという内容で
結果として約3倍近く速くなっている。
innodb_flush_log_at_trx_commit = 1
![スクリーンショット 2014-06-07 21.45.13.png](https://qiita-image-store.s3.amazonaws.com/0/35451/f752d983-f4c9-f10f-f2fe-ff0f7df300dd.png)

innodb_flush_log_at_trx_commit = 2
![スクリーンショット 2014-06-07 21.45.41.png](https://qiita-image-store.s3.amazonaws.com/0/35451/7f623318-1a14-da34-17a5-86768a25fc51.png)
TinyMCE Advancedで、文字背景色の設定ボタンを追加したいとき

WordPressのプラグイン「TinyMCE Advanced」で、文字背景色の設定ボタンを追加したいときの手順。

#手順
設定から、「TinyMCE Advanced」の設定画面を開き、ボタンをドラッグ＆ドロップで持ってきて保存する。

#参考
以下のページを参考にさせていただきました。

TinyMCE Advanced の設定法と使い方
http://bazubu.com/wp101/how-to-use-tinymce-advanced

非常に詳しい解説ページ。素晴らしいです。