※スマホ対応はしてません。

「現場のプロが教えるHTML+CSSコーディングの最新常識 知らないと困るWebデザインの新ルール4」という本を書きました。

カテゴリー: Web, 拙作

気が付けば五月、大型連休も終盤です。は、は、早いものですね……!!

さてさてTwitterの方では何度か言及してきたのですが、三月末に著作が販売となりました。単著ではなく、こうめさんこと大竹孔明さん @Bamboo_C、小川裕之さん @barchin、中江亮さん @brdr_slash (書籍署名掲載順)らとの共著です。

event
最後の方に記念イベントの講習会みたいなやつの紹介してるので良ければご覧くださいまし。

こちら皆さんの執筆報告記事です。(こっちは公開日時順)

どーんとアフィも貼っておきます。みんな! 買ってくれよな!

内容

(さらに…)

理想的な一日の流れを考えてみたんだけど、24時間って、やっぱり少ないなあ……。

カテゴリー: 日記

最近就寝時刻が後ろへずれがちなので修正したいと思い立ち、せっかくだしじゃあ何時に寝たらちょうど良いの?というところから考えてみた結果、一日の理想の流れはこんな感じになりました。

時刻行動備考
06:00起床、朝食早起きする理由は不明
07:00ネットメールチェックとか
08:00
09:00仕事今日もぞい
10:00
11:00
12:00昼食
13:00ネット
14:00仕事
15:00そろそろおやつ
16:00
17:00
18:00
19:00夕食
20:00趣味え、短い……
21:00
22:00就寝八時間睡眠
23:00
00:00
  • 妄想なんで、この日程で活動してませんから!
  • 睡眠八時間、労働八時間。するとその他八時間。
  • 朝昼のネットは技術の話題をおっかけたりというのを想定している。まとめサイトとかじゃないよ! すると仕事に入れても良いかもしれない。(というか仕事の途中でもそういうの見てるな。)
  • 理想の睡眠時間は7.5時間と聞いた。短くなっても長くなる事はないだろうと思うので、8時間の予定でちょうど良いのでは。
  • 通勤時間なんかは含まれていない。

ネットの時間はもっと削っても良いかもしれない。仕事に入れてもいいし、あるいはこれが趣味といっても良いかも。

早起きは三文の徳か?

なんとなく早起きは格好良いかなーくらいの気持ちで起床時間を設定した。でも別に早起きする利点があまり思いつかない……。

実践した経験から言うと、特に冬場は陽が昇って気温が上がってから行動し始めた方が効率が良い気がする。低血圧気味なもんで。

早起きのコツ……

教えてほしい。

まず早く寝る事が大事だと思うんだけど、幼い頃から寝付きが悪かったので、もはやどうにもならないのかな。どうしたら良いのかはよくわからない。暖かい飲み物とかはあまり効果がなさそう。

瞑想は良かった。でも利かないときは利かない。

冬場に起きる方は、電気毛布にタイマーを仕掛けて、起きる頃にはほっかほかーてなのにすると目覚めがさっぱりする。体が暖かければ布団から出る勇気もそんなに必要ないしね。

タイマーはこれを使っている。(アフィだよ。)(ヨドバシカメラの方が安いよ。)

十五分単位で指定して、オンにしたりオフにしたりできる。一度設定したら毎日そのまま使い続けられるのが良い。ちょっとでかいけど便利っぽい。

夏はどうしたら良いかな。

仕事しないのが最強っぽい

それを言ってはいけない。

「フロントエンドエンジニア養成読本」を読んで、エンジニアになってよ!

カテゴリー: CSS, JavaScript, Web

著者の方々から頂いておりましたので、遅まきながらご紹介さして頂きたいと思います。

(すみません、半年近く経ってしまいました……。)

概要

  • ウェブのクライアント側の濃い技術がたっぷり
  • UXの話からブラウザーの仕組みまで
  • 難易度は高め、だけどそこまで高くはない
  • 全てを理解できなくても、勉強の指針として目次を頭に入れておくと良さそう
  • ツール解説は特になし
  • 「10年先も役立つ力をつくる」は本当だと思う

    (さらに…)

「Web製作者のためのGitHubの教科書」は非技術者におすすめの本です。

カテゴリー: 開発環境

著者の一人、平木聡さんから頂いてましたので、紹介させて頂きます。

GitHubは年中無休なので、お正月に本書を読みながら諸々を試しておくと、新年の業務がスムーズになるんじゃないすかねー。

概要

  • GitだけでなくGitHubだけの機能も紹介
  • GUIアプリ(SourceTree Win/Mac)とコマンドラインとの両方で作業を解説
  • 画像多数、ちなみに総天然色
  • 言い回しや書体、図解が読みやすい

    (さらに…)

JavaScript設計の世代と近未来の話。(JavaScriptおれおれAdvent Calendar 2014 – 24日目)

カテゴリー: JavaScript

JavaScriptおれおれAdvent Calendar 2014 – 24日目

個人的に、こんな感じで認識してますって話。書くにあたりあんまり精査してないので勘違いありそう。やさしく教えてください。

もちろん個々人では先取りしてあれやこれややってる人もいて、そういう人たちは特に今でも第一線で頑張っているように思う。

原初

  • 設計なし
  • DHTML (Dynamic HTML)
  • NoScript

設計なしに書いていた時代。

もちろん個別のアルゴリズムとかはあったんだけど、アプリケーションというよりはウィジェットとかそういう規模のもの。

あれよあれ、マウスカーソル追っかけるやつとかそういうの。もちろんまともに考えられたものもあったけど、少数派。JavaScriptといえば「よくわからない派手で邪魔なもの(を作るやつ)」という認識。ブラウザーの設定やプラグインでスクリプトの実行を停止している閲覧者も少なくなかった時代。

中にはJavaScript偏重のウェブアプリケーションもあった。そういうのは設計されていたけれど、他の世界(だいたいJava)の世界観をそのまま持ち込んだみたいな感じだった。

第一世代

  • 模索中
  • DOM, jQuery
  • Ajax
  • hashchange, Hash Bang

Ajaxバブルの時代。(なんだそれ。) 気取って「モダン」とか言い始めた頃。

HTMLを動的に操作

jQueryの出現及びAjaxの発見により、画面を動的に変化させるという発想が広まった。よくわからない派手な動きから、堅実で便利なUIへ。

それに従いウェブアプリケーションのクライアント側の比重が大きくなる。ここでクライアント側の設計という作業工程が発生。

リッチでモダンな素敵アプリ

モダンなウェブアプリのはしりはGoogle Maps(2005年)。実際はAjax(XHR)ではなかったが、画面表示後にサーバーと通信して情報を更新するというパターンが大流行。設計しよう、ないとしねるっていう気になってきた。

またURLフラグメント識別子、いわゆる「ハッシュ」を操作して画面状態をURLに保存できるようにもなった。後のHistory APIへの系譜。全ページで共通のリソースを用い、URLから判断してクライアント側で画面を構築する。SAP: Single Page Applicationの始まり。

手探り

とはいえ、設計としてはまだ手探り。各人で諸々設計して実装していて、それぞれ妥当性はあるんだろうけど、共通認識としての設計パターンはまだ構築されていなかった(あるいは普及していなかった)。

第二世代 ←イマココ

  • MVx
  • HTML5, CSS 3
  • エンジニアリング
  • 黒い画面
  • 試験
  • 携帯端末

フロントエンドエンジニアの台頭、エンジニアリングの推進。

要求の肥大化

HTML5でJavaScriptでできる事が圧倒的に増え、CSS 3で表現の幅が飛躍的に高まる。その分要求も大作志向に。

設計しないとしねる。

MVx

AngularJS(2009年)あたりがなんだかんだで中心となって設計の共通認識が進む。MVCとかそういうの。

Ruby on Rails(2004年)もサーバー側でMVCとか言ってたのも含め単語の混乱が起こる。「お前のMVCはMVCじゃない」みたいな言説が乱立。結局何が真のMVCなのか未だによくわかんないや……。

黒い画面

設計の必要性が認識されたあたりで、HTML以外の言語出身のガチ勢(要はプログラマー)が増えてくる。良い開発環境作りに腐心。タスク実行、パッケージ管理、リソースの結合と縮小、

様々な便利ツールが出現し、黒い画面を前にPhotoshop出身のJSerが悲しい顔をするようになる。

試験環境も整備がすすみ、試験のないライブラリーはすべからく地獄の火の中に投げ込むべしみたいな風潮。熟知すべし。

エンジニアリング

CSS 3で視覚表現が豪勢になった分マシンパワーを要求するようになり、ちゃんと動くよう調整する必要が出てくる。ので、開発者ツールを使って重い処理を検出したり描画コスト高い箇所を判断したり。

第三世代

  • Web Component
  • カスタム要素
  • Virtual DOM
  • Worker

来たるべき近未来。

認識間違ってる可能性が他の項より高いのでアレなら教えてください、やさしく。

カスタム要素

勝手に好きな要素を作れる仕組み。

例えばタブUIとかそういうのは全部カスタム要素にして、それぞれの画面用の情報(タブのラベルとか本文とか)を与えて画面に出すっていうのができる。

雰囲気はjQueryプラグインみたいに「作る人」と「使う人」に分かれそう。

Virtual DOM

高速に画面更新するための、裏側の仕組み。内部的にはModel-Viewに分かれていて、Model変更時のView更新を最小限に抑える事で描画を高速化する。

MVxでは視覚情報と論理情報を綺麗に分割していたが、逆に結合してひとつのモジュールとして管理し、モジュールを組み合わせて大きなモジュールを構築する。

物理と論理が小さく結合しているあたり、カスタム要素と相性良さそう。

Worker

非同期に処理を行う仕組み。処理時間が長くなってしまうものをバックグラウンドで実行する事できる。

Workierからは諸事情によりDOMを触れないけどVirtual DOMなら触れる、てのはどうでしょう。あんまり関係ないか。

頑張ろう

最後雑になった。全体的に色々省略しました、短い方が良いかなって。

しかしやっぱり未来予測とか無理だ……。