魔法使いの卵

WEBエンジニアの卵の成長記録

PhpStormを日本語化する

PhpStormを日本語化できるの?

  • できます

やり方

  • 日本語リソースをインストールする
cd ~/
git clone git@github.com:yuuna/IDEA_resources_jp.git
  • 該当ファイルまで移動します
/Applications/PhpStorm.app/Contents/lib
  • リソースファイルを上記にコピーする
cp ~/IDEA_resources_jp/resources_jp.jar /Applications/PhpStorm.app/Contents/lib/resources_jp.jar
  • phpstormを再起動

最後に

  • お世話になったIDEA_resources_jpを片付けてます
rm -rf ~/IDEA_resources_jp

感想

ao-works.net

  • 上記をもとにやってみました
  • かんたんなので英語苦手な人もこれで使いこなせるんじゃないかな

OSX El Capitanをクリーンインストールして1から設定した話

クリーンインストールした経緯

  • 環境を一度きれいに整理したくなったのが理由

激選して入れたアプリ

Finderをカスタマイズ

  • XtraFinder様がEl Capitanがつかえなくなったので純正をカスタマイズすることにした

  • 以下が作業内容

itkhoshi.com

  • 実際にやった作業
    • リスト化
    • 各バーをすべて表示
    • 環境設定はサイドバー以外デフォルト
  • ※気づいたこと
    • Finderほとんど使わなかった

Homebrewインストール

  • xcode-selectをインストールする
xcode-select --install
  • homebrewをインストールする
ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
  • doxygenをインストールする
brew install doxygen

開発環境構築

default: Warning: Authentication failure. Retrying...
    default: Warning: Authentication failure. Retrying...
    default: Warning: Authentication failure. Retrying...
  • 以下の対応で治ります(応急処置)
    • 通常のsshで仮想環境に入るかVirtualBox経由で入るかはおまかせ
    • どちらにしても次のバージョンアップで改善されてそう
chmod 600 /home/vagrant/.ssh/authorized_keys
  • 作った鍵はgithubに登録して疎通テストする
ssh -T git@github.com

ログインシェルをzshに変更する

  • zshのインストール
brew install zsh
  • 該当ファイルを開く
sudo vi /etc/shells
  • 以下を追加
/usr/local/bin/zsh
  • ログインシェルを変更する
chpass -s /usr/local/bin/zsh
  • 自前のdotfilesを入れる
git clone git@github.com:yutanakano/dotfiles.git
ln -s ~/dotfiles/.zshrc ~/
  • 課題
    • 個人的にはsetup.shで必要なものは自動でインストールしてシンボリックリンク貼るところまでできてると楽できると確信

php7をインストールする

  • デフォルトのphp環境がすでにサポート外なので更新する
brew install homebrew/php/php70
brew install homebrew/php/php70-xdebug
  • .zshrcを更新する
source ~/.zshrc
  • 結果
php -v
PHP 7.0.11 (cli) (built: Sep 16 2016 23:09:59) ( NTS )
Copyright (c) 1997-2016 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies
    with Xdebug v2.4.1, Copyright (c) 2002-2016, by Derick Rethans

brewでcomposerをインストールする

brew install homebrew/php/composer

brewでtigをインストールする

brew install tig

brewでtmuxをインストールする

brew install tmux

brewでvim8.xをインストールする

brew install vim --with-lua --HEAD
  • 最後にmacを再起動すれば終わり

反省点

  • まだまだ自動化できるはず

よかったこと

まとめ

  • クリーンインストールはある程度自動化する仕組みをつくってないと辛い
  • おすすめのツールとかあれば教えてください
  • 一応最小の構成で初期設定終えた
  • 最後の方、小並感やばい(真顔

MacのPHPのバージョンをPHP7に上げる

はじめに

普段仮想環境もしくはサーバ内でしか開発しないので まったくmacの標準の環境を使って開発することはないけど Macの中を整理していると急に古い環境っていうのが どうも気に食わなかったのでphpバージョンを上げてみることにした

環境

買った時のOS 今のOS
Yosemite EI Capitan

標準で入っていたphpのバージョン

(๑˃̵ᴗ˂̵)و < php -v
PHP 5.5.31 (cli) (built: Feb 20 2016 20:33:10)
Copyright (c) 1997-2015 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2015 Zend Technologies

qiita.com

  • 上記でサポートされているバージョンか確認
  • サポート終了してるPHPだった(白目

brew updateでbrewが死んだ

brew update
  • あ、死んだ
(๑˃̵ᴗ˂̵)و < brew update
/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:55:in `require': cannot load such file -- mach (LoadError)
    from /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:55:in `require'
    from /usr/local/Library/Homebrew/extend/pathname.rb:2:in `<top (required)>'
    from /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:55:in `require'
    from /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:55:in `require'
    from /usr/local/Library/Homebrew/global.rb:3:in `<top (required)>'
    from /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:55:in `require'
    from /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:55:in `require'
    from /usr/local/Library/brew.rb:15:in `<main>'
~
  • brewが死んだ時の対応

qiita.com

  • 以下、直し方を抜粋
cd /usr/local
git reset --hard && git clean -df
sudo chown -R $(whoami):admin /usr/local
brew update
  • 死んだ理由
    • yosemiteからEl Capitanにアップデート(らしい

php7が動くようにする

  • 参考元

qiita.com

  • php7をインストールする
brew install homebrew/php/php70
  • bashrcもしくはzshrcを書き換える
    • 僕はzshを使っているのでzshrcを指定してますが、bashrcの場合でも同じです
vim .zshrc
  • 以下を追加します
export PATH="$(brew --prefix homebrew/php/php70)/bin:$PATH"
  • zshrcの変更内容を即時反映させる
source ~/.zshrc
  • phpのバージョンを確認してみる
(๑˃̵ᴗ˂̵)و < php -v
PHP 7.0.11 (cli) (built: Sep 16 2016 23:09:59) ( NTS )
Copyright (c) 1997-2016 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies

ついでにXdebugも入れておく

brew install --build-from-source php70-xdebug
  • はい、かんたんに入りました
PHP 7.0.11 (cli) (built: Sep 16 2016 23:09:59) ( NTS )
Copyright (c) 1997-2016 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies
    with Xdebug v2.4.1, Copyright (c) 2002-2016, by Derick Rethans

感想

  • 先人に感謝
  • Apacheなのはどうしようかなぁ・・・

githubのProjectsを早速導入してみた話

githubのProjectsとは

  • 以下参照

qiita.com

  • 今日追加された機能ですが、便利そうだったのでさっそく導入してみました。

Projectsの使い方

  • 以下が参考になるとおもいます

qiita.com


Project名の命名

  • 運用の方法によって変わるとおもいます
  • 今回はphaseとかそういう期間的命名にしています
  • 運用フェーズに入っているサービスとかならサービス名とかでもいいんじゃないでしょうか

カラム名と用途

カラム名 用途
Issue 問題があるところやいずれ対応をしなければならない問題が発生したら作成
PR Issueを対応する時や作業する時に作成したPRを設置
Review コードレビューしてほしいPRをこちらに移動させる
KPT 振り返り時につかう
DONE 完了したカンバンはこちらにためて問題がなければ削除

何にメリットを感じたのか

  • アプリケーションの現状の把握が行いやすいです
  • 特にIssue周りの把握が快適になるなぁとおもいました。

Issue周りで感じていた個人的なツラミ

  • もともとgithubにIssueはあるが管理するのがつらい
  • Issueが溜まってくると誰がどれを着手していて未着手がどれでがわかりにくい
  • かといって別に切り出して管理するのも煩わしくてつらい
  • だれかに聞かないとわからない状況がつらい
  • Issueの建て忘れなどヒューマンエラーが起こりやすい

ProjectでIssueカラムを作成することで改善されるであろう問題

  • Issueカラムにはノートを使ってサービスの問題などをメモしておくことが可能(さらっとメモれるので作り忘れが防げる)
  • Issueカラムのメモからその場でIssue化することができるので気づいたらチーム内でサポートできる
  • IssueカラムのIssueは未着手のみを残すようにするとIssueのステータスが分かる("あ、これまだ誰も手付けてない"ってことがわかる)
  • 対応中のIssueはPRを見ればわかるし未対応のIssueはProjectで把握できるし完了のIssueはIssueを見たらわかるようになる

感想

  • github様ありがとうございます

Composerでrequire-devに任意のパッケージをコマンドで追加する

はじめに

しょっちゅうやり方忘れるのでメモ程度に残しておく

require-devへ1ライナーで追加する方法

composer require アカウント名/パッケージ名 --dev

require と require-devのちがい

種類 目的
require 本番環境と開発環境で共に利用
require-dev 開発環境のみ利用

さいごに

  • バージョンとか色々罠あるのでなんかそのへんいつかまとめたい

yumコマンドで環境を破壊した話と教訓

結論

  • 思考停止して以下のコマンドを叩くと環境が壊れた
yum install -y パッケージ名
yum update -y パッケージ名

経緯

  1. 必要なパッケージがあった
  2. パッケージを導入した
  3. 環境が壊れた(依存するパッケージのVersionを確認していない為)

教訓

  • 現環境でパッケージを変更する際は必ず依存しているパッケージのVersionの確認しておくこと

最近プライベートで活動していたこと

はじめに

最近ブログ書いてなかったので最近プライベートでやっていたことを晒しておく

某スタートアップの手伝い

  • 社長が技術の話が分からずサポートしてほしいと言われたので以下のことをしていた(声をかけられた時にはすでに炎上していた)
    • エンジニアと非エンジニアのパイプ役
    • エンジニアのタスク管理と進捗管理
    • 技術的質問に関するケア(主にgitと環境周り)

個人的に問題だと感じた点

  • 開発環境(動作環境)を持っているのが一人のエンジニアだけ
  • コードが会社の資産のはずなのに一人のエンジニアのPCの中にしかない
    • エンジニアが飛んだ時のリスクヘッジなどが一切できていなかった
  • コードをVersion管理していない
  • 共通で動作確認する環境がない
  • タスクが属人化していた
  • 挙げだすときりがないのでetc...

個人的によかった点

  • gitを導入するとどうよくなるのかわかってもらえた
  • gitのワークショップ的なことを行い実際に開発していくフローをしってもらった
  • コードレビューの文化を取り込むようにしてみた
  • 非エンジニアとエンジニアをちゃんと繋げれたらお互いハッピーになれることを知った
    • リリースまでに色々な調整をやってた
  • 無事リリースできた

懸念点

  • 環境もコードもひとまず動けばおk的なかんじでやっていたので今後つらい思いしそうだなーとおもいました。

感想

  • スタートアップってこんなかんじなんだなーというのが体験できました。