2018-12-14

「共有しました」「共有してください」というけれども。

ウェブ業界で働いていていつも思うのが、共有して欲しい、共有しましたよ。という表現がほんとよく使われているなぁということ。

結論からいうと、共有という言葉は私にとっては、あくまでもFYI (For Your Information) であって、仕事のやり取りで使うべきでないワードなんじゃなかろうかと考えています。

なぜかというと、「共有という言葉にはアクションが含まれないから」です。

もちろん勘のいい人なら、情報を共有するだけで、勝手にアクションに移してくれる優秀な方もいるでしょう。

でも、仕事であれば、共有するといったからにはそこには何かしらの意図というものがあるはずです。

それこそ、

「次の仕事に活かしてね」

なのか、

「モックを作っといてね」

なのか、

「見積もり用意しといてね」

なのか

どうやら私のような人間はレッドリストに載らないまでも、

保全対象ぐらいにはなって欲しいと願う次第です。

ちょっとでも共感してくれる人がいればいいなぁ

仕事の基本エッセンシャルノート良い判断ができる人

作者: 鳥原隆志
出版社/メーカー: 日経BP社
発売日: 2018/01/25
メディア: 単行本
この商品を含むブログを見る

2018-12-13

Google reCAPTCHA ver3 を試す

Fire HD 10 タブレット (10インチHDディスプレイ) 32GB

出版社/メーカー: Amazon
発売日: 2017/10/11
メディア: エレクトロニクス
この商品を含むブログ (7件) を見る

Google reCAPTCHA ver3とは何か？

reCAPTCHA v3 returns a score for each request without user friction. The score is based on interactions with your site and enables you to take an appropriate action for your site

公式サイトには、ユーザに画像をポチポチ選択したり、文字を正しく読むことを強いたりせずに、リクエストに対する「スコア」を返す仕組みで、

スコアは、サイト上のページとのインターアクションに基づいており、そのスコアを用いて自分のサイトで適切なアクションが取れることを可能にしてくれる。

とある。

要するに、何かユーザに操作を強制せずに、機械的にボットか人かをGoogleが判断してくれて、その判断スコアを返してくれるものである。

いままでは、人間でもうまく画像認識や文字認識ができないと次のステップに進めない、という状況が起こりがちだった。

ver3のスコアを利用することで、ユーザへ何か作業をお願いすることなしに、ボットか、そうでないかのスコアを返してくれて、サイトの特性に合わせて、スコアが0.7以上は人間と判断、とかサイトの所有者が自由に設計が可能になる。

また、機械学習の結果スコアは変動し、例えばテスト環境と、本番環境でのスコアが異なることもある。

では本題。

実装に必要なものは、ブラウザ側でのJS実装と、サーバサイドでのスコア確認である。

フォーム送信でreCAPTCHAver3を利用した場合のサンプルを載せておく。

reCAPTCHAver3 test

Satechi 充電用パススルー Type C 4k HDMI出力カードリーダー USB3.0ポートx3 マルチハブスペースグレイ

出版社/メーカー: Satechi
メディア: エレクトロニクス
この商品を含むブログを見る

2018-04-25

MT7 RC1を試してみた。

さくっと試そうと思ったら、下記のようなエラーがでてインストールができず。

specified key was too long max key length is 767 bytes

いろいろ調べた結果、my.cnfにシステム変数を追記して、

@my.cnf
# MT
innodb_file_format = Barracuda
innodb_file_per_table = 1
innodb_large_prefix

; mysqld (ver 5.6.28)を再起動

$ vi lib/MT/ObjectDriver/DDL.pm
@269を下記のように変更
$table_ddl .= ') ROW_FORMAT = DYNAMIC';

で行けた！
RC1とはいえ、ちょっとこれどうなのよ。

参考
https://nautilus-code.jp/articles/key_was_too_long_when_install_movabletype/

2018-04-23

sketch-codeなる、ワイヤーフレームからhtmlを自動生成するAIツールを試してみた。

コードはこちら

#セットアップ
$ git clone https://github.com/ashnkumar/sketch-code.git
$ cd sketch-code/
$ pip install --upgrade pip #pip ver10が必要らしいです。
$ pip install -r requirements.txt

#モデルデータとかを取得
$ cd scripts/
$ sh get_data.sh
$ sh get_pretrained_model.sh
$ cd ../src
# ../examples/nash_ex02.pngを適切なパスに変更
$ python convert_single_image.py --png_path ../examples/nash_ex02.png --output_folder ./generated_html --model_json_file ../bin/model_json.json --model_weights_file ../bin/weights.h5

こんな手書きのワイヤーが

こんな感じに出力されました。

４カラムじゃないよ！と言いたい気持ちを抑えつつ、
エリア定義ぐらいはいけそうです。

今回はpre-trained なモデルをダウンロードして使ってみましたが、
自前で学習させればもっといいのができるんでしょうね。

元記事はこちら
https://blog.insightdatascience.com/automated-front-end-development-using-deep-learning-3169dd086e82

2018-01-18

知らないうちにrpmforge終わってた・・・

https://qiita.com/bezeklik/items/ba4ccd806ae39d35f782

2017-11-27

Let's encryptを使ったAWS EC2(Amazon Linux)へのSSL導入

参考サイト

かんたんまとめ

Let's encryptは、無料で利用できるSSL証明書です。
今回はAmazon Linuxで構築した社内サーバのSSL証明書の期限が切れそうだったので、
ためしにインストールして見ました。

実際に入れて見てわかったことは、下記の４点です。

Amazon Linuxではまだ自動スクリプトでのセットアップ検証がすんでないらしく手動で設定を行う必要がある。
証明書の有効期限は３ヶ月間
cronで自動でリニューアルする
Aレコードがインストールするサーバを向いている必要がある
- つまりDNSが切り替わってからでないと導入できない

$ sudo wget https://dl.eff.org/certbot-auto
$ sudo chmod a+x certbot-auto
# 依存パッケージでエラーになったので、一度パッケージを削除のうえ、アップデート→https://goo.gl/mHx4Qe
$ sudo yum remove libstdc++-devel
$ sudo yum update
$ sudo ./certbot-auto certonly --webroot -w /var/www/html --email test@example.com --debug -d www.example.com
license: Agree
share email: Yes
# 下記パスにファイルが自動作成される
$ sudo ls /etc/letsencrypt/live/www.example.com

# apacheの設定ファイルを編集
$ sudo vi /etc/httpd/conf.d/ssl.conf
$ sudo /etc/init.d/httpd configtest # テスト
$ sudo  /etc/init.d/httpd restart

3ヶ月ごとの更新なので、cronで自動化する。
$ sudo vi /etc/cron.d/letsencrypt
00 16 * * 2 root /home/ec2-user/certbot-auto renew --post-hook "service httpd restart"

#更新期限１ヶ月を切ったあと、毎週火曜日の16時に更新が走るかを確認して完了です。

Amazon linuxだと少しハマりましたが、結構簡単に導入できて、cron設定もできました。

2017-08-23

手を動かしてみたらDockerをざっくりと理解できた件。

Dockerについては、

コンテナ型の仮想化技術である
アプリケーションの環境をコンテナに閉じ込めてポータブルにできる。
そのため、ホスト OS上の１プロセスで動作するものである
VMWare やVirtualBoxのようなホストOSの上でゲストOSを動かすわけではないので、動作が軽い

これぐらいの知識がある程度で始めました。

特に最初の２つのイメージが湧かなかったので、その辺りを身をもって実感するためにいろいろと試してみました。

はじまりはいつもここから
 https://docs.docker.com/docker-for-mac/

まずはインストール
https://docs.docker.com/docker-for-mac/install/

$ docker --version
Docker version 17.06.0-ce, build 02c1d87

次にnginxを動かしてみる

$ docker run -d -p 80:80 --name webserver nginx
Unable to find image 'nginx:latest' locally
latest: Pulling from library/nginx
94ed0c431eb5: Pull complete
9406c100a1c3: Pull complete
aa74daafd50c: Pull complete
Digest: sha256:788fa27763db6d69ad3444e8ba72f947df9e7e163bad7c1f5614f8fd27a311c3
Status: Downloaded newer image for nginx:latest
3728cb8621a5504423e833b7b8d14c02842a44b1886f1e150082f58d54205d0

ローカルにイメージがなければ、勝手にDocker Hubから Dockerイメージをダウンロードする模様

コンテナプロセスを確認してみる

$ docker ps
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                NAMES
3728cb8621a5        nginx               "nginx -g 'daemon ..."   4 minutes ago       Up 4 minutes        0.0.0.0:80->80/tcp   webserver

動いているのを確認

コンテナを止めて、再起動してみる

$ docker stop webserver
webserver
$ docker start webserver
webserver

webserverコンテナを削除してみる（nginxイメージは残る）

$ docker rm -f webserver
webserver
$ docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
nginx               latest              b8efb18f159b        7 days ago          107MB
hello-world         latest              1815c82652c0        7 weeks ago         1.84kB

一括でコンテナを削除

docker rm $(docker ps -aq)

イメージも削除してみる

$ docker rmi nginx
Untagged: nginx:latest
Untagged: nginx@sha256:788fa27763db6d69ad3444e8ba72f947df9e7e163bad7c1f5614f8fd27a311c3
Deleted: sha256:b8efb18f159bd948486f18bd8940b56fd2298b438229f5bd2bcf4cedcf037448
Deleted: sha256:ba49ddf19ae3c9d08d348b3f621faca9c2bf4030a28f249af512d76fc9010cb9
Deleted: sha256:7b8885a6166d207114b95dacfe115f9cf8fd023e69bd0d4d1ca30736cf03ca15
Deleted: sha256:eb78099fbf7fdc70c65f286f4edc6659fcda510b3d1cfe1caa6452cc671427bf

macでは~/Library/Containers/com.docker.docker/Data あたりにイメージファイルなどが保存される模様

テスト用のhello-world イメージを削除しようとすると、怒られる。

$ docker rmi hello-world
Error response from daemon: conflict: unable to remove repository reference "hello-world" (must force) - container 3e350518xxxx is using its referenced image 1815c826xxxx

実際には、

$ docker stop eager_shannon
$ docker rmi {image_id}

としないといけないといけない

ubuntu コンテナをベースにapache + php7環境のコンテナを作ってみる

公式のubuntuコンテナをダウンロード

$ docker pull ubuntu
; lampという名前のコンテナをubuntuイメージからdetachモードで作成してbashを起動
$ docker run -itd --name lamp ubuntu bash

; シェルに入る
$ docker attach lamp

; Dockerのubuntu コンテナにphp mysql apache2を入れてイメージを作成する
# apt-get update
# apt-get -y install apache2
# a2enmod ssl
# a2ensite default-ssl
# apachectrl restart
# apt-get install apt-file
# apt-file update
# apt-get install software-properties-common
# add-apt-repository ppa:ondrej/php
# apt-get update
# apt-get install php7.1
# apt-get install php7.1-mysql
# apt-get install php7.1-imagick
# apt-get install php7.1-mbstring
# apt-get install php7.1-bz2
# apt-get install php7.1-xml
# apt-get install php7.1-sqlite
# apt-get install php7.1-intl
# apt-get install php7.1-xdebug
# apt-get install php7.1-memcache
# apt-get install php7.1-redis
# apt-get install php7.1-mongo
# apt-get install php7.1-gd
# apt-get install vim
# apt-get install git
# vi /var/www/html/index.php
# apt-get install sysv-rc-conf
# exit 
; my-apache-php7という名前でコンテナをイメージとして作成
$ docker commit {container_id} my-apache-php7
; 一度containerを削除
$ docker rm {container_id}

MYSQLのコンテナを作成する

$ docker pull mysql/mysql-server
$ docker run --name mysql-container -e MYSQL_ROOT_PASSWORD=secret -d mysql/mysql-server:5.7

#mysqlコンテナのIPアドレスを調べる

$ docker inspect mysql-container | grep IPAddress
            "SecondaryIPAddresses": null,
            "IPAddress": "172.17.0.3",
                    "IPAddress": "172.17.0.3",

#他のコンテナから利用できるようにgrantを発行

$ docker exec -it mysql-container mysql -uroot -p
mysql> grant all on *.* to root@"172.17.%" identified by "secret";
mysql> flush privileges;

#アプリケーション側からは下記のような形で接続できる

$link = mysqli_connect("172.17.0.3", "root", "secret", "mysql”); //php

#作成したイメージからコンテナを作成してapacheを起動

$ docker run -itd -p 8080:80 --name webserver my-apache-php7 apachectl -D FOREGROUND
#ソースファイルをデプロイ
$ docker exec -it webserver git clone https://github.com/chienowa/docker-test.git /var/www/html/app
# pullする場合
$ docker exec -it webserver bash -c "cd /var/www/html/app && git pull"
# ファイルコピーする場合（mysql接続用ファイルをコンテナにホストからコピー）
$ docker cp mysql.php 1349871fa1ff:/var/www/html/

これでなんとなく、Dockerイメージの作成、コンテナの使い方、ソースのデプロイ方法のイメージが掴めたかな！？

dockerのインストールからコンテナ利用を試行錯誤してみてわかったことをまとめてみました。

Dockerコンテナは１つのフォアグラウンドで動くサービスと、そのサービスが依存するライブラリ/モジュールとで構成されるものという理解が、一番ベストプラクティスに近い気がする

dockerのコンテナとはアプリケーション環境の複数のプロセスをまとめるものではなく、apache+phpとそのモジュールたち、rubyとgemとrails、など、１プロセスに必要な依存ソフトウェアをコンテナにまとめるのが正しい使い方という理解

１コンテナ内でapacheとmysqlを二つのサービスを起動させることはできない

monitやsupervised を使えば複数のサービスを使えるが、本来的な使い方ではなさそう。

たとえばmysqlは別ポートで起動する１サービスなので、別コンテナとして利用するのが本来的な使い方。

DockerfileはDockerイメージをビルドするための Infra As a Codeみたいなもの（Vagrantfileに近い）→※今後試す

いろんなツールをインストールして、一つのDockerイメージを作り込む（イメージが重くなる）というよりは、軽いベースイメージを元に、Dockerfileで都度イメージを作成するためのもの

本来的にはDockerfileを使ってテキストファイルでセットアップ手順を記述し、コンテナをビルドすると言う形が管理上好ましい

各コンテナは172.17.0.x のようなプライベートIPを振られるので、それを使ってコンテナ間通信ができる。

複数コンテナを管理する際はdocker compose を使ってyamlで複数のコンテナ管理を記述すれば、便利に管理できる！→※今後試す

つぎはAWS ECS上でコンテナを動かしてみようと思います。