YYPHP#85に参加してきました。

先週、5/24 に東京に行くついでがあったので、そのままYYPHP#85に参加してきました。

YYPHPは毎週金曜日に行われるPHPerの集まりです。

conpassでの説明文を見ると

「PHPerの部室」です。PHPについて、雑に、ゆるく、ワイワイ話し合う集いです。毎回お題を決めずに雑談を出発点にいろいろなことを突発的にやります。

とあります。IT系の勉強会などは様々ありますが、PHP限定というあたりが嬉しいところです。地元にいるとなかなか言語専門の勉強会とかはなかったりするので。

それにしても、毎週休まず開催。今回で第85回とのこと。自分でも数回、勉強会を主催させていただいたことはありますが、結局日々の忙しさに流されて1年近くもやってないので、この継続力はすごい。続けることは本当に大事!
とても素晴らしい取り組みだと思います。

内容も非常に濃いもので、とても勉強になりました。

 

以下に公式まとめがありますので、内容はそちらをどうぞ。

https://qiita.com/suin/items/7033187982e922d73934

 

個人的に気になった事を振り返ります。

WordPressでComposer使うとき、みんなどうしてるのかな?の疑問について

自分のお仕事としてWordPressに機能を追加したり改造したりするお仕事をいただくことが多いんですが、そういうときにcomposerを使いたかったりします。

が、WordPressはネームスペースとか無いので、そこにPSR-4のオートロード入れてネームスペースで管理すると、WordPressの既存関数とかfunctions.phpに書いてあるやつと、うまくあわなかったりとか、ようするに、なんか気持ち悪いなぁといつも思っていて、みんなどうしているのかな?というぼんやりした質問をさせてもらいましたが、やっぱり、index.phpとかの起点になるファイルから、オートロードして、関連するファイルとかだけネームスペース下で、WordPressのクラスとかはバックスラッシュつけて使う感じのようです。

gRPC

この話題がでたときには、自分は勉強不足のため聞いたことない言葉で「??」ってなっていたのですが、気になったので少し調べてみました。

Googleが開発したRPCのフレームワーク?ぽいもののようです。

今の所、自分の理解としては

Protocol Buffersというデータのやり取りのための構造を定義するスキーム言語というもので、リクエスト、レスポンスを一括で定義してあげて、そこからサーバサイド、クライアントサイドのコードを一式でジェネレートする感じのフレームワーク。

と理解しています。

gRPCの公式ドキュメント的なのをみると、なんとPHP向けのドキュメントもありました。

今の自分のお仕事からはあまり触れる機会はないのかもですが、興味は持てました。時間を見てもう少し学びたい。

参考

全体的に思ったこと・感じたこと

PHPerの集まりだけど、やっぱりサーバレスはみなさん気になるようでした。

また、Laravelの高負荷環境での運用とか、WordPress冗長化とか、そういうお話も沢山でした。

なんか、ちょっと前にくらべて、PHPでこんなアプリ作りました。とかそういうのじゃなくて、ウェブアプリとか作るのは当たり前で、それをいろいろな要件とか環境にあわせて、どうやって運用していくのか?
というあたりがエンジニアの腕の見せどころということなのかな。

その中の選択肢というか、実現するための、手段の一つとしてPHPがあるよね。という空気になってきていて、フロントからバックエンドからサーバ環境から広い視点で、見れたり、選択できたり、提案できるようになっていきたいなと思わせられる勉強会でした。

毎週やっているので、日程が合う日は参加しやすいし、なるべく金曜日に合わせて東京出張するようにスケジューリングしようかな。

また、リモートでの参加も可能とのこと!

ちなみに、この記事、金曜日に書いてますので、今日もあります。

 

Google Pixel Slate と Surface Pro の比較(ハードウェアとして比較)

久しぶりのブログ更新です。

昨年末から、おいらの心を騒がせている Google Pixel Slate を手に入れましたのでレビュー。

おそらく似たような立ち位置にいるSurface Pro(すこし古い第5世代ですが。。。)と、ハード面で比較してみました。

打合せや外出先での作業などに使用する持ち運び用のサブノートPCとしての視点で、大きさや重さなどを比較してみます。

サイズ・重量について

見た目的にはそれほど大きさは変わりません。
左:PixelSlate、右:Surface。キーボード付カバーを装着した状態では、PixelSlateのほうが厚い。
本体だけならPixelSlateの方が薄い。

タブレットとして使う場合は、PixelSlateの方が薄いです。
ただ、タブレットとしての使用がメインということであれば、iPad Proもありますし、タブレットにもなるノートPCという用途ではキーボードカバー込のSurfaceの方が持ち運びしやすいとも言えます。

開いた状態の大きさでは、Surfaceの方がずいぶん小さく感じます。

閉じた状態だとそれほど変わらないけど、開くと大きさが結構変わります。
スタンド部分も含めてスペースがないと作業がしにくい機種なので、この大きさの差は結構気になりますね。

キーボードを開いた状態の違い。

↑これ、個人的には大きな違いだと思っていて、Surfaceの方が打ちやすい気がします。
PixelSlateがペタンと開くだけなのに対し、Surfaceはディスプレイ下部に斜めに貼り付く。

ただ、Pixel Slateがキーボードを本体の後ろに180度回すことで、キーボードカバーをつけたままタブレットとして利用できるのに対して、Surfaceは、タブレットとして使用するときはキーボードを外さないといけません。

先程も書きましたが、タブレットとしてはPixelSlate、ノートPCとしてはSurfaceの方が使いやすい気がしますね。
あくまで個人的な意見ですが。

 

重さについて

Pixel Slate

本体 731g キーボード 486 g 合計 1206g

Surface Pro5

本体 770g タイプカバー 310g 合計 1080g

という事で、やっぱりタブレットとしてはPixel、ノートPCとしてはSurfaceのほうが使いやすい気がしますね。
PixelSlateは本体は薄くて軽いんですが、キーボードカバーが磁石で本体とくっつく感じで、おそらくその磁石が重いんだと思います。

また、これは個人的な感覚なんですが、Surfaceはキーボードカバーが本体にピタッとくっつく仕様なのですが、PixelSlateはキーボードと本体がしっかり固定しないでパカパカな感じです。
そのため持つときに、すこし気を使って持ち上げないといけなくて、なんというか、握力が必要というか、数字以上に重いなって感じてしまいます。

実際に使ってみた感想

個人的にChromebook大好きおじさんなので、ハイエンドなChromebookはとても快適なソフトウェアです。(あとで使い勝手とかソフトウェアについてもブログ書きます)

ただ、ハードウェアとして見たときには、先発のSurfaceなどと比べると、すこし改善を求むというところも多々あります。

個人的に、持ち運び用のサブノートPCとして利用しているので、キーボード込での重さや持ちにくさが気になるところではありますね。

あと、キーボードカバーが磁石でくっつくタイプなんですが、そのマグネットパワーが強力すぎて、磁石がくっつくタイプのデスクで打合せをしたときに、机にくっついて持ち上げるのに一苦労してしまったことがあります。

今回は、ハードウェアとして似た立ち位置のSurfaceとの比較について書きましたが、あまり良さが伝わらなかったですね。。

ただ、中身はとても素晴らしいので、またブログ書きます。

 

 

しばらくボーッとしてたり、Qiita書いたりしてたので、このブログを書いていなかったですが、最近はChromebook熱が上がってきてて、いろいろネタがたまっているのでブログ頑張りたい。

新潟グラム2017 Vol.1「レスポンシブ & jQuey」に参加してきました。

最近、ブログを全然更新しないので、こういうのに参加したときくらいはちゃんと書こうと思ったり思わなかったりする今日この頃な私です。
参加してきました。
https://connpass.com/event/50766/

新潟グラムは、参加2回目ですが、有料のイベントのわりに(もしくは有料だからこそ?)、たくさん人が集まりますね。
4〜50人くらいの教室がいっぱいになっていました。

最近のレスポンシブウェブデザイン対応の勘所と実装方法あれこれ

講師: 長谷川広武(´ oムo `) さん
株式会社HAMWORKS 代表取締役
https://ham.works

実は今回遅刻しての参加になってしまったので最初のほうが聞けなかったのですが、レスポンシブな案件を請けるときに気をつけること、お客さんと事前確認したほうが良いことなどをまとめて発表いただきました。

ありがたいことに、私の場合はこまかいところはざっくりおまかせでお仕事をいただいたときにも、ちゃんとこちらの判断や提案をとりいれてくださるお客様が多いので、つい甘えてしまいますが、取り決めをちゃんとやることで、制作の際に迷うことがなくなって工数がへったり余計な手間がなくなって、本来頑張るべきところに集中できることも多いと思うので、事前確認とかちゃんとやろうと思いました。

講義いただいて一番気になったところが、最後におまけ的に発表されていた

「うちはSASSでメディアクエリーこうやって書いてます」

というところ。

この後の交流会のときに、そんなに質問するほどのことじゃないんじゃね?とか言われたので、おそらく一般的なやり方なんだろうと思うんですが、一応有料セミナーってことで、見せていただいたコードをそのまま書いていいのかわからないので、ざっくり説明するけど
こんな感じでメディアクエリー書くやり方。

親ファイルで

各ブレイクポイント毎にフラグを準備

フラグ1 をtrue
 メディアクエリー1{
  ここで子ファイルをインポート
 }

フラグ2をtrue
 メディアクエリー2{
  ここで子ファイルをインポート
 }

子ファイル

if フラグ1
 いろいろ書く
if フラグ2
 いろいろ書く

という書き方。
私は、@cotentを使ったやり方でやってきたので、このやり方は新鮮でした。

小生のやり方。

/*こういうのを定義しておいて*/
@mixin media_query_pc{
    @media (min-width: 768px){
        @content;
    }
}
@mixin media_query_mobile{
    @media (max-width: 768px){
        @content;
    }
}

/*こんなふうに書く方法*/
.body{
  width:1100px;
  @include mediaquery-mobile{
    width:1000px;
  }
}

@contentを使うほうが、同じセレクタに対するスタイルが離れないので見やすいかなというのはありますが(このあと発表された西畑さんも、自分の書き方を発表してくれて、こっちは覚えられなかったのですが、たしかおなじような書き方で、同じような事言われていました)
でもIF使うやり方は、このパターンを覚えておくと、ほかのときにもいろいろと流用できそうな気がしたので覚えておこうと思います。

SASSのメディアクエリーは勝手に、@content一択だと思っていたので、他の人のやり方を見るって大事だなぁて思いました。

ステップアップjQuey -jQueryをもうすこしだけ上手に書くための10のTIPS-

講師: 西畑 一馬 さん
株式会社トゥーアール代表取締役
https://www.to-r.net

JQueryを書くときに、便利になったり楽になったり、「過去の自分のコードに苦しめられたり」しないためのちょっとしたTips集の発表でした。

実は、PHPとかHTMLとかCSSとかって、最初に触り始めたときは右も左もわからず、ネットにもあまり情報がなかった時代なので、とにかく本を読みながら体系的に覚えてきたのですが、javascriptって、昔はサイトの一部をピカピカさせたりするためのプログラムという認識で(個人的な意見)、そんなに本気で学んでいませんでした。そうこうしているうちに、jQueryとかがでてきて、ドロップダウンメニューとか画像の表示などサイトの一部をかっこよく動かしたりする流れがきて、そのままjavascriptをCSSみたくいじれるやつ。ってことで、やっぱり断片的に、「そのとき実現しなきゃいけないこと」を学んできたのみでした。

なので、よく考えると本を読んだりして体系的に学んだ事がなくて、結構自己流でやっつけちゃってるところが多いかも。。なんて思っていたので、こういう場で、一般的にはこうやってるよ。的なTipsは結構役に経ちました。

初心者向け的に発表されていたけど

  • 同じ要素にイベント仕掛けるときに、わかりやすくするためのjsプレフィックスをつけましょうというお話(固有名詞はうろ覚え)
  • 変数名の付け方 とくに jQueryオブジェクトには $をつけようとか、定数は大文字スネークケースとか
  • javascriptでの、ネームスペース風な書き方
  • 等々、実は結構ためになりました。

    大まかにみれば、自分用のノウハウのなかで同じような課題解決はしていたけど、他の人がどうやっているかとか、一般的なお作法とかって、一人で仕事しているとついつい学ばずに進んでしまうので、とても参考になります。
    おそらく、こういう気付きが、私が勉強会にでる一番の目的だと思ったり思わなかったり。

    最後に交流会と懇親会

    今回もいろいろな人に出会えました。新潟ってITの人いっぱいいるんだなぁ。。ってこういうの出るたびに思います。
    あと、個人的に感じただけなんで、実際はどうなのかわかりませんが、「最近、ここの会社なんかすげーな」っていう会社に、優秀な技術者さんがだんだん集まってきているように思います。
    ちょっと前は、他の会社だったり、フリーランスだったりした人が、だんだん勢いのあるところに集まってきているという感じです。

    そういう先頭をぐいぐい行くIT企業みたいところが新潟に増えてきたのかなぁ。。。
    新潟のIT界隈も変わっていくんだなぁ。。なんて思ってみたりしたりしなかったり。そんな交流会でした。

WordBench 富山 に参加してきました。

【勉強会】WordBench 富山 勉強会@富山市 第67回 11月26日(土)
https://www.facebook.com/events/1741536562763982/
に参加してきました。

今秋は、いろいろな方と出会いがあり、遠方の勉強会への参加が多めです。
ありがたいことです。
軽い気持ちで参加したら、20名以上の参加で会場はびっしり埋まってて、富山のWP熱すげーなってのが第一印象。
あと、開始前に会場裏の「富岩運河環水公園」ってところをフラフラ歩いてたんだけど、すっっっごくいいところで、あまりに美しすぎて謎の敗北感を感じるほど。(褒め言葉です)
WordBench富山に(参加&&会場がサンフォルテ)だったら足を運ぶことをお勧めします。

Welcartについて

WordPressのECサイト構築プラグイン「Welcart」を開発しているコルネ株式会社の南部様によるセッション。Welcartについてわかりやすく解説していただき、開発の歴史や運営の方法、セキュリティについてなど、色々盛りだくさんに解説をしていただきました。
Welcartは、たしか5年前とかそういう時期に(たしかまだバージョン1になる前)、あるお客様と一緒にWordPressでECサイトできないか検討している過程で使ったことがありました。そのときは、申し訳ないけどなかなかに使いづらくて断念しました。(そのお客様の業態とシステムがあわないってのが大きかったですが)。。そのときは結局ECキューブを選択したのですが、それがキッカケで、その後も特にWelcartと触れ合うキッカケがないままになっていました。
でも、今回お話を聞いて当時と比べてめちゃめちゃ進化しているなぁ、、、て思いました。
デモを見せてもらいましたが、もう別物ですね。今後は積極的に使っていこうと、心をあらたにして、食わず嫌いだった自分を恥じる今日このごろです。

感じた事

コアな機能は本体プラグインで提供しつつ、ウィジェットとかの見た目機能は専用テンプレートで提供してて「カスタマイズするときはこれの子テーマをつくりましょう」という姿勢や、拡張機能を専用プラグインで配布しているところ。
あとは、当たり前なのかもですが商品情報がカスタム投稿として実装されているところとか(これはデモみてるときのURL見てそう思っただけなんで違うかも)、WordPressの流儀というかそういうのに添ってつくられているので、普段からWordPressをがっつりやっている人には、いじりやすそうだなって感じました。
あと、なんというか、南部様の話しぶりとかからにじみ出てくる人柄が、「THE開発者」って感じの方で、こういう方がリーダーシップとって開発されているシステムなので、これからもどんどん良くなっていくだろうなと感じました。(なんか偉そうな書き方になってしまいました。すみません。m( _ _ )m)

よりよいコードを書く!


WordBench富山の神垣さんによるセッションでした。
静的コード解析による読みやすいコードを書きましょう。というお話。
普段から「大事だよね」とかいいながら、ついつい疎かになる「コーディング規約」について、ちゃんとやろうぜ!って内容と、ちゃんとやるための手法やツールの紹介をしていただきました。
「3日経てば他人のコード」は、自分の中で「var_dump書きたくなったらテスト書け」と並ぶCI格言にリストされました。
WordPressのコーディング規約は、1,2回読んだだけで、実際にはクォートの部分とか直接のパフォーマンスに関わりそうな部分しか守ってなかったので、(ごめんなさい・・)、ちゃんと守ろうって心をあらたにしました。というか自動チェック&自動整形ですね。Atomでどこまでできるんだろうか。。。あとで調べねば。あと、{}とかifのスペースは個人的にはどっちとも言えないなぁ。。という印象でしたが、ヨーダ記法はまさにそのとおりだと思ったので意識して取り入れるようにしたいと思います。

こういう『書き方』をちゃんとやっていないと、結局勘違いとかで無駄な時間を取られたりするので超大事。
ありがとうございます。m( _ _ )m

以上。

大勢が参加する勉強会だと、意見とかもバンバン出て活気がありますね。次回は長岡との合同開催の計画も持ち上がっているようで今後が楽しみです。

PHPカンファレンス2016に行ってきました。

PHPカンファレンス2016に行ってきました。
もうPHPer歴10年以上ですが、実はカンファレンス参加ははじめてでした。
ずっと行きたかったのですが、秋のこの時期って学校や子どもの行事が重なっちゃってなかなかいけませんでいた。

一番の印象は、人すげーいっぱいいるな。。てことです。
新潟でPHPイベントで何千人くらすが集まることってないですからびっくりしました。田舎の引っ込み思案な俺は若干人当たりしながら、それでもたくさんの知識と刺激と出会いをいただけました。

聞いてきたセッションについてまとめがてらブログに。

PHPの今とこれから2016

日本PHPユーザ会
廣川類さん

オープニング的なセッションということもあり、今回のテーマ「?>NEXT」ということで、PHPのこれから。PHP7.1とか、hhmv/hackとか、PHPを取り巻く状況の今とこれからについてお話をきかせていただきました。
PHP7は、すこしづつ使い始めています。最近はコンピュータやネットの速度がかなりあがってきているのでバージョンを上げるだけで目に見えて速度がかわる。っていう経験はあまりないですが、PHP7にはそれがあります。もう枯れた言語かとおもわせておいてこの進化。廣川さんのお話にも出てきたJITの実装など、まだまだポテンシャルを秘めていそうなPHPのこれからに夢が広がりました。

Composerプラグインをつくってみよう

中野拓さん
@Hiraku

https://speakerdeck.com/hirak/phpcon2016

実は一番パラダイムがシフトした感じがしたセッションです。
最近は、PHPのライブラリを使おうとしたら、ほぼ全部Composer経由になってきてるので、そういう意味で、ここらで一つちゃんと学ぶきっかけを。っていう軽い気持ちで聞きにいきました。
まずは、Composerプラグインの実例紹介とか作り方のポイント説明などを丁寧にしていただき、「なるほど、そうやってつくるんか。。。とか、composer.jsonってけっこういろいろできるんだなぁ。。」って言う感じで聞いていたのですが、それらを一通りお聞きして、あぁためになったなぁとか思っていたら、、、

実はここからが本題です。と、始まったのが以下の事。

  • Composerとはライブラリの依存関係解決といわれていますが、それだけじゃないですよね。
  • Composerとは曖昧だったPHPライブラリという概念を「パッケージ」という言葉で定義した存在
  • Composerは、PHPライブラリ(パッケージ)をつくるためのフレームワークであり、
  • そして、ライブラリ(パッケージ)の集合が、プロジェクトである。
  • つまり、Composerとはプロジェクトの全てを掌握する存在。

だからこそ、Composerプラグインっていろいろな事ができる可能性があるんじゃね?
という呼びかけ。

た、たしかに!!
Σ(゚口゚;

そう考えると、Composerプラグイン(Composerのscriptsプロパティも)の可能性を感じずにいられなかった。
今度Composer使うときちょっとそういうアタマで考えてみよう!!

PHP7で堅牢なコードを書く – 例外処理、表明プログラミング、契約による設計

タワーズ・クエスト株式会社 取締役社長
和田卓人

https://speakerdeck.com/twada/php-conference-2016

とっっっても大事なことだけど、今ひとつわかっていなかったり曖昧にすませていたり、ときには省いてしまったりしちゃう「堅牢なコードを書く」ってことについて、非常に明快に解説していただけた内容。
これを無料で聞けるってすごくね?っていう内容でした。

タイプヒンティング、値の制限、例外処理、そして、恥ずかしながら今回はじめて知った表明(アサーション)。など、堅牢なコードを書くために実例を交えた手法の紹介。
そして、それらを、どういうときに、どういう考えて使っていくのか?

正直、いままでは結構フィーリングでやってた事も多く恥ずかしくなってしまいました。
予防的プログラミング、攻撃的プログラミング、契約による設計という考え方にわけて、どんな局面で何を考えて、どんな手法をつかうのか?
非常に濃い解説をしていただけた気がします。

堅牢なコードを書く っていうテーマなので結構固い話だったり、怖い話だったりするのかと思っていましたが、このテーマでお話を聞いた後に「うぉープログラムすぐに書きてー!!」ってワクワクしてくるとは思わなかった。そんな価値あるセッションでした。

安全なPHPアプリケーションの作り方2016

HASHコンサルティング株式会社 代表取締役
徳丸浩

https://speakerdeck.com/twada/php-conference-2016

この日一番聞きたかったセッション。
上記の和田さんのお話とセットで聞けたので、ホントによかった。
ネットのセキュリティでおなじみの徳丸さんのお話。

PHP周りのCMSなどの脆弱性とその攻撃手法を具体的に見せていただけて、(((( ;゚д゚)))アワワワワってなりながらも、とても参考になりました。
強力な脆弱性の発見に「興奮しました」と語る徳丸さんがなんかすごく素敵。

Drupalで発見された最凶クラスの脆弱性の紹介をしてくださっているときに、「これ、ドゥルパゲドンと呼ばれてるんですが」みたいなことをポロッとつぶやいてて、それがツボって、昨日からずっとアタマのなかで「ドゥルパゲドン」がぐるぐる回ってる。

安全なWebアプリ構築のためには、脆弱性のない(少ない)バージョンの言語の安全なライブラリをつかって、防御的なコードの書き方をしていくことが大事ってことが身に染みました。

LTいろいろ

  • 家庭用ブロードバンドルータでWordPress動かすとかマニアにはたまらない試み!!
  • CodeIgniterが熱い。やっぱりこれからのフレームワークはルーティングする感じ。今までみたいにCRUDの画面遷移全部PHPでやるというよりはPHPはAPIを提供してフロントはJSとかアプリでって感じになっていくのかな?PHPの役割としては、APIとかで要求されたデータを速く、安全に、安定して返す。というあたりでしょうか。
  • レシートプリンタみたいのやつは反則www
  • Serverlessにすげー興味でてきた
  • drone.ioがモンスターボールにしか見えない
  • この日一番の笑いを巻き起こしたと思われる「一般の人が1年プログラムをやってみて・・」のLT!! 新人さんに技術教えるときの順番の参考になりました。
  • IoTやりたいな。もれそうなときに限ってトイレ埋まっているのはとてもよくわかる。
  • MySQLとPHPは同じ傷を舐め合う仲間(^^;
  • オープンソース界隈で翻訳活動されている方々には本当に感謝です
  • 厳正な抽選は、おそらくたくさんのチームを救うと思う(^^
  • やさしい規約の考え方はとても大事
  • Vagrantで満足してたけど、ほかにもいろいろチャレンジしてみるって思う
  • チームでのコミュニケーション。いいチームで仕事したい。

懇親会

この歳ですが、かなりのコミュ障なので、知らない人の中に一人でいるとしょんぼりしちゃうのですが、こんな俺にも優しくおつきあいいただき沢山の方とお話ができ、新たな出会いをいただけました。
ありがたいです。
WordPress界隈はまだまだ元気なこと。
フレームワークは、みんなLaravelになってきてる
これからのPHPはAPIとかのバックエンドとしての役割をとても期待されているのかな?
地方にも元気なひといっぱいいる。
とか感じることができました。

運営者様スタッフ様、お疲れ様でした。とてもよい知識と刺激をいただけました。m(_ _)m

あと、あきらかに普通よりもネットを使う人種の方々が何千人と集まっているのにびくともしない無料Wi-Fiスポット!!
CONBUさんもすごいと思う。

それから、会場で売ってたお弁当、みためオシャレなガパオBOXなるもの。
結局どうやってたべるのが正解だったのだろう・・ぶっかけてかっ食らったけど。
PHPカンファレンス2016ガパオBOX

【#TechBuzz】10/7 第26回HTML5+JS勉強会 in 代々木に参加してきました

東京出張での打合せがありましたので、

そのまま勉強会に参加してきました。
http://html5js.connpass.com/event/33011/
https://atnd.org/events/78125
↑これです。

まとめを兼ねて、久しぶりにブログ書きます。

Webアニメーションについて

川上 和義さん(@saruyama_monki)

ディズニー社で培われてきたというアニメーションの基本原則12の紹介をWebアニメーションで実装するとどんな風になるのか?という内容を、実際に作成してCSSアニメーションの実例で見せていただき勉強になりました。
アニメーションの要望は高まっているように感じていますが、ついついJS側で実装してしまうのですが、メンテナンス性とかを考えるとCSSアニメーションでできるものはCSSで実装する方がいいのかもな。と考えを新たに。本腰をいれて勉強せねば。

HTML/CSS3のイマドキコーディング技術

ICS 鹿野壮さん(@tonkotsuboy_com)

フロントエンドの前線で仕事をされている鹿野さんによる「フロントエンドの技術は数年前のをそのままやっていると、作り手にもクライアントにもよくないので、新しいものを学びハッピーなフロントエンジニアライフをおくりましょう」的な講義。8つのあるあるネタを元に現場ではこういうのをやっているよという内容を教えていただきました。
中でも、古いブラウザ対応についても、現在はモダンブラウザがかなりのシェアをもっているので古いIEやベンダープレフィックスなどはある程度なくしていってもいいのでは?という呼びかけに、たしかにそうだよね。頷いてしまいました。

あと、「知らんかった・・・(汗)」ってなったのが、imgタグのsrcset属性について、これWordPressなどでもimgタグを出力する関数つかうと普通に実装されているので、HTML5で勧告済みなのかと勝手に思っていましたが、HTML5.1の仕様なんですね。まあsrc入れてるので互換性には問題ないですが勘違いでした。(ちゃんと調べてから使おう!)

さらには、講義後に鹿野さんと名刺交換させていただいたときにその話をさせてもらったんですが「あのエスアールシーセットってぇ・・・」て話したら「ソースセットね」ってやんわり訂正されて超恥ずかしい。。。(TT)
一人でやっていると、文字での情報は勉強できるけど、周りに普段から会話でやり取りできる人がいないのでコーディング周りの 「読み方」 は鬼門です。

全体的に、Flexboxとか普段から使いたいけど古いブラウザ的にどうだろう・・・という踏み切れない気持ちを強く後押ししてくれる講義でした。

名刺交換タイム

最後に名刺交換して交流を深めるタイムみたいのを設けていただいたので、フロントエンド界隈の人々と情報交換ができて知識と刺激を沢山いただいてきまいた。
なかでも、話題にでたのが「sass+compass」ってどうなの?というお話がホットでした。

  • compassをつかうとベンダープレフィックスを書かなくていいけど、コンパイルされたCSSにはもういらないようなベンダープレフィックスのズラズラついちゃうからスマートじゃない?
  • compassを使っていても、主にCSS3関連のベンダープレフィックスを省略できることくらいしか使わない?
  • どうせgulpとかのタスクランナーも併用するんだから、いっそのことsass+Autoprefixerでいいんじゃね?

というあたりの意見が交わされました。

これらは確かにそうかも。と思わせられて、これから検証していきたいと思いました。

トーキョーはこういう熱い勉強会がたくさんあってうらやましい今日このごろ。

ちなみにこの記事、高速バスで新潟に早朝に帰りついたはいいけど、家の鍵を持って出るのを忘れてしまい家には入れないので、しょんぼりしながら市内のコワーキングスペースcodeforで書いたことはヒミツです。

ScotchBoxにLaravelをインストールする

VagrantのScotchBoxにLaravelをインストールしようとすると、composerでエラー。

The following exception is caused by a lack of memory and not having swap configured
Check https://getcomposer.org/doc/articles/troubleshooting.md#proc-open-fork-failed-errors for details

みたいな感じ。
調べてみると、メモリがたりません。ってことらしいです。
ScotchBoxはUbuntuなので、Ubuntuにスワップ領域を追加する処理をします。

Ubuntuでスワップ領域を確保してcomposerでLaravelをインストール

Laravelをインストールする前に、下記のコマンドを実行します。

スワップ用ファイルを作成

$ sudo mkdir /var/swap/
$ sudo dd if=/dev/zero of=/var/swap/swap0 bs=2M count=2048
$ sudo chmod 600 /var/swap/swap

スワップ領域の割り当て

$ sudo mkswap /var/swap/swap0
$ sudo swapon /var/swap/swap0

サーバ起動時に自動的にスワップを割り当てるように処理

$ sudo vi /etc/fstab

最後に一応スワップの状態を確認してみる

$ sudo cat /proc/swaps

上記を行ってスワップ領域の設定が完了したら、あとは通常通りLaravelのインストールが行えるはずです。

$ composer create-project laravel/laravel --prefer-dist

以上です。

参考はこちらでした。
http://qiita.com/scleen_x_x/items/f3fc492bcbf0f6c2896c

Vagrant+Scotch Box にphpMyAdminをインストール

VagrantでPHP開発環境をつくりたいんだけど、最低限PHPとMySQLが動けばいいくらいであとは細かいことは気にしなくていいって、感じの軽い開発のときに、そういう環境がさくっと立ち上げられるScotchBoxが重宝しそうです。
PHPとか新しいバージョンのがはいっているのでLaravelとかも動きます。
ただ、phpMyAdminが入っていない?のか見当たらなかったので、ScotchBoxの立ち上げから、phpMyAdminのインストールまで。

これで、PHPとmySQLが動いている「とりあえずなPHP開発環境は揃うはず」

参考にさせていただいたサイト

Scotch BoxをインストールしてphpMyAdminを動かす

  1. 任意の場所で
    git clone https://github.com/scotch-io/scotch-box.git <フォルダ名>

    これで、フォルダ内に必要ファイルが入ります。

  2. 上記のフォルダを見ると、「Vagrantfile」とうファイルがあるので任意で編集。
    Vagrant.configure("2") do |config|
    
        config.vm.box = "scotch/box"
        config.vm.network "private_network", ip: "192.168.33.10"
        config.vm.hostname = "scotchbox"
        config.vm.synced_folder ".", "/var/www", :nfs => { :mount_options => ["dmode=777","fmode=666"] }
    
    end
    

    上記でいうところの

    config.vm.hostname = "scotchbox"
    

    scotchbox がホスト名になります。私のChromeだと、アドレスバーにscotchboxとだけ打つと検索しにいってしまうことがあって不便だったので、scotchbox.local みたいなアドレスっぽい名前に修正しました。

    config.vm.synced_folder "."・・・・
    

    の “.” がローカルの作業フォルダになります。通常は、上記でcloneしたときに作ったフォルダの中にpublicていうのができててそれが作業フォルダになります。ここを変えると作業フォルダを変更できますが、ここで指定したフォルダの中にpublicというフォルダができてそれが作業フォルダになります。
    例えば、

    config.vm.synced_folder "./www/"・・・・
    

    としたときには、wwwフォルダのなかのpublicフォルダが公開フォルダになります。
    そのままのほうがわかりやすいかも。

  3. あとは
    vagrant up
    
  4. で、環境が立ち上がって先ほど決めたホスト名でのアクセスを確認できたらphpMyAdminのインストールをします。
    まずは

    vagrant ssh
    
  5. ScotchBoxのOSはUbuntuなのでphpMyAdminインストールは
    sudo apt-get install phpmyadmin

    インストール中にいろいろ聞かれますが、
    Webサーバーはapachを選択。
    Configuring phpmyadmin は「No」
    ・・・
    でインストールは終了しますが、このままだと<ホスト名>/phpmyadmin でアクセスできません。

  6. Ubuntuの公式にしたがって
    sudo ln -s /etc/phpmyadmin/apache.conf /etc/apache2/conf-available/phpmyadmin.conf
    sudo a2enconf phpmyadmin
    sudo /etc/init.d/apache2 reload
    

    これでOK。
    <ホスト名>/phpmyadmin
    でphpMyAdminにアクセスできたら成功です。

  7. ちなみに、ScotchBoxが最初から準備してくれているDBへのアクセスは
    ユーザ名:root
    パスワード:root
    です。

以上、まあようするにUbuntuへのphpMyAdminのインストール方法なんですが、まとまった情報がなかったので
まとめ+備忘録を兼ねて。

アドレスが少し変わりました

すでにお気づきかもしれまんが、当ブログのアドレスが少し変わりました。
といっても、各記事のアドレスはかわりません。

ブログトップページのURLが、
https://www.katacom.jp/
から
https://www.katacom.jp/a/

に変更になっております。

ドメインルートには、私が個人的に営んでいる事業のサイトが表示されております。

引き続き、当ブログも(なるべく)更新していきたいと思います。

今後とも、何卒よろしくお願いいたします。

m(_ _)m

CSS Nite新潟版Vol.4 に参加してきました。

6月6日に開催された、「CSS Nite新潟版Vol.4」 に参加してきました。

http://cssnite.jp/niigata/vol04/

いろいろと学べる事が多い会でしたので、まとめを。

初参加ですが、思ったよりも大きな会場で、なおかつ人もたくさん集まっていて新潟って、Webをやっている人たち、いっぱいいるんだなぁという印象でした。

丸山純一郎さんのセッションの中で(みんなの共通認識として)言われていましたが
「お客さんが何のためにホームページをつくるのか?それは売上を上げるためですよね」
ってことと同じように、CSS Niteに集まった人たちも、やっぱり何のためにこういう会に参加するのか?というと最終的には自分たちの売上を上げるためなのだと思います。
Webをやって飯をくっていくために・・というか。。

だから、よりよいものを作るため、よりよい仕事をするために知識を深め、技術を磨いており、そのために勉強会などに参加しているわけです。

そう考えた時に、
鷹野雅弘さんのセッション「Illustrator+Photoshop最新テクニック」と松田直樹さんのセッション「これからのWebサイト設計〜CSSフレームワークでつくるマルチデバイス対応サイト」はWebデザインをしていくなかで、とても実のある内容でした。お二人のセッションから、Web制作のなかで「作業」をどうやって軽減していくか?いつもの作業を「変数化・関数化・自動化」していくことで製作者の作業をガサッと減らす方法をデザインとコーディングの部分で学ばせていいただけました。
なぜ作業を軽減するのか?については、講師の皆さんが言葉は違うけど触れておられたように、「作業を軽減して、その分ちゃんと考える時間を作りましょう。」ってことですよね。
普段一人で仕事することが多いので、つい、いつもの慣れた方法に落ち着いてしまうことが多いのですが、毎回ではなくても、ちょっと余裕のあるときに、学習コストをかけてでも、新しい環境や新しい機能、Tipsを取り入れることで、その後の作業が格段に楽になることがありますが、そういうことのキッカケとモチベーションをいただけました。

つくったサイトが、ちゃんとお客さんのお役に立てるように、設計にアタマをつかう時間の確保していかねばなりません。

また、つくるだけでなく、つくったものをどうやって運用していくか?
小杉聖さんのセッション「成果を重視したウェブ活用の基礎体力がつく資格・ウェブ解析士 〜テレビショッピング的な5分間〜」で、小杉さんが言われていたように、アクセス解析の数値を、Webの体温や血圧のように見る。って言葉たとても印象的で、単純に訪問者・閲覧数が増えたねとか減ったねっていう話ではなく、、設計段階で目的がしっかりしたサイトをつくるからこそ、それがちゃんと活かされているかを、測るための数値として見ることができるんですよね。

Webで良い仕事をするためには、作ることが目的ではなく、設計と運用が大事になってくるし、そこをちゃんとやらないとこれからは「おまんま食い上げ」ですよ。という中で、地方でWebをやっていくヒントとなったのが丸山純一郎さんのセッション「Uターンして実感する地域格差、Web事業をどう展開していくか?」でした。
いきなりお客様に難しい事を言っても話が噛み合わない。だからこそ設計→制作という流れではなく、あえて、まずは制作。そしてつくって動かしたものをちゃんと検証して、それを元に改善していくなかで「設計」していく。
「設計→制作」ではなく、あえて「制作→設計」という流れをつくる。
というのは、実際に普段の仕事の中でとても共感出来る内容でした。

田舎での仕事は、Webについて(というかIT全般について)詳しくないお客様がほとんどですから、いくら技術がありますという話をしても、お客様にはピンと来ない。
そういうときに活きてくるのは、やっぱり「信頼」だと思うんですよね。
我々はWebの知識や技術は持っている。でもそれを100%活かせるシーンてなかなかないのですが、お客様から「信頼」をいただけて、「お前がやるなら全部まかせるよ」と言ってもらえて仕事ができたら、大変だしプレッシャーもあるけど、ただ、自分の知識や、また周りの人の協力も全部つかって全力で仕事できるわけで、一番幸せで楽しい仕事なんじゃないかと思うのです。
そういうために、まずは「制作」って事だと思ったのですが、この制作の時にはやっぱり「デザイン」が実際問題として大事になってくると思います。
「制作」において、お客さんにいくらWebマーケティングや顧客動線の話、ましてやCSSやらJavascriptの話をしても通じませんから、実際には「ぱっと見」の「おぉ!」って感激が大事になってきてしまうんですね。

本来のデザインが持つ目的とずれた話になりますが、お客様に提案していく中での現実問題として、やっぱり「制作→設計」の流れの中で、お客様にまずはつくってみましょう。という言わせるためのポイントとして「見た目がかっこいい!うちのサイトこんなにすごいのになるの!」という感動があるかどうか?は、やっぱり現実問題として、最初の提案が通りやすいかどうか?に大きく関わってくるってのはあると感じています。

原一浩さんのセッション「Webデザイントレンド:キャプチャで振り返る2014-2015年の潮流」は、その資料の膨大さに度肝を抜かれたというか、なんかすげーって圧倒されながら見てたのですが、カッコ良い・キレイなサイトには、一つ一つのパーツにやっぱり時代とかお客様の環境の変化の中で、ちゃんとした意味があって、それを適切につかうこと。松田さんのセッションで醤油差しの話がでてきましたが、機能性と見た目の美しさってのはやっぱり同じ方向を向いているんだな。と感じさせられました。
あと、デザイントレンドを追っていくことで、世界中で試されているABテストの結果を手に入れることができる。ってのは、一朝一夕でできることではないけど、とても腑に落ちる表現でした。
そして、早速活かされている人がいてとてもためになりました。^^
http://dtp.jdash.info/archives/Hamburger_Menu_Test_2014
こういう風に他の方が復習してくれるのって、とても勉強になりますので、ネットっていいなって思います。

同じくCSS Niteに参加されていて、懇親会でお話させていただいた方が
http://mikubell.tumblr.com/post/121096042197/css-nite-2
という記事を書かれていますが、まさにその通りで、また逆に言うと、エンジニアもこれからは「デザイン」の領域まで入り込んでいかないとだめですよ。ってことだと思うのですが、やっぱり「全体」が見渡せて制作できて、デザインもコーディングもプログラミングも全部わかる人がいて、そこからパーツに落とし込めるか?ってことが
ないと、ちゃんとした成果のでるWebに辿りつけないのかな。。そういうところを目指さないと何も残らないなと強く思います。

エンジニアは、デザインの領域(とくに見た目よりも顧客の動線や感じ方などロジカルな部分)。
デザイナーは逆にエンジニアの領域に踏み込み、よりロジカルで「説明できる」・・・のは当たり前で、さらに一歩上を行って、ロジカルでなおかつ感動というかこころを動かすデザインをつくっていく必要があると感じました。

・・・

こういう会に参加させてもらう意義は、新しい知識や技術を手に入れるということはもちろんですが、すでに(明確にでも、潜在的にでも)わかっていることでもしっかり再確認できて、その上で、よしやるぞっていうモチベーションを上げていける。って事が大きいと思います。
いろいろな方と出会えて、お話ができて、そういう意味ではとても有意義な会でした。