js勉強会用資料

ちょっとした勉強会用に書いたやつ

太古のコード

See the Pen jzNaoa by tic40 (@ccpzjoh) on CodePen.

特徴

  • DOMの状態管理がない
  • DOMを手作業で直接更新
  • DOMの状態を毎回把握しないといけない

データバインディング

See the Pen dmbJPy by tic40 (@ccpzjoh) on CodePen.

特徴

  • モデル(js object)の更新に伴って、ビュー(DOM)に変更が反映される
  • 手作業でDOMを更新する必要がない

データバインディング + コンポーネントベース

See the Pen yKBpwr by tic40 (@ccpzjoh) on CodePen.

特徴

  • DOMはほぼjs側で生成する
  • コンポーネント化することで、コードの再利用性が高まる
  • コンポーネントごとに単一の責任を負わせることで副作用が減る
  • テストが容易

Hugoにgoogle analyticsを設定する

config.toml に以下を追加

googleAnalytics = "{your tracking code}"

Hugoはgoogle analytics用のテンプレートをすでに用意している。 テンプレートファイルに以下の一行を追加だけで良い。

{{ template "_internal/google_analytics_async.html" . }}

これでビルドすればgoogle analyticsコードが埋め込まれる。

参考: Internal Templates | Hugo

dockerコンテナで起動したPHPビルトインサーバにアクセスできない

適当にdocker コンテナを走らせる。-p で8080ポートを指定。

$ docker run -it --name {container-name} -d -p 8080:8080 {image-name}

docker コンテナ内でphpファイルを作成し、php ビルトインサーバを以下のように動かした。

$ echo "<?php echo 'hoge;" > index.php
$ php -S localhost:8080

ブラウザで http://localhost:8080 にアクセスしてみる

f:id:tic40:20180305214812p:plain

見れない。

localhostを0.0.0.0 にしてビルトインサーバを再起動してみる。

$ php -S 0.0.0.0:8080

見れた。 localhost ではなく、0.0.0.0を指定することでアクセスできる。

Hugoでポートフォリオサイトを作る

github pagesを使って自身の経歴を公開するポートフォリオサイトを作ろうと思い立った。 今回、Hugoという静的サイトジェネレータを使って構築したのでその手順を記しておく。

使用するツール

Jekyll と Hugo 両方使ってみてHugoの方が簡単だったのでHugoで構築する。

github.com

The world’s fastest framework for building websites.

世界最速

できあがったもの

完成イメージはこちら

https://tic40.github.io/

構築方法

前提

  • github pages を使って無料で公開する
  • ユーザページとして公開する (https://.github.io/)

手順

$ brew install hugo
$ hugo new site <site name>
  • テーマを設定。submodule として登録しておく
$ cd <site name>
$ git submodule add https://github.com/budparr/gohugo-theme-ananke.git themes/ananke;\
$ echo 'theme = "ananke"' >> config.toml
$ git submodule add -b master git@github.com:{USERNAME}/{USERNAME}.github.io.git public

こうしておくことで、public/ の変更をpush したときに、公開用リポジトリに変更をpushされるようになる。

  • ローカルで動作確認
$ hugo server -D

*-Dオプションをつけるとドラフト状態の投稿も表示されるのでつけておくといい

デフォルトだと、1313ポートでローカルサーバーが立ち上がるので、ブラウザで確認できる。

http://localhost:1313/

  • デプロイ

1コマンドでリリースできるようにスクリプトを作っておく

$ vi deploy.sh
#!/bin/bash

echo -e "\033[0;32mDeploying updates to GitHub...\033[0m"

# Build the project.
hugo # if using a theme, replace with `hugo -t <YOURTHEME>`

# Go To Public folder
cd public
# Add changes to git.
git add .

# Commit changes.
msg="rebuilding site `date`"
if [ $# -eq 1 ]
  then msg="$1"
fi
git commit -m "$msg"

# Push source and build repos.
git push origin master

# Come Back up to the Project Root
cd ..

スクリプトに実行権限を付与

$ chmod +x deploy.sh

スクリプトを実行して公開

$ ./deploy.sh

githubにアクセスしてページが表示されればOK

https://{USERNAME}.github.io

記事を投稿する

記事ファイルの作成

$ hugo new posts/{title}.md

上記で作成されたファイルを編集して、deploy.shを実行すれば公開される。 *上記で作成した記事は、ドラフト状態(draft: true) になっているため、そのままでは本番に反映されない。公開時は draft: false にしておく

最新の詳しいドキュメントはこちらを参照

https://gohugo.io/documentation/

brewfileでMacのソフトウェアインストールを自動化する

3年ぶりにmacを買い替えた。

macbook air 11inch(2014) -> macbook pro 13inch(2017)

13インチなのにサイズがほとんど11インチairと同じだ。ディスプレイもきれいになって、最高という感じ。

せっかくなので、今まであまり使ったことがなかったHomebrewを使ってソフトウェアインストールを自動化してみた。

github.com

homebrew をインストールする

$ /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

Brewfileを作る

移行元のmacで、dumpコマンドを実行しBrewfileを書き出す。

$ brew bundle dump

brewでインストール可能なパッケージはsearch コマンドで検索できる。

$ brew search {name}

書き出されたBrewfileを元に不要なものを削除したり、追加したりして、下のようなBrewfileを作った。

$ cat Brewfile
cask_args appdir: "/Applications"
tap "homebrew/core"
tap "homebrew/bundle"
tap "caskroom/cask"
brew "vim"
brew "zsh"
brew "curl"
cask "atom"
cask "docker"
cask "dropbox"
cask "evernote"
cask "filezilla"
cask "firefox"
cask "google-chrome"
cask "google-drive-file-stream"
cask "google-japanese-ime"
cask "iterm2"
cask "keepassx"
cask "mysqlworkbench"
cask "skitch"
cask "skype"
cask "slack"
cask "vlc"

上記のBrewfileを移行先PCに置いてbrew bundle を実行する。

$ brew bundle

おしまい

Slack基本使い方まとめ

概要

Slackをちゃんと業務で使うために、基本機能まとめる。

get.slack.help

基本

メンバー種別/権限

大きく4つの種別が存在する。

  • オーナー
  • 管理者
  • メンバー
  • ゲスト

詳細はこちら Slack メンバーの種別と権限 – Slack

チームとワークスペース

チームとは、Slack を使ってコミュニケートする人たちのグループです。

Slack ワークスペースは、あなたとチームメートがコミュニケートし、仕事を果たすために共有するデジタルスペースです。

ふむ。チームとワークスペースは、意味合い的には同じなのかな。

小〜中規模の企業では、全社員が1つの Slack ワークスペースに所属するケースが多いでしょう。

大規模組織じゃないかぎりは、1つのワークスペース運用のみで事足りるようだ。

チャンネル

ワークスペース内にはいくつもの チャンネルがあり、他のメンバーとの会話のほとんどがこのチャンネルを利用して行われます。

  • ワークスペースの中に、チャンネルは属している。プロジェクトや関心事の単位でチャンネルをワークスペースの中に作成していけば良さそう。
  • #general と #random はワークスペース作成時にデフォルトで作成される。#general はチーム全体共有用、#random は雑談用。

パブリックとプライベートチャンネル

  • パブリックは、チーム全体に公開される。チーム内の誰もが閲覧できる。
  • プライベートはそのチャンネルに招待されたメンバーのみ閲覧、検索可能。一部メンバーとクローズドな会話をするときに使う。

DM(ダイレクトメッセージ)

DMはチャンネル内でできない、よりセンシティブな会話をするときのみ使う。

検索

右上の検索ボックスから検索可能。

無料と有料プランの違い

4つのプランがある。フリー/スタンダード/プラス/Enerprise Grid

プラン・製品・機能 – Slack

フリープランには、以下のような制限がある。運用が以下の制限に引っかかるようであれば、有料プランへ移行した方がいい。

  • 検索可能メッセージ: チームの直近のコミュニケーション10,000件
  • 音声通話とビデオ通話: 一対一のみ
  • ファイルストレージ: ワークスペース全体で 5GB
  • アプリとサービス: 10 点のサードパーティまたはカスタムインテグレーション

実践

ワークスペースの作成

https://slack.com/create#email

環境設定

https://{workspace name}.slack.com/admin/settings#settings

ワークスペース設定、チーム権限、認証などを設定可能。

メンバーの招待

https://{workspace name}.slack.com/admin/invites

チームへの参加

  • チームオーナーまたは管理者から招待してもらう
  • 招待メールが届くので、メール内のリンクから参加する

カスタム絵文字の登録

  • 左上のチーム名をクリック
  • 「slack」をカスタマイズを選択する

*使用できる画像にはピクセル幅、ファイルサイズの制限があるので注意。

スレッド機能

チャンネルに投稿されたメッセージに対して、直接コメントできる。 一連の会話をまとめることができる。

メンション機能

@のあとに対象を入力することで、その対象に対して通知を送ることができる。

  • @here: チャンネルに参加していて、オンラインのメンバー全員に通知を送る
  • @channel: チャンネルに参加している全メンバーに通知を送る
  • @everyone: このメンションはワークスペース全員に通知を送る
  • @{username}: username に対して通知を送る

メッセージ書式

*msg* : 強調
~msg~ : 取り消し線
_msg_ : 斜体
> : 引用
>>> : 複数行の引用
`code` : コードブロック
```code``` : コードブロック。ブロックで表示する。

slashコマンド

/ (slash)の後に特定のコマンドを入力することで様々な機能を実行できる。スラッシュを入力すると、コマンド一覧がサジェストされる。

3rdパーティアプリケーションとの連携

App Directory から、外部サービスとSlackの連携をさせることができる。

https://{workspace name}.slack.com/apps

googleカレンダーGitHub、Jira など様々な外部サービスとの連携が用意されている。

雑感

slack >>>>> chatwork

エンジニア転職面接で最低限聞いておくべきチェックリスト

Webアプリケーションエンジニア目線で確認しておくべきことのチェックリスト。忘れがちなので書き出してみた。

チェックリスト

  • 会社のメインプロダクトは?
  • 開発手法は?
    • プロジェクトマネジメントツールは?
    • ソースコード管理は?
    • CI/CDにはどう行っている?
    • コミュニケーションツールは?
  • 開発環境は?
    • サーバ構成は?
    • 開発環境構築は自動化されているか?
    • サーバサイドの採用技術/メインFWは?
    • フロントエンドサイドの採用技術/メインFWは?
    • 開発マシン、モニタ、その他デバイス、ソフトウェア、に最も力を発揮できるものを使えるか
  • インフラ
  • 組織について
    • 社内人間関係に問題はなさそうか。
    • 組織におけるエンジニア部署の立場はどうか。
    • 開発部署のリーダーが尊敬できそうな人間かどうか。(自分より優れていると感じるか)
  • 人事評価制度について
    • エンジニアの評価はどのように行うのか。その評価制度で自身に昇給の見込みがあるのか。

まとめ

これぐらいは最低限確認しておくべきだな、と最近感じている。