2016年が終わる
今年もおつかれさまでした。
去年たてた、今年の目標
〜技術編〜
コップ本読破する
→半分くらいしか読んでない。JJUG CCCにCfP出す
→出した。盛大に失敗した。反省と学びはあった。The Swift Programming Language読破する
→全く読んでない。Swiftやってない。
圧倒的未達!!!まず3つ目とか忘れてた。だめじゃん・・・
〜精神編〜
- もっと前向きになる : 反省はしても、後悔やくよくよやうじうじは程々に
→割といい感じだと思っている。油断しないよう、図々しくならないよう気をつける。
〜私生活編〜
ヨガ以外に何か運動する
→一瞬ボルダリングしたり、走ったり歩いたり、コロコロ筋トレするやつしたりした。
痩せた。見た目にあらわれない。誰かのライブに行く
→星野源の!ライブに!行った!最高だった!!!!!!!
でも何この目標?
来年の目標
〜勉強編〜
- コップ本読破する(継続…)
- サイ本読破する
- 今作ってるwebアプリを完成させる
- シェルちから、vimちからを上げる
- 英会話ちからを上げる
来年は自分の時間が増えそう。インプットを増やしたい。
〜精神編〜
- 楽しくやる
- 思ったことを言う
- ここに書いている目標を念頭において過ごす + 定期的にアップデートする
〜私生活編〜
- 痩せる
- 節約する
- 生活を落ち着ける
2月から東京へ移ります><よろしくお願いいたします。
今年やったこと
togglとかブログとか見ながらほーんって思ってる。
- 書いたのは主にScala、次にJava、あとはJSとかGoを必要に迫られ少しだけ…
- スクラムでの開発をやった
- チームの皆東京、自分だけ京都っていうのを経験した、やってみないと分からないであろう不便さや工夫を学んだ
- チームがよくなる方法みたいなのに興味がでてきた
- 営業についていったり採用活動に関わったりして知らなかったことを知った
- 海外出張をした、外国の方と仕事をした
- Java女子部は主に関西で参加した
女性エンジニア大集合!新春LT×座談会 #javajo - よこなのへたのよこずき - JJUG幹事業は変に緊張せず出来る仕事が増えた
- JJUGナイトセミナーでちむさんと登壇した
JJUGナイトセミナー「Git入門」で登壇した話(&質問の回答) #jjug - よこなのへたのよこずき - JJUG CCCでセッションのお手伝いをした
JJUG CCC 2016 Springで若者として煽り芸にトライした #jjug_ccc - よこなのへたのよこずき
JJUG CCC 2016 Fallで怒り新党やってみた #jjug_ccc #ccc_gh4 #ccc_g4 - よこなのへたのよこずき - Java Day Tokyoでインタビューしていただいた
Java女子部 on Twitter: "#JavaDayTokyo #javajo @java のブースにお邪魔してきましたー @ihcomega が英語頑張ってくれました! @maaya8585 は英語喋れないので隣で笑ってました! https://t.co/yKHsIPHZh1" / Twitter - 1人勉強会した
第1回孤独サイ本読書会という名のおひとりさま勉強会 #yokodokusho - よこなのへたのよこずき
ここ最近のおひとりさま勉強会 #yokodokusho - よこなのへたのよこずき - 周りの方に教わったことはアウトプット(?)を通じ自分のものにしようという意識が芽生えた
うらがみさんアドバイス解析〜リテラルはGCされない〜 #hogedriven - よこなのへたのよこずき - 3回ほどメディアに出していただいた
【今週のエンジニア女子 Vol.29】仕事がとてもリアルに感じられる…横田紋奈さん | RBB TODAY
https://geechs-magazine.com/tag/entertainment/20161101
https://geechs-magazine.com/tag/entertainment/20161226 - Schooに出していただいた
Java女子会〜Java女子部って何?〜 -1回目-|オンライン動画授業・講座のSchoo(スクー) - 少しだけ本が読めるようになった
- 基本的に何かに着手するまでが長いのだけど少しだけ短くなった
来年もよろしくお願いいたします!!!
npm/docsで学ぶ英文法②
クリスマスですね。
私はケーキを焼いて十分に楽しみました。ブッシュドノエルใ(^▽^ )ว ใ(^▽^ )ว ♬♬ pic.twitter.com/PqoFWseUIC
— よこな / Ayana (@ihcomega) December 24, 2016
さて、頑張ったブッシュドノエルをアピール出来たのでもう十分なんですが、
ihcomega.hatenadiary.com
↑こちらの続きいってみよー!
みっつめ👀
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のドキュメントでは普通に出てきますねー。
あまり細かいことを考えずに書かれているだけかもしれませんが、
ちょっと気になりました。
おしまいです。今回も、正解がよく分からないままw
英文を読む時、構造 -> 意味という順番で捉えないと危険だっていうのは
前回書いた通りで揺るがないのですが、
上のように意味から判断しないといけない場面ももちろんあります。
まずは文法的なジャッジが出来るよう文法をちゃんと身につけて、
その上で、意味的に考えなくてはならないケースに備えて
語彙を増やすとか言葉のニュアンスを知るとかが必要になってきますね。
大変!!!!!
Merry Christmas!!!!!
npm/docsで学ぶ英文法①
最近、暇つぶしに訳しています。 https://github.com/npm/docsgithub.com
おかげでtypoを見つけてPRを出すことも出来ました('_')
なかなかマージされないけどね…
https://github.com/npm/docs/pull/781github.com
さて、
読んでいる中で特徴があるなと思った英文を取り上げて分析する
という遊びをします。
ひとつめ👀
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
説を採用して先に進みます。
文のつくり
構造はこんな感じになります。
訳
疑問は残りますが訳してみると
これはあなたが、小さな共有された部品から より大きくカスタマイズした解決策を生み出すことを可能にします。
前とのつながりを考えつつ自然な日本語を目指す(難しい...)と
そうすることで、共有された小さな部品を組み立てて、 より大きくカスタマイズされた解決策を生み出すことが出来るのです。
できたใ(^▽^ )ว ใ(^▽^ )ว ♬♬ちょっとセンスないな。
ふたつめ👀
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
に冠詞がないのはなぜだろう。固有名詞的な扱いをしているのかな?
ふぁ〜〜〜みっつめ👀もあったのですが、疲れたので終わりにしますw
うぅ、何気に難しかったです。
しかも
なんかのドキュメント読んでて英語の構文が難しいと感じる場合、本当に複雑なケースとただネイティブじゃない人が書いててカオスなケースがあるので判断が難しい。
— よこな / Ayana (@ihcomega) December 11, 2016
って思っているので、文法的に正しいものだけを信じる力が必要です。
今回は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さんの話を聞いてめちゃくちゃカッコイイと思った。素敵な考え方をたくさん聞けた。 #jjug_ccc
— よこな / Ayana (@ihcomega) December 3, 2016
自分の感想を書く前に、素敵にまとまったなかやまさんのメモ。
Javaエンジニアのキャリアを考えるパネルディスカッションを聞いてきたメモ #jjug_ccc #ccc_cd7 pic.twitter.com/FQplH73HbO
— Nakayama san (@nakayama_san) December 3, 2016
印象的だったことと感想メモ
※私の解釈が入ったり記憶違いがあったりするかもしれません…
いくつかテーマがあったけど、どの話がどのテーマで出た発言だったか不確かなのでごちゃまぜ。
よしおりさん(@yoshiori)
- 何となく「技術一本でやっていく」って言ったほうがかっこいいと思ってない?
- 前任者と同じことをして文句を言ってもしかたない、面白くない
- エライ立場になったら自由が増えるよ!コードが書けない?いやいやそういう時間も自由に作れるようになるはずだよ
- 常に自分がいちばんヘタクソになれる環境を選んできた
-> しびれた。よい環境、楽しさ、やりやすさ…全部自分で作れる!!
ひしだまさん(@hishidama)
- 技術でやっていきたい!ただ綺麗なプログラムを書くには綺麗な仕様が必須なのでそういうところから口出しして関わっていきたい
-> 私もそういう姿勢を持ちたい!
自分が今会社でやっている(よしとしている)役割や責任の分担ももっと改善できそうなのよね。
いいもの作るために、いい仕事するために、キャリアを固定観念や慣習に基づいた分け方したくないよねー。
おおたにさん(@johtani)
- 若い人にかなわないと思って違う方向に進み始めた
-> 私も含め多くの人が「スゴイ」って思ってる方でもやっぱりこういう気持ちがあって
だからこそ他との差別化とか自分の強みとかを考えられるのかもしれないし
「スゴイ」といわれるアクションをし続けられるのかもしれませんね。結果やっぱりスゴイ。
ゆーすけさん(@yusuke)
- 昔は(技術的/論理的に?)正しいことをズバズバ言ってばかりだったけど今思うと…
-> うろ覚えだが…昔いいと思っていたことが今はそうではないという経験は誰にでもあるし
貫くところと変わるところどっちも必要だよなあ、とか感じた記憶がある。
自分が今、キャリア…というと大袈裟かもしれませんが
進む方向とかやることについて考え中なのもあって
本当にぐっときたセッションでした。
懇親会
参加者いっぱいでしたねーわいわい。話しかけてくださった皆様ありがとうございました!
初対面だったJava女子部の皆さんとか是非、
「わたしこのTwitterアイコンです」っていうのを教えてほしい・・・w
LTでは無茶ぶりで@opengl-8080さんに私の大好きなのやっていただけて嬉しかったです。
感想
今回も幹事として参加出来てよかったです。
半年に一度、Twitterではなくリアルで皆さんに会える機会は自分にとってすごく大事です。
だから!!!人間大好き
— よこな / Ayana (@ihcomega) December 4, 2016
楽しいこと、いい仕事、成功…
1人で出来てもあまり嬉しくなくて、あくまで
人とやりたい、人と分かち合いたい、人に喜んでもらいたいって思ってしまうんですね。
また、人のこと知りたい、人の考えを聞きたい、人の行動を見たい、そんな興味もあります。
人駆動人生!!!!!!!!!!!!!!!(よくわからない)
とにかく。いろんなひとと顔を合わせて、聞いて、話して、
そしていろんなことが分かる、いろんなことを感じるっていうのは
自分の次の行動に繋がる大きな尊い出来事なのですー。
ここからは内輪な内容しかない日記。
幹事の打ち上げ
お肉美味しかったです。
てらださん(@yoshioterada)のほわほわした感じがやっぱり素敵でした。
せろさん相談のってくださってありがとうございました。
いやいやいや、100回も言ってないと思います!!
— Shin Tanimoto / CERO-METAL (@cero_t) December 3, 2016
💢
会長(@yusuke_arclamp)、まちこさんからも人生のアドバイスいただけて嬉しかったです。
ここには書けませんがw
あ、あと前回の失敗を二度と繰り返さないようにお酒飲まなかったところ発見が・・・
(今までまじで気付かなかった)今日土曜なのに酔っ払い多すぎない!?!?って思いながら帰ったんだけど、いつも自分が酔っ払ってて気付かなかったのか…
— よこな / Ayana (@ihcomega) December 3, 2016
次の日
日曜、うらがみさん(@backpaper0)、ちむさん(@syobochim)、
たろさん(@ngsw_taro)、やんくさん(@yy_yank)さんと遊びに行きました。
ためになる話も楽しい話もいい天気の中お散歩も出来て最高でした。
Javaコミュニティがくれた素晴らしい出会いに乾杯🍷
エンジニア立ち居振舞い:自分は出来ないと思い込みすぎない
お題「エンジニア立ち居振舞い」
↑便乗!!
自分は出来ない、レベルが低いと必要以上に思わない方がいいに違いない。
なぜ?
自分が困る
- 精神的に疲れる
- 他者からの評価すら下がる、給料アップチャンスを逃し得る
いいと思っていないものをアピールするのって難しいからね。
後輩 *1 が困る
- 適切な説明や指導が出来ない
「自分に出来たのだから万人に出来るはず」「自分がバカだから分からなかったけど、この人には説明しなくても大丈夫」ってなる。 - 後輩の自信や評価までもをマイナスにしてしまう
先輩 *2 が困る
- 先輩だって間違える、ということを忘れてしまう
先輩と意見が違ったとき、「自分の方が間違ってるんだろう」と思い込んで事前に分かったミスをスルーしてしまう。もっと良いはずのアイディアを出せない。
その他
- 自分を評価してくれる人に失礼だ
自分の成果を褒めてくれる人がいるのにそれを否定して嘘にしちゃうの、とても残念。
じゃあどうする?
人ではなく、事実を評価しようとがんばる
- バグ出した、知らないことがあった -> 自分はダメエンジニアだ
この手の自己評価をして嘆いたところで、バグは直らなければ知識も増えない。
「自分はまだまだレベルが低いから仕方ない」という逃げにしかならない。
だから、 - バグ出した -> 何故出した、どうやって直す、どうしたら防げた、次からどうする
- 知らないことがあった -> 何が分からなかったのか、何を知ればいいのか、何を学んだのか + 何なら知っていたのか
当たり前だけど、こういうことを考えて行動したい!
自分の行動を、自分という人間の評価だとすぐに錯覚しない!
- バグ出した、知らないことがあった -> 自分はダメエンジニアだ
時々自分の行動を褒める
対象がなければ行動する。
おしまい!
うらがみさんアドバイス解析〜リテラルはGCされない〜 #hogedriven
この前関西のエンジニアおともだちと集まって遊んだ時に発表した資料を公開しちゃお〜
何かと言うとですね。
かなり昔だけど、ふと浮かんだ疑問をツイートしたら
うらがみ(@backpaper0)さんがコード書いて実験してくれて。
それを今更解析したよ〜ってことで発表して、内容合ってるか皆さんに見ていただいたの!
資料だけだと分かりづらいかもしれんけど、すごく勉強になったし面白かった。
うらがみさんへのお礼としてアップルパイも焼いていい経験になったよー!
ツイート↓
よし。
— よこな / Ayana (@ihcomega) November 10, 2014
String s = new String("うわぁ");
って書いちゃった時
newで生成される方じゃなくて"うわぁ"の方のStringオブジェクト(何て説明したらいいのか、リテラルの方)は、
どこからも参照されていないからすぐ(?優先的に)GCの対象になる。
ですか?
コード by うらがみさん↓
gist.github.com
この作業で生じたTODO
- コンスタントプールについて勉強する…というかjavapを学ぶ
- コードの後半も読んでみる
最後に、資料には書いてない感想を追加しておこう。
こうやって有識者の方に教えていただく内容って結構難しいけど、
ちゃんと考えれば理解できるし、何となく分かったで放置せず向き合っていきたいなー
ここ最近のおひとりさま勉強会 #yokodokusho
細々とやっているのですが間が空きました。また続けていこうと思います。
なんか難しくなってきて全く進まなくなってきましたんですが
ここで絶望して投げ出す癖を絶対に治すぞ〜〜〜
昨日のJava女子部で
身の回りの優秀な方は皆本を読んでいるよねという話になって
そうだよねって改めて思ったからです・・・
全然勉強しないから成長が遅いという当たり前の因果が
いよいよ辛くなってきたので、もう少し気合入れて頑張ります😓
Now or never! Nothing is too late to start!
そうそう、サイ本読んでると、当たり前のことなのに説明回りくどくない?って時々思う。
でも例えば経験のない人とか、他の言語やってきた人とかが理解するには
こういう表現が必要なのかもしれないなーと納得しています。
どんな読み手を想定するか?どこまで噛み砕くか?何を知ってる前提で話すか?
本を書くことの難しさを感じるぜ(アホっぽい)。