夫婦エンジニアMeetup主催しました #eventdots
1/23に夫婦エンジニアMeetupを渋谷のdots.で行いました。 eventdots.jp
Togetter
感想
コミュニティで運営する方がイベント自体は続けやすい。一人でやってるひとすごい。
今まで、dots.女子部のイベントだったりGeek Women Japanのイベントだったりを運営してきて、だいぶ運営慣れたかなと思っていましたが、まだまだでした。
初心に戻ってやることリストを作ったり、必要な人は頼ったりして今後も運営するときはやっていきたいと思った。
KPT
Keep
- 夫婦でエンジニアというコンテキストで新しい方に知り合えた
- 参加者全員と話すことができた
- よねちゃん(dots.のコミュニティマネージャの一人)めっちゃ助かった(ケータリング、受付、接続周り)
- 開催前にイベントについてコメントされた時、すぐに回答できた
Problem
- コンセプトの詰めが甘く、自分も心から楽しめていなかった
- 「結婚してなくても参加できると思わなかった」というコメントをよくもらった
- 拡散不足(個人的にはあまり大掛かりにならなくてもいいかなと思っていたが、大場さん夫妻に負い目を味あわせてしまったのは申し訳なかった。)
- 日時の設定ミス(子持ち共働きのエンジニアは平日渋谷に19時はキツイ。土日なら参加したいという方は居た)
- 箱の選定ミス(気軽に使えるからとdots.を選んでしまった)
- 運営の人員不足(当日要員として少なくともあと1人は必要だった)
- 運営としてのサポート不足(SNSでの写真NG確認、LTの順番決め)
Try
- 今後も自分は夫婦でエンジニアの人と関わりたいのか立ち止まって考える
- まずは自分の周りの夫婦エンジニアとご飯会などして顔合わせ
- そのメンバーが集まれる日をベースに開催日を決定。
- イベントというよりはあくまでMeetupであることに重きを置く(全員とはいえなくても8割と話せたといえるくらい)
あけましておめでとうございます
あけましておめでとうございます。
昨年はお世話になりました。
本年もよろしくお願いいたします。
今年の目標は「集中」です!
今まで色々やってきましたが、今年は自分のスキル上げていくために、色々手を出さず、自分の時間を作って、自分が伸ばしたいこと、やりたいことのために時間をかけていきます。
目指せGitHub毎日コミット!
あと細々した内容だと
・一番痩せてた頃まで痩せてkeepする(-6kg)
・怪我しないように余裕を持って行動する
・一人飲みは月一回まで
2017年のしょこもよろしくお願いします‼︎
Success is doing, not wishing.
今年も今日で終わりなので2016年を振り返り、2017年の抱負を書こうと思います。
記事タイトルについて
この記事のタイトルは私の軸となる考え方です。
Success is doing, not wishing. (Tom Hopkins)
訳は「成功は行動をすることであり、願うことではない」です。単純ですね。成功するためには羨ましがるんじゃなくて、ひたすらただただ行動しなければならない。そういう生き方をしてきました。この言葉に出会った時、まさに私だと思い、今でも心に残っています。
2016年振り返り
どんな感じだった?
1月:Geek Women Japanの初活動(新年会)
2月:有給消化
3月:転職(2社目)
4月:ほぼ毎日をウィッグで過ごすようになる
5月:早速病んで休んで、某社にインターンシップ
6月:東工大の授業に参加し始めた
7月:とにかく登壇した
8月:入社以来携わってきたPJのリリースに追われてた
9月:めっちゃ移動した(大阪・京都〜北海道)
10月:Geek Women Japan 2016の準備で死にそうだった
11月:心療内科の通院を再開した
12月:業務でScalaが書けるように異動できた
所感
転職してから、社外活動の範囲や規模がどんどん大きくなったなと思いました。
いいことを言うと、社外活動範囲がとても広がったので、自分の居ないところで話題になってたり、「あ、あの羊のアイコンの!」など一方的に知られているケースが増えました。社外に出ているエンジニアの中でも比較的注目されているんだなと嬉しかったです。
でも、自分のキャパシティ以上に社外活動をした結果、髪が抜けてしまったり、本業に影響が出てしまったり、なかなか身体と心のバランスがとれず苦しかったです。
12月からはPJの異動が叶い、Scalaや周辺技術の勉強・開発ができてとても快適です。メンバーも3人でとても気楽です。
2017年はどうする。
基本方針
社外活動を減らします。なんでも安請け合いするのではなく、絞って社外活動をし、自分が本当にやりたいこと(楽器演奏や、自分のプログラミングスキル向上)ができる時間を増やせるようにします。そのために、今iPhoneの壁紙に、以下の質問を設定することで冷静に判断するようにしています。
- 労力に見合った対価が得られるか
- 自分と関係者、どちらも楽しめるか
- 自分と関係者、どちらもおおきくなれるか
- 自分と関係者の周りに人が増えるか
- 寿命が縮まないか?健康削らないか?削っても超回復するか?
これらの質問に「はい」と答えられるものに絞り、自分を尖らせていきたいと思います。
それではみなさん来年もよろしくお願いいたします。
夫のエバンジェリストになりたい #惚気 #夫大好き
この記事は妻・夫を愛してるITエンジニアAdvent Calendarの最終日です。
うらがみさんとTwitterのノリで決めたらその2までできてて衝撃でした。笑
TL;DR
エンジニア夫婦はいいぞ。meetupやるからきてね eventdots.jp
馴れ初め
勉強会「dodosoft」で出会い、結婚しました。今結婚して3年目です。
付き合ってすぐ同棲したので、一緒に住んでるのは4年くらいです。
旦那の好きなところ
優しい
あれやりたいからここ行ってきていい?とか一緒にこれやろうよ!とか受け入れてくれる優しいところが好きです。
松村Advent Calendarや妻・夫を愛しているITエンジニアAdvent Calendarにも参加してくれました。
夫のおかげで社内外で活躍できていると心から思います。
www.adventar.org
muramurasan.hatenablog.jp
交友関係に寛容
学生時代から男友達が多い私で、仲いい友人と二人で出かける時とかも、予め言っておけば行っていいよって言ってくれるところが好きです。この信頼関係が築けているのが良いです。
エンジニアトークで盛り上がれる
rebuildで〜とか、今日はもくもくデートしようとか、そういうノリを受け入れてくれる、むしろお互い楽しめる関係性が築けているところが好きです。
記念日を大事にする
付き合った日、入籍記念日、挙式日、誕生日すべてを大事にしてくれて何かしらイベントをやってくれるところが好きです。
家事ができる
一人暮らしの期間が長かったので家事がほとんどできる。で、私が許せないレベルのところはどんどん直してくれて、今ではすべて任せられます。(例えばおしゃれ着を普通の洗剤で洗うことがなくなりました)
育ちがいい
ご飯を用意する時に、副菜とかもちゃんと用意してくれるところが好きです。
よく褒めてくれる
私が「これできたよー!」とか「発表やりきったよー!」とか言うとよしよしって褒めてくれるところが好きです
一緒にお家Hackできる
詳しくはこちらで。 qiita.com
病気に理解がある
私は精神疾患を患っています。それについて知識・理解があるところが好きです。
私のことをよく見てる
ちょっと調子が悪そうなときとか、疲れているときとか、自分より早く気づいてくれるところが好きです。
お笑いのネタを日常会話に入れて会話できる
サンドイッチマン・アンジャッシュが特に好きな夫の影響でお笑いが好きになりました。日常会話で入れてる/入れてたネタを少しだけ紹介します。
- 「う〜さーむっ!」(ガリットチュウ 福島善成「客を見送ったあとの赤坂見附のキャバクラ嬢」(第8回 細かすぎて伝わらないモノマネ選手権)
- 「居うる!」(ラーメンズ「不思議の国のニポン」)
- すごい角度で撮るセルフィー(バカリズム「女子会」
- 「食べた?」『たべた』「どうだった?」『おいしかった』(ともしげ(モグライダー)「ゴッドタン この若手知ってんのか2015」)
- 「おじゃーん!」「いとみやび」(ゆきのうえ「平安バカップル Peeping Life-World History- #0」)
いいだしたらキリがなくなってきた
のでこのあたりにしておきます。
22くらいで結婚してどうだった?
正直早い方だとわかっていますが、でも、こんな素敵な男性もう現れないだろうなと思いながら結婚しました。
今でもたまにLIKEな男性がでてきたりしますが、「総合的に夫を超えられるか?」と考えると無理ですね
まとめ
こういう話をできる夫婦Advent最高だなーという感じです。これからもよろしくおねがいします。
夫婦エンジニアMeetupやるよ!
夫婦でエンジニアの人って結構いると思うので、仲良くなりたいです!なのでmeetupを開催することにしました!
keynoteはおしどり夫婦でエンジニアとしても活躍されている大場夫妻です。
Hangout参加枠やキッズスペース用意などもしているので、是非お越しください〜
参加できるのは夫婦エンジニアだけでなく、それに憧れる女性や、お子さんです。
おまけ:今年のクリスマスの予定は?
昨日二人でホテルランチしてきました。最高でした。お昼スタートだったのでゆっくりした時間を過ごすことができました。
今日は我が家で私の同僚を呼んでクリスマスパーティーをします!
初めてのクリスマスホームパーティーにわくわくです。やっていいよっていってくれた旦那大好きー!
それではみなさん、メリークリスマス!
主催イベント:Geek Women Japan 2016のふりかえり #geekwomenjapan #gwjp2016
この記事は松村Advent Calendar 2016 最終日です。
最終日は私が強力な友人と企画したカンファレンス「Geek Women Japan 2016」のふりかえりをします。
Geek Women Japan 2016とは
Geek Women Japan 2016は11/3に新宿で開催した、エンジニア女子が中心となって一同に集まり、ギークなセッションを繰り広げるカンファレンスです。
主催はGeek Women Japanで、今回が初の開催です。
私はコアキャスト(メインの運営者)とスピーカーとしてカンファレンスに参加しました。スピーカーとしてのブログはこちら
okoysm.hatenablog.jp
私のやったこと
一人でやったことばかりじゃないですが、主な役割です。
企画
カンファレンスで何を行うのか、どんなプログラムを実施するのかなどなど企画しました
運営
- カンファレンスを運営するためにタイムスケジュールを作成したり、ボランティアスタッフを集めて事前説明会をしたり、当日の指示・サポート・運営活動を行いました
- コミュニティコラボセッションの企画推進を担当しました(締め切り守ってメール送ったり)
広報
2015/10に始動したばかりだったためまずは知名度をあげるために様々な場所でLTを行ったり、懇親会で興味のありそうな人と名刺交換してスポンサー候補として連絡を取り合ったりしました。
Web
Geek Women Japanの公式ページとカンファレンスページを作成しました
配布物作成
チラシを作成しました
スポンサー集め
スポンサー集めました
自分の感想
めっちゃ疲れました。特に9月10月は忙しかったです。自分としては初めてのカンファレンススタッフがまさか当日じゃなくてメインスタッフという。
ボランティアスタッフとの記念写真
得られたもの
- カンファレンスを運営する経験
- SPAを実装するくらいのマークアップスキル
- 人的ネットワーク
- チラシ納品ノウハウ
犠牲にしたもの
- 体力
- 精神的な健康
- 夫と二人で過ごす時間
Geek Women Japanコアキャストの感想
- 初回の割には成功した!でも課題はいっぱい
- 1回目をやれたから、そこからブラッシュアップして2回目はやろう。
またやりたい?
やりたい。てかやりますよ!!!現在準備中です!!
Geek Women Japan代表になりました
もう少しコアキャストほしいので、カンファレンスを創る楽しさ味わいたい人、運営やってみたい人いつでも声かけてね!
あと関西でもやりたいから、そっちでやってくれる人も募集中!
逃げるは恥だが役に立つ #転職
このブログは転職Advent Calendarの23日目です。
昨日は同じ高専出身の先輩で、会社の後輩のいわたんでした。
qiita.com
この記事について
自分がやりたいこと、本当に大切なことを見つけて伸ばせるから、転職はいいぞって話をします。ドラマ「逃げるは恥だが役に立つ」の話は出ません。恋ダンスはサビだけ踊れます。
自己紹介
しょこ (@okoysm) です。高専*1を卒業し、20歳・新卒で総合電機メーカーのソフトウェア開発部門に設計開発者として入社しました。 そして、今年の3月より現職でサーバーサイドエンジニアをやっています。
TL;DR
- 転職してよかったか?と聞かれると失敗と成功半分半分。でも、人生経験として転職はいいぞ。
- 自分のやりたいことと会社に求められていることが一致していると仕事しやすい
「逃げるは恥だが役に立つ」?
恋ダンスで話題の「逃げ恥」ですが、このタイトルはもともとハンガリー語のことわざです。
Szégyen a futás, de hasznos. (ハンガリー語) = Running is a shame, but useful. (英語) = 逃げるは恥だが役に立つ
意味は「戦場を選べ」、つまり「自分の土俵で戦え、自分の得意分野で勝負しろ」という解釈になります。
自分の場合
どこでも役に立てない、中途半端なスキルセットでした。ことわざに合わせて言うならば「戦える土俵がない」と思ってました。なのに逃げました。そんな自分を高く評価してくださった、一番初めに内定をくださった今の企業の内定を承諾し、今働いています。
転職のきっかけ
主なきっかけは3つです。
1. 夫が転職した
2. 作ってるもの・使ってるユーザーがわかりやすいものを作りたくなった
3. 会社の方針が自分の方針と合わなくなってきた
夫が転職した
詳しくはこちらのエントリで
muramurasan.hatenablog.jp
夫が転職したのは昨年の10月です。それまでもなんとなくWeb系への憧れがありましたし、いつかそういうので働きたいなーって思ったりしてました。ただ、身近な夫が転職したのは自分の中で大きなきっかけになりました。夫が人生を考えている今、自分はどうだろう?と。そして、夫が転職して新しい会社で色々なものを得ているのを見て、とりあえずDODAに登録しました。
作ってるもの・使ってるユーザーがわかりやすいものを作りたくなった
もともと作っていたのはオンプレミス環境向け管理パッケージソフトで、主なユーザーはデータセンター管理者を想定していました。開発の理念である「お客様にThank you!と言われるものづくりをしよう」にはとても賛同していましたが、作るもの・想定ユーザーどちらも遠く、「自分が作ったプロダクトは本当に喜ばれているのだろうか?」と考えることが多かったです。
それよりは、もっと身近なものを、身近な(ITリテラシー低い人でも使える)ものを作りたいと考えていました。
会社の方針が自分の方針と合わなくなってきた
自分のいる部門が自社製品を設計開発するのではなくSEとして出向して開発するように会社の方針が変わりました。SEとして一時期金融系B2Cシステムの開発に従事していましたが、あくまでも「ベンダー」だったので、何をするにも制約があり苦しかったです。ここで私は改めて 自分にベンダーは向いてない と思いました。
転職活動どうだった?
基本的に仕事の後だったのと、別業界からの転職だったので体力・精神ともに結構苦労しました。
ちなみにこのときの転職活動はWantedlyと転職エージェント(DODA)を使いました。
嬉しかったこと
いろんな会社のいろんな社風・考え方に触れられた
これは転職活動しなくてもできたのですが、転職活動をきっかけに様々な会社にWantedly経由で訪問しました。
自分の会社とは変わった考え方、服装などとても新鮮でした
メーカーでやってきた「当たり前」が評価された
SIを経験したWeb業界で活躍する方に聞いて気付かされたのですが、例えばテストの方法など、メーカーでは「MECEに」「境界値をみる」など当然とされていることが、Webしか知らない人だと「この辺プログラム難しかったしバグ多かったからテストしておこう」となってる人が多いので、その意味で、メーカーの当たり前をそのまま適応するかは置いておいて、考え方などは悪くないと言われ嬉しかったです。
好きでやってた社外での活動が評価された
当時、私は業務外で女性エンジニアコミュニティ「dots.女子部」の若女将(運営メンバー)をやっていました。また、dots.女子部のイベントを中心に様々なイベントで登壇していました。私自身は好きでやってただけなのに、それが転職において「強み」として評価されたのは嬉しかった
辛かったこと
主に辛かったのは3つです。
業務後疲れた状態で面接を迎えること
ちょうど転職活動していた時期が忙しかったため、頭が回ってない状態で役員面接を何度も迎えました。
もし本命を受けるときは半休とるなどしたほうが良かったなと今では思います。
自分のスキルセットがWebと合わない
自分が主にやっていたのはフロントエンドとバックエンドの開発とオフショア開発のブリッジSEだったのですが、それがWebのスキルセットと合いませんでした。
私がやってたフロントエンドは前時代的なもの(Flex/ActionScript3.x)でしたし、バックエンド開発をやっているといってもWebサービスではなかったのでバックエンドも合わず、ブリッジSEは英語アピールの一つくらいにしかならず、インフラは業務知識であるだけで自分のやりたいことに合わない。
とても苦しかったです。
ゼネラリストではなく、ほどほどにしかできない器用貧乏
私の職務経歴書を見ると分かるんですが、年齢(25歳)の割に経験してきた担当工程めちゃくちゃ広いんですよ。ただ、これは裏を返せば「これなら任せてください」という強みがないということです。
転職活動において、自分を採用するメリットをPRするのはとても難しいです。
今の会社に評価されたポイント
入社前後で聞いた話を踏まえると以下の3点かなと思います。
ポテンシャル
20歳で就職したので面接時は24歳なのに4年目で前職での担当工程はビジネス側から開発のテスト・納品まで多岐にわたり、かつオフショアのブリッジSEもやったり、研修の一環で営業や工場のラインやったりと、いわゆる理系大学院2年生と同じ年でたくさんのことをやってきていました。
それに加え人見知りしないので、新しいものをどんどん吸収するために周りを巻き込めるのではという点でした
テクノロジーブランドの向上要員
私は社外での活動が好きですが、弊社の多くのエンジニアはあまり発信しません。「勉強会に参加しよう」って言われてるくらい、参加すらしない人が多いです。
そんな中、勉強会に参加するだけじゃなく、企画したり運営したり登壇したりする人が来るだけで社内に新しい風を吹かせられるという点が評価されました
会社にいない「新しい風を吹かせてくれる人材」
自分で書くのも恥ずかしいですが、勉強会に登壇したり、新しい仕組みを導入したり、アジャイルな開発に慣れていたり、一通りの工程を経験していたり、とにかく行動力とスピードがある。そんな人材弊社には居ませんでした。
ですので、テクノロジーブランドを向上すべく「新しい風を社内に吹かせてくれそう」という点が評価されたと思います
転職した感想
成功したと思った部分
新しいこと・楽しいことをガンガンできる
「新しい風を吹かせてくれる人材」と見られているので、デザイン思考*2や、アジャイルのプラクティス、新しいフレームワークの導入など、新しいこと面白いことをたくさんやらせていただいています。
Mashup Awards for Proにも出させていただき、実際にチームを優勝に導きました。
okoysm.hatenablog.jp
自分が本当に大事にしたいことが分かる
転職した時は「ITリテラシーが低い人でも使ってるB2CのWebサービス開発がしたい」と思っていたのですが、実際転職して自分が大事にしたいことは、
「職能に縛られず自分がチームで考えたいいとおもったコンテンツを世の中にガンガン出したい」「技術面の師匠がすぐそばに居ること」だったことです。
失ってから初めて気づくとはよく言いますが、まさにそれで、前職はとても恵まれていたのだなと改めて感謝しました。
失敗したと思った部分
※注意※以下の失敗した部分については、自分なりになんとか失敗にしないように改善案を検討・実践しています。
面接官の話していた言葉の定義が自分と違った
面接官は「上流から下流のテストまでできる」と聞いていたのに、実際はウォーターフォールみたいな開発手法を採用しており、サーバーサイドエンジニアはディレクターから降りてきた仕様を詰めて、実装するというスタイルでした。悪くいうならば社内外注ですね。
私はこの言葉を「上流のコンテンツ検討からデザイン、フロントエンド開発、サーバーサイド開発、テストすべてに携われる」と思っていました。
ですが面接官は「上流のマネジメントや下流の担当レベルの開発までできる」という意図で話していたことが入社後にわかりました。入社当時フロントエンド・バックエンド両方やりたいと思っていた自分としてはまずここで大きな失敗をしたと思いました。
開発環境が想像以上にレガシーだった
まずウォーターフォール開発で一つ一つのフェーズで中間成果物を作成して開発しているためとてもリリースまでに時間がかかっています。前職ならこれくらいもっと早く終わったのに・・・悔しい・・・という気持ちを感じることが多かったです。
この会社に転職してから定時後2週間ほど某社に社会人インターンに行っていたのですが、初めてRuby on Rails触った人が実装しても、弊社なら3ヶ月かかりそうな規模のリリースを行いました。
開発環境のレガシーさは語ればキリがないので一つだけいいます。メインサービスはEOLを数年前に迎えているPHP5.x系*3で動いています。PHPの最新バージョンは7.1です。
自分の伸ばしたいスキルと会社に評価されるスキルの不一致
半期に一度の上司から評価されたのですが、評価が高かったのは「この会社で身につけたスキルを発揮した時」ではなく「前の会社や社外で自分が見つけたスキルを発揮した時」です。中途採用者だしそういうものなのかもしれないけれど、自分は普段の業務で手札を増やすために転職したのに、外や前職で手に入れた手札を出すことのほうが評価されてしまっている。もっと言えば、業務よりその手札を出すことを期待している人も社内に少なくありません。
そんな状況で今25歳。ここで20代後半を過ごして30以降エンジニアとして生きていけるのだろうかと日々考えて、色々試したりしています。例えば、アーキテクチャ検討・Scalaの実装に集中できるチームに異動したり、転職DRAFTにENTRYするなど。
今後どうする?
逃げるは恥だが役に立つ。でも、やりたいこともやる!
ここでタイトルに戻ります。意味は「自分の土俵で戦え、自分の得意分野で勝負しろ」でした。
そして自分のやりたいことが、「職能に縛られず自分がチームで考えたいいとおもったコンテンツを世の中にガンガン出したい」「技術面の師匠がすぐそばに居ること」です。
だから、今後は自分の得意分野を活かしつつやりたいことができる職場に今の職場を改善するか、私の得意分野を求めていて、かつ私のやりたいことができる職場に移るかしていきたいと思います。
Always Job Hunting!!
20代後半ガッツリ働きたいので、「あなたみたいな人材がほしい!師匠もつけるよ!」という会社のみなさま、Wantedlyなどで連絡ください。
参考リンク
学習メモ: クラス (2/2) #dwango #Scala
この記事について
ドワンゴScala研修テキストを学習したときのメモです。 okoysm.hatenablog.jp
前回はこちら okoysm.hatenablog.jp
DOING
クラス
メソッド定義
メソッド本体が1つの式だけからなる場合
基本形(実態)。
(private[this/package名]/protected[package名]) def methodName(parameter1: Type1, parameter2: Type2, ...): ReturnType = ???
一般的な定義
={}
を使ったスタイルのほうが{}
内に複数の式を並べて書けることを利用した派生形。- こっちのパターンのほうが使うことは多い
(private[this/package名]/protected[package名]) def methodName(parameter1: Type1, parameter2: Type2, ...): ReturnType = { ??? }
返り値の型は明記しよう
- 省略しても特別な場合以外は型推論してくれるけれども、読みやすさのために明記する習慣をつけよう
- 個人的にはこれがいいから静的型付け言語好き
アクセス権
- アクセス権は3種類 (private, protected, public)
Scala独特のアクセス権まわりの書き方
- private[this]:同じオブジェクトからのみアクセスが可能
- private[package名]:同一パッケージに所属しているものからのみアクセスが可能
- protected[package名]:派生クラス+同じパッケージに所属しているもの全てからアクセスできるようになる
メソッドを実装してみる
メソッド名に+を指定できるのが衝撃だった
scala> class Point(val x: Int, val y: Int) { | def +(p:Point): Point = { | new Point(x + p.x, y + p.y) | } | override def toString(): String = "(" + x + ", " + y + ")" | } defined class Point scala> val p1 = new Point(1, 1) p1: Point = (1, 1) scala> val p2 = new Point(2, 2) p2: Point = (2, 2) scala> p1+p2 res0: Point = (3, 3)
複数の引数リストを持つメソッド
メソッドは複数の引数リストを持つように定義することができる
def methodName(parameter11: Type11, parameter12: Type12, ...)(...)(parameterN1: TypeN1, ..., parameterNM: TypeNM): RerurnType = ???
用途
実装してみる
複数の引数リストを持つ加算メソッドを定義してみる。
- 複数の引数リストを持つメソッドはobj.m(x)(y)の形式で呼びだす
- 一番下のように、最初の引数だけを適用して新しい関数を作る(部分適用)こともできる
scala> class Adder { | def add(x: Int)(y: Int): Int = x + y | } defined class Adder scala> val adder = new Adder() adder: Adder = Adder@5132ea8c scala> adder.add(2)(3) res2: Int = 5 scala> adder.add(2) _ res3: Int => Int = $$Lambda$1791/569849097@1ceeb7d7
疑問点
- 複数の引数リストを持つメソッドで、最初の引数だけを適用して新しい関数を作る(部分適用)の使い所はどこ?
フィールド定義
定義
(private[this/package名]/protected[package名]) (val/var) fieldName: Type = Expression
val/var
- val: 変更不能なフィールドになる
- var: 変更可能なフィールドになる
アクセス権
- private : そのクラス内だけからのみ
- private[this] : 同じオブジェクトのみ
- private[package名] : 同一パッケージからのみ
- protected : そのクラスの派生クラスからのみ
- protected[package名] : 派生クラスと同一パッケージに所属しているもの全て
- なにもつけない:public
private[this]は若干高速
- JVMレベルでのフィールドへの直接アクセスになるため、若干高速
- 細かいレベルでのパフォーマンスチューニングをする場合は意識すると良い
継承
クラスのもう一つの機能が継承
継承の目的
Javaの継承の目的とあんまり変わらん
実装の継承におけるJavaとの違い
ScalaはTrait(次々回)を使うことで複数の実装の継承ができる
実装の継承には複数の継承によりメソッドやフィールドの名前が衝突する場合の振舞いなどに問題があることが知られており、Javaでは実装継承が1つだけに限定されています。 Java 8ではインタフェースにデフォルトの実装を持たせられるようになりましたが、変数は持たせられないなどの制約があります。 Scalaではトレイトという仕組みで複数の実装の継承を実現していますが、トレイトについては別の節で説明します。
通常のクラスの継承の構文
Javaと同じくextends
書く
class SubClass(....) extends SuperClass { .... }
メソッドをoverrideするとき
JavaはアノテーションやJavadocで記載していたが、Scalaでは明示的に書く
scala> class APrinter() { | def print(): Unit = { | println("A") | } | } defined class APrinter scala> class BPrinter extends APrinter { | override def print(): Unit = { | println("B") | } | } defined class BPrinter scala> new APrinter().print A scala> new BPrinter().print B
この章での疑問点
- コンストラクタの引数をそのまま公開したくない場合などあるのだろうか(Javaでいうprivateな変数にしてgetter/setterで取らせたいみたいなやつかな)
- 複数の引数リストを持つメソッドで、最初の引数だけを適用して新しい関数を作る(部分適用)の使い所はどこ?