月別アーカイブ: 2017年10月

[Vue] 親コンポーネントのデータ/メソッドを子コンポーネントから使う

前提

以下の環境で動作確認

要素 バージョン
debian 8.6
node 8.6.0
Vue 2.6.1

概要

題の通り、Vueの親子コンポーネント間でのデータとメソッドのやり取りを行う方法の備忘録。
本記事では、以下のようなVueコンポーネントの親子関係を用意し、子コンポーネントから親コンポーネントのデータ、メソッドを利用する。

  • 親コンポーネント(parent)
    — 文字列データ及びそれを書き換えるメソッドを定義
  • 子コンポーネント(child)
    — テキストボックスとボタンと持ち、親のデータの読み書きを行う

親コンポーネント

<template>
  <div>
    <child :data="data" @set="setData"/>
  </div>
</template>

<script>
  export default {
    name: 'parent',
    data() {
      return {
        data: '',
      }
    },
    methods: {
      setData(data) {
        this.data = data
      }
    }
  }
</script>

子コンポーネント(child)に、属性dataとメソッドsedDataを渡す。
:dataと@setは省略記法で、それぞれv-bind:dataと、v-on:setを省略したもの

子コンポーネント

<template>
  <div>
    <input type="text" ref="text">
    <button @click="$emit('set', $refs.text.value)">Set</button>
    <p>{{ data }}</p>
  </div>
</template>

<script>
  export default {
    name: 'child',
    props: ['data'],
  }
</script>

親コンポーネントから受け取る属性は、propsで定義しなければならない。一見面倒だが、これによって不要な属性を受け取らずに済む。

buttonクリック時に、親コンポーネントのイベントに伝搬するために、$emitを用いる。$emitの第二引数以降が、元のイベントに対する引数になる。

実行結果

画像のように、テキストボックスに文字列を入力し、ボタンをクリックすると、親コンポーネントのsetDataメソッドが実行され、dataが書き換わる。

備考

  • Vueではコンポーネントの親子関係が深くなるとバケツリレーが始まるので、Vuexを導入が推奨されるみたい
  • VuexはReactにおけるReduxのような、Vueでストアを一元化するためのフレームワーク

3年目プログラマが参考にしたQiita記事まとめ①

特にカテゴリもレベルも偏らずにざっくばらんに、参考になったQiita記事を一言添えて列挙するシリーズ1本目

翻訳: WebAPI 設計のベストプラクティス

WebAPI、というかRestFulAPIに関するベストプラクティスをまとめた記事を日本語訳した記事。

RestFulの基本的な説明から、具体的な設計方法までわかりやすく解説されている。

個人的には「ページング情報はレスポンスヘッダに入れよう」の項が一番参考になり、その後実務でもSPAでのページング処理を実装する際に大いに役立った。

「WebAPI 設計のベストプラクティス」に対する所感

題の通り、一つ目の記事に関する捕捉記事。両記事に目を通すとよく分かるが、WebAPIの設計に絶対の正解は無い。どのような設計が最もRestFul的で、ユーザビリティに富んでいるかは、やはりその時々で違ってくるので、色々なパターンを抑えて最良の選択をできるようにしたい。

うまくメソッド名を付けるための参考情報

基本的にプログラミングは英語で行う必要があるので、英語が苦手な人にとっては特に苦労する命名作業。頻出単語と、その単語を含んだメソッドがどんな動きをするのかのルールを抑えておくだけで、コードを書くときにも読むときにも役立つ。
最近でも、命名に迷った時は軽くこの記事に目を通すようにし、この記事を見ても適切な名前が浮かばない場合はそもそも設計に誤りがあると考えるようにしている。(適切な名前を付けられないロジックは、複数の責務が混在してる可能性が高いため)

ベアプログラミングが無理ならサイレントベアプログラミングを検討しよう

(サイレント)ペアプログラミングではなく、(サイレント)ベアプログラミング。

サイレントベアプログラミングは記事内での造語だが、ベアプログラミングは昔からある手法で、「解らないことをクマのぬいぐるみに相談すると、自然と自己解決できる」というもの。もちろんクマのぬいぐるみが解決してくれるわけではなく、質問するためにまず問題点を整理するプロセスが重要ということ。記事内でのベアプログラミングは、ぬいぐるみ相手に話しかける必要があるので職場などで行うには難易度が少々高い。そのための代替案がベアプログラミングだ。

一通り記事を読んで思ったが、これプログラマなら誰しも多かれ少なかれ脳内ではやっているのでは‥‥?

ターミナル 作業効率化 tips集

ターミナルでキー入力する際のTips集。常日頃からCUI上で開発を行っていると、コマンド入力を頻繁に、それこそ息をするように行う必要があるので、こういった小さなTipsの積み重ねが生産性に大きく影響する。

ちなみに私はMacの標準ターミナルでなく、iTerm2を使っているが、基本的に記事内のTipsの多くはどのツールでも共通だったりするので問題は無い。

新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則

この手の記事はだいたいリーダブルコードを読むだけで済む話だが、一冊丸々読まずともこの記事の内容を押さえているだけでかなり変わると思う。

新人プログラマ向けと言ってるが、正直プログラミングを始めたばかりの人にこれを求めるのは少々酷かもしれない。とは言っても早い段階からこういった考えを持たせたほうが、余計なクセが付かずに済むので、遅すぎず早すぎないタイミングで学べると良さそう。

何かのときにすっと出したい、プログラミングに関する法則・原則一覧

DRYとかKISSとか驚き最小の原則とかそういったものの紹介記事。こういうのを頭に入れておいて、かつ言葉もセットで覚えておくと、コードレビューがスマートに行えそう。

個人的にはボーイスカウトの規則が好きで、日々実践をしているのだが、テストが整備されていないコードに対して行うのは勇気がいるので単体テストぐらいは整備されてて欲しい。

あきらめるにはまだ早い!ソースコードの品質向上に効果的なアプローチ

組織内のコード品質を高めるための手段まとめ。あまり即時性のあるものではなく、こういった仕組みを組織内に導入すれば、長い目で見て確実にコード品質が高まり、生産性の向上に繋がるといった感じ。
なかなか簡単に実行できることじゃないものが多いが、できそうなことから少しずつ手を出せるようにしたい。

コードレビューの極意。それは「自分のことは棚に上げる」こと!!

題の通り。これはコードレビューに関わらず、何かに対してダメ出しをする時の原則だと思う。
自分もできてないけど、そうした方が良いと思うから他の人にそれを要求するようにすれば、自然と自分もそれに従って出来る様になるのでは。

データサイエンティストを目指して半年で学んだことまとめ

軽い気持ちで機械学習に手を出してて苦労してるところで非常に参考になった。

プログラミング、フレームワークの力で、機械学習ができるのは事実ですが、作ったモデルや予測結果の説明ができなければ価値がありません。

が特に心に響いた。極端に言えば、機械学習は魔法のようなモノとまで認識していたようだ。

モデルの精度を上げるために、「とりあえず、Deep Learningで!」や「分類問題を解くならSVM!」等、アプローチだけに気をとられていると、すぐに精度があがらなくなります。勿論、納得できる良い精度は出ません。

そして早い段階でこれにぶち当たった。精度が出ない。何故?何も知らないから。

vimで保存時に不要な行末スペースを削除する

概要

.vimrcに以下のコマンドを追加すると、ファイル保存時に、不要な行末スペースを自動で削除してくれる。

autocmd BufWritePre * :%s/\s\+$//ge

解説

autocmdは、vimで特定のタイミングで何らかのコマンドを実行させるコマンド。

第一引数に指定している”BufWritePre”は、コマンド実行のタイミング指定で、ファイルを保存する直前を意味する。他にもファイル保存直後や、新規ファイル作成時などのトリガがある。

第二引数”“は、対象となるファイル名のパターンを表す。例えばtxtファイルでのみ適用したい場合、.txtと指定すればよい。今回は全てのファイルにおいて動作させたいので”*”を指定する。

第三引数には、実行するコマンドを記述する。

:%s/\s\+$//ge

を紐解くと、ファイル内の全ての/\s+$/を空文字で置換するという記述で、行末の手前にあるスペースを削除するという意味になる。

以上より、

autocmd BufWritePre * :%s/\s\+$//ge

とvimrcに記述することで、全てのファイル保存時に、ファイル内の不要な行末スペースを削除するという機能をvimに追加することができる。

参考

[vim] 挿入モードで検索ハイライトを無効にする

概要

検索時のハイライトはありがたいけど、挿入する頃には鬱陶しいので消したい。
:nohを適当にマッピングしてもいいがそれも面倒くさい。

挿入モード遷移時に:nohを実行する

autocmdのInsertEnterを使えば、挿入モード遷移時に任意のコマンドを実行させられるので、ここでnohを叩かせる。

autocmd InsertEnter * :noh

が、ダメ。動作しない。

Why

ヘルプを叩いてみた。

:noh[lsearch]           Stop the highlighting for the 'hlsearch' option.  It
                        is automatically turned back on when using a search
                        command, or setting the 'hlsearch' option.
                        This command doesn't work in an autocommand, because
                        the highlighting state is saved and restored when
                        executing autocommands |autocmd-searchpat|.
                        Same thing for when invoking a user function.

autocommandでは機能しないってハッキリ書いてあった。

代替策

しかたないので、挿入モード移行時にはハイライト機能を無効にし、挿入モードを終了したら有効に戻すというアプローチを取る。

autocmd InsertEnter * set nohlsearch
autocmd InsertLeave * set hlsearch

いい感じに動いた。

vimで矢印キーを使う癖を矯正(強制)する

vimのカーソル移動についつい矢印キーを使ってしまう人に、vimで矢印キーは絶対使っちゃイケないんだと思い込ませるための設定。

nnoremap <Up>    :q!<CR>
nnoremap <Down>  :q!<CR>
nnoremap <Left>  :q!<CR>
nnoremap <Right> :q!<CR>
inoremap <Up>    <ESC>:q!<CR>
inoremap <Down>  <ESC>:q!<CR>
inoremap <Left>  <ESC>:q!<CR>
inoremap <Right> <ESC>:q!<CR>

一応解説すると、ノーマルモード挿入モード問わず、矢印キーを叩いてしまうとファイルを保存せずに閉じるので、矢印キーを使わないカーソル操作を強制できる。恐怖で支配する的なアレ。

話題のオープン職務経歴書を書いてみる

概要

以下の記事に一通り目を通して強く影響を受けたので、自分なりに解釈、アレンジしながら書いてみた。

名称について

参考記事では「職務経歴書OSS化」というワードが使われているが、Githubで公開してるだけでOSS要素はあまり無いと思った。本記事ではリクナビの「オープンエントリーシート」に準えて、「オープン職務経歴書」といワードを用いることにする。

といっても、後述のデメリットから職務経歴書というよりはスキルシートに近いので、「オープンスキルシート」とするのが正確かもしれないが、そうすると元の参考記事からさらに離れてしまうので、職務経歴書のワードはそのまま使うことにした。

オープン職務経歴書の概要

名の通り、グローバルに公開した職務経歴書。元記事に倣って、Githubに公開することを想定する。

職務経歴書と言えば転職活動時に使う前提のものとなるが、書き方によっては転職の意思がなくても多くのメリットが得られる。自分で書いてみた感触と、元記事で紹介されている情報をあわせて、メリット/デメリットを整理すると以下の通りになる。

メリット

  • 継続して書いておくと、いざ転職活動などで必要になった際に困らない
  • 自身の経験/スキルを客観視することができる
  • 他人に自身の経験/スキルを説明しやすくなる
  • 他人に自身の職務経歴書を校正してもらえる
  • 話のタネになる。技術アピールのきっかけになる
  • お金がかからない
  • Githubを使えばMarkdownでサクッと書いてサクッと公開できる

デメリット

  • 公開できる情報に制限がある
    — 個人情報
    — 企業情報
    — 各種製品名
  • 記載内容やフォーマットに統一性がない

オープン職務経歴書の例

職務経歴書(履歴書)を英語でCurriculum-Vitaeというらしく、Githubでこのワードを検索すると、リポジトリが山ほど出てくる。
Github Curriculm-Vitae

もちろん、本記事の内容に関係ないリポジトリも数多くあるが、適当にリポジトリを選択してみると、日本人/外国人問わず、多くの職務経歴書(履歴書)が確認できる。また、本記事ではMarkdownを想定しているが、HTMLやPDF、Texなど、様々なフォーマットでも公開されている。

記載内容

既存のオープン職務経歴書をいくつか見てみると、やはり人によって記載している内容は大きく異なる。登壇歴や出版歴など、輝かしい功績を記載している人もいれば、具体的な会社名や製品名を出した、本物の職務経歴書のような人もいる。

本記事では、私がグローバルに公開しても確実に問題ないと思った範囲についてのみ記載することにする。そのため、具体的な会社名、製品名は伏せ、どのような技術を用いた業務を行ってきたかを確認できるようにする。

公開できる範囲で、精一杯のアピールができるように、今回は以下のような構成にした。

基本情報

氏名、メールアドレス、各種SNSアカウントなど、公開できる範囲で記載。私は割りと本名をネット上で利用しているのでここは気にしなかった。流石に電話番号や住所は書かない。

資格

死角?ありません、無敵です。
とりあえずIPA資格だけ、名前と取得年月を記載。運転免許とか簿記とか、エンジニアに本質的に関わらないものは割愛。

自然言語

日本語/英語どのぐらいいけるか。あえて正直に書いた。

プログラミング言語/フレームワーク

趣味、実務問わず、一定期間以上使っていた言語及びフレームワークを列挙。それぞれの言語について、実務の経験年数と備考を記述。

実務経歴

これまで実務で関わってきたプロジェクトを、特定されないような大雑把な表現で紹介。個々のプロジェクトについて、期間及び使用技術、担当業務などを記載。

成果物

以上を元に、以下のオープン職務経歴書を作成した。
Sa2knight/Curriculum-Vitae

所感

  • 転職うんぬんでなく、経歴を客観視しつつ常に更新し続けることが醍醐味だと感じた
  • 「君、何が出来るの?」的な問に対して今後はURLを張るだけで解決しそう
  • そもそもエンジニアがこういった情報を紙で出すことが前時代的なのでは
  • Githubに置いてるので、そのままその人のソースコードを閲覧できるのはエンジニア的には大きいかも
  • 経験年数で技量を測るのはナンセンスだと思うけど現状コレが主流なので仕方ない
  • Markdownだとテーブルのスタイリング調整ができないのでちょっと辛い