このエントリーをはてなブックマークに追加

入社して1年が経過した岩原です。こんにちは。
最近、リモートワークが話題ですね。
今回は、1年間リモートワークをして体感したことや、リモートワークに必要なものなどを書いていきたいと思います。
あくまでも環境に大きく左右されるものなので、参考程度と思っていただければ。

リモートワークに必要なもの

まずは、リモートワークに必要なものを挙げてみたいと思います。

インターネット回線

必須です。
意外と家にインターネット回線がひかれてない家庭も多いと聞きます。
いざリモートワークを始めようとした際に、どうにもならなくて詰みます。 ビデオ会議などでそれなりに帯域を使用するため、ISDNやADSLではなく、VDSLや光ファイバーを使用した光回線の方が良いでしょう。

作業用のパソコン

職場でパソコンを使用している方は必須です。
職場から支給されていれば問題ありませんが、最近は家にパソコンが無い家庭も増えています。
BYODの場合は申請が必要な場合もありますので、会社に確認をしてみましょう。

ちなみに、弊社ではリモートワーカーにMacBookPro(スペック盛り盛り)を支給しています。

テキストコミュニケーション能力

ほぼ必須です。
中には仕事中ずっとビデオ会議をつないでいるようなところもありますが、
それでもチャットなどでほぼリアルタイムにやり取りすることのほうが圧倒的に多くなります。
メールのように冗長にならず、かつ的確に自分の思いを記すのは思ったより大変だったりします。

また、顔を突き合わせての同期コミュニケーションではなく、非同期コミュニケーションになるため、
相手からの即時返信を期待せずに仕事できる状態にしておくことが重要になってきます。

急ぎの場合はビデオ会議にしたほうが良いですが、相手が応じることができる状況にあるとは限らないので、
どちらにしてもある程度並列稼働できるようなタスク状態にしておくことが重要です。

図太さ

テキストコミュニケーションでは相手が忙しいかどうか伺ってから質問などというマナーは不要です。
そもそも、忙しいかどうかが見えないので、いつまで経っても質問できない状態のままになってしまいます。
したがって、相手の状況がわからなくても質問を投げるような、ある程度の図太さは必要です。

自分の状況を発信する

相手の状況が見えない == 自分の状況も相手からは見えていないということなので、
あらゆる手段を用いて自分の状況を発信する必要があります。

GitHubのIssueやPull Requestなどで細かくログやコミットを残したり、
分報チャンネルが有るならば、悩んでることややってることを発信したりします。

自分が抱いている不安は相手も抱いている可能性がある、ということを念頭に置いておくと、
トラブルを未然に防ぐことが出来ます。

体感したこと

ここからは、1年間のリモートワーク生活を通じて体験したことを並べていきます。

意外と変わらない生産性

一番懸念してた生産性については、意外と出社するのとほぼ変わらないかと思います。
割り込みや業務外の雑事などによる生産性の低下はありませんが、
その代わり家事や子供の世話などが入ってくるので、私の場合は、トータルでトントンになるかと思います。
むしろ、かわいい子供からの割り込みは英気を養ういい機会にすらなります。

一人暮らしの方や、一人になれる環境がある方は生産性が上がる…とも言い切れなかったりします。
自宅にいるということで、スイッチがなかなか切り替わらず、生産性が上がらない…ということもあるかと思います。

仕事とプライベートの切り分けの難しさ

家で仕事する場合、どうしても仕事とプライベートの切り分けが難しくなります。
いざ時間になってもなかなか取りかかる気になれない…といったことがよくあります。
私の場合は、メガネを普段用から仕事用のものに変えることで、スイッチを切り替えています。
なにかしらのスイッチを用意しておくか、いっそのこと自宅から出てしまうのが良いでしょう。

通勤によるストレスからの解放

満員電車による通勤がなくなった分、ストレスはなくなりました。
こちらは思ってもみなかった効果です。満員電車によるストレスは意外とあるようです。
これは明確にリモートワークになってから良かったと思える点です。
その代わり出勤による運動がなくなったため、意識しないとあっという間に運動不足になってしまいます。

まとめ

リモートワークで効率を上げられるかどうかは、いかにして集中できる環境をつくるか見えない環境にいるということを意識する いうことに尽きるかと思います。
会社で真面目にやってる風ではなく、実際にタスクをこなさないと評価されない状態にはなるので、
色々と健全かと思います(個人的にあまりそういう状態を見たことはないのですが)。

また、一人暮らしなどで止める人が誰も居ないと、仕事にのめり込みすぎてしまう場合があるので、
意識的に時間を見るようにしたほうが良いでしょう。

昨今注目されているリモートワークですが、何かの参考になれば嬉しいです。


このエントリーをはてなブックマークに追加

こんにちは。澤井です! 私はカルテット入社前にWordPressを使ったサイト制作をしていました。 入社後の現在でも保守や構築を作業する事があり、WordPressは私にとってなじみの深いCMSです。

今回は、そんな私にとってなじみの深いWordPressの基本機能である、パーマリンクについてすこし詳しく書こうと思います。

パーマリンク

WordPressの公式ドキュメントでは、パーマリンクを以下のように解説しています。

パーマリンクとは、ブログの個々の投稿、カテゴリーなどの投稿一覧ページへの恒久的 (半永久的) な URL です。

主に使われるパーマリンクは2種類あります。

  • Uglyパーマリンク(デフォルト)
  • Prettyパーマリンク

パーマリンクは、WordPress管理画面 > 設定 > パーマリンク設定で設定します。

パーマリンク設定画面

本記事では、Uglyパーマリンクの表示の流れを確認して、その後にPrettyパーマリンクUglyパーマリンクに変換するルール(リライトルール)についてみていきたいと思います。

Uglyパーマリンク

WordPressをインストールした直後のURL構造は、https://example.com/?p=123のように、クエリ文字列を使用します。 この形式は、Uglyパーマリンクと呼びます。

WordPressは、クエリ文字列にマッチする投稿を表示します。 例えば、スラッグがcategory-sampleのカテゴリーの中で、投稿IDが1の投稿を表示するURLは以下のようになります。

https://example.com?p=1&category-name=category-sample&page=

※ 実際には、https://example.com?p=1で同じ投稿を表示できますが、 説明を分かりやすくするために、category-name=category-sample&page=も加えています。

上記のpcategory-namepageなどを、パブリッククエリとよびます。 パブリッククエリは、WordPressがデータベースに問い合わせする際の条件として使われます。 WordPressで使用可能なパブリッククエリは、WPクラス(wp-includes/class-wp.php)で定義されています。

WordPressは、パブリッククエリをもとに問い合わせ条件を作成し、SQLを実行してデータベースから表示すべき投稿を取得します。

https://example.com?p=1&category-name=category-sample&page=の投稿取得条件は、以下のようになります(投稿取得条件は、WP_Query::query_varsプロパティで確認できます)。

Array
(
    [p] => 1
    [page] => 
    [category_name] => category-sample
)

pageクエリは、今回の記事では重要でないので、説明しませんが、詳しく知りたい方は以下を参考にしてください。

注: ‘page’ クエリ変数には、コンテンツに クイックタグが含まれページ送りが設定されている個別投稿または固定ページのページ数が含まれます。

関数リファレンス/get query var - WordPress Codex 日本語版

Prettyパーマリンク

Prettyパーマリンクは、ユーザーフレンドリーで見た目の良いリンク構造を提供します。 実際の運用では、Uglyパーマリンクを使うことは少なく、Prettyパーマリンクを使用することが多いと思います。

以下、本記事の主題であるPrettyパーマリンクからUglyパーマリンクへ変換するリライトルールについて記載します。

今回は、Prettyパーマリンクを以下のように設定してみます。

カスタム構造 https://example.com/%category%/%post_id%

上記のようにパーマリンクを設定をした場合、https://example.com?p=1&category-name=category-sample&page=で表示される投稿は、以下URLで取得できるようになります。

https://example.com/category-sample/1

WP_Query::query_varsを確認すると、投稿取得条件は、 Uglyパーマリンクと同じになっています。

Array
(
    [p] => 1
    [page] => 
    [category_name] => category-sample
)

https://example.com/category-sample/1https://example.com?p=1&category-name=category-sample&page=へ変換するルールをリライトルールとよびます。

リライトルールは、wp_options.option_namerewrite_rulesレコードに格納されています。 WordPressは初期化時に、WP_Rewrite::rulesプロパティにリライトルールを保持します。
(WP_Rewriteオブジェクトはグローバル変数$wp_rewriteとしてアクセスできます)。

パーマリンク構造を、https://example.com/%category%/%post_id%に設定したときのWP_Rewrite::rulesプロパティを確認してみます。 WP_Rewrite::rulesは、正規表現とマッチ後の置き換え方法を表します。

正規表現でキャプチャされた部分を$match配列に順番に適用していきます。 上から順にマッチを試み、最初にマッチしたものを変換ルールとして採用します。

WP_Rewrite Object
(
    [permalink_structure] => /%category%/%post_id%
    // ...
    [rules] => Array
        (
            [^wp-json/?$] => index.php?rest_route=/
            // ... 
            [(.+?)/([0-9]+)(?:/([0-9]+))?/?$]
                 => index.php?category_name=$matches[1]&p=$matches[2]&page=$matches[3] --- (1)
            // ...
            [(.+?)/?$] => index.php?category_name=$matches[1]
        )
   // ...
)

https://example.com/category-sample/1は、上記(1)にマッチします。

  • 1番目にキャプチャされたcategory-sampleは、$matches[1]で使用されて、category_name=category-sampleになる
  • 2番目にキャプチャされた1は、$matches[2]で使用されて、p=1になる
  • 3番目のキャプチャはないので、$matches[3]は空になり、page=になる

リライトルールが適用された結果、Uglyパーマリンクhttps://example.com?p=1&category-name=category-sample&page=と同じクエリ文字になります。 結果、WP_Query::query_varsUglyパーマリンクと同じものになります。

Array
(
    [p] => 1
    [page] => 
    [category_name] => category-sample
)

以上、PrettyパーマリンクからUglyパーマリンクへのリライトルールを見てきました。

注:WordPressはフロントコントローラーindex.phpですべてのリクエストを処理するので、他のページにアクセスした時にindex.phpに処理を移すようWebサーバーを設定しておく必要があります。Webサーバーの設定もリライトと呼ばれますが、WordPressのリライト(Ugly/Pretty)とは全く別の設定箇所になりますのでご注意ください。例えばApacheではmod_rewriteを有効にし.htaccessに設定を記述します。

WordPressは、パーマリンクの設定次第でURL構造が大きく変わります。 思ったとおりのURLで投稿が表示されないといった問題が発生した場合は、一度リライトルールを確認すると良いかもしれません。


このエントリーをはてなブックマークに追加

2020年あけましておめでとうございます!今年もカルテット開発部ブログをよろしくおねがいします!

この記事は Symfony Advent Calendar 2019 19日目の記事です。大幅に遅刻しましたが検証に時間がかかったためなのでご容赦ください m(_ _)m

now.shとは

now.sh とは、サーバーレスで様々な言語のウェブアプリケーションを動かすことができるPaaSです。

公式にサポートされているのはnode.js, Go, pythonですが、サードパーティのビルダーを利用することでPHPも使えます。
※ ただし、 PHPのビルトインウェブサーバー を使うことになるので、本番環境にはおすすめできないかもしれません。試す際は自己責任でお願いします。

Symfony4アプリをGitHub経由でnow.shにデプロイしてWEBアプリケーションとして動かす

ソースコード側の準備

src/Kernel.php に細工しておく

now.shの環境では /var/cache/var/log に書き込めないので、キャッシュ書き込み先とログ書き込み先をnow.shでも書き込める /tmp 等に変えておく必要があります。 どこをどのように変えるのかは https://github.com/juicyfx/now-php/blob/master/examples/framework-symfony-microservice/src/Kernel.php を参考にしてください。

.env じゃないファイルを使う

now.shではデプロイ時に .env という名前のファイルはすべて無視されます。
無視しない設定はありません、必ず削除されます(T_T)

かと言って Symfony4+で .env は必要な環境変数のテンプレートなので、内容が全然なくても .env を置かないでアプリケーションを動かすことはできません(厳密に言うと違うんですが…気になる人はお手元のSymfonyアプリケーションのconfig/bootstrap.phpを読んでみてください)。now.shのデプロイ時に .env を消されないためには、 .env.env じゃない名前に変えます。私は myenv にしました。
.env を変えたら config/bootstrap.php でSymfonyDotEnvによって .env を読み込んでいる箇所を探して、 myenv を読むように変更しておきましょう。

Symfony4のphpunit.xml.distはテスト時のbootstrapとして config/bootstrap.php を読み込んでくれるので、ローカルでの機能テスト等も問題なく動きます。
テスト用の環境変数は .env.test でなく myenv.test、 ローカル動作確認用の環境変数は .env.local でなく myenv.local に記載すればOKです。

デプロイ設定

秘密の環境変数の準備(ローカル)

アプリケーションにはDBのパスワードとか、SECRETとか。レポジトリにコミットしたくない環境変数がありますよね。
そういった秘密の環境変数はローカルPCにnow-cliをインストールしてnow-secretsに登録しておきます。

# xxxという変数名でyyyという値を登録
$ now secrets add xxx yyy

注意しておきたいのは、secret名はユーザー別であってプロジェクト別ではないという点です。複数のWEBアプリをnow.shにデプロイしてそれぞれ違う値を使いたい場合はそれぞれ a-password b-password のように、どのsecretがどのプロジェクト用のものかわかるようにしておくと良いでしょう。

.nowignoreの準備

now.shにデプロイするときに無視するファイル・ディレクトリを指定するファイルです。gitignoreと同じようなものと考えてください。
ローカルから /vendor を含めてデプロイしようとするとビルドが FetchError というエラーでほぼ確実に落ちるので、 .nowignore/vendor は除外しておきましょう。
/vendor なしでデプロイしてもサーバー側で勝手に composer install してくれるようです。

now.jsonの準備

now.json を準備します。 now.jsonはnow.shのためのデプロイ指定を記述するjsonファイルです。プロジェクトのルートディレクトリに置きます。

{
  "version": 2,
  "env": {
      "APP_ENV": "prod",
      "MY_ENV": "@my-env"
  },
  "builds": [
    { "src": "public/index.php", "use": "now-php"}
  ],
  "routes": [
    { "src": "/(.*)", "dest": "public/index.php" }
  ]
}

{ "src": "public/index.php", "use": "now-php"} で指定している now-php というのがPHP用のビルダーです。
公式でなくサードパーティ扱いですが、特にベンダープリフィクスは不要のようです。

now.sh側で composer install するときは require-dev は無視されるようなので、 APP_ENV はかならず prod にしましょう。
now secretsに登録した秘密の環境変数は @ をつけて参照できます。(MY_ENVの定義を見てください)

デプロイ

GitHubにpushするだけです。

安定性

正直自分専用の軽いAPIアプリしか動かしてないので、まだわかりません。
最初に書いたように、PHPのビルトインウェブサーバーを使うことになるので、安定性は保証できないと思っています。