by shigemk2

当面は技術的なことしか書かない

vivaldi show address bar

vivaldiでURLをコピペすると時々www.shigemk2.com/ みたいな感じでhttpとかhttpsが抜けてしまうことがある。

設定→アドレスバー→「show full address」にチェックを入れると良い。

この設定をすればプロトコルのコピペが出来ない問題は解決するけど、この設定をしないと挙動が不安定になるのがいただけない。 Mac OSX Sierraでも起きるし、Ubuntu 16.10でも起きるし。

f:id:shigemk2:20170321092142p:plain

URL protocol is not copied if location bar gets typed into | Vivaldi Forum

後半 メモ #ichigayageek

ichigayageek.connpass.com

株式会社セプテーニ・オリジナル 下村 様 Scalaの線形化と抽象型メンバの統一の限界

  • 自分型アノテーション
  • value size is not a member of ListA.this.B
  • scalacは線形化のプロセスで抽象型メンバーのプロセスにおいて最後のものが採用される

  • コンパイルが通った

  • 自分型アノテーションで線形化の順番を明示する

  • Dottyではなおった

株式会社リクルートマーケティングパートナーズ 松川 様 DDD on Slick3

  • クリーンアーキテクチャ
  • Slickだと、DBIO型を使う必要がある
  • テスト用のTestRunner
  • UseCase層でトランザクションしたい
  • DBIO型をScalaz.Monadへ

Fringe81株式会社 豊島 様 Scala on GAE

  • GAEを採用していること
  • なんでGAEなのか
  • 既存の事業やりながら新規もやるのでリソース厳しいから、Paas使ってインフラ部分を楽したい
  • Javaのライブラリとかよい
  • 「Scalaでお仕事使われているんですか」
    • GAEで大丈夫なのか
    • GAEで動いているのか
  • GAE Scala
    • スタンダード環境 − Java7
      • jetty
  • Java8じゃない
  • flexible environmentをつかうことでJava8/Dockerを使っている(制約多いけど早い。G社としてはスタンダードを使って欲しい)
  • GAEのフレキシブルは仕様が不安定なのでG社としてはあんまりおすすめしていない
  • 長らくベータ版だったのが、最近GA化した

  • ケーススタディ akka-httpで作ったプロジェクトをデプロイする

    • 東京リージョンなのでレイテンシも良い
    • app.yaml
    • Dockerfile(ファットなjarじゃないといけない)
    • gcloud app deploy
  • Read系はGAE standard(golang シンプルなサーブレット)

  • Write系はGAE flexible(scala きっちり作るぶぶん)

というCQRSを採用する

  • NEWS: Java8がGAEスタンダードでアルファリリース

株式会社オプト 田中 implicit parameterの解決規則

− implicit 便利だけど把握するのが難しい - どこで定義したらimplicit value見つけてきてくれるのか分からない - implicit インスタンスがどこから来たのか

  • メソッドに引数に合う型の値をコンパイラが探してきて代入してくれる

  • ローカル

  • importされたパッケージ
  • トレイト/クラス
  • コンパニオンオブジェクト

  • implicit parameter

  • 型引数のコンパニオンオブジェクトも検索対象
  • scalaz.Orderをユーザー定義型でも使えるようにしたい
  • デフォルトの解決先を指定することが出来る

  • Fuge[Hoge]のインスタンスがどこから来たのか

    • コンパニオンオブジェクトを見る
    • 探索規則を把握している
    • IDEAでCtrl + Shift + Pするといい
    • バグの温床になるのでimplicit conversionは多用しないこと

株式会社マーベリック todesking 様 DatasetでもzipWithIndexしたい

  • Spark
    • 大規模データを分散したマシンで扱うためのフレームワーク
  • 仮想的な配列
    • HDFS上のファイル
    • RDB/Redis
  • データモデル RDD[A]
    • 基本的データ型
  • DataFrame
    • RDDと同様だけども別実装
    • 型安全性が犠牲に
    • SQLによるデータ操作
    • カラムナストレージによりメモリ効率が上がった
    • 型安全性を向上させたDatasetというのもある
  • monotonically_increasing_id()
    • RDD経由
    • Partition Sparkにおけるデータの分割単位 処理はParitionごとに並列に実行される
    • 複数のpartition上で連番を振る
  • DataFrame/DatasetはRDDの上位互換じゃないが、InternalAPIを使えば出来なくもない
  • RDD経由でやったほうがいい

前半 メモ #ichigayageek

株式会社ネクストビート 衣笠 様 オフショアでもScala開発

  • さくらのクラウド
  • C

からのしっかりとした仕組み

  • stage1 ドメインモデル設計
    • ヘキサゴナルアーキテクチャ
    • case classのオブジェクト
    • コンパニオンオブジェクト
  • stage2 モデルとDBのマッピング設計
    • slick
  • stage3 リポジトリの設計
  • stage4 フロントエンド実装

    • リポジトリを叩く
  • リリース

    • Slack
    • ECRに直接コミット
  • 企画書とSlackでのやりとり

  • ドメインの設計は小さいものならベトナムの人にやってもらう
  • 全部ドキュメント化してアサインした人のレベルを引き上げる

ナイル株式会社 的場 様 何故AkkaのActorを使うのか?

  • Appliv
  • Akkaを使って1年ほど開発
  • (これから使うひと向け)

  • インスタンス

    • システムをリアクティブにするためにActorを呼ぶ
  • 即応性/耐障害性/弾力性/メッセージ駆動

    • 早くレスポンスが返ってくるようにすること
    • リアクティブ宣言を読む
  • Actorでないとき

    • メッセージの遅延が全部に行き渡る
  • Actorであるとき

    • 別スレッドで動いている
    • メッセージを送り続ける
  • Actorでないとき

    • エラーが全部に行き渡る
  • Actorであるとき

    • 別スレッドで動いている
    • 次の処理に進む
  • 順次処理するので過負荷を防ぐ

    • メッセージキュー
      • ほぼ同時にメッセージが来ても、キューで制御
      • シングルトンにしておけばデッドロックもない
    • メッセージに基づいた処理を行う
  • 冗長化が楽

    • Akka
    • withRouterメソッドとRoundRobinRouterを使って、冗長化 + ラウンドロビンできる
  • RemoteActor

    • サーバーをまたいで処理をしたいという需要にこたえる
    • 設定ファイルいろいろ書く
  • Actorはメッセージ駆動であること 粗結合であるので遅延/エラーの伝搬を防ぐ/負荷の調節/サーバーをまたいだ処理もできる

  • スライド: preparing for distributed system failure

株式会社VOYAGE GROUP 大谷 様 高スループット・低レイテンシーなWEBサービスにおけるパフォーマンス対策の現実

  • katzchang
  • 増田が好き
  • Survlet on Tomcat
  • Zucks Ad Network

人類の限界

  • マイケル・ジャクソン 1975
    • やるな
    • 上級者向けはまだやるな 最適化がひつような場合はやる必要があるかもね
  • ドナルド・クヌース 1974
    • ただしい問題を解くこと
  • 苦労があるが、パフォーマンス対策に手間をかける必要はないと思う
    • でもパフォーマンス対策は必要
  • New Relic APM
    • JVM Thread Profilling
  • 2014/9/6

    • Map keyとしてTupleをやめてみよう
    • ハッシュコードの計算がTuple2では遅いかも
    • case classにすると早いかも→早くなった
    • こんな感じでいろいろ潰したら10倍くらいのパフォーマンスになったのでだいたいOKになった
  • プラクティス

    • デプロイしてから考える
    • 事前検証はほどほどに
      • 人工的なテストデータは難しいから
      • 機能が動いてお金を稼ぐほうが尊い 機会損失のほうがつらい
      • サービスレベルを若干低く扱う
    • どこが重要かは会社によって違う
      • リクエストのトランザクション
      • 過去データ
      • 広告掲載面
  • 設計判断は経営判断であること
    • デプロイをしたらパフォーマンスが落ちた

株式会社セプテーニ・オリジナル 高嶋 様 IntelliJでScala開発をする上で抑えたいポイント

  • IntelliJ + Scala
  • Scalaプラグインについて用意している機能について知らない人が多い

  • 型がわかる

  • implicit conversion highliting
    • どの型がimplicitされているかわかる
  • scala console
    • sbt consoleをその場で
  • scala worksheet

    • その場で計算して結果を出してくれる
  • scala pluginのマニュアルを読んだほうがいいとおもう