投稿者: ぜろみや

  • ゆるいのか!?フリーランス2年目に突入したWebエンジニアの1日

    ゆるいのか!?フリーランス2年目に突入したWebエンジニアの1日

    フリーランスはどのような1日を過ごしているのか、想像したことはあるでしょうか。

    なんかおしゃれな服を着て、薄くて高機能なノートパソコン(Mac)やスケッチブックを持ち歩き、日中はスタバでおしゃれに仕事、クライアントとの打ち合わせをスマートに決め、夜はバッハの旋律を聞きながらこだわりのコーヒーの香りをクールに楽しむ。

    そんなイメージでしょうか。

     

    もしかしたらそんなシャレオツな人もいるかもしれませんが、ここでとあるフリーランスWebエンジニアの1日を見てみましょう。




    タイムスケジュール

    2018年8月現在、だいたいこんな感じで生きてます。

    8:30 起床

    会社員に比べればだいぶ緩やかな起床ですね。ちなみに目覚ましはかけません。

     

    8:32 PC前に移動

    朝起きて2分で仕事場につきました。身支度もする必要ありません。部屋着のままです。通勤時間がないのはフリーランスの特権ですね。

     

    8:35 ブログのアクセスを見る

    今日もほとんどアクセスなしかぁ…そもそも深夜にアクセスがあるわけないのに、どうしても気になりますね。

    現在4つくらいサイトを持ってますが、どれもほとんどアクセスがありません。つらい。

     

    8:40 ソシャゲをはじめる

    仕事しないんですね朝ごはんを食べる前にソシャゲのスタミナを消費する必要がありますので、急いで周回してます。一日の中で唯一急いでいる時間かもしれません。

     

    9:00 朝ごはん

    Amazon Primeでアニメを観ながらのんびり朝ごはんを食べます。朝ごはんはパン派。

    朝ごはん食べないのはいろいろよくないので、絶対に食べましょう。

     

    9:30 ブログのアクセスを確認

    気になるんですよね~。朝起きてから今までにそんなアクセスがあるわけないのに。あっても3人とかです。これはもう病気です。

     

    9:40 仕事開始

    ようやく何か始めるみたいです。仕事開始時間は一般的な会社にほぼ合わせてます。会社員が出勤してる間にのんびりしてるわけですね。

    午前中は、基本的に受託関係の作業はしません。ブログを書いたり、本を読んだり、経営やWebサービスについて学んだり、いわゆる「頭を使うこと」を中心に作業します。

    午前中は一日の中で脳が一番働く時間なので、考えなければいけないことはこの時間に集中して行うと吉です。また、先に受託に手を付けてしまうと一日中だらだら受託に時間を費やしてしまって、受託以外の作業を進めることができないという状況に陥ることが多いため、午前中に無理やり時間をとってやってます。

     

    一日中ただひたすら受託でコーディングやってるわけではありません。それだと事業はいつまで経っても成長せず、やがて受託の仕事が入らなくなれば、そこでゲームオーバーです。

    フリーランスはひとりで経営も仕事もこなす必要がありますので、これはずっとフリーランスとして生きていくために大事なことです。



    13:00 昼ごはん

    またAmazon Primeでアニメを観ながらお昼ごはんをゆっくり食べます。

     

    13:30 昼寝

    実は昼寝をすることで、作業効率が上がることが科学的に証明されています。というかご飯食べた後は普通に眠いので寝ます。

    会社員だったときも、ご飯食べたあと30分間くらい寝てるときが多かったですね。

     

    15:30 起床

    けっこう長いこと寝てましたね

    ちなみにまだ部屋着のままで、着替えてません。ずっと部屋にいるんで部屋着以外の服を着るメリットもないです。
    たぶん寝汗ですごいことになってますが、誰にも会わないので大丈夫。

     

    15:40 仕事再開(コーディング)

    午後からはバリバリコーディングをこなします。基本的に仕事の終わり時間を決めていないし、やらなければいけないことは午前中にやってますので、きりのいいところまで適当にやります。

    チャットの返信や、外注とのやり取りも午後からやることが多いです。とはいえ常に見てますので、もちろん緊急性の高いものは優先します。

     

    18:00 晩御飯

    晩御飯は置き換えダイエットです。お昼いっぱい食べるし、夜はあまり食べなくていいかなと思ってます。だいたい仕事しながら食べてます。

     

    19:00 風呂

    お風呂に入ったあともコーディングが続くことが多いです。

    納期直前なんかは、稀に12時過ぎることもありますね。ただ、まったく苦にはならないです。
    誰にも邪魔されないし、好きな音楽を隣の迷惑にならない程度にガンガンかけてノリノリでコーディングします。終電とかないし、終わったらすぐ寝られますしね。

    納期に余裕があったり、なんか今日はもういいやって思ったら18:30くらいで切り上げることもあります。

     

    1:30 就寝

    きりのいいところまで仕事したら、ブログ書いたりゲームしたり本を読んだり、朝の続きをやることが多いですね。

    だいたい1:30に寝ることにしてます。

     

    まとめ

    上記はある1日の例となりますが、フリーランスは基本的に一日のスケジュールが外的要因によりかっちり決まることがほぼないため、もっと自由です。

    例えば、ふらっと買い物に行ったり、ちょっと仕事したくないなと思ったら京都の観光地を巡ってみたり、隣の県まで行ってみたり…

    その代わり、逆に言えば「全てを自分で管理しなければいけない」ので、あまりにもダラダラしていると生きていけなくなります。

     

    スタバは行かないの?

    行きません。家でやったほうが圧倒的に効率がいいです。

    これが僕の職場です。ノートパソコン(Windows)にモニター繋いでやってます。

    Web制作の場合は開くウィンドウが多い(デザイン、エディター、ブラウザ、フォルダーetc)ので、ノートパソコン1台だと相当きついです。

     

    ただ、デザイナーさんやライターさんであれば、家の中より外に出たほうがいろいろ刺激があり捗りそうな気もします。

    そういった意味で、午前中はどこかのカフェでコーヒーを飲みながら作業するのも良いかなと最近思い始めました。

    また、コワーキングスペースなんかもありですよね。
    コワーキングスペースのメリットは、なんといっても同じようなことをしている人が集まるということだと思いますので、孤独になりがちなフリーランスにとって、仲間をあつめるという意味でもコワーキングスペースを選択肢に入れるのはありだと思います。

     

    打ち合わせは?

    基本、しないですね。電話や通話もほとんどすることがなく、チャットがメインです。今のところ地域を限定せず、クラウドソーシングを使って全国の仕事を請けるスタイルなので。

    打ち合わせや常駐が多い地域密着型フリーランスさんもいらっしゃいますが、僕には向いてないなと思うのでやってません。

     

    バッハの旋律は?

    たまに聞きます。サカナクションのね。
    もし僕の音楽の好みに興味があったら、下の記事を読んでみてください

    https://meshikui.com/2018/07/28/505/

    あと、実はコーヒーもコーヒー屋さんから豆を買ってきて挽いて飲んでます。

    缶コーヒーとかインスタントコーヒーがメインの人、ぜひコーヒーにこだわってみてください。おいしいコーヒーは人生を潤わせますよ~



    おわり

    フリーランスはその自由さから、「みんながだいたいこういった一日を過ごしている」という概念が薄いように思えます。

    会社員のごとく一日きっちり時間を決め働いている方もいらっしゃいますし、僕のようにゆるいけど最低限やることを決めているスタイルや、はたまた働きたいときだけ仕事をとってきて短期集中でバリバリやる方もいらっしゃるかと思います。

    また、常にタイムマネジメントの試行錯誤をしてみたり、事業も成長していますので、1年後には全然違うタイムスケジュールになっているかもしれません。

    不労所得が大量に入ってくるのでもうほとんど働いてないという方もいますよね。羨ましい限りです。

     

    ただ一つ言えるのは、自由だからといって毎日本当に好き放題生きていると、フリーランスとしてはすぐに死にます
    常に今後のこと、事業を成長させることを考えたり、フリーランスとしてだめになってもすぐに別の道へ進めるよう準備をしておいたりといったことを無理やりにでもやっておかないとダメだと思います。

    フリーランスって自由で適当に生きてて楽でいいよねというイメージをお持ちかもしれませんが、案外そうでもないです。
    もしそう見える人がいても、その人はそれまで積み重ねてきた努力の結果、自由を手に入れたんですよ、きっと。

  • WordPress functions.phpを関数ごとに分割して管理しやすくする話

    WordPress functions.phpを関数ごとに分割して管理しやすくする話

    現在はWordPressを使用してのWebサイト制作の需要が高く、小~中規模のコーポレートサイトをWordPressのオリジナルテーマでCMS化するといった案件が多くあります。

    僕が得意なのはこの分野で、何十件ものサイトのWordPressオリジナルテーマを作ってきました。

     

    その中で、やはりだいたいどのサイトでも使うコードというものが存在していて、これを毎回「あれ、どうすんだっけ…」と調べて書くのは非常に効率が悪いしめんどくさいです。

    そんなときは、テンプレート内やfunctions.phpに全てのコードを書くのではなく、関数を作って関数ごとにphpファイルを作って管理することで、以降同じような処理を書くときにぐっと時間が短くなります。

     

    今回は、僕が普段行っているファイルの管理方法を紹介します。




    テーマの雛形を作る

    プログラミングの時短のコツは、なんといっても「最低限必要なソースがあらかじめ用意されている」ということが基本になります。

    bootstrapやLaravelなどのフレームワークと呼ばれるものも原理は同じです。ただ、これらは「人様が用意してくれたフレームワーク」なので、学習に時間がかかる、拡張しづらい、自由が利かないなどのデメリットがあります。

    ただ、チームでの開発のときに、マニュアルが用意されているため自分以外の人が全く何を書いてあるかわからないといった状況にならないため、主に大規模な開発を行ったり、デザインの段階からフレームワークを用いることを前提としているのであれば非常に便利ですが、逆に小規模だけどデザイン性を重視していて、小回りが利いたほうがいいという状態のときは使いづらいです。

     

    そこで、「人様が作ったフレームワーク」ではなく、「自分のために、自分で作る、自分のためのフレームワーク」を作っていこうぜというわけです。

    拡張性に優れている雛形ができれば、サイトを作れば作るほどどんどん使い勝手がよくなっていきます。最初は数時間かかっていた作業も、雛形があれば数分で終わります

     

    WordPressテーマの雛形の例

    ここで僕の雛形をざっと紹介します。

    こんな感じ。

    themeというフォルダ内にテーマファイルを保管していて、WordPressサイトを作るときはこのthemeフォルダごとコピペしてフォルダ名を変更、あとはstyle.cssの中のテーマ名を変更すればテーマの基本は完成。あっというまですね。

    custumizerフォルダはテーマカスタマイザーという機能を使うのに必要なソース、
    tplフォルダは、各ページ共通で読み込まれるテンプレート(ナビとか)
    functionsフォルダはfunctions.phpに書くところの関数を、関数ごとにファイルにして分けてます。

    functions



    なんでfunctions.phpを分ける必要があるの?

    ひとえに、管理、拡張のしやすさが理由です。

    例えば、title.phpとcategory_list.phpの中身を見てみましょう。

    <?php
    /**
    * タイトル文字数制限
    *
    * @param integer $limit 表示させる文字数。引数を指定しない場合は20
    */
    function show_limit_title($limit = 20) {
      global $post;
      $title = $post->post_title;
      
      if( mb_strlen( $title ) > $limit) {
        $title= mb_substr( $title , 0 , $limit ) ;
        $show_title = $title. ・・・ ;
      } else {
        $show_title = $title;
      }
    
      echo $show_title;
    }
    <?php
    /**
    * 一覧とか詳細にその記事のカテゴリーを表示させるやつ
    *
    * @param string $delimiter 区切り文字を指定できる。引数を指定しない場合は区切り文字なし。
    */
    function show_category( $delimiter = null ) {
      $cats = get_the_category();
      $tmp = $cats;
    
      if( !$cats ) {
        return false;
      }
      
      foreach( $cats as $cat) {
        $cat_id = $cat->term_id;
        $cat_link = get_category_link( $cat_id );
        
        // 出力部分
        echo '<a href="' .$cat_link. '">' .$cat->name. '</a>';
        if( $delimiter && next($tmp) ) {
          echo $delimiter;
        }
      }
    }

    各関数については以下の記事で紹介しています。

    WordPress – タイトルの文字数制限を、関数を作っていい感じにやる

    WordPress – その記事が属するカテゴリーの一覧を表示させる関数

    関数ごとにファイルを分け、それぞれの関数にドキュメントで説明を加えています。ドキュメントはWordPressの規約にのっとっているつもりですが、もしできてなかったらごめんなさい。

     

    今のとこ紹介したのは2つですが、これが10個とか20個になったらfunctions.phpどうなると思いますか?どこに何が書いてあるか探すのも時間かかるし、拡張するのも大変になってきます。

    関数ごとにファイルを分けてやることで、拡張したいときは各ファイルを触ればいいし、関数を追加したいときはファイルを追加すればいいだけです。シンプルでわかりやすいですね。

     

    ちなみにこのブログ書いてて思ったんですが、関数の名前とファイル名を一緒にしたほうがもっとわかりやすいですよね。まだまだ修行が足りてませんでした

     

    functions.phpの書き方

    functions.phpの中身は非常にシンプル。

    <?php
    /**
    * Add Theme Supports
    * WordPressのテーマ拡張機能の有効化
    */
    // add_theme_support('menus'); // メニュー機能
    // add_theme_support('post-thumbnails'); // サムネイル機能
    
    
    /** 
    * Include Functions
    * いろんな関数を個々に読み込む
    * いらないものはできればコメントアウトしておきたい
    * 使わないのに入れておくと邪魔なものは最初からコメントアウトしてある
    */
    get_template_part('functions/editor'); // エディターに関するカスタマイズ
    // get_template_part('functions/menu'); //メニュー機能のカスタマイズ用
    get_template_part('functions/mobile'); // スマホ分岐
    get_template_part('functions/short_code'); // ショートコード集
    // get_template_part('functions/widgets'); // ウィジェットの設定
    get_template_part('functions/category_list'); // カテゴリー表示させたりする
    get_template_part('functions/new'); // Newマーク
    get_template_part('functions/pagenation'); // ページネーション
    // get_template_part('functions/thumbnails'); // サムネイルのあれこれ
    get_template_part('functions/title'); // タイトルの文字数制限
    get_template_part('functions/body_class'); // bodyのclassの表示
    
    
    /** 
    * Theme Customizer
    * テーマカスタマイザーを使うときに。
    */
    // get_template_part('customizer/customize'); // カスタマイザーの記述はここ
    // get_template_part('customizer/style'); // 色を変えたりするときのstyleの記述
    // get_template_part('customizer/customizer-repeater/functions'); // repeaterのプラグイン
    // get_template_part('customizer/repeater'); // repeaterのカスタマイズ
    

     

    こんな感じで、各phpファイルをget_template_part();という関数を使って呼び出し、使わない関数はコメントアウトしているだけ。

    get_template_part();については公式Codexをどうぞ。

     

    おわり

    今回は、WordPressテーマ開発の効率化のため、テーマの雛形作りとfunctions.phpの分け方について紹介しました。

    雛形を作るときは苦労するんですが、慣れれば拡張もさくさくいけるようになるし、自分で自分のためになるツールを育てるというのはすごく楽しいです。

     

    同じような作業を繰り返し行う場合は、その作業をいかに短縮するかというのは我々エンジニアの重要なテーマです。

    それでは、良いエンジニアライフを。

  • WordPress プラグインでできる最低限のSEO【インデックス促進】

    WordPress プラグインでできる最低限のSEO【インデックス促進】

    昔から人々を夢中にさせてやまないSEO(検索エンジン最適化)ですが、Googleの技術の進歩により、最近ではコンテンツSEOが大事だよという認識がようやく浸透してきたように思えます。

    しかし、だからといって技術SEOをないがしろにしていいわけではありません。

    コンテンツSEOがユーザーにとって有益な情報を与えるということであれば、技術SEOはGoogleがページ内容を正しく認識できるようにするという意味合いが強いです。

     

    今回は、その技術SEOの中でも僕が特に重要だと思うクロールにフォーカスを当て、正しく迅速にクロールを行ってもらうために使える、WordPressのプラグインの紹介をしたいと思います。

     

    本記事の構成は以下のとおりです

    1.クロールとインデックスについて
    1-1.クロールとは
    1-2.インデックスとは
    2.Search Consoleについて
    2-1.Search Consoleでできること
    2-2.All in One SEO Packの使い道
    2-3.Search Consoleへの登録
    2-4.サイトマップの送信
    2-5.Fetch as GoogleとWebSub(PubSubHubbub)

    それでは順に見ていきましょう。




    クロールとインデックスについて

    クロールはSEOにとって特に大事と冒頭で説明しましたが、なぜなのか、そもそもクロールってなんやねんという話から。

    クロールとは

    Google公式ガイドラインでは、クロールについて以下のように説明されています。

    新しいウェブページや更新されたウェブページを検出するプロセスのことです。Google はリンクをたどる、サイトマップを読み込むなど、さまざまな手段で URL を検出します。Google はウェブをクロールして新しいページを検出し、(該当する場合は)そのページをインデックスに登録します。

    新しいサイトを立ち上げたり、新しい記事を公開したとき、その時点ではまだ検索に載りませんよね。これはなぜかというと、Googleにクロールされていないためです。

    Googleはクローラ(Googlebotと名付けられています)という自動プログラムを使い、ウェブ上に公開されたサイト/ページをクロールしようと日夜活動を続けていますが、基本的にとんでもない数のサイトが日々更新し続けられているため、公開してすぐのサイトに速攻でクロールしに来てくれることはまずありません。

    クロールされなければまだGoogleに認識すらしてもらえていない状況というわけです。これが、公開した記事がすぐに検索に載らない理由です。

     

    インデックスとは

    こちらもガイドラインより引用

    Google は認識したすべてのウェブページを「インデックス」に格納します。各ページのインデックス エントリにはそのページのコンテンツと場所(URL)が記述されています。「インデックスに登録する」とは、Google があるページを取得し、そのページを読み込んで、インデックスに追加することを指します。例文: 「今日、私のサイトの一部のページが Google のインデックスに登録されました。」

    クロールされたページはGoogleによって構造を理解され、インデックスと呼ばれるデータベースに格納されます。この流れはもはや「インデックスされる」という動詞になってしまってますが、正確には「インデックスに登録される」が正しいんですね。

    ユーザーが検索を行うと、このインデックスから、ユーザーが検索した語句に対し最も有益な情報が書かれているであろうページが検索結果に出されるわけです。

     

    以上、クロールとインデックスについてざっくり説明しました。なぜSEOにおいてクロールが重要かおわかりいただけましたでしょうか。

    そもそも、クロールされてインデックスに登録されなければ検索に載らないということですね。

     

    極端な話、例えば速報系の情報を扱っているブログであれば、「速報!台風が明日上陸する!」というタイトルの記事を書いても、検索に載るのが3日後とかだったらまったく意味ないですよね。

    というわけで、以降はこのクロールを促すという点に絞って、その方法と使用するプラグインを説明していきます。



    Search Consoleについて

    Search Consoleとは、Googleで提供しているツールの1つで、サイトを登録することでSEO上重要な様々な恩恵を受けることができます。以前は「ウェブマスターツール」という名前だったんですが、Search Consoleに変わりました。無料で使えます。

    SEOを意識するのであれば、Search Consoleにサイトを登録しないと話になりません

    前述したクロールの促進のためにも重要なので、Search Consoleについて少し説明させていただきます。

     

    Search Consoleでできること

    Search Consoleに登録すると、以下のようなことができるようになります。

    • クロールの促進(Fetch as Google、サイトマップ)
    • 検索アナリティクス
    • サイト上のエラーの通知、改善
    • スパム被害やペナルティの通知、改善
    • セキュリティの問題の通知、改善

    その他にも機能はありますが、SEO上特に重要なのはこのあたりかと思います。

    検索アナリティクスとかおもしろいですよね。こんなワードで検索してんのか…ってなります。学びのためにもぜひ見てみてください。

    各種通知については、登録したメールアドレス宛てにメールがきます。スパム判定とかされたら相当やばいので、Googleからのメールはこまめにチェックしましょう。

    今回はこの中でも、クロールの促進方法について詳しく説明していきます。

     

    All in One SEO Packのインストール

    Search Consoleでなんやかんやする前に、まずWordPress側で少し準備をしましょう。

    今回使うプラグインは「All in One SEO Pack」です。ご存知の方は多いかと思われますが、このプラグイン、名前の通りSEOに必要なことはだいたいできます。

    All in One SEO PackをインストールしていればSearch Consoleへの登録もできますので、まずAll in One SEO Packをインストールしましょう。

     

    Search Consoleへの登録

    All in One SEO Packをインストールしたら、一般設定の中に「ウェブマスター認証」という項目がありますので、そこにSearch Consoleの認証コードを入力します。

    これだけでSearch Consoleとの連携は完了です。Search Consoleでサイトが正常に登録されたかを確認しましょう。

     

    さらに、All in One SEO PackではGoogle Analyticsも設定できます。

    Search ConsoleとGoogle Analytics両方に登録したら、今回のメインテーマはクロールの促進なので、ひとまず他の設定はあとまわし。

     

    サイトマップの送信

    次は、Search Consoleで自サイトのサイトマップを送信します。

    サイトマップを送信することで、Googlebotくんはサイトの構造を把握しやすくなります。また、どこからもリンクされていないページをクロールするのにも使われます。

     

    サイトマップを送信するにはまずサイトマップを作らないといけないんですが、All in One SEO Packなら拡張機能でサイトマップを作れるうえ、記事が更新されるたびにサイトマップも自動で書き換わり、さらに自動で送信してくれます

    これは使わない手はないです。人によってはGoogle XML Sitemapというプラグインを使う人もいるようですが、プラグイン1個で済むならプラグイン同士の競合が発生することもないし、All in One SEO Packではサイトップ生成についても細かく設定ができて便利です。

     

    拡張機能を有効にする

    All in One SEO Packの「機能管理」を選択し、その中の「XMLサイトマップ」を有効にします。

    サイトマップの設定はほとんどそのままでいいと思うんですが、僕は下記2点に注意しています。

    更新を予約

    サイトマップを更新し、Googleにサイトマップを送信するスケジュールです。記事を更新する頻度に合わせて設定します。

    投稿タイプ

    All in One SEO Packの一般設定でnofollowとしているページをここでチェックしていると、Search Consoleでエラーになります。

    サイトマップに書いてるからクロールしようと思ったのに、nofollowって言われて追い返されたんやけど

    ということですね。

     

    サイトマップの生成ができたら、Search Consoleの管理画面からサイトマップを送信します。

     

    フィードの送信

    サイトマップの他にも、フィードの送信をすることも可能です。

    これは僕も最近はじめて知りました。

    サイトマップはサイトの構造をGoogleに伝えるのに対し、フィードを送信することで、更新したページの情報をダイレクトにGoogleに伝えることができます。

    Googleも、サイトマップとは別にフィードの送信をすることを推奨しています。

    自サイトのフィードのURLは、WordPressサイトであればだいたい/feed/となっているはずです。実際にアクセスして確認してみてください。

     

    Fetch as GoogleとWebSub(PubSubHubbub)

    Search Console上からFetch as Googleを行うことで、Googleにクロールを促すことができます

    クロールしてほしいURLを入力し、「取得」をクリック。ちなみに「取得してレンダリング」をクリックすると、Googlebotくんがページをどのように認識しているかを見ることができます。

    「あれ、なんか実際のページと違うんだけど」ということが稀にありますので、たまに見ておきましょう。

    取得すると「インデックス登録をリクエスト」というボタンが出てきますので、迷わず押しましょう。これで、クロールしてもらい、インデックスをやってくださいとお願いするわけです。

     

    WebSub(PubSubHubbub)

    Websub(ちょっと前まではPubSubHubbubという名前でした。長いし覚えにくいしどう考えても浸透しそうにないんで変わったんですかね…)とは、Googlebotくんやフィードリーダーに対し自動的にプッシュ通知を行う機能です。

    上記Fetch as Googleと同じ機能ではあるんですが、記事を作るたびに毎回Fetch as Googleやるんめんどいわーという方は(普通めんどいと思います)この機能を使いましょう。

     

    WordPressを使っている場合、WebSub/PubSubHubbubというプラグインをインストールし、有効化するだけでこの機能を使えます。



    おわり

    これで、クロール対策はばっちりですね。ここまでの作業をしておくことで、記事が更新されてから、Googlebotくんがクロールしてくれるまでの時間がぐっと縮まります。

    えっ、もうインデックスされてる!ってなりますので、ぜひやっておきましょう。

     

    なお、新規にサイトを立ち上げる場合はどこからもリンクされていない状態なので、Googlebotくんがサイトを見つけるのに非常に時間がかかります

    よって、新規サイト立ち上げの際は、Search Console登録からFetch as Googleまでの流れは必須となりますので、覚えておいてください。

     

    ちなみに、本記事に書かれている内容の一部(Websub)は、以下に紹介する本で勉強しました。その他のことは前から知っていたんですが、この本にももちろん書かれています。

    さらに、最近の主流であるコンテンツSEOについても「SEOってそんな大変なの!?」と思うくらいぎっしり細かく書かれていますので、SEOについてガチで勉強したい人はぜひ読んでみてください。

     

    ではでは、良いクロールライフを!

  • 完全受託からの脱却~ストック型ビジネスを進めるために必要な方向転換

    完全受託からの脱却~ストック型ビジネスを進めるために必要な方向転換

    このブログではしょっちゅう言ってますが、とにかく受託だけのフリーランスから脱却したいと思っています。

    受託で生きているフリーランスが悪いと言ってるわけではないです。高度なスキルを持ち、案件を請け負うことで事業を成立させることはもちろん可能ですし、むしろずっとそれができるフリーランスさんを尊敬しています。職人ですよね。

    ただ、僕は基本的に「働きたくない」という信念を常に持ち続け生きてますので、「受託=働いたぶんだけお金がもらえる」というスタイルだけでは自分がフリーランスになった意味がないと思っています。

    また、僕のスキルはWeb制作+WordPressに特化していますので、いつか急にこの分野の需要がなくなったらと考えるとちょっと怖いです。100%ないとは言い切れませんよ?

    とはいえ、現に今の収入はほとんどが広告代理店、もしくは制作会社からの下請けとなっていますので、今後受託以外で収入を得ようとするのであればいろいろ準備も必要ですし、考え方を変える必要があります。

     

    Web系在宅フリーランスが受託から脱却し、下請け以外で生きていくには、下の記事で書いたように「ブログでの広告収入」や「Webサービス」等、不労所得で勝負することになります

    https://meshikui.com/2018/08/10/612/

    ブログも、「ユーザーに有益な情報を届け、その対価として収入を得る」と考えるなら、それも立派なWebサービスといえます。

     

    本記事では、受託制作のフロー型ビジネスから個人開発等のストック型ビジネスへとチェンジするにあたって必要な考え方、これからどう動くかをまとめたいと思います。

    なお、本記事は大きく分けて以下の3つの構成となっています。

    1. 受託からストック型への転換ルート
    2. 時間管理とモチベーション
    3. 学習する内容の違い




    完全受託からストック型への転換ルート


    完全受託スタイルからストック型収益へと転換するためには、以下の2通りのルートがあると考えます。

    1. 受託で資金を貯める、もしくは資金調達をし、一気に受託→ストック型へ切り替える
    2. 受託もしつつ収入源を確保した状態で、更にストック型も同時に進める

    どちらも一長一短あると思いますが、僕の場合は②を選ぶことにしました。その理由は、

    • 資金がない
    • 貯金が苦手
    • 収入がないと精神的にくる

    という、まぁ要するに「今、しばらく収入がなくても困らないほどのお金がない」というのが大きな理由なんですが、Webサービスを開発・リリースしてもそれが全然収入に繋がらなかった場合のリスクも考えると、「2.受託もしつつ収入源を確保した状態で、更にストック型も同時に進める」という選択のほうが王道で安全だと思います。



    タイムマネジメントとモチベーション


    「2.受託もしつつ収入源を確保した状態で、更にストック型も同時に進める」のルートを選んだ場合、タイムマネジメント(時間管理)とモチベーションが鍵を握ることになります。

    「1.受託で資金を貯める、もしくは資金調達をし、一気に受託→ストック型へ切り替える」は、受託をばっさり辞めてますので仕事時間の100%をストック型へ回せますし、やるしかない、やらないとお金がなくなるという状態なので、モチベーションも維持できます。モチベーションを維持する秘訣は、強制的に実行せざるを得ない状態に身を置くのが最も効果が高いと言われています。

    ②の場合はまずフロー型の収入源は確保されてますので、「まぁ生きていけてるし焦らなくていっかー」となりがちです。そして焦らなくていっかーが重なって積もってくると、いつまで経っても進みません。これはもう確実に進みません

     

    この状態になることを確保するために、例えば「1日のうち2時間以上は必ず受託以外のことについて考える」と決めてやることが重要です。

    この「受託以外のことを考える時間」を、「自己投資の時間」と考えることにします。

    そしてその成約を守るためには

    • 成約を忘れないようにする
    • 必ず守れるよう時間を確保する
    • 「今日はいいや、明日からがんばろう」とならないよう燃え続ける

    上記3つが大事です。順に対策を考えてみましょう。

     

    制約をわすれないようにする

    これは根本的に大事なことで、よく経営やWeb制作について役立つ情報を得たときにいろんな方法を駆使して保存するわけですが、だいたいこうなります。

    • Evernoteにメモる → 見ない
    • フォルダ分けしてブックマークする → 見ない
    • PCのデスクトップ付箋を使う → 見ない
    • 「お役立ち」フォルダを作ってtxtにしてまとめる → 見ない

    基本、見なくなります。

    書いたことすら覚えてないので、ふと気まぐれにEvernote開いたとき「こんなこと考えとったんか…今全然ちゃうけど」ってよくなります。

     

    僕は長年これに悩んでましたが、これを回避するのに画期的な方法がついに見つかりました。以下2つです。

    Twitterのプロフィールに固定する

    僕は基本的にツイ廃なので、1日のうちかなりの時間をTwitterに費やしています。

    Twitter閲覧してるときはたびたび自分のプロフィールを見るわけですが、大事なことをプロフィールに固定すると何回も目に入ります。

    ただしこの方法には、

    1. 基本的に1つしか置けない
    2. 人に見られて恥ずかしいことは書けない

    というデメリットがあります。本当に大事で、人に見られてもいいことだけにしておきましょう。例えば「付箋を必ず見る」と書いておいて、付箋に全てを書いておくようにするのもありだと思います。

    ブログに書く

    これは今やってることがそうなのですが、ブログに書くことで「人にもわかりやすいように書こう」とするので、必然的に自分にもわかりやすく、かつ言葉を選びながらまとめながらアウトプットするので頭に残りやすいです。

    自分で書いたブログは基本的にかわいいので、割としょっちゅう見ます。そして見るたびに「ここは別の考え方もあるな…」とか、「これは更に深く掘り下げられるな…」と、どんどん拡張されていきます

    そうなると記事も増えアクセスも増え、もしかすると収益につながるかもしれませんので、Webサービスを考えるという点でいえばいいこと尽くしですよね。

     

    Twitterの固定プロフィールとブログによるアウトプットはかなり効果ありです。みなさんもやってみてください。ツイ廃じゃない人には向いてないかもしれません。

     

    必ず守れるよう時間を確保する

    「1日2時間以上は必ず自己投資の時間にする」という制約を守るためには、当然ですがその2時間を確保する必要があります。

    そしてそれは、午前中がいいと考えます。なぜかといいますと、

    • 午前中が一番頭が働く。
    • 仕事が終わってからやろうと思うと、仕事が終わらないことがある。
    • 仕事が早く終われば、夜も時間を確保できる

    といった理由があるからです。

    無理やり時間を作るのなら、早めにまとめてとるほうが集中できていいです。

     

    受託のスケジュールも、「朝はWebサービスのことを考える」ということを念頭に置いて組むといいですね。ただ、緊急性の高いこと(納期とか、重大な不具合)はさすがに優先しましょう。そうならないように仕事できるのがベストですが。

    一般的には、早朝~午前中にメインの仕事を集中し、午後からゆっくりと自己投資の時間に取り組むほうが効率がいいとされているようです。ただ、僕は朝早く起きるということがこの世のストレスの原因ベスト3みたいな人間だし、午前中に慌ただしく仕事をしたくないという理由で、この方法はとらないことにしました。

     

    「今日はいいや、明日からがんばろう」とならないよう燃え続ける

    人間とは怠惰な生き物であり、基本的に危機的状況に陥らないことに対しては後回しにしがちです。特に、スケジュール余裕で組んでるのに、納期直前になぜかデスマーチになるタイプの方は要注意です。

    自己投資の時間は、別に今日考えなかったからといって生活に困ることもないし、最悪一生やらなくても別になんともないので、今日進まなかったら明日以降も進まない可能性が高いです。

     

    これを回避するには、自分に鞭打ちモチベーションを保つしかないわけですが、そんな甘々な人間が自分に鞭を打つでしょうか。打ちません。

    というわけでここは逆の発想でいきましょう。

    「働かなくてもお金がしこたま入ってきて、高層マンションに住み、毎日のようにおいしいものを食べ、旅行に行きたいときはいつでも時間と資金が有り余っている」状態を妄想するのです。それしかなくないですか?

    他にモチベーション保つ方法あったら教えてください…。



    学習する内容の違い


    今まで受託だけで生きてきたわけですが、当然そこには長い年月をかけた学習と努力の積み重ねがあります。

    そして、これからストック型ビジネスで食べていくとなると、今ままで学んできたこととは別方面のことを学ぶ必要があります。

    もちろん受託だけで生きていくにしろ、ずっと学習と努力を続けることは重要なので、学習にかける時間は変わりません。

    ただ、受託制作で必要な知識と、ストック型ビジネスに必要な知識は全然違いますので、今後どのような知識が必要かを考えたいと思います。

     

    今まで蓄えてきた知識、経験

    僕はフリーランスになるぞ!と決意してからコーダーとして制作会社へ入社、経験を積んでフリーランスWebエンジニアとして独立したわけですが、その間多くのことを学んでいます。だいたい以下の順で勉強しました。

    1. Webデザインの基礎
    2. HTML+CSS
    3. jQuery
    4. WordPress
    5. PHP+MySQL
    6. EC-CUBE、その他CMS
    7. gulp、Sass
    8. git

    だいたい1~3ができればWeb制作会社へ入社できる可能性が高いと思います。その後は入社してから学びました。

     

    今後も受託フリーランスとして生きるのであれば、「1つの分野に特化する」か、「様々な分野で仕事ができるよう幅を広げる」かの選択になると思いますが、フリーランスになって間もないうちは特化型のほうが信用があり、仕事の質も高く保てるため安定します。

    幅を広げるのは1つの分野でエキスパートレベルになってからのほうがいいでしょう。全部中途半端だと仕事がなくなります。

     

    この話はちょっと本題から脱線して濃い話になりそうなので、詳しい内容はまた別の記事でまとめたいと思います。

     

    ストック型ビジネスにあたって、これから学ぶべきこと

    完全受託からストック型ビジネスへ転換しようと思うと、Webサービス開発やマーケティングのための学習を新たにすることになります。そしてその代わり、先ほど述べた「様々な分野で仕事ができるよう幅を広げる」という選択を捨てることになります。はっきり言ってそんな時間はありません。

    Webサービス開発をしよう!となったら、開発すると決めたサービスに必要な技術、プログラミング言語を突き詰めることになりますので、必然的に「1つの分野に特化する」ルートをたどることになります。そしてそれは、開発をしながら必要な技術を調べて身につけることになるでしょう。

     

    また、技術的なことだけでなく、マーケティングについても学ぶ必要があります。

    まとめると、僕が考えるこれから学ぶべきことは以下のようになります。ちなみに、既にそれぞれの知識に必要な本もチョイスしてありますので、さっそく学んでいく次第です。

    僕が本を選ぶ基準は、「有名な人、尊敬している人が紹介していた」「レビュー数がそこそこあり、点数も高い」「なるべく新しい書籍(古くても1年前)」といったあたりで選定しています。決して値段が安いからとかじゃ…ないですよ!

    • Webマーケティング
    • SEO
    • 開発に必要な言語
    • 事業開発の知識(リーンスタートアップ)

    自分にとって最高に良いサービスができたと思っても、ユーザーに需要があるとは限りません。そのために、事業開発・顧客開発を学びます。リーン・スタートアップと呼ばれる手法が有名なようなので、そこから入ろうと思います。

    また、検索からの流入を狙うためにも間違いなくSEOは必要です。SEOなんかわかる人がやっときゃええねんというプログラマー思考はここから先は通用しません

    検索からの流入だけでなく、Webマーケティングも重要になってきます。今のとこ知識がないので、SNSとリスティング広告やるんちゃうくらいしか思いつかないです。きっともっといろいろあるはず。勉強します。

    Webサービスであれば、PHPでなくてもJavaScriptやRuby、Pythonといった選択肢もありますし、アプリを開発するならJavaやSwiftを使いますよね。ただ、全部を基礎から学んでいるといったいどれだけ時間がかかるかわからないので、これらは開発したいものに合わせ、必要に応じて学んでいくというスタイルでいいと思います。また、個人で開発するという地点においては、完璧に綺麗なコードは必要ありません。とりあえずはちゃんと動いて、自分が管理できればオッケーです。

    WordPressもせっかくここまで学んできたので、できれば使いたいですね。プラグインを組み合わせたり、既存のプラグインの改造でけっこうサービス開発の時間短縮になると思います。WordPressをフレームワークとする考え方、僕は全然ありだと思っています。

     

    おわり


    以上、僕が今の受注オンリースタイルからストック型スタイルへと方向転換するにあたり、必要となる準備、マインド、今後の指針についてまとめました。

    指針が決まったら、次は具体的にどう進んでいけばいいかを考えたいと思います。

    同じく受託脱却がしたいと思っている方のお役に少しでも立てれば光栄です。

  • wp_head();とwp_footer();とはいったい何なのか

    wp_head();とwp_footer();とはいったい何なのか

    WordPressテーマ開発をやり始めたころ、「header.phpにはwp_head();を、footer.phpにはwp_footer();を必ず書いてください」と言われ、意味もよくわからず「とりあえずこれ書いとかんと動かんのやな」くらいのイメージでいましたが、書かなければ動かないということは当然これらは重要な役割を持っているからなのです。

     

    よく「なんで動かんのやろ…」と原因不明の不具合に悩まされているとき、wp_head();かwp_footer();のどっちかがないということがたまにありますが、この方々はとんでもなく重要な役割を持っていることを知れば、書き忘れることも少なくなるでしょう。

    むしろ愛着すら持つようになるかもしれません。

     

    というわけで、今回はwp_head();とwp_footer();がいったい何なのかを徹底解説したいと思います。




    wp_head();とは

    WordPress Codexでは、wp_head();について以下のように説明されています。

    ‘wp_head’ アクションをスタートさせる。テーマテンプレートファイル内の</head>タグ直前で使う(例: header.php や index.php の中)。

    全然意味がわかりません。とりあえず</head>の直前に入れたほうがいいということだけは伝わります。

    これでは結局なんやねんってなってしまうので、実際にテンプレートにwp_head();を入れて、サイト上でどのようになっているのか確認してみましょう。

    <!DOCTYPE html>
    <html lang="ja">
    <head>
    <meta charset="utf-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <title><?php wp_title( '|', true, 'right' ); bloginfo('name');?></title>
    <link rel="stylesheet" href="<?php bloginfo( 'stylesheet_url' ); ?>" type="text/css" />
    <?php wp_head(); ?>
    </head>

    ↓ブラウザ上で見てみると…

    <!DOCTYPE html>
    <html lang="ja">
    <head>
    <meta charset="utf-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <title>テスト</title>
    <link rel="stylesheet" href="http://localhost/nomou/htdocs/wp-content/themes/sample/style.css" type="text/css" />
    <meta name='robots' content='noindex,follow' />
    <link rel='dns-prefetch' href='//s.w.org' />
    		<script type="text/javascript">
    			window._wpemojiSettings = {"baseUrl":"https:\/\/s.w.org\/images\/core\/emoji\/2.4\/72x72\/","ext":".png","svgUrl":"https:\/\/s.w.org\/images\/core\/emoji\/2.4\/svg\/","svgExt":".svg","source":{"concatemoji":"http:\/\/localhost\/nomou\/htdocs\/wp-includes\/js\/wp-emoji-release.min.js?ver=4.9.6"}};
    			!function(a,b,c){function d(a,b){var c=String.fromCharCode;l.clearRect(0,0,k.width,k.height),l.fillText(c.apply(this,a),0,0);var d=k.toDataURL();l.clearRect(0,0,k.width,k.height),l.fillText(c.apply(this,b),0,0);var e=k.toDataURL();return d===e}function e(a){var b;if(!l||!l.fillText)return!1;switch(l.textBaseline="top",l.font="600 32px Arial",a){case"flag":return!(b=d([55356,56826,55356,56819],[55356,56826,8203,55356,56819]))&&(b=d([55356,57332,56128,56423,56128,56418,56128,56421,56128,56430,56128,56423,56128,56447],[55356,57332,8203,56128,56423,8203,56128,56418,8203,56128,56421,8203,56128,56430,8203,56128,56423,8203,56128,56447]),!b);case"emoji":return b=d([55357,56692,8205,9792,65039],[55357,56692,8203,9792,65039]),!b}return!1}function f(a){var c=b.createElement("script");c.src=a,c.defer=c.type="text/javascript",b.getElementsByTagName("head")[0].appendChild(c)}var g,h,i,j,k=b.createElement("canvas"),l=k.getContext&&k.getContext("2d");for(j=Array("flag","emoji"),c.supports={everything:!0,everythingExceptFlag:!0},i=0;i<j.length;i++)c.supports[j[i]]=e(j[i]),c.supports.everything=c.supports.everything&&c.supports[j[i]],"flag"!==j[i]&&(c.supports.everythingExceptFlag=c.supports.everythingExceptFlag&&c.supports[j[i]]);c.supports.everythingExceptFlag=c.supports.everythingExceptFlag&&!c.supports.flag,c.DOMReady=!1,c.readyCallback=function(){c.DOMReady=!0},c.supports.everything||(h=function(){c.readyCallback()},b.addEventListener?(b.addEventListener("DOMContentLoaded",h,!1),a.addEventListener("load",h,!1)):(a.attachEvent("onload",h),b.attachEvent("onreadystatechange",function(){"complete"===b.readyState&&c.readyCallback()})),g=c.source||{},g.concatemoji?f(g.concatemoji):g.wpemoji&&g.twemoji&&(f(g.twemoji),f(g.wpemoji)))}(window,document,window._wpemojiSettings);
    		</script>
    		<style type="text/css">
    img.wp-smiley,
    img.emoji {
    	display: inline !important;
    	border: none !important;
    	box-shadow: none !important;
    	height: 1em !important;
    	width: 1em !important;
    	margin: 0 .07em !important;
    	vertical-align: -0.1em !important;
    	background: none !important;
    	padding: 0 !important;
    }
    </style>
    <link rel='stylesheet' id='dashicons-css'  href='http://localhost/nomou/htdocs/wp-includes/css/dashicons.min.css?ver=4.9.6' type='text/css' media='all' />
    <link rel='stylesheet' id='admin-bar-css'  href='http://localhost/nomou/htdocs/wp-includes/css/admin-bar.min.css?ver=4.9.6' type='text/css' media='all' />
    <link rel='https://api.w.org/' href='http://localhost/nomou/htdocs/wp-json/' />
    <link rel="EditURI" type="application/rsd+xml" title="RSD" href="http://localhost/nomou/htdocs/xmlrpc.php?rsd" />
    <link rel="wlwmanifest" type="application/wlwmanifest+xml" href="http://localhost/nomou/htdocs/wp-includes/wlwmanifest.xml" /> 
    <meta name="generator" content="WordPress 4.9.6" />
    <link rel="canonical" href="http://localhost/nomou/htdocs/" />
    <link rel='shortlink' href='http://localhost/nomou/htdocs/' />
    <link rel="alternate" type="application/json+oembed" href="http://localhost/nomou/htdocs/wp-json/oembed/1.0/embed?url=http%3A%2F%2Flocalhost%2Fnomou%2Fhtdocs%2F" />
    <link rel="alternate" type="text/xml+oembed" href="http://localhost/nomou/htdocs/wp-json/oembed/1.0/embed?url=http%3A%2F%2Flocalhost%2Fnomou%2Fhtdocs%2F&#038;format=xml" />
    <style type="text/css" media="print">#wpadminbar { display:none; }</style>
    <style type="text/css" media="screen">
    	html { margin-top: 32px !important; }
    	* html body { margin-top: 32px !important; }
    	@media screen and ( max-width: 782px ) {
    		html { margin-top: 46px !important; }
    		* html body { margin-top: 46px !important; }
    	}
    </style>
    </head>
    

    うわーっ!なんかいっぱい増えてる!

    <meta name=’robots’ content=’noindex,follow’ />

    以降は全部wp_head();によって出力されているんですね。

     

    そう、wp_head();とは、WordPressさんサイドで用意してくれるhtmlをhead内に出力してくれる関数なんです。

    例えばそこには、All in one SEO Pack等のプラグインで設定したmeta情報や、プラグイン固有のスタイルシート、javascriptファイルなんかも出力されることになります。

     

    逆に言えばwp_head();がないと、head内に必要な情報が出力されないということです。

    wp_footer();とは

    これも例によりCodexを見てみましょう。もしかするとわかりやすい説明が…

    ‘wp_footer’ アクションフックをスタートさせる。テーマテンプレートファイル内の </body> タグ直前で使う(例: footer.php や index.php の中)。

    うん、そうだと思った。

     

    wp_footer();も、働きとしてはwp_head();と同じです。</body>直前に、ページの最後に読み込まれるべきスクリプトなんかが出力されるわけですね。見てみましょう

    <?php wp_footer(); ?>
    </body>
    </html>

    ↓ブラウザ上で見ると…

    <script type='text/javascript' src='http://localhost/nomou/htdocs/wp-includes/js/admin-bar.min.js?ver=4.9.6'></script>
    <script type='text/javascript' src='http://localhost/nomou/htdocs/wp-includes/js/wp-embed.min.js?ver=4.9.6'></script>
    	<!--[if lte IE 8]>
    		<script type="text/javascript">
    			document.body.className = document.body.className.replace( /(^|\s)(no-)?customize-support(?=\s|$)/, '' ) + ' no-customize-support';
    		</script>
    	<![endif]-->
    	<!--[if gte IE 9]><!-->
    		<script type="text/javascript">
    			(function() {
    				var request, b = document.body, c = 'className', cs = 'customize-support', rcs = new RegExp('(^|\\s+)(no-)?'+cs+'(\\s+|$)');
    
    						request = true;
    		
    				b[c] = b[c].replace( rcs, ' ' );
    				// The customizer requires postMessage and CORS (if the site is cross domain)
    				b[c] += ( window.postMessage && request ? ' ' : ' no-' ) + cs;
    			}());
    		</script>
    	<!--<![endif]-->
    			<div id="wpadminbar" class="nojq nojs">
    							<a class="screen-reader-shortcut" href="#wp-toolbar" tabindex="1">ツールバーへスキップ</a>
    						<div class="quicklinks" id="wp-toolbar" role="navigation" aria-label="ツールバー" tabindex="0">
    				<ul id="wp-admin-bar-root-default" class="ab-top-menu">
    		<li id="wp-admin-bar-wp-logo" class="menupop"><a class="ab-item" aria-haspopup="true" href="http://localhost/nomou/htdocs/wp-admin/about.php"><span class="ab-icon"></span><span class="screen-reader-text">WordPress について</span></a><div class="ab-sub-wrapper"><ul id="wp-admin-bar-wp-logo-default" class="ab-submenu">
    		<li id="wp-admin-bar-about"><a class="ab-item" href="http://localhost/nomou/htdocs/wp-admin/about.php">WordPress について</a>		</li></ul><ul id="wp-admin-bar-wp-logo-external" class="ab-sub-secondary ab-submenu">
    		<li id="wp-admin-bar-wporg"><a class="ab-item" href="https://ja.wordpress.org/">WordPress.org</a>		</li>
    		<li id="wp-admin-bar-documentation"><a class="ab-item" href="http://wpdocs.osdn.jp/">ドキュメンテーション</a>		</li>
    		<li id="wp-admin-bar-support-forums"><a class="ab-item" href="https://ja.wordpress.org/support/">サポートフォーラム</a>		</li>
    		<li id="wp-admin-bar-feedback"><a class="ab-item" href="https://ja.wordpress.org/support/forum/feedback/">フィードバック</a>		</li></ul></div>		</li>
    		<li id="wp-admin-bar-site-name" class="menupop"><a class="ab-item" aria-haspopup="true" href="http://localhost/nomou/htdocs/wp-admin/">テスト</a><div class="ab-sub-wrapper"><ul id="wp-admin-bar-site-name-default" class="ab-submenu">
    		<li id="wp-admin-bar-dashboard"><a class="ab-item" href="http://localhost/nomou/htdocs/wp-admin/">ダッシュボード</a>		</li></ul><ul id="wp-admin-bar-appearance" class="ab-submenu">
    		<li id="wp-admin-bar-themes"><a class="ab-item" href="http://localhost/nomou/htdocs/wp-admin/themes.php">テーマ</a>		</li></ul></div>		</li>
    		<li id="wp-admin-bar-customize" class="hide-if-no-customize"><a class="ab-item" href="http://localhost/nomou/htdocs/wp-admin/customize.php?url=http%3A%2F%2Flocalhost%2Fnomou%2Fhtdocs%2F">カスタマイズ</a>		</li>
    		<li id="wp-admin-bar-updates"><a class="ab-item" href="http://localhost/nomou/htdocs/wp-admin/update-core.php" title="2件のプラグイン更新, 翻訳の更新"><span class="ab-icon"></span><span class="ab-label">3</span><span class="screen-reader-text">2件のプラグイン更新, 翻訳の更新</span></a>		</li>
    		<li id="wp-admin-bar-comments"><a class="ab-item" href="http://localhost/nomou/htdocs/wp-admin/edit-comments.php"><span class="ab-icon"></span><span class="ab-label awaiting-mod pending-count count-0" aria-hidden="true">0</span><span class="screen-reader-text">0件のコメントが承認待ちです。</span></a>		</li>
    		<li id="wp-admin-bar-new-content" class="menupop"><a class="ab-item" aria-haspopup="true" href="http://localhost/nomou/htdocs/wp-admin/post-new.php"><span class="ab-icon"></span><span class="ab-label">新規</span></a><div class="ab-sub-wrapper"><ul id="wp-admin-bar-new-content-default" class="ab-submenu">
    		<li id="wp-admin-bar-new-post"><a class="ab-item" href="http://localhost/nomou/htdocs/wp-admin/post-new.php">投稿</a>		</li>
    		<li id="wp-admin-bar-new-media"><a class="ab-item" href="http://localhost/nomou/htdocs/wp-admin/media-new.php">メディア</a>		</li>
    		<li id="wp-admin-bar-new-page"><a class="ab-item" href="http://localhost/nomou/htdocs/wp-admin/post-new.php?post_type=page">固定ページ</a>		</li>
    		<li id="wp-admin-bar-new-shop"><a class="ab-item" href="http://localhost/nomou/htdocs/wp-admin/post-new.php?post_type=shop">店舗情報</a>		</li>
    		<li id="wp-admin-bar-new-user"><a class="ab-item" href="http://localhost/nomou/htdocs/wp-admin/user-new.php">ユーザー</a>		</li></ul></div>		</li>
    		<li id="wp-admin-bar-edit"><a class="ab-item" href="http://localhost/nomou/htdocs/wp-admin/post.php?post=11&#038;action=edit">固定ページを編集</a>		</li></ul><ul id="wp-admin-bar-top-secondary" class="ab-top-secondary ab-top-menu">
    		<li id="wp-admin-bar-search" class="admin-bar-search"><div class="ab-item ab-empty-item" tabindex="-1"><form action="http://localhost/nomou/htdocs/" method="get" id="adminbarsearch"><input class="adminbar-input" name="s" id="adminbar-search" type="text" value="" maxlength="150" /><label for="adminbar-search" class="screen-reader-text">検索</label><input type="submit" class="adminbar-button" value="検索"/></form></div>		</li>
    		<li id="wp-admin-bar-my-account" class="menupop with-avatar"><a class="ab-item" aria-haspopup="true" href="http://localhost/nomou/htdocs/wp-admin/profile.php">こんにちは、<span class="display-name">root</span> さん<img alt='' src='http://1.gravatar.com/avatar/d01ced56814ff772907fb3f10654240e?s=26&#038;d=mm&#038;r=g' srcset='http://1.gravatar.com/avatar/d01ced56814ff772907fb3f10654240e?s=52&#038;d=mm&#038;r=g 2x' class='avatar avatar-26 photo' height='26' width='26' /></a><div class="ab-sub-wrapper"><ul id="wp-admin-bar-user-actions" class="ab-submenu">
    		<li id="wp-admin-bar-user-info"><a class="ab-item" tabindex="-1" href="http://localhost/nomou/htdocs/wp-admin/profile.php"><img alt='' src='http://1.gravatar.com/avatar/d01ced56814ff772907fb3f10654240e?s=64&#038;d=mm&#038;r=g' srcset='http://1.gravatar.com/avatar/d01ced56814ff772907fb3f10654240e?s=128&#038;d=mm&#038;r=g 2x' class='avatar avatar-64 photo' height='64' width='64' /><span class='display-name'>root</span></a>		</li>
    		<li id="wp-admin-bar-edit-profile"><a class="ab-item" href="http://localhost/nomou/htdocs/wp-admin/profile.php">プロフィールを編集</a>		</li>
    		<li id="wp-admin-bar-logout"><a class="ab-item" href="http://localhost/nomou/htdocs/wp-login.php?action=logout&#038;_wpnonce=775107e931">ログアウト</a>		</li></ul></div>		</li></ul>			</div>
    						<a class="screen-reader-shortcut" href="http://localhost/nomou/htdocs/wp-login.php?action=logout&#038;_wpnonce=775107e931">ログアウト</a>
    					</div>
    
    		</body>
    </html>
    

    これまたすごい量のコードが出力されています。

    ここにはページの最後に読み込むスクリプトに加え、ログインしているときにサイト上部に表示される管理バーのコードも出力されます

    なので、wp_footer();がないと一部のスクリプトが読み込まれずエラーになったり。管理バーが表示されません。

     

    おわり

    wp_head();とwp_footer();の重要さがご理解いただけたかと思います。この方々がいないと、ページはまともに機能しません。

    以後、書き忘れのないよう注意しましょう。

    本記事の基礎的なことを含め、マッハでWordPressについてプロ並みのスキルを身につけたいなら、TechAcademyのWordPressコース等、プログラミングスクールで学ぶのが手っ取り早いです。

    最短4週間でオリジナルテーマを作れるようになりますので、ホームページを作りたいけど外注に出すと高いから自社で作りたい方や、WordPress構築の仕事を請けたい方はぜひ検討してみてください。

    WordPressでWebサイトを構築するのに便利なプラグインを以下の記事で紹介しているので、ついでにどうぞ。

    WordPress構築で使える、カスタマイズに便利なプラグイン11個

    それじゃ、バイバイ~

     

  • スマホのときだけ電話番号をリンクにしたいときのCSS小技

    スマホのときだけ電話番号をリンクにしたいときのCSS小技




    電話番号をタップしたら電話できるようになる

    <a href="tel:0000000000">0000000000</a>

    これですが、そのままだとPCでもクリックできちゃう。

     

    実はSkypeとか入れてたら普通に電話できるから別にクリックできてもいいんだけど、あんまりスタンダードではないので、基本はクリックできないほうがいい。

    そんなとき便利なのが、

    pointer-events: none;

    というプロパティ。これはクリックイベントを無効化にするという奇跡のプロパティで、これを知っていると役に立つ場面が多々ある。

     

    というわけで、スマホ以外では電話番号はタップしても何も起こらないようにしてやればいい。

    @media screen and (min-width: 751px){
      .telLink {
        pointer-events: none;
      }
    }
    <a href="tel:0000000000" class="telLink">0000000000</a>

    telLinkというclass名つけるだけでいけるので、再利用性抜群です。

     

    メディアクエリじゃなくてちゃんとデバイスで判別したい!という場合はjQueryを使いましょう

    .is-eventNone {
      pointer-events: none;
    }
    $(function(){
      if(!navigator.userAgent.match(/(iPhone|iPad|iPod|Android)/)){
        $('.telLink').addClass('is-eventNone');
      }
    });

     

  • フリーランスは相場を気にするだけで生きるのが楽になるという話

    フリーランスは相場を気にするだけで生きるのが楽になるという話

    フリーランスになったばかりだと、イマイチ相場がわからずにクライアントに提示された値段でそのまま受注しがちです。

    もしくは、自分がこの相場で大丈夫と思う単価で請け負い続け、割と不自由なく生活もできてるし、別にこのままでもいいのではと思っている方もいると思います。

     

    ですが、想像してみてください。もしも相場が自分の思っている単価の倍くらいだとしたら?もしかすると、同じ仕事量で倍稼げるとしたら?

    または、相場が自分が思っているより安かったらどうでしょう。単価を調整することでクライアントも納得しやすくなり、もっと仕事がとれるようになるかもしれません。

    今回は、そんな大事な相場を手っ取り早く知る方法、そして相場を知ることで得られるメリットについてお話します。




    フリーランスが相場を知る方法

    結論からいうと、相場を手っ取り早く知る方法は以下2点です。

    • 外注に出してみる
    • 同じ領域のフリーランスに聞く

    順に見ていきましょう。

     

    外注に出して見積りを見てみる

    僕が自分の見積もり単価に疑問を持った、というかもっと端的にいうと「あ、俺の見積もりだめじゃんこれ」と思ったのは、案件があふれてしまったので以前勤めていた制作会社に案件を手伝ってもらうため見積もりをお願いしたときのことでした。

    ・・・え?たっか!!!いや無理無理無理!!!

    ってなったんです。

    そう、自分がクライアントに出した見積もりに比べ倍以上の値段だったんですね。クライアントには、制作会社に外注に出すのでたぶんいつもより4割くらい高くなると思います~言うてたんですが、それどころじゃなかったです。

    まぁ制作会社だし仕方ないか、そりゃフリーランスより高くて当然だわと最初思ったんですが、ふとここで試しに他のフリーランスにも別の案件で見積もりを出したところ…

    たっけえええええ!!たけぇ!!!!

    なんとその制作会社より高かったんです。

     

    そして、ここで確信しました。「あ、俺の見積もりだめじゃんこれ」です。

     

    同じ領域のフリーランスに相場を聞く

    迷ったら、先輩に聞く。

    これは人生の基本です。ネットで調べても出てきません。だって、自分のライバル、しかも全然知らん相手に自分が不利になる情報を教えてくれる人なんかなかなかいませんので。

    一回「フリーランス 相場」とかで調べたことがあったんですが、割と適当なことしか書かれていません。それに、果たしてその人がそれで成功してるかどうかもわからないですしね。

     

    というわけで、恥を忍んで先輩フリーランスに聞いてみました。聞く相手はなるべくベテランで、信用のおける人のほうがいいですよ。

    「僕の相場、安すぎますかね…」
    「安すぎますね」

    即答でした。そして、自分の知ってる範囲でよければと、相場と単価のつけかたについてアドバイスをいただきました。ありがとうございます・・・



    フリーランスが相場を知ることで得られるメリット

    正しい相場を知ることで得られるメリットは、収束すると以下3点になります。

    • お金を稼げる
    • 外注に出しやすくなる
    • 人生に余裕が増える

     

    お金を稼げる

    これは単価が増えるので、当然です。

    もし自分の思っていた相場より実際の相場が安い場合でも、実際の相場に近づけることによって仕事が増える可能性が高まります。

    相場より安いと仕事は増えますが、相場より高いと仕事は減ります。だってフリーランスですよ?そんなどこの馬の骨かもわからん個人にわざわざ相場より高い金払うんだったら制作会社に頼むわってなりますよね、普通は。

    質を求めるなら会社のほうが圧倒的に有利なんです。人が多いからチェックも徹底してますし、サポートも手厚いですからね。

     

    じゃあ、今の自分の相場が実際の相場より安い場合、相場に近づけることで仕事の受注率が減るのでは?と思うかもしれません。

    これは実際その通りで、受注率自体は減ると思います。

    ところがその変わりに、質の良いクライアントと出会え、質の良い仕事ができるようになります。安くて質の悪い仕事を2つ請けるのと、相場に近い価格で質の良い仕事を1つ請けるのはどちらがいいか、明白ですよね。

    実際、ベテランともなるとめっちゃ単価高くしても仕事が入るときは入るので、そうなると勝ちですよね。超高単価の仕事をちょっとだけやって生きていくなんて夢のような話です。

     

    外注に出しやすくなる

    これも大事なことで、あまりにも自分の提示金額が安いと、請けてくれるのはよほど優しい人か、駆け出しのフリーランスさんばかりになってしまいます。

    別にそれでもいいならいいんですが、実際のところ、安い案件に安く応募してくるフリーランスさんは、ほとんどちゃんと仕事しません。納期が遅れるリスクが非常に高いです。

     

    ちゃんとしたフリーランスさんに気持ちよく仕事をしてもらい、良い関係を保つためにも、相場を知っておくことは必須といえます。

    仲間なんかいらねぇ。俺はずっと一人さ…今までも、そしてこれからもな…

    という人はまぁ別にいいと思うんですが、正直しんどいですよ。一人は。病気になったり急にやる気がなくなったりしたときやばいですからね。

     

    仕事以外の時間に余裕が出る

    僕としては、お金を稼げるよりこっちのほうが大事だと思います。

    これも単純な話ですが、同じ量の作業を今までより高い金額で請けることができるようになると、1ヶ月にこなさなければいけない作業量が減るわけです。

    そうなると、休憩時間が増えるだけでなく、受注案件以外にできることが増えます。例えば、ブログ書いたり情報収集したり、仕事仲間と交流してみたり。何かプラグインやサービスを作ってみるのもいいですね。

     

    人生のほとんどが請け負いで埋まってしまうと、もはやそこに選択・成長の余地はありません。ただ来る案件をこなして生きるだけだったら会社員でもできますからね。

    せっかくフリーランスになったんだから、自由に生きたい。自分の人生を自分で選択したい。そのためにも適正相場を知ることは重要だと言えます。

     

    おわり

    相場を知ると、人生が変わります。

    もちろんその相場に合った実力を持っている必要がありますが、自信を持ってください。「僕なんかがこんなみなさんと同じ相場で仕事を請けるなんてとてもとても…」なんていう姿勢だと逆に仕事は来ないと思います。

    基本的に、一人ぼっちで仕事してると相場がわからなくなりがちなので、フリーランス仲間はほしいですよね。もう気軽に「どれくらいで見積もってます?」ってビール飲みながら聞けるくらいになったら人生相当イージーになるんじゃないでしょうか。

    ではでは、適正相場でハッピーな人生を!

    見積もりの作り方については、以下の記事をどうぞ。

    フリーランスの見積もり作成術~金額設定のコツ

  • jQuery チェックしたラジオボタンの値を、テキストフィールドに反映させる方法

    jQuery チェックしたラジオボタンの値を、テキストフィールドに反映させる方法

    ラジオボタンでチェックさせ、その値を別のテキストフィールドに反映させる方法。

    例えば、メールアドレス入力のときに@以降を選択させることができる。




    <input type="email" name="your-email">
    
    <p>※@以降を以下から選択できます。</p>
    <ul class="addressList">
      <li><label><input type="radio" name="addressSelect" value="" checked>選択なし</label></li>
      <li><label><input type="radio" name="addressSelect" value="@docomo.ne.jp">@docomo.ne.jp</label></li>
      <li><label><input type="radio" name="addressSelect" value="@ezweb.ne.jp">@ezweb.ne.jp</label></li>
      <li><label><input type="radio" name="addressSelect" value="@softbank.ne.jp">@softbank.ne.jp</label></li>
      <li><label><input type="radio" name="addressSelect" value="@yahoo.co.jp">@yahoo.co.jp</label></li>
      <li><label><input type="radio" name="addressSelect" value="@gmail.com">@gmail.com</label></li>
    </ul>
    $(function(){
        var addressSelect = $('input[name="addressSelect"]');
        var yourEmail = $('input[name="your-email"]');
    
        addressSelect.change(function(){
            var selectVal = $(this).val();
            var getAddressData = yourEmail.val();
            var posData = getAddressData.indexOf('@');
            
            if(posData < 0) {
                addressData = getAddressData;
            } else {
                addressData = getAddressData.substring(0,posData);
            }
            yourEmail.val(addressData + selectVal);
        });
    });

     

    8行目の

    var posData = getAddressData.indexOf('@');

    で、テキストフィールド内の@以降の文字列を取得。

    if(posData < 0) {
        addressData = getAddressData;
    } else {
        addressData = getAddressData.substring(0,posData);
    }

    もし@以降に文字列があれば、@までの文字列を取得する。
    @以降に文字列がなければ、全ての文字列を取得する。

    これにより、例えば

    hogehoge@gmail.com

    と既に入力していても、@以降のみを変更することが可能。

     

    そんな処理は必要なく、ただ反映させたいだけであれば上記をまるっと削除し、

    $(function(){
        var addressSelect = $('input[name="addressSelect"]');
        var yourEmail = $('input[name="your-email"]');
    
        addressSelect.change(function(){
            var selectVal = $(this).val();
            var getAddressData = yourEmail.val();
    
            yourEmail.val(getAddressData + selectVal);
        });
    });

    これだけでOK。

    ラジオボタンで値を選択すると、テキストフィールドに入力した値は削除され上書きされる。

  • イベントトラッキングが計測されないときに確認すること

    イベントトラッキングが計測されないときに確認すること

    Google Analyticsで、リンクや電話番号をクリックされたことを計測するためのイベントトラッキング。

    基本、以下のように記載していれば今までは計測できていました。ググっても、紹介されているのはだいたいこの形ですよね。

    <a href="http://hoge.com/" onclick="ga('send','event','カテゴリ','アクション','ラベル');">リンク</a>

    ところが、先日いつも通りの設定方法では計測できていないことがあり、調べて解決したのでメモ。




    Analyticsトラッキングコードを確認

    まずはAnalyticsのトラッキングコードが正常に<head>内に書かれているかを確認しましょう。

    一般的には、だいたい下記のようなコードである場合が多いです

    <script type="text/javascript" >
    	window.ga=window.ga||function(){(ga.q=ga.q||[]).push(arguments)};ga.l=+new Date;
    	ga('create', 'UA-XXXXXX-XX', 'auto');
    	
    	ga('send', 'pageview');
    </script>
    <script async src="https://www.google-analytics.com/analytics.js"></script>
    

    トラッキングコードが正常に動いているかを確認したいときは、Analytics管理画面の「リアルタイムレポート」を見れば一瞬でわかります。

    もし理由あってAnalytics管理画面に入れない場合は、Chromeの拡張機能Tag Assistantで確認してみましょう。

     

    ところが、問題のサイトのトラッキングコードはちょっと違ったんです。

    <!-- Global site tag (gtag.js) - Google Analytics -->
    <script async src="https://www.googletagmanager.com/gtag/js?id=UA-XXXXXX-XX"></script>
    <script>
      window.dataLayer = window.dataLayer || [];
      function gtag(){dataLayer.push(arguments);}
      gtag('js', new Date());
    
      gtag('config', 'UA-XXXXXX-XX');
    </script>

    Global site tagと書かれているのが確認できるかと思います。

     

    Global site tag(グローバルサイトタグ)とは?

    これはどういうことかというと、最近またGoogle Analyticsの計測タグが新しくなり、このGlobal site tag(グローバルサイトタグ)というものが使われるようになったんです。

    なので、今までのタグとはちょっと設定方法が変わります。

     

    グローバルサイトタグでのトラッキングコードは以下の通り

    <a href="http://hoge.com/" onclick="gtag('event', 'アクション', {'event_category': 'カテゴリ','event_label': 'ラベル'});">電話番号</a>

    sendを省略する代わりに、若干ややこしくなってますね。

    ただ、グローバルサイトタグのトラッキングコードには、デフォルトのアナリティクスイベントというものが用意されるようになりました。

     

    デフォルトのアナリティクスイベントとは?

    上記で紹介した書き方は、デフォルトではなく、いわゆる自作のイベントトラッキングコードです。

    デフォルトのアナリティクスイベントは、Googleさんサイドでアクション、カテゴリ、ラベルを用意してくれているイベントトラッキングコードのことを指します。

     

    例えば、以下のような形。

    gtag('event', 'login', { method : 'Google' });

     

    このように書くと、アクション「login」、カテゴリ「engagement」、ラベル「Google」の Google アナリティクス イベントが送信されるということです。

    今のところメリットはイマイチわかりませんが、公式ドキュメントによると

    通常は、デフォルトの Google アナリティクス イベントを使用することをおすすめします。デフォルトのイベントには、デフォルトのカテゴリやラベルがあらかじめ設定されています。これらのイベントを使用することで、レポートの一貫性や将来実装される機能との相互運用性を確保しやすくなります。

    とのことなので、おそらく将来追加される何かしらの機能と連動するようになるんじゃないかと予測されます。

     

    デフォルトのアナリティクスには他にも種類がありますので、下記公式ドキュメントを参考にしてみてください。

    Googleアナリティクス



    おわり

    今までできていたのに、急にできなくなった…という事態が発生した場合、まずはコードの記述にミスがないかを確認するのがベストですが、特に自分の書いたコードにミスがなさそうな場合は、サービス元の仕様に何か変更がないかを確認することが重要です。

    いつの間にか仕様が変更になってること、けっこうありますからね…

     

    アクセス解析やSEO関連の情報は、できるだけ新しいものを参考にしてくださいね!

    それでは、良いアクセス解析を!

  • BackWPupのエラーをようやく解決した話

    BackWPupのエラーをようやく解決した話

    WordPressのバックアップ用プラグインBackWPupをよく使っているんですが、クライアントから自動バックアップでエラーが出るとの連絡が。

     

    ログを見てみるとこんな感じ

    エラー:シグナル”SIGXCPU”(CPUの時間制限を超えました)がスクリプトへ送信されます!とのこと。

     

    だいたいはサーバーのスペック不足が原因だと思うのですが、いろいろ試してみて解決したのでメモ。




    ファイルとデータベースのジョブは分ける

    まず、サーバーへの負担を減らすためにも、ファイルとデータベースのバックアップは分け、それぞれ別のタイミングで自動バックアップをとるよう設定。

    これにより、重要なデータベースのバックアップだけでもとりあえず正常に行えるし、そもそもファイルはそんな頻繁にバックアップとらなくていいと思うので(WordPressはあんまりファイルいじらないため。ローカルに手動で保存もできるし。)、データベースは毎日、ファイルは週一でバックアップをとるようにしました。

     

    しかし、これではエラーは解決できませんでした。次いってみましょう。

     

    最大スクリプト実行時間を設定

    ググると最初に出てきたのがこれ。

    最大スクリプト実行時間を60秒にしてみたらなおったよ~という報告がありましたが、僕の場合はだめでした。



    サーバーの負荷を軽減で解決

    最終的にこれで解決しました。

    サーバーの負荷を軽減が、デフォルトでは無効になっているので、最小にしたところ無事自動バックアップが正常に行われていました。

     

    最大スクリプト実行時間はあまり関係ないかもしれませんが、念のため。

     

    よくわからないサーバーを使っていると、よくわからないエラーに悩まされることが多々あります。サーバーはいいサーバーを使おうね!

    おすすめサーバーは以下で紹介していますので、よかったら見てってくださいね。

    https://meshikui.com/2018/12/03/1396/

    ではでは、良いバックアップライフを。

  • 【WordPress】記事内にテンプレートを挿入するプラグイン”TinyMCE Templates”

    【WordPress】記事内にテンプレートを挿入するプラグイン”TinyMCE Templates”

    複数の記事内に同じ内容、例えば広告だったり、他の記事のリストだったりを挿入したいときに便利なプラグイン”TinyMCE Templates“。




    使い方は簡単で、プラグインをインストールすると管理メニューに「テンプレート」という項目が追加されるため、そこからテンプレートを作成するだけ。

    複数のテンプレートを登録でき、記事内に挿入する際にテンプレートを選択できる。

     

    ショートコードとして挿入

    テンプレートを作成する際、更新ボタンの下に「ショートコードとして挿入」という項目があり、デフォルトは「いいえ」になっている。

    これを「はい」にすると、登録した内容をショートコードで挿入することができるようになる。

    ショートコードとして挿入できると、例えば

    「あ、テンプレート修正せんと。でも全記事やるのめんどくせー」

    ってときに、ショートコードで挿入している場合は、テンプレート編集画面でテンプレートを修正するだけで済む。

    ただし、記事側でテンプレートを編集できないというデメリットがある。

     

    逆に、「いいえ」にするとショートコードではなくテンプレートに書いたhtmlコードをそのまま挿入することになる。

    こちらは記事側でhtmlを編集できるが、修正が必要な場合は全記事なおす必要がある。

     

    ショートコードとして挿入を、

    • 「はい」…全記事に同じテンプレートをいれる必要があり、たびたび修正が発生する可能性がある場合(広告を貼りかえる場合等)
    • 「いいえ」…テンプレートの一部を記事ごとに書き換える必要がある場合。(管理者からのコメントや、URL等)

    このように使い分けるといいだろう。

  • PHP初心者にまず読んでほしい一冊の本

    PHP初心者にまず読んでほしい一冊の本

    駆け出しペチパー(PHPer)のみなさま、こんにちは。

    検索でこの記事を発見して読みに来ていただいたということは、おそらくこれからPHPを勉強してプログラミングができるようになりたい、もしくはなんとなくPHPわかるけど、ちゃんと基礎を学ぼうと思う、そういった意思を心に秘めていることだと思います。

     

    それでは、PHP初心者がまず何をすればいいのか。答えは1つです。

     

    この本を読んでください。

    当記事では、この本(タイトルが長いけど「この本」で通すのもなんなので、以降マスターブックと呼びます)を読んでほしい理由を綴っていますので、どうぞお付き合いください。だいたい5分くらいで読めると思います。

    ちなみに、私もマスターブック持ってます。PHPを使う方であれば、大半は持ってるんじゃないかと思うくらいメジャーで素敵な本なので、知っておいて損はないですよ!




    PHPの本を読むという行為のメリット

    マスターブックを読んでほしいという話の前に、そもそもプログラミング初心者はまず本を読むべきだという話をします。

     

    「PHPの情報を検索して調べる」vs「PHPの本を読む」

    だいたい、プログラミング関係の情報はググれば山ほど記事がありますよね。無料で調べられるし、ネットさえつながっていれば現場でもどこでもその場で調べることができます。

    これに関しては、ネット社会のすばらしさを実感します。とても良いです。

    それでは、いったい何が悪いのか。それは、検索するのは自分であり、基本的に自分の知っている範囲でのワードでしか調べることができないという点です。

    作業中にわからない部分があり、検索して解決するという点に関しては圧倒的メリットがありますが、そもそも自分が知らないことを調べるというのはなかなか難しい傾向にあります。

     

    実は恥ずかしいことに私がそういった経験がありまして、PHPを初めて触ったときからずっと検索だけで2年ほどやってきたんですが、それでもマスターブックに書いてある大半が知らないことでした。「これそういう意味だったの!?そんな便利な関数あったの!?最初に知っときたかったーー」のオンパレードです。

    ネット検索だけで数年がかりで蓄えた知識は、一冊の本を買って数日間で得られる知識に敵わないんですね。

     

    また、ネット上の記事はほとんどが個人が書いたブログです。もちろん法人とか、しっかりした手順で書かれた記事もあるのですが、「いやこれ間違っとるけどちゃんと自分で書いたコードか?」「この記事さっき別のサイトで見たのとほぼ同じやししかも解決せんかったやつや!」ってなることが多々あるのが現実です。

    私のサイトのコードは自分で書いたものだし動作確認も行っているので、たぶんコピペで動くとは思うんですが、それでも確実かと言われると自信がありません。。

    一方、本は違います。いろんな方面のプロが何回もチェックしてますので、間違っているということはほぼほぼないです。信用が違いますね。



    マスターブックを読むメリット

    本を読むという行為自体のメリットを伝えた次は、どうしてこの本を勧めるかを書いていきますね。

     

    マスターブックの内容

    マスターブックは全部でChapter13まであり、下記のような構成になっています。

    1. PHPの開発環境
    2. PHPの基礎
    3. PHPの組み込み関数
    4. WebでのPHP
    5. クラスとオブジェクト
    6. データベースの準備
    7. データ操作の基本
    8. PHPからデータベースを操作する
    9. PHPとMariaDB/MySQLで作る会員管理システム-基本機能
    10. PHPとMariaDB/MySQLで作る会員管理システム-管理機能
    11. データベースの運用
    12. PHPの応用
    13. これからプログラミンぐをしていくにあたって

    どうですか?やばみが伝わりますか?

     

    この本一冊で、PHPの基礎~応用はもちろん、開発環境の構築の話やMySQL(MariaDB)の作成・操作方法、更に会員管理システムを実際に作りながら学べ、挙句の果てにChapter13では自分で設計から考えプログラミングをするためのレクチャーをしてくれます。最後に練習問題もあります。

    もう全部ですよね。まさにPHPマスターブックです。



    マスターブックを読んだあとは

    マスターブックを一通り読み終え、会員管理システムも作ってみたあなたは、もうPHPの基礎はマスターしています。本を読み終えたら、文系美女と観光地にデートでもいきましょう。

    美女なんかより、もっともっとPHPを学びたいストイックなあなたに、基礎の次のステップへの指針をさらっと紹介しておきます。

     

    PHP公式サイトに訪れる

    PHP公式サイトには、言語リファレンスというPHPの辞書があります。

    リンク → 言語リファレンス

    基礎を学ぶ前にこのサイトを見てもいったい何を書いてるのかわからない、わからない部分がわからないという事態に陥ると思いますが、基礎を学んだあとはこのサイトの呪文が読めるようになっているはずです。

    わからないことは公式サイトで調べるようにしましょう。

     

    PHPフレームワークを学ぶ

    フレームワークという言葉を聞きなれない方もいらっしゃるかもしれませんが、簡単にいうと土台です。PHPでシステム開発をするために必要な機能や枠組みがあらかじめ用意されているソフトウェアで、大規模なシステム開発や、ECサイト開発によく使われます。

    WordPressも、フレームワークと捉えることが可能です。いろんなタグや関数、リダイレクト機能、データベース管理機能が備わってますからね。

    数あるPHPフレームワークの中でも私がおすすめするのは、今熱いと言われているLaravel、EC-CUBEで使われているSymfonyの2つです。

     

    オブジェクト指向について学ぶ

    マスターブックでも少し触れられてはいますが、オブジェクト指向は難しいです。たぶんすぐには理解できないと思います。

    ただ、私は無理してオブジェクト指向をマスターする必要はないと思っています。上記のフレームワークがオブジェクト指向で組まれているので、構造を理解できて編集できる程度の知識があればいいんじゃないでしょうか。自分で1からオブジェクト指向で組むのは現実的とは思えないです。

    たぶん、オブジェクト指向で組む必要があるのは、フレームワークを作るレベルのエキスパートたちですよね。。

     

    まとめ

    わからないことや疑問に思ったことを調べるにはネットが便利ですが、しっかりと基礎を身に着けたければ本を読むほかありません。

    たった一冊の本を読まなかったばっかりに、数年間苦労した私のようにならないためにも。。

     

  • WordPressの記事から括弧”[]”で囲まれた文字列を取り除いて表示する方法

    WordPressの記事から括弧”[]”で囲まれた文字列を取り除いて表示する方法




    FC2とかからWordPressに記事データを移管した際、”[emoji:v-412]”みたいな文字列がたくさんあって邪魔です。

    そんなときは、functions.phpに以下のように記述。

    function content_replace($content) {
    	$content = preg_replace("/\[emoji.+?\]/", "", $content);
    	return $content;
    }
    add_filter('the_content', 'content_replace');

    ちなみに、”[]”で囲まれている文字列全てを削除したい場合は、2行目を

    $content = preg_replace("/\[.+?\]/", "", $content);

    こう変更。

     

    あとは記事を表示させたい場所にいつも通りthe_content();と書けばOK

     

  • WordPress – 特定のタームの記事だけ処理を変えたいときの条件分岐

    WordPress – 特定のタームの記事だけ処理を変えたいときの条件分岐

    「このタームの記事だけ項目を非表示にできますか?」と言われたとき、すぐにはわからなくてちょっと調べたので、以後すぐ思い出せるようにメモ。




    実装

    has_term( ‘slug’, $taxonomy );を使えば簡単。
    第一引数は対象となるターム、第二引数はそのタームが属するタクソノミーを指定します。

    <?php
    if( has_term('service','cat_blog') ) {
      // ここに「service」というタームに属する場合の処理を書く
    } else {
      // それ以外の場合の処理。
    }
    ?>

     

    ただ項目を非表示にするだけでよかったら、

    <?php
    if( !has_term('service','cat_blog') ) { //"service"に属さない場合
      // 処理を行う
    }
    ?>

    これだけでOK。

     

    複数のタームを指定したい場合はarray()を使う。

    <?php
    if( has_term( array('service','shop') ,'cat_blog') ) {
      // ここに「service」もしくは「shop」というタームに属する場合の処理を書く
    } else {
      // それ以外の場合の処理。
    }
    ?>

     

    タクソノミー関係の分岐ってけっこうややこしいので、「どうやってググったらええかすらわからん!!」ってときは、WordPress Codexを見てみるのが一番早いです。

    以下の記事も参考にどうぞ!

    WordPress開発が捗る!ブックマークしておくべきCodexまとめ

     

    以上、現場からでした。

  • WordPress 条件分岐 “is_archive()” が効かないときに確認すること

    WordPress 条件分岐 “is_archive()” が効かないときに確認すること

    is_archive()とは、アーカイブページであるということを示す条件タグです。




    使うときは以下のように使います

    <?php
    if( is_archive() ) {
    	// 投稿一覧ページでのみ行いたい処理
    } else {
    	// その他で行う処理
    }
    ?>

     

    ところが、設定 > 表示設定 で、一覧ページ用の固定ページを指定している(例:infoとか)場合、一覧ページと判別してくれません

    そんなときはis_home()を使いましょう。

    <?php
    if( is_home() || is_archive() ) {
    	// 投稿一覧ページ及びアーカイブページでのみ行いたい処理
    } else {
    	// その他で行う処理
    }
    ?>

    is_home()だけだと全記事一覧ページしか判別してくれない可能性があるので、is_archive()も加えてやることで、カテゴリーページや年別アーカイブページも判別してくれるようになります。

     

    もしかするとトップページでis_home()を使用している方もいるかもしれませんが、
    トップページはis_front_page()で分岐してやるのが正しいです。

  • aタグの中にdiv入れていいんですか!?消えたブロック要素の概念

    aタグの中にdiv入れていいんですか!?消えたブロック要素の概念

    突然ですが、HTML5ではaタグの中にdivやsection等のブロック要素を入れてもいいということを知っているでしょうか。

    HTML5から入った方は、何言ってんだ素人なのかこのおじさんはと思うところでしょう。しかし、HTML4からコーディングをしている世代にとっては革命的なことなのです。おじさんたちはブロック全体をリンクにしたいときにとても困っていました。HTML5が主流になってもう何年も経つのにこの事実を知らなかったし、今でもaタグの中にブロック要素を入れてはいけないという概念をお持ちの方はなかなかに多いんじゃないでしょうか。

    そもそも、HTML5には「ブロック要素」「インライン要素」という分類すらないということを最近知りました。これはまずい。我々でいうところのテーブルレイアウト世代のような時代遅れレッテルを貼られる前に、初心に帰ってHTML5の勉強をしようと思いました。

    詳しいことはHTML5リファレンス等のサイトを参考にしてもらったほうがいいと思いますが、HTML5はこんなことになっていたのかという事実を軽く何点か紹介します。

    HTML5世代も、もしかすると古いサイトの修正とかでHTML4を触ることもあると思うので、HTML4ではできないことがあるということを知っておくためにも、流し読みしていただくといいかもしれないですね。




    コンテンツ・モデル

    前述したとおり、HTML5には、「ブロック要素」「インライン要素」という分類は廃止されており、その代わりにコンテンツ・モデルと呼ばれるモデルでさらに詳細に分類されるようになった。

    セマンティックなコーディングを心掛けるためには、どのタグがどういった役割なのかを抑えておいたほうがいいでしょう。

    参考:http://www.htmq.com/html5/007.shtml

     

    API

    ドラッグ&ドロップやファイルの操作等が、APIの充実により簡単に実装できる。

    ウェブアプリケーションの開発がよりスムーズに行えるようになっているようです。フロントエンドという言葉が流行り出したのも、このAPIが充実してからじゃないでしょうか。

    参考:http://www.htmq.com/api/

     

    画像のRetina対応・レスポンシブ対応

    pictureタグやimgのsrcset属性により、Retinaやレスポンシブにおける画像の切り替えが簡単に行える。これは便利ですよね。僕もよく使ってます。

    ちなみにpictureは画像自体が変わる場合(アートディレクション)に用いるのがお作法のようですね。

    参考:
    https://reference.hyper-text.org/html5/element/picture/
    https://reference.hyper-text.org/html5/attribute/srcset/

     

    他にも便利な変更点が多くありそう。HTML4とCSSで苦労してきた世代は、ぜひ初心に戻ってHTML5とCSS3の仕様をじっくり読んでみるといいでしょう。

    きっとコーディングが楽になると思いますよ。

  • WordPress – その記事が属するカテゴリーの一覧を表示させる関数

    WordPress – その記事が属するカテゴリーの一覧を表示させる関数

    WordPressの記事を書いて、例えばカテゴリーを複数選択したとき(ニュース、日常)、記事の詳細ページとかに、選択したカテゴリーの一覧がいい感じに表示される関数を紹介する。




    functions.phpに以下のように記述

    function show_category( $delimiter = null ) {
      $cats = get_the_category();
      $tmp = $cats;
    
      if( !$cats ) {
        return false;
      }
      
      foreach( $cats as $cat) {
        // 出力部分
        echo $cat->name;
        if( $delimiter && next($tmp) ) {
          echo $delimiter;
        }
      }
    }

     

    使うときは、テンプレートに以下のように書く

    <?php show_category(','); ?>

    出力はこんな感じでされる

    ニュース,日常

    引数には区切り文字(’,’とか’/’)を指定できる。何も指定しない場合は、区切り文字なしで続けて表示される。

     

    カテゴリーをspanとかaタグで囲みたいときは、foreachの中をちょっといじる。

    function show_category( $delimiter = null ) {
      $cats = get_the_category();
      $tmp = $cats;
    
      if( !$cats ) {
        return false;
      }
      
      foreach( $cats as $cat) {
        $cat_id = $cat->term_id;
        $cat_link = get_category_link( $cat_id );
        
        // 出力部分
        echo '<a href="' .$cat_link. '">' .$cat->name. '</a>';
        if( $delimiter && next($tmp) ) {
          echo $delimiter;
        }
      }
    }

    上記のような関数を作り、引数なしで出力すると、そのカテゴリーページへのリンクがついたaタグで囲まれたカテゴリー一覧が出力される。

     

  • WordPress – タイトルの文字数制限を、関数を作っていい感じにやる

    WordPress – タイトルの文字数制限を、関数を作っていい感じにやる

    WordPressのテーマ制作のとき、レイアウトが崩れるのを防ぐためにタイトルの文字数を制限してやる必要がある、という場合。

    タイトルの文字数制限でググればやり方が書いてあるが、毎回書くのはめんどうだしソースもちょっとぐちゃっとなりがちなので、関数を作って、そして簡単に実装できるようにする。




    functions.phpに以下を記述

    function show_limit_title($limit = 20) {
      global $post;
      $title = $post->post_title;
      
      if( mb_strlen( $title ) > $limit) {
        $title= mb_substr( $title , 0 , $limit ) ;
        $show_title = $title. '・・・' ;
      } else {
        $show_title = $title;
      }
    
      echo $show_title;
    }

     

    あとは、タイトルを表示させたい部分に、”the_title();”の代わりに以下のように書くだけ。

    <p><?php show_limit_title(); ?></p>

    デフォルトでは20文字制限となっているので、文字数を変えたい場合は括弧の中に数値を入れてやる。

    // 40文字まで
    <p><?php show_limit_title(40); ?></p>

    場所やカスタム投稿によって表示文字数を変えたい場合は引数の値を変えるだけでいいので、使いやすいです。

    あなたのfunctions.phpのおともに是非!

    functions.phpのちょっとした小技を書いたこちらの記事もどうぞ🤗

    WordPress functions.phpを関数ごとに分割して管理しやすくする話

  • WordPressテーマ作成時に、いろんなサイズのサムネイルのダミー画像をサクッと生成する方法

    WordPressテーマ作成時に、いろんなサイズのサムネイルのダミー画像をサクッと生成する方法

    WordPressのテーマを制作するとき、サムネイル機能をつけることはよくあると思うが、「サムネイル画像が登録されていない場合に表示させるダミー画像」を作るのが意外とめんどくさい。

    今回は、その作業をなるべくぱぱっと終わらせる小技を紹介しよう。




    準備するもの

    何はともあれ、元となる画像を用意しよう。

    上の画像はAdobe Stockのサンプルなので勝手に使わないように。

    大きさは、1920px x 1920pxのものがいいんじゃないだろうか。できるだけいろんな形に切り取られてもおかしくない画像を用意しよう。

    サムネイルサイズの設定

    サムネイルのサイズを複数登録する必要がある際、functions.phpにいつも書くであろうこういうやつ。

    add_image_size( 'arhive-thumbnail', 438, 289, true );
    add_image_size( 'single-topics-thumbnail', 916, 600, true );
    add_image_size( 'single-shop-thumbnail', 458, 300, true );
    add_image_size( 'top-topics-thumbnail', 373, 250, true );
    add_image_size( 'single-shop-thumbnail', 285,200, true );

    …書くよね?

    いつも通りでOK。

    アップロード

    作った画像を管理画面からアップロードしてしまう。

    するとなんということでしょう

    uploadsフォルダ内に、あらゆるサイズで切り取られたダミー画像が勝手にできあがっているじゃありませんか。

    これなら開発の流れでついでにできちゃうし、汎用的な画像をあらかじめ用意しておけば、どのサイトでも使いまわせる。デザイナー様のお手を煩わせるまでもないのである。

  • Vagrant+VCCWでWP開発環境を構築~終了まで

    Vagrant+VCCWでWP開発環境を構築~終了まで

    長年XAMPPを使っていましたが、最近小難しい案件が増えてきたため、そろそろVagrantを使ってみようと思いました。

    取り急ぎWordPressの開発環境がほしいわけで、VCCWを使って開発環境の構築をしてみたところ、いろいろ嵌ったのでメモ。

    なお、Windowsしかわからないので、Macでの場合とはちょいちょい違うこともあると思います。

    準備からの流れは以下の通り

    1. VirtualBoxのインストール(初回のみ)
    2. Vagrantのインストール(初回のみ)
    3. VCCWのダウンロード
    4. vagrant-hostsupdaterのインストール(初回のみ)
    5. 初期設定
    6. Vagrant起動
    7. Vagrant終了(だいじ)

    順に見ていきましょう。




    Virtualboxのインストール(初回のみ)

    公式サイトから最新版をインストール。僕の場合はOracle VM VirtualBox Base Packages – 5.2.8 (Microsoft Windows Only)をダウンロードし、インストールしました。

    いやいやVirtualBoxってなんやねん

    Vagrantの前に、実はこのVirtualBoxというやつが大事です。

    そもそもVagrantというのは、簡単にいうとサーバーの環境情報を書き込まれたファイルであって、これだけではサーバーとしての機能はありません。

    VirtualBoxという仮想マシンを使ってVagrantという設定ファイルを読み込み、仮想サーバーを立ち上げるということになります。

    言ってしまえば、VirtualBoxこそがサーバーの本体です。

     

    Vagrantのインストール(初回のみ)

    公式サイトからWindowの64bit版をダウンロードし、インストール。

     

    上記2つは、インストール中も特にオプションとか変更はせず、ストレートにそのままインストールしました。
    2つともインストールしたら、PCは再起動したほうがいいらしいので、再起動しました。

     

    VCCWのダウンロード

    PCの再起動が終わったら、おもむろにコマンドプロンプトを開き、開発環境を構築すると思われるディレクトリに移動。

    僕の場合は、”C:\vagrant”というディレクトリを作り、その中で開発環境を構築することに。

    cd ../../
    mkdir vagrant

    C直下まで移動し、vagrantというディレクトリを作る。これくらいであればマウスの右クリックでもできるので、どっちでもいいんですが、黒い画面でできるようになっていたほうが後々便利ですよ。

    次に、vagrantのディレクトリに入り、更にsampleというディレクトリを作り、そしてその中に入る。

    cd vagrant
    mkdir sample
    cd sample

    次は、vccwをgitからダウンロードさせていただく。

    git clone https://github.com/miya0001/vccw.git

    うまくいけば、vccwというディレクトリが作成され、その中にいろいろ入っているのが確認できると思います。

    今のうちにvccwディレクトリ内に移動しておきましょう。

    cd vccw

    vagrant-hostsupdaterのインストール(初回のみ)

    vagrant-hostsupdaterは、hostsファイルを自動で書き換えてくれるプラグイン。これがあれば、vagrant up したあとにhostnameで設定したURLでブラウザからアクセスできるようになる。ちなみにこれはVagrant本体と同じく、PC1台につき1回インストールすればOK。

    vagrant plugin install vagrant-hostsupdater



    初期設定

    vagrant upする前に、WordPressインストール時の設定をいじっておきましょう。

    site.ymlの編集

    provisionディレクトリ内にあるdefault.ymlを、vccwディレクトリ直下に移動し名前をsite.ymlに変更する。コマンドプロンプトなら以下でできる

    copy provision/default.yml site.yml

    site.ymlをエディタで開き、設定をちょっといじる。WordPressの初期設定をいろいろいじれるようになっているが、とりあえず重要なのは以下

    • hostname
    • ip
    • lang

    hostnameは、そこに設定したアドレスでブラウザから確認できるようになる。ここで注意したい点が以下の2つ

    • 実際にあるドメインは使用しないほうがいい。
    • ~.devという形式は、chromeでは使用できないらしい。sample.testとかにすればOK

    ipは、最初は初期設定のままでOKなんですが、環境を複数構築したい場合は、ipが同じだとうまくいかないっぽいので、値を変える必要がありそう。(例:192.168.33.11)

    langは言語設定。日本語が良ければ”en_us”→”ja”にしておきましょう。



    他にもデバッグモードとかマルチブログモードの設定もできるようになっています。好みに合わせて設定しましょう。

    Vagrant 起動

    vagrant up

    実際にブラウザでsample.testとうってアクセスし、うまく表示されていれば大成功!

    念のため管理画面にログインしてみます。

    ログインの初期設定は、デフォルトでは(admin/admin)になっているみたいです。本番にアップする際に面倒なので、最初からsite.ymlを編集してちゃんとしたアイパスに設定しておいたほきましょう。

     

    Vagrant終了(だいじ)

    Vagrantを起動したら、基本的にずっと起動したままになっています。

    これだとPCをシャットダウンできない事態に陥るため、作業終了の際は必ずVagrantを終了させてやりましょう。

    vagrant halt

    Vagrantの起動状態を確認

    終了させたら、Vagrantが終了したかを確認しときましょう。

    vagrant status

    Current machine states:

    wptest.test poweroff (virtualbox)

    The VM is powered off. To restart the VM, simply run `vagrant up`

    poweroffって出てるので止まったみたい。

     

    はまった点

    vagrant-hostsupdaterをインストールしていなかったため、アクセスできずにややはまり。そしてvccwを1回削除し、同じ名前のディレクトリ、同じIPでもう1回インストールしたら、hostnameは変わったもののWordPressのインストールディレクトリが以前のままになっていて(データベースに記録されているんだろうか…よくわからない)レイアウトが大爆発してはまった。

    • vagrant-hostsupdaterを忘れない(初回のみ)
    • IP、hostnameはプロジェクトごとに変える

    これを気を付ければスマートにいけると思います。