読者です 読者をやめる 読者になる 読者になる

やまろぐはてな

yamanokuの技術メモ。Qiitaは怖くて書けない。

フロントエンドエンジニアってどんな生き物なのか

戯言 フロントエンドエンジニア

f:id:cardboarder:20170226213138j:plain

こないだ他業種(SE)の人と偶然呑む機会があって、自分の同僚が「MEをやってます」って伝えたんだけど「MEってなんですか?」と返されました。

弊社ではマークアップエンジニア=MarkupEngineerの頭文字からそれぞれとってMEと略されて「MEチームの皆さんは何か有りますか」などと聞かれている。この辺は独自文化っぽいので分からなくて当然かなとは思いました。

と「マークアップ」の話をしてみても結局何をやってるのかと聞かれてしまいフロントエンドとバックエンドという部類があって、前者から枝分かれしているのがマークアップエンジニアことMEです、みたいに説明しました。(以下引用)

  1. バックエンドエンジニアとは、単一の環境、つまりサーバ上で仕事をする人のことを指します。彼らは、新しいソフトウェアをインストールしたり、ハードウェアをアップグレードしたりするなど、環境を変更する権限を持ちます。
  2. フロントエンドエンジニアとは、全く異なる数えきれないほどの環境で仕事をする人のことを指します。最新のデスクトップコンピュータから3年落ちのものだったり、メモリが少なく処理に時間がかかるような古い電話だったりと様々です。彼らは、ユーザのブラウザに対して何もすることができないため、その環境を変更することができません。それでも、すべての環境で動作するコードを作る必要があります。

http://postd.cc/front-end-and-back-end

この辺は同じエンジニアという分類で括ってあげることでだいたい理解してくれましたが、たとえば親のような仕事でもパソコンに触れる機会が全くない人間にどう伝えるか、というのが最近悩ましいということがあります。(めんどくさいのでwebサイトを作る仕事やっていますと伝えてます。そんなもんじゃないでしょうか)

いわゆるフロントエンドエンジニアって範囲が広義すぎるから何をもってして従事できているのかが正直分からんのが実際のところで、明確な身分証明みたいなものも免許みたいなものもないので人に説明するのはなんか難しいねという感じです。

あと人によっては見栄などで大した技術もないのにプロのエンジニアですみたいに経歴詐称したりする世界らしいのでそのへんも厳しいです。

逆に言えば自分たちの業種からみたシステム、インフラ、バックエンド側って具体的にどういう仕事してるんだみたいに思う人間が多いんじゃないかとは思う(そもそもデザイナーの業務もあまり分かってないというのはあると思う)。歩み寄りをすることを怠ってはいけないなとは感じます。

久々の更新でしたが特にオチはないです。写真には特に意味はないと思います。

初心者にGit教える時に必要最低限のCUIコマンド

git 初心者

f:id:cardboarder:20170116221632p:plain

前提条件

ガチ初心者でgitの操作をCUIで学ぶため、基本1人でmasterで作業するという「いやお前それGit管理じゃないだろそれ」という前提でやってもらます。いいんだよ細かいのはこれから学んでいけば。

作業前にリポジトリとかはどこかで作って置いたほうがよい(Github、Bitbucket、backlogなど)。

必要なコマンド群

リポジトリのクローン ... gitを使う設定

git clone https://xxxxxxxx/xxxx.git

※この時もしかしたらログインIDやパスワード聞かれるかもだが、気にせず入力してください

作業ファイル全追加 ... 作業したファイルを保存

git add -A

コミットメッセージ ... 何の作業をしたかの記録

git commit -m "commit message"

プッシュ ... サーバーにアップする

git push

プル ... 人が作業した分を同期・ダウンロード

git pull

右のはあくまでもそうした意味ではなく、イメージ。だいたいこれで足りる。自分は足りた。

cloneした後に「作業 → add → commit → push」を基本ローテーションとして作業。

必要に応じて他の初心者を入れて同様に作業させて、pullを理解してもらう。コンフリクト起こしたら、その時は都度修正、コミットなどしてくれ。

基本の骨組みはこのイメージでいいのではないか

実際Gitは様々なコマンドがあったりフローが存在して、いわゆる「ちゃんと理解できたらちゃんと使える」代物とも言われてるので、使いこなすにはある程度知識や経験が伴う。

とはいえ自分がやってきた中では基本このイメージさえできていれば、後はそれに付随する肉付きをしていけばいいんじゃないかと思っている。

たとえば作業でpushまでしたけど実は違ったものが最新になっていたのでそれを直すというのがあった際に、上記コマンドであれば作業後に再びadd、commit、pushなどをする一連の流れがあるわけだが、そのままだと煩雑なコミットログになりかねない(別に慣れる間であれば気にしなくて良いのだが)

そのためにgit revertだったりresetだったりcheckoutというコマンドが調べて出てくるのだが、そうした時に学んでいけばいいんじゃないかとは思う。

それなりに親切なGit

あとGitは丁寧なので、たとえば新しくブランチを切って作業して何も考えずadd、commitしてpushすると「リモートにそんな追従ブランチねーよ」と教えてくれて以下のコマンドを提示してくれます。

git push --set-upstream origin branch

アメリカ語だけど頑張って訳せばそれなりにちゃんと教えてくれてるんだというのがわかる。なので極端に怖がらなくてよいのだ。

極端な言い方をさせてもらえば、やり方次第でなんとかなるのがGitである。

Git教育について知見が欲しい

ウチではこうやってるよ的なのを募集しています。

こちらからは以上です

wordpressの組込みをするときに思うセクショニングの話

wordpress html5 html W3C サイト運用 品質管理 セクション

みなさんセクショニングマークアップしてますか

f:id:cardboarder:20161226223136p:plain

してない人は正直に手をあげなさい。先生は怒らないので。

最近html5.1の勧告がありましたよねという話で

前置きはどうでもいいんですが、セクショニングでは個人的に気になっている点があります。

【HTML5.1勧告】セクション要素内見出しレベル仕様の変更について | とあるコーダーの備忘録

つまり、どうやら以下の様なことができなくなってしまうとのことです

<body>
<h1>見出し 1</h1>
<section>
<h1>見出し 1</h1>
<h2>見出し 2</h2>
</section>
<section>
<h1>見出し 1</h1>
<h2>見出し 2</h2>
</section>
</body>

いや、もとからそういう書き方はvalidationでエラー吐くよとはありましたが、MDNでは上記書き方が正しいよと載っているんですよ。

見出し要素の順位 (例では、最初のトップレベルセクションのためのh1、サブセクションのh2、および、セカンドトップレベルセクションのためのh3 ) は重要ではないことに注意してください。明確さを失いますし、推奨しませんが、どんな順位でも明確に定義されたセクションでの見出しとして用いることができます。

どっちやねん。

ところかわってwordpress組み込みの話

上記のことを引っ張った上で本題。

wordpressで組み込みがある際にページを作るときは固定ページを元にして作成するなどあるとは思いますが、ニュース記事などの記事作成時にみんなどういう風に捉えているのかということが気になってます。というのも…

記事作成時の「見出し」をどうしているのか

f:id:cardboarder:20161226082959p:plain

wordpressで新規投稿をするときにこのような画面に遷移します。この時に「段落」プルダウンを押すと段落。見出し、整形テキストが選択できるようになります。

この時に見出しを選んでそれぞれ入力してソースを見るとこんな感じで出力されます

f:id:cardboarder:20161226083336p:plain

これと上記HTML5.1のセクション要素の仕様変更と合わせるとまあまあややこしい話ですよねと思います。

つまり大見出しを書く時にh1が存在してしまい、他の部分でh1を使っていると(ロゴとか)セクショニングがややこしい判定になるんじゃないのかということ。

人はそうそうセクショニングを意識できない

今まではこの投稿記事自体にarticle要素なりsection要素で囲めば外とは関係なく使えてたのですが、それが今後効かなくなるとなると元々の組み方を変えねばならんよなーとなってくる。

一番僕が懸念しているのは、運用を非エンジニア職の人に渡してしまうとそこはもう魑魅魍魎と化したブログ記事が出来てしまうわけです(br改行が大量に挟まってたりとかね)。そんなん気にするなよってのはあると思いますが、僕は出来る限りゴミみたいな中身を増やしたくないとは思っている。

かといって人の書き方を制約してしまうというのもあってはならない話だし、この辺の話はブログサービスなりを作っている中の人にどうしているのかを聞くのが一番早いと思う。どっちかというとアメブロとか楽天ブログとかのよりエンジニアとはかけ離れたところの。

現状考えうる問題解決案

と書いてはみたものの現状でうまい回避策は見当たらないです。苦渋の選択として、

よい回避策を募集しております。こちらからは以上です

あと関係ないかもですが投稿画面でタグ自動生成しないやり方もあるようなのでシェア―です

webkikaku.co.jp

社内分報 ver 2.0について

分報 品質管理 作業効率

みなさんこんにちは今日はSlackでの分報(ぶんぽう)について触れてみます。

おさらい

yamanoku.hatenablog.com

分報分からん人向けに言うと、1日のことを報告する日報を分刻みレベルで今何しているかをSlackとかのチャットツールで自分用のチャンネルを作って報告するというもの。(詳しくは以下を御覧ください)

c16e.com

手間だろとはいうのは確かにありますが、今その人がなんの作業をやっているかという可視化と、不安点や疑問点を書くことによって問題点の洗い出しができたりと、業務する上で分からなかったことが浮き彫りになるという試みのもと行われていました。去年くらいにもウチでも導入してみてました。

1.0での問題点

ウチの分報は基本ディレクター陣が制作陣に対してどれくらいの作業量なのか、そして今彼らは何をしているかを把握するためのものとして機能させていました。それを導入してからまるまる1年経ってどうなったか、というところで振り返ってみて上がった問題について挙げてみます。

  • いちいち書くのがダルい
  • 報告=今この作業をしているというのが判明する
  • 作業量の重さが分からない
  • どれくらいの作業量になるかの報告がしづらい
  • もっと有効に使えないか

一番問題となっていたのが「報告=今この作業をしているというのが判明する」ということで、これはその人の抱えるタスクの全体量の中でそれがどれくらいを占めるものかを把握できないのと、残りは何が残っているかを把握しづらいというのがありました。

タスク管理に関してはbacklogを使用してそれぞれのガントチャートでどの程度あるのかを朝礼時に確認するなどして問題があれば調整や他の人に移動するなどがありますが、その日のタスクや明日以降にかかる進捗度をbacklogのみで判定するのは難しいのと自分たちは基本Slackに貼り付いているので、既存の分報事態をバージョンアップする必要があるなと思いました。

バージョン2.0への移行

既存の問題点を解消するために運用方法を以下のように変更してみました。

次回やることリスト・今日やるリストの追加

  1. その日の終わりに次回やることをリストにして分報に記載
  2. 翌朝までに追加案件があればコメントいただく
  3. 次回やるリストに関してスケジュールが難しそうなときは朝礼時に相談する
  4. 今日やることを分報に追加

いわゆるTODOリストとして機能させようとしております。

次回やるリスト --- これは当日最後に記載する

  • A案件 レスポンシブコーディング
  • B案件 お気に入り上限数変更修正
  • C案件 作業見積もり確認
  • D案件 品質チェック対応
  • MEミーティング

追加コメント --- これはやるリストの間にあるもの(なくても良い)

***:@yamanoku 明日の作業でE案件の修正作業がくると思うので担当お願いできますでしょうか。

今日やるリスト --- これは当日最初に記載する

本日中対応

  • A案件 レスポンシブコーディング
  • D案件 品質チェック対応
  • E案件 修正対応

できれば対応

  • B案件 お気に入り上限数変更修正
  • D案件 品質チェック対応

ミーティング

  • MEミーティング(11:00〜11:30)

TODOとしての使い方

上記のようにリスト化するのは必須なのですが、よりタスクを分かりやすくするために以下2点も追加

  • 現在やっている案件がどれかを明確化する
  • 終わった案件は打ち消し線や【完了】など記載して作業時間を書く

f:id:cardboarder:20161226001249p:plain

イメージとしてはこんな感じ。別に絵文字なり打ち消し線は自由でOK。むしろなにが終わってなにを進行しているかを明確化させる以外のことは自由にやってOK。

導入してみて

自分はいちいち記入することよりも、1つの投稿を編集してTODOよろしく管理するほうがやりやすいのでよかったのですが、今のところ他の作業者も良い感じのようです。あとはこれをディレクターやマネージャー陣がスケジュール管理に役立て欲しいなと思うところはあります。

それと改めてSlackのサービスがもつ柔和性というか何にでも使えるという良さを再認識しました。分報は特にサービスやAPIを利用してやるものではないのですが、チャットサービスを利用してアレコレ表現できるのはすごいと思います。

最近だとゲームも作れるみたいとも聞きました。もちろん何かしらサービスとも連携できるのでもっと複雑なこと&簡易的にできるものがあれば探ってみたいです。

とはいえまだまだ導入してみたばかりなので、今後不満点や改善点があがれば随時ブラッシュアップして対応していきます。

こちらからは以上です

エンジニア立ち居振舞い : 誰がどう触っても良いようにつくる

エンジニア立ち居振舞い

お題「エンジニア立ち居振舞い」

マークアップなのかフロントエンドなのかいまいち良く分からない位置付けに居ますが、自分の中で大事にしていることについて。

タイトルの通りなんですが簡単な例でいくと、jQueryでトグルボタンを実装する時に

$("#button").on("click",function(){
  $(this).next().slideToggle();
});

という風になると思う。でもこれには問題があって、ボタンを何度もクリックすると律儀なまでにトグルする動作が押された回数分繰り返されるのでボタンを押すのを止めても動作し続けてしまう。

なので以下のように対応する。

$("#button").on("click",function(){
  $(this).next().stop().slideToggle();
});

これはstop()メソッドを使用することでトグルしようとする動作を一度ストップさせるので、押す→トグル動作の間にボタンを押してもその動作をキャンセルして次の動作へ移行させることができる。

動作イメージは以下よりどうぞ。

https://jsfiddle.net/ft21p1cy/2/

これは非常に単純な例ですが、ユーザーはどういった操作をするかはエンジニアには検討が全くつかない。我々は「1回クリックする」だけのことを考えますが、間違って2回クリックしてしまうとその人は「何だこれは」という風になってしまいます。たった1つのメソッドを追加するでだいぶ使いやすくなるのに、そういったことに気がつけないというのが一番怖い部分です。

だからどんな人がどのようなシチュエーションで弄ったとしても「出来る限り」平等なユーザー体験をもたらさなければならない、というのが私たちの使命なのだと感じています。

こちらからは以上です