iPhoneとmineoで、Wi-Fi-なしでインターネットに接続しようとすると「データ通信機能を起動できませんでした」と表示される問題の対応についての解説です。

問題について

iPhone7(SIMフリー)に、mineo(Dプラン)のSIMカードを入れて設定した後、Wi-Fiなしでインターネットに接続しようとすると「データ通信機能を起動できませんでした」と表示されてインターネットにつながらない。

対処法

以下の2つの方法のいずれかで対応できると思います。

ネットワーク設定をリセットして再度接続

iPhoneの設定→一般→リセット→ネットワーク設定のリセット

で一旦ネットワーク設定をリセット

設定→一般→プロファイルで、入っているプロファイルを削除

自分が利用しているプランのmineoのプロファイルを再度インストール

ネットワーク設定（iOS端末）｜各種設定｜ご利用時の各種設定｜初期設定と各種設定｜mineoユーザーサポート

モバイル通信のデータ通信設定の見直し

設定→モバイル通信→通信のオプション→4Gをオンにする→データ通信のみに設定
（音声通話とデータになっている場合はデータ通信のみに変更）

私の場合は上記をすることで解決しました。

モバイル通信のデータ通信設定をデータ通信のみにすると電話ができなくなるのではないかと不安に思うかもしれませんが、関係ありません。
4Gでの「音声+データ通信」というのは、「VoLTE通信」なので、データ通信のみにしても、データ通信が4Gになるだけで、音声通話は3G帯域で行えるので問題ありません。あくまで4Gを音声通話で使うことで、音声がよりクリアになるというだけの話です。

ちなみに、私の場合は、最初はデータ通信のみにすることでネットにつながるようになるのですが、後で再度「音声+データ通信」にしてみたところ、問題なく設定することができました。

そのため、結局のところmineoDプランの場合音声+データ通信でもできたので、そこが原因だったのかどうかは確かではありません（調べると、iPhone7とmineoDプランはどちらもVoLTEに対応しているということでしたので動作はするはずです）が、私の場合そこをデータ通信のみに切り替えることでネットにつながるようになったので、最初のネットワーク設定のリセットとプロファイルの削除と再インストールを行っても駄目だった方は一度試してみる価値はあるかもしれません。

Macのディスクユーティリティで、first aidという機能があります。

これは、Macのディスクのエラーチェックをしてエラーがある場合は修復をする機能です。

しかし、この機能を使用していると、Macが固まってしまう現象に遭遇します。

この対処法について書きたいと思います。

フリーズしたように見えるのは正常動作

実は、first aid実行時に、Macがフリーズした「ように見える」のは正常な動作です。

実行時に上記のような説明文が表示されますが、説明文に

「First Aidにより、起動ボリュームが一時的にロックされます。実行中はアプリケーションが応答しなくなります。」

と書いてあります。

そのため、First Aidを実行中にはしばらく他のアプリケーションをクリックしても応答しなくなるため、フリーズしたように見えますが、そのまま放置しておくと、時間はかかりますが実行が終了すると、きちんと操作できるようになります。

数時間放っておいてもそのままフリーズしたような状態のままの場合、本当にMacに何かエラーが発生している可能性がありますが、大抵は数十分程度放置していると実行結果がきちんと返ってくるはずです。

Laravelのファイルとフォルダのパーミッション設定についてです。

下記の記事が参考になりました。

Laravelのパーミッションを適切に設定 | Qiita

ディレクトリに対して権限を変更
sudo find laravel-root-directory -type d -exec chmod 750 {} \;

ディレクトリは750なので、所有者は全部可能、グループは読み実行可能、その他はできない設定

ファイルに対して権限を変更
sudo find laravel-root-directory -type f -exec chmod 640 {} \;

ファイルは640なので、所有者は読み、上書き可能、グループは読みのみ可能、その他はできない設定

最後にストレージとキャッシュの権限を変更
sudo chmod -R 770 laravel-root-directory/storage/ laravel-root-directory/bootstrap/cache/

ストレージ、キャッシュフォルダは所有者、グループは全部可能。その他はできない設定。

webサーバーのApacheをインストールすると作成されるwww-dataをグループに追加する
sudo chown -R myusername:www-data laravel-root-directory

これは、上記はwww-dataグループになっていますが、自分の環境（CentOS、nginx）では、httpdのグループがwwwだったので、以下の設定で上手くいきました。

sudo chown -R myusername:www laravel-root-directory

グループ「www」がphpを自分の環境の場合実行しているので、phpファイルは読み出しのみの設定で問題ありませんでした。
phpファイルの実行権限は、所有者、グループとも読みのみで問題ないんですね。
実行権限が必要なのかなとイメージ的には思っていたのですが。

例えばPerlなんかはCGIで755にするのが一般的でしたが、755ってのは所有者は全部できて、グループユーザが読み、実行権限があるということですもんね・・・。

使っているPHPはPHP-ｆｐｍなので、モジュール版ではなくてCGI版なのですが、同じCGIでもPerlとPHP-FPMではパーミッションが違うと、これはややこしい話です・・・。

LaravelをCentOS、nginx環境にインストールしたのですが、初期設定完了後にサイトへアクセスすると、404エラーが発生しました。

エラーログを確認すると

permisson denied

が発生

phpファイルへのアクセスが拒否されているようです。

該当のエラーが起きているファイルやディレクトリを

chmod 777 エラーが起きているファイル

にしています。

結果、そこから先のファイルがさらにエラー

プロジェクトフォルダとファイルを全て777にしたらいけるんでしょうけど、それはそれでセキュリティに不安が残ります。

そもそも、nginx環境のphpのサイトで、プロセスを実行しているユーザってどのユーザなのでしょうか。

ps　コマンドでプロセスを監視してみます。

すると

httpd php-fpm

となっていたので、ユーザ「httpd」が実行しているようです。

ユーザ「http」が属しているグループはどこなのでしょうか。

groups httpd

httpd : www

ということで、httpdユーザは、グループ「www」に所属していました。

プロジェクトフォルダのオーナーをwwwに変更してみます。

chown -R ユーザ名:www プロジェクトフォルダ名

これで、該当のフォルダのオーナーのグループが「www」になりました。

これで、サイトにアクセスするとエラーが消えて無事にサイトが表示されました。

サーバはkusanagiを利用しているのですが、

phpinfo();

で表示されるphpのバージョンは7系なのに、

サーバにログインして、コマンドラインで

php -v

で表示されるのは、5系というよくわからない事象に遭遇して困ってしまいました。

これで何故困るかというと、Composerをアップデートしたときに、以下のようなエラーが出たからです

このComposerのアップデートには、phpの7系が必要だよ

みたいなエラーです。

しかし、phpinfo()で確認すると使っているPHPのバージョンは7系で、サーバにログインしてコマンドラインで実行している
Composerは5系のPHPを見ているようだという謎です。

調べてみると、KusanagiのPHPは、Webサーバで実行しているのはPHP-fpmというCGI版のPHPで、コマンドラインで実行しているのは、apache経由でモジュール版のphp5系で実行しているとかとういったかんじの現象のようでした。

Kusanagiのサーバでは、rootでサーバにログインして

kuasanagi php7

を実行することでphp7の実行環境に切り替わるようですが、apacheのモジュール版はphp7になっていない？？

というよく分からない感じです。

さらに調べると、Kusanagiではサーバにログインして

yum update

で、モジュール版もPHP7に切り替わるといったことが書いてあったので、試してみると、

yum updateでエラー

で、これはサーバのPythonのバージョンを3系に上げていたので、Python2系で書かれているyumがエラーを起こしている様子
これは、いろいろとぐぐることで対応方法が出てきたので、yumのソースで、Pythonのパスが書いてあるところを、
サーバに残っているPython2系へのパスに何箇所か変更します。

これで yum update　が実行できました。

これで、満を持して

php -v

を実行。すると、またも

php 5.6〜〜〜

と。え、php7に変わってない・・・？

いったん諦めてから翌日サーバにログインして

php -v

をもう一度実行してみると

PHP 7.3.1 (cli)

と、無事アップデートしてました。

よく分からないですが、yum updateしてからサーバに反映されるのに
時間が必要だった？みたいで、apacheを再起動することで反映されたのか、
よく分かりませんが、何にせよ時間経過で反映されました。

よく分かりませんが、Composerで実行していたPHPは、モジュール版というよりも、CLI版
というPHPのようで、確かにphp -vをすると

PHP バージョン(cli)

と、cliを後についています。
ここのCLI版のバージョンが影響していたようですが、何にせよ今回のケースでは
yum update　で無事解決したようです。

この後、

Composer update

を実行すると、無事エラーにならずアップデートを行うことができました。

CentOSで、suコマンド(ユーザの変更)を実行した際に、以下のエラーメッセージが表示されました。

実行しようとしたコマンド
su ユーザ名

表示結果
bash: /home/ユーザのホームディレクトリ/.bashrc: 許可がありません

原因と対処

いろいろと調べてみたところ、該当のユーザのホームディレクトリに、そのユーザのアクセス権限がなかったことが原因でした。
何かの作業中に、間違ってそのディレクトリのオーナー権限を変更していたが原因だったみたいです。

以下の対応で解決しました。

cd /home/

chown ユーザ名:ユーザ名 ./ユーザのホームディレクトリ

これは、該当のディレクトリのオーナーとグループをそのユーザにするということです。

この後に再度suコマンドで該当のユーザに変更したところ、問題なく実行できるようになりました。

Linux系のサーバにrootユーザでログインして、Composerを実行しようとすると、以下の警告メッセージが表示されます

Do not run Composer as root/super user! See https://getcomposer.org/root for details

https://getcomposer.org/root　を見ろということなのでアクセスしてみると、説明がありました。

How do I install untrusted packages safely? Is it safe to run Composer as superuser or root?

どうやって信頼されてないパッケージを安全にインストールできますか？
Composerをスーパーユーザやルートユーザで安全に実行できますか？

Certain Composer commands, including exec, install, and update allow third party code to execute on your system. This is from its “plugins” and “scripts” features. Plugins and scripts have full access to the user account which runs Composer. For this reason, it is strongly advised to avoid running Composer as super-user/root.

Composerのコマンドには、実行、インストール、アップデートが含まれていて、システムに影響するコードを実行することをサードパーティに許可します。
これは、プラグインとスクリプトの特徴に由来しています。プラグインとスクリプトはComposerを実行するユーザアカウントに完全にアクセスします。
この理由により、Composerをrootユーザで実行しないことを強く推奨します。

You can disable plugins and scripts during package installation or updates with the following syntax so only Composer’s code, and no third party code, will execute:

あなたはプラグインとスクリプトを、パッケージをインストールかアップデート時に以下のコードを追加することで無効にすることができます。
サードパーティのコードは実行できなくなります。

composer install –no-plugins –no-scripts …
composer update –no-plugins –no-scripts …

The exec command will always run third party code as the user which runs composer.

In some cases, like in CI systems or such where you want to install untrusted dependencies, the safest way to do it is to run the above command.

execコマンドはサードパーティのコードをcomposerを実行するユーザと同じように実行します。

いくつかのケースで、CIシステムまたは信頼されていない依存関係をインストールするときに、最も安全なのは上記のようなコマンドで実行することです。

ComposerはPHPのパッケージ管理ツールですが、Composerを使用する前に、まず環境にComposerがインストールされているかの確認が必要になります。

CentOSでの確認方法についてですが、導入が完了されている状況であれば、コマンドラインで

composer

と打てば、下記のようなコマンドが表示されます。
インストールされている場合は、現在の入っているComposerのバージョンも確認できます。

Composerのインストールは、公式サイトからインストーラーをダウンロードしてセットアップ後、作成されたcomposer.pharを、

/usr/local/bin/composer

へ移動させることで実行可能になるので、ここまでができていれば上記の様な画面が表示されます。

なければcomposerコマンドが実行できないはずです。

インストールの手順は以下の通りです。

php -r “copy(‘https://getcomposer.org/installer’, ‘composer-setup.php’);”

php composer-setup.php

php -r “unlink(‘composer-setup.php’);”

mv composer.phar /usr/local/bin/composer

Laravel Homesteadで、2つ目のサイトを追加する手順についてです。

Homesteadに２つ目のサイトを追加する手順についてですが、メインマシンのHomesteadディレクトリにある、Homesteadディレクトリにサイト構成を追記します。

Homestead.yml

sites:
– map: homestead.test
to: /home/vagrant/code/project1/Laravel/public

– map: homestead.test2
to: /home/vagrant/code/project2/public

databases:
– homestead

– site2

サイトと、データベースに必要なデータを追加します。

その後、Vagrantを再起動します

vagrant reload –provision

メインマシンのhostsファイルに、2つ目のサイトの設定を追記します。

192.168.10.10 homestead.test2

これで、homestead.site2にアクセスすると、

no input file specified

となります。

2つ目のサイトにLaravelがインストールされていないためです。

メインマシンから

vagrant ssh

で仮想マシンにログインします。

Laravelをプロジェクトフォルダにインストールします。

cd /home/vagrant/code/
composer create-project –prefer-dist laravel/laravel project2

この後、

homestead.site2

にアクセスして、Laravelの初期サイトが表示されたら初期設定完了となります。

Ubuntuのサーバで、特定のディレクトリを削除しようとしたところ、エラーが発生して削除できませんでした。

実行しようとしたコマンド
rmdir ./directory

発生したエラー
rmdir: failed to remove ‘./diectory’: Device or resource busy

このエラーについて調べてみたのですが、削除しようとしたディレクトリが、マウントディレクトリになっているということで、削除できないようです。

以下の対処をすることで削除できるようになりました。

sudo umount ./directory

上記コマンド(ディレクトリのマウントを解除)実行後、

rmdir ./directory

これで問題なく削除できるようになりました。

Laravelで認証機能を使う方法についての解説です。

Laravelには認証に必要な機能が最初から準備されているので、必要であれば使用することができます。

ちなみに、普通にベーシック認証を行うのであれば、.htaccessを使えばいいのですが、ここで言っている認証とは、ユーザIDとPWを入力してログインし、ログインしていなければログインページに飛ばされるというやつです。

あまりカスタマイズしないのであれば簡単に実装できます。

artisanでauth機能を準備する

コマンドラインで、Laraｖelのプロジェクトフォルダに移動し、

php artisan make:auth

このコマンドを実行します。

これを準備することで、必要なファイルがLaravelディレクトリに生成されます。

rouesファイルに追記されている

routesのweb.phpに、さきほどのコマンドを実行することで、下の２行の記述が追加されています。

Auth::routes();

Route::get(‘/home’, ‘[email protected]’)->name(‘home’);

上記は、homeディレクトリにアクセスしたときに、ログイン画面が表示される記述です。

あとは、ルートファイルの認証をかけたいページに、以下の記述を追加することで、該当するページに認証がかかります。

Route::get(‘/admin’, ‘[email protected]’)->middleware(‘auth’);

基本認証

ログイン画面を通した認証でなく、基本認証をしたい場合も簡単に実装できます。

auth.basicミドルウェアを使用します。

Route::get(‘/admin’, ‘[email protected]’)->middleware(‘auth.basic’);

基本認証を使用した場合に求められるID/PWは、laravelでプロジェクトを作成後にmigrateで作成される、userテーブルに登録されているユーザemailとパスワードと同じになります。

Laravelをインストール後に、初期設定で変えておく場所についてのメモ書きです。

.envファイル

.envファイルは、Laravelをインストールにしたフォルダにあります。

ここに、プロジェクトが接続するデータベースに関する設定などの情報が保存してあるので、必要に応じて変更する必要があります。

.envファイルを変更した後に反映させるには、

php artisan config:clear

を実行する必要があります。

app.php

/config/ディレクトリにある「app.php」ファイルに、いくつか設定に関する項目があります。

timezoneの設定です。日本のサイトの場合は、Asia/Tokyoにしておくとよいでしょう。

‘timezone’ => ‘Asia/Tokyo’,

デフォルトでは、en になっていますが、これは英語ということなので、日本語に設定します。

‘locale’ => ‘ja’,

ただし、これだけでは英語のままでに保護になりません。

/resources/lang/en

このフォルダとその中のファイル群を

/resources/kang/en

にまるっとコピーします。

あとは、それ以下にエラーメッセージの文章が全部英語で書いてあるので、それを
地道に日本語に変更します。

全部変更すると大変なので、使っているぶんだけ変更することでも問題ないと思います。

以下に翻訳版が上がっていました。
5.1のだそうですが・・・。

Laravel 5.1 日本語バリデーションメッセージファイル

また、これだけでは attributeが英語で出力されるので

さきほどの validation.phpの

‘attributes’ => [],

このようにすることで、対応するattributeが日本語で出力されます。

‘attributes’ => [
‘title’ => ‘タイトル’,
‘body’ => ‘本文’,
]

Laravel5.7で、フォームを作っていてエラー発生時に入力のフォームの値を保持する方法についてです。

結論からいうと、bladeテンプレートに　{{ old(‘項目名’) }}　の値をもたせることで入力前の値を保持できます。

こんなかんじです。

 <table class="table table-striped">

            <tr>
                <td>タイトル</td>
                <td><input type="text" name="title" value="{{ old('title') }}" placeholder="タイトルが入ります" /></td>
            </tr>

            <tr>
                <td>本文</td>
                <td><textarea name="body">{{ old('body') }}</textarea></td>
            </tr>

これは、入力値のフォームなので、はじめは空欄なので、入力前の値だけ保持できていればいいですが、これが編集する場合だと

初期）　編集前の値を持っている
エラー時）　入力エラーの値を持っている

の２つの状態を持っている必要があります。

これは以下のように記述することで解決できます。

<table class="table table-striped">

            <tr>
                <td>タイトル</td>
                <td><input type="text" name="title" value="{{ old('title' , $post->title) }}" /></td>
            </tr>

            <tr>
                <td>本文</td>
                <td><textarea name="body">{{ old('body', $post->body) }}</textarea></td>
            </tr>

oldの２つ目にデフォルト値を持たせることができます。

Laravelで簡単なフォームを作るのは基礎中の基礎ですが、慣れないうちは何箇所かつまづいたので記録に残しておきます。

フォームの仕様

記事を投稿してデータベースに保存する

件名(タイトル)と本文を入力し、データベースへ保存する。

サイトへアクセスすることで保存された記事一覧と、

ただこれだけのシンプルな仕様。

まずは環境構築

環境構築にはhomesteadを利用しました。

手順はこちらの記事に書いているので割愛します。

Laravel Homestead導入時の悪戦苦闘メモ

最初にやったのは古いバージョン(Laravel4系)だったので、再度やりなおしてLaravel5系でやってみました。

Laravel HomesteadをPHP7で動作させる

環境構築に手間取りましたが、ようやく動作したのでフォームの制作

１．マイグレーションでデータベースを作成

まずは、Homesteadの環境にログイン後、Artisanコマンドでテーブルを作成します
今回は、記事を投稿するので、postsというテーブルを作成

php artisan make:migration create_posts_table –create=posts

public function up()
    {
        Schema::create('posts', function (Blueprint $table) {
            $table->increments('id');
            $table->string('title');
            $table->text('body');
            $table->boolean('delete_flg')->default(0);
            $table->timestamps();
        });
    }

ファイルを作成した後、

php artisan migrate

でテーブルを作成します。

モデル作成

テーブルを作成後、テーブルに対応したモデルを作成します。

php artisan make:model Post

これで、

/App/Post.php

が作成されました。
これで、テーブルに対応したオブジェクトを呼び出すことができるようになります。

このモデルはあとで使います。

管理画面を作る

まずは、記事を投稿する管理画面を作ります。

まずは管理画面の処理に対応するコントローラーを作成します。

php artisan make:controller AdminEntryController

これで、/Http/Controllers/AdminEntryController.phpが作成されました。

このファイルには管理画面の処理に対応する記述を追加していきます。

この時点では雛形が作られただけで処理は何も入っていません。

ルーティングを記述する

/admin/entry にアクセスしたとき、管理画面の投稿画面を表示するようにします。

ルーティングを記述ファイルは、/routes/web.phpにあります。

これに以下を追記します。

Route::get(‘/admin/entry’, ‘[email protected]’);

これでは、url「/admin」にアクセスしたときに、コントローラAdminEntryControllerの「top」メソッドにアクセスするということです。

最初は、とりあえずテンプレートを単純に表示するだけにしてみます。

public function top()
    {
        return view('admin.entry');
    }

これは、このメソッドが実行されたときに

/resources/views/admin/index.blade.phpを表示するという処理です。

まだテンプレートを作成してないので、URLにアクセスしてもエラーになります。

テンプレートを作成します。

bladeテンプレートの作成

bladeテンプレートは、laravelで使われているテンプレートで固有の記法があります。

CMSやフレームワークを使ったことがある人であればテンプレートという説明を聞くと大体イメージがつかめると思いますが、基本的には同じです。

ただ、bladeテンプレートの特徴としては、親と子の継承というものが特徴です。

大体のサイトは、基本となる共通部分があって、後はコンテンツ部分やタイトルなど、一部異なる部分があります。

Laravelのbladeテンプレートでは、共通している部分をまず、親のテンプレートとして作成します。

あとは、それぞれのページは、親のテンプレートを継承することで、異なる部分だけ作成するというようなイメージです。

この特徴により、子のテンプレートは最小限の記述で、また必要なテンプレートも最小限ですみます。

これで、bladeテンプレートの作成が完了したら、/admin/へアクセスすると、エラーがなければサイトが表示されます。

フォームを作成する

とりあえず、作成したフォームの雛形のテンプレートは以下の通りです。

注意が必要な点としては、フォームは、デフォルトの設定では、クロスサイトリクエストフォージェリ対策に、@csrfをテンプレートに埋め込んで置く必要があります。
これを書いていないと投稿時にエラーになります。

@extends('admin.parent')

@section('title', '投稿管理(入力画面)')

@section('content')
    <form action="/admin/entry/" method="post" id="formid" enctype="multipart/form-data">

        @csrf

        <table class="table table-striped">

            <tr>
                <td>タイトル</td>
                <td><input type="text" name="title" value="" placeholder="タイトルが入ります" /></td>
            </tr>

            <tr>
                <td>本文</td>
                <td><textarea name="body"></textarea></td>
            </tr>

            <tr>
                <td colspan="2" class="text-center">
                    <input type="submit" name="submit22" value="登録" class="btn btn-primary">
                    　<input type="hidden" name="action" value="ok">
                </td>

            </tr>

        </table>

    </form>
@endsection

これを、実行したときに登録する処理を追加する必要があります。

まずは、ルーティングに以下を追加します。

Route::post(‘/admin/entry’, ‘[email protected]’);

最初のルーティングは、getで書いてましたが、投稿の処理はpostで渡すことで処理を分岐できます。

postでURLにアクセスしたときには、同じコントローラーでも異なるメソッドを実行するようにしています。

上記の処理ではcompleteメソッドを実行します。

completeメソッドの定義

completeメソッドを以下のように定義しました。

    public function complete(Request $request)
    {
        $post = new Post();

        $post->title = $request->input('title');
        $post->body = $request->input('body');

        //セーブメソッドは、継承している親クラスのモデルオブジェクトに定義されている
        $post->save();

        return view('admin.complete');
    }

$post = new Post();

で、最初に作成したPostモデルのオブジェクトを呼び出しています。

この記述で行うには、ファイルの先頭に

use App\Post;

を追記しておく必要があります。

この追記がない場合

$post = new App\Post();

になります。

その変数にポストで投げられた値をリクエストから取得して、saveメソッドでデータベースへ保存します。

その後は、完了画面のテンプレートを表示します。

この処理はかなりシンプルですが、Laravel独特の記法なので、覚えておく必要があります。

エラーがなければ、これでフォームの保存が実行できます。

投稿のサイトへの表示

今度はサイトに表示する処理を書いてみます。

一覧画面と詳細画面に分けて作成します。

まずはルーティングに必要な処理を追加します。

//トップページで一覧表示
Route::get(‘/’, ‘[email protected]’);

//詳細ページの表示
Route::get(‘/post/{id}’, ‘[email protected]’);

この例では、ページの表示処理を、PostsControllerというクラスを作成して行います。

トップページに一覧を表示する（indexメソッドの実行）処理、詳細ページを表示する処理（detailメソッドの実行）に分けています。

PostControllerは、最初と同じく

php artisan make:controller PostController

で作成しておきます。

以下が、PostsControllerクラスに定義した、トップページと詳細ページの表示のメソッドです。

use App\Post;

class PostsController extends Controller
{
    //トップページを表示する
    public function index(Request $request) {

        $posts = Post::where('delete_flg' , '<>', '1')
            ->get();

        return view('index', compact('posts'));

    }


    //ブログ詳細記事を表示する
    public function detail(Request $request, $id) {

        $post = Post::find($id);

        return view('post', compact('post'));

    }
}

indexメソッドでは、削除フラグが1でなく記事を取得するような処理を行っています。

detailメソッドでは、URLから取得したユーザIDに該当する記事を取得して、テンプレートに表示しています。

bladeテンプレートはそれぞれ以下のように定義しています。

@extends('layout')

@section('title', "新着記事")

@section('content')

    <ul>

    @foreach ($posts as $post)
        <li><a href="/post/{{ $post->id }}">{{ $post->title }}({{ $post->created_at->format('Y年m月d日') }})</a></li>
    @endforeach

    </ul>

@endsection

@extends('layout')

@section('title', $post->title)

@section('content')

    <p class="text-right">{{ $post->created_at->format('Y年m月d日') }}</p>

    <div class="contents">
    {!! nl2br(e($post->body)) !!}
    </div>

@endsection

記事の編集、削除

最後に、管理画面から記事の編集と削除を行えるような処理を追加します。

今回のケースでは、ルートファイルにまず以下のような処理を追記しました。

Route::get('/admin/edit/{id}', '[email protected]');

Route::post('/admin/edit/{id}', '[email protected]');

Route::get('/admin/delete/{id}', '[email protected]');

編集画面は、同じURLでアクセスしますが、最初はgetでアクセスし、編集完了処理はpostでアクセスすることで実行するメソッドを分けています。

//記事を編集する
    public function edit(Request $request, $id) {

        $post = Post::find($id);

        return view('admin.edit', compact('post'));

    }

    //記事の修正を完了する
    public function store(Request $request , $id)
    {
        $post = Post::find($id);

        $post->title = $request->input('title');
        $post->body = $request->input('body');

        //セーブメソッドは、継承している親クラスのモデルオブジェクトに定義されている
        $post->save();

        return view('admin.complete');
    }

    //記事の削除を完了する
    public function delete(Request $request , $id)
    {
        $post = Post::find($id);

        $post->delete_flg = 1;

        //セーブメソッドは、継承している親クラスのモデルオブジェクトに定義されている
        $post->save();

        return view('admin.delete');
    }

削除処理は、delete処理を使うのではなく、一応データベースには残しておきたいので、delete_flgを１にするアップデート処理にしています。

管理画面のトップページのbledeテンプレートも、記事一覧を表示するように変更しておきました。

@extends('admin.parent')

@section('title', '投稿管理')

@section('content')
<div class="text-right">
    <input type="submit" name="submit" value="新規登録" class="btn btn-primary" onclick="location.href='/admin/entry/'" />
</div>

    <div class="content">

        <table>
            @foreach ($posts as $post)
                <tr><td><a href="/post/{{ $post->id }}">{{ $post->title }}</a></td><td><input type="submit" value="編集" onclick="location.href='/admin/edit/{{ $post->id }}'" ></td><td><input type="submit" value="削除" onclick="location.href='/admin/delete/{{ $post->id }}'" ></td></tr>
            @endforeach
        </table>

    </div>

@endsection

Laravelでサイトを構築するのに、仮想環境でHomesteadを利用していたのですが、サイトへアクセスすると、最初だけ「502 Bad Gateway」というエラーが表示される状況に遭遇しました。

しかも、ずっと表示されるわけでなく、何回か再読込をすると解消するという謎の状況。

とりあえず、nginxのエラーログを見てみると、以下のエラーが。

[error] 2276#2276: *472 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 192.168.10.1, server: homestead.test, request: “GET / HTTP/1.1”, upstream: “fastcgi://unix:/var/run/php/php7.3-fpm.sock:”, host: “homestead.test”

このエラーで対処法をググっていろいろ調べていたところ、対処法が見つかりました

New Laravel (Homestead) installation: 502 Bad Gateway – *Refresh* – the website is displayed correctly | stackoverflow

以下の通りにすることで治りました。

まずは、/etc/php/7.3/mods-available/xdebug.iniを編集します

sudo vim /etc/php/7.3/mods-available/xdebug.ini

上記ファイルの行の頭に「;」を全てつけてコメントアウトします。

nginxと、php7.3-fpmを再起動します

sudo service nginx restart
sudo service php7.3-fpm restart

これで、502 bad gatewayのエラーは出なくなりました。

xdebugというのが、phpのエラーを詳細に追いかけるツールだそうで、それが有効になっていることの副作用的なかんじでしょうか？

何にせよ上記を無効にすることで治りました。

Homesteadのlaravelで、artisan migrateでデータベースを作成しようとしたところ、エラーが起きました。

実行したコマンド
php artisan migrate

エラーの内容
SQLSTATE[HY000] [1045] Access denied for user ‘homestead’@’localhost’ (usin
g password: YES) (SQL: select * from information_schema.tables where table_
schema = homestead and table_name = migrations)

原因についてですが、laravelの実行ディレクトリで、「.env」ファイルを編集する必要があるということなので、編集してみましたが、結局同じエラーが出て接続できません。

さらに原因を調べてみたのですが、「.env」ファイルを変更してもそれを反映させるためにコマンドを実行する必要がありました。

laravelの実行ディレクトリで、以下のコマンドを実行します。

php artisan config:clear

これで、再度マイグレーションを実行したところ、問題なく実行され、データベースにも反映されました。

Laravel HomesteadをPHP7で動作させる方法についてです。

Laravelの仮想環境のLaravel Homesteadについて検証していたのですが、公式サイトのチュートリアルに沿って導入していると、何故かLaravelと、対応するPHPが5系でした。

最新のPHP7に対応させるための方法を探していたのですが、調べると何のことはなく、公式サイトのHomesteadのチュートリアルにはPHP5系に対応する記事と、PHP7に対応する記事でそれぞれチュートリアルがあるだけでした。

前の記事で紹介していたのは、4.2なのでphp5系に対応してました

Laravel 4.2 Homestead (PHP5対応)

Laravel 5.7 Homestead (PHP7系対応)

後者のチュートリアルに従ってやっていれば問題なくPHP7系のHomestead環境が整いました。

前者はHomesteadコマンドベースになっていて、後者はVagrantコマンドがベースになっているので、やり方の違いに若干戸惑いましたが・・・。

laravelの勉強をしていて、環境構築用にlaravel homesteadを導入してみたのですが、かなり苦戦したのでメモを残しておきます。

laravel homesteadとは

laravelをローカル環境に導入するときに、環境構築の手間を省くために公式に準備された仮想環境構築ツールです。

laravel homesteadの仮想環境の構築には、Virtual Box+Vagrantを利用するのですが、Vagrantの設定をlaravelの仮想環境に特化するように準備してくれるツールです。

公式サイトには、laravel homesteadを使うことでローカルへの環境構築が楽ちんになると書いてあったのですが、思わずはまってしまったのでメモとして残しておきます。

導入の手順

１・Virtual BoxとVagrantをダウンロードします。

homesteadは基本Virtual BoxとVagrantを使うだけなので、何はともあれこの２つをインストールします。

２・Composerが導入されていない場合はComposerを導入します

Composerは、phpのパッケージ管理ツールです。
Composerは、Laravelを導入するのにあたってほぼ必須となるツールです。
入ってない場合は入れておきます。

３・Homsteadの設定を行います

公式サイトの手順に従います

HomesteadのCLIツールのインストール

composer global require “laravel/homestead=~2.0”

bashプロファイル ~/.bash_profileを編集してコマンド実行パスを追加

export PATH=$PATH:~/.composer/vendor/bin

ymlファイル（Vagrant用の設定ファイル）の初期化

homestead init

SSHキーの設定

ssh-keygen -t rsa -C “[email protected]”

homesteadの仮想環境生成

homestead up

それで、以下のエラーが出ました。

Bringing machine ‘default’ up with ‘virtualbox’ provider…
There are errors in the configuration of this machine. Please fix
the following errors and try again:

vm:
* The host path of the shared folder is missing: ~/Code

これは、要するに、ホームディレクトリに Codeというフォルダがないということです。

cd ~
mkdir ./Code

これで再度

homestead up

これでエラーが解消され、問題が解決しました

これで、仮想環境が作成されたのでSSHでアクセスしてみます

homestead ssh

無事仮想環境にログインできました。

メインマシンのhostsファイルに、以下を追加します。

192.168.10.10 homestead.app

公式サイトによると、この時点でサイト(homestead.app)へアクセスできるはずなのですが

http://homestead.app

上記URLへアクセスすると、エラー。

No input file specified

これは、ファイルが存在していないということらしい。

調べて見ると、 ymlファイルに設定されているのが以下の通りなのですが

sites:
– map: homestead.app
to: /home/vagrant/Code/Laravel/public

これは、上記のドメインが、/home/vagrant/Code/Laravel/publicに紐付けられているということなのですが、仮想マシンにログインして確認したところ、「/home/vagrant/Code/」以下に、Laravelのディレクトリが存在していない。

これには相当ハマってしまい、調べても原因がよく分かりませんでした。

とりあえず、メインマシンのcomposerのバージョンが少し古かったみたいなので、メインマシンのcomposerのバージョンを最新に更新。

homestead destroy

これで一旦仮想環境を削除して

homestead provision

これで再度作り直してみます。

これで再度サイトへアクセスすると、表示されました。

しかし、今度は別のエラーが・・・

autoload.phpがないとかそういうことらしく、調べれてみると、必要なファイルが存在してないのがあるようなので、これはComposerをアップデートしたらいいということなので、アップデートしてみます。

composer update

すると、途中でエラー。

proc_open(): fork failed – Cannot allocate memory in phar:///usr/local/bin/composer/vendor/symfony/console/Application.php

メモリが足りていないというエラーです。

php.iniを編集して、memory_limitを編集してみるも、駄目。
調べると、swap メモリの設定を追加したらいけるということ。

仮想マシン内で、以下のコマンドをスーパーユーザ権限で実行

sudo /bin/dd if=/dev/zero of=/var/swap.1 bs=1M count=1024
sudo /sbin/mkswap /var/swap.1
sudo /sbin/swapon /var/swap.1

これで再度Composerをアップデートしたところ、通りました・・・！

Laravelの初期画面。ついに起動！ここまで長かった・・・

雑感

簡単に仮想環境が構築できるといいつつ、やってみると何箇所かはまるポイントがあって大変でした。

ぶっちゃけ、ローカルの仮想環境って、homesteadなんか使わなくてもMAMPやXAMPで十分じゃね・・・という気もしますが、何故Vagrant+Virtual Boxを使うのが良いのかよくわかりません。

また、仮想環境にデフォルトの設定で2GBのメモリが割り当てられるようなので、仮想環境にメインマシンのメモリも圧迫されます。

とりあえず、こういうものもあるということで、引き続き色々使って試してみようとは思います。

その後

Homestead環境のセットアップが終わってからですが、まずは、Laravelのデフォルトのサイトが表示されています。

その後どうやってサイトを作り込んでいくかですが、メインマシンの

~/Code

フォルダが仮想マシンのエイリアスになっているようなので、そこを作業フォルダにしていけばその後の仮想環境の作業をメインマシンで進めていけます。

作ったサイトはhostsファイルにドメインと仮想マシンのIPアドレスを紐付けることで、仮想マシンでの表示が確認できます。

Homesteadの仮想環境はメモリを圧迫するので、使い終わったら、コマンドラインで

homestead halt

で停止することができ

homestead up

で再度起動できます。

homestead環境の削除

vagrant box remove laravel/homestead –all

ymlファイルの更新後の仮想環境への反映

vagrant reload –provision

Laravelのバージョンアップ

公式のLaravel5.7のHomestead導入ガイドに従ってHomestead環境をセットアップしたのに、デフォルトのLaravelのバージョンが5.4で最新の5.7ではなかった。

5.4から5.7へのバージョンアップは、仮想環境のLaravelフォルダまで移動して、個別に行った。

手順としては、Laravelフォルダにある composer.jsonファイルを編集して、設定内容の変更を行った後に、

composer update

で適用される。
（このあたりはググったら色々でてくるので詳細は割愛）

laravelで、homesteadを導入時に、以下のエラーに遭遇しました

コマンド

homestead up

を実行

それで、以下のエラーが出ました。

Bringing machine ‘default’ up with ‘virtualbox’ provider…
There are errors in the configuration of this machine. Please fix
the following errors and try again:

vm:
* The host path of the shared folder is missing: ~/Code

これは、要するに、ホームディレクトリに Codeというフォルダがないということです。

cd ~
mkdir ./Code

これで再度

homestead up

これでエラーが解消され、問題が解決しました

サーバでいろいろ設定をしていると、パスを通すという言葉が、ときどきあります。

この、パスを通すというのがどういう意味についてなのですが、サーバやコンピュータでコマンドを実行する際に、そのコマンドの実行ファイルがどこにあるかということです。

ユーザはコマンドラインで様々なコマンドを実行していますが、それは、結局コンピュータやそのサーバの中で、そのコマンドに対応する実行ファイルがどこかにあるのです。

linux系のサーバやコンピュータであれば

/bin/
/sbin/

といったディレクトリ以下に、それらの実行ファイルがあります。

そのディレクトリを開いてみると、多くの実行ファイルがあり、慣れ親しんだ ls や cd といった実行ファイルも存在しています。

これは、linux系であれば、/bin/や/sbin/は、はじめから定義されているのでその場所はわかり、また、bash_profileでは

/usr/bin/
/usr/sbin/

といった場所にははじめからパスが通してあります。

コンピュータでコマンドを実行した際に、コンピュータは、そのパスが通っている場所以下の、コマンドに該当する実行ファイルを探しているわけです。

もしコンピュータ全体から実行ファイルを探そうとすると、膨大な時間がかかっているため、パスを通すことで実行ファイルの場所を絞っているわけです。

特定のソフトウェアをインストールした場合、そのソフトに対応するコマンドが利用できるようになる場合がありますが、ソフトをインストールしただけでは、コマンドのパスが通っていないため、実行ができないことがあります。

これができるようにするためにパスを通す必要があるのです。

パスを追加することで、パスが通された以下にあるディレクトリに実行ファイルがないかどうかを検索対象に追加されます。

パスの変更の仕方

.bash_profileを編集します。

.bash_profileは、ホームディレクトリにあります。
ない場合は作成するとよいです。

編集後、

source ~/.bash_profile

で反映されます。

AmazonのCEOであり、世界長者番付一位の大富豪である経営者・ジェフベゾスの不倫がばれて、それが原因かどうかは定かではないですが（おそらくはそうでしょう）、離婚するということが、先日話題になりました。

この件に関しては、ジェフ・ベゾス自身も公式Twitterで公表しています。

pic.twitter.com/Gb10BDb0x0

— Jeff Bezos (@JeffBezos) 2019年1月9日

離婚の原因と言われているのが、ハリウッドの有力エージェントであるPatrick Whitesell(パトリック・ホワイトセル)氏の妻でニュースキャスターのLauren Sanchez(ローレン・サンチェス)さんとのW不倫で、それがスクープされたからだと言われています。

Daily Mailで、ジェフ・ベゾス氏がローレン・サンチェスさんに送ったテキストメッセージが流出し、スクープされています。

'I want to smell you, I want to breathe you in': Jeff Bezos' steamy text messages to married TV anchor revealed https://t.co/iHQlLrdz5L

— Daily Mail US (@DailyMail) 2019年1月10日

ジェフ・ベゾス氏がサンチェスさんに送ったテキストメッセージ全文

ジェフ・ベゾス氏がサンチェスさんに送ったテキストメッセージが公開されていて、以下の内容となっています。

‘I love you, alive girl. I will show you with my body, and my lips and my eyes, very soon.’

‘I want to smell you, I want to breathe you in. I want to hold you tight.… I want to kiss your lips…. I love you. I am in love with you.’

‘I miss you. I want to kiss you right now and tuck you in slowly and gently. And maybe in the morning wake you up and not be quite so gentle with you.’

‘Your energy and ideas and competence and SPIRIT turn me on. You make me better. You’re meant for me.’

‘I am so full of love for you. My heart is growing just so it can have room for you. It’s bigger than it’s ever been and still swelling.’

‘I want to hold you tight.… I want to kiss your lips…. I love you. I am in love with you.’

‘You know what I want? I want to get a little drunk with you tonight. Not falling down. Just a little drunk. I want to talk to you and plan with you. Listen and laugh … I basically WANT TO BE WITH YOU!!! Then I want to fall asleep with you and wake up tomorrow and read the paper with you and have coffee with you

簡単に和訳してみました。

——————————————————-

愛しているよ、元気なあなたを。
あなたに私の体とくちびると、目を見せたい、今すぐに。

あなたの臭いを嗅ぎたい、あなたに息を吹きかけたい、強く抱きしめたい・・・
あなたの唇にキスをしたい・・・愛している、私はあなたへの愛と共にある。

あなたがいなくて寂しい。
私はあなたにすぐキスをして、ゆっくりと紳士的に押し倒したい。
そして朝起こして完全にあなたと紳士的ではない。

あなたのエネルギーとアイデア、能力とスピリットは私をその気にさせる。
あなたは私をよりよくする。あなたは私のために生まれてきた。

本当にあなたを愛している。
私のハートは成長して、あなたと部屋にいたい。
それはこれまでになく大きくなってまだ膨らんでいる。

あなたは私が何を欲しがっているか知っている？
私は今夜あなたと少し飲みたい。
泥酔はしない、少し飲むだけだ。
私はあなたとの計画を話したい。
聞いてそして笑う・・・私は単純に貴方と一緒にいたい！！
そして私は貴方と一緒に寝て、次の日に起きて、新聞を読み、コーヒーを飲みたい。

———————————————-

若干下ネタも入っていますが、ジェフ・ベゾス氏が、かなり情熱的にサンチェス氏に熱を上げている様子がわかります。

また、このメッセージに追加として、シャツを来ていないタオルだけを纏ったベゾス氏が鏡の前に立っている自撮り写真をサンチェス氏に送っていたそうです。

世界一の資産家でありIT企業のCEOも、メッセージが芸能人と同じように流出してしまうというのかというかんじがしますね・・・。

一昔前でいうとカードゲームはアナログで遊ぶものでしたが、最近はスマホやタブレットをはじめとしたデジタルカードゲームが人気となっています。

そこでデジタルカードゲームがどのくらい人気があるのか調べてみました。

ハースストーン(Hearthstone)

ハースストーンは世界でのプレイヤー数が1億人を突破しているということです。

プレイヤー1億人突破を祝おう！ | ハースストーン

ただし、これは累計でのプレイヤー数なので、アクティブユーザがそれだけいるのかどうかは不明です。

調べたところ、月間プレイヤー数が3000万人ということなので、それでもだいぶアクティブ数がいるようです。

とはいえ、Googleトレンドで見る限りでは、検索結果は徐々に減っているようなので、アクティブユーザ数は減少傾向にあるといえそうです。

ちなみに、これは全世界でのプレイヤー数なので、日本でどれだけの数のプレイヤーがいるかどうかも不明です。

グーグルトレンドの検索結果を見る限りでは、ハースストーンよりもシャドウバースのほうがプレイ人口は倍近くなのでだいぶ多いようです。

世界で見ると圧倒的に人気なのがHearthstoneと言えるでしょう。

シャドウバース

シャドウバースは、ダウンロード数が2000万ダウンロードを突破したということなので、ハースストーンと比較するとプレイ人口はだいぶ少ないです。

しかし、ハースストーンは世界で人気なのに対してシャドウバースは日本で人気のあるゲームなので、日本国内ではハースストーンよりもプレイ人口が多いものと考えられます。

海外のプレイヤー数がどのくらいいるのかは調べてみたものの不明でした。

おそらくメインは日本人プレイヤーだと思います。

ドラゴンクエストライバルズ

ドラゴンクエストライバルズは、ダウンロードが1300万を突破したということなので、ダウンロード数だけで見るとそれなりに伸びてはいるようです。

しかし、グーグルトレンドでの結果を見る限りでは、ドラゴンクエストライバルズの検索結果が見られません。

しかし、Youtubeの動画を見ているとそれなりに再生回数は出しているので、ある程度のユーザ数はいるように思えます。

ドラゴンクエストは、主に日本でのファンが多いゲームなので、プレイヤーもほとんどが日本人だと考えられます。

ドラゴンクエストが好きなユーザ向けに開発されたゲームで、ゲーム自体はよく作られているのですが、ドラクエユーザとカードゲームユーザがあまり一致しないのか、プレイヤー数は伸び悩みがやや感じられる気がします。

番外編：アナログカードゲームはどうなのか

Magic the gathering

アナログカードゲームのMagic the gatheringについても調べてみたのですが、こちらもGoogleトレンドを見る限りでは、全盛だったのが今から20年以上前で、プレイヤー数は徐々に減少し、現在は安定期になっているようなイメージです。

全盛期に比べるとだいぶプレイ人口が減っていますが今なお世界的に人気のカードゲームということはできるでしょう。

2013年にhearthstoneが発売されてから、当初はhearthstoneが爆発的な伸びを見せましたが、現在は減少傾向にあるので、およそhearthstoneのプレイヤー数の半数くらいがmtgのプレイ人口であるといえそうです。

遊戯王、デュエルマスターズ

大人のカードゲーマー達からすると若干知名度が低い気もしますが、紙のカードゲームでは遊戯王とデュエルマスターズが最も日本国内では高いようです。

売上ベースでみると、マジックザギャザリングとは比較にならないほど、これらのカードゲームは売上が高いです。

Googleトレンドで見ると、国内では「遊戯王」の検索結果が最も多い結果となっていますが、これがカードゲームの遊戯王を指しているのかどうかよく分かりません。

※ 私は遊戯王プレイヤーではないので、何故遊戯王だけ検索結果がこれだけ多いのか、理解不能です・・・。

データベースを勉強していると、やたら出てくるのが「トランザクション」や「コミット」「ロールバック」という言葉です。

PHPやMysqlでプログラミングで案件に携わっていても、これらのトランザクションという仕組みに遭遇する機会が実はそれほどなかったりするのでイメージとしては掴みづらかったりします。

トランザクションとは

トランザクションとは、複数のSQLの実行処理を１つのまとまりにまとめたものです。

トランザクション内でのSQL実行時に正常に実行できなかったり、何か問題が発生した場合、トランザクション開始時まで巻き戻す（ロールバック）を行います。

分かりやすい例でいうと、銀行口座から別口座への送金がそうです。

ある口座からお金を引き落とす処理を行って、別講座に加算する処理を行うまでの間にシステム障害が発生したとすると、口座からお金が引かれた状態で、別の口座にはお金が加算されていない状態になり、そこから復元できなくなる可能性があります。

これを防ぐのがトランザクションという仕組みで、まとまりの処理が終了するまでの間にエラーが起きたら初期の段階にロールバックをして巻き戻したり、あるいは資源をロックして、他の処理からアクセスできないようにします。

MySQL+PHPのデフォルト仕様

MySQL+PHPではオートコミットがONになっています。

これはどういうことかというと、個別にSQLを実行するたびに自動でCommitを行います。

そのため、SQLは個別に処理されるため、上記のような銀行口座の処理のような仕組みを実装する場合には、トランザクションの仕組みを別途記述して実装しないといけません。

PHPにも begin Transaction　commit rollbackといった機能があるため、必要に応じて記述することで、トランザクションの仕組みを利用することが可能です。

自分が現在作成しているSQLのプログラムにトランザクションの仕組みを導入する必要があるかどうかというのは、その処理によるため、必ずしも全ての処理でトランザクションを記述しなければいけないということではありません。

ただし、仕組みとしては理解しておく必要があるでしょう。

Javascriptでデータベースに値を挿入したり、取得する方法についてです。

基本的にはできない

結論からですが、基本的にはできません。

理由としては、Javascirptは、クライアントサイドの言語だからです。

クライアントサイドというのは、PC側のブラウザの機能で処理を実行するということです。

データベースというのは、サーバ側です。

そのため、サーバ側のデータベースから値を取得しようと思った場合、サーバ側で処理を実行する必要があります。

Javascirptはサーバ側で動くプログラムではないため、この処理は一般的にはサーバサイドの言語で行います。

サーバサイドの言語としては、例えばPHPやRubyなどがあります。

サーバサイドの処理として、これらの言語と組み合わせることが一般的には必要になります。

例外としてNode.jsを使えば可能

例外として、Node.jsを使うことでjavasciptの記述でデータベースに接続して処理を行う事が可能です。

Node.jsは、サーバ側の処理をjavascriptで行うことを可能としています。

jquery3をサイトに導入していたところ、以前のjquery1系で動いていたプログラムが動かなくなったので原因を調べていました。

原因を調べる方法は、Safariの開発者用のツールで、開発→javascriptのコンソールで調べていたのですが、エラーの内容が

$.get is not a function

というものでした。

このエラーメッセージについて調べていたのですが、原因がわかりました。

読み込んでいたのはjquery3だったのですが、

https://code.jquery.com/jquery-3.3.1.slim.min.js

というライブラリを読み込んでいたのですが、この末尾についている「slim」というのが、容量を軽くするために、いくつかの機能を省いているバージョンらしいです。
getもその１つで、その他にもajaxなども動作しないようです。

そのため、読み込み先をslimでなく普通のjqueryに変更したところ動くようになりました。

https://code.jquery.com/jquery-3.1.0.min.js”

使っていたスマートフォンのキャリアを、ソフトバンクからMVNOのmineo(マイネオ)に乗り換えて使ってみたので、感想を書いてみます。

ソフトバンクから乗り換えた理由

ソフトバンクを解約して安いMVNOに乗り換えた理由はただ一つで、月額料金の安さです。

ソフトバンクを利用していたときは、毎月7000円〜8000円の月額料金を支払っていましたが、mineo(マイネオ)に乗り換えてから毎月2500円程度の月額費用ですむ計算になります。

実に半額以下の利用料金になっている計算になります。

ソフトバンクからMVNOに乗り換えると本当に、半額以下になって単純にお得なのか？

ソフトバンクからmineo(マイネオ)に乗り換えることで、半額以下の月額料金になりましたが、ここにはカラクリがあって、単純にまるまる半額安くなったというわけではありません。

ソフトバンクは、機種本体代金の割引でお得感を出している

ソフトバンクは携帯電話の機種本体の代金を２年縛りで本体代金を割引（実質無料）のような形にすることで、お得感を出しています。

例えばiPhoneは、シムフリーの新製品を買うと10万円くらいしますが、これはMVNOを利用している場合、機種代金は別なので

MVNOの場合
月額2500円×24 + 10万円 = 16〜17万くらい

ソフトバンクの場合
月額8000円×24 + 本体割引で実質無料 = 17万くらい

ということで、新機種の携帯電話を２年ごとに買い換えることを考えた場合、MVNOでもソフトバンクでも総費用にそこまで差はありません。
（もっとも、MVNOで２年毎に新製品を買い換える場合、旧製品を売ることで少しお得になると思いますが）

しかし、携帯電話を４年使う事を考えた場合

MVNOの場合
月額2500円×48 + 10万円 = 22万くらい

ソフトバンクの場合
月額8000円×48 = 38万４０００円くらい

と、１５万円以上MVNOのほうがお得という計算になります。

つまり、MVNOは、１つの機種を長く使い続ければ続けるほど、また、スマホ本体の機種料金が安ければ安いほどお得になります。

一方、ソフトバンクなどの３大キャリアは、２年ごとにiPhoneを最新機種に買い換えることを考えるとMVNOを比較してもそこまで遜色ある内容ではありません。

以上のことを考えて、どちらが自分に合っているかを考えてみるといいでしょう。

自分の場合は、これまではiPhoneを２年おきに新しくしていたのですが、やめてできるだけ長く使い続けることにしました（といっても、４年おきくらいになると思いますが）

そのため、今後はこれまでよりもトータルで見て安くなると思います。

また、機種をiPhoneの最新の機種でなくて少し古い機種で我慢したり、Androidにすればよりコストパフォーマンスはよくなるでしょう。

デメリットは何なのか

ソフトバンクからmineoに乗り換えたことによるデメリットは何があるか

１・月額容量

月額容量が、ソフトバンクのときは月7GBでしたが、一方でmineo(マイネオ)にすることで、月3GBの契約にしています。

そのため、月に利用できる容量は減っていますが、これまでの利用履歴を確認したところ、平均月2GBくらいの使用だったので概ね問題ないと思います。

これは、自分の使い方が、自宅のWi-Fiがメインで、キャリアでの通信はおまけだからです。

こでも、自分がどのくらい毎月使うかを考えて選ぶと良いと思います。

２・混み合っている時間の遅さ

次に、昼どきなど混み合っている時間に通信帯域が制限されて遅くなるという点についてです。

これは実際あると思うのですが、私の場合はほとんど気になりませんでした。

理由としては１と同じで、Wi-Fiでの使うのがメインでキャリアの通信はおまけ程度だからです。

これが自宅にWi-Fiがなしでキャリアがメインでとなると、また違ってくるかもしれません。

今のところ問題は上記の２点だけです。

値段以外でmineoにしてよかったこと

値段以外の点で、mineoにしてよかったことも使ってみると何個かありました。

１．未使用帯域を翌月に繰り越せる

現在の契約では月の帯域は3GBですが、使わなかった場合、未使用分を翌月に繰り越すことができます。
例えば、１GBしか使わなかった月は、余りの２GBは翌月に繰り越せるので、翌月は5GB使うことができます。
そのため、実質的には3GBよりは多く使えるイメージです。

２．テザリングが無料

ソフトバンクのときは、テザリングオプションが月額500円かかっていました。
mineoではテザリングオプションがなくてもテザリングが可能です。

３．専用の通話アプリを使うことで通話料金が安い

ソフトバンクは、ソフトバンク同士の電話での通話料金は時間帯によっては無料ですが、それ以外のキャリアに電話した場合、30秒20円の通話料金がかかります。

mineoの場合、普通に電話した場合キャリア関係なく30秒20円の通話料金ですが、専用の通話アプリ「mineoでんわ」を使って通話をした場合、30秒10円の通話料金になります。
また、この通話アプリも使い勝手はそこまで悪くありませんでした。

トータルで見た満足度：非常に高い

ソフトバンクからmineoに乗り換えてしばらくたちましたが、総合的に見て満足度は非常に高いです！

今のところ他のMVNOに替えようかとか、３大キャリアにしようかという不満はありません。

ポイントとして、自分の利用の仕方がWi-Fiメインか、そうでないかというのは重要なポイントとなると思うので、迷っている人はその点を踏まえて検討されてはと思います。

マクドナルドにMacbookを持っていって、繋がらなかったときの対応のメモです。

状況

Macbook Proをマクドナルドの無線LANに接続して、ブラウザを開く
↓
ポップアップでマクドナルドのWi-Fiログインの画面が出てこようとするが、「証明書が無効です」と出てくる→証明書の設定と出てくるので、証明書の設定をクリックして、常に信頼にチェックを入れる
↓
やはりポップアップが真っ白のままでログイン画面が出てこない

対応

ブラウザを開くと、ネットにはつながらないが、ブラウザの画面に「時計が遅れています」→「PCの時刻と時計が合っていません」というエラーが表示されていることを確認。

PCの時計設定を見ると、確かに1月１日になって時間とずれていた。

そこで、MacbookProのWi-Fiの設定をスマホとテザリングでスマホのネットワークにつなぎ直し、Macbookの時刻設定をネットにつなげて一旦合わせる

この後に再度マクドナルドのWi-Fiにつなぎ直すことで無事にポップアップでのログイン画面が表示されてつながるようになりました。

CSSフレームワークとして有名な、Twitter bootstrapについての勉強メモです。

bootstrapのインクルード

ダウンロードしてFTPでアップロードしなくてもCDNからincludeする記述ができます。

//4系
//ヘッダに記述
<link rel="stylesheet" href="https://stackpath.bootstrapcdn.com/bootstrap/4.1.3/css/bootstrap.min.css" integrity="sha384-MCw98/SFnGE8fJT3GXwEOngsV7Zt27NXFoaoApmYm81iuXoPkFOJwJ8ERdknLPMO" crossorigin="anonymous">

//フッタに記述
<!-- オプションのJavaScript -->
<!-- 最初にjQuery、次にPopper.js、次にBootstrap JS -->
<script src="https://code.jquery.com/jquery-3.3.1.slim.min.js" integrity="sha384-q8i/X+965DzO0rT7abK41JStQIAqVgRVzpbzo5smXKp4YfRvH+8abtTE1Pi6jizo" crossorigin="anonymous"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/popper.js/1.14.3/umd/popper.min.js" integrity="sha384-ZMP7rVo3mIykV+2+9J3UJ46jBk0WLaUAdn689aCwoqbBJiSnjAK/l8WvCWPIPm49" crossorigin="anonymous"></script>
<script src="https://stackpath.bootstrapcdn.com/bootstrap/4.1.3/js/bootstrap.min.js" integrity="sha384-ChfqqxuZUCnJSK3+MXmPNIyE6ZbWh2IMqE241rYiqJxyMiZ6OW/JmZQ5stwEULTy" crossorigin="anonymous"></script>

グリッドシステム

bootstrapは、12本のグリッドで構成されていて、幅を指定する場合にそのグリッドのどれだけを利用するかを指定でき、幅指定がスムーズです。

クラス

.container　クラス

全体を囲うコンテナです。
画面幅によって可変です。

.container-fluid　クラス
可変のコンテナです

.row
行に与えるクラス

.col
列に与えるクラス

.col-画面幅-グリッド数

画面幅
bootstrap3系 .col-xs Extra Samll オートレイアウト(全幅に対応、主にスマホ縦用)
bootstrap4系 .col- Extra Samll オートレイアウト(全幅に対応、主にスマホ縦用)
3、４共通 .col-sm Samll 576px(スマホ横)
3、４共通 .col-md Medium 720px (PC)
3、４共通 .col-lg Large 940px(PC)
3、４共通 .col-xl ExtraLarge 114opx(PC)

レスポンシブの対応

列のグリッド指定は、12を超えると自動的に折り返します。

この仕組みを使って、例えばレシポンシブで記述する場合は以下のようにします。

<div class="container">

<div class=".col-xs-12 .col-md-4">
左カラム(PCのときは左カラムの隣に右カラムが回り込む、スマホのときは下に回りこむ)
</div>
<div class=".col-xs-12 .col-md-8">
右カラム
</div>

</div>

上記はBootstrap3系の場合で、bootstrapが4系の場合は以下の記述になります。
col-xsが4系ではcol-になっている他、containerだけでなく、rowで囲ってやらないといけなくなっています。

<div class="container">
 <div class="row">
<div class=".col-12 .col-md-4">
左カラム(PCのときは左カラムの隣に右カラムが回り込む、スマホのときは下に回りこむ)
</div>
<div class=".col-12 .col-md-8">
右カラム
</div>
 </div>
</div>

上記のように記述すると、スマホレイアウトのときは左カラムの下に右カラムが入ります。(.col-xs-12 4系では .col-12が適用される)
PCで見た時は、左カラムの横に右カラムが回り込みます(.col-md-4、.col-md-8)

メニューを折りたたみ式にしたい

collapseというクラスを指定することで、メニューを折りたたみ式にすることが可能です。

<button type="button" class="btn btn-info" data-toggle="collapse" data-target="#menu">menu</button>
<ul id="menu" class="collapse">
    <li></li>
<li></li>
    </ul>

テーブルのtdの横幅

bootstrap4からは、 class=”w-◯◯”(◯◯は数字)で横幅を%指定できる。

靴を毎日長いことはいていたら、臭いがついて自分でも少し気になるようになってしまいました。

靴の臭いを簡単に取る方法というのをネットで調べていると、「冷凍庫で1日冷凍すると菌が死んで臭いが取れる」という記述があったので試してみました。

1日冷凍してみた結果

1日靴を冷凍してみたところ、出した直後は臭いが確かになくなっていたのですが、しばらく時間が経つとまた臭いが少し戻ってきました。
つまり、冷凍したら臭いが消えるというのはでたらめで、菌は冷凍することで冷凍されている間は活動を停止するのですが、気温が戻ることで活動は再開されます。
臭いの原因は菌なので、冷凍したからといって菌が死ぬことはありません。（あくまで出した直後だけです）

熱湯に浸してみた結果

臭いの原因は菌ということは、逆に熱湯に浸すと菌は死滅するのでは？
ということで、煮沸した熱湯に靴を浸してみると臭いは消えるのか実際に試して実験してみました。

靴を鍋に入れて煮込む・・・というかんじではなく、煮沸したお湯に靴を数秒間浸してから抜き出すという程度です。
（さすがに煮沸まですると靴がおかしくなりそうなので）

熱湯は効果があった・・・しかし別の注意が必要

靴を熱湯を浸してみると、臭いが消えました。

これは、やはり一定以上の温度の熱で菌が死滅するからだと思います。

肉などの生鮮食品が、加熱すると安心というのと理屈は同じですね。

しかし、熱湯の熱は、靴の素材によっては、素材がおかしくなってしまうデメリットがあります。

私の試した靴では、靴の中敷きにしている素材がゴムのような素材だったので、熱で少し変形というか、歪むようなかんじになってしまいました。

こういうことがあるので、靴も素材を確認してふやけたりしそうであればやめたほうがいいでしょう。

しかし、臭いは乾かすと見事になくなりました。

靴は毎日同じ靴を履いていて蒸れたりすると臭いがつくのであくまで一時的な対処にしか過ぎないと思いますが、熱湯に浸すのは確かに効果があったので、臭いが気になる人は自己責任でやられてはと思います。

また、細菌は靴の中の何らかの汗や垢などを食事にしているようなので、単純に靴を何足か持っておいて、臭いが気になりだしたら予備の靴を準備しておいて、そちらに履き替えて臭いが取れるまで放置するのもおすすめです。
（というか、どちらかというと熱湯に浸すのも荒療治で素材に影響があるので、靴の臭いが気になる方は、できればそちらのほうがおすすめです）

WordPressで、ソースコードにSQLを直書きで新着記事を10件表示するというのをやってみました。

やりたいこと

PHPのファイルにSQLを直書きで、新着記事から10件の記事を表示したい

何故SQL直書きが必要なのか

WordPressには、新着記事を指定件数表示する記述が準備されているので、通常であればSQL直書きで記事を取り出す必要はありません。

しかし、今回やりたいことは、WordPressのサブディレクトリにインストールした別のWordPress(ブログ用）から、新着記事を表示したいということです。

もともと、Simplepieというライブラリを使ってやっていたのですが、サイトをhttps化すると取得ができなくなってしまいました。（理由は分かりません）

そのため、仕方なしで、本体のサイトでブログのデータベースに接続し、そこから最新記事を取り出すことにしました。

SQL文は以下のようなかんじです。

#新着記事を10件取り出す
$s_sql = "
            select post_title, post_date ,guid
              from wp_posts
            where post_status = 'publish' order by post_date desc limit 10";

一応解説すると
wp_posts　・・・　WordPressの記事が格納されているテーブル
post_title ・・・　記事タイトル
guid ・・・　記事のURL
post_status = publish ・・・　記事が公開されている
order by post_date desc limit 10　・・・・　最新記事から10件

あとは、普通に while文でループして記事を出力したらOKでした。