Visual Studio Codeで設定(ユーザー設定・キーボードショートカット)をDropboxで管理・共有する
Visual Studio Code(VS Code)設定の保存形式はJSONファイル
ユーザー設定とワークスペース設定があり、同じ設定項目があればワークスペース設定に記述されている設定内容が優先されます。
ユーザー設定はインストール時にデフォルトで存在し
ワークスペース設定はワークスペースを開いた状態で設定を変更すると、ワークスペースルートに.vscodeディレクトリが作られsettings.jsonファイルが生成/更新されます。その後の変更もここに反映されます。
なお、ユーザー設定はCommand + ,でデフォルト設定との比較ビューでコメント付きのJSONファイルが表示されるので変更する際に対比できるので便利です。
キーボードショートカットの設定として、keybindings.jsonもありますがこちらも同じ要領です。
ユーザー設定を複数環境で共有するためにDropboxを利用
当初 設定を複数マシンで共有するために、ワークスペースルート自体をDropbox配下のディレクトリに指定して開いていたのですが、ワークスペース設定の共有だと 同一マシンでさえ他のワークスペースを開いた際に設定が適用されず不便でした。
そもそもユーザー設定を共有すべきでしたね。
VS Codeの設定ファイルは~/Library/Application Support/Code/Userディレクトリ配下にあるので、ここのsettings.jsonとkeybindings.jsonをDropbox配下のファイルへsymlinkを貼ります。
~$ cd ~/Library/Application Support/Code/User ~/Library/Application Support/Code/User $ rm settings.json ~/Library/Application Support/Code/User $ ln -s /Users/my-account-name/Dropbox/VS\ Code Settings/.vscode/settings.json ./settings.json ~/Library/Application Support/Code/User $ rm keybindings.json ~/Library/Application Support/Code/User $ ln -s /Users/my-account-name/Dropbox/VS\ code/.vscode/keybindings.json ./keybindings.json
Windowsなら
> mklink "C:¥Users¥my-account-name¥AppData¥Roaming¥Code¥User¥settings.json" "C:¥Dropbox¥VS code¥.vscode¥settings.json" C:\Users\my-account-name\AppData\Roaming\Code\User\settings.json <<===>> C:\Dropbox\VS code\.vscode\settings.json のシンボリック リンクが作成されました。 > mklink "C:¥Users¥my-account-name¥AppData¥Roaming¥Code¥User¥keybindings.json" "C:¥Dropbox¥VS code¥.vscode¥keybindings.json" C:\Users\my-account-name\AppData\Roaming\Code\User\keybindings.json <<===>> C:\Dropbox\VS code\.vscode\keybindings.json のシンボリック リンクが作成されました。
ですね。
追記:今は拡張機能でできます
#devsumi 2017参加レポ (Developers Summit 2017) 最終日 (2/17)
デブサミ2日目 最終日!
2日目にして最終日のレポです。
■ 自動化はどこに向かうのか ~まだ開発・運用の自動化で消耗しているの?~
乗り換え含む乗った全ての電車が遅延で消耗してしまった、途中から。
自動化は目的ありきで、ツール使いたいからってだけではダメよ。という感じの内容でした。シーズではなくニーズありきでという話がJJUGで出ましたが、何でも目的ありきですよね。
でも、何の自動化すらやってない現場がもし2017年現在まだあるならば、それはヤバいと思う。
テストとかデプロイの自動化してない状況で、納品後に「あ!これ確認し忘れた!!」とか「あ!これ入ってない!!」とか言われるとすごい嫌な汗でるよね。昨日体験しました(;´Д`)#devsumiE
— Makoto (@mako_limone) 2017年2月17日
■ 完全ベンダーロックインのMicroservices/DevOpsでマイクロソフトに貢献しよう!
MSエバンジェリストの牛尾さんセッション。
前半DevOpsの話、後半VSTS紹介。
ソフトウェア産業で生きてるなら(お金を貰ってるなら)イケてると思ったツールにはお金を払おう。 #devsumiB
— Ryoichi Obara (@ryoichi_obara) 2017年2月17日
■ Google Chrome 56登場で待ったなし! 30分で学ぶ常時SSL/TLS実装のポイント
■ コンテナをフル活用した現場
The Twelve-Factor App (日本語訳) を中心に。
リポジトリの中には、必ずDockerがあること。scriptフォルダーやdocフォルダを配置。script/bootstrapやscript/serverと叩くと動くように共通ルールにしている。#devsumi #devsumiE
— 池田 泰延 clockmaker_bot (@clockmaker_bot) 2017年2月17日
PJ参画時のスタードダッシュが効くようプロジェクトをまたがってルールが決まっているのが良いですね。
Kubernetesとは
— 池田 泰延 clockmaker_bot (@clockmaker_bot) 2017年2月17日
「アプリケーションがどこで動いているかを意思する」世界から「アプリケーションがどう動いているかだけを意識していれば良い」背系にできる#devsumi #devsumiE
■ C#で簡単にモバイルアプリを作ろう!
MSエバンジェリストちょまどさんによるC#とXamarinの概要の紹介。
C#のライブコーディングがありましたが、こちらもネットワーク不調でしたね。
動画を予め用意しておくっていうリスク管理は重要ですね。
■ コミュニティとエンジニアの生き方
コミュニティの運営についての非常にアツいセッション。
コミュニティは参加者と登壇者と運営で成り立っていて、参加者は"いわゆるお客様"ではない。コミュニティは集団の何かしら少しづつの貢献の上に成り立っていて、使い潰して捨てられるようなものでは成立しない。
無いことを嘆いたり・批判をすることは良くない。
私も社内で勉強会を主催することがあるのですが、
やはり運営についての難しさを感じることが
"継続は力なり"と言いますが、継続するためには集団の力が必要と改めて感じました。
そのためにどうするかのtry and errorや具体的なTipsが聞きたい。
⇒Ask The Speakerに行ってみた。やはり社内は大変で、社外のコミュニティの方が数の力があるので、まだやりやすい方ですねとのことでした。
■ 今年はJava進化の年! 今知っておくべき新しいJava
本業で使うので聴講。
Java 9についての変更概要に関するセッション。
2017/07/27 リリース予定とのことで、これはまた近くなったら別途書こうと思います。
■ 総評
セッションタイトルが(仮)のままのものが多かった。
永遠のβ版じゃないんだから、気持ちよく固めきってきてほしい。
あと運営スタッフが今回から変わったのか会場がかなりドタバタしていたのが目立った。
と、文句はこれぐらいにして・・・
今回私の周辺では6人参加と過去最大でした!
去年も書いたけど、アフターだけ謎に参加の弊社員は来年こそ来てくれるはず!!
と言いつつも今年は増えたので来年もっと割合が増えると良いな!
#devsumi 2017参加レポ (Developers Summit 2017) 初日 (2/16)
今年もデブサミへ!
参加4年目です。仕事が忙しいのに申し訳ない。でも参加。
今年のテーマは
"エンジニアとして生きる、技術の先にある現実に踏み出す"
です。papandaさんっぽいです。
やはりデブサミはソウルフルであってほしい。
■ Webフロントエンドの変遷とこれから
前半は歴史の話、侍魂とか懐かしい。
後半はこれからのWebフロントエンドとエンジニアが幸せであり続けるための話。
はじめてのプログレッシブ ウェブアプリ | Web | Google Developers
GitHub - extensibleweb/manifesto: The Extensible Web Manifesto
■ Google のインフラ技術から考える理想のDevOps
重要なのは役割ではなく知識範囲としてのフルスタック
製造業などで自工程完結という言葉がありますが、
それぞれのセクションがセクションを越えてやりやすいような仕事をするというのは目指したい所です。セクショナリズムではないですね。
■ 30分でLINE Messaging APIを使ったチャットボットを作って優勝賞金1000万円のLINE Bot Awardsにチャレンジしよう!
最初は概要説明、そして残り13分で
登録〜echobotを動作させるBotのライブコーディング。
IntelliJ使ってたけど結構良さそう…!! 手早い。
■ パネルディスカッション「エンジニアが創るプロダクトの未来 ~エンジニアからプロダクトマネージャーへ~」
自社もプロダクトを持っているので染みる話もあり。
valuable, usable, feasible
この3点で考えるってのは布教していきたい。
■ MicrosoftのAI開発機能/サービス
Cognitive Serviceの紹介。
Azure基礎的な感じですが、私は知らなかったのでミになりました。
■ IoTへのWeb側からの関わりかた
ダイエットフードwとMQTTの紹介。
■ 事業成長にコミットするエンジニア組織への道のり
文化のつくりかたの話。
エンジニア採用に力を入れた後だが、社員エンジニアはこうあるべき、という指針がふわっとしており、その価値が確立できなかった。
組織として見直すことに。そこで、
・売上/利益最大化
・事業成長に負けないように技術的に成長すること
とした。
技術 × 熱意 × プロダクト理解
管理も必要だが、エンジニアが主であることが改めて重要である。
・人事制度の変更:
マネージャーとエンジニアの乖離についてのキャリアの再定義。
・(開発ではない)合宿:
模造紙や付箋などでエンジニアのみで実施。課題とアクションプランが明確になるように。
・求職者へのアピール:
ブログ・インタビュー・OSS活動・社内LT/ハッカソン
■ 視点移動〜ビジネスと組織と人の狭間で越境し続けるエンジニアの物語、その彼岸
私は泣きにきたんでしょうか、感動しました。
久々のpapandaさん。
やべー 感動しすぎて涙ぐんでしまったwwwwww #devsumiB
— おー (@Sakenenryou) 2017年2月16日
わかる・・・本当きてよかった