投稿者: ぜろみや

  • WordPress 国産で無料のブログ用テーマ「Simplicity」の紹介

    WordPress 国産で無料のブログ用テーマ「Simplicity」の紹介

    突然だが、テーマが変わったのにお気づきだろうか。

    当ブログの読者はほとんどいないため、おそらく気付いているとかいう以前の問題だとは思うが、テーマを変更したのには理由がある。

    私は、当ブログを「テーマのカスタマイズをまったく行わない」という縛りプレイのもと運営している。具体的には、テンプレートを直接いじらない(functions.phpも含め)ということだ。

    フロントエンドエンジニアなのに何しとんねんと思われるかもしれないが、一種の遊びのようなものである。気にしないでほしい。テーマを自作する程度のスキルはちゃんとある。

    そして、今までは「Kale」という海外製のシンプルなテーマを使用していたのだが、カスタマイズをしないのにシンプルなテーマを選ぶという愚かさにとうとう気付いてしまい、しかもフォントも日本向けではないので読みづらいという理由もあったため、カスタマイズに優れていて、日本製で、無料であるという条件のもと、新しいテーマを探した。

    そんなとき出会ったのが、この「Simplicity」である。

    「Simplicity」のダウンロードはこちら




    Simplictyのすごいところ

    インストールして30分くらいしか経っていないが、それだけの時間でもこのテーマのすばらしさを実感できたため、軽く紹介させていただく。

    カスタマイザーが豊富

    明らかに無料ではないレベルのカスタマイズの数々。

    レイアウトの設定も数多く、SEOやアクセス解析の設定、SNSの設定などもできる。

    特にすごいのがこのスキン機能

    ワンクリックでサイトの雰囲気をガラリと変えることができる。しかも種類が多い。

     

    記事ページがすごい

    非常に読みやすい。

    見出しのスタイルもオシャレだし、可読性が良い。日本人には日本人の読みやすさがあるんだと痛感した。

    前のテーマのときもなんとか頑張って読みやすいようにスタイルを調整していたのだが、Simplicityは最初から圧倒的に読みやすいのだ。

     

    記事の下には、よくあるシェアボタンや関連記事が最初からついてる。プラグインとかいらない。

     

    ウィジェットがすごい

    途方もない数のウィジェットが設定できる。広告用のウィジェットまである。

     

    とりあえずざっと見た感じでもこんなにすごい。おそらくもっといろいろな機能があるのだろう。無料というのが信じられない。あとで請求とかされないよね?(されない)

    とにかく今すぐWordPressでブログ書きたいんじゃ!という人には本当にオススメ。

  • WordPress 特定のページを404にリダイレクトさせる方法

    WordPress 特定のページを404にリダイレクトさせる方法

    例えば、WordPressの仕様上絶対に生成されてしまうんだけど、アクセスされたくないので404にしたい場合。
    あんまないとは思うんですけどね…




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

    add_action( 'template_redirect', 'status404' );
    
    function status404() {
      if ( is_tax(array('hoge','moge')) ) {
        global $wp_query;
        $wp_query->set_404();
        status_header(404);
      }
    }

    上記の場合は、”hoge”もしくは”moge”というスラッグのついたタクソノミーページを404にするというものです。

    条件分岐タグを使えば、404にするページを複数指定できます。
    条件分岐タグ一覧

    この分岐の条件を間違えると、全然違うページが404になったりして大変なことになるので、実装する場合はよくチェックしましょう。

  • Settings Syncの設定方法(Gist IDってなんやねん)

    Settings Syncの設定方法(Gist IDってなんやねん)

    ついこの間まで頑なにDreamweaverを使っていましたが、ついに流行のVisual Studio Codeに乗り換えました。軽いし高機能だし素晴らしいですね。世界が変わりました。

    ただ、Settings Syncで同期の設定をするときにちょっとてこずったので、備忘録として解決方法を記しておきます。




    設定のアップロード

    アップロードまではスムーズにいけました。
    設定手順は以下の通り

    1. Githubでトークンを入手(まだGithubのアカウントを持ってない場合はSign Upする)
    2. VS Codeの拡張機能でSettings Syncをインストール
    3. 設定をアップロード

    1.Githubでトークンを入手

    Githubにサインインしたら、右上の自分のアイコンから「Settings」に飛ぶ → 左のメニューから「Developer settings」を選択 → 左のメニューから「Personal access tokens」を選択。

    「Generate new token」をポチー

    適当に名前をつけて、”gist”にチェックを入れて、”Generate token”をポチー

    するとアクセストークンが表示されますので、控えておきましょう。(※画像は公式マニュアルのものです。)

    2.VS Codeの拡張機能でSettings Syncをインストール

    インストールしたら再起動。

    3.設定をアップロード

    正常にインストールできて有効になっている場合は、「Shift + Alt + U」でアップロードできてしまいます。

    初回にアップロードするときにアクセストークンを聞かれますので、さっき控えたやつをペーストしてエンター。これで設定がgitにアップロードされます。



    設定のダウンロード

    先に僕がやらかした間違えた方法と、解決法を記しておきます。

    まず、別PCのCodeにSettings Syncをインストールし、「Shit + Alt + D」でダウンロード。

    このとき、アクセストークンを聞かれました。別PCだからでしょうね。で、アクセストークンを入力したんですが、また入力欄が出てきました。トークン間違えたかな?と思って再度トークンをコピペしてエンターを押したのが間違いで、実はトークンの後に”Gist ID”なるものを入力する必要があったんですね。

    この”Gist ID”を入力してねという説明を読んでなかった僕が悪いのですが、その後入力を直そうと思って「Shft + Alt + D」を何度押してもエラー文が表示されるだけで何も起きなくなってしまいました。

    頼む、修正させてくれ…Gist IDを入力したいだけなんや…

    ここでコケてしまい、Settings Syncを再インストールしたりCode自体を再インストールしたけど全然ダメ。

    でいろいろいじっていたところ、「Ctrl + Shift + P」でコマンドパレットを呼び出し、「Sync: Reset Extension Settings」を選択することで設定がリセットされ、無事解決。

    というわけで、正しい手順はこちら(同PCへのダウンロードの場合は2はいらないかと思います)

    1. Gist IDを入手
    2. 「Shift + Alt + D」を押し、トークンを入力
    3. その後、Gist IDを入力

    Gist IDの入手方法

    Githubにサインインし、自分のアイコンから「Your gists」を選択。

    「cloudSettings」という項目があると思うので、クリック。

    クリックで飛んだページのURLが「https://gist.github.com/ユーザー名/謎の文字列」となっていると思いますが、謎の文字列の部分がGist IDとなっています。これをトークンとは別に控えておいてください。

     

    おわり

    Visual Studio Codeは、高機能であるという代償に設定方法がいろいろめんどくさかったりします。設定さえしてしまえば後は幸せな開発環境が手に入ると思いますので、ぜひめげずにトライしてみましょう。

    ではでは、良いVSCodeライフを!

  • 「コンテンツの幅が画面の幅を超えています」が直らないのと格闘したお話

    「コンテンツの幅が画面の幅を超えています」が直らないのと格闘したお話

    「別の業者さんに作ってもらったこのサイトがモバイルフレンドリーテストに通らないんですが、見ていただけますか?」というお仕事を請けたときのお話。

    見た感じ別に悪いとこなさそうやし、まぁすぐ解決するやろとたかをくくっていたのですが、まずどこが悪いのかすらわからない時点から既にバトルはスタートしていたのだった…

    なんとか解決したので、役に立つ情報かはわかりませんが、何かのヒントになれば幸いです。




    viewportの記述ミス

    カンマがありませんでした。

    <meta name="viewport" content="width=device-width,initial-scale=1.0 maximum-scale=1.0">

    いやviewportの記述が脱字っとるやんwwwwwwはい終わり楽勝wwwwwwww

    <meta name="viewport" content="width=device-width,initial-scale=1.0,maximum-scale=1.0">

    結果:何も変わらず。

    これで終われば平和だったのですが、世の中そううまくいかないようです。
    次いってみましょう。

     

    そもそもモバイルフレンドリーテストはページが正しく認識されるのか?

    何事にも不具合はつきものなので、こういった疑問を持つことも大事です。
    Page Speed InsightsがほとんどのサイトでUnavailableとなっていたのも気になっていたので…
    というわけで、自分が作った他のサイトや、有名なサイトをモバイルフレンドリーテストにかけてみました。

    すると、だいたい想定通りの結果となっていたので、テスト結果は信用できそうな感じです。

    さらに、body内部を全部消してすぐテストしてみたところ、

    このページはモバイルフレンドリーです

    との結果が出ました。
    この時点で、下記のようなことがわかります。

    • テストはキャッシュ関係なく、現時点でのページでリアルタイムに行われる
    • 原因はbody内のどこかにある

    それでは次にいきましょう。

     

    Search Consoleも見てみる

    テスト結果だけではイマイチ全貌を把握できないので、Search Consoleの閲覧ができるようにしてもらいました。

    検索トラフィック→モバイルユーザビリティから、エラーを確認することができます。

    すると、問題のあるページが大量にあったので、これはおそらく共通部分が原因だろうと思いました。

     

    原因のありそうな箇所を削除してテストする

    一部分を削除した状態でテストしてOKと出れば、その削除した部分に問題がある、ということになります。

    というわけで、共通部分のheader,footerを削除してテストしてみました。

    結果:ダメ

    ダメでした。えぇ…共通部分が悪いんじゃないの…

    共通部分が原因じゃないとなると、つまりサイト全体的に何かがおかしいということになってきます。

    もう一度原因を探るべく、部分的に削除してはテストを繰り返しました。



    異変が起きた

    もう何を消してもダメで、何も書かれていない状態でないとOKにならないという絶望的状況のなか、半ばヤケクソでbody内を以下のようにしてやりました。

    <body>
    <div id="wrapper">
    <div id="">
    <article class="">
    <main>
    <p>ああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああああ</p>
    </main>
    </article>
    </div>
    </div>
    </body>

    だいぶ精神が崩壊気味です。いろいろ削除して枠だけにしてあるので、記述がおかしいのはちょっと気にしないでもらいたいのですが、
    問題は、この状態でもNGだったということです。

    これはいったいどういうことなんだ…普通に考えてそんなわけがない…

    ちなみに、<p>あああ</p>だけだとエラーになりませんでした。

    ただ、逆に「これだけしか書いてないのにNGになる」というのは、原因が絞りやすくなったということに他なりません。

    さっぱりわかりませんが、もう少しで解決する。そう確信しました。

     

    問題はCSSにあり

    ここまで中身のない状態でもエラーが出るということは、cssに問題があるという可能性が高いです。
    というわけで、上の状態で全てのcssの読み込みをはずしてみたところ…

    このページはモバイルフレンドリーです

    きた…!もう少しだ…!

    cssを元に戻し、上記に使われている要素のスタイルを眺めてみました。
    すると、怪しい記述を発見。

    body {
      min-width: auto;
      padding-top: 90px;
    }

    min-width: auto;

    おそらく、PCでの表示でmin-widthを設定していたのを、メディアクエリで打ち消したかったんだと思いますが、min-widthにautoは誤りです。

    min-width:1px;となおしてテストにかけました(initialのほうが正しいかもしれないです)。

    このページはモバイルフレンドリーです

    やったぜ!!!

    もちろんほとんど中身がない状態での通過だったので、本番環境でもcssをなおしてテストしました。
    無事、通過。

    よかった…。完全勝利。

    おわり

    モバイルフレンドリーテストは、SEOを行うにあたって避けては通れない部分ですが、これは数ある対策のうちの一つにすぎません。

    更なる対策として、【集客職人 RankingCoach】などのSEOツールを使い、ホームページの集客力をアップしていくのも手段の一つです。SEOコンサルを行う際に使用するのも有効ですよね。

     

    それでは、エレガントなSEOライフを。

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

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

    WordPressのプラグインには、便利なものが山ほどありますが、まだ慣れていないうちは何を使えばいいかわからないですよね。

    その中でも、数々のWordPress案件をこなしてきた私がよく使っているプラグインをいくつか紹介します。

    便利なプラグインを知っていれば、WordPressでのサイト制作は確実に質が上がりますよ。




    ほぼ必須系

    どんな案件だろうと入れておいて損はない系プラグイン4つ

    SiteGuard WP Plugin

    お手軽にセキュリティ対策ができるプラグイン。

    いろんな機能がありますが、とりあえず「ログインページ変更」「画像認証」「ログインロック」だけでも有効にしておけば、ブルートフォースアタックに対応できます。

    もちろんこれだけでは万全と言えないので、その他のセキュリティもチェックする必要はあります。

    ダウンロードはこちら

     

    BackWPup

    データのバックアップを自動でとってくれるプラグイン。

    データベースはもちろん、テーマどころか、インストールしたディレクトリ以下であれば丸ごと全部バックアップとれてしまう。便利。

    バックアップ用プラグインはいろいろありますが、高機能かつ自由度が高く、一番オススメです。

    ダウンロードはこちら

     

    その他のデータベースバックアップ方法は、データベースのバックアップをとる方法3タイプで紹介しています。

     

    All in One SEO Pack

    その名の通りこれ一つで、metaまわりの設定やOGPの設定、AnalyticsやSearch Consoleとの連携が行える。

    「titleやdescription等は管理画面からこのプラグインを使って変更できます」と丸投げできて便利。

    最近、Yoast SEOと比べられることが多いけど、僕はこっちのほうがわかりやすくて好き。無料で十分いけます。

    ダウンロードはこちら

     

    TinyMCE Advanced

    エディターの拡張機能プラグイン。

    フォントサイズ変更くらいはデフォルトで入れておいてあげると親切。

    ダウンロードはこちら

     

     

    準必須系

    そういう案件であればだいたいこれを使うであろうプラグイン5つ。

    Custom Post Type UI

    カスタム投稿タイプとカスタムタクソノミーを設定できるプラグイン。

    高機能かつ自由度が高い。

    ダウンロードはこちら

     

    Custom Post Type Permalinks

    カスタム投稿タイプのパーマリンクの設定ができる。

    だいたいCustom Post Type UIとセットでインストールする。

    ダウンロードはこちら

     

    Advanced Custom Fields

    カスタムフィールドの設定をするならこれ。高機能。

    リピーターフィールド等、一部有料の拡張モジュールもあるが、安いし買えばいいと思う。

    プラグイン自体をテーマ内に含めてしまう方法もあるので、テーマを作成するときにも使えます。

    ダウンロードはこちら

     

     

    MW WP Form

    日本産のお問い合わせフォーム用プラグイン。

    フォームに必要な機能はだいたいついている。

    日本語なので、フォーラムも日本語で情報も多く使いやすい。

    ダウンロードはこちら

     

    WP Admin UI Customize

    特定のログイン権限に対し、管理画面に表示させる項目を手軽に設定できるプラグイン。

    クライアントには重要な部分を触らせたくない場合に。

    ダウンロードはこちら

     

    テスト系

    テストするときとかに便利なプラグイン2つプラスおまけ1つ。

     

    Theme Test Drive

    ログインしているときだけ、テスト用に設定したテーマを表示させることができるプラグイン。

    これを使えば、わざわざテスト用サーバーを準備しなくていいので時短になる。

    ただし、対象はテーマだけで、管理画面から入力する必要のある部分(固定ページの内容とか)を変更する場合はややこしくなる。

    最終更新が2年前となっているが、テストが終わったらアンインストールすればいいので、特に問題はない。

    ダウンロードはこちら

     

    Duplicate Post

    投稿を複製できるプラグイン。複数の記事に対しチェックが必要な場合に捗る。

    これでカスタムフィールドを複製するとデータベースが壊れることがあるので要注意

    運用開始後はあんまり使わないほうがいいかも。

    ダウンロードはこちら

     

    おまけ – WordPressテーマユニットテストデータ

    様々な状況を想定した記事データをインポートし、記事ページの表示をチェックするためのツール。

    日本語対応で、これによりけっこうな量の表示不具合を発見できたりする。1回は使ってみるといい

    詳細はこちら

     

     

    以上、WordPressで使える便利なプラグインたちを紹介しました。

    基本はカスタマイズをガンガン行うとき用に使用するプラグインが多いです。上記のプラグインで、だいたいのWordPress案件はこなすことができますね。

    ただ、便利でガンガン使ってしまう反面、人が作ったものなのでどのようなバグが潜んでいるかわからないため、作業前にデータベースのバックアップは必ずとっておきましょう。

     

  • WordPress – 親カテゴリーIDと階層を指定し、リスト表示させる

    WordPress – 親カテゴリーIDと階層を指定し、リスト表示させる

    要件

    管理画面で”親カテゴリーのID”と”階層”を入力し、カテゴリーリストを表示させたい。

    例:
    カテゴリーID…1,4,5
    階層…2
    と入力すると、

    • カテゴリー1
    • – カテゴリー1の子1
    • – カテゴリー1の子2
    • カテゴリー4
    • カテゴリー5

    みたいに表示される感じにしたい。




    問題

    最初は、”wp_list_categories()“を使ってこんな感じでぱぱっとできると思っていました。値の入力はテーマカスタマイザーでの手入力です。

    <?php
      $options = get_option( 'my_theme_options' );
      $side_cat_id = $options[ 'side_cat_id' ]; //カテゴリーIDを文字列で取得
      $side_cat_hierarchy = $options[ 'side_cat_hierarchy' ]; //階層を文字列で取得
    
      // 階層が入力されてない場合は親のみ表示
      if($side_cat_hierarchy):
        $depth = $side_cat_hierarchy;
      else:
        $depth = 1;
      endif;
    
      // wp_list_categories()の設定
      $args = array(
        'depth' => $depth,
        'title_li' => '',
        'include' => $side_cat_id,
        'hide_empty' => 0,
        'hierarchical' => 1
      );
    ?>
    
    <ul>
      <?php wp_list_categories( $args ); //出力 ?>
    </ul>

    ところが、子カテゴリーが表示されない…

    どうも、’inculde’でカテゴリーIDを指定すると、階層を有効にしても、指定したIDのカテゴリーしか表示されないようです。子カテゴリーは自動で出てこない。

    解決

    先に、指定した親カテゴリーIDの子孫を全部取得し、一家全員のIDをincludeに入れてやる作戦に変更。

    <?php
      $options = get_option( 'my_theme_options' );
      $side_cat_id = $options[ 'side_cat_id' ]; //カテゴリーIDを文字列で取得
      $side_cat_hierarchy = $options[ 'side_cat_hierarchy' ]; //階層を文字列で取得
    
      // 階層が入力されてない場合は親のみ表示
      if($side_cat_hierarchy):
        $depth = $side_cat_hierarchy;
      else:
        $depth = 1;
      endif;
    
      // 指定IDの子孫カテゴリーIDを全部取得し、変数"$include"にまとめる。
      if($side_cat_id):
        $parents = get_categories(array(
          'hide_empty' => 0,
          'include' => $side_cat_id
        ));
        $childes = array();
        foreach($parents as $parent):
          $childes = array_merge($childes, get_categories(array('hide_empty'=>0, 'child_of' => $parent->term_id )));
        endforeach;
      
        foreach($childes as $child):
          $child_id[] = $child->cat_ID;
        endforeach;
      
        if($child_id):
          $child_cat_id = implode(',' ,$child_id );
        endif;
      
        $include = $side_cat_id. ',' .$child_cat_id;
      else:
        $include = '';
      endif;
    
      // wp_list_categories()の設定
      $args = array(
        'depth' => $depth,
        'title_li' => '',
        'include' => $include,
        'hide_empty' => 0,
        'hierarchical' => 1
      );
    ?>
    
    <ul>
      <?php wp_list_categories( $args ); //出力 ?>
    </ul>

    これで、要望通り動くようになった。

    もうちょっとすっきり書けないかなぁ…

  • 初心者がコーディングを3倍速くするために知っておきたい6つの技術

    初心者がコーディングを3倍速くするために知っておきたい6つの技術

    HTML/CSSコーディングは、ある程度慣れてくると、どうやって書けばこのデザインを実現できるかという思考から、どうやれば早く効率的に終わらせることができるかという思考に切り替わってきます。

    早く終わらせるには、ただタイピングが早くなるとかショートカットを覚えるというだけでなく、世の中にはいろいろ便利なコーディング技術があるということを知る必要があります。

     

    というわけで今回は、この技術を知ったおかげでコーディングがめっちゃ速くなったというものをいくつか紹介しますので、「コーディング 速くする」とかで検索した人が便利な技術に出会える機会が少しでも増えるといいなと思います。

    本記事で紹介する技術は以下の6つ。

    • Emmet
    • Sass
    • BEM
    • gulp
    • スニペット
    • マルチカーソル

    順に見ていきましょう。





    Emmet

    最初にこれを知ったときは、「俺は今まで何をやってたんだ」というレベルの革命が起きました。とあるセミナーで、講師がそれを使って見せたときは「え、今何したの???????」って感じでした。

     

    Emmetがどんなものかを簡単に説明すると、例えば、以下のようなHTMLを書きたいとき。

    <section id="about">
     <div class="l-container">
       <div class="l-box">
         <h3 class="title"></h3>
         <p class="txt"></p>
       </div>
       <div class="l-box">
         <h3 class="title"></h3>
         <p class="txt"></p>
       </div>
       <div class="l-box">
         <h3 class="title"></h3>
         <p class="txt"></p>
       </div>
     </div>
    </section>

    Emmetを使うと、

    section#about>.l-container>.l-box*3>(h3.title+p.txt)

    こんだけです。

    やばくないですか。上記はちょっとイマイチわかりづらかったかもしれないですが、要は

    p

    と打ってTabキーを押すだけで、

    <p></p>

    と展開されるといった感じです。圧倒的スピードでHTMLを書くことができます。

    しかもEmmetはCSSにも使えます。例えば、

    • va → vertical-align:
    • fz → font-size:
    • bdls → border-left-style:

    など、書くのがめんどくさい記述を大いに短縮して書くことができるようになります。

    Emmet、是非習得してみてください。簡単に導入できますし、これを使うのと使わないのでは倍速くらい差が出ると思います。

    Sass

    こちらは、使い始めるとコーディング方法ががらりと変わります。コーディング自体が速くなるだけでなく、変数を使った値の操作や、慣れればSMACSSBEMといったCSS設計を学ぶことにより、cssの管理性、拡張性、再利用性なんかを考えるようになり、「あー、エンジニアやってるなー」といった気になってきます。

    奥が深く、すぐに習得できるようなものではないですが、フロントエンドエンジニアとしては是非習得しておきたいもの。いきなりいろいろやるのはハードルが高いと思いますが、どんなことができるのかさらっと紹介します。

    要素のネスト(入れ子)

    例えば、CSSでこんな感じで書きたいとき

    ul {
      margin-bottom: 20px;
    }
    ul li {
      margin-bottom: 5px;
      padding-left: 5px;
    }
    ul li:last-child {
      margin-bottom: 0px;
    }
    ul li a {
      text-decoration: none;
    }

    Sassでは、入れ子で書くことができます。

    ul {
      margin-bottom: 20px;
      li {
        margin-bottom: 5px;
        padding-left: 5px;
        &:last-child {
          margin-bottom: 0px;
        }
        a {
          text-decoration: none;
        }
      }
    }

    全体的に書くコードを少なくするだけでなく、どの要素にどんな子要素がいるか、階層はどれくらいかなどが一目でわかるようになります。

    最初は、この入れ子ができるだけでもかなり速くなります。ただ、ばんばん入れ子にしていると実際のCSSがえらいことになりますので、慣れてきたら「がんばって3階層までに納める」といったルールを作っていきましょう。

    他にも変数やmixinといった便利な機能があるんですが、それらはSMACSSなどの再利用性を考えるようになるまではイマイチ有用性がわからないかもしれないので、徐々に慣れていけばいいでしょう。

    Sassを使いこなせるようになり、再利用性の高いコードを書けるようになってくると、独自のフレームワークのようなものができていき、コードを書く量が減っていきます。数をこなすほどどんどんスピードが上がっていきますよ。



    BEM

    BEMはSassと組み合わせることで効力を発揮します。BEMは、技術と言うよりどちらかというと概念に近いんですが、どのようなものかさらっと紹介します。

    BEMとは、Block(塊)、Element(要素)、Modifiier(状態)の3つの頭文字をとった略語で、主にCSSのための命名規則の一つです。
    この3つの概念を念頭に置いて、次のようにclassに名前をつけます。アンダースコアだったりハイフンだったりは、人によって好みでつけている感じが見受けられますが、元となっているのはこの形。

    class=”{Block}__{Element}–{Modifier}”

    ちなみに僕はこう。

    class=”{Block}__{Element}_{Modifier}”

    例えば、以下のようにマークアップします。

    <article class="content">
      <h2 class="content__h1"></h2>
      <p class="content__text"></p>
    </article>
    
    <article class="content">
      <h2 class="content__h1_center"></h2>
      <p class="content__text"></p>
    </article>

    “content”は独立したブロックで、基本はどこでも使いまわせるクラス。

    “content__h1”,”content__text”は、“content”の中でしか使えないクラス

    さらに”content__h1_center”とすることで、”content_h1″にバリエーションを持たせることができます。他にもバリエーションがほしかったら、”content__h1_center-red”とかね。

     

    この一見ややこしいことをしているBEMですが、

    • CSSで深い入れ子にならない(読みやすい)
    • 命名に迷わず、かつわかりやすい
    • 拡張しやすく、壊れにくい
    • ほぼ全要素にclassをつけるので、要素に依存しない。

    といったメリットがあり、最初は苦戦しますが、慣れてくると命名に迷わなくなり、逆にすらすら書けるようになります。しかも後で修正するときに、修正しやすいです。ぜひ挑戦してみてください。

    gulp

    gulpとは、タスクランナーと呼ばれるツールの一種で、いろんな作業を自動化することにより、開発にかかる時間を短縮できるものです。だいたいは、前述のSassとセットで使われる(というより、gulpを使ってSassをコンパイルする)ことが多いです。

    これはどんなことができるかというと。

    ベンダープレフィックスを自動でつける

    gulp-autoprefixerというモジュールを使うことで、書くのが面倒な-webkit-やら-ms-やらのベンダープレフィックスを、なんと自動でやってくれるようになります。

    .flex {
      display: flex;
    }
    
    /* コンパイル後 */
    
    .flex {
      display: -ms-flexbox;
      display: flex;
    }

    僕は基本的に各ブラウザの最新にしか対応していないですが、gulp-autoprefixerは対応するブラウザをオプションで選択することもできるので、どんな案件でもなんとかなります。

    リロードしなくても、修正が反映される

    cssやhtmlを修正したあと、ブラウザで確認しようとするとページのリロードを行う必要がありますが、gulpのbrowser syncというモジュールを使えば、わざわざ毎回ページをリロードしなくてすむようになります。

    モニターが2つあり、片方にページを写し片方にエディタを写せば、エディターでセーブするだけでページに修正が反映され、時間が短縮されますね。

    スニペット

    僕はDreamweaverしかほぼ使ったことがないので、他のエディターではできるかわからないんですが(現在はVisual Studio Codeを使用していますが、Codeでも普通にできます)、スニペットという機能があります。

    これは、よく使うコードを辞書として登録しておき、ショートカットでぱぱっと呼び出せるという機能です。

    例えば、

    _res
    
    /* Tabキーぽちー↓ */
    
    @media screen and (max-width: 1024px){
    }

    みたいな使い方。素敵だと思いませんか。数行に渡るコードが一瞬で書けます。

    WordPressの開発とかでも、よく使うけど書くのが面倒なものは全部スニペットに登録しちゃってます。

    ショートカットじゃなくても、辞書からダブルクリックで呼び出したりもできるので、安心です。

    マルチカーソル

    こちらもエディタ依存ですが、Dreamweaverの場合の紹介です。

    複数行を一括で修正したいとき、Altを押しながらマウスでドラッグすると…

    こんな感じでぱぱっとできちゃう。

    Ctrlバージョンではこんなことも可能。

    任意の場所をCtrlでぱっぱっぱと指定し、一斉に修正できます。

    VS Codeでのマルチカーソルのまとめは、以下を参考にどうぞ。

    VS Code 複数行選択できる「マルチカーソル」まとめ

    マルチカーソル以外にも便利なショートカット等、コーディング時間を短縮する機能がエディタにはありますので、「エディタ名 便利 機能」とかでググると幸せになれますよ!

    おわり

    他にもまだまだコーディング高速化の技術はあると思いますが、とりあえず僕が最初に出会ったとき「これはやべぇ!」と思った技術の紹介をしました。実際にこれらの技術と出会い、会社に導入するようになってからは、会社全体の業績がぐーんと伸びて一気に成長した……ような気がします。

    HTML/CSSコーディングは、仕組みがわかってしまえばあとは作業です。この作業をいかに効率化し、ぱっと終わらせることができるかによって、仕事の質も上がっていきます。

    もちろん僕もまだまだ修行中の身ですので、「他にもこんなんあるよ!」とかあったら教えてください。

     

    さらにWeb制作の効率を上げるために、こっちの記事もどうぞ!

    Web制作の効率爆上がり!超便利なChromeの拡張機能10選

    ではでは、いいコーディングライフを。

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

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

    フリーランスになると、自分の金額を自分で決めなければいけません。僕は制作会社でWebディレクターをやっていたので、なんとなく費用感はわかっていましたが、それでもフリーランスとなると更に細かく気を遣う必要があると感じました。

    自分もお客さんも納得する、そんな見積もりの出し方を日々考えています。そして何より、いい仕事をする。悪い仕事、悪いクライアント(失礼な言い方ですが、実際にいます)はお断りする意味でも、最適な金額をつけられるようになりましょう。

     

    ※あくまで1フリーランスの方法なので、これが絶対正しいわけではないです。少しでも参考になればと思います。

     

    ちなみに、見積もりに使うWebサービスはmisocaがオススメ。

    その他フリーランスの作業効率化に便利なWebサービスは下記記事にて紹介しています。

    https://meshikui.com/2018/03/13/182/




    自分の1日の価値を決める

    まずはここからです。例えば1日8時間働くとして、自分の時給を自分で決め、時給×8で1日の値段を決めます。これは、1人日(いちにんぴ)という考え方です。技術者の場合は、人日(工数とも言われます)が基本単位となります。

    金額は何の仕事をメインにしているかにもよると思いますが、IT系の場合はだいたい、1時間5,000円で1人日40,000円くらいがフリーランスのスタンダードな気がします。相場を知る方法は以下の記事を参考にどうぞ

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

    1人日が決まったら、あとは作業時間に応じて詳しく値段をつけていきます。ただ、実際に見積書に人日を書く必要はなく、そこは円だけでいいと思います。お客さんは「だいたいそのくらいの時間なのか」と思ってしまいますが、実際は時と場合、その人のスキルによって変わりますし、あくまで目安としての人日計算でいいんじゃないでしょうか。

     

    いつもやっているようなことは、ある程度値段を決めておく

    開発といっても例えば、HTMLコーディングやWordPressの初期設定など、だいたいいつも決まってやっていて、内容があまり大きく変わらない作業があると思います。
    そういった作業は、最初からある程度値段を決めておきます。もちろん、単位は”円”ではなく”時間”です

    例えば…

    • トップページコーディング…1.5日
    • 下層…2時間
    • WordPressテーマ基本設定費…1日

    といった具合に。これには、いくつかの理由があります。

     

    企画段階では、ページ内容がどれくらいあるかわからない

    ページの内容によって、だいたいこのページはこれくらいの値段だろう、と毎回見積もりの度に調査していては、見積もりだけで1日つぶれることになりかねないし、効率的とはいえません。ましてや、どのページがどれくらいの量ありますか?と聞くのは、お客さんにとっても面倒だし、正直そんなの誰もよくわからないです。

    なのでここは、ざっくり1ページ2時間かかることにして固定で出してしまったほうが、スムーズにいきます。全ページが2時間以上かかることは、まぁそうないと思います。

     

    もちろん、1ページ完結型のサイトも珍しくありません。その場合は見積もりを作ってくださいと言われた段階でわかると思いますので、臨機応変に対応しましょう。

     

    いつもやる作業は、作業時間が短くなる

    はい、これとても大事です。

    HTML/CSSコーディングなんかはそれはもうひたすら毎日のように書き殴るわけですが、書けば書くほど、コーディングスピードは当然速くなっていきます。

    もしくは、sassやemmetを学び急激にスピードアップすることもあるでしょう。SMACSSやBEMなどの設計方法を学べば、効率よくコーディングできるようになります。

     

    そう、経験値が増えてレベルが上がると、コーディングにかかる時間は減るのです。そんなとき、かかる時間を毎回計算していたらどうなるでしょうか。がんばって勉強して速く作業ができるようになったのに、値段が安くなるというわけのわからないことになりかねません。

    もちろんこのあたりもうまく加味した上で計算できれば最高ですが、なかなか難しいので最初から決めておいたほうが無難です。

    作業によっては値段を変える

    上記で値段を決めておけと言ったにも関わらず、今度は何を言っているかというと…

    ひとえに制作といえど、いろんな種類の作業がありますよね。例えば以下のような要件があるとします。

    • HTML/CSSコーディング
    • PHPプログラミング
    • 顧客データ入力2,000件

    この場合、コーディングとプログラミングは1時間4,000円で計算したとして、顧客データ入力2,000件も同じく計算したらどうでしょう。だいたい2日かかるとしたら、顧客データ2,000件入力するだけで64,000円かかることになりますね。どえらいことです。普段高額な仕事を請ける方は麻痺しているかもしれませんが、64,000円は一般的な家賃くらい払えます。

     

    要は、作業にも専門家しかできない作業から誰でもできそうな作業までピンキリなので、全部同じ値段で出していたらお客さんが納得しないことがあるでしょう。

    納得できないなら、その部分は他に回してくださいと言えるなら全然それでいいんですが、(データ入力ならそれでいい気もしますが)なかなかそうもいかないので、値段を下げたほうがいいでしょう。

     

    ただし、もし同じ値段でお客さんが納得してくれたら、外注に出しちゃうというのも手です。それであれば、外注時におけるディレクションも含めた自分に対する値段ということで無理やり自分も納得できますしね。

    もちろん、場合によっては値段を高くしてもいいと思います。最終的に「自分もお客さんも納得できる値段」に持っていければ勝ちです

     

    自分のやる作業を決めておく

    上記の作業ごとに値段を変える、という件のおまけ的な話ですが、自分がやる作業を決めておいて、それ以外はやらない、というスタンスでいるのも大事です。

    例えば僕の場合、デザインはやりません。できないわけではないんですが、できないわけではないレベルで仕事をするというのは、良いことは一切ない(時間かかる、質が悪い、イメージが悪くなるetc)ので、得意なこと、お任せくださいといえることだけでお仕事をいただいてます。

     

    ただし、データ入力のような「ファッ!?こんなん誰でもできるやろなんでやってくれんのや」と、それはまぁおっしゃる通りだというようなことを言われたときに「僕はやらないんです!!!!」と言えるような強靭な精神を持っていない限り、ある程度許容範囲は広く持っておいたほうがいいでしょう(笑)

    対応範囲、及び仕様をあらかじめ伝える。

    これも、慣れないうちはなかなか難しいと思うのですが、大事です。

    例えばトップページコーディング4時間としたとき、いざデザインが来た段階でもうjavascriptアニメーションがとんでもなかったり、SVGがすんごい動いてたらどうしましょう。やばいですよね。

    なので、見積もりの段階で※javascript等のアニメーションが複雑な場合は、料金が変更になる場合がありますと注釈を書いておきましょう。

     

    お問い合わせフォームも、単純なものであればプラグインでできますが、選択によって内容が変わったり、予約できる日時を管理画面で編集できたりという要望があとから来た場合「いやーそれはちょっときついっす…追加料金と時間をいただければなんとか…」とはならない場合が多いので、あらかじめ※特殊な仕様が必要な場合は以下略と書いていたほうが安全です。

     

    あとは、SEO対策もですね…普通にコーディングしたあとで「SEO対策ができてないんだけど」と言われて、そりゃやってないものと憤慨するより、最初からSEO対策は含んでませんと書いておいたほうがいいです。

    SEO対策してくださいと言われたら、「詳しくはわからないので、どこをどうすればいいか教えてください」と言うことにしています。ただし、最低限セマンティックコーディングは心がけたほうがいいでしょう。

     

    脱線しましたが、こういったリスクを未然に防ぐことは金額を決める立場では非常に重要になるので、がんばってできるようになりましょう。だいたい1回は失敗して損するので、次から気を付ける心持ちでいいと思います。

     

    プラグインを使う場合のリスクと代替案

    こちらもなかなか、やってみないとわからない部分もあるのですが、もしわかるのであれば最初に説明してあげたほうがいいです。

    例えば、メルマガシステム

    WordPressのメルマガは、プラグインを使用すれば実装可能ではありますが、レンタルサーバーからのメルマガ配信は思うようにいかない場合が多いです。じゃあ専有サーバーにすればいいんじゃないかと言われますが、専有サーバーに比べれば、レンタルサーバー+メルマガ配信サービスのほうがはるかに安いし、機能的にも素敵です。

    なので、「プラグインを使えば実装はできますが、動作が安定しません。確実性を求めるのであれば、メルマガ配信サービスのほうがいいと思いますよ」と言ってあげましょう。

     

    あとはSNSへの自動投稿もそうですね。

    • 簡単だし安いけど動作が安定しないプラグイン
    • めっちゃ高いし実装に時間かかるし、実際に認証されるかわからないけどサポートはできるオリジナルシステム(ただしSNSの仕様変更で使えなくなる可能性はある)
    • 面倒だが、無料で間違いなく確実にできる手動投稿

    上記の中から選ばせてあげましょう。まぁ無料のやつを選ぶんじゃないですかね。

    クライアントは当然、システム的なことであればなんでも具現化できると思っていますので、できる・できないはきちんと説明してあげる必要があります。そのためには、自分の経験も必要ですけどね。

    まとめ

    以上、現在僕が見積もりの際に気を付けていることを書きました。結論、自分も相手も納得できる値段というのが肝だと思います。

    僕自身、他のフリーランスの方の見積もりをあまり見たことがないのでほとんどが自分の考えになってしまっていますが、「それは違うよ!」とか「こういうのもいいよ!」ってのがあれば教えてほしいです。

     

    自分に値段をつけるというのはなんだか恐れ多い気もするかもしれませんが、フリーランスは、もっと自分に自信をもって値段をつけてください。相手に言われた値段で納得できない場合は、無理に請けなくていいんです。

    ランサーズとか見てると、ほとんどがあり得ないような低価格で募集されていて、そしてそれに提案がそこそこあるんですよね。もっと自分を大事にしましょう。

  • 上付き文字を表すsupが反映されないとき確認すること

    上付き文字を表すsupが反映されないとき確認すること

    意外と知られていない、上付き文字を表すためのhtmlタグ、<sup>。

    例えば、

    <p>定価200円<sup>※</sup></p>

    とすれば、

    定価200円

    のように表示されます。

    ちなみに下付き文字を表す場合は<sub>。これはいつ使うんだろう。

    ところが、タグで囲んでも反映されない場合があります。そんなときはリセットCSSを疑ってみましょう。




    html, body, div, span, applet, object, iframe,
    h1, h2, h3, h4, h5, h6, p, blockquote, pre,
    a, abbr, acronym, address, big, cite, code,
    del, dfn, em, img, ins, kbd, q, s, samp,
    small, strike, strong, sub, sup, tt, var,
    b, u, i, center,
    dl, dt, dd, ol, ul, li,
    fieldset, form, label, legend,
    table, caption, tbody, tfoot, thead, tr, th, td,
    article, aside, canvas, details, embed, 
    figure, figcaption, footer, header, hgroup, 
    menu, nav, output, ruby, section, summary,
    time, mark, audio, video {
    margin: 0;
    padding: 0;
    border: 0;
    font-size: 100%;
    font: inherit;
    vertical-align: baseline;
    }

    ありますね。削除しときましょう。

    リセットCSSはまだ使っている方も多いと思うんですが、そこまでやらなくていいじゃんというのも含まれていますので、自分用に適宜削除したり定義を追加したりしてやればいいと思います。

    ノーマライズCSSをベースにしている場合は心配いりませんね。

  • gulpでplumberが動かないときの単純なミス

    gulpでplumberが動かないときの単純なミス

    gulpでSASSをコンパイルする際、SASSで記述ミスがあったりすると”gulp watch”が中断されてしまう。

    それを防ぐために”gulp-plumber”を使用しているわけですが、設定しているにも関わらずやっぱりどうにも中断されてしまう。

    Node.jsやモジュールのバージョンのせいか、はたまたgulpfileの書き方が悪いのかといろいろ調べていたけど、結局解決しないまま月日は流れ…

    そしてある日、急に解決しました。原因はとても単純。




    var gulp = require('gulp');
    var sass = require('gulp-sass');
    var sassGlob = require('gulp-sass-glob');
    var autoprefixer = require('gulp-autoprefixer');
    var browser = require('browser-sync');
    var plumber = require('gulp-plumber');
    var sourcemaps = require('gulp-sourcemaps');
    var wait = require('gulp-wait');
    
    gulp.task('server', function() {
      browser({
        proxy: 'http://localhost/xxxx/htdocs'
      });
    });
    
    gulp.task('sass', function() {
      gulp.src('htdocs/common/_sass/**/*scss')
        .pipe(plumber())
        .pipe(sourcemaps.init())
        .pipe(sassGlob())
        .pipe(wait(100))
        .pipe(sass({
          outputStyle: 'expanded'
        }))
        .pipe(autoprefixer())
        .pipe(sourcemaps.write('./'))
        .pipe(gulp.dest('htdocs/common/css'))
        .pipe(browser.reload({
          stream: true
        }));
    });
    
    gulp.task('default', ['server'], function() {
      gulp.watch('htdocs/common/_sass/**/*.scss', ['sass']);
    });

    gulp-plumberはタスクの先頭に書いてやる必要があったのでした。