ナガモト の blog

Full Cycle Developerを目指すエンジニアが有用そうな技術記事や、ポエムのようなよしなしごとを投稿するブログです。

「第4回 転職透明化らぼ-技術ブランディング編」参加レポート

先日、転職透明化らぼに参加してきました。 rtlabo.connpass.com

第1回から気になっていましたイベントでしたが、やっと初参加することができました。

参加した動機は私自身ジョブホッパーなので、自身のこれまでの行いを省みるため。また、現職ではエンジニア採用にも積極的に関わるつもりのため、改めて勉強しておきたかったためです。

イベントは異なる視点・ポジションのパネラーが3人呼ばれており、それぞれの発表とパネルディスカッション。また、イベントスポンサーの3社のLTが行われました。

パネラー発表

翔泳社 近藤 様 「メディアから見た技術ブランディングに効くコンテンツ 〜企業編・個人編〜」

冒頭にコール&レスポンスで会場を味方につけつつ、個人の印象を残すという戦略を実行しつつ、ブランディングをテーマにプレゼンしているところで説得力を感じました。

メディアの編集者だけあってとても理解しやすいプレゼンでした。技術ブランディングについてコンパクトにまとめてあるのでサクッと読めてしまいますし、私がどうこう説明するよりSpeaker Deckを見ましょうという感じです。

クラウドワークス 飯田 様 「技術ブランディングやっていきの会社が考えるフェーズ別戦略」

技術ブランディングについてなんとなく理解した気になっていることを丁寧に言語化し、目標とする状態とそのモデルとなる会社も認識して目標・ゴールを具体化しているところが素晴らしいと感じました。

また、組織としてのやっていきと、それを支える個人レベルでの工夫を合わせて紹介されていて、ためになりました。 背中を見せることと、いい意味でそそのかすこと、ぜひやっていきたいです。

mottox2 様 「プレイヤー目線の技術ブランディング

エンジニア個人(特にマネージメントではなく技術職として)の視点からの技術ブランディングに関するプレゼンでした。

「発信することで信頼の初期値が上がる」「最近のいい会社は採用にエンジニアが関わるからブランディング時に人事を意識する必要はない」はしっかり覚えておきたいと思いました。 また「まずは自分の活動透明化から始めよう」とプレゼンを綺麗に締めくくったところに、ソフトスキルも備えていてすげえなあと思わされました。

ご本人のブログを見るとより理解が深まると思います。

スポンサーLT

スポンサーであるゆめみさん、うるるさん、プレイドさんからも技術ブランディングについてLTいただきました。会社紹介だけでなく、知見を共有してもらえるのはとてもいいですね。

内容とは一切関係ないですが一番印象に残ったのはこちら。

パネルディスカッション

参加者から寄せられた質問に対してプレゼンター3名とモデレーターgamiさんがトークを繰り広げました。ネットラジオをやってるだけあってモデレーターに安定感があって聴きやすかったです。

以下、ディスカッションの内容メモです。 発言者がないものは発言者を覚えていなかったり、誰かが重要でない(全員同じ意見など)ものです。

Q. ブランディングを主導するのは誰?どの部門?

旗振り役、リーダは組織によるが、エンジニア全員が関与する。人事だけ、エンジニアだけということは基本ない。

Q. 発信の最初の一歩が難しい、どうするか

mottoさん「先輩にLT枠に申し込まれたことがきっかけだった。きっかけはなんでもいい。ブランディングやっている企業に入ればメンターが見つかる」

Q. SIのブランディング工夫

小規模な受託案件のAWS運用といった抽象化したノウハウ。受託開発は露出がすくないからこそやると差別化できる。

Q. 技術ブランディングで効果が出た施策

ありきたりだけどブログ。

mottoさん「広く知られるという意味では同人誌。仕事・内向けでは誠実な仕事をすること」

近藤さん「趣味を共有すると仕事獲得やキャラ付けにも役立つことがある」

Q. 採用するとき個人のアウトプットどこまで見る?

飯田さん「めっちゃ見る。アクセスできるものは全部見る。数年前からの積み重ねも見る」

Q. 実務経験がなくともブランディングになるか?

mottoさん「なりうる。独学だからすごい、すごくないじゃない。サービスやライブラリを作って評価(内定など)される人はいる」

Q. ツイッターに技術以外どの程度書いていいの?

自由でいい。

gamiさん「自分を毀損してしまわないか。そうでなければ自由でいい」

Q. ブランディングの指標

飯田さん「定性的にはOBに外からの評判を聞く」

近藤さん「ブログのPVをKPIにするのは危険(炎上へのインセンティブになる)。登壇の誘いなどアウトプットへのアウトカムを指標にしている」

Q. 広く使われている技術でどう差別化するか

近藤さん「導入ハードルの高い受託やレガシーなところでの試行錯誤は反響が大きい」

飯田さん「巨大なモノリスRailsアプリに立ち向かう会社は多いが、どう立ち向かったかのアウトプットは差別化できるのではないか?」

mottoさん「深みのある話ができるならそれをやる。深みのある話は個人では難しいが会社ブログならできそう。個人では差別化できないならしなくてもいい」

所感

期待していた通り、ブランディングに関する学びとその整理ができました。最近サボりがちな自分に喝を入れることもできてよかったです。

また、懇親会で人事の方から「面接やカジュアル面談後の【湯上り感】を大事にしている」という話を聞きました。自分の過去の経験からも【湯上り感】はとてもしっくりきたし、いい言葉だと思いました。

2019年あと1ヶ月と少し頑張っていこう。

余談

書き終わってから他の参加者の記事に気づいたのですが、下記ブログが私より早くよくまとまっておりました! naipaka.hatenablog.com

RubyKaigiはテク良い、RubyWorldはエモ良い【RubyWorld Conference2019参加レポート】

RubyWorld Conference 2019に参加してきました。

RubyWorld Conferenceは初参加でしたが、参加してよかったとはっきり言えます。弊社には感謝です。

感想を一言にするならばタイトルの通り「RubyWorldはエモ良い」になりますが、せっかくなので参加してきた感想をもう少し記事に残しておきます。

RubyKaigiと全然違うのが面白い

RubyWorld Conferenceは全体の印象としてテクノロジー寄りではあまりありません。 RubyWorld Conference 2019 開催趣意書を見ればわかると思いますが、人間を無視しないプログラミング言語であるRubyが非エンジニアも無視せず、巻き込んでいく、繋げていくためのカンファレンスのように感じました。

技術的な内容のセッションもありましたが、頭が疲弊するような難易度の高いセッションが続くことはありませんでした。

想像以上のエモさ

前述のRubyKaigiとの違いや、エモい話が聞けるというのは事前に知り合いから聞いていました。 ただ、事前に聞いていても驚くほど想像以上にエモかったです。より正確に言うと想像以上に心にくる、刺さるスピーチをいくつもあったという感じです。

これまでRubyコミッターのことは高い技術力をもって淡々とRubyを改善しているクールなエンジニアのような印象を勝手に抱いていましたが、Ruby Prize 2019を受賞した糸柳さんのスピーチを聞き、相当な熱意と共に情熱的に難しい問題に取り組んでRubyを進化させているのだと感銘を受けました。

糸柳さんのスピーチに限らず、全編通してRubyとそのコミッター、そしてコミュニティへの感謝の気持ちを再認識させられました。

感情が溢れたツイートたち。

自治体の理解・後押しがすごい

オープニングセレモニーでは知事、市長、官庁ら来賓からの挨拶がありました。その内容がよくある当たり障りないお偉いさんの挨拶ではなく、Rubyという言語とその利用シーンをある程度理解した上で、今後にどんな期待をしているか、どんなサポートをしていくつもりでいるかを示してくれました。

なんと頼もしいことでしょうか。 地方では京都や福岡に勢いがありますが、松江にも可能性を感じさせられました。

来賓挨拶へのリアクション

プログラミング教育・エンジニア育成への取り組みがすごい

セッションの中で数も多く、個人的に目立っていると感じたのは教育・育成をテーマにしたものです。 DIVE INTO CODEさんのルワンダでの取り組み、高専や大学の教育に協力するモンスター・ラボさんの事例、CoderDojo Japanさんの全国的な取り組みなどのお話を聞けました。

低い敷居でほとんどの人に平等にチャンスがあるというのはプログラミングの長所だと思いますが、さらに平等に、さらに敷居を低くする活動・環境整備を進めている人がこんなにもいる。社会が良くなっているように感じました。

その他個人的ハイライト

最後に

来年も行くために、エンジニアリングを頑張って、ビジネスで数字をあげて、継続的にスポンサーできるようにしていきたいです!

MacにPlantUML + Visual Studio Codeでモデリング環境構築(OpenJDK version)

以前PlantUML + Visual Studio Codeモデリングする環境構築の記事を書きました。 ngmt83.hatenablog.com

先月新しいパソコンに同様の環境構築をしようとして詰まったので、異なる方法をメモとして残しておきます。

なお、これらの事項については先述の過去記事をご覧ください - PlantUMLとは何か - UMLとは何か - PlantUMLをおすすめする理由

過去記事と同様に環境構築できなくなった理由

Java SE Development Kitのダウンロードにアカウント登録が必須になっていたためです。

有料というわけではなさそうですが、アカウント(Oracleプロファイル)作成のフォームで心が折れました。

f:id:ngmt83:20191024190928p:plain
Oracleプロファイル作成フォーム

必須項目を表す*が全項目にありますね…

ツールを使わせてもらうのですから、私の個人情報なんて安いものだと思いますが、勤務先の情報になると話は別です。*1

とそんな事情で他のJava Development Kitを探しました。

無償のOpen JDK

巷では「Javaが有料になった、Javaはオワコン」なんて騒がれましたが、Java全てが有料になったわけではありません。ありがたいことに無償で利用する方法も用意してあります。感謝しながら使いましょう。

Open JDKはこちらから該当のVersionをダウンロードしましょう。 jdk.java.net

この記事では2019年10月時点で最新の安定板であるJDK 13.0.1 GA Releaseを例に進めます。

Open JDK 13をインストール

この章についてはわかりやすい記事があったため、そちらを参考(ほぼ同じ)にしています。

digitalmania.info

まずJDK 13.0.1 GA Releaseをダウンロード・解凍します。するとjdk-13.0.1.jdkというフォルダが作成されるのでそれを適切な場所*2へ移動させます。 私は標準的な配置・設定を好むのでよく用いられる/Library/Java/JavaVirtualMachinesにおきます。シェルからの操作例は次の通りです。

sudo mv jdk-13.0.1.jdk/ /Library/Java/JavaVirtualMachines

java_homeコマンドから正しくOpen JDK 13が認識されているか確認できます。

/usr/libexec/java_home -V

そしてjavaコマンドで実行されるようにPATHを通します。

export JAVA_HOME=`/usr/libexec/java_home -v 13`

これでjavaコマンドが実行されるようになりました。下記のコマンドでversionまで確認できます。

java --version

Graphvizをインストール

brew install graphviz

PlantUMLをインストール

brew install plantuml

VSCodeにエクステンションをインストール

marketplace.visualstudio.com このエクステンションはとても便利なのでぜひインストールしましょう。

「option+d」でプレビューを見ることができます。

「command + shift + P」からPlantUMLコマンドを検索すると「ダイアグラムをエクスポート」できることがわかります。png画像での出力などを簡単にできます。

所感

Javaでいろんなツールが作られているのでOpen JDKといった形で無償で利用できるのはとてもありがたいです。

最近はとても複雑な状態管理をPlantUMLで状態遷移図(State diagram)に落とし込んでわかりやすくしています。モデリング言語を扱えるように勉強しててよかったなと噛み締めています。

*1:電話番号なんかはそもそも公開していないことすらある

*2:実際にはPATHを通せばどこでもいい

見積もりって難しい。過小見積もりをやらかしたので省みる

9月半ばに新しい会社に入社して、初めてそこそこ大きめの機能をメインで実装することになり、そこで目一杯やらかしました。

やらかしたのは過小見積もりです。見積もりは完璧にできるわけはないし、完璧を目指してはいないのですが、今回は特にひどすぎました。

リアルタイムなツイートがこちら。

雑に例えると「ストーリーポイントで8ポイントと見積もったにも関わらず、実際やってみたら34ポイント相当だった。」「予想の3倍以上労力がかかった。」という具合です。

さすがにこんなことを繰り返すのはまずいので何故これほどの過小見積もりが起こったか振り返り、原因・要因など心当たりをブログに残しておきます。*1

前提

私がいるチームは1ヶ月前は3名程度だったのが、今は5名程度*2になり、これからチーム開発するための態勢を整えていくという状況。 メンバー全員が1人で大抵のことをできる中、みんながやりやすいようにプロジェクトの進め方を手探り中。

メンバー構成は業務委託で協力してくれる人が複数人、複数社。正社員エンジニアが2名。*3 委託でコミットしてくれているメンバーはそれぞれ拠点があるため、複数拠点のリモートチーム状態。

見積もりはいくつか基準となるIssueがXポイントであると軽い共通認識を作った上で、実装担当者が取り組むIssueに相対的なポイント設定をする。 今はベロシティを厳密に追っているわけではない。

上記の前提で原因をざっくり技術面・メンタル面・他にわけて心当たりをあげます。

技術面

エンジニアリングの見積もりなので、当然ですが技術的な原因には心当たりがありました。以下のような原因が思い当たりました。

  • 採用されている技術を正しく織り込めていない
  • 類似実装部分の読み込みが足りない
  • 基準となるIssueのXポイントをAさんのY時間に置き換えてしまう

採用されている技術を正しく織り込めていない

私は前職ではAngularを用いていわゆるSPAとAPIサーバという構成でアプリのフロントを実装していました。今関わっているサービスはサーバーサイドのフレームワークにフロントも含み、複雑でないJavaScriptで実装されています。*4

しかし、入社したてということもあってかIssueを見積もる際に私は 「(Angularだったら)これをああやってえいってやればいいから…5ポイントだな」 と誤った前提で見積もってしまいました。フロントの実装中に大変すぎると感じてやっとこの過ちに気づきました。

類似実装部分の読み込みが足りない

アプリの改善や機能追加では既存の機能で使っているモジュールやライブラリを転用できることがよくあります。私はドックフーディングを通してどんな機能がどの辺りにあるか概ね理解できているつもりでいました。そのため、見積もる際に 「既存の機能Aと似た実装でいいはずで、多分〜な感じだろうし、もし予想が外れても既存のコードみたらどうにでもなるっしょ!5ポイントだな」 と甘々な見積もりをしてしまいました。

似てるように感じても実際には違っていたり、追加機能のほうがより高度なライブラリの知識が必要だったり、膨らむことが多いです。類似実装の読み込みと実際に書いてみるのは大事です。

基準となるIssueのXポイントをAさんのY時間に置き換えてしまう

ストーリーポイントは工数ではありません。Issue同士の比較による相対見積もりです。これを理解していても油断すると勘違いしてしまいます。

「5ポイントのIssue XをAさんは半日で終わる。」という情報から無意識に「Aさんは10ポイント/日」と誤認してしまうと危険です。 半日で終えられるのはサーバーサイドで完結するIssueだけかもしれないし、仮にサーバーサイドについてAさんと私が同じような生産性だったとしても、フロントはそうではないはずです。

ポイントは工数ではなく、Issue間の相対見積もりでしかない。Issueの締め切りが心配な場合はポイントを設定した上で、実装方法・使用技術・自分の習熟度を加味して締め切りに間に合いそうか考えましょう。 「自分にとって時間がかかりそうな部分がある」程度の共有でも周りにとってはありがたいはずです。

メンタル面

自分の気の持ち方が見積もりを見直す機会を潰してしまったと感じたことがありました。以下のような考え方によくないところがあったと思います。

  • できるかどうかじゃない、やるんだよ。履き違えたポジティブ
  • このくらいはできるはず、活躍してやるぜ。期待に応えたがり

できるかどうかじゃない、やるんだよ。根性ポジティブ

過小見積もりに気づき始めた時、メンバーから「間に合いそうですか?」「大丈夫ですか?」「(期日までに)できますか?」*5といった声をかけられました。そんなとき私は、 「できるかどうかじゃない、やるんだよ」 と冗談半分に返していました。辛い辛い言いながらやるより、暗くならないし捗るからこうやって言うのですが、この言葉・考え方のせいでもっとよいリカバリの機会を逃していたのではないかと思います。 やるしかないことは楽しく、勢いよくやったほうがいいですが、もっと良いやり方があるはずのときにポジティブを履き違えた考え方をするのはもはや思考停止でした。

このくらいはできるはず、活躍してやるぜ。期待に応えたがり

人は第一印象で決まるとよく言われますが、仕事においては入社後すぐにインパクトを与えらえるとその後がとてもスムーズになるでしょう。 また、自身のキャリアが5年になり、リードエンジニアへとステップアップしたいと考えている私は焦りすぎていました。

その焦りが実力を過信させたかもしれないし、チームに入った直後に普段通りの成果をあげられないという普通のことを見落とさせたのかもしれません。活躍するつもりで今後もやっていきますけどね!

当たり前のことばかりな上にまとまりがないですが、ブレスト的にあげると次の通りです。

  • 入社直後は予定が読みにくく(自分が忘れただけの場合もある)、開発にあてる時間が少なかったり変動する
  • 環境が変わったあとリズムをつかむのには思いの外時間がかかる
  • 得意な技術スタックでもローカルコーディングルールや採用したデザインパターンの差異はじわじわ効く*6
  • リモートチームによって露呈する自分のコミュ力不足

環境を変えたらオーバーヘッドがあるのは当然だという話と、リモートワークではコミュニケーションがより重要になるという話です。

どう対策するのか?

対策は思いついてないです。あったらぜひ教えて欲しいです。仕組みには至らない気をつける程度であれば次の通り意識していきたいです。

  • 実際に30分くらい手を動かして見積もる
  • わからないかもしれない・時間がかかる可能性を早く共有する
  • 認識できていない不慣れもあると考える

見積もりに少し時間を割くことでずれを小さくできます。また、早い共有で見積もりの更新やリカバリする機会を作れるかもしれません。わからなくなってから、時間がかかってから共有するよりも心理的ハードルが低いというのも良い点です。不慣れについては認識できないものもあります。認識できない不慣れが影響を及ぼしていることを理解していれば、差異がでたときも冷静に対応ができそうです。

最後に

完璧な見積もりはありえません。完璧がないからこそ、完璧に近づける努力をしていきましょう。

*1:当然チームでの振り返りもします

*2:フルタイムでない業務委託の人など1人とカウントするか判断が難しい

*3:みんな委託とか社員とか関係なく、主体的にどんどん進めてくれる人たちでありがたい

*4:現段階においてこの選択はとても正しいと思う

*5:「Issue分けましょう」などの具体的なアドバイス、助力も受けました。ありがとう

*6:どんなときもベストなコーディングルールはないし、良し悪しの話ではない

MacBook Proオレオレ初期設定 エンジニア編

先日エンジニアリングが関係ない初期設定の記事を書きました。この記事ではエンジニアの環境構築について備忘録的に書き残します。

関連の記事はこちら ngmt83.hatenablog.com qiita.com

環境

ゴール

色んなエンジニアが使用している or 色んなエンジニアに勧められる初期設定を終えた状態。

具体的にはターミナル, Docker, GitHub, エディタ(VSCode), DBを扱いやすい状態です。

特定のプログラミング言語などの具体的な開発環境については記載しません。

ターミナル

  • Xcode(Command line tools)
  • iTerm2
  • Homebrew
  • Fish shell

最近はXcodeをインストールすればCommand line toolsもついてくるので、特に意識せずインストールするだけでいいです。*1

iTerm2は下のリンクからダウンロードして使用します。 www.iterm2.com

Homebrewをインストールします。サイトに記載されている通りのコマンドでインストールできます。

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

brew.sh

Fish shellをHomebrewを利用してインストールし、デフォルトのシェルをFishに設定します。

brew install fish
echo "/usr/local/bin/fish" | sudo tee -a /etc/shells
chsh -s /usr/local/bin/fish

Docker

サイトの通り、ダウンロードしたインストーラの指示通りに操作するだけなので、特に説明はありません。

GitHub

  • ssh key gen
  • GitHubに公開鍵登録
  • Git config user.name email設定

ターミナル上での操作は次の通りです。

# sshキー作成
ssh-keygen -t rsa -b 4096

# Gitで使用する名前, email設定
git config --global user.name "名前"
git config --global user.email メールアドレス

GitHubへの公開鍵登録はWEBページに従ってください。

エディタ(Visual Studio Code)

  • VSCodeインストール
  • VSCodeコンフィグ
    • 半角スペース可視化
    • タブスペース設定
    • shell fish化
    • コンフィグ共有
  • VSCodeエクステンション
    • Docker
    • PlantUML

エディタは各々が好きなものを使えばいいと思います。しかし、VSCode以外にメインエディタがあっても、利用者が多く、ペアプロにも便利な機能を持つVSCodeをサブとして使用できるようになっている方が望ましいです。

まずはこちらからVSCodeをインストールして、コンフィグやエクステンションを設定しましょう。 code.visualstudio.com

コンフィグ

VSCode内のターミナルで利用するシェルとタブで挿入される半角スペース数、半角スペースの可視化を設定します。

{
  "terminal.integrated.shell.osx": "/usr/local/bin/fish",
  "editor.tabSize": 2,
  "editor.renderWhitespace": "all",
}

エクステンション

便利なエクステンションはいくつもありますが、より汎用的なDockerを扱いやすくするものと、設計で活躍するUML作成に役立つものをインストールします。

marketplace.visualstudio.com

ngmt83.hatenablog.com

PlantUMLの動作環境構築については次の記事を参照ください。 marketplace.visualstudio.com

DB

  • DBeaver入れる
  • Dockerのコンテナ MySQLと接続する

サイトからダウンロードするだけのため非常に簡単です。 dbeaver.io

もしDocker composeなどで設定済みであれば、開放されているポートを設定してください。 DB接続用のユーザ名やパスワード設定もしましょう。

最後に

今回はさらに効率的で理想的な環境はおいておき、多数にとってベターな共通設定にのみ目を向けました。設定漏れに気付くのは大抵後のことなので、気づけばこの記事を更新するかもしれません。

MacBook Proオレオレ初期設定

9月中旬に新しい会社に入社し、久しぶりにMacBook Proの環境構築をしたので色々忘れないようにここに書き残しておきます。

この記事ではエンジニアリング環境については触れません。Macを使う人ならほぼ全員が使えるものばかりです。 (向き不向き、好き嫌いがあるのでおすすめは特にしない)

設定は大きく3つにわけられます。

  • システムと環境設定
  • 便利アプリ設定
  • Chromeエクステンション設定

環境

システムと環境設定

箇条書きにすると次の通りです。

  • Touch ID設定
  • Apple IDログイン
  • Dock設定変更
    • 『自動的に表示/非表示』有効化
    • 『最近使ったアプリをDockに表示』無効化
    • アプリ整理(削除)
  • Touch Barファンクションキー化
  • トラックパッド周りの設定変更
    • 副ボタンのクリック 二本指
    • ホットコーナーで画面をロック
  • キーボード設定
  • ディスプレイの配置設定
    • 外部ディスプレイをミュートする

Touch ID設定

指を置くだけでロックが解除されるのは非常に楽です。すぐ設定しましょう。

Apple IDログイン

購入したアプリや、iCloudを利用する場合に必要です。

Dock設定変更

デフォルトだとDockがずっと表示されたままです。画面を無駄に専有されている感じが嫌いなので、自動で出たり消えたりするように設定します。 また、たまにしか使わないアプリを使用した後、Dockに常駐するのも好きじゃないので、非表示にします。設定画面は次の通り。

f:id:ngmt83:20190926225351p:plain
Dock設定画面

あとは、デフォルトでDockに表示されているアプリから使わないものを削除します。SafariとかメールとかPagesとかいらないです。

Touch Barファンクションキー化

私はTouch Barをほぼ使いこなせていないため、タイピングに便利なFキーに変更しています。 また、音量調整や画面の明るさ調整をスムーズにするためにFnキーを押したときはControl Stripを表示するようにしています。設定画面は次の通り。

f:id:ngmt83:20190926230012p:plain
Touch Bar設定

トラックパッド周りの設定変更

トラックパッドの右下や左下のクリックが下手なので指2本のクリックを副ボタンクリックに設定します。

f:id:ngmt83:20190926230605p:plain
トラックパッド設定

また、簡単に画面をロックするために右下にホットコーナーを設定します。セキュリティの関係上ちょっと離席をする場合もロックしたほうがいいですし、実際にそういったルールが存在する職場もあるのでけっこう重宝する設定です。Touch IDを設定していればロック解除も楽ちんなので、PCから離れるときは画面ロックする習慣をつけましょう。

f:id:ngmt83:20190926230950p:plain
ホットコーナー設定

キーボード設定

ライブ変換をストレスに感じるならオフにしましょう。もしくはGoogleの日本語入力をインストールしましょう。

f:id:ngmt83:20190926231852p:plain
キーボード設定

www.google.co.jp

便利アプリ設定

パスワード管理アプリとウィンドウ整列アプリは個人的に必須だと思っています。パスワード管理アプリのためにDropbox*1も入れます。この記事では最小限のDropbox、KeePassX、Magnetの3つを設定します。

Dropbox設定

Mac用のアプリのインストールとログインまでしましょう。Finderで確認できるようになれば設定完了です。

f:id:ngmt83:20190926233739p:plain
finder

KeePassX設定

アプリをダウンロードして、Dropbox等の自分が使用しているクラウド上のデータベースを開きましょう。*2 www.keepassx.org

Magnet設定

Appストアからダウンロードしましょう。*3

Magnet マグネット

Magnet マグネット

  • CrowdCafé
  • 仕事効率化
  • ¥250
apps.apple.com *4

私は左右2分割やメインディスプレイとサブディスプレイの行き来*5に左半分や右半分をよく利用するので、「command + option + カーソルキー」で上下左右半分になるようにします。commandとoptionはキー同士が近いのでおすすめです。

f:id:ngmt83:20190926235121p:plain
Magnetの環境設定

Chromeエクステンション設定

Safariは即座にDockから消してChromeを入れましょう。そして便利に使うためにエクステンションを設定しましょう。おすすめのエクステンションを紹介します。

Awesome Screenshot

名前から分かる通り、スクリーンショット撮影のエクステンションです。無料で十分な機能が使えますし、機能が多すぎて使いにくいわけでもなく、おすすめです。

chrome.google.com

OneTab

ブラウザで開いているページをリンク集としてまとめてくれるエクステンションです。ウィンドウやタブを開きまくる人には特におすすめです。 WEBページとして公開することもできるので、複数のページをスマホ実機で見たいときや知人にメッセージで共有したいときに重宝します。

chrome.google.com

esarea

Markdown記法*6をアシストしてくれるエクステンションです。esaを使っていなくても便利に使えます。GitHubのIssueやPRにMarkdownで書くときもアシストしてくれてとても便利です。

chrome.google.com

Copy as Markdown

Markdown記法でリンクを書くときに、[リンクテキスト](URL)の形式に手打ちするのはそこそこ面倒です。このエクステンションはそれを簡単にしてくれます。

chrome.google.com

例えば先ほど紹介したesaのページを開いたタブで使用すると次のような文字列をクリップボードにコピーしてくれます。

[esa - 自律的なチームのための情報共有サービス](https://esa.io/)

最後に

まっさらだったパソコンが自分色に染まるというか、手足として馴染んでいく感覚は少し気持ちがいいですね。

みなさんのおすすめ設定があればぜひ@ngmt83に教えてください。

*1:好きなクラウドストレージでいい

*2:1Passwordもいいらしいですね

*3:Windowsはデフォルトでウィンドウ整列ショートカットがあるのにMacにはなぜないのか

*4:ウィンドウ整列アプリはいくつかあるので好きなのものでいいです

*5:たまにしか使用しないプロジェクターのときにウィンドウを見失わないで済むのでおすすめ

*6:エンジニアじゃなくてもMarkdown使いますよね?使ってない?使えると捗りますよ!

技術書典6の「個人開発がやりたくなる本」はエモいい!

例えば元高校球児の描く野球ものはリアリティがあって野球経験者は共感しやすいだろう

例えば学園もので描かれる青春はある種ファンタジーとも言えるような憧れがつまっているだろう

「個人開発がやりたくなる本」にはそんな共感と憧れがある

by 弱小エンジニア

booth.pm

つい黒歴史になりそうなポエムを書いてしまいましたが、「個人開発がやりたくなる本」はいいぞ!ってことが言いたかっただけです。

「個人開発がやりたくなる本」ってどんな本?

サブタイトルにある通り「個人開発者13名によるエッセイ集」です。

執筆者それぞれが思い思いの構成で、ある人は熱く、ある人は淡々と、またある人は享楽的に綴っているのです。

技術要素もあるし、学びはたくさんありますがエッセイ集という表現は適切でしょう。

だがそれがいい

なんで読もうと思ったの?

個人開発したいと思いながら行動に移せない私は技術書典6でこの本をチェックしていましたが、物理本を完売で手に入れられませんでした。電子書籍を買おうか悩んでいたところに@dala00さんの「本の予備?があるのあげます。Crieitに感想でも書いてもらえたら嬉しいです」という主旨*1のツイートを見かけたのですぐにDMして送っていただきました。

本は4月にもらってGWには読み終わり、既に2周以上しています。*2

感想がこんなに遅くなった(すみません)のは「この本を読んで私もアプリが作れました(ドヤ)」をやりたかったからです。

で、アプリは作れたの?

自作アプリを3つ!作りかけて凍結しています……

本を読む前はリポジトリ作成すらできていなかった私にとってこれは進歩です!読んでなければ1つも着手できていなかったでしょう。

作りかけて凍結した理由はプライドが無駄に高かったり、あれやこれや機能を詰め込もうとしたりでゴールできなくなったためです。ちなみにこれは7章で作り終わらない原因の1つとして紹介されています。

おすすめは何章?

全部です。

十人十色の個人開発者達なので「わかるうううううう」と感じる章も「そういう考えの人もおるんやな」と感じる章もあります。 プロフェッショナル 仕事の流儀情熱大陸を彷彿とさせる章があるかと思えば、文字通りのクソアプリ*3が紹介される章もあります。 章ごとに全然違うのです。 しかしこの違いはとてもためになる違いだと思っています。

人によって好みはあるでしょうし、仮に1章しか響かない人もいるかもしれません。しかしその分、その1章はハマるでしょうし、1章のためだけに買う価値もあるでしょう。

内容紹介薄くない?

引用したい箇所は多すぎて冗長になるし、感じることは人それぞれだと思うのであえて触れていません。自分の目で確かめてくれ!ということです。

とはいえこのままでは書籍紹介記事としてあまりに不親切なので参考になりそうなリンクを以下に貼っておきます。

crieit.net

blog.warally.info

togetter.com

購入はこちらから!

booth.pm

(多分BOOTHで買った方が執筆者に還元されやすいです。)

最後に

もうすぐ技術書典7だけど技術書典6の本を読んだっていいじゃない!

むしろ技術書典7の戦利品で学んだ知識・技術を生かし、個人開発がやりたくなる本を読みながら自作アプリを作り上げましょう!

*1:元ツイートは削除済みのため記憶は曖昧

*2:ところどころ読み返したくなる本です。

*3:つんつくつん