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の方だろうと…。
こちらは訳のところでも補足します。

文のつくり

複雑な箇所は、細かいところだと上に挙げたのくらいな気がするので、
全体の構造を見てみます。
f:id:ihcomega:20161225024745p:plain:w700
SとVがたくさん〜

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

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

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

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

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

{
  "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_depmy_test_frameworkっていうのが各semverを指す名前。
さっきは、この名前と値の関係から、thatの先行詞を判断しちゃったわけです!

気になること

you'd like to use

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

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


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

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

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

Merry Christmas!!!!!

npm/docsで学ぶ英文法①

最近、暇つぶしに訳しています。 github.com

おかげでtypoを見つけてPRを出すことも出来ました('_')
なかなかマージされないけどね… github.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部分はここです。
f:id:ihcomega:20161216232955p:plain:w600
makeSVOCの形を取れる代表的な動詞ですね。

形式目的語はここです。
f:id:ihcomega:20161216223318p:plain:w600

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

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

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

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

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

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

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

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

文のつくり

構造はこんな感じになります。
f:id:ihcomega:20161216224452p:plain:w550

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

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

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

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

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

ふたつめ👀

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で始まる副詞節の主語が省略されている

f:id:ihcomega:20161216224419p:plain:w700

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

unless it (a name is) in a git directory

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

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

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

f:id:ihcomega:20161216224430p:plain:w400

文のつくり

構造を捉えます。
f:id:ihcomega:20161216224436p:plain:w700

以上をふまえて訳すと

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

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

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

疑問

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


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

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

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

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

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

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

JJUG CCC 2016 Fallで怒り新党やってみた #jjug_ccc #ccc_gh4 #ccc_g4

12/3(土)はJJUG CCC 2016 Fallでした。

といっても、当日まったく無理のない時間帯に京都から移動したので午後参戦でしたし
14:30~ 「JJUG presents マチコ&河村の怒り新党」の準備に結構時間使いましたし
いつもと同じような幹事としての仕事は後半ちょろっとしかしませんでしたね…
(他の幹事の皆さんありがとうございます!!!)

JJUG presents マチコ&河村の怒り新党

Java女子部生みの親マチコさんと、JJUG副会長の河村さんと
某番組のオマージュ?企画をやらせていただきました。
私はネタを集めたり資料を作ったりに加えて、当日の進行役(?)が担当。

セッションの内容は伝わりませんが、資料をあげてみました。
いらすと屋の圧倒的パワーで、
本家の雰囲気を感じられるスライドに仕上がったと思っています(自画自賛)!
ちなみにネタは私の妄想ではありませんよ。

ハッシュタグは #ccc_gh4 の方が使われていたかも…
こちら↓のURLでセッション中のツイートが追えます。
twitter.com

印象的だったことメモ

  • 問題が起きたときは最初のアクションが大事である
  • 営業とエンジニアは違う生き物である、くらいの意識で歩み寄ろう
  • 評価者が自分より上の人に、自分のメンバーを自信持って推せる!という状態が健全だろう
  • ↑この「自分のメンバー」にあたる人は、評価者のさらに上の人をイメージして自分の成果を伝えよう
  • 思ったことは言おう
  • 意見を言わない人を責めたり受動的に待つだけでなく話しやすくなる工夫をしよう

いやーマチコさんも河村さんもズバズバと話してて隣で圧倒されました。
私は「それっぽくお便りを読む力」を出来るだけ発揮したつもりです。

会場の方もたくさん発言してくださって本当に嬉しかったです。
ありがとうございます!!!!!!!!!!!!!!!!
そしてAD体型のせろさん(@cero_t)がマイク持って走り回ってくださって
とても助かりました。ありがとうございます!!

Javaエンジニアのキャリアを考えるパネルディスカッション

最初の方だけ聞きました。

しびれた。

自分の感想を書く前に、素敵にまとまったなかやまさんのメモ。

印象的だったことと感想メモ

※私の解釈が入ったり記憶違いがあったりするかもしれません…
いくつかテーマがあったけど、どの話がどのテーマで出た発言だったか不確かなのでごちゃまぜ。

よしおりさん(@yoshiori)

  • 何となく「技術一本でやっていく」って言ったほうがかっこいいと思ってない?
  • 前任者と同じことをして文句を言ってもしかたない、面白くない
  • エライ立場になったら自由が増えるよ!コードが書けない?いやいやそういう時間も自由に作れるようになるはずだよ
  • 常に自分がいちばんヘタクソになれる環境を選んできた

-> しびれた。よい環境、楽しさ、やりやすさ…全部自分で作れる!!

ひしだまさん(@hishidama)

  • 技術でやっていきたい!ただ綺麗なプログラムを書くには綺麗な仕様が必須なのでそういうところから口出しして関わっていきたい

-> 私もそういう姿勢を持ちたい!
自分が今会社でやっている(よしとしている)役割や責任の分担ももっと改善できそうなのよね。
いいもの作るために、いい仕事するために、キャリアを固定観念や慣習に基づいた分け方したくないよねー。

おおたにさん(@johtani)

  • 若い人にかなわないと思って違う方向に進み始めた

-> 私も含め多くの人が「スゴイ」って思ってる方でもやっぱりこういう気持ちがあって
だからこそ他との差別化とか自分の強みとかを考えられるのかもしれないし
「スゴイ」といわれるアクションをし続けられるのかもしれませんね。結果やっぱりスゴイ。

ゆーすけさん(@yusuke)

  • 昔は(技術的/論理的に?)正しいことをズバズバ言ってばかりだったけど今思うと…

-> うろ覚えだが…昔いいと思っていたことが今はそうではないという経験は誰にでもあるし
貫くところと変わるところどっちも必要だよなあ、とか感じた記憶がある。

自分が今、キャリア…というと大袈裟かもしれませんが
進む方向とかやることについて考え中なのもあって
本当にぐっときたセッションでした。

懇親会

参加者いっぱいでしたねーわいわい。話しかけてくださった皆様ありがとうございました!
初対面だったJava女子部の皆さんとか是非、 「わたしこのTwitterアイコンです」っていうのを教えてほしい・・・w

LTでは無茶ぶりで@opengl-8080さんに私の大好きなのやっていただけて嬉しかったです。

qiita.com

感想

今回も幹事として参加出来てよかったです。
半年に一度、Twitterではなくリアルで皆さんに会える機会は自分にとってすごく大事です。

だから!!!

楽しいこと、いい仕事、成功…
1人で出来てもあまり嬉しくなくて、あくまで
人とやりたい、人と分かち合いたい、人に喜んでもらいたいって思ってしまうんですね。
また、人のこと知りたい、人の考えを聞きたい、人の行動を見たい、そんな興味もあります。
人駆動人生!!!!!!!!!!!!!!!(よくわからない)

とにかく。いろんなひとと顔を合わせて、聞いて、話して、
そしていろんなことが分かる、いろんなことを感じるっていうのは
自分の次の行動に繋がる大きな尊い出来事なのですー。


ここからは内輪な内容しかない日記。

幹事の打ち上げ

お肉美味しかったです。

てらださん(@yoshioterada)のほわほわした感じがやっぱり素敵でした。

せろさん相談のってくださってありがとうございました。

💢

会長(@yusuke_arclamp)、まちこさんからも人生のアドバイスいただけて嬉しかったです。
ここには書けませんがw

あ、あと前回の失敗を二度と繰り返さないようにお酒飲まなかったところ発見が・・・

(今までまじで気付かなかった)

次の日

日曜、うらがみさん(@backpaper0)、ちむさん(@syobochim)、
たろさん(@ngsw_taro)、やんくさん(@yy_yank)さんと遊びに行きました。

ためになる話も楽しい話もいい天気の中お散歩も出来て最高でした。
Javaコミュニティがくれた素晴らしい出会いに乾杯🍷
f:id:ihcomega:20161205120127j:plain:w300

エンジニア立ち居振舞い:自分は出来ないと思い込みすぎない

お題「エンジニア立ち居振舞い」
↑便乗!!


自分は出来ない、レベルが低いと必要以上に思わない方がいいに違いない。

なぜ?

自分が困る

  • 精神的に疲れる
  • 他者からの評価すら下がる、給料アップチャンスを逃し得る
    いいと思っていないものをアピールするのって難しいからね。

後輩 *1 が困る

  • 適切な説明や指導が出来ない
    「自分に出来たのだから万人に出来るはず」「自分がバカだから分からなかったけど、この人には説明しなくても大丈夫」ってなる。
  • 後輩の自信や評価までもをマイナスにしてしまう

先輩 *2 が困る

  • 先輩だって間違える、ということを忘れてしまう
    先輩と意見が違ったとき、「自分の方が間違ってるんだろう」と思い込んで事前に分かったミスをスルーしてしまう。もっと良いはずのアイディアを出せない。

その他

  • 自分を評価してくれる人に失礼だ
    自分の成果を褒めてくれる人がいるのにそれを否定して嘘にしちゃうの、とても残念。

じゃあどうする?

  • 人ではなく、事実を評価しようとがんばる

    • バグ出した、知らないことがあった -> 自分はダメエンジニアだ
      この手の自己評価をして嘆いたところで、バグは直らなければ知識も増えない。
      「自分はまだまだレベルが低いから仕方ない」という逃げにしかならない。
      だから、
    • バグ出した -> 何故出した、どうやって直す、どうしたら防げた、次からどうする
    • 知らないことがあった -> 何が分からなかったのか、何を知ればいいのか、何を学んだのか + 何なら知っていたのか
      当たり前だけど、こういうことを考えて行動したい!
      自分の行動を、自分という人間の評価だとすぐに錯覚しない!
  • 時々自分の行動を褒める
    対象がなければ行動する。


おしまい!

*1:自分より経験が浅い人、年下の人、レベルが下の人、知ってることが少ない人…などを便宜上こう書いてみた

*2:自分より経験のある人、年上の人、レベルが上の人、知ってる人が多い人、所謂スゴイ人…などを便宜上こう書いてみた

うらがみさんアドバイス解析〜リテラルはGCされない〜 #hogedriven

この前関西のエンジニアおともだちと集まって遊んだ時に発表した資料を公開しちゃお〜


何かと言うとですね。
かなり昔だけど、ふと浮かんだ疑問をツイートしたら
うらがみ(@backpaper0)さんがコード書いて実験してくれて。
それを今更解析したよ〜ってことで発表して、内容合ってるか皆さんに見ていただいたの!
資料だけだと分かりづらいかもしれんけど、すごく勉強になったし面白かった。
うらがみさんへのお礼としてアップルパイも焼いていい経験になったよー!

ツイート↓

コード by うらがみさん↓
gist.github.com

この作業で生じたTODO

  • コンスタントプールについて勉強する…というかjavapを学ぶ
  • コードの後半も読んでみる

最後に、資料には書いてない感想を追加しておこう。
こうやって有識者の方に教えていただく内容って結構難しいけど、
ちゃんと考えれば理解できるし、何となく分かったで放置せず向き合っていきたいなー

ここ最近のおひとりさま勉強会 #yokodokusho

togetter.com

togetter.com

togetter.com

細々とやっているのですが間が空きました。また続けていこうと思います。
なんか難しくなってきて全く進まなくなってきましたんですが
ここで絶望して投げ出す癖を絶対に治すぞ〜〜〜

昨日のJava女子部で
身の回りの優秀な方は皆本を読んでいるよねという話になって
そうだよねって改めて思ったからです・・・

全然勉強しないから成長が遅いという当たり前の因果が
いよいよ辛くなってきたので、もう少し気合入れて頑張ります😓

Now or never! Nothing is too late to start!

そうそう、サイ本読んでると、当たり前のことなのに説明回りくどくない?って時々思う。
でも例えば経験のない人とか、他の言語やってきた人とかが理解するには
こういう表現が必要なのかもしれないなーと納得しています。

どんな読み手を想定するか?どこまで噛み砕くか?何を知ってる前提で話すか?
本を書くことの難しさを感じるぜ(アホっぽい)。

Scalaのforeachはパターンマッチで書けるのね

val hoge = List(1, 3, 5, 7)

こんなリストがあるとして

順番に要素を出力してみよう。

👻例1

foreachを使うと

hoge.foreach(h => {
  println(h)
})

こうなる。

👻例2

これをパターンマッチと再帰的なサムシンでも書けるっぽい。

@tailrec
def f(hoge: List[Int]): List[Int] = {
  hoge match {
    case h :: fuga =>
      println(h)
      f(fuga)
    case _ =>
      List.empty[Int]
  }
}

f(hoge)を呼び出せば例1と同じになる。

何故急にこんなことを書いてみたかというと、
例2にあるcase h :: fuga => の意味が分かった記念。
最初::が要素追加かと思って何をしているのか理解できんかったけど、リストを順番に処理しているのね。

ちなみにここでの再帰処理を図におこすとこんな感じだと思う!
f:id:ihcomega:20160727210926p:plain

Scalaのパターンマッチはとにかく強いらしい…?