Deprecated: The each() function is deprecated. This message will be suppressed on further calls in /home/zhenxiangba/zhenxiangba.com/public_html/phproxy-improved-master/index.php on line 456
luccafortのブックマーク / 2018年12月21日 - はてなブックマーク
[go: Go Back, main page]

タグ

2018年12月21日のブックマーク (5件)

  • バッチ処理の一部で 30 分以上かかっていた処理を 14 秒で終わるようにした話 - @watson1978 の日記

    Ubiregi Advent Calendar 2018 の 18 日目です。 ユビレジではたくさんのお客様の大量の POS データをお預かりしており、様々なバッチ処理も実行されています。今回は特定のケースでバッチ処理の一部が 30 分以上かかっていた処理を 14 秒で終わるようにした話について書きたいと思います。前回の Ruby 2.5 の SEGV と闘った話 - @watson1978 の日記 に引き続き DTrace を使った話になります。 はじめに ユビレジでは CSV ファイルでお客様が特定のデータをダウンロードしたりアップロードできる機能があります。CSV ファイルにエクスポートしたり、CSV ファイルから DB に取り込む処理を Worker を起動してバッチ処理しています。 大量のデータを保有しているアカウントと同量のデータを用意して手元の環境で試したところ時間がかかるこ

    バッチ処理の一部で 30 分以上かかっていた処理を 14 秒で終わるようにした話 - @watson1978 の日記
    luccafort
    luccafort 2018/12/21
    なるほど、DTrace知らなかったけど便利そう…と思ったけどブコメみてプロファイラ調べたらこっちのほうが良さそうなきがしてきた。なんか特別な問題あったのかな?
  • Swagger+JSON SchemaでAPIの型をテストして開発サイクルをスピードアップさせた話 - pixiv inside

    CTO兼福岡オフィス立ち上げ担当として新アプリを作っている@edvakfです。 JSON APIを開発しているとこういう問題がありがちですよね。 仕様どおりにAPIの形式を作ったはずだけどなんか自信が持てない テストでいくつかのキーが存在するかの簡単なチェックはしてるつもりだけど、全部チェックするのは大変すぎる APIのControllerやViewをリファクタリングしたらレスポンスの形が変わってアプリがめっちゃクラッシュし始めた というのが怖くて誰もリファクタリングできなくなった APIドキュメントがメンテされない 知らない間にレスポンスのフィールドが増えてたけどドキュメントに書いてない これらを解決したい!と思って試行錯誤したら、スマートに解決することができました。この記事ではRailsのことについて書きますが、考え方は他の言語・フレームワークでも同じです。 なお、今回使ったgemのバ

    Swagger+JSON SchemaでAPIの型をテストして開発サイクルをスピードアップさせた話 - pixiv inside
    luccafort
    luccafort 2018/12/21
    committee ライクなものなのかなapivore?もしそうなら試してみたい気持ちがある。
  • 開発タスクを決める思考整理のためのIssueテンプレート - Konifar's ZATSU

    開発タスクの決まり方は組織によって色々だろうけれど、いきなりポンとタスクを渡されて 「そもそもこれなんでやるんだっけ?」「他のタスクと比べて今やる意味あるんだっけ?」という気持ちになったことはないだろうか。工数かかるなーと思いながらよくよく課題を聞いてみたら、実はもっと簡単なやり方でスマートに解決できそうだったとか。 開発する時には、課題と解決策の納得感を持って進めたい。結果的にその解決策の筋がよかったとしてもだ。こういった意識を持っている開発者は意外と多い印象だが、チームで働く上でそのマインドを統一するのは意外と難しい。 そこで、開発タスクを決定する際の思考整理としてIssueテンプレートというものを用意してみたことがある。やろうとしているタスクに関して、一度このテンプレートに沿って埋めてみるのだ。書いている途中であれ?となるかもしれないし、書いたものを叩き台にして開発者からもっといい解

    開発タスクを決める思考整理のためのIssueテンプレート - Konifar's ZATSU
    luccafort
    luccafort 2018/12/21
    どういう問題を解決したいか?を出すのにコンテクストの共有が出来てないとそもそも方向性を誤ることがあったのでぼくらのチームは背景を共有してから解決策を模索するようにしてる。
  • v-kansai Vue.js/Nuxt.js meetup #1 - おうさまのみみはロバのみみ

    Vue.jsのコミュニティーができたということで第1回に参加してきた。 vuekansai.connpass.com なお、すでに2回目のスケジュールが確定してる。 いまみたら30人枠(抽選)のところに80人募集がかかっていてVue熱の高まりを感じる。 vuekansai.connpass.com 第3回の開催場所なども募集されているそうなのでいま会場提供すると会社の宣伝として強そうだなと思いました(小並感) あと個人的には Vue Fes 関西 (…がやりたいなという話が出た)が実現するとめちゃくちゃ嬉しいし、やってほしいという気持ちしかないです。 参加した感想 個人的には参加してよかったという面とそういえば「これ質問したかったんだけど忘れちゃってたな…せっかく質問できる機会があったのにもったいない」という反省点があります。 そのあたりは後述しますが登壇してるときに観客側がめちゃくちゃ静

    v-kansai Vue.js/Nuxt.js meetup #1 - おうさまのみみはロバのみみ
    luccafort
    luccafort 2018/12/21
    昨日 #v_kansai に参加したのですが真面目にVue Fes Kansai期待しています。
  • 正しさとGo - Qiita

    はじめに Goの良いところは、最低限の文法を知っていればコードを上から順番に読むことで詳細を容易に理解できることです。 文法の中にシンタックスシュガーや特別な省略が許されていないため多様な表現になることはありません。 そのためGoを書ければGo体と標準ライブラリを読むことができます。 しかし以下の原因により、これらの利点を守ることが難しくなることがあります。 DSL フレームワーク 抽象化 これらは設計として新たな制約を課すことで品質向上や実装を容易にするためのものです。 またこれらを採用する論理立てた 正しい 理由が存在します。 DSL DSLを提供するツールとして、DIのための wire があります。 GoでDIを実現するためには多くの実装を必要とするため、実装量を減らすためにもDIツールが求められてきました。 これは 正しい です。 しかし一方でDSLはコードを読む人間に言語以上

    正しさとGo - Qiita
    luccafort
    luccafort 2018/12/21
    "「コードがシンプルであるためコードレビューで気がつくことができる」"GolangのErrorの処理、面倒だなと思う半面シンプルすぎるくらいにシンプルでどういうときにエラーが返るかわかりやすいので好きなのかも。