Author Archives: ake_nyanko

schooさんで生放送授業をやってきました

去る2017年7月16日、schooさんで超初心者向けのインターネット公開生放送授業をやらせていただきました。

【HTMLに一切触れたことがない初心者のための60分】
https://schoo.jp/class/4191

1回限りの生放送限定でアーカイブはされないので、後から見てもらうことはできないんですが、
内容的には本当に「HTMLって何をするものなのか?」「HTMLってどうやって書くのか?」といった超初心者向けの内容を
ほんの触りだけ紹介する感じの内容です。

なんですが、実際やってみるととにかく時間が足りない足りない…w
制限時間に対して内容入れすぎなんだろうけど、でも「せめてこのくらいは…」と思うとどうしてもいろいろ入れたくなっちゃって。
最後の方はもう半分くらいはしょって、とりあえずサンプルの題材にしてたうちの猫たちの写真と動画を見せるところだけは死守してみたりww
いやほらだって、ぶっちゃけHTMLだけ書いてたってパッと見面白くないじゃない?w
そろそろ飽きてくるだろう後半部分なので、可愛いネコ写真で癒やされてもらうのも大事かとwww

普段はプロを目指している前提の初心者さんや、既に現場に出てるけど基礎があやふやな経験者さん向けに、
HTMLの基礎を一からキッチリ叩き込む系の講座をやってるので、なかなか初めての人に興味をもってもらう目的の講座
っていうのがやっぱり作ってて難しかったですね。
いっそ前半のHTMLとCSSの触りだけで実習終わりにして、後は全部小話とか質疑応答にしちゃった方が楽しかったかも。
まぁそれだと技術的には内容スッカスカなのでそれはそれでアレですけどね。

初めての試みでなかなかテンパりましたけど、結構楽しかったので、
また機会があったらお呼びいただけるとありがたいなーと思います( ´∀`)

ちなみにいつもやってるサポタントさんのセミナーは、
諸事情によりしばらくお休みさせていただくことになっております。
再開は早ければ年内、遅いと来年以降になるかと思いますが、それまではこちらの著書で学習していただけると幸いです( ´∀`)

【HTML5.1勧告】セクション要素内見出しレベル仕様の変更について

html5.1

2016年11月1日付でW3CがHTML5.1を勧告しました。
HTML5からの変更差分はこちらにまとめられていますので、詳細はこちらを見ていただくとして、
今回はその中で「removed」つまり削除された仕様の一覧の中にあった次の項目に注目したいと思います。

・The use of nested section elements each with an h1 to create an outline.
(・アウトラインを生成するためにそれぞれh1を持つネストされたセクションを使用すること)

HTML5でのアウトラインと見出しのルール

2014年勧告のHTML5では、「セクショニング・コンテンツの入れ子によって正しく階層構造がマークアップされている場合、その中で使用される見出しレベルは問わない」という仕様がありました。
このことはHTML4.01からHTML5になったときの大きな仕様変更のひとつであり、HTML5が登場した初期には盛んに紹介された項目であったため、ご存知の方も多いかと思います。
W3CのHTML5仕様では以下の2つのマークアップはいずれも同じアウトラインを生成するとして事例紹介されています。

<body>
 <h1>Apples</h1>
 <p>Apples are fruit.</p>
 <section>
  <h2>Taste</h2>
  <p>They taste lovely.</p>
  <section>
   <h3>Sweet</h3>
   <p>Red apples are sweeter than green ones.</p>
  </section>
 </section>
 <section>
  <h2>Color</h2>
  <p>Apples come in various colors.</p>
 </section>
</body>

<body>
 <h1>Apples</h1>
 <p>Apples are fruit.</p>
 <section>
  <h1>Taste</h1>
  <p>They taste lovely.</p>
  <section>
   <h1>Sweet</h1>
   <p>Red apples are sweeter than green ones.</p>
  </section>
 </section>
 <section>
  <h1>Color</h1>
  <p>Apples come in various colors.</p>
 </section>
</body>

HTML5.1でのアウトラインと見出しレベルのルール

ところが、HTML5.1では上記のうち「各セクションの見出しレベルを全てh1にする」事例が削除され、

Authors should use headings of the appropriate rank for the section’s nesting level.
(著者は、セクションのネストレベルに応じて適切なランクの見出しを使用する必要があります。)

◎出典:https://www.w3.org/TR/2016/REC-html51-20161101/sections.html#headings-and-sections

との記載がなされています。
著者は、セクションのネストレベルに応じて適切なランクの見出しを使用する必要があります。
つまり、HTML5.1の仕様ではセクショニング・コンテンツによって正しく情報構造をマークアップしていても、それだけで正しくアウトラインを生成することはないということになります。
文書のアウトライン=情報の階層構造はあくまで見出しレベルによって判定される以前の仕様に戻ったという風に解釈して良いと思われます。

仕様変更によって何か影響はあるのか?

この仕様変更によって何か実務的に影響はあるのか? という点ですが、
実質的には特に何もないと思われます。
理由は、そもそもネストされたセクション要素の見出しを全てh1にしてマークアップしているケースはほとんど無いと思われるからです。

仮に全てのセクションの見出しをh1にしてしまっていたとしても、それで「今まで正しくアウトライン判定されていたものが急に判定されなくなる」ということはありません。
なぜなら今までもそのマークアップでは正しくアウトライン判定されていなかったはずだからです。

今回削除されたアウトライン判定の仕様は、当初から「at risk(今後削除される可能性がある仕様)」扱いであり、W3C仕様でも「スクリーンリーダー等の支援技術やブラウザでこの仕様をサポートしている環境はまだ無い」と注意を促していました。
そして仕様としては残しながらも「制作者は正しくアウトラインを伝える必要がある場合、セクションのネストレベルに応じた見出しレベルを使用することを推奨」していました。

もともと仕様だけはあったけれども実質的には機能していなかったものを、今回正式に削除しただけのものであるので、仕様変更に伴う実質的な影響は「何もない」ということになります。

ではセクションを入れ子にして階層構造をマークアップすることは意味が無いのか?

アウトラインが見出しレベルによってのみ判断されるということであれば、「セクション要素なんか使わなくても良いのではないか?」と思う方もおられるかと思います。
個人的には、「使っても使わなくても結果は全く同じ」なのであれば別に好きにすればいいと思います。
ただ、見出しレベルによる暗黙のアウトラインはあくまで「見出しから次の見出しまでをひとつのセクションとしてみなす」というものであるため、確実に意図した範囲がひとつのセクションとしてみなされているとは限りません。

例えば次のようなケース。

<body>
  <h1>第一階層の見出し</h1>
  <p>(1)hogehogehoge</p>
  <h2>第二階層の見出し</h2>
  <p>(2)hagehagehage</p>
  <p>(3)fugafugafuga</p>
</body>

この場合、①は第一階層に所属、②と③は第二階層に所属するコンテンツであると自動的に認識され、それ以外の解釈はありえません。
しかしセクション要素によって各見出しに所属するセクションの範囲を明示して次のようにマークアップすれば、

<body>
  <h1>第一階層の見出し</h1>
  <p>(1)hogehogehoge</p>
  <section>
    <h2>第二階層の見出し</h2>
    <p>(2)hagehagehage</p>
  </section>
  <p>(3)fugafugafuga</p>
</body>

③のコンテンツは第一階層に所属するコンテンツであることを明確に表現することができるのです。
ひとつのセクションに含まれるコンテンツの範囲を明確に定義できるのはやはりセクション要素であるので、セクション要素によって各セクションの範囲と階層を正しくマークアップした上で、各階層の見出しレベルはセクションのネストレベルに応じて適切に設定するというのがやはり理想的なマークアップであると思います。

Node.jsインストール攻略法【非エンジニア向け】

node

先日、遅ればせながらNode.jsをインストールすることにしました。
一番の理由は、タスクランナーのgulpを使いたいから。
「gulpとはなんぞや?」とかいう話は別のブログを参照してもらうとして、
これを使うにはまず何はなくともNode.jsが必要だということで、どうやってインストールするのかグーグル先生にお伺いしてみました。すると、出るわ出るわ。情報の嵐。
さすが昨今のWeb制作でもはや必須と言われるNode.js。いろんな人がいろんな方法を紹介してくれており、基本的に情報には事欠きません。

が、実に様々な方法の情報が入り乱れており、黒い画面系の知識も乏しいエンジニアでもない者がいざやろうと思うと逆に混乱し、トラップにハマりやすい状況にあります。
かくいう私も目についたものから適当に手を出してやってしまったため、結果的に何度もインストール/アンインストールしなおす羽目になり、その過程で何度も「ヽ(`Д´#)ノ ムキー!!」となるトラブルに見舞われましたので、後学のWebデザイナーさん達のためにNode.jsインストールの攻略法をまとめておきます。

今どきのWeb制作者はやっぱりMacだよね、という風潮があるので以下全てMac環境を前提としております。あしからず。

Nodeをインストールするには複数の方法がある。

まず、Node.jsをインストールする方法としては大体おおまかに次の4つの方法があると思ってください。

  1. 公式インストーラからインストール
  2. パッケージ管理ツールでインストール
  3. Nodeバージョン管理ツールでインストール
  4. パッケージ管理→バージョン管理ツール経由でインストール

どの方法でもインストール自体はできるのですが、
その後の管理等で使い勝手が変わってくるため、自分の目的と照らしあわせて最初からインストール方法を選んでおいたほうがよいと思います。以下、それぞれの方法の特長とそのメリット・デメリットを簡単にまとめます。
(※なお、各ツールの具体的な導入方法は参考サイトの方を参照してください)

1.公式インストーラ

◎Node.js公式(https://nodejs.org/
installer

GUIで操作できる唯一のインストール方法です。
通常のアプリケーションと同様、ダウンロード→ダブルクリック→OK連打のコンボであっという間にインストールは完了します。簡単・便利・楽ちん!
ただし、公式にはインストーラーは用意されていますが何故かアンインストーラーは用意されていないため、この方法でインストールしたNode.jsを関連ファイルも含めてキレイに削除するためには黒い画面を駆使する必要がでてきます。「私黒い画面とか分かんないし〜。インストーラーあるならポチればいいじゃん〜」的な感じで安易に使うと後で痛い目見ます。

【メリット】

  • とにかく簡単
  • インストールするだけなら黒い画面の知識不要!

<参考>「5分で終了。node.jsの環境構築が拍子抜けするほど簡単だったのでサンプルプログラム付きでまとめてみました【Mac編】」

【デメリット】

  • アンインストールが激しく面倒くさい
  • バージョン変えたくなった時に黒い画面使えないと軽く死ねる

<参考>「Mac OS X から Node.js をアンインストールする方法」

【おすすめタイプ】

  • とにかくできるだけターミナルとか使いたくない。
  • インストールしたらバージョンアップとかしない主義。
  • アンインストールする時のことなんか知らん。今さえよければそれで。

2.パッケージ管理ツールでインストール

「homebrew」というOS X 定番の「パッケージ管理ツール」経由で直接Node.jsをインストールする方法です。
◎homebrew(http://brew.sh/index_ja.html
homebrew

「パッケージ管理ツール」とは、Nodeに限らずUNIXの世界で流通する様々な言語やソフトウェアのインストール・更新情報を簡単に集中管理できるようにするためのツールです。イメージ的にはApp StoreのUNIX無料版みたいな感じでしょうか(※あくまでイメージです)。パッケージ管理ツール自体は複数あるのですが、Macの場合は「homebrew」というものが定番で、エンジニア初心者向けの解説書などを見ると、一番最初の開発環境構築のところで「とりあえずhomebrew入れろ。話はそれからだ。」と言われて問答無用で入れさせられるものになります。
まずは先にhomebrewをインストールし、homebrewを通してNode.jsをインストールする、という2段構えの作業となります。
homebrewさえインストールされていれば、nodeのインストールは以下の1行で終了です。

$ brew install node

ただ、ここで非エンジニアが初めてhomebrewを導入しようとした時、少々問題が発生します。
単純にhomebrew公式サイトに行って、インストール用のコマンドをコピペしただけではおそらくhomebrewは動かないのです。理由は、homebrewを動かすための前提条件があるから。

homebrewからNode.jsをインストールしたい、という場合、
非エンジニアなどが初めて挑戦する際には

1.Javaのインストール
2.Command Line Toolsのインストール
3.Homebrew 本体のインストール
4.Node.jsのインストール

というステップを順に経て、やっと目的を達成できるという状態になるので頑張ってください。
<参考>「パッケージ管理システム Homebrew

【メリット】

  • Nodeのインストール、アンインストール、アップデート、いずれも簡単なコマンドでサクッと処理できる。
  • 特に削除する時などは $brew uninstall node とするだけで関連ファイルも含めてサクッと消してくれる。楽過ぎる。

【デメリット】

  • homebrew自体を使えるようにするための事前の環境構築が激しく面倒くさい。(下手するとここで詰む)
  • 同時にインストールできるNodeは1バージョンのみ。複数バージョンの管理はできない。

【おすすめタイプ】

  • 今後のために定番のフロントエンド開発環境を整えたい。Nodeのインストールはその一環。
  • 複数バージョンのNodeを用意しておく必要はない。

3. Nodeバージョン管理ツールでインストール

homebrewを経由せず、Node専用のバージョン管理ツールからNode.jsをインストールする方法です。
Node専用のバージョン管理ツールを使うと、バージョン違いのNodeを複数インストールし、必要に応じて使用するバージョンを簡単に切り替えたりすることができるようになります。
特にNode.jsを前提とした各種開発をしていると、特定バージョンのNodeでないと動かないツールが出てきたりすることもあるため、頻繁にバージョンの入れ替えをする必要がある人には必須のツールとなっています。
Node専用のバージョン管理ツールも複数ありますが、今一番旬なおすすめは「nodebrew」というものだそうですので、これを使う前提とします。
◎nodebrew(https://github.com/hokaccha/nodebrew
nodebrew

nodebrewはバージョン管理ツールなので、基本的にバージョンを指定してNodeをインストールする形となります。

$nodebrew install-binary <バージョン>

また、インストールしただけではまだ利用できず、「このバージョンを使うよ」という宣言も必要になります。

$nodebrew use <バージョン>

homebrewでのインストールよりちょっぴり面倒ですね。
でもプロジェクトごとに使うNodeのバージョンを切り替えたいのであればとても便利な仕組みです。

【メリット】

  • 複数バージョンのNodeを簡単に使い分けできる。
  • 使い方も比較的シンプルで分かりやすい

<参考>「node.jsのversionを管理するためにnodebrewを利用する」

【デメリット】

  • nodebrewの設定で「パスを通す」作業が必須。UNIXの基礎知識が無いとキツイ。
  • 既にNode.jsが入っているとnodebrew自体がインストール出来ないので削除作業が必要。
  • nodebrew自体をアンインストールする必要が出た場合、どうしていいか分からない。。。(情報求む)

【おすすめタイプ】

  • 黒い画面の基礎知識がある。または勉強する気がある。
  • 複数バージョンのNodeを用意しておく必要がある。
  • Node王に、オレはなる!

4. homebrew→nodebrew経由でインストール

パッケージ管理ツールのhomebrewからまずnodebrewをインストールし、nodebrewからNode.jsをインストールする合わせ技の方法です。
この方法だとnodebrew自体も簡単にアップデート・アンインストール出来るので、3の方法で謎だった「nodebrew自体をアンインストールする方法」で頭を悩ませる必要がありません。
なので、「これでパッケージ管理もバージョン管理も両方出来て最高じゃない!?」

・・・・と思った方、残念賞!

この方法は、Yosemite以上の環境の方にはお勧めできません!なぜなら、
homebrewでインストールしたnodebrewではnodeを正常にインストールすることができないから!
何を隠そう、それを知らずにJava→Command Line Tools→homebrew→nodebrewと、環境構築フルコースを完走したあげく、最後のNodeのインストールでトラップにハマって詰んだのが私ですorz
もうね、ため息しか出ないですよ。ほんと。。。
ちなみに試してないですが、ネットの情報を見る限り、以前はそれでできていたようなので、
Mervericks以下なら大丈夫なのだと思います。

【おすすめタイプ】

・Mervericksから絶対にOSバージョンアップしないと誓う人

まとめ

というわけで、いろいろ試してみた結果、Node.jsをインストールする方法としては

  • 後のことはともかく、とにかく今すぐサクッと動かしたいなら「公式インストーラ」
  • ある程度後々のことも考えてバランスの良い環境を作りたいなら「nodebrew経由」

という感じがいいんじゃないかと思います。
homebrewは、少なくともWebデザイナー・コーダーがNode系のツールを使うだけならすぐには不要なのではないかと思いますね。将来的にバリバリ開発する方に回りたいならあらかじめ環境構築の一環として整備するのも良いですが、少なくともNode.jsのインストールとその管理のためだけなら無くても良いです。
時間は有限なので、活用する予定のない環境構築している暇があるなら、UNIXの基礎を勉強した方がいいです。

というわけで、非エンジニアの方はまずは「黒い画面恐怖症」を克服してみるといいと思います。
<参考>「Webデザイナーの為の「本当は怖くない」”黒い画面”入門」

フリーランスが抱くマイナンバー制度に対する漠然とした不安

mn_logo_b

いよいよ来年から「マイナンバー制度」が施行されます。
始まってしまうものは仕方ないので今更是非を問うつもりはないのですが、
原則生涯同じ番号を使い、今後様々な情報と紐付けられる可能性のあるマイナンバーをどう管理するのか、という点について
フリーランスの場合は会社員とは比較にならない大きなリスクが存在するのではないかと感じたのでまとめておきます。

▼マイナンバーの提出先が複数になる

会社員の場合、基本的に所属している会社は1つ、バイト掛け持ちのような場合でもせいぜい2〜3箇所がいいところでしょう。
しかしフリーランスの場合は、通常いくつもの取引先を持っているのが普通ですし、
新規開拓営業や紹介などによって取引先は基本的に増える傾向にあります。
(全く増えない、もしくは減り続けるのはマイナンバーとは別の意味で危機です;)

その取引先が「源泉徴収義務者」に該当した場合、フリーランスが請求した金額は相手先企業によって
源泉徴収された上で支払いが行われます。そして、来年度からは企業が源泉徴収した金額を税務署に通知する書類(支払調書)に
マイナンバーを記載する義務が発生します。

つまり、源泉徴収する取引先の数=マイナンバーの提出先の数 となるわけです。
10社あれば10箇所、20社あれば20箇所、100箇所あれば100箇所に、重要個人情報の塊であるマイナンバーを提出する必要が出てくるわけです。
新規の、1回ポッキリになるかもしれない相手であってもです。

一度提出したマイナンバーの管理は、相手に任せるしかありません。
渡した相手が法律にのっとって厳重に管理してくれる保証は、ありません。
もちろん多くの企業はちゃんと管理してくれるでしょう。
ですが、取引先の数が増えればその分、不手際をやらかす企業にあたってしまうリスクは当然上がります。

▼マイナンバー廃棄の基準が不明確

会社員やアルバイト等の場合、その企業を退職すればマイナンバーは廃棄されることが法律に明記されています。
しかし、外注先の個人事業主のマイナンバーについては、廃棄の基準が法律上はありません。
常識的に考えれば「取引がなくなった相手」のマイナンバーは保管する意味がありませんので廃棄対象になると思われますが、
「単にしばらく発注していない相手」と「今後も取引をしない相手」をどう区別するのでしょうか?
その基準は、法律上は何も明記されていないため、各企業が個別に判断するしかなく、
理論的には一度入手したマイナンバーを永久に保管(放置)し続けることも可能なわけです。
そういう企業はそもそも「ちゃんと管理しよう」という意識に欠ける可能性が高いため、
ずさんな管理により流出させてしまうリスクも高いと思わざるを得ません。

▼万が一流出してしまった場合の手続きを考えると頭が痛い

実際にはそうそう流出・悪用されるなどということは無いと思いたいですが、
上記の理由によりフリーランスの場合は会社員よりも格段に流出のリスクは高く、
フリーランスを続ける限り自衛の手段がほとんど無い状況です。
もし万が一流出したことが確定した場合、法律に基いてマイナンバーを再発行することはできます。
できますが、当然、これまで提出した各所へのマイナンバー書き換え手続きを全てやり直さなければなりません。
何十とある取引先も全てです。
杞憂にすぎないかもしれませんが、もし現実になったらクソとても面倒くさいです。

▼個人事業主への発注をためらう企業が出るのでは?

あとこれは憶測にすぎませんが、マイナンバーの管理は企業にとっても結構な負担なはずです。
従業員のマイナンバー管理は仕方ないとしても、外注先のマイナンバーまで管理するのは嫌だから、
という理由で、個人事業主への発注をためらう/とりやめる企業が出てきたりすると、商売上がったりです。
幸い今のところ私の周りの取引先からは「取引停止」も「法人成りの要求」も特に聞かれませんが、
ひそかに「フリーランスかぁ。マイナンバーめんどくせぇな」という理由で発注対象から外されたとしても
知る方法がないので分かりません。正直不安しかありません。

▼新規取引先を開拓しづらくなるのでは?

受注する側としても、これまで継続したお取引のある企業さんであれば性善説に基いて信頼することもできますが、
紹介ではない形で聞いたこともない企業からオファーがあった時、
マイナンバーのことが頭をよぎると心理的に請けづらくなるような気がしてなりません。
創業間もないベンチャー・中小零細企業、特に法人成りしたての元個人事業主あたりが
個人に発注しようとした際に「きちんと法律に基いて厳密に個人情報を管理します」ということを
相手に信用してもらわないと受注を断られる、なんてケースも出てきたりこなかったり。


そんなこんなで、フリーランスにとってマイナンバーはハイリスク・ローリターンな制度でしかないな、
という印象です。

そんなマイナンバーの取り扱いに関する不安を可能な限り払拭する方法については、また次回。

display:table-cell; の使い方まとめ

ff514934c8f52753b6f4d3600768f496

いつもコーディングセミナーを担当させていただいているサポタント株式会社のスキルアップコラムにて、
display:table-cell;を活用した「仮想テーブルレイアウト」の使い方を掲載させていただいております。
時代はそろそろflexboxだろ!!という声が聞こえてきますが、個人的にはまだまだtable-cell押しですw
(だってflexboxめんどk…)

何気に仮想テーブルレイアウトの使い方をちゃんとまとめたブログ記事とかあんまり無いような気がするのでよかったら参考にしてください!
意外とハマりがちなポイントや、ちょっとしたデザインTipsも紹介してますよ☆

詳しくはこちらへ!!!!

 ↓ ↓ ↓ ↓ ↓ ↓ ↓

コーディングセミナー開催してます

サポタント株式会社主催のコーディングセミナーで講師担当しています。
直近の開催セミナーはこちら。