よこなのへたのよこずき

noteもよろしくね

株式会社マイクロアドを退職しました

退職 雑談

しました。正確には、します。

2015年3月1日に入社したマイクロアド、2017年4月27日が最終出社日でした。5月15日から次の会社でお世話になります。

マイクロアドはプログラミングをはじめ技術者として必要な基礎が全くない私を採用し、育ててくれた場所です。感謝の気持ちと愛はとどまるところを知らないぜ。

これまでを振り返る

入社してからの3ヶ月

PCを作ったりJavaで課題をやったりSwiftでアプリを作ったり小さな案件を担当したり・・・色々お勉強の期間でした。
日々新しいことが分かる喜びにわくわくしつつも、前の会社(そこそこ大きいSIer)との雰囲気のギャップに戸惑い、必要以上は喋らないようにしたり、お手洗いとかもコソコソ行ったり、それはそれは大人しく過ごしていたのが懐かしいです。

3ヶ月経ったとき

京都オフィスへ移りました。期間的にも、内容的にも、私のマイクロアドライフは京都での生活がメインで、オフィス、メンバー、町、すべてが本当に大好きです。
マイクロアドのサービスの根幹とも言える、広告配信サーバの開発を担当し、Scalaにも出会い、チャレンジングな日々を過ごしました。特に初めてScalaの案件をやったときは慣れるのに時間がかかって、一生終わらないのでは・・・と焦ったのを覚えています。

大事なことをたくさん教わりました。分かりやすい例で言うと、読みやすいコードを目指すこと、テストを書くこと、コードレビューをすること・・・「コミュニティではよく聞くけどやったことがなかったもの」が当たり前になって、開発の楽しさ、学ぶことの面白さ、先輩の偉大さなどを日々感じていました。

経験も技術もあるメンバーに囲まれていたのもあって、開発だけではお役に立てないと思い、自分が出来ることや得意なことを見つけることの大事さにも気付かされました。自分の場合はせっせとwikiを書いたり*1、広報や採用の方も頑張ったり、営業さんと話をしたり、コミュニティ活動したり…そのあたりは、マイクロアドにおいて他のエンジニアに負けないくらい丁寧にやってきたつもりです。
余談ですが…↑こんな感じで外向けに色々やってきた結果起きたいいことの話。ある営業さんが「怪しい会社かと思ったけどよこなさんがいる会社だから大丈夫ですね」って話聞いてもらえたことがあるんだそうです。これは本当に嬉しかったです。ちょっと話盛ってるかもしれませんがw

いやぁ話を戻しまして。移住したての頃すごく楽しかったなー。思い出が美化されているだけかもしれませんが、大した責任もなく守られた存在だったのでしょう、毎日呑気に幸せに暮らしていました。引っ越した2015年夏の明るい京都オフィス(大きな窓があるのです)のようすが目に焼き付いていて、時々とてもハッピーな光景として思い出します。きっと一生忘れないと思います。

あと京都メンバーとは美味しいものたくさん食べにいったし、旅行もしたし、ビール工場も行ったし、おうちにもお邪魔させていただいたし、仕事以外の思い出もいっぱいです！

1年ちょっと経ってから

あるとき、それまでのように京都のチームで仕事をする体制が終わりました。試験的にスクラムでの開発をやってみるチームに入れてもらい、(今思えばそういう構成は避けたほうがよかったかなと思うものの)東京のメンバー10人弱と京都の自分というメンバーで1つのプロダクトを担当することになります。扱うシステムも、配信サーバのみならず、広告の管理画面とかログの転送処理とか、多岐に渡るようになりました。

ここからは少し大変でした。京都では自分だけ違うチームに属している、スクラムをやるチームでは自分だけ京都にいる、という形になってしまったので、どこにも100%の所属意識がなくなったというか、妙な疎外感があったというか、まぁしばらくは辛かったです。
ですが、それは自分にとってマイナスではなくて、常に「どうしたらいいかなー」を考えさせてくれる成長の機会でした。そして、メンバーと意見交換し、ちゃんと分かってもらって少しずつ改善も出来ました。今も東京で同じメンバーと仕事をしていますが、本当にいい雰囲気で、楽しく働きやすいチームです。多分社内で優勝。(と思っているｗ)

あとは先に述べた通り色々なシステムを見るようになったのも勉強になりました。それまでやってた広告配信サーバは、リクエストを受ける→DBに登録されている情報を参照する→色々処理するｗ→レスポンスを返すというのが役目ですが、じゃぁそのDBのデータはどこからくるのかというと管理画面なわけです。しかし完全分業だった頃は管理画面の仕様などほぼ知らないまま作業していたので、処理の意味がよく分からなかったり、これは仕様だ・・・と曖昧なまま片付けていたりしたことも多々ありました。
システム間の関わりを理解出来るようになってからは案件の目的が分かりやすくなったり、提案の方向性を定めやすくなったりした気がしています。また、営業さんと話すたびに、コアの部分な開発だけでは自分がやりたいことは出来ない*2と感じていたため、新たな視点を身につけられたのはありがたいことでした。

スクラムが始まった頃を振り返ると、チームとしても個人としてもよくなったことがたくさんあるなぁと感じます。もちろん現実は美しいだけのものではなく、誰かとぶつかることや愚痴を言うことやお酒を飲みすぎる*3ことは幾度もありましたけども。

最後の3ヶ月くらい

東京に来ました。京都が好きすぎて考えないようにしていましたが、やっぱり新しい体制で上手く仕事をやるには東京に来たほうが色々スムーズなのは明らかだったので心を決めました。

移動してからは、チャットに長文を打たなくても人とコミュニケーションが取れるってこんなに素晴らしいんだな、と改めて感じる日々でしたｗ*4仕事だけじゃなく、ランチ一緒に行こうぜとか、対面でしか分からない面白いネタを共有できるとか、そういうところにも私は結構幸せを感じていました。「ちょっと私コミュニケーションに飢えてます」とか言って、毎日たくさん話していた気がします。

スクラムもより上手く回るようになりました。まだまだこれでOK！とは言えないかもしれません*5が、皆で考えながら良くしていけていました。

つまり

働きやすくていい会社だったなと思います。もちろんプンプン٩(๑`^´๑)۶ということもたくさんありましたよ。でも今思えばあまりに些細なことか、自分の視野が狭く未熟なだけだった気がします。
学んだことたくさん、素晴らしい出会いたくさん、やっぱり感謝がつきません。

ついでに入社前のこと

転職のとき、マイクロアドの面接は一発目でした。直感でここがいい！と思って、でも一応ほかも見てみて、やっぱり結局入社してました。内定をいただいたときのウキウキは忘れません。 そういえば面接も印象的で、メモ取ろうとしたけど持っていったボールペンのインクが絶望的になく、仕方ないから筆圧高めに書いてあとで何とかしようって透明のノートを生成していた記憶があります。「え、あぶり出し風？」と面接官がペンを貸して下さいました。そんな奴が面接に来たら気持ち悪いだろ、と強く思いますがあたたかいですね・・・(恥ずかしい)

そして、何の力もないけどついていけるかな、とか、間違って採用したのではないか、面接官を騙してしまったのではないか、ととにかく自信がなくて異常な不安とともに入社を待ったなーとｗあははは・・・
転職先は不安なくらいがいいよ、きっと。

これからを簡単に語る

次

決まっています。スタートアップです。というざっくり。詳細はまた少しずつ明らかにします(ということでご存知のみなさま、入社するまではオフレコでお願いいたします〜)。

何故また転職を

2年ごとに仕事を変えて、ジョブホッパーを目指しているわけではないんですよ・・・

まだ形が出来ていないものを作り上げる、という挑戦がしたかったこと。この人と働きたい！という方のいらっしゃる職場に身を置けるチャンスをいただけたこと。色々ありますが、この2つが大きいです。
そこそこ歴史もあり組織が大きくなっているマイクロアドとは違ったことが出来るのではないかなと思い、割とスピーディに決めてしまいました。しばらくは転職するつもりもなかったので、自分でも意外な、しかし幸運な出来事です。この会社にこのフェーズで入るチャンス、逃すわけにはいかない！！！という感じです。わっくわく。

行った先で自分にどんなことが出来るのか、どうやったら価値を出していけるのか、まだぼんやりとしたイメージしかありませんが、がむしゃらに頑張って見つけていきたいと思います。

さいごに

転職を検討するにあたり、色々な方にお話を聞かせていただきました。
世の中にはどんな会社があるのかなー、皆さんどんなことを考えて働いているのかなー / 会社を選んでいるのかなー、とか先輩方に聞いてみたくて、主にJavaコミュニティの皆さんに声をかけまくって、勉強させていただきました。貴重なお話聞かせてくださった方々、会社にお誘いくださった方々、本当にありがとうございました＞＜何かで恩返しできたら幸いです。

引き続きどうぞよろしくお願いいたします！

やってみたかったやつ

ウィッシュリスト

('ω')ｳﾌﾌ

いや〜長くなってしまった―

*1:あまりドキュメントがある感じではなかったので、教わったことを色々記録した。後から入ってきた人に役立ったと言ってもらえて嬉しかったな―。

*2:様々な方と話すうちに、エンジニアリングだけを極めるというよりも、人と話して課題を解決できるようになるとか、チームを良い方向に導くとか、人間の絡む部分?で仕事をしたいと思うようになっていたのだ。

*3:これは仕事関係なくいつものこと説ある。

*4:リモートワークも、同じところに集まって仕事するのもそれぞれにいいところがあるわよね〜という感じ。どちらかに縛られるのではなく、両方の選択肢があるといいよねって。

*5:そもそもこれでOK、とかいう状態はないでしょうが。

ScalaMatsuriとても楽しかった #ScalaMatsuri

Scala コミュニティ

ScalaMatsuriに参加しました！

先に感想を書くと、とても楽しかったです！！
全トラックがっつりセッション聞いたわけではないのだけど、
ロビーにいる間も話したことない方と交流したりScalaの話したりキャリアの相談したり、
貴重な経験が出来ました。行って良かったという感想しかありません。

スタッフのみなさま本当にお疲れさまでした。ありがとうございました。

内容も充実していたし、なんか終始飲食物が提供されていてすごかったですｗ
寿司までありました。

サビ抜きを待ちわびる自分のようすが・・・

何言語もやったことあるわけじゃないけど、Scalaは好きだなー書いていて楽しいなーと思うので
自分も何か貢献できることがあればやりたいですー。
ひとまずJava女子部でScala勉強会を企てるぞ！(話は通した)
あと初心者向けの何かとか、翻訳系のお手伝いならきっと出来るのでチャンス見つけていこう！

1日目

新サービスをゼロから開発してローンチするのに大切だった3つのこと

speakerdeck.com

とても参考になって面白かったです！！

こういう話でよく思うのが、自分はデザイナさんと仕事をしたことがないなということ。
プロダクトマネージャとの関わり方とか、営業とのそれは分かるーっていう話も多いですが
デザイナさんとの話はへぇそういうもんなんだ…ってなることもしばしば*1。関わってみたい。
(どうでもいいけど、デザイナには「さん」をつけるのにマネージャにはあまりつけんな。何で。)

あとTwitterのStickersの正しい使い方を知りました。写真に貼るのね。
DMにて、単体でマスクとか眼鏡とかを送って遊んでいてすみませんでした。

広告配信システムで積み重ねてきたパフォーマンスTips

speakerdeck.com

同業者さんのお話だったので興味があって聞きに行きました。
困ったときに思い出して知恵を拝借しよう。

ScalikeJDBC入門

Introduction to ScalikeJDBC

たまたま「数週間前にScalikeJDBC始めました」みたいな状況だったのでお邪魔しました。
お話にもあったとおりScalikeJDBCはドキュメントが充実してますが
まだ自分が読めてないところの話もあったので楽させていただいちゃったぜ、という。

懇親会

色々な方と話せました。多分たろうさんといわたんさんが何かと間に入ってくださったおかげ。
ありがとうございました。

2日目

朝会

去年は出なかった(何故か品川シーサイドのいきステ行ってた・・・)ので初めて。
迷いのないさくさく進行に感激しました。

Scala エンジニアのための英会話教室

終始英語だったので、自分に出来ることと言えば翻訳ツイートだろうとそっちを頑張りました。

最後にした質問がいい感じのラップアップになったのは嬉しい😊

Chrisさん、モチベーションが大事とおっしゃっていましたが、
ScalaMatsuriはとてもインターナショナルだし、英語ができると楽しさ倍増なので
それもモチベーションのひとつとしてよさそうですねー。
年に1度だけのイベントなので、それだけだと弱いかもしれませんが、ｗ
私は今回懇親会でDevonさんとたくさん話してとても楽しかったので、やったぜ〜という気持ち。

引き続き頑張ります。
ビジネス・テクニカルな英語はダメダメなので、OSSのPRでの勉強やってみよう。
このPR読もうぜって皆で持ち寄って理解する会とか簡単に出来そうだな。

ゆるふわ Scala 女子会

この会のためおやつ買いに行ったらダイバーシティで迷子になりましたが、
無事ドーナツを獲得し帰還、参加できました。

初回ということで圧倒的ゆるふわでした。皆さんにお会い出来て嬉しかったです〜！

Scalaの女性向けコミュニティが発足するかはともかく、
上にも書いた通りJava女子部でScalaのイベントをやってみようと思います('v')

そうそう、女性向けコミュニティにおいて男性が何出来るか、みたいな話がありましたね。
色々あると思いますが、
まずは、周りにもし「コミュニティ参加してみたいけどハードルを感じてる」って方がいらしたら
お声かけいただくとか・・・。やっぱりこれがよさそうでしょうか😊誰にでも出来そうだし！

既にどんなコミュニティにも参加出来るぜ〜みたいな方は
内容に興味があれば躊躇なくご参加いただけるはずなので大丈夫でしょうし、
女性であっても「女性向け」に抵抗がある方を無理に巻き込んだり説得したりする必要はもちろんないと思っています。

しかし「女性向けなら私にも参加出来るかも…？」という方がいらっしゃるのは事実なので
そういう方がコミュニティデビュー / 登壇デビュー / ブログデビュー…
何でもいいですがとにかく練習に使えるような場とか、
仲間がいれば頑張れる方のモチベーションあげるきっかけとか、
そういうのを作り、そしてちゃんと必要としている方に届けられたらいいですね〜。

そうすると、女性向けじゃない、誰でも参加型イベントにも女性が増え始めるはず😚
Javaのコミュニティでもそういう変化を目にしているので(まだまだ少ないけど)、きっと。

あ、自分は女性ですしJava女子部やってるので女性女性言うてますが、
変に女性を特別扱いしてるわけじゃぁなく。
これ以外のくくりでコミュニティやっても面白そうだし、色々出来そうですね。
初心者会、新卒会、中堅会、関東会、何でも。同じ〜。

懇親会

きの子さん(@aa7th)※本名ではない にお声かけいただいて
みなさんと飲みに行ってとてもエンジョイしました。

だんだん疲れてきました。おしまい。
来年も楽しみです！

*1:今回に関しては、デザイナさんパートもとてもよく分かるものだった

GitHubにスパムだと思われた・・・(再・Speaker Deck編)

GitHub

私のブログの中で何気に人気なエントリのひとつが以下なのですが

ihcomega.hatenadiary.com

おかげさまで再度同じ目に遭遇いたしました。

今度はGitHubではなくSpeaker Deckにて。


↑ある日スライドのアップロード作業をしていたところ、日頃の行いは良いはずなのに、
スライドが1つもないみたいに見えるようになったんです。

かと言ってログインしてみると消えているわけではなく、
全てUnpublishedにステータスが書き換わっていました。

そして再度publishしようとしても出来ず、新しいスライドの追加も出来ず、
問い合わせるっきゃない！という状況になったので


アカウント名をクリックすると出て来るプルダウンから
"Feedback"でメッセージしてしまいました。


クリックするとやたらおしゃれな便箋が立ち上がるので

Hi,
Could you check the status of my account?

All PDFs I have uploaded got unpublished and cannot be updated.
Also, I cannot upload new files.

Thanks,

と送っておきました。

You were incorrectly caught by our spam detecting robots. I've cleared that flag, so you should be good to go now. You may need to try uploading your files again.
誤ってスパム検出ロボットの餌食になったっぽい。ボットフラグ削除しておいたので、もう大丈夫。再度アップロードしてもらう必要があるかも。

3日くらいするとこんな返事が。
うっ…どうやらまたスパム検出ロボットに見つかってしまったようだ…
一度に大量アップロードしたからかな？

Hi ◯◯(メールくれたひとの名前),

Thank you for solving it! Now everything is fine.
Best regards, ◇◇(自分の名前)

と返しましたが、こういうのって返事くるとうざいんですかね？

ひとまず解決したのでよかったです！！

npm/docsで学ぶ英文法はもうない

英語

あけましておめでとうございます！

ihcomega.hatenadiary.com ihcomega.hatenadiary.com

の続きです。

github.com

全部訳してみましたが、もうトリッキーな文は出てきませんでした。

唯一勉強になったのが、このフレーズ。

ということで本シリーズは終了です。よこな先生の次回作にご期待ください('_')

2016年が終わる

雑談

今年もおつかれさまでした。

去年たてた、今年の目標

ihcomega.hatenadiary.com

〜技術編〜

  • コップ本読破する
    →半分くらいしか読んでない。

  • JJUG CCCにCfP出す
    →出した。盛大に失敗した。反省と学びはあった。

  • The Swift Programming Language読破する
    →全く読んでない。Swiftやってない。

圧倒的未達！！！まず3つ目とか忘れてた。だめじゃん・・・

〜精神編〜

  • もっと前向きになる : 反省はしても、後悔やくよくよやうじうじは程々に
    →割といい感じだと思っている。油断しないよう、図々しくならないよう気をつける。

〜私生活編〜

  • ヨガ以外に何か運動する
    →一瞬ボルダリングしたり、走ったり歩いたり、コロコロ筋トレするやつしたりした。
    痩せた。見た目にあらわれない。

  • 誰かのライブに行く
    →星野源の！ライブに！行った！最高だった！！！！！！！
    でも何この目標？

来年の目標

〜勉強編〜

  • コップ本読破する(継続…)
  • サイ本読破する
  • 今作ってるwebアプリを完成させる
  • シェルちから、vimちからを上げる
  • 英会話ちからを上げる
    来年は自分の時間が増えそう。インプットを増やしたい。

〜精神編〜

  • 楽しくやる
  • 思ったことを言う
  • ここに書いている目標を念頭において過ごす + 定期的にアップデートする

〜私生活編〜

  • 痩せる
  • 節約する
  • 生活を落ち着ける
    2月から東京へ移ります＞＜よろしくお願いいたします。

今年やったこと

togglとかブログとか見ながらほーんって思ってる。

来年もよろしくお願いいたします！！！

npm/docsで学ぶ英文法②

英語

クリスマスですね。

私はケーキを焼いて十分に楽しみました。

さて、頑張ったブッシュドノエルをアピール出来たのでもう十分なんですが、
ihcomega.hatenadiary.com ↑こちらの続きいってみよー！

みっつめ👀

05 - Using a package.jsonより

This object will hold attributes named after the packages you'd like to use, that point to a semver expression that specifies what versions of that project are compatible with your project.

補足

  • semver
    npm用語で、Semantic versioningを指すようです。
    詳細はSemantic versioning and npmを読めば分かりそう(まだ読んでいない)。

ポイント

  • 非制限用法の関係代名詞 thatが使われている・・・？

学校では「非制限用法にthatは使えないよ(一応例外もあるけどね)」って習いますよね。
でも前半に出てくる, thatがそれにしか見えない。合っているのでしょうか。
色々調べたけど確証は持てず、かといってそれ以外にいい感じなthatの用法も
見つかりませんでした。

ひとまずthatは関係代名詞であるとして話を進めます。

先行詞は、pointという動詞が原型、つまり三単現のsがないことから
objectではなく、attributesまたはpackagesです。

ではどちらか。attributesだと思います。
なぜか。文法的に先行詞を確定させる要素がなく、意味で判断してしまいました。
point toが、JSONの名前と値を結びつけるような表現だと思ったため、
semver形式の値と対になるものはattributeの方だろうと…。
こちらは訳のところでも補足します。

文のつくり

複雑な箇所は、細かいところだと上に挙げたのくらいな気がするので、
全体の構造を見てみます。

SとVがたくさん〜

訳

このオブジェクトは、あなたが使いたいパッケージから名前をとった属性を持ち、その属性は、
そのプロジェクトのどのバージョンがあなたのプロジェクトと互換性を持つかを特定するsemver表現を指します。

分かりやすく直してみます。

このオブジェクトは、使いたいパッケージから名前をとった属性を持ち、その値はsemver形式を取ります。
semver形式は、依存するプロジェクトのどのバージョンが自分のプロジェクトと互換性を持つか表すものです。

こんな感じでしょうか…。

正攻法ではないけど、
説明の対象であるpackage.jsonのdependenciesとdevDependenciesを
例で見てしまうと分かりやすい気がします。

{
  "name": "my_package",
  "version": "1.0.0",
  "dependencies": {
    "my_dep": "^1.0.0"
  },
  "devDependencies" : {
    "my_test_framework": "^3.1.0"
  }
}

^1.0.0とか^3.0.0っていうのがsemverで、
my_dep、my_test_frameworkっていうのが各semverを指す名前。
さっきは、この名前と値の関係から、thatの先行詞を判断しちゃったわけです！

気になること

you'd like to use

普通、それなりにかっちりした書き言葉ではyou'dみたいな省略形を使わないはず
・・・例えば大学のレポートやテストでは省略形やめましょうって言われてきたし、
会社のドキュメントとかでも避けるようにしています
が、npmのドキュメントでは普通に出てきますねー。

あまり細かいことを考えずに書かれているだけかもしれませんが、
ちょっと気になりました。

おしまいです。今回も、正解がよく分からないままｗ

英文を読む時、構造 -> 意味という順番で捉えないと危険だっていうのは
前回書いた通りで揺るがないのですが、
上のように意味から判断しないといけない場面ももちろんあります。

まずは文法的なジャッジが出来るよう文法をちゃんと身につけて、
その上で、意味的に考えなくてはならないケースに備えて
語彙を増やすとか言葉のニュアンスを知るとかが必要になってきますね。
大変！！！！！

Merry Christmas！！！！！

npm/docsで学ぶ英文法①

英語

最近、暇つぶしに訳しています。 https://github.com/npm/docsgithub.com

おかげでtypoを見つけてPRを出すことも出来ました('_')
なかなかマージされないけどね… https://github.com/npm/docs/pull/781github.com

さて、
読んでいる中で特徴があるなと思った英文を取り上げて分析する
という遊びをします。

ひとつめ👀

01 - What is npm?より

This makes it possible for you to compose larger, custom solutions out of these small, shared building blocks.

ポイント

  • SVOCと形式目的語のあわせ技が使われている

①SVOC部分はここです。

makeはSVOCの形を取れる代表的な動詞ですね。

②形式目的語はここです。

It is possible for [人] to [動詞]は[人]が[動詞]できるの意でよく使われますが、
SVOCと合わさって学校のテストに出そうな構文になっています。

  • composeの目的語が分かりづらい

これは・・・文法的なトリックというより単純におかしい、
あるいは私の読み取りが完全に誤っている気がします。

まず、composeは自動詞だと「作曲する」というような意味になるので、
文脈的に他動詞である可能性が高いです。

他動詞ということは目的語が必要なので
composeの後にある名詞をピックアップすると、solutionsとblocksのみです。
動詞との位置関係からしてsolutionsが目的語であると予想できます。

しかしここで問題が…。solutionsを修飾すると思われるlargerとcustomの間に
andがないのが不自然な気がするんですよね―。
larger, custom solutionsをlarger and custom solutionsと同意と捉えて良いならば*1
文として意味も通ります。

でも2つの単語を繋げるとき、カンマってandの代用になるのか…？
という疑問が残っておりよく分かっていません😂

ひとまずlarger and custom solutions説を採用して先に進みます。

文のつくり

構造はこんな感じになります。

訳

疑問は残りますが訳してみると

これはあなたが、小さな共有された部品から
より大きくカスタマイズした解決策を生み出すことを可能にします。

前とのつながりを考えつつ自然な日本語を目指す(難しい...)と

そうすることで、共有された小さな部品を組み立てて、
より大きくカスタマイズされた解決策を生み出すことが出来るのです。

できたใ(^▽^ )ว ใ(^▽^ )ว ♬♬ちょっとセンスないな。

ふたつめ👀

05 - Using a package.jsonより

name: defaults to author name unless in a git directory, in which case it will be the name of the repository

nameという項目の説明なのでこんな形になっていますが、次の文で考えてみます。

A name defaults to author name unless in a git directory, in which case it will be the name of the repository.

ポイント

  • Unlessで始まる副詞節の主語が省略されている

主節と副詞節の主語が同じ場合、副詞節の主語とbe動詞は省略できます。
ここではa nameが主語なので、

unless it (a name is) in a git directory

が省略された形ということになります。

  • 関係形容詞のwhichが使われている

後半のin which caseは前置詞 + which + 名詞という形でしばしば使われる
関係形容詞(関係代名詞の一種)というやつです。
whichで前の文を受け、caseを修飾しています。そこに前置詞のinがついているので、
日本語にあてはめると次のような感じになります。

文のつくり

構造を捉えます。

訳

以上をふまえて訳すと

nameのデフォルト値は、Gitディレクトリの中にない場合、authorの名前です。
その場合、それがnpmリポジトリの名前となります。

となるかな？
できたใ(^▽^ )ว ใ(^▽^ )ว ♬♬

と思ったものの、npm init --yesをしてもそんな挙動にならない件…
Gitディレクトリにあろうがなかろうが、Macのディレクトリ名になる…

疑問

author nameに冠詞がないのはなぜだろう。固有名詞的な扱いをしているのかな？

ふぁ〜〜〜みっつめ👀もあったのですが、疲れたので終わりにしますｗ

うぅ、何気に難しかったです。
しかも

って思っているので、文法的に正しいものだけを信じる力が必要です。
今回は2つとも不安を残しているので、間違っているのかもしれない。

ただこれだけは言える！
単語の意味だけ調べて雑に英文を読むのでなく、
構造を意識しないと間違いや理解不足のもとなので文法とても大事！！！
特に長文とか複雑な文で「？」となったときは
こんな風にSとかVとか書いたり、文法的な根拠から推理するのがよい訓練になると思っています。

文型(SVCとかSVOOとかいうアレです)把握が苦手な人とかいたら喜んで勉強会したい。どうなんだろう。

*1:small, shared building blocksも同様。