ABC119 D - Lazy Faith
何とか時間中に解けたけどもう少しスマートに早くできるようになりたい、、
二分探索を使うという発想は良かったが、解説にあるような最小値と最大値を挿入するというのを思いつかなかった。リストの中から見つからない、という状況をif文で何とかしていたので全通り試すのを無駄に複雑にしてしまった。また、xからsに行って戻ってきて次にtへ行く、というような計算の仕方をしてしまったのでこれまたif文の嵐になってしまった。x->s->t or x->t->sのような計算の仕方ならシンプルにかけた。
あとは自前の二分探索使ったせいか遅くて苦労した。最終的にはpypyで提出してみたら何とか通った。今までpythonで書いてTLEなったからc++に書き直すということを何度かしてきたので計算量的には大丈夫なはずの時には試してみよう。
本番で書いたコード
JAWS DAYS 2019 に参加した
合計10トラック?で10時から17時までランチセッション含めてずっと何かしら発表がなされていた。 流行りということもあってコンテナ/k8s関連のを中心に聞いてみた。うちの会社で活用できることあるのかなぁ、、
新卒一年目のSREがコンテナをデプロイできるようになるまでの道のり
新卒1年目のSREがコンテナをデプロイできるようになるまでの道のり [JAWS DAYS 2019] - Speaker Deck
何となく聞いたことある〜始めて聞いたくらいのワードがたくさん出てきた。発表聴きながらだとちょっと全容が把握できなかったけど、今資料見たら少しは理解が進んだ気がする。しかしまぁやりたいことに対してやらなきゃいけないことが多すぎないかな、、
RDBリファクタリングと異種間DB移行の戦い – Amazon DMSを使った止めずにリファクタリングする手法
その他資料
JAWS DAYSでデータベースリファクタリングの話をします - そーだいなるらくがき帳
amazon dmsってのも今回知ったけど異なるDB間でレプリケーションもどきをやるってすごいな。そしてauroraはあくまでpostgres互換であって、微妙に違う動作する時もあるから辛いと。
- DBリファクタリングする時にはトリガーが使えると便利
- postgresはトリガーが色々あって使いやすいのでまずはpostgresに移行する
- DMSを使ってデータ移行させていく
- DBアクセスをAPI経由でやるように抽象化してあげて、サービスごとにリファクタ以前/以後を制御してあげて、ちょっとずつ移行
EC2からKubernetesへの移行をセキュリティ/モニタリングから考える
- freeeが扱っている情報はやばいやつが多い。侵入されてデータ取られでもしたら大問題
- 侵入者がどう動くかを想定して対策をしていく
- 多層防御という考え方
- ログを色々なところで取得する。AWSが対応していない部分は自分たちで作る
- 取得したログから必要なものをアラートにあげる。基本はslackで通知
- 予防的な対応へシフトして行きたい
Infrastructure as Codeに疲れたので、僕たちが本来やりたかったことを整理する
- コードに落としていくのはいいことだけどやりすぎよくない
- db立てるのとかそんなに何回もやる? ぽちぽちしたら10分でできるのに、、
- ROI意識していこう
- 組織のフェーズによっても違うはず
みんなのプロコン2019 D - Ears
すぬけ君一体どういう生物、、
まだこのレベルはコンテスト中に解けない気がする。
解法
すぬけ君が行ったり来たりする中で、石が数がどんどん増えていき、一つも石が入っていない耳ももちろんある状態。どれだけ石が入るかは散歩の仕方によるけれど、偶数/奇数に着目すると散歩の仕方の制約から、番号が若い耳から0個ゾーン、偶数ゾーン、奇数ゾーン、偶数ゾーン、0個ゾーンに分かれる。幅が0のゾーンもあることに注意する。
雑な図だけど散歩をsで始めてeで終わった場合の、各耳の石の数を表してみた。
ゾーンの幅はゼロの場合はあるけど右から左に移ることはないので、左から順に番号つけてそれを一種の状態とみなす。そして座標iとゾーンの状態でdpをしていく。
遷移のイメージはこんな感じ。実装する時には右側の矢印の塊みたいなイメージでやるとdpテーブルの長さをL+1にしなくても実装しやすい。
https://atcoder.jp/contests/yahoo-procon2019-qual/submissions/4230647
参考にしたサイト
http://drken1215.hatenablog.com/entry/2019/02/10/014800
https://atcoder.jp/contests/yahoo-procon2019-qual/submissions/4229534
第10回 PostgreSQLアンカンファレンス@東京 に参加した
pl/sqlをpl/pgsqlにした話 を同人誌にした話
資料
https://www.slideshare.net/TakashiMeguro/plsqlplpgsql
oracleもpl/sqlも触ったことなくてpl/pgsqlは少しだけ、という感じだったのでいまいちイメージできない話ではあった。データベースの移行というのは大変なんだな
闇RDBアンチパターン
フラグの闇
- delete_flag が色々ある(1,2,0,9,99,null)。それぞれに意味がある。
- そいつらを組み合わせて状態を作るのであれば最初から状態をもつ方が良い
- 事実に基づいてデータベースを設計していく
論理id
- idの中の桁とかで意味を持たせる。ゼロから始まるidはこういう属性、みたいなやつ。
- パースする必要が出てくる
- 別でカラム持って、とりあえずトリガーかけよう
転んだ後のバックアップ
- 納品時は動いたけどエラーになる日がくる
- mysqlのdumpはエラーになったら標準出力にだす
- 知らないうちにエラーになる
- db2は0を返す
- バックアップをテストする
- 5年前のバックアップは多分リストアできない
- リストアまで考えよう
なんかgithubでもリストアに失敗したみたいな話あった気がする
タイムゾーンの闇
pg2arrowとarrow_fdwに向けて
- pg-stromを作ってる(stormだと思ってた、、)
- ssdからgpuにデータ転送してgpu上でsql実行する
- 今の時代
- IoTとかDBの外でデータが発生している
- 集計解析する為にimportするのが遅い RDSもimportが遅い
- fdwで外のファイルをそのまま扱う
- apache arrowという形式
テーブル更新ログを取得するextensionを作った
- 特定インスタンスへの差分更新を後からまとめて別インスタンスへ適用したい
- ダウンタイム少なく行こうできる
- tablelogというモジュールが昔あった
- すでにメンテされてない
- Cの関数だとDBaaSにはいれられない
- 新しいtablelogモジュール
- pl/v8で書いた
- ログの蓄積方法
- トリガーを仕込む
- 更新情報を別テーブルに貯める
- 好きに加工して突っ込む
- なぜplv8?
postgresをコンパイルする時の話
- pgconf asia 2017の資料
- gccのコンパイルオプションを色々工夫して早くする
- コードを自動生成していると余計なコードが結構発生する
- 使っていない変数の削除
- 関数のインライン化
- 他にも色々最適化のオプションは本当に色々ある
- 数パーセントの高速化になった
- インライン化が重要
- ファイルが別れているとだめな場合があるのでリンク時の最適化をかけるといい
- コンパイラがコンパイル時にcpuのプロファイルをとって最適化かける
- pgoというやつ
- python3で使える。お試しした時に10%くらい早くなった
- pythonの場合は400くらいプロファイルとってる
- コンパイル時間はかなり長くなる
拡張統計とjoinの話
- pg_hint_plan
- 辛い
- 本質的な問題から目を背けている。使わない方がいい
- データが変わった時に追従できない
- 拡張統計情報create statistics
- 関数従属なカラムをfilter(where)に使ってるとプランをうまく作れない
- 統計情報作ってやる
- 結合に対応してないという情報があって試してみた
- だめだった
- 結合方法より前に拡張統計情報が見られていない
詳しい話はこちら kyabatalian.hatenablog.com
postgresqlのいけてるテク7選
- timestampの範囲
- キャンペーンの範囲みたいなの
- start_at is null or start_at<now()
- timestampでinfinityが使える
- coalesce(start_at, '-infinity')<now()
- tstzrange で範囲をそのまま扱える
- 半開区間をそのままかける
- gistも貼れる
- with句で書きやすい
- valuesはtableが入る場所にいくらでもかける
- 定数とか書きやすい
- filter節
- 統計処理
- ltree型
- ツリーのデータ構造を簡単に扱える
- カテゴリ構造に使えそう
postgres11 のパラレルクエリの動作
- 実際に起動されるworkerがパラメータで決定される
- worker数が増えるごとの性能をプロファイルをとった
- 11が途中でさちる
- 統計情報がおかしかった
- 11になるとだいたい半分になった
- pg_class.relpages
- 実際のファイルサイズは正しい
- もともと正確でないと言われているとはいえおかしいn
- 元のテーブルは100G
- 会社だと10G
- 家の3Gテーブルだと再現しない
EM meetup #4 に参加した
engineering-manager-meetup.connpass.com
エンジニアチームビルディングジャーニー
資料
https://www.slideshare.net/yusukehisatsu/ss-130125728
チームを立て直した話
ボロボロのチームを立て直したエンジニアリングマネージャーのお話 - めざせプロダクトマネージャー( @Nunerm )
で書いた話+a
- メンバーの内発的動機がどこにあるのかを把握して、それに応じてインプットの仕方を変える
- 踊り場を作って遊ばせる
- カオスエンジニアリング
という話が参考になった。まずは1on1の中でメンバーがどの欲求が強いのかを意識して探るようにしてみる。 また、今度長期の休暇をとるのでその時に色々任せてみよう。
まだ何も始めてない会社での第一歩
資料
https://www.slideshare.net/KouNakajima/ss-130131061
事業会社がキラキラして見えるというのは本当にその通り。うちも客先常駐はないが基本受託なのでメンバーがよく自社サービスやりたいと言っている。OST風懇親会は評価の方に行ってしまったけど機会があれば受託の人で集まって話をしてみたい。
em_meetup から生まれる！？ Engineering Manager Job description
資料
https://speakerdeck.com/dskst/engineering-manager-job-description
自社のjob descriptionを作ってみたいなと思った。今は本当に基本的な仕事はこの辺、みたいなのことのコンセンサスはなんとなく取れているけどそこから先はメンバーが自由に動いている状況。動いてくれていてそれなり成果が出ているので良いっちゃ良いが、今年度は基本の業務が若干うまくいかなかった感じがあるので、改めて仕事を定義してみてもいいかもしれない。
わかりやすいJD
https://boards.greenhouse.io/renttherunway/jobs/1050628
https://mercari.workable.com/j/F3C8AE1289
1つの大きなプロダクトをみんなで作る
資料
https://speakerdeck.com/tunepolo/develop-1-huge-product-with-multiple-teams
フィーチャーチーム読んでみる
http://featureteamprimer.org/jp/feature_team_primer_ja.pdf
失敗体験から学ぶEM方法論
開発部として良かった/うまくいかなかった取り組み、そして「評価」の難しさ
資料
https://speakerdeck.com/mochizukikotaro/em-meetup-20190201
OST風懇親会でもここで話を聞いた。メンバーの成長の為のフィードバックとしての評価とお給料を決める為の査定を分けて考えるのが自分はしっくりくる。うちの場合はボーナスは360度評価でみんなでお互いに決めるので、そこからの高い/低いはある程度納得感はでる。年俸もボーナス時の評価等を参考に役員が決めていて、まぁそんなもんかなという感じ。
あとはこの辺か
今か、少し先のフェーズで1番良さそうだと思ったのは、グレードで評価方法を分けるもの。
— Ippo Matsui / Ginco (@ippo_012) February 1, 2019
低いグレードはスキルシートで評価。
グレードがあがると実績で評価。
スキルシートのメンテナンス問題をかなり改善出来そう。#em_meetup
その他
https://www.ipa.go.jp/jinzai/hrd/i_competency_dictionary/download.html
ABC116 D - Various Sushi
考え方は正しかったっぽいので、本番で解きたかった。 あとネタの種類に対して美味しさが複数値あり得るということにしばらく気付かなかった。サンプルとかちゃんと見よう。
解法
とりあえず美味しさが大きい順に取っていって、暫定の回答を作る。そこからちょっとずつ変えていって、比較して行けば良さそう。美味しさだけに注目して暫定解を作ったので種類を増やしていってボーナスを考慮した時に満足ポイントが上がるか試していく。種類を増やす為には暫定解から一つ寿司を削って選択していない中から選ぶが、この時に
- 種類を増やしていくので暫定解に含まれているネタ毎には最低一つは寿司を残す必要がある
- 暫定解に含まれるネタの寿司を後から選ばない
- 一つのネタの中で一番美味しい寿司を削っても意味ないので美味しさが小さいものから削っていく
- 同様に寿司を選ぶ時には新規ネタの中で一番美味しいものを選ぶ
よって、
- 暫定解
- 絶対に残す寿司
- 削ってもいい寿司
- 選んだネタの種類数
- 暫定解から削った寿司以外でまだ選ばれていない寿司
を管理すれば良さそう。さらに、まだ選ばれていないネタから寿司を選ぶ必要があり、その中でも美味しいものから選ぶ必要がある。 流れとしては
- 寿司を美味しい順に並べる
- 美味しいものからK個選んで暫定解を作るが、その際に選んだネタはあとで使わないようにマークしていく。また、ネタ毎に最初に出てきた寿司「以外」を保持する
- 選んでない(マークしていないネタの)寿司を美味しい順に見ていって、追加して満足ポイントが大きくなるか見ていく。その際には毎回計算するのではなく、差分を計算する方が早い
情報科学若手の会冬の陣2019 に参加した
聞きながらとったメモなので聞き逃しや不完全な部分があるかも
本発表
Webフロントエンドを頑張りたい人と頑張りたくない人の為の話
- 頑張りたくない人
- 最小構成で楽するにはどうしたらいいか
- 用語集
- ECMAScript仕様 javascript 実装
- nodejs
- commonjs
- html/css/jsを生で書くのは?
- ページ数が少ない、jsほぼいらない、IEサポート必要ない ならok
- IEは最新の標準仕様に追従してない 対応すると依存ライブラリが増える
- jquery 動いているサイトは山ほどある
- DOM APIが進化してdom操作に不自由しなくなった virtual domもある
- webpackとかは必須
- 依存ライブラリが多くなる
- parcel zero-configの思想で作られいて楽だが、細かいカスタマイズができない
- rollup デフォルトではESModulesとか扱えない。ライブラリ開発使うのが良いと行っている人もいる
- なんでこんなに複雑に?
- 半分はIEのせい EOLがこない。サポートする必要がある
- とりあえずやりたい人の為の最小構成用意した あとでgithub 小さいってどのくらい?
- 頑張りたい人
- スキップ
- jsの可愛いところ
資料 https://arayaryoma.github.io/wakate2019w-slide/#/
実装して学ぶ Symbolic Backward Execution
- シンボリック実行とは?
- 数学でいうx,y,z的な変数的なやつ
- if文があったら網羅的に実行できる
- テストケースを網羅的に作れる
- 他にも色々
- FSE
- スタンダード
- エントリポイントから特定地点に向かって実行
- BSEは逆
- 最弱事前条件を計算すれば逆にできる
- ある性質が過不足なく満たされる
- 手動で計算してみる
- smtソルバはz3
- pythonで作ってみる
Deepな異常検知技術の最新事情
- chillstackという会社を企業しました
- deepにも色々な手法がある。前回発表したのはCNNで二値分類
今回はGAN
- よく使われるのは生成機(G)の方。fake画像とか超解像とか
Gで生成できないデータがきた時に異常とする
- G(z)とデータを比較するスコアがある
- AnoGAN
- 学習させたあと、異常か知りたいデータに一番似ているG(z)を作るzを探して、スコアを計算する
- G(z) -> G(g(z))と変形してインクリメンタルに探索する めっちゃ時間かかる
- EfficientGAN
- 探索コストがほぼぜろに
- データを潜在空間へ写像するEncoderを一緒に学習する
- zを探索する必要なし
資料 https://speakerdeck.com/palloc/yi-chang-jian-zhi-falsezui-xin-shi-qing-togei-yu-falsehua
セキュリティキャンプとCコンパイラ自作の誘い
- https://www.ipa.go.jp/jinzai/camp/index.html
- 選択コースと集中コース
- 講師(スペシャリスト)の人にすぐ聞ける
みんな熱意がある
- 他のものを知る足がかりになる
- gccとか頑張れば理解できるようになるのではないかと思える
- 実装方針
- インクリメンタルに作る
- 最初は小さく
- アセンブラをいい感じ出力してるサイトがある
- C言語は学部レベルでいける
ruiさんの資料見ながら進める
トップレベルの文法が辛い
- 普通の変数宣言が辛い
- 最近の言語はパーサに優しい
- 文法が結構複雑
- if(i=0,j=0) が合法
- 楽しい
Webデバイストラッキング手法の紹介
- webデバイス スマホとか
- デバイストラッキング
- サーバ側が同じ人との通信であることを知りたい
- 複数デバイスにまたがることもある
- 広告とか調査とか
- ユーザがコントロールできない手法だと問題になることがある
- cookie
- ip address
- 住所というよりビルのイメージ
- NAT
- webrtcを超える為の技術がある
- hsts super cookie
- tcp timestamp
- ssl session ticket
-
- NTA不要になり、普通にidとして機能する
- 割と普及してきた
アドテク業界では普通に使われている?
- わかる人が見るとすぐわかるので使われない。炎上したことも
資料 https://speakerdeck.com/kurochan/webdebaisutoratukingushou-fa-falseshao-jie
Node-RED フロー 分散処理化による次世代の都市システム
- スマートシティ
- 年に関わるセンサデータを取得してフィードバック
- ゴミ収集車にセンサ載せる
- 都市の至るところに展開できる
- 100Hzくらいで取得して、リアルタイムにデータ送信
- 一日100台。三日くらいでほぼ全域がカバーできる
- 超高性能ドライブレコーダ
- ゴミの量をカウントしたり、道路の表示のかすれ/陥没/ひびを検知できる 自治体の人へ
- たくさんのデバイスがあるので処理フローが複雑
- 従来であればクラウドで
- できればエッジ側で処理したい
- Node-Red
- 分散環境に対応してない
- 共同研究している人が分散対応させた
- ディープラーニングもエッジでやりたいので、専用のノード作った
CTFと現実世界
- CTFはコンビュータ総合格闘技
- 賞金も結構もらえる
- 企業主催の大会が増えている
- 技術の吸収・キャッチアップ
- リクルーティング
- メリットがあると認知されてきた
- ジャンル
- pwnable, reversing, web, cryto
- いずれも難易度が高くなっている。専門知識が必要
- 非自明なものが難しい・面白い
- セキュリティという分野自体がロジックパズルと相性良い
- 最近はネタ切れ気味
- OSSとか研究成果へ
- OSSでの問題で想定していない解法が出てくる -> 0day攻撃に
- バグハンティングと似ている部分もある
LT
キャリア選択のかんどころ
- 技術に関してもT型人材、複数の柱を作る
- 技術以外のソフトスキルも勉強しよう
- マネジメントとか育成とか
- ビジネス書も読もう
仕事の頑張り具合を記録して可視化する
- 開いてるウインドウを記録する
- もともと研究でやってた
- プログラミング教育で困っている人を検知する
- 社内リソースなので外部送信できない 自分で作る
- cocoaとswiftで作った
- 容量は一年で60Gくらい
- だいたい仕事頑張ってる
- http://haneuma0628.hatenablog.jp/entry/2018/12/21/000000
今年作るもの
- イベント運営めんどい
- タイムキープ周りを管理してくれるもの
- 過去に似たようなものを作った クソアプリになった
- ラズパイで作る
- android things
- kotlinでできる
