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
感想
- 上記をもとにやってみました
- かんたんなので英語苦手な人もこれで使いこなせるんじゃないかな
OSX El Capitanをクリーンインストールして1から設定した話
クリーンインストールした経緯
- 環境を一度きれいに整理したくなったのが理由
激選して入れたアプリ
- Google Chrome
- Google 日本語入力
- Firefox
- Firefox DeveloperEdition
- kobito
- Clipy
- AppCleaner
- Karabiner
- Alfred
- MacClean
- iTerm2 Version3
- sequelpro
- Slack
- Skype
- Line
- sourcetree
- virtualbox
- 1Password 6
- dropbox
- phpstorm
- xcode
- docker for mac
Finderをカスタマイズ
XtraFinder様がEl Capitanがつかえなくなったので純正をカスタマイズすることにした
以下が作業内容
- 実際にやった作業
- リスト化
- 各バーをすべて表示
- 環境設定はサイドバー以外デフォルト
- ※気づいたこと
- Finderほとんど使わなかった
Homebrewインストール
- xcode-selectをインストールする
xcode-select --install
- homebrewをインストールする
ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
- doxygenをインストールする
brew install doxygen
開発環境構築
オレオレ開発環境自動化scriptをつかった
- 鍵作ったりconf作ったり必要なプラグインいれたりboxいれたりなどしてる
※Vagrant1.8.5ではバグがあり以下のようになります
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
gitとかで管理してたらそのままgit cloneしてシンボリックリンク貼ればおk
サンプルコマンド
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を再起動すれば終わり
反省点
- まだまだ自動化できるはず
よかったこと
- PhpStormのLicense更新
- クリーンインストールすることでMacの中とってもきれいになった
- 自分のscript見直すいい機会だった
まとめ
- クリーンインストールはある程度自動化する仕組みをつくってないと辛い
- おすすめのツールとかあれば教えてください
- 一応最小の構成で初期設定終えた
- 最後の方、小並感やばい(真顔
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
- 上記でサポートされているバージョンか確認
- サポート終了してるPHPだった(白目
brew updateでbrewが死んだ
- 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が死んだ時の対応
- 以下、直し方を抜粋
cd /usr/local git reset --hard && git clean -df sudo chown -R $(whoami):admin /usr/local brew update
- 死んだ理由
- yosemiteからEl Capitanにアップデート(らしい
php7が動くようにする
- 参考元
- 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も入れておく
- 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とは
- 以下参照
- 今日追加された機能ですが、便利そうだったのでさっそく導入してみました。
Projectsの使い方
- 以下が参考になるとおもいます
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 パッケージ名
経緯
- 必要なパッケージがあった
- パッケージを導入した
- 環境が壊れた(依存するパッケージのVersionを確認していない為)
教訓
- 現環境でパッケージを変更する際は必ず依存しているパッケージのVersionの確認しておくこと
最近プライベートで活動していたこと
はじめに
最近ブログ書いてなかったので最近プライベートでやっていたことを晒しておく
某スタートアップの手伝い
- 社長が技術の話が分からずサポートしてほしいと言われたので以下のことをしていた(声をかけられた時にはすでに炎上していた)
- エンジニアと非エンジニアのパイプ役
- エンジニアのタスク管理と進捗管理
- 技術的質問に関するケア(主にgitと環境周り)
個人的に問題だと感じた点
- 開発環境(動作環境)を持っているのが一人のエンジニアだけ
- コードが会社の資産のはずなのに一人のエンジニアのPCの中にしかない
- エンジニアが飛んだ時のリスクヘッジなどが一切できていなかった
- コードをVersion管理していない
- 共通で動作確認する環境がない
- タスクが属人化していた
- 挙げだすときりがないのでetc...
個人的によかった点
- gitを導入するとどうよくなるのかわかってもらえた
- gitのワークショップ的なことを行い実際に開発していくフローをしってもらった
- コードレビューの文化を取り込むようにしてみた
- 非エンジニアとエンジニアをちゃんと繋げれたらお互いハッピーになれることを知った
- リリースまでに色々な調整をやってた
- 無事リリースできた
懸念点
- 環境もコードもひとまず動けばおk的なかんじでやっていたので今後つらい思いしそうだなーとおもいました。
感想
- スタートアップってこんなかんじなんだなーというのが体験できました。