ためすう
Python のバージョンが低いと Telnet で timeout が指定できない件
2018-03-25目的
Python を触っていた時、Telnet の第3引数に値が入れるとエラーが発生しました。
その原因を調べてみました。
原因
tn = telnetlib.Telnet("www.example.com", port, timeout)
↓
tn = telnetlib.Telnet("www.example.com", port)
参考 URL のドキュメントを見ると分かるのですが、Python 2.5 では
第 3 引数 の timeout が対応していないことが原因でした。
参考URL
unix でログインしているマシンの情報を得る
2018-03-19目的
複数台の Web サーバーから取得したログファイルを整理するためです。
オプションでいろいろ情報を見ることができます。 今回見たのは、 OS が何 bit か、サーバーの ip アドレスになります。
自分の Vagrant 環境で試しました。
コマンド
何 bit かを調べます
$ uname -p
出力
x86_64
hostname を調べます
$ uname -n
出力
localhost.localdomain
ファイル名にする
$ touch $(uname -n)-$(uname -p).log
localhost.localdomain-x86_64.log のファイルが作成されます。
オプションについて
-p, –processor print the processor type or “unknown”
-n, –nodename print the network node hostname
参考URL
Vagrant が起動しなくなった時にすること
2018-03-17目的
数年ぶりに Vagrant で環境を立ち上げようとしたら、エラーが発生するようになったので
起動できるようにします。
発生しているエラー
$ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Checking if box 'chef/centos-6.5' is up to date...
==> default: There was a problem while downloading the metadata for your box
==> default: to check for updates. This is not an error, since it is usually due
==> default: to temporary network problems. This is just a warning. The problem
==> default: encountered was:
==> default:
==> default: The requested URL returned error: 404 Not Found
==> default:
==> default: If you want to check for box updates, verify your network connection
==> default: is valid and try again.
==> default: Clearing any previously set network interfaces...
There was an error while executing `VBoxManage`, a CLI used by Vagrant
for controlling VirtualBox. The command and stderr is shown below.
Command: ["hostonlyif", "create"]
Stderr: 0%...
Progress state: NS_ERROR_FAILURE
VBoxManage: error: Failed to create the host-only adapter
VBoxManage: error: VBoxNetAdpCtl: Error while adding new interface: failed to open /dev/vboxnetctl: No such file or directory
VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component HostNetworkInterface, interface IHostNetworkInterface
VBoxManage: error: Context: "int handleCreate(HandlerArg*, int, int*)" at line 66 of file VBoxManageHostonly.cpp
手順
Virtual Box を再インストール
こちらからダウンロードして、インストールし直します。
起動してみます。
$ vagrant up
The provider 'virtualbox' that was requested to back the machine
'default' is reporting that it isn't usable on this system. The
reason is shown below:
Vagrant has detected that you have a version of VirtualBox installed
that is not supported. Please install one of the supported versions
listed below to use Vagrant:
4.0, 4.1, 4.2, 4.3
Vagrant のバージョンが古いと言われました。
Vagrant のバージョンを確認します。
$ vagrant version
Installed Version: 1.7.2
Latest Version: 2.0.2
To upgrade to the latest version, visit the downloads page and
download and install the latest version of Vagrant from the URL
below:
http://www.vagrantup.com/downloads.html
If you're curious what changed in the latest release, view the
CHANGELOG below:
https://github.com/mitchellh/vagrant/blob/v2.0.2/CHANGELOG.md
Vagrant が古いみたいなので新しいバージョンを再インストールします。
Vagrant の再インストール
こちらから再インストールします。
また起動してみます。
$ vagrant up
Vagrant failed to initialize at a very early stage:
The plugins failed to initialize correctly. This may be due to manual
modifications made within the Vagrant home directory. Vagrant can
attempt to automatically correct this issue by running:
vagrant plugin repair
If Vagrant was recently updated, this error may be due to incompatible
versions of dependencies. To fix this problem please remove and re-install
all plugins. Vagrant can attempt to do this automatically by running:
vagrant plugin expunge --reinstall
Or you may want to try updating the installed plugins to their latest
versions:
vagrant plugin update
Error message given during initialization: Unable to resolve dependency: user requested 'dotenv (> 0)'
またエラーが発生してしまいました。
vagrant plugin のバージョンがおかしいみたいなので、インストールし直します。
vagrant plugin をインストールし直す
$ vagrant plugin expunge --reinstall
起動してみます。
$ vagrant up
起動することができました。
参考URL
PHP でデザインパターン (シングルトン)
2018-03-11Singleton の目的
- 指定したクラスのインスタンスが絶対に1個しか存在しないことを保証したい
- インスタンスが1個しか存在しないことをプログラム上で表現したい
また、
たとえば、システムの設定を表現するクラスや、システム全体で一度読み込んだデータをキャッシュしておくクラスで利用する。
Singleton の実装に関して
Singleton クラスのコンストラクタは private にする。
Singleton クラス外からコンストラクタを呼ぶことを防ぐため。
下記の方法でインスタンス生成できないようにする
- 自身を外部から new する
- 外部から clone する
- 派生クラスを new する（派生クラスを作ることができないようにする）
Singleton の実装例
<?php
// final で派生クラスを作ることができないようにする
final class Singleton
{
private static $instance;
private $id;
private function __construct()
{
$this->id = time();
}
private function __clone()
{
}
public static function getInstance()
{
if (is_null(self::$instance)) {
self::$instance = new self();
}
return self::$instance;
}
public function getId()
{
return $this->id;
}
}
$ins1 = Singleton::getInstance();
sleep(3);
$ins2 = Singleton::getInstance();
print($ins1 === $ins2);
print "\n";
print($ins1->getId() === $ins1->getId());
print "\n";
出力結果
1
1
エラーパターンの確認
- 自身を外部から new する
$ins0 = new Singleton();
// Fatal error: Call to private Singleton::__construct() が発生
- 外部から clone する
$clone_class = clone $ins1;
// Fatal error: Call to private Singleton::__clone() が発生
- 派生クラスを new する（派生クラスを作ることができないようにする）
class ChildSingleton extends Singleton
{
public function __construct()
{
}
}
$ins3 = new ChildSingleton();
// Fatal error: Class ChildSingleton may not inherit from final class (Singleton) が発生
参考
gmailのメールアドレスをOutlook 2007で使う
2018-03-10目的
html メールの作成をした時
動作確認で Outlook で受信メールを見ることができるようにすることです。
方法
Outlook の設定にて
受信メールサーバー、送信メールサーバーに gmail のメールサーバーの情報を入力します。
メールサーバーへのログオン情報には gmail のアカウント情報を入力します。
これで gmail のメールアドレスに来たメールを Outlook で見ることができるようになりました。
受信メールサーバーとは
- 「POP」は「Post Office Protocol（ポスト・オフィス・プロトコル）」の略
送信メールサーバーとは
- 「SMTP」とは「Simple Mail Transfer Protocol（シンプル・メール・トランスファー・プロトコル）」の略
参考URL
git リポジトリの移行をする
2018-03-04目的
個人の git リポジトリをチームで使うリポジトリへ移すことが必要になりました。
方法
$ git clone --mirror <SOURCE_REPOSITORY_URL>
$ cd <REPOSITORY>
$ git push --mirror <DESTINATION_REPOSITORY_URL>
ちょっと補足
$ git clone --help
> --mirror
> Set up a mirror of the source repository. This implies --bare. Compared to --bare, --mirror not only maps local branches of the
> source to local branches of the target, it maps all refs (including remote-tracking branches, notes etc.) and sets up a refspec
> configuration such that all these refs are overwritten by a git remote update in the target repository.
$ git push --help
> --mirror
> Instead of naming each ref to push, specifies that all refs under refs/ (which includes but is not limited to refs/heads/,
> refs/remotes/, and refs/tags/) be mirrored to the remote repository. Newly created local refs will be pushed to the remote end,
> locally updated refs will be force updated on the remote end, and deleted refs will be removed from the remote end. This is the
> default if the configuration option remote.<remote>.mirror is set.
参考URL
bowerでc3のインストール
2018-02-28目的
bower を使って、 c3 のインストールを行いました。
bower とは
フロントエンド用パッケージ管理ツールであり、依存関係も管理してくれるものです。
c3 とは
d3 を元にグラフを扱いやすくしたものです。
インストール手順
$ bower install c3
bower_components 以下に d3、c3 がインストールされました。
今後
bower_components 以下のファイルをそのまま呼び出しても使えますが
gulp などのビルド自動化ツールを使って、bower_components を呼び出すようにしてみたいと思います。
参考
Python ライブラリ・モジュールの場所を見つける
2018-02-25目的
python でファイルを実行するときに、module の場所を見つける必要がありました。
解決策
#### 確認環境
$ python himejima$ python –version Python 3.6.2 :: Anaconda custom (64-bit)
test.py
import datetime import json
print(datetime.file) print(json.file)
出力結果
/anaconda3/lib/python3.6/datetime.py /anaconda3/lib/python3.6/json/init.py ```
※ 環境により異なります。
参考
DIとDIコンテナとサービスロケータ その3
2018-02-22本記事の範囲
本記事では、サービスロケータ を記事の範囲とします。 DI 、DI コンテナについては別記事で書いています。
サービスロケータとは
「サービスロケータ」とは、サービス（オブジェクト）の取得を抽象化するデザインパターンです。
サービスロケータの例
<?php
require_once './vendor/autoload.php';
use Pimple\Container;
class Client
{
private $container;
public function __construct(Container $container)
{
$this->container = $container;
}
public function log($messgae)
{
$this->container['service_interface']->log();
}
}
interface ServiceInterface
{
public function log();
}
class Service implements ServiceInterface
{
public function log($message)
{
echo $message . "\n";
}
}
// Client呼び出し
$container = new Container();
$container['service_interface'] = function ($container) {
$service = new Service();
return $service;
};
$container['client'] = function ($container) {
$client = new Client($container);
return $client;
};
$client = $container['client'];
$client->log('ssssss');
ここでは、$container がサービスロケータとなります。
依存するものが DIとサービスロケータで異なります。
DIの場合
- ServiceInterface を実装しているオブジェクト
サービスロケータの場合
- DIコンテナ (Pimple)
$this->container['service_interface']
これによって、Client クラスが DIコンテナ (Pimple)の依存が強くなり、Client を利用するときは DIコンテナも必要とされるようになってしまいました。
DIコンテナについてまず知っておくべきなのは、DIコンテナを使ってさえいれば「依存性の注入」ができるわけではないってことだ。 DIコンテナは、依存性の注入を実現するための便利な道具として使える。 でも、使い方をミスって、サービスロケーションというアンチパターンを作ってしまっていることも多い。 DIコンテナをサービスロケーターとしてクラスに組み込んでしまうと、 依存関係を別の場所に移そうとしていたはずなのに、よりきつい依存関係を作り込むことになる。 おまけにそのコードはわかりにくくなってしまうし、テストもしづらくなる。
結局のところ、サービスロケータはアンチパターンのようです。
参考
DIとDIコンテナとサービスロケータ その2
2018-02-18本記事の範囲
本記事では、DI コンテナについて書きます。 サービスロケータは別記事で。
DI コンテナとは
DIを楽にしたり、オブジェクト生成のコードをまとめるための便利なツール
DI コンテナ の例
Main.php ( 1 ファイルに全部まとめました)
<?php
require_once './vendor/autoload.php';
use Pimple\Container;
class Service
{
public function log($message)
{
echo $message . "\n";
}
}
class Client
{
private $service;
public function __construct(Service $service)
{
$this->service = $service;
}
public function log($message)
{
$this->service->log($message);
}
}
$container = new Container();
$container['service_interface'] = function ($container) {
$service = new Service();
return $service;
};
$container['client'] = function ($container) {
$client = new Client($container['service_interface']);
return $client;
};
$client = $container['client'];
$client->log('ssssss');
今回は Pimple を使用して、依存性について定義しました。
これによって、呼び出し元で依存性の注入を直接記述しなくても良くなりました。
（Client に渡すクラスが インターフェースになったら、一工夫が必要そうです。）