ハッピーバイクライフなう

運動神経ゼロの私が、普通二輪の卒業検定に受かるまで。 - おもろいことしかやらないという記事の続きです。

花壇を破壊し、教官に白い目で見続けられながら約2.5~3ヶ月ほど教習所に通いました。

真夏の教習はマジでお勧めしません。

8の字のような細かい動作を練習する場合、クラッチ操作でエンジン部分に負荷がかかり、車体がクッソ暑くなります。
（そうでなくても体感40度超えなので、たまに熱中症で教習生が救急車で運ばれていくそうです。）

私は教習中にウォオオン！という突然のスーフォア（教習で使うHONDA CBR400SF）の叫びを聞いたために、思わず8の字花壇の中で絶叫した事があります。

乗りたいバイクがたくさんあった話

それでも今後苦楽もしくは死を共にするバイクを探すのに勤しんでいました。
ハーレーダビッドソンも魅力的でしたが、現実的ではないという事でHONDAのREBELなどを候補に入れていました。が、たまたま見かけた女性ライダー誌を見るとまあREBEL率が高い。

人との被りが苦手な私は、教習所で見かけたGSX250R(2015)に一目惚れするのでした。

自分に合うバイクVSかっこいいバイク

レンタルバイクで初公道に。
見るも無残に目の前を横切ったクロスバイクとエンカウントし、フロントブレーキをかまして無事に貸し出し業者の前で立ちゴケました🙂🌷
元々足つきも悪く、重心がズレる瞬間に片足では184kgを支える支点を見つける余裕もなく…おそらく初めてのツーリングでは10回程度はこけたんじゃないかな？（都心から飯能市まで出ました）

修理代はレンタルの5倍くらいかかりました。
憧れのバイクで立ちゴケましたし、寒いし途中で動かなくなるし呆然としてしまう瞬間もありました。

それでも、直線を走るときの…あのアクセルを開けた時の音や、感じる風が心地よくて、もっと乗りたい！運転が上手になりたい！という気持ちがさらに大きくなりました。

（同行してくれた人・業者さんには目一杯迷惑かけたので、ごめんですが…）

そのあとは現実的なラインを探りながらウィンドジャマーズ→スズキワールド→SOX→YSPって感じで嫁探し。懲りずにスーパースポーツに絞ってました。

納車！

私の貧弱な体ではSSを支える事が難しい＆運転への恐怖が払拭できていないという事を考慮して、gixxer(2017)をチョイスしました。134kgという軽量な車格と、125cc超えだが250程いかつさもないというところが魅力的。何より倒しまくって練習するにはいいだろうと考えました。

総額310k強かな？それでもめちゃくちゃ分割した。（修理代未完）

初期不良とかは勘弁なので、スズキワールドさんでお世話になりました。

アリさんみたいな見た目のgixxerちゃんと対面。一緒について来てくれる人もいたので、不安よりも楽しみな気持ちが上回ったのです。

納車2日目にして横倒しし、エンジンタンクに傷を付けました。が、夜の練習はサイコーです。
人を轢かずに、ちゃんとウィンカーを出して交通状況に気を配る自分に拍手を贈りたい👏

今後はグッドライダーと呼ばれるくらいに運転テクを上げていきたいです。
次の目標は道志とタンデムだな！

令和元年基本情報技術者試験を振り返る

言い訳3行

・アルゴリズムの正答率は77％、Java66％だった。
・情セとセキュリティで死んだ
・ちょいちょい凡ミスが多かった
→午後で足を引っ張って死んだ、自己採点は60％＆51％だった。

傾向

【午前】例年より難化傾向らしい。隣接行列、レジスタの16進数への符号化？問題などが出題される。ROIとかSEOポイズニングとか微妙なポイントの引っ掛けが出てきて、付け焼き刃の知識を嘲笑われている気がしてならない。
正答した問題については自信を持って説明できるが、わからんやつは本当にわからんかった。監査系の問いが若干多めだった？（ストラテジ苦手）

【午後】平年どおりの難易度らしい。
アルゴリズムとJavaに時間を極振りしたので、情セとセキュリティの問題を読み上げ終わった頃にはつい他人事のようなテンションになってしまった。

対策

【午前】いつもの参考書と時事ニュースも見るか。

【午後】Javaは使わないとはいえ、メイン関数の例外宣言は正答しないとまずい気がする。アルゴリズム対策の本を続けてやるか。
ついにTCP/IPに手を出すことにする。
後半はいつも通り問題解きまくるコースで。

午前問題の問21

職場のH先輩に教えてもらった。
レジスタ、ストローブ、クロックなどの単語たちが完璧に説明できなくても解ける問題。

この

データを符号化する。ストローブが上がるところまでが観測範囲。

問題文

```
クロックの立ち上がりエッジで、８ビットのシリアル入力パラレル出力シフトレジスタの内容を上位方向へシフトすると同時に正論理のデータをレジスタの最下位ビットに取り込む。
また、ストローブの立ち上がりエッジで値を確定する。各信号の波形を観測した結果が図の通りである時、確定後のシフトレジスタの値はどれか。ここで、数値は16進数で表記している。
```

クロックの立ち上がりエッジで、８ビットのシリアル入力パラレル出力シフトレジスタの内容を上位方向へシフトする
→なんか論理シフトする内容なのはわかる

正論理のデータをレジスタの最下位ビットに取り込む
→booleanと仮定して、レジスタの最下位がtrue(1)
になる

また、ストローブの立ち上がりエッジで値を確定する。各信号の波形を観測した結果が図の通りである時、
→ストローブが凸している時データの内容が確定する

図から読み取れること
ストローブが凸しているところまでのクロックは9回立ち上がっている
→9回論理シフトと最下位ビットへの書き込みが行われる

図に照らし合わせてクロックのエッジのタイミングを2進数で表現する

0000 0001←1回目

0000 0011
0000 0110
0000 1100
…
1000 1101←9回目のシフトと書き換え

これを2進数から16進数で表現する。

1000 1101

1000→2の7乗で128
1101→2の3乗 2の2乗 2の0乗で13
128＋13＝141

141/16=8 141%16=13
13→16進数でD

8D イが正解

先輩マジ天才です。
これをあっさり解く先輩がおわす弊社のエンジニアについてはこちらからどうぞ。笑

運動神経ゼロの私が、普通二輪の卒業検定に受かるまで。

普通二輪免許を取得しました〜🎊👏👏

卒業証明書の状態なので、公道を走るまでにまだもう少し猶予があります。

教官に幾度となく「ギアの変え方忘れちゃったの！？」「交通法規守って！」のようなお言葉をいただき続けた練習期間だったので、皆様にご迷惑をおかけしない為にも家の周辺で練習をしていこうと思ってます…orz

実はこの免許を取るまでに卒検は3回受けました。

スペック：運動神経ゼロ奴

中学生まで自転車乗れなかったウーマン。
今は通勤でクロスバイクに乗ったりする。
球技スポーツなどは悉くノーコンなのでマジで参加したくない。多分球に対して特殊な磁場が発生している。

そんなウーマン、なんとなく、暇だな〜。遠くへ行きたい。二輪かっこいいという憧れを抱く

梅雨の時期のある日、家で開発したり本を読むなどしていたのですが、
目疲れたな…他の事やりたいとぼんやりするタイミングが増えました。

以前だったら水彩画を嗜んだりしていましたが、社会人になってから趣味が変遷してきたなー…と。
他に何をしてきたかというと、西関東へ鈍行で遊びに行ってコンデジで写真撮影したり、地元の美味しいものを食べたり…でも熱海とか箱根とか鉄板は行きつくした感ある…
足がほしい

何もしたくないときはゆるキャン△を見て脳のオーバーフローを鎮める作業に入る私なので、凛ちゃんが格好良く見えて仕方ないわけです。

\\ ---イメージをお伝えしたく、突然の素敵記事---
nlab.itmedia.co.jp

ちょっと田舎の方の緑に囲まれながら、風を切って走る。しかもこの乗り物は自分の主導権で動く！というポイントにも惹かれ、よし。申し込みしよう。と何も考えずに申し込みに向かったわけです。

即申し込み〜引き起こし

地元から近めで評価も高い尾久教習所にお世話になりました。
教習ってうんざりすることが多いけど、技術教習に関するレビューの高さが異様だったのでここに決定。
（別にHPのデザインが可愛いからとか、TLS接続しているからは決定打ではない）

受付のお姉さんに普通二輪を取得したい旨を伝えると、横から出てきたお兄さんが「バイクの引き起こしをしてください。出来なければ申し込みは受け付けられない」とおっしゃる訳です。わーお。

軍手を借りて、教習車が止まっている屋根下のスペースで引き起こし体験。

わっ！バイク思ってたより大きいなあ！
まあ腕筋については根拠のない自信もあるので、大丈夫でしょw

でもこの子207kgあるの。

www.bikebros.co.jp

掴んで、引き上げるをするだけで悲鳴をあげる私の腰。（なんかビッ！て音がした気がする）
お兄さんから引くのではなく押す、というレクチャーをいただき無事引き起こし完了。
「わっ。意外に力ありますね！」と私のゴリラっぷりを目の当たりにしたお兄さんに世辞をいただいて、ちょっと得意げになる私。しかし本当の地獄はこれからだった。

教習〜普通二輪には乗れないよ〜

教習開始早々、追突・車両横転・加速不良に苛まれる私。

だってバイク怖いんだも〜ん！！

そう、みんな簡単そうに走るけど、思ったよりも操作性が複雑で、加速するまでの指示系統が身につかないうちは

操作をミスると突然猛スピードで発車する重たい鉄の塊🏍🏍🏍=3

「えっ！？重ｯ！？💢💢」と免許を取りに来たにも関わらず、車両に理不尽な逆ギレをする私。見かねた教官の指示で、125ccからの練習になったのでした。
そういえば私は原付にも乗ったことがなかった…
教習所で出来たお友達にお願いし、時間があれば夜の武蔵境で練習もしてみました。
速度とアクセルの回し方の雰囲気については学べるのでオススメ。
2回ほどで普通車の練習に戻ることができました。

番外）ばくおん!!

うだる暑い夏の日にそんな事をしているので、モチベーションも疲労とともにやって来やすいのです。そんな時は美少女とアニメで癒されよう……
という事で合間にばくおん!!をウォッチします🦀

bakuon-anime.com

けいおん!にかぶれとるな〜という第一印象から入りつつも、作中のバイクはどれも精巧に、格好良く描かれていて、その中にバイクを通して深まる関係性の描写もあり、普通に知識がなくても楽しめる作品でした。
ベテランがゆえに、バイクの定義にこだわってちょっとこじらせている中野ちゃんが好きです。

ミス・コースアウト

そんな感じでバランスを保って乗車できるようになるまでたくさん申し送りを受けて、同じ項目で人の倍教習を受けたと思ってます。

等間隔に置かれたパイロンを通過する時は、肩からハンドルを曲げる動きを練習してました。
狭路については低速で安全な走りを実現しなければならないところを、手が滑ってアクセルで速度がかかり、8の字の中に花壇に衝突して破壊活動を行うなどしてました。ｷｬｰｰｰ!!!!>-🌷🌷🌷🏍=33

コースの植え込みを直している教官の大きな背中を見て、お花・教官マジですまんよ…と心の中で謝る日々。

教官にしつこく半クラッチを使用しての走行を要求される時。
同じ項目で受けている隣の教習生の走りがめっちゃ綺麗な時。
モチベが下がりまくるので上のばくおん!!鑑賞に戻ります。
（でも半クラは超大事）

後半に〜続く〜

Kotlin Fest2019に参加しました<<後編>>

残暑お見舞い申し上げます。

まだまだ暑い日が続きますが、次回の基本情報技術者試験まで1ヶ月強となりました。
午後の練習問題は相変わらず6割超えないくらいに終わってます…。

さて、転職したばかりの環境でヒィヒィ言っているうちにとうとう9月の中旬になってしまいました。増税前に会社の金で行ったKotlinFest後編についてまとめていこうと思います。

八木俊広さん ( @sys1yagi )
Kotlin コルーチンを 理解しよう 2019

小谷野 雄史さん ( @bandwagondagon )
Coroutinesから紐解くKtorの仕組み

Malvin Sutantoさん ( @MalvinSutanto )
Code Generation in Kotlin with Annotation and KotlinPoet

木原 快さん ( @gumimin_ )
もっと Kotlin × Spring

荻野陽太さん ( @youta1119 )
Kotlin/Nativeはなぜ動くのか？

Kotlin コルーチンを 理解しよう 2019

Ktorってなんとなく使ってみたけどこの記述は何をしているの？他のDIライブラリと何が違うの？？という疑問にぴったりな講演でした。

Ktorとは？

KtorはDIをもたらすことで薄いフレームワークを作ってくれます。
よく***Application.ktに書いているinstallというブロックは機能の追加をする役割をしています。

Ktorは計算パイプラインの機構を提供しており、FeatureやRoutingの実行順序を柔軟に変更することができます。

例えば
Thread1はリクエストをするが、計算待ちの場合は他のリクエストを受け付け、
並行して走るThread2は計算ができます。
計算終了後、Thread2はThread1の処理と合流します。

suspend

別スレッドでリクエストを受け付ける事ができる

launch

ブロック内ではThread3を生成するが、終了しない場合は全てのパイプラインが実行を待つ。

async

ブロックでは別スレッドを生成し、これが終了するまで次のCallフェーズには移らない。

proceed, await

suspendしながら次のフェーズまで処理をする事ができる。最後のフェーズが終了したらまたMonitoringフェーズに戻り、全ての処理が完了したら処理が終了する。効率的に計算する事が可能。

Continuation(コールバックが入ったクラス)

suspend

コード実行を中断する可能性がある。同じサスペンドの中で呼び出す事ができる
通常の関数からはビルドエラーする
→コンパイル後は引数にコールバックが入る＋返り値がAnyになる

suspendの呼び方

suspendブロック内でstartCoroutineで走らせる事ができる
返り値（途中中断した場合マーカーがかえる）を持つ関数がある。

continuationを受け取る関数もある（状態の制御が可能）

マーカーを返却することで強制的にスレッドの終了が可能

ApplicationObjectをフェーズ間で共有する事ができる

Code Generation in Kotlin with Annotation and KotlinPoet

こちら外国の方の講演でした。KotlinPoetというAPIライブラリを使って、アノテーションを作っちゃおうぜというお話でした。

まず、全体的に話のレベルが高かったです。
おそらくこれはKotlinを使ってライブラリか何かを作りたい人向けのもので、
私が唯一感覚としてハマったのは、あるJsonパーサーを使っていて遭遇したキャスト関係のエラーについてくらいでした。

（正直よくわからんかったです。自分に知識が足らなすぎて…
下記内容はほぼほぼ自分の解釈+言葉遣いになるので、ニュアンスが違ったら教えてください。）

メタプログラミングについて

機能に振る舞いを加えたり、変更したりする。
ex)実行中はリフレクションやパーサーとして、コンパイル時はジェネレータとして、
実行中にファイルやプロパティを読みこむ。

ex)変数を読み込む、機能を呼び出す
xmlやjsonのように解釈する

保守しづらいバッドプラクティスなコードについて考えてみよう

入力に基づいてファイルを生成する
アノテーションはソースコード、バイトコードもしくはどのような種類のファイルでも出力できる。
安全にコンパイルする
静的にコードを解析し、実行前にエラーするのを防ぐ。

アノテーションプロセッサはJava6から加えられたAPI仕様。

@AutoMapはデータクラスをMapとして解析できるようにコンパイルしてくれます。
こやつから

@AutoMap
data class Person(
val id: Long,
val name: String?,
val address: Address
)

こう

/* *
* Converts [Person] to [Map].
*/
fun Person.toMap(): Map {
val map: Map = mapOf(
"id" to id,
"name" to name,
"address" to address
)
return map
}

kotlin-stdlibをGradleにDIすると使えます(not AndroidModule)

講演者はmetadataもオススメと話していましたが、こちらは割愛します🙇‍♂️

KotlinMetadataUtilsを実装するgetSupportedAnnotationTypesをオーバーライドする事で設定の文字列を返している。
@AutoPlocessorは別途build.gradleで追加する。

ClassNameで返り値のマップを指定できる

val returnType: ParameterizedtypeName = ClassName("kotlin.collections", "Map")
.plusParameter(String::class.asTypeName)
.plusParameter(Any::class.asTypeName().copy(nullable = true))

プレースホルダーで%T, %Mと変数をリプレース出来る
これはKotlin特有の型推論を使ったテクニック👏

if (element !is TypeElement || metadata == null) { …

mapOfの返り値を指定する
％S ->string, %L -> literal

Funspecでにアノテーションだけではなく、コメントを加えることができる。
引数の型と返り値の型、KDocを書いていく事ができる。

val mapClass = ("kotlin.collections", "Map")

val funSpec = FunSpec.builder("toMap")
.receiver()
.returns()
.addKdoc("Converts [%T] to [%T].", className, mapClass)
.addCode(codeBlockBuilder.build())
.build()

FileSpec.builder(className.packageName, className.simpleName)
.addFunction(funSpec)
.addComment("This is a generated file. Do not edit")
.build()
.writeTo(outputDir)

どんなコードができるかは101枚目のスライドを見てみましょう。

感想としては、自分たちが使っているライブラリたちは、きっとこのような過程を経て出来ていくんだなあ、と。言語特性をフル活用してコーディングする経験としてはライブラリ作成ってかなりいいのかも。
そして、完全にKotlin製のライブラリって実はOKHttp4のようにまだまだ少数派なのかも…と思い直す講演でした。

もっと Kotlin × Spring

こちらの講演は、今の現場でSpringを使うことが多い為に聴きに行きました。
別途まとめ直すかもしれません。

Kotlin/Nativeはなぜ動くのか？

CyberAgentからギークな新卒の方がお話をされにいらっしゃってました。
Kotlinをコンパイルする為に必要なミドルウェア(LVVM)のお話周りです。

KotlinFestのひよこ

前記事にも書きましたが、Kotlin界隈の方々は親しみやすく、一定数ギークな人たちが集まっているコミュニティという印象です。

そこでのエンジニアは純粋に好きなものを追いかけていて、それがどのような方向性であれ容認していくところが素晴らしいと感じています。

ちなみに、我が社のKotlin使いの先輩はGraphQL、Springなど使って管理画面を一新するそうです。。
酒の誘惑に負けずに共に頑張りましょう（私自身、酒はそんなに飲みませんが…）

私はもう少しSpringとお友達になることにします🌸

Spring Boot事始め

仕事でJavaを扱うようになったので、SpringBootと仲良くなる方向性になりました🐕

エンジニアなりたての頃にEclipse(pleadis)の重さに悩まされ、Javaのわからなさ・書けなさに悩んだ記憶から早3年…

今回はフレームワークの根幹であるSpringBootについて先輩からご教示いただいたので、メモっていきます。

SpringBootとは

Javaプラットフォーム向けのオープンソースライブラリ。 アスペクト指向プログラミングを根幹にしたフレームワークで、webやsecurity、batch処理などの機能を備えている。 DI機能を使うことができ、環境ごとに使う関数を切り替える事が出来るなどの旨味がある。

DIとは

依存性の注入のこと。 クラス内で使用するメンバにアノテーションを付与することで、宣言と初期化が同時に出来る。

そのインスタンスは外から参照されるものの、その状態を気にせず使用できるところがポイント。 イミュータブルなオブジェクトの作成が推奨される設計の場合非常に便利。ただし、意図的に初期化ができてしまう機能も存在する為、プロジェクトの設計方針に応じて使用する。

依存性の登録方法

①自動(コンパイル時によしなに依存性の注入を行う)

@Component
　∟@Service
　∟@Controller

②手動(作成者が意図的に依存性の注入を行う)

- XML
- JavaConfig

@Component

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Indexed

などのinterface群により定義されている。 ルートのクラスで@ComponentScanを付与することによって、このアノテーションが付いた下位クラスを探す。 後述するBeanをDIコンテナに登録する為のアノテーション。

JavaConfig

DIコンテナを登録する為のクラスファイル。定義ファイルなどではない。 @Beanアノテーションを付与することによって、メソッド名と同名のBeanが作成される。 インスタンスはSingletonに扱われ、DIコンテナ1つにつき1つ作成される。

Bean

ライフサイクルの衝突を避けてインスタンスを静的に生成する。 あるクラスのメンバをBean(豆)のように内包した形で上記を実現する。

依存性の種類

①フィールドインジェクション

②コンストラクタインジェクション

③セッターインジェクション

①フィールドインジェクション

独自に依存性の注入を行うや方法。

public class ImageThumbnail {
  @Autowired
  private ImageRepository imageRepository;   
  public ImageThumbnail() {   
  }
}

②コンストラクタインジェクション

springに依存せず、独自に依存性の注入を行う方法。

public class ImageThumbnail {
  private ImageRepository imageRepository;   

  public ImageThumbnail(ImageRepository imageRepository) {
      this.imageRepository = imageRepository;
  }
}

③セッターインジェクション

lombokを使用してgetter, setterを出力する方法。 イミュータブルではなくなってしまう為、扱いに注意が必要。

public class ImageController {
  private ImageRepository imageRepository;

  public void setImageRepository(ImageRepository imageRepository) {
    this.imageRepository = imageRepository;
  }
}

Springに捧げるとよしなにセットしてくれる

@Service
public class ImageService {
…
}

Kotlin Fest2019に参加しました<<前編>>

残暑お見舞い申し上げます。

新職場1週間目でした🎉🎉🎉 環境構築諸々など無事に済んでよかった。

今回はなんと会社のお金で週末にKotlinFestに参加する権利をいただき、エンジニアらしい行事に参ずる事ができて感無量でした。

小さな勉強会にはちょくちょく参加していましたが、Kotlin書く人達（Kotler?）は温和で親しみやすい雰囲気でありながら、ギークな部分が垣間見える面があり、非常に良い雰囲気の中で勉強させてもらいました。

断片的ではありますが、内容をまとめていきたいと思います。 自分が聞いたのは下記の5セッションです。

1. オープニングセッション
長澤太郎
Svetlana Isakova

2. Server-side Kotlin by Ktor
Coroutinesから紐解くKtorの仕組み
小谷野 雄史

[EN]
3. Code Generation in Kotlin with Annotation and KotlinPoet
Malvin Sutanto

4. もっと Kotlin × Spring
木原 快

5. Kotlin/Nativeはなぜ動くのか？
荻野陽太

オープニングセッション

遅刻したもので、長澤さんが「Have a nice Kotlin !!」という部分からの参加になってしまったorz Svetlana IsakovaさんはJetBrains社（Kotlinを開発した会社の人）らしく、これまでのKotlinの進化についてや、魅力的な機能を紹介してくださっていた。

Kotlinは既存のコードを壊さないような構造をしている

まだ自分の経験の中で実感できてはいないが、前の職場ではJavaのリプレースをKotlinで少しずつやっていて、共存が出来ていたので確かにこれは便利なものだと思っている。

コミュニティでは常に問題共有を行い、対応していくことを考えている

コミュニティについては、プロダクトコードをほとんど書いていなかったこともあり、胸を張って参加する事が出来ていなかったが、今後は積極的に情報のキャッチアップをしたい。（特にJavaの方も）

Kotlinをより良いプロダクトにする為にみなさんからフィードバックが欲しい

とのことで、いくつかの機能について紹介をいただく。

• inline class
• extention property
• immutable collection
• flow(experimental)
• multi platform project

改めて思ったのは、本当にKotlinの言語仕様わかってなさすぎた… 他のエンジニアと自分のコードを見比べたり、客観的にアドバイスいただいて思うことはこの知識量の差でもあるなと実感。 Kotlinの良さをしっかり理解してコードを書くというよりも、今まではAndroidの機能を実装するということにウェイトを置いてしまっていたと実感した。

今はSvetlanaさんは新しいKotlinの本を執筆されているそうで（仮タイトルはAtomic Kotlinだったかな）、これはプログラミング初心者や、Java初心者でもついていけるような内容にしていくそう。

初めて型言語の大きな勉強会に参加したけど、Railsやフロントエンドの時よりも、女性エンジニアが少ないのが少し気になったのよね。 もう少し同士が増えたら嬉しいななんて思う。

www.coursera.org ちなみに、こちらのCouseraからAuditモードでKotlinの学習ができるそうです。

基調講演のSvetlanaさんのスライドはこちら。

基調講演での技術紹介

ここからは聞き取れた内容と、Svetlaさんのスライドを雑に訳す+補足情報を加える事で自分が解釈できた情報を書いていきます。 まだ実際に試していない内容になるので、ご注意ください。 サンプルコードについては、スライドより抜粋させていただきました。

- inline class

オーバーヘッドなしに値をラップできる いまは実験段階

Duration APIは1.3.50で実験的に提供される

同じ関数を違う型で扱いたい時、その分だけオーバーロードするには冗長的すぎる。 そんな時、クラスでラップしてあげれば他の方のオブジェクトも割り当てる事ができる。

inline classを定義し、下部で関数を定義できる。

また、inline classではval(再代入不可)なコンストラクタしか宣言ができない。

この性質を利用して、明示的な単位を設定することができる。

val Int.seconds
  get() = toDuration(DurationUnit.SECONDS)
fun greetAfterTimeout(duration: Duration)
greetAfterTimeout(2.seconds)

- contract

日本語で契約、約定という意味。 スコープ関数として定義され、自身をレシーバとした関数を実施し、その内容を返す。 しかし、runブロックの中で初期化をしてしまうとコンパイラがそれを検知できない為、エラーを返す。（これについては仕様。後述する。）

isNullOrEmpty()についても同様。 レシーバにヌル許可を割り当てた場合、これを検知する為にエルビス演算子を挿入する必要がある。

しかし、contractsはコンパイラに明示的にコードのその他の情報を共有する。

ブロック内では1度きりのみ呼ばれるようになり、

関数が偽を返せば、レシーバがヌル不可であると解釈する。

これを利用してrunブロックでの変数初期化、エルビス演算子なしでの解釈が可能となる。

なぜコンパイラに情報が不足した状態だったのか　

それに依存する事でコードが壊れることを防ぐ為。

contractsを使うことでrunとisEmptyOrNullは便利になるし、独自に関数で定義できるようになる為便利ー。

- immutable collection

ImmutableListにPersistentListというキャストに便利な仲間が加わるよ。

オリジナルのリストデータ構造の一部を共有している。 なんとaddができる。ハッピー。

val list = persistentListOf(1, 2, 3)
val newList = list.builder().apply {
  add(4)
  add(5)
}.build()
println(newList) // [1, 2, 3, 4, 5]

- flow(experimental)

ReactiveStreamを基礎としたsuspend?

flow { emit(value) } 
  .map{}
  .filter{}
  .catch{}
  .collect{}

RxJavaとの統合

flow.asPublisher()
publisher.asFlow()

suspendのメカニズムによってBackpressureが起こります。

->余談 : BackPressureとは

https://github.com/Kotlin/kotlinx.coroutines/blob/master/reactive/coroutines-guide-reactive.md

https://qiita.com/pljp/items/f748125934fd3f880565 （上記の日本語訳）

同じ処理を追随させて別のスレッドで行わせる事ができる。メインスレッド側の最後の処理が終了した後、別スレッドの処理も完了する挙動をする。

Flowableとは

データの流れを消費する事ができる、ファクトリーメソッドとReactive Streams Patternを実装している。 PublisherとReactive StreamsはFlowableの継承をしていて、別のReactive Streamの操作とPublisherを直接的に受付けている。

- multi platform project(expect actual)

expect fun Char.isUpperCase(): Boolean
public actual fun Char.isUpperCase(): Boolean

ビジネスロジックを共有できる プラットフォーム依存のUIを保てる （共有部分は異なるかもしれない）

expectは共通部分に宣言する事ができる。 異なるプラットフォームにはactualが宣言できる。

共通部分については標準的なライブラリで使う事ができる。

標準的なもの、KtorHTTP client、serialization、couroutinesなどなど… すでに本番環境で動いている事例もあります。

マルチプラットフォームにモダンなアプローチをしています。

このように、共有したい部分を調整できます。

引用:

qiita.com

現場で役立つシステム設計の原則を読み終えたのでまとめていく

最近は無職期間を活用しながら普通二輪の教習に通っていたろんです。

開発に関してはサボりつつも、重要そうなエッセンスを取り入れる為には良いタイミングだと思い、ゆっくり掲題の本を読んでいました。

こちらは次の職場の先輩に勧められた本で、オブジェクト指向+ドメイン設計でのアプローチになるので読むといいと勧められました。

前職で同僚が読んでいたこともあり、前置きは少し読んでいたのですが

リーダブルコードを貸した後に、こちらの方が良いと思って読んでいると聞き、「ちょっとそういう主旨で読まないで欲しいんだけど…」と複雑な思いを抱えながらの出会いだった記憶があります。ちなみにその同僚にはやんわりとこれはリーダブルコードの代用ではないと伝えておきました。

結論から言うと、設計思想についての取っ掛かりとして良本だと思えました。

自分がいいと思ったポイントは下記で、

・ドメイン設計の具体的な思考法

・画面とドメインロジックの分離について

・Web-APIの設計方法

などです。

業務についての理解が浅いことで、アプリケーションの整合性に支障をきたすという部分が実務において心当たりがあり、反省しました。

自分の話になりますが、 前述した同僚の彼は仕様把握に意欲を燃やしていて、カスタマーチームとの連携も積極的に話を聞きにいくなどしていた面が特に素晴らしいと思い、様子を見ていました。

彼はスクラムマスターを兼任していて、働きの結果として開発チームのタスクの量がかなり膨れてきた事が目につきましたが、これは潜在的に元からあった問題を表明する事が出来たので良い傾向だと感じました。

問題なのは優先順位で、つい「開発として実装が楽なのでこちらを先に実装してしまおう…」という意識で楽なタスクに手を出しがちなのですが、それで達成感はお手軽に味わえても、後々を考えたら「これってまとめて実装した方がよかったのよね…」とごちゃごちゃしたUIを目の当たりにして後悔する事になります。

これは、本の中でも述べられている設計の失敗だと思っていて、最初から情報量が多くなる事が想定されていれば、DBについては詳細情報として分離し、アプリケーション側としてはオブジェクト単位での実装を実現する事で仕様を把握する側、アプリケーションを実際に使用する側としてもわかりやすいものになったと思います。

ただ個人的にはこの思い切りの良さをどうやって推進するかが懸念点で、よく必要のないものは実装しない(YAGNI)と言われているように、 オペレーション / ユーザーが何をしていて、将来どういうことをしていくのかもわからないままにアプリケーションの設計の話をしていくのは難しいと考えます。 そこで文頭に戻り、やっぱりこのアプリケーションはどのように人の役に立つかを考える必要が出てきます。

これは今後の自分の課題で、

タスクの要件を満たす実装ではなく、本質的・根本的に考えて、ユーザーが欲しいものは何か

を知る / 思考する必要があります。ユーザーがアプリを使う背景についての解釈が曖昧だった為に、実装の条件を考える上で時間を使ってしまった事に気づいて、すぐに対処できなかったのが悔やまれます。

ちなみに、この本の対象者は、オブジェクト指向についてなんとなく理解はできたが、 そのアウトプットの仕方に迷っている人で、正直Rails（もしくはSTIなORマッパーを採用しているフレームワーク）から入ってきた人・開発してる人（初心者）にはそんなに意味を為さないと思っています…。（この書籍の内容を実現するとSTIで表現するには難しい部分があるんでは…と感じます。） そんな方々は技術書展とかで見かけるRailsの設計パターン系の話を読む方が臨場感あって（いろんな意味で）面白いと思うよ。。

また、引用元の本も記載されているのでこれから知見を広めていきたいという人にもおすすめです。

久々にブログを書いたので色々と辛い… 来週から社会性を取り戻しに新職場で頑張りたいと思います。