【Kotlin Developers Meetup】に行ってきました

Kotlin Developers Meetup

https://kotlin.connpass.com/event/90679/

に行ってきたので、そのときのレポート

Creating DSLs in Kotlin

JetBrains社のHadi Hariri氏にKotlinについて講演してもらいました。

ただ、英語での講演だったので、全然聞き取れませんでした。。。


LT

LT1: FSM DSL in Kotlin

資料

https://speakerdeck.com/tomoya0x00/fsm-dsl-in-kotlin

Kotlinでtree探索をしようとした話。

私が不慣れなのと、内容の難易度が高くてついて行けませんでした。。。


LT2: Readable Code in Kotlin

資料

https://speakerdeck.com/kaonash/readable-code-in-kotlin

以下、LTを聴きながらのメモ

 

リーダブルコードの中で

「コードは理解しやすくなければならない」と書かれている。

 

理解しやすいコードは

簡潔なコードというわけではない。

短いコードは一見かっこいいかもしれないが、

理解がしずらい点もある。

 

どうやれば理解しやすいコードがかけるか?

1.  nullableのハンドリング

できるだけ早くスマートキャストをしてあげて、

nullなのかそうでないのかという状態を明示するようにする。

2. 型推論にあまりたよりすぎない。

型推論は便利。

ただ、あまり頼りすぎると、

この変数の型はなんなんだと分からなくなってしまう。

 

変数の型を確かめるために、コードをたくさん追わないと行けない。

だから、型推論できる場所でも型を書くようにしましょう。

ではどんなときに型を書くのか?

変数名で型を推測できるときは書かなくてもよいが、

そうでないときは書いたほうがいい。

 

また、letについてみんながどう思っているのかを知りたい。

letはわかりにくいので

runmapというネーミングに変えてあげたほうが

英語が苦手な見としては、わかりやすい。


LT3: multiplatform kotlin?

資料

https://speakerdeck.com/panini/kotlin-multiplatform

以下、LTを聴きながらのメモ

 

登壇者のPaniniさんはKotlinエンジニアなのだが

React Nativeも最近書いている。

React Nativeの良い点としては、

ファイルをセーブしたら、そのまま実行してくれるので便利。

 

ただ、jsよりもkotlin書きたい。。。。

そんなときに

Kotlin.js

という、kotlinをjsに変換してくれる神と出会った。

 

Kotlin を React Nativeで書くためには、

一行、ライブラリをimportする文を書くだけでできる。便利。

 

Hot Reload

jsはコンパイルされないから、すぐに実行できる。

Kotlinでもできないのかな?と思って調べたら、

gradle continuous build

という神の機能がある。

これを使ったら、ファイルの変化を検知してHot Reloadしてくれる。

コンパイルを挟むので少し時間がかかるけど、早いので良い。


LT4:spring fu on graalVM

以下、LTを聴きながらのメモ

 

登壇者の型は、Kotlin イン アクションとか、あかべこ本を書いた方。

graalVM

というのがある。

jvm言語はもちろん、それ以外の言語もこれの上で走る。

AOT compile

Javaや通常、実行時にバイトコードがマシンコードになるが、

これを使うことで、直接バイナリを得ることができる。

ただ、これはlinuxでしか動かない。

なので、macの上で docker  とか使って動かそう。

spring boot も動かせるよ!

ただ、jarファイルを食わせたら、エラーになってしまう。。。

ここで登場するのが

Spring Fu

kotlinでかけるよ!

これをgradlewで動かすと、もちろん動く。

そして、、、jarファイルを食わせると、、、同じようなエラーになってしまう。。。

告知!

kotolin fes 2018やるよ!

品川でやるよ!みんなきてね!


LT5: create minicraft mod with kotlin

以下、 LTを聴きながらのメモ

(英語でのLTだったので、メモが間違っている部分があるかもです。。)

 

登壇者の方は、Y.A.M の 雑記帳を書いている人。(いつもお世話になってます!!)

mine craft をやっているよ。

登壇者の方の息子さんもmine craftをやっているよ。私のPCでね!笑

mine craft modというものがあるよ

modというのは

オブジェクトのようなもので、

ブロックを追加したり、人のステータスを変更できたりするよ

forgeというもので、modカスタマイズできるよ。

modはInteljとgradleで作れるよ!

そしてjavaを使うんだけど、

今回kotlinでやってみたよ!

今回のゴールは私の息子がmodを作ることだ

ただ、

・子供がタイピングしたりエラーを解消したりいろんなファイルを触ったりするのはとても難しい

・重要なのは、早く、遊びながら作れること

結果として

modは子供がプログラミングに興味を持つのにいいきっかけになった。

そして、早くmodを作ることにも成功した!


Q & A

Hadi Hariri氏に直接質問をできるQ & Aが用意されました。

ただ、質問と回答が英語だったので聞き取れず。。。

英語勉強しよう。

【UIT#3 The “Backends for Frontends” sharing】に行ってきました

UIT#3 The “Backends for Frontends” sharing

https://uit.connpass.com/event/88434/

に行ってきたので、そのときのレポート

「マイクロサービスの思想から捉える、Backends for Frontendsとその類似パターン」 qsona (株式会社FiNC)

資料

以下、講演を聴きながらのメモ

BFFとは」「その位置付けと目的」

backend for frontendという言葉は少し混乱がある。

server for frontendという言葉のほうが実態に近いように思う。

複数のAPIを合成したりする位置付け

UI側でのABテストなどをする

BFFとマイクロサービスの関係性

マイクロサービスとは、協調して動作する、小規模な自律型のサービス

FINCアプリの場合は、各プロダクトが様々な機能を内包している。

機能の11個、それが単体でも事業になりそうなものが

FINCアプリの中にある。

それらを別々のマイクロサービスとして扱っている。

 

様々なクライアントと様々なサーバーがある。

それらを直接組み合わせると、

APIのコール数が増えるなどの問題がある。

 

その解決策として、中間に1つサーバーを挟む。

それを API Gateway として扱っている。

 

このAPI Gateway には独自のロジックは持たせたくない。

ロジックを持つと、マイクロサービスの旨味が減ってしまう。

注意点

バックエンドロジックをAPI Gateway にもりもりしてしまうと

辛くなる。

宣伝

Microservices architectureよろず本というのを書いたので、読んでね!

類似パターン

クライアントとBFF層のやりとりはgRPCにして

BFF層kotlinで書く。

iOS と Android は基本的に同じ構成をしている。

画面遷移など。

デザインによる違いなどの吸収はクライアント側で行う。

gRPCにした理由は

RPCにしたかったから。

レストフルは避けたい。

クライアントの要求に答える形なので、RPCとしたかった。

Kotlinの理由

既にいる Kotlin エンジニアのコストが減る。

並列処理として go や node.js を使おうかという考えもあったが、

コルーチンでギリギリ行けそうなので Kotlin



「FOLIOのBFFと秩序の話」 Quramy (株式会社FOLIO)

以下、講演を聴きながらのメモ

「FOLIOのBFFと秩序の話」 Quramy (株式会社FOLIO)

今日話すこと

FOLIO の BFF の自慢話

こんな失敗したのでみんなしないでねという話。

イントロ:サービス紹介、システム構成

MobileAPP と Web で大きく BFF を分けている。

モバイルアプリの iOS とAndroid へ提供している API は同じもので

デザインによる違いはクライアントで吸収させている。

BFF のお仕事

下流サービスの集約

Web の BFF は SSR(サーバサイドレンダリング)も行なっている

Aパート:良い話(うまくいった自慢話)

まずアーキテクチャはどんなのを採用しているか?

クリーンアーキテクチャ風

なぜこんな風にしているか?

BFF はクライアントやマイクロサービスに挟まれているので

クリーンアーキテクチャが親和性が高いと思ったから。

主な目的は型付け。

Json でやりとりをしていて、 Node.js を採用しているので、

型をつけたかった。

リクエストやレスポンス整形で誤っていればコンパイルエラーになるようにしている。

BFF の思想を決めておく

やるべきこと、やらないことを決めておく。

日付の計算やパースフォーマット、数値項目の加算原産など

チームでこれらのことに合意をとって進めて行くと良い。

Bパート:辛かった話(失敗した話)

Web の BFF と Mobile の BFF は作られた時期が全然違う。

Webのほうが古くて、それでつらかった部分を考慮して Mobile が作られている。

悲劇の紹介

ユーザーがみるダッシュボード的な画面。

ログインした次の画面、マイページ的な。

これが辛い。

薄いコントローラと巨大なロジック層によって

巨大な Json を返す。

React を採用しているので、クライアントで Json を処理する。

辛い部分として、

巨大なロジック層の部分が 1800 行とかある。

また、型も Any にしている。

型がついてないし、巨大なので触りたくない状態。

だが、旧来のMVCの形をしているので、ある意味わかりやすい部分はある。

直近の対処

改修をする際には、なるべく型付けを少しづつしていってリファクタリングをしている。

もう少し先の対応としては、

React コンポーネントが必要な Json を取りに行くという

画面側が必要な部分だけ取りに行く。next.jsのような思想を目指している。

おさらい

秩序をもたらすためには、

  • レイヤを意識しよう
  • ユースケースを意識しよう
  • スキーマ + 型を使おう


「merpay Frontend における BFF」 @1000ch (株式会社メルペイ)

資料

https://docs.google.com/presentation/d/1RY2qCIypDBju2LfVhBfBnBaaVN_SFM_KAz7-WVucl90/edit#slide=id.p

以下、講演を聴きながらのレポート

 

BFF のことを調べていたら

「使う側にとって、良い設計になっているバックエンド」

という文献に当たった。

最初は、API をまとめるための API サーバーという認識だったが、

複数の API サーバーにリクエストして、htmlを生成するサーバーも BFF と呼ぶ。

と、古川さん(Node.js会長の)が言っていた。

backend for frontendsという言葉なので、捉え方によってはなんとでもなりそう。

広義の意味では SSR Server を BFF と行ったり、

API をまとめる APIサーバーを backend for BFF という捉え方もできる。

node.js が API をまとめるようにしたくなかった。

isomorphoic app を動かすようにしたかった。

フロントエンドの人が js を触っているので、

その人たちもメンテナンスができる。

backend for bff がやっていること

API Gatewayとして動作させている。

httpリクエストを gRPC に変化して横流しする。

将来的にはアグリゲーションさせるかもしれない。



「なぜBFFを導入しなかったのか」 Kento Moriwaki (Wantedly, inc)

資料

Bffを導入しなかった理由(僕らにはまだ早かった)

以下、講演を聴きながらのメモ

システム構成

railsの一枚岩だけど Micro Service 化を進めている。

バックエンドとフロントエンドの責務を分けて行きたいと思って、

BFF の登場だ!ということを考えた。

課題

グローバルヘッダーやフッターは全ページ共通

ただ、SSR 化したかったのは、ヘッダーやフッターを除いて中のコンテンツを SSR したかった。

共通パーツ問題を解決するために考えたこと

  1. reactバージョンを作る?
    rails jqueryで2重管理になってしまう
  2. 全部react実装に統一する?
    Angularもいれていたので、Angular と React を2重管理させるのはカオスになりそうだった。

課題:インフラの問題

どうやってデプロイするか?

切り替わりの間で何か障害が起こったときのインパクトがでかすぎる。

また、画面を少しづつ移行させたいという要望もあった。

 

これらの課題を解決するに至らず、BFF は挫折した。

今後は

これらの要件を満たしつつ、最小限の工数で。

BFF は目的じゃなくて手段の一つ。

もともと作っていた Restful API でやってきたこと

model を json に変換するところを共通化していた。

複雑な処理もあるが、小さい Service 単位に切り出していた。

これらのことのように、Controller を薄くしておいたおかげで

さまざまな部分を共通化できた。

今後もし BFF に対応したかったら、

  • 対応する API を叩くように書き換えるだけ
  • BFF で直接 Render することも可能。

まとめ

SSR したいだけなら、BFF は必須じゃない

ただ、BFF のメリットはすごくあるので

1つ1つ疎結合にしていって、一歩ずつやっていこうと思う。



「LINEとBFFの話」 Jun (LINE株式会社)

資料

以下講演を聴きながらのメモ

LINEは、

  • サーバの人が多い
  • サーバは Java, Perl
  • サーバーサイドテンプレート
  • SPA でもindex.htmlはサーバーに置いてある

BFF というものは

フロントエンドとか技術だけの話だけではないと思う。

BFF の導入は慣れているプロセスを破壊するものなのか?

破壊は改善です!というのも、エンジニア以外から「本当に?」と思われてしまう。

BFF というのは、組織と責任が伴う。

 

BFF がなかったら、テンプレートがサーバーにあるため、責任が不明確。

例えば、画面の問題があって、テンプレートはサーバーにあるため

サーバーのエンジニアが見る

からの、「これはテンプレートの問題ですね」

となって、フロントエンドエンジニアが対応する

これは非効率

 

また、「これくらいのテンプレートならサーバーサイドエンジニアでも直せるや」

と思って直すと、フロントエンドエンジニアの人の知らないところで変更が入ってしまってつらい。

BFF があると

問題の切り分けが効率がよい。

サーバーサイドエンジニアはデータを触るだけ

フロントエンドエンジニアの人も、渡ってきたデータを触るのに集中できる。

何か BFF で問題が発生した場合は

インフラの人と責任分担して解決しよう。

SEO/OGP/i18n

のことは、最初から考慮して設計しよう

あとからの対応はほぼ無理になる。

performanceに関わること

BFF を導入しても遅くない。

むしろ早い。

node.js の速さもある。

内部ネットワークでの data fetch をすると rtt 1桁くらいになる。

「BFF しましょうとなったときに気をつけたいこと」

結果的にいいもの作って証明しないといけない。

開発環境を慎重に選びましょう

責任をちゃんと話し合いましょう

計測できるようにしましょう。

 → 数字がないと、何がよくなったのか証明できない。

結論

BFF はいいものだが、それだけじゃ進まないときもある

他の組織と話合おう

責任を分け合って、一部だけがつらくならないようにしよう。

結果的に良いものを作って、みんな幸せになろう。



「BFFアンチパターン」 @yosuke_furukawa

資料

バックエンドとフロントエンドを分けること自体がアンチパターンだという文献もある

そこで書かれていることが、

「どちらにも詳しいという人がいなくなってしまうし、責任の所在が不明確になったりもする。」

 

古川さんが BFF アンチパターンを書いていたときに

だんだん組織アンチパターンになってしまった。

 

BFF はフロントエンドとバックエンドの架け橋。

アンチパターンその1:スパースコミュニケーションのアンチパターン

BFF はアーキテクチャを疎結合にするが、

コミュニケーションまで疎結合になってしまうパターン。

n+1 queryのパターン

マイクロサービスだからといって

API を簡素にしていい訳ではない。

これらのことは、コミュニケーションをとらなかったから起こったこと。

アーキテクチャは疎であったとしても

対等な存在であり、コミュニケーションは密に行おう。

アンチパターンその2:インフラレスポンシビリティ

フロントのために BFF を導入したのに

何か BFF で問題があったとき、その責任をバックエンドに押し付けてしまうという問題

BFF は全員でみるべきものであるので、みんな当事者意識をもつようにしよう。

アンチパターンその3:ビックバンジョイント

フロントとバックエンドを別々で開発しており、

お互いに開発が完了した段階で結合テストをしましょうという段階で

確実に想定外のレスポンスが存在する。

なので、最後の最後で結合してあとは結合テストということができない。

なので、結合テストの部分はスケジュールを長く持たせないといけない。

古川さんたちがやっていることとして、

開発中にモックで作っているものを、

お互いの開発が部分的に終わったら、終わった部分から少しずつ本物にしていくということ。

【サポーターズCoLab勉強会】新規事業開発におけるエンジニアの心得に行ってきました

【サポーターズCoLab勉強会】新規事業開発におけるエンジニアの心得

https://supporterzcolab.com/event/410/

に行ってきたので、そのときのレポート

対象者

  • 現在新規事業の立ち上げに携わっている方
  • これから新規事業にたずさわるかもしれない方
  • (もしくはたずさわりたいと思っている方)
  • ライブラリを書くより、プロダクト開発が好きな方

話すこと

  • 作りすぎて失敗したことの事例紹介
  • つくりすぎないために
  • コアバリュー大事

登壇者の方が作ったサービス

pook

https://s.pook.life/lp/

ランサーズは、オンラインクラウドソーシングの会社だが

pookはオフラインでやることに特化したサービス

 → オフィスで肩を揉んでくれたり

 → 栄養士の方が手作りご飯を届けてくれたり

本題

エンジニアの新規事業への関わり方

そもそも新規事業って?

新規事業とは、既存事業から生かして、新しい経済成果を生み出すこと。

対して、起業というのは0から始めること。

どうやって関わって行くの?

求められること

サービスを作ることが求められる。

実際には、プログラムを書くというよりは、問題を解決すること。

失敗1:作りすぎた。

リリース時に作ったのは、

  • APIの数150本
  • ページは80

ガチガチの仕様をその通りに作ってリリースした。

多いと何が悪いか。

多いとリリースが遅くなる

 → 多すぎたということは、無駄なことを作ってしまった。

  → 使われないコードはただのゴミ。

本当にあった怖い話

 nヶ月書けて作った仕組みをすぐに消した。

 顧客が本当に求めていたものと違った。

どうすれば良かったか?

作らなければよかった

 → しかし作って見ないと分からないこともある。

  → 作る前にそもそも考えることがあるはず。

  • 同じような体験ができるサービスを作って模擬する。
  • ユーザーにもっとヒヤリングする
  • プロトタイプで実験してみる。

反省

  • 作らないで実験できないか考えてみる。
  • 試したい仮説をすぐに実装できないか考える

失敗2:技術選定

エンジニアあるある。

最近イケてる○○という技術を使おうぜ!

 → 既存に縛られないので、使いがち

結果

情報が少なくて死ぬ。

社内で知識が多い人の助けも受けられない。

サービスがあたるか当たらないかという問題の前に

サービスが作れるか作れないかという問題が発生する。

反省

  • 枯れた技術を使うべきだった
  • もっと協力しやすい技術を選定すべきだった。
  • できるかどうか分からないは早めに潰す。

失敗3:仕様が変わる。

どうしてそうなった?

  • 作るべきものがあやふやだった
  • 目的を達成するための機能がもりもり
  • 全部マスト

どうすればよかった?

コアバリューを定めて、やらないことを決める。

コアバリューとは?

ミッションやビジョン実現のために、組織が独自にもつ共通の価値観。

これを選定することで、作らないものを決めることができる。

 → コアバリューはなんですか。どうしても欲しい機能はなんですか。と唱える。

  → そうすることで、議論の着地点も見つかる。

反省

コアバリューを決めて、作らないを決める。


まとめ

新規事業開発に置けるエンジニアの心得

  • 一番大事なことは作らないこと
  • また、そのために、コアバリューを決める。
  • エンジニアとして問題を解決することにコミット

とはいえ、経験がないと分からないことが多いので、経験をたくさんしよう。


Q & A

Q1.

コアバリューを決めることでいらないものが見えてくるということだったが

APIの数など具体的にはどの程度減ったりするか?

A1.

Apiの数は80本になったりした。大体全部合わせて半分くらいになった。

Q2.

やっていくなかで一番コストがかかることは?

A2.

新規事業でいうと、人件費が一番コストになる。

技術でいうと、どこにコストがかかるか?

 → 作って捨てればいいので、キレイに作らないことを考えればよかった。

  → 無駄にキレイにつくることを考えてしまった。

   → 結果、使われないキレイな部分ができてしまった。

なので、キレイに作るっていうところにコストがかかる。

Q3.

新規事業をやる上で、予算をどのくらいに抑えろとかあったか?

A3.

最初はなかったが、途中からなんでこんなに時間かかってんだとかあった。

最初はノリで始まったものだが、どうしてこれこんなに時間かかってるの?とか。

新規事業は黒転するまでに時間がかかる。

 → なので、試算を前もってしておいて(エンジニアどのくらい必要です。どのくらいでリリースできます。どのくらいで黒転しますとか)ロードマップ考えておこう。

Q4.

開発するに置いて、「これ使ったよ」みたいなツールとかあるか?

A4.

プロトタイプを作るツールでいうと、InVisionというツールを作っていた。

https://www.invisionapp.com/

InVisionというのは、web上ピピッと操作してプロトタイプを作れるツール。

逆にコンフルエンスを使ったのは失敗だったと思った。

コンフルエンスはバージョン管理ができたり、キレイに書けたりすることができるツール

別にキレイに書く必要はなかったが、キレイにかけるがために、キレイに描こうという空気ができてしまった。

それよりも、ガンガンアウトプットできるようなツールのほうが良かった。

【集まれKotlin好き!Kotlin愛好会 vol1】に行ってきました

【集まれKotlin好き!Kotlin愛好会 vol1】

https://love-kotlin.connpass.com/event/86390/

に行ってきたので、そのときのレポート

談義: NaotoTakehataさん「サーバーサイドKotlinとの邂逅」

以下、談義を聴きながらのメモ

kotlin導入のきっかけ

Kotlin は Android のイメージがまだ強いが、なぜサーバーサイドで使おうと思ったか?

従来、 Java(spring) で開発をしていた。

開発メンバーから新しい言語にチャレンジしたいという要望があった。

リスクと葛藤

  • Java の資産がいっぱいある
  • 作り直す時間
  • 導入後に廃れたらどうしよう
  • Kotlin できる人材が少ない

kotlinのいいところ

Java からの移行がしやすい。

  • Kotlin で Spring の使用が可能
  • 過去に使っていたライブラリの活用も可能
  • 部分的にjavaを残すことも可能
  • コードの変換が可能

Java to Kotlin

Android Studio の機能で、コードの変換が可能

最初から自分で書き直すよりは、コストがかからない。

結果、Java から Kotlinに移行して、その他(ライブラリなど)はそのまま使えている。

構文の形だけkotlinに書き換えるくらいでいける。

Kotinはサーバーサイドでも十分使える

Javaを使って入れば移行コストは比較的低い

Kotlinはモダンで良い言語

宣伝

「てっくぼっと!」というエンジニアブログをやっていて、

そこで Spring と Kotlin の話を書いていたりするので読んでね。


談義: AtsukoFukuiさん「こんな時どう書くの? 逆引きKotlin入門」

資料

今回のゴールは Kotlin 描き始めたい初心者が  Kotlin よさそうって思えるようになることだよ。

以下、談義を聴きながらのメモ

変数

変数の宣言は var ,  val がある

var mutable

val imutable

型推論ができるので、型を書かなくても変数宣言できるよ!

オプショナルが使える。

null を許容する変数には、変数の末尾に をつける

null を意識するようになるので、ぬるぽで落ちることが少なくなるよ!

変数は class に属する必要がない。つまり、第1級オブジェクトとして宣言できる。

定数には const

関数

fun で関数がかける。

デフォルト引数と名前付き引数をサポートしている。

条件式

if文

Kotlin において if は式。文ではない。

つまり、値を返すことができる。

なので、if 文の中に値をそのまま書けば、それが return される。

例えば、

val max = if (a > b) {

  a

} else {

  b

}

のように。

三項演算子はつかえないが、エルビス演算子が使える。

エルビス演算子の名前の由来は「?:」という記号を横からみると

エルビスプレスリーに似ていることから付いた名前だよ!

null チェックは、スコープ関数とオプショナルの組み合わせがよく使われる。

when

if 同様に when も式

whenの後ろの()の値が比較の対象になる。

when(point) {

  in 0..10 -> User.gold

  else -> User.other

}

みたいにかける。

()を省略してもよい。

when {

  point in 0..10 -> User.gold

  score in 10..20 -> User.Silver

}

のように、違う値を比較することもできる。

まとめ

kotlinはかわいい!


談義: Paniniさん「Convert  Java  file to  Kotlin  file ⇧⌘K」

資料

以下、談義を聴きながらのメモ

android studioで、Java file を Kotlin にconvertすることができる

90%くらいはちゃんと動く。

Java で書いたコードは自分で意図は理解しているので

あとはコンバートしてくれれば Kotlin がかける!

 

ただ、Java  で書いたコードを変換してくれているだけなので、微修正は必要。

 

ぬるぽが起こるところは Kotlin でも起こるので

!!が付いていることがある。

その場合は?をつけると、その値が評価されなくなるので良い。

ただ、評価されなくなるのも困るので、

ちゃんと何か値が代入されるよってことで

lateinit 修飾子をつける。

そしたら ? もいらない。

ただ、初期化の段階で入れる予定の初期値をちゃんといれたい。

だが、onCreate 内で初期化している

そんな場合は、lazyを使えば遅延初期化で初期化ができる。


談義: takahiaさん「KotlinでRealmを扱う」

資料

以下、談義を聴きながらのメモ

Realm とは、Android や ios で使われる、簡易的なDB

登壇者の方は毎回、

「トランザクションの管理と CRUD の実装は、なんで面倒くさいんだろう。」

と思っていた。

Spring Boot は

1個のアノテーションでトランザクション管理ができる。

共通の interface で Crud の実装ができる

まとめ

Realm の transaction 管理は inline で定義して共通化する。

Realm の基本的な CRUD は abstract class で定義して共通化する。


談義: miho.sasakiさん「How to KotlinのセッションからKotlinらしい表現を学ぶ」

資料

Google I/O に行ってきて、

Java っぽいコードをどうやって Kotlin にしていくかっていうライブコーディングをやっていて

そのコードの書き出しを自分でもやってみたので、そういう発表。

「AKIBA.AWS #6 ネットワーク x 基礎編 – VPNとDirectConnect -」に行ってきました

AKIBA.AWS #6 ネットワーク x 基礎編 – VPNDirectConnect –

https://classmethod.connpass.com/event/84401/

に行ってきたので、そのときのレポート

1. 日本でAWS Direct Connectを利用する話

資料

 

以下、講演を聞きながらのメモ

想定する聴講者

ネットワークはあまり詳しくないけど、AWSを使ってみたいIT技術者

ネットワークセキュリティとその設計

Direct Connectはオンプレとクラウドを繋げるサービス

 

インターネットは怖いのでセキュリティをしなければいけない。

コンピュータセキュリティは大きく分けて2種類ある

エンドポイントセキュリティ

 → ウィルス対策ソフトを入れたり

ゾーンセキュリティ

 → 企業などが、自分の管理下のネットワークを置いて、そこで管理すること。
プライベートなネットワークのこと。

 → 組織内の人のみアクセスできるプライベートネットワーク。専用の箱を作って管理。

 → 誰でもアクセスできるパブリックネットワークとの境界を
しっかり分けて管理しましょうということ。

 → 会社の場合だと、ルータがその境界になっていたりする。

家庭のネットワークと企業のネットワークの違い

会社のネットワークは、システムの用途などでプライベートネットワークが別れている。

オフィスのLANとデータセンターで別ネットワーク。

それぞれのプライベートネットワークをどう繋ごうかと考えたりする。

拠点間プライベートネットワーク

方法としては大きく2種類ある

インターネットVPN

安価でベストエフォート

パブリックなインターネットを経由して行うが、組織内の通信を暗号化することにより実現。

インターネットを経由して行なっているので、使い勝手も特に差異はない。

IP-VPN

高価・高セキュリティで帯域保証つき

インターネットベンダーの設備を経由して、閉じた通信網のなかで行う通信。

 → 昔は、ビルとビルの間に線をつないで、、、とかやってる時代もあった。

 → いまは、ネットワークベンダーの設備を使ってやったりしている。

 

Ethernetであれば、ネットワーク通信自体の要件に違いはない。

セキュリティレベルや品質で選択する。

クラウドのネットワーク設計

いわゆる、VPCの話。AWSVPCはどういうつくりなのか?

VPCとは

AWSで使えるネットワーク機能

ざっくりいうと、AWSで使えるネットワーク機能が詰まったもの。

 

VPCの便利なところというのが、

パブリッククライドとしては、東京リージョンということで共通で使うのだが、

ユーザごとにネットワークを切って使うことができる。

 

それぞれのVPCは独立していて、閉じた仮装プライベートネットワーク。

やろうと思えば、VPC同士の接続(ピア接続)もできる。

 

本番と開発のネットワークを分けたいというような形で使われることが多い。

本番のネットワークのセキュリティレベルはあげたいが、

開発用はポコポコサーバーを建てたい、など。

 

VPCとプライベートネットワーク(社内の環境)との相互接続を実現するために

AWSが提供しているDirect Connectというのがある。

 

VPCとプライベートネットワークを繋げる手段は3

  • VPCのインターネットVPN機能
  • EC2でインターネットVPNソフトウェアを実行
  • AWS Direct Connect (今回のメイン

Direct Connectの特徴

  • 高品質
  • 高セキュリティ

サービスとしてのSLAは未定義なため、

現状は、月のアクセスがどのくらいまで保証、というのが明示されていない。

AWSによるサービスのメンテ頻度など実績で比較する。

Direct Connectはメンテ頻度が少ないので、安定しているなど。

対して、インターネットVPNというのが、構築も簡単で手軽である。

AWS Direct Connect

日本で使えるところ。

  1. エクイニックス ty2(東京 東品川)
  2. アット東京 cc1(東京 新豊洲)
  3. エクイニックス os1(大阪 四つ橋)

AWSのリージョン(東京・大阪)とは別

コラム

Direct Connectがある場所に、日本のAZがあるの?という質問がよくある。

真実はわからないが、違うというアナウンスがされている。

Direct Connectの使い方

Direct Connectが提供してくれるのは全てではなく、

VPCから、先ほどの3箇所(エクイニックスty2、アット東京cc1、エクイニックスos1

までの通信が用意される。

 

その3箇所のところにLANの差込口があるので、そこまでは繋ぐよ。

そこから自社のネットワークまでは、自分で用意してね。っていうようになっている。

自社のネットワークまでの繋ぎ方は2種類ある

占有プラン

3つのいずれかのデータセンターと通信を自前で行なって

IP-VPN接続などをする。

自社内のプライベートネットワークの中に

3つのうちのデータセンターへの口を用意する。

メリット

ユーザが自分でいろいろ設定するので、制約は少ないというメリットがある。

 → たとえば、複数のネットワークベンダーからデータセンターに繋ぐということもできるし、

   いくつものVPCを繋げるということもできる。

デメリット

価格が高いこと

共用プラン

ネットワーク事業者が、3つのうちのデータセンターとクラウドとの接続をやっているので、

自社内からそのクラウドに対して、IP-VPN接続を行う。

メリット

占有プランと比べて、データセンターとのやりとりコストや予算などが抑えられること。

デメリット

制約が多いことと、接続できるVPC数が1つだけであること。

まとめると

  • 共用プラン:比較的手軽
  • 占有プラン:本格利用

とっかかりはどうするか?

Direct Connnectを使いたいとなったら、既存のネットワーク事業者の営業さんに相談をする。

 → 中には、Direct Connectの経験があるネットワークベンダーもある。

 → AというネットワークはIP-VPN接続でやって、
   Bというネットワークはネットワークベンダーにお願いして、というようなやりかたもある。

技術的な不明点があれば、質問したり、AWS専用線アクセス体験ラボの活用がおすすめ

おまけ

  • Direct Connect応用機能
    → 占有プランでないと使えなかったりする。
  • パブリック接続
  • Direct Connect Gateway
  • Lag

まとめ

  • Direct connectはプライベトネットワークとVPCを高品質セキュアにつなぐサービス
  • 占有プランと共有プランがある
  • 質問があればネットワークベンダーに質問してみよう。

Q & A

Q1.

メンテナンスの頻度はよくある?

A1.

Direct Connectの推奨としては、冗長構成となっているので

片方がメンテナンスになってしまっても、

もう片方が残っていればいいというような状況にしておくのがよい。



2. AWS 専用線アクセス体験ラボトレーニング参加レポート

登壇者の方(濱田さん)から。

今回の講演で、面白かったポイントを伝えたりしようと思う。

また、これを聞いた人が参加したいなと思ってもらえたらよいかなと思う。

資料

 

以下、講演を聞きながらのメモ

イントロ

濱田さんが日頃の業務をしているときに

AWSとオンプレとの接続はマスト要件」という案件がある。

そういう場合は、

Configファイルを渡して、つながったら、よしやった!と思う。

ただ、当時のイメージとしては、

お客さん側の得体のしれない機材や得体の知らないネットワークが

どのように稼働しているのかイメージがつかなかったため、

体験ラボハンズオンに参加した。

 

結論からいうと、バックエンドやVPNとかよくわからないという方にとっては

とても学びがあって楽しい。

体験ラボとは?

学べる。

ルータを使った接続の体験とかができる。

会社でネットワークの運用とかをやっている人におすすめ。

 

トレーニングは2種類あって、

ハンズオントレーニングの方をやってきた。

(もう片方は座学なのかもしれない、、、たぶん。)

 

料金が無料!!!!!!!!

 

ハンズオン会場は、AWSのビルの素敵なところで行なう。

注意:ボルダリングするところがあるが、そこの写真とると怒られる。

 

行くときは、PCAWSアカウントを用意しておく。

 

講師は、AWSの菊池さんという人。ガチガチのスペシャリストの人。

とても丁寧に教えてもらえる。

 

ハンズオン形式でテキストを進めて行く形。

 

講演の中で説明されるが、

あるWEBサイトにAWSアカウトを登録すると

自分のAWSアカウントのDirect Connect のところに

Virtual Interfaceが自動で作られる。すごい。

 

ハンズオンの中では、VGWの作成などが

こうやればできますよってテキストに書いてあって、それをやる。

 

ある程度最初に、どんなことをやるのかイメージして

ハンズオンで進めていくことで理解が深まるのでよい。

よかったこと

  • Direct Connectの設定の流れを一気通貫で学ぶことができる。
  • ルーターコマンドを体験できる。
  • 講師にマニアックな質問ができる。
    → 参加人数がそれほど多くないので、
    ネットワークスペシャリストにVPNや専用線の質問ができる!
  • テストラボトレーニングの資料がもらえる。

まとめ

これまで霧のようなイメージだったお客さん側の環境が理解できるようになった!

また、無料だし3時間くらいだし、失うものは何もないので参加すると良い!

AWS 専用線体験」で検索!

Q & A

Q1.

無料ということだったが

ハンズオン内で行うAWS料金も無料?

A1.

そこはさすがに自分持ちです。

ただ、ハンズオン内でかかる費用は50円くらい。

しかも、ハンズオンの資料がもらえるので、それを見ながら1週間くらい遊んだりはできる。

1週間くらいはハンズオン用のデモの環境を残しておいてくれるので)



3. VPN接続とルーティングの基礎

まず始めに、登壇者の菊池さんから

今回はだいぶテクニカルな内容になります。と説明があった。

菊池さんは、AWS認定を8冠しているすごい方。

資料

 

以下、講演を聞きながらのメモ

1. AWSVPN接続

いわゆる、インターネットVPN

 → インターネット上の通信でパケットをカプセル化することで仮想敵なトンネルを形成

 

実現方法によって2つの分類がある。

  • ハードウェアVPN
  • ソフトウェアVPN

ハードウェアVPN

接続に必要な部分が、AWSのサービスとして提供されている。

ソフトウェアVPN

EC2の中にソフトウェアをインストールして、そこを通してVPN接続すること。

 

この2つを比べて一番違う部分が、

ソフトウェアVPNの場合は、

VPN接続の部分を、ユーザが自分たちで保守・運用しないといけない
例えばEC2インスタンス建てたりソフトウェアをインストールしたりとかということ

今回のテーマはハードウェアVPN

ハードウェアVPN = マネージドVPN

拠点間を繋ぐIPSecVPN

2. ハードウェアVPN

出てくるコンポーネントは3

  • customer gateway
    → オンプレ側に設置するルータ
    public ipを必要とする。
  • virtual private gateway
    VPCにアタッチするゲートウェイ
  • VPNトンネル
    → CGWとVPGを繋ぐ

 

AWS上での設定はとても楽。3ステップ。

 

設定ファイルが最後にDLできる

 

設定ファイルには、

  • IPSecVPNの設定情報
    → IKE/Ipsec/TUNNEL
  • BGPルーティングの設定(動的ルーティングの場合)

が書かれており、

IKEの事前共有鍵、AWS側の接続先IPなどが書かれている。

 

AWS側では、2箇所でルートが設定されている。

  • VGW
  • VPCのルートテーブル

3. BGPによる経路交換

AWSを使うと、IPSecまでの設計はほとんどいらない。DLするConfigに書かれている。

ネットワークの経験がない人がBGPをやろうとすると、一気にハードルが高くなる。

 

BGPとは?

Border Gateway Protocol

のこと。

動的ルーティングプロトコルの1

 

AS(Autonomous System:自律システム)間で経路情報を交換する。

ASナンバーというのは、大きなネットワークキャリアとかが、他と通信するための番号。

 

TCPで接続したルータ間で経路をアドバタイズ(広報)する

 → パスアトリビュート属性を付加することで経路を制御

  → ISPとかが複数の経路を提示してくれるが、
この属性によって最短の経路が何かを示してくれる。

 

VGWVPNトンネルの間にルータが2つある。

  • CGWで設定したCIDRCGWから受け取るルータ
  • VPNCIDRCGWに送信するルータ

 

BGPでは、パスアトリビュートのパラメータが10以上ある。

AWSでよく使われているのは

  • Local_Prefence
  • AS_PATH
  • Med

ここら辺の話はとてもディープな話になるので、

また次回の勉強会でやろうかな菊池さんがおっしゃってました。

4. 設定時の注意

CGWには実績のある機器を設定しよう

 → 不具合の回避

 → 実績のない機器を検討する場合は事前検証を。

 

AWSが公式に検証をサポートしている機器もある。

そういうものを使えば、まぁ、間違いないでしょう。

その機器の中に、 Cisco とか Juniper とかある。

コラム

ネットワーク屋さんからすると、CGWVGWは同じ機種を使うのがセオリーなので

AWSで使われている、謎の機器を使うときは、サポートされているものを使いましょう。

サンプルコンフィグの注意点

CGWNAT環境にある場合。

クライアントのFireWallの奥にCGWがある場合。

その時は、インターネットからFireWallを超えてCGWにアクセスできるように設定しよう。

サンプルコンフィグを使うと、NATGWIPが記載されているので、そこの書き換えが必要。

繋がらないときのトラブルシューティング

  • Ipsecがダウンしていないか
  • BGPがダウンしていないか
  • ルートテーブルが反映されているか

まとめ

  • ハードウェアVPNはマネージドなIpsecVPN
  • BGPまたはstaticルーティング経路を設定
  • AWSが、設定は簡単

Q & A

Q1

今回話したような内容は、ネットワークベンダーさんがやってくれる?

A1

基本的にやってくれる。

Q2.

経路交換しているときに、

VPC側の経路情報が流れてしまうという話があったがルーティングの設定をすればよいのか?

A2.

そうですね。オンプレの設定だけルーティングするような設定をしないといけない。

Q3.

Direct ConnnectSLAの設定がないという話で、冗長構成が推奨ということだったが、

どういう内容があるか?

A3.

データセンサーから線を2本引くなど。どこまでお金かけるかとか、考え方とかによることになる。

Q4.

AWS側でVPN接続する際にルータが2

CGWCIDRを受け取るものと、VPCCIDRを送るもの)出てくるが、

それが別れているのはなぜか?

A4.

AWS側が冗長化のためにやっている。

メンテナンスの際は、片方がとまるが、片方は生き残ったままというような形になる。

勉強会に行ったら友達作りとアウトプットをしよう

私が勉強会に足を運ぶようになって

よかったな、これからも続けたいなと思うことです。

友達作りをしよう

勉強会に来ていた他の方々と仲良くなりましょう。

初対面の人と仲良くなるのはとてもハードルが高いと僕自身も思いますが

もし仲良くなれたときのメリットがとても大きいので頑張って仲良くなるようにしています。

 

もしそこで、何かしらのコミュニティに参加できるようであれば

積極的に参加するようにしましょう。

ある程度コミュニケーションがとりやすく、学べることが多い

同じ勉強会に来ている時点で、すでに同じことに興味を持っていることが分かっています。

更に、同じことに興味を持っているような人は、自分と同じような状況やスキルセットになっていることが多いです。

 

「最近どんなことやっているんですか?」という会話から、

共通の話題でコミュニケーションをとることが比較的容易だと思います。

 

親密感が出て来たら、自分が悩んでいることや、人の意見を聞きたいような話題を振って見ましょう。

自分と同じような悩みを持っていたり、解決する術をその人は持っているかもしれません。

良いライバル意識が生まれる

似た状況、似たスキルセットの人が多いので、

自分に足りないもの、身に付けないといけないと思っているものを持っている人が多いです。

 

そういった人と自分を比較することで、

「自分ももっと頑張ろう」と思えることができます。

 

会社の同期等でもそれができるかもしれませんが、

私の場合は、会社の同期はやっていることが全然違ってライバル関係になるのが難しかったり

同期という意識から、なかなか自分の弱みを出すのが難しかったりしたので

こういうところで出会える人は本当にありがたいと思います。

気軽に質問ができる

会社だとどうしても立場や印象を気にしてしまって

「こんなことも分からないの?」と思われたら嫌だということがありますが(本当はそういうことを気にしないのが良いですが)

そういうことを気にしなくてもよいので、気軽に質問ができます。

 

また、相手から質問された場合でも

「会社だと間違ったことは言えないし、ちゃんとよく知らないから答えられない」

という気持ちになりがちかもしれませんが、勉強会友達だと

「間違っているかもしれないけど、自分はこういうところまで知っているよ」

ということが言いやすいと思います。

新しい友達ができる

これは当たり前と言えば当たり前ですが、新しい友達ができます。

しかし、ただ友達という訳ではなく

自分と似た状況に苦しんだ経験があったり、共通の話題が生まれやすい存在であることが多いです。

うまくいけば、会社の人には話せないようなことを話せる、大事な存在ができるかもしれません。

一期一会を大事にしていきましょう。

※ただ、勉強会のつながりを利用して変なことを考えている人もいるらしいので、友達選びは気をつけましょう

アウトプットをしよう

得た知識を更に固めることができる

勉強会に参加すること自体、とても良いことだと思います。

ただ、参加してなんとなく頭の片隅に入った、くらいだと勿体無いと思います。

得た知識をアウトプットしようとすることで

記憶に強く残ったり、勉強ではなんとなくしか分からなかった部分も分かるようになったりします。

実はとてもアウトプットしやすい

勉強会で聞いている内容は

ありがたいことに、すでに「誰かが学びやすいように」作られたものです。

 

学んだ内容をそのまままとめるだけでも

それは誰かが学びやすいような形に近いです。

スライドの順番やレイアウト・補足説明など、アウトプットに向けた労力も大分削減されているでしょう。

 

「こんな内容アウトプットしても誰も興味を持たないかもしれない…」なんて思わず、

とりあえず学んだことをまとめただけのものをアウトプットするだけでも十分良いことだと思います。

 

自分で勉強会を開くのも良いですし、

ブログに書くだけだったら特にマイナスはなくてプラスしかないと思います。

自分が興味を持っていることを周囲に知らせられる

勉強会で「こんなことが面白いと思った」「勉強になった」

ということを周りに知らせることは、とても良いことです。

 

例えば会社などでアウトプットをすると、

「この人はこんなことに興味を持っていて勉強会に行って来たんだ」

と思ってもらえるので、運がよければ良い仕事を任せてもらえるかもしれません。

もしくは、社内で同じ興味を持っている人と話ができるかもしれません。

 

また、プライベートな時間を使って勉強しているということを伝えられるので

それだけでも好印象を持ってもらえるかもしれません。

まとめ

勉強会に参加してそこで終わるだけではとても勿体無いので

積極的に友達作りやアウトプットをしていきましょう。

何か良いきっかけができるかもしれません。

気分がのらない・やりたいことが見つからない時の対処法

日頃生活していて、「なんか気分がのらない」「したいことがない」

という状態がありませんか?

 

そういう状態のときは、どうすればいいのか考えても

なかなかアイデアが浮かばないものです。

 

気分がのらないとき

私が行なっている対処法としては、

テンションがあがった状態のときに、今何をしているかをメモしておくことです。

 

そこでメモした内容、例えば「ここのカフェに行くとテンションがあがった」ということを

気分がのらないときにやってみると、気分がのるようになったりします。

 

なんか分からないけど気分がのらないが、どうしたらいいか分からない

という状態のときは、一種の自分が分からなくなっている状態だと思っています。

そんなときにはメモを見て

自分はどんなときに気分がのる人間なんだと、分かることができます。

例えば私の場合は

  • アニメソングを聞く
  • 落ち着いたピアノの音楽を聞く
  • カフェに行く
  • 好きな服装をする
  • プログラミングをする
  • 溜まっていた調べごとを片付ける(前もって、時間ができたときに調べようと思ったことをメモしておく)
  • 家事をしたり、部屋を綺麗にしたりする
  • 運動をして帰ってお風呂に入ってから何かをする

ということをメモしていたりします。

また、実行するときは

疲れてしまわないように適度に休憩を入れながらやるのが良いと思います。

やりたいことがないとき

これも、気分がのらないときと同じでメモをします。

「時間ができたらこれをしよう」「休みの日をつかって○○に行こう」

ということを、やりたいことが思いついたときにメモをしておきます。

 

今特にやりたいと思っていなくても、過去に自分がやりたいと思ったことなので、

腰をあげて実際にやってみると、楽しくてのめり込めることもあります。

ポイントは「やらなければいけないこと」ではなく「やりたいと思ったこと」です。

 

例えば私の場合は

  • ○○の映画を見る、録り溜めたドラマを見る
  • 自転車で長距離を走る
  • 書こうと思っていたブログを書く
  • マッサージを受けに行く
  • 久しぶりに友達に会いに行く
  • アプリ開発をやる

ということをメモしたりしています。

 

どうしても「今回は面倒だから、また次回でいいか」と思ってしまう場合は

期限をつけてメモをしておくことも効果的だと思います。

大切なのは、「どうしても今しなきゃいけない訳じゃないけど、とりあえずやってみるか」という

最初の腰をあげる部分だと思うので

そこさえ頑張って乗り越えてみたら、以外と充実した1日を送れると思います。

電車の遅延情報をslackに投稿するbotをつくりました

githubに公開しています。

使い方は REAME.md に書いてあり、特に難しいことをしなくてもいいのですぐに使えると思います。

github

https://github.com/acchanAlexander/notice-train-delay-to-slack

 

チャットワーク用はこちら

ブログ:電車の遅延情報をチャットワークに投稿するボットをつくりました。

github:https://github.com/acchanAlexander/notice-train-delay-to-chatwork

 

【サポーターズCoLab勉強会】客先常駐エンジニアが戦闘力を上げるN個の方法に行ってきました

【サポーターズCoLab勉強会】客先常駐エンジニアが戦闘力を上げるN個の方法

https://supporterzcolab.com/event/362/

に行ってきたので、そのレポート

※今回の講演は、あくまで登壇者の方の経験や意見です。

そもそも客先常駐って何?

  • 別の企業に出航して働く形態
  • SI系によく見られる
  • 派遣の場合もあるが、そうでない場合もある。

求人について

  • とりあえず未経験でも採用しているところが多い
  • 大手は新卒メインだが、中途は通年採用もしている
  • 前期黒字(設けている)ことを強くアピール
  • 土日はしっかり休めそうな雰囲気
  • 開発案件に携われるということを押している

実際にやる仕事

  • コールセンターだったり
  • SEサポートだったり、
  • ヘルプセンターだったり
  • テスターだったり
  • etc…

メリット

  • 大手企業で仕事をする権利がもらえる可能性がある。
  • 日頃触れないような、古い技術を触ることができる。
  • 給料は悪くないこともある。

デメリット

  • コミュ障にはやさしくない「調整業務」が発生する恐れ
  • 「まずやりたくない仕事」にぶちこまれる恐れ
  • 給料が良いとも限らない
  • 技術的モチベーションの高い人が少数派の恐れ
  • 技術的な向上が望めない場合もある

ぶっちゃけると、研修充実は怪しい

 → 十分な研修ができない可能性

なぜか

  • 教育的ノウハウがない
  • 下請け的なポジションになりがち
  • 保守的になりがち
  • リードするような人がいなかったり
  • モチベーションが低い空気

更にそれはなぜか?

  • そもそも入社する人の特徴が、休みや正社員に惹かれて来る人
  • プライベートな時間の使い方が勉強とかでなかったり
  • 自分が将来どうなりたいかとか、あまり考えてない
  • 安定を求めている
  • 技術に対するモチベーションが低い

客先にエンジニアをぶち込む人(自社の営業の人)の特徴

  • 法人向けの営業脂肪だった
  • 「ベンチャー」という言葉の響きに惹かれた
  • ITに興味がない
  • とりあえず、売り上げやノルマを達成すればいい
  • 数字や単語の組み合わせで仕事をしている
    → 「phpとは、何かサービスを作れるもの」など
    → 経験は何年で、給料はどのくらいで、ということだけを見て人を選んだりする
    → その人がどのようなことが得意か・やりたいかということは見ていない

戦闘力の上げ方

  • とりあえず勉強会に積極的に出てみよう
  • 周りのエンジニアや客先と仲良くなっておこう
  • 開発をやりたいなら自分でサービス作ろう
  • 副業やインターンに手を出してみよう
  • 自社に過度な希望をもつのはやめよう

実践できたら、次のステップ

  • とりあえず勉強会でLTとか登壇する
  • 客先から自分に会う案件を直接紹介してもらう
  • 自分で作ったサービスを人に使ってもらう
  • 異業種交流会とかで小規模な受託案件を探そう

本当の自社との付き合い方

「自社 = 自分の味方」ではないかも?

  • 敵というわけであはないが、少なくとも味方ではない恐れ
  • 敢えていうなら、自社は取引先
  • 基本的には、サポートは期待できない
  • 自社待機の社員は負債という見方も

会社の基本

  • 安く仕入れて高く売る
  • 長期的な教育よりも短期的な利益

どうしたらいいの?

  • 技術の学習はできるだけ自力で
  • 受けの姿勢よりも攻めの姿勢で
  • 副業はどんどんやろう
    → 実は、会社は副業禁止とは言えない。
    ただ、会社に不利益が怒るようなことはやってはいけない。
  • とにかく情報を集めること、集めまくること
    → 結構、常駐先の人からぽろっと聞けたりもする。

担当営業とは仲良くなろう

敢えて言うなら、担当のために働いてあげよう
→ 自分に仕事を持って来てくれる人のために働こう
会社は守ってくれないが、担当は守ってくれるかもしれない。

担当のことが信用できなくなったら終わり

担当もエンジニアが信用できなくなったら終わり

自分の会社のことを理解しよう

絶望する前に、会社に一石投じよう

居続けることもできる。辞めることもできる。

僕らは自由であることを常に頭に置いておこう。

【サポーターズCoLab勉強会】Google公式サポート!Kotlin入門に行ってきました

【サポーターズCoLab勉強会】Google公式サポート!Kotlin入門

https://supporterzcolab.com/event/360/

に行ってきたので、そのレポート

資料

以下、講演を聞きながらのレポート

 

Kotlin入門までの助走読本
https://drive.google.com/file/d/0Bylpznm149-gTGRjOFRkWm9PODg/view

というのを、登壇者の方が去年書いた

 

2012年に最初のKotlinがリリースされた

 

KotlinはJavaScriptへのトランスパイルもできる。Babelとか使って。

 

extension functionsがKotlinがJavaと比較して実装しやすいメリットの一つだ。

 

簡単なコードを実行したかったら
https://try.kotlinlang.org/
で簡単に実行できる。

 

デコンパイル
→ Kotlinで書き出したものを、Javaのソースに変換もできる。

 

Kotlinで書いて、iOS用のコードに変換することもできる。

 

Kotlinのオススメ本

 

型を書かずに変数宣言したりしたら、ビルド時間が遅くなる?

e.g

var str: String = “moji”

ではなく、

var str = “moji”

と書いた場合に、ビルド時間が遅くなる?

 → 特に感じることはない。

 

Null安全なので、スマートキャストができる

 → 逆に、Javaではできなかったらしい。。。

 

エルビス演算子は、右辺にreturnを書き、即 return するような場面が多い。