Mac初期設定メモ
Macを新調したので、設定やいれたアプリメモ。
OS: Mojave 10.14.2
Macの設定
- 一般
- 外観 -> ダーク
- トラックパッド
- 軌跡の速さを最速に設定
- タップでクリック -> ON
- 通知センターのジェスチャーOFF
- エディタを横スクロールさせたとき動作してうざいので
- Dock (使わないので邪魔にならない設定に)
- サイズを小さく
- 画面上の位置 -> 左
- なんとなく
- Dockを自動的に表示/非表示 -> ON
- ターミナルから
defaults write com.apple.Dock autohide-delay -float 10.0; killall Dock
実行- マウスカーソルを画面端においてもすぐにDockが表示されないようにしている
- アクセシビリティ
- スクロールジェスチャと修飾キーを使ってズーム -> ON
- ディスプレイ
- カーソルのサイズ -> 1段階大きめに
- Finder
- 新規Finderウインドウで次を表示をユーザーフォルダに変更
- 前マシンでデフォルトの「最近使った項目」は活用した記憶がないので変更してみた
- すべてのファイル名拡張子を表示 -> ON
- 30日後にゴミ箱から項目を削除 -> ON
- 隠しファイル表示
- ターミナルから
defaults write com.apple.finder AppleShowAllFiles TRUE; killall Finder
実行
- ターミナルから
- 新規Finderウインドウで次を表示をユーザーフォルダに変更
- キーボード
- ショートカット->入力ソースショートカットを切る
- 使わないし、他アプリのショートカットとぶつかるので
- ショートカット->入力ソースショートカットを切る
Webからダウンロードしていれたアプリ
- Google Chrome
- Alfred
- AppStoreからいれると確かPowerpackをいれられないのでサイトからDL
- Workflowインストール
- SimpleTimer
- Localhost
- Snippet設定
:mail
でメールアドレスが展開されるように設定
- Google日本語入力
- Homebrew
- zsh
- JetBrains-toolbox
- ここからIntelliJ IDEA Ultimateをインストール
- 旧マシンからsettingsをexportしてimport
- ここからIntelliJ IDEA Ultimateをインストール
- Myrica (フォント)
- Rictyを使っていたけど乗り換えてみた
- VisualStudioCode
- Command + Shift + P -> Shell command install で ターミナルから
code
コマンドを使えるように設定
- Command + Shift + P -> Shell command install で ターミナルから
- InkDrop
- 最近試しているMarkdownメモアプリ
- Dynalist
- Zoom
- Docker
- Paw
AppStoreでいれたアプリ
- Countdown
- 最近試しに使っているタイマーアプリ
- GrandPerspective
- ストレージ利用状況確認用
- Virus Scanner Plus
- Toggl Desktop
- 1Password
- Slack
- LINE
- TweetDeck
- Xcode
- todoist
homebrewでインストールしたツール
ターミナルの設定
- フォントをMyrica 18ptに
- ログインシェル変更
/etc/shells
に homebrewでいれたzsh追加後、chsh実行- 参考:Macの環境設定(3) zshを入れる - Qiita https://qiita.com/nenokido2000/items/763a4af5c161ff5ede68
JJUG CCC 2018 Spring「JavaエンジニアのためのDocker入門」というタイトルで登壇しました
2018年5月26日(土) JJUG CCC 2018 Spring にて 「JavaエンジニアのためのDocker入門」というタイトルで登壇しました。もう大分日が経っているのですが、こういうのブログに残さないのよくない・・・と思い今更ながら記事を書いています。
別に私はDockerスペシャリストというわけではないんですが、自分が使って便利だと思ったので、基本的なことを改めて勉強しなおしてまとめたものを発表したという感じです。 まさかの一番大きい部屋(300人)を割り当てられてテンパりましたが、たくさんの人に聞いて頂いた分反響も大きく、大変いい経験になりました。ありがとうございました!
Scala関西SummitはScalaについての知見をみんなで持ち寄る場です
現在、Scala関西Summit 2018 1日目(セッション日)のトークを募集しております。
Scala関西Summit 2018 - 関西最大級Scalaカンファレンス 11/10(土),11/11(日)開催
現時点ですでに数本のトーク応募をいただいております。ご応募いただいた方ありがとうございます! ただ、運営的にはもっと多くの、もっと幅広い人からぜひトークをご応募いただきたいと考えております。 ですので、そういう趣旨のお話をします。
「勉強会で登壇する」ということに対しての一部の人の反応に対する違和感
これはScala界隈に限らない話なのですが、「勉強会で登壇した」「勉強会を主催している」というだけで、技術的に優れた、もしくは先を行っているエンジニアなんだと思われることが結構あります。
前者は、発表や資料をみた上でそう言ってくださる分には光栄だし嬉しい話なのですが、発表を見たことがない筈の人にまで言われることもしばしばです。後者に至っては技術力は全く関係ありません。
どうも、技術的に先を行っているエンジニアじゃないと「勉強会で登壇できない(しちゃいけない)」「勉強会を主催できない(しちゃいけない)」と思っている人が結構いるようです。
Scala関西SummitはScalaについての知見をみんなで持ち寄る場
少なくとも自身が開催する勉強会について、技術的にすごい人がすごい技術を教えるための場ではなく、みんなで知見を持ち寄って共有する場だと考えています。 そこに技術レベルの高低は関係ありません。 ですので、Scala関西Summitは「Scalaのすごい人にScalaを教えてもらうための場」ではなく「Scalaに興味があるみんなで、Scalaについての知見を持ち寄る場」です。
技術的に先を行っていなくても発表できると思われる内容の具体例
「そんなこと言われても自分ぐらいのScalaレベルじゃあ発表できるようなこと何もないよ!」という方もいらっしゃるかもしれないですが、例えばこういう話ならどうでしょう?具体例を挙げてみます。
未経験者やほぼ知識がない人に向けての基本の解説
私は割と最近覚えたばかりの技術について、「○○入門」みたいなタイトルで発表することが多いです。
先日東京で開催された JJUG CCC 2018 Spring では、JavaエンジニアのためのDocker入門 というタイトルでDockerの基礎についての発表をしました。
別に私はDockerのプロフェッショナルというわけではなく、当時利用歴も2、3ヶ月使った程度という浅さでした。ですが、基本的なことなら説明できると判断してトークを出しました。
いい加減なことを言うわけにはいかないので改めて勉強しないといけないことも多く、本を読み直したり人に聞いたり、資料も発表も念入りにレビューしてもらったり・・・とそれなりに大変でした・・・。ただ、自身の勉強にもなるのでヒィヒィ言いながらも機会があれば、こういう形で登壇チャレンジをしています。
またこのときは、まさかの300人規模の部屋で流石にプレッシャーも半端なかったのですが、それも含めていい経験になりました。(※ 参加者のアンケート結果で部屋の規模を決めたとのことなので、逆に言うと入門者向けがそれだけ需要があるってことです。)
それなりに大変なので「自分がやっているからみんなもやればいい」というようなことを言うつもりはないです。ただ個人的には、まだ深く理解していない技術の基本的なことを、自身も勉強しながらまとめて発表する人がもっと増えてもいいと思っています。
「こういうところでつまづいた」「うまくいかなかった」という知見の共有
去年のScala関西Summitでは「元インフラエンジニアがScalaを触ってつまづいたところ」というセッションがありました。 また私のセッションも、導入時にちょっとうまくいかなかった類(手伝ってくれた人からの評判がよくなかった)の話 でした。
こういった苦労したところ・あんまりうまくいかなったことの共有もとても意義のあることだと思います。
2017年のタイムテーブルはこちら。(動画へのリンクもあります。)
技術レベル関係なくいろんな人にトークを応募してほしい理由
すべての方がそうというわけではないですが、登壇する方は大体、最近自身が得た新しい知見を発表します。 ですので、例年公募で来るセッションは高度なトピックが多くなりがちです。
Scala関西Summitでは毎年スタッフやチャレンジしてくれそうな方に基本文法の解説やハンズオンを依頼しており、入門的な内容もカバーできるように努力しているつもりですが、幅広いレベル・テーマのトークが公募で集まるに越したことはないと考えています。
もちろん「そんなこと言われても自分には無理だ」という方もいらっしゃると思いますが、私のこの記事を読んで「そういう話なら自分にもできそうかも」「あ。そういう話で応募していいんだ。」と思った方いらっしゃいましたら、ぜひとも公式サイトのスピーカー応募フォームからご応募いただけますと幸いです。
応募、登壇に際して気をつけてほしいこと
記事の本筋からは外れてしまうのですが、これを読んで「登壇したことないけどチャレンジしてみよう!」という方に結果嫌な思いをさせてしまっても嫌なので、過去の自分の経験上「これは気をつけた方がよさそう」と思う点を書いておきます。
誤解を招かない発表タイトルをつける
私自身よく失敗するので説得力がないのですが・・・。
発表概要やターゲットを公開していても、発表タイトルで「思っていた内容と違っていた」と言われてしまうパターンは多いです。
タイトル以外の概要説明やターゲットなどがしっかり参加者の目に留まるようにして、ミスマッチが減るように改善はしていくつもりではありますが、そもそも気をつけてつけていただくのがまぁ一番かなぁと思います。私も気をつけます・・・。
応募したあと、いざ発表準備していたらタイトルと内容にどうしてもズレが生じてしまった・・・・!という場合は修正も承ります。(実際、過去に変更もありました。)とはいえあんまり大きい変更は困りますし、時期によっては印刷物の修正が間に合わないこともありますので、極力応募時にしっかりつけていただくのが一番です。
資料の文字は大きめにして、スライドの下の方は余裕をもたせる
これは当然、その方がスライドが見やすいからという理由になります。
個人的な主観を事実であるかのように言わない
これはかなり重要です。 根拠がない主観を事実のように語らないようには気をつけてください。
ありがちなのは、「xxは□□より便利」とか「(ベンチマークをとったわけでもないのに)○○は速いなどと発言してしまうパターンです。 根拠がない事柄については、「これは私の個人的な意見ですが」と、あくまで自分の主観である旨を事前に断ってください。 発表準備が整ったら、主語が大きくなっている箇所がないか、見直していただくのがいいと思います。
・
・
・
なかなかこれらは自分で気をつけても気が付けないことありますので、特に登壇慣れしていないうちは誰かにレビューをしてもらうのがいいと思います。私もたいてい、誰かにレビューを依頼しています。
「登壇してみたいけどレビューしてくれる人が周囲にいない・・・!」という方は Twitterとか でご相談ください。なんとかします。
公式サイトのイベント説明について
この記事を書くにあたり、 公式サイト のイベント説明を修正しました。 私達がScala関西Summitをどういうイベントにしたいか、どういう場にしたいか。これでより伝わればいいなと思います。
そう言うきの子さんはトークだすの?
私も本当はトークを出したいんですが、去年の振り返りシートを見ると「委員長はトークを出さない」という項目がありました・・・。(去年、自分のセッション準備に気を取られすぎてしまって、イベント自体の準備がおろそかになった部分があった・・・) 1日目のセッション日については、私は「みんながScalaの知見を持ち寄るための場作り」に注力しますので、みなさんどしどしご応募お願いいたします。
(なぜ1日目と明記したかというと、2日目の仕切りは他の人に担当してもらっているからです。2日目は私もできうる限りアウトプットもインプットもしていくぞ〜\( 'ω')/)
まとめ
Scala関西Summitでは初歩的な話から高度な話まで、Scalaにまつわる幅広いトークを募集しております!あなたのご応募をスタッフ一同心よりお待ちして!おります!!!締切は8/31(金)でーす!
5/9(水)「大正GeekNight」開催します! #TaishoGeek
5/9(水) 大正GeekNightというイベントを開催します。
5/9(水) 大正GeekNight Vol.1 - connpass
場所はJR大正駅近くのゲストハウス Hostel Nagayado OSAKA さんのイベントスペースです。
続きを読むOSSに初貢献した話 - ScalaMatsuri2018レポートその1 #ScalaMatsuri
3/16〜3/18 3日間に渡って開催された ScalaMatsuri2018 に参加してきました。 すっかり遅くなってしまったのですが、感想ブログを書いていこうと思います。
続きを読むScalaのOption.mapとKotlinのletの話
先日、Scala初心者向けの勉強会 を開催してそこで「OptionのforeachはKotlinのletみたいな使い方をするものですか?」という質問をうけたのですが、そのときKotlinのletをきちんと思い出せないままズレた回答をしてしまったので、とりいそぎブログを書くことにしました。(すみません・・・) 勢いで書いているので語弊がある部分があればご指摘いただけると幸いです。
続きを読む