読者です 読者をやめる 読者になる 読者になる

水底

ScalaとかC#とかネットワークとか

私的WindowsのUnixShell環境(暫定)

OUCC Advent Calendar 2016 - Adventar 二日目の記事にしましたが特にOUCCは関係ありません. 他のadvent二日目の記事を偶然見かけて「いや, 明日やろwww」とか思ったら今日でした. 今日は九条カレンさんの生誕祭が終わってしまったという悲劇的な日です.

Windowsを利用していても, 結局のところUnixShellが必要になる. Anniversary updateでBash on Windowsが追加されるなどWindows上のUnixShell(モドキ含む)の発展が著しいが, ある程度自分用の環境が整ったので簡単にまとめる.

続きを読む

Pythonのimportで見事ハマる

(環境: Windows10-anaconda/python3, Debian8.5-anaconda/python3)

TL;DR

循環インポートしてた

タイトル通り. python様に「おめぇのpackage認めねーから!」とお叱りを受ける.

調べると大体以下の解決策がヒットする

  • ルートパスが解決できていないのでPYTHONPATHをプロジェクトルートに設定する
  • sys.path.append("/path/to/dir")でパスを追加する
  • 自作package化するためにpackageにしたいディレクトリに空の__init__.pyというファイルを作成する
  • 自作packageを呼び出す際はimportで.pyを含めない

(上2つはパスの解決のため, 3つ目はディレクトリ構造をpackageと認識させるため(python3.3以降は不要らしい), 4つ目は拡張子を除いた文字列がモジュール名と認識されるというルールのため)

が, どれを試しても解決しなかった. エラー内容はno module named ~~ is not a packageといったもののみで上記以外見当付かず. PyCharmを利用していたのでそちらも確認したがエラーのサジェストは一切なし. 動かなくなった前後の変更点を端から試したところ循環インポート, 実際には(エントリポイントのpy -> とあるモジュールA, とあるモジュールA -> エントリポイントのpy)となっていた. この循環インポートをなくしたところ実行できるようになった, めでたし. (エラーサジェスト欲しかった…)

キーバインディング暫定まとめ(Win/OSX/Linux)

(Linuxに追記アリ 2016/12/3)

独自のキーバインディングを多用する, しないと死ぬタイプの人種のため全ての環境でなにかしらのキーバインディングソフトにお世話になっている. 一段落したため各環境について簡単にまとめておく.

続きを読む

Scala関西Summitでスタッフがscala.collection再入門(改)をしゃべってきた #scala_ks

Scala関西Summitお疲れ様でした. 自分はスタッフとして参加しつつlongで1つしゃべっていました. ひしだまさんの裏だったので1対1とかにならないか不安だったのですが意外と来て頂いたようでありがてぇありがてぇ. 「あれ…タイトルや資料に既視感が…」という方もいたと思うのですが, その通りです. 元々Scala関西勉強会で一度喋ったものなのですが, 委員長のきの子さんの強い要望(?)によりCFPを出して最終的に登壇することになりました. 時間を目一杯使いつつ最後のほうのスライドは端折りましたが実は計画通りです(あまりお行儀は良くないですが…). 「1発表スライド」としてだけでなく「完結した資料」としてまとめておきたかったんです(そのせいで文字も多めになっていたり). タスクに追い込まれれば追い込まれるほど変なところで潔癖症になるタイプ.

※注: 以前の資料と同じようで結構更新しています. 表現が怪しかったり微妙に間違っていた箇所の修正を多数含みます.

最後にどうしても記録しておきたかった名言で〆

Docker in Docker のメモ書き

「Dockerの中でDcckerを動かしたい」ということはよくあると思う. 主に2つのアプローチが存在する.

  • dind(DockerinDocker)イメージを利用
  • sockをホスト-コンテナで共有する

今回は後者を取り上げる. なお, どちらの方法もセキュリティ的にやや難ありなので注意して使う必要がある. 以降, すべてのホストをA, 通常のコンテナをB, コンテナ内から呼び出されるコンテナをCとする.

利用方法は非常にシンプル. A-B間で「sock」と「dockerコマンドそのもの」をrun時にvolume経由で共有する. 以下, 簡単なサンプル.

# on A
docker run -it -v /var/run/docker.sock:/var/run/docker.sock -v `which docker`:/bin/docker alpine sh

# on B
which docker
# => /bin/docker
docker info
# => Aのデーモンのinfoが出力される
docker ps
# => B自身が含まれたリストが出力される

A上でBCが並列に実行されるイメージだ.

注意点

ABのディストロが異なるとき

バイナリ互換の関係か, 共有したはずのdockerコマンドが動かないことがある(ホストA: ubuntu, コンテナB: alpine で確認). どうしようもないので, Bに対してコマンドを個別でインストールまたはBのイメージビルド時に埋め込む必要がある. (ちなみに公式docには, 「クライアントとしてのdockerコマンドならOS Xでビルドしてもlinux上でもだいたい動くはずだぜ!」とか書いてありますが動かないものは動かない, 悲しい)

Docker in Dockerのrun時にvolumeを使うとき

B内でdockerコマンドを叩くときに -v を使ってvolume共有したいことがあると思う. このとき, :の前に記述したパスはsockの所有者, つまりAのパスとして解釈される. BのコンテンツをCと共有したい場合は一旦Aを経由させる必要がある.

以下, 上記の注意点を考慮したサンプル

# on A
docker run -it -v /var/run/docker.sock:/var/run/docker.sock -v /piyoA:/piyoB alpine sh

# on B
apk add --no-cache docker
docker run -it -v /piyoA:/nyanC alpine sh

B上の/piyoBA上の/piyoAを経由してC上の/nyanと共有される.

トレジャーデータでインターンしてた話 #td_intern

第一話「なんだかホントに入社した気分です!」

8/1-9/30の二ヶ月間参加してました. 丸ビルのプレミアムフロアでした. すごい. そして皆さんにご報告があります. インターン開始直後のこのツイート

なんと一回も涼風青葉さんにならずに切り抜けました!!!

f:id:amaya382:20161001195150j:plain

やっていたこと

メンターの @myui さんの下でHive上で動く機械学習ライブラリである Hivemall の開発を主に行っていました. なかなか慣れずに終始進捗がよくなかったのが心残りです… 具体的な内容はスライドを見ればわかるかもしれません. ちなみに今後もたまにPR投げようかなーと思っています(既に手元にはbranchが).

(やたら枚数が多いですがアニメーションを分割しているだけです)

エイゴハナセルヨウニガンバリマス(震え声)

続きを読む

ISUCON6ダメでした #ISUCON

去年の に引き続き2回目のイスを投げるコンテストに @uadachiさん, @hayasshi_さんと チーム お腹すいたCity で出てきました. 自分は学生ですが一般枠です. 結論から言うと ダメでした

以下文章力がないのでメモみたいな箇条書き

前日まで

  • チームリハーサルとしてISUCON5のお題をakka-http+scalikejdbcでフルスクラッチ(!)

    • akka-httpは初めてだったが同期/非同期制御周りが非常に扱いやすい印象. また使ってみたい
    • が, やはりフルスクラッチに5hほどかかってしまった(しかもチェックしきれてない)ので断念, おとなしくチューニングで行く方針に
      • (恐らく3人とも慣れていれば十分にできると思われ)
  • その他, githubのprivate repoとslackとかを使いながらいい感じのconf集めやらsnippetsの用意

当日

  • インタァンの関係で自分はリモート参加
    • 去年のエントリで「ハングアウトで通話しながらやってたんですが, 実際に集まるべきでした. 多分効率が全然違う.」とか書いたのに…
  • 予定通りScala実装で, 去年と違いちゃんと動く実装だとのことで一安心
    • ソースを読むと結構こなれたコードが散見された(出題がはてなさんだからかな?)
      • よさisここにあり
  • とりあえずベンチ回すと他のチームが3k~4kの中, 堂々の 0点
  • 主に以下の分担で進めた
    • DBやらクエリ周りをいい感じに
    • Nginxとか静的ファイルとかをいい感じにしたり全体の管理とか(@uadachi)
    • redis導入や非同期処理やデプロイ周りやら(@hayasshi_)
    • apiごとの細かな部分はその場で分担
      • 個人的にslow queryやコードから明らかだったhtmlifyの改善. (終わってから超重要なポイントだったと知る)
      • 「keywordはメモリで管理行けるやろwついでになんかすごい正規表現あるし適当に直そw」という軽いノリで直そうとする
      • 当然のようにハマる
        • concurrentなcollectionに慣れておらず微妙に手間取る
        • escape処理をミスりまくってバグの嵐(contentが全部リンクになったりして楽しかった(棒))
      • (模範解答らしい?)aho-corasick?trie?とか考える余裕なく
  • 普段intellijで完結させてるせいで, 「あれ?UbuntuOnWindows環境でsbt動かないっけ?」とか言ってローカル環境で動かすのは諦めた(←後々致命的すぎた)
  • その他, メンバー全員で非同期沼にハマったり(servletサン…)
  • 最後の最後でそれなりの速さで動いた(っぽい)もののベンチマーク間に合わず😇

去年からの成長点

  • リハーサルをしたおかげか, DB周りの(簡単な部分の)扱いがちょっと早くなった
    • 設定を流し込んだり
    • 一部計算をcolumn化したり
    • indexやらメタ的な部分の確認・調整
  • 開発スタイルの確立
    • PRは作るがガンガンmerge
  • あれ…?それだけ???
    • まるでせいちょうしていない

もっとやるべきだったこととか

  • キャッシュ箇所の洗い出し
    • もっと早く, 明確に
    • 大体メモリに載せれば早くなる(てきとう)
    • ロジック変更を伴うチューニングといかにうまく並行して作業分担ができるか
      • 若しくはキャシュ箇所は思考停止で先に全部やったほうが後々楽か(?)
  • 正規表現の扱い
    • aho-corasickとかtrieに切り替えていくための知識と勇気
  • 統合の検討
    • APIレベルであったり
    • 今回のようなmicro serviceであればそれらの統合も視野(?)
  • skinny frameworkに詳しくなる
  • ベンチでfailした箇所を早期にデバッグ・解決する手段
  • ローカル環境はなにがなんでも用意する
    • やっぱり最初は デバッガ使ってアプリを実際に動かして 追いつつ
    • 終盤色々弄ってバグらせないためにも必須
  • リモートはダメ, ちゃんと集まる
    • 打ち上げが許されない

お疲れ様でした. 結果はダメでしたが色々と知識が増えました. 最後に非常にいい感じのコミットログで〆

f:id:amaya382:20160918194816p:plain