BigQueryにおける半構造データ(JSON型)と検索インデックス + パフォーマンス検証 - Qiita
もうとっく19日を過ぎていますが、空いていたのでぶっこみました(内容も詰め込みました)。 今回は、BigQueryのJSON型と検索インデックスに関して(比較的)詳細に調べたので説明していきたいと思います。 具体的には以下について説明します。 BigQueryでJSON型を扱う方法 検索インデックス SEARCH関数 検索インデックスのパフォーマンス検証 最後のパフォーマンス検証は割と必見ですが、その他の3項目については、詳細に説明していて文量が多いため、適宜興味のあるところを読んでいただけたらと思います。 要点 本記事の重要な点をかいつまむと以下のようになります。 JSON型の操作について ドット演算子で簡単にフィールドにアクセスできるが、そのままではJSON型のため、他の型として扱いたい場合は、JSON_VALUE関数などを用いて変換する 数値は(意図せず)丸められる可能性があるため、
Glue Schema Registry の導入を断念した話
業務で AWS Glue Schema Registry を使おうとしたけど、やっぱりやめたというお話。 Glue Schema Registry#What’s Schema Registry?#AWS Glue Schema Registry は2020年に発表された AWS の機能だ。 Control the evolution of data streams using the AWS Glue Schema Registry一方、私が最初に schema registry 的なものを見たのは Confluent の例。 Schema Registry の概要 - ConfluentAWS の Glue Schema Registry はこれより後のリリースであり、同等のものの AWS マネージド版といったところだろうか。 schema registry で何ができるかは Confl
CSチームへの事前共有用のリリースノートを書く - ヴェルク - IT起業の記録
boardというSaaSを提供していて、その運用における開発チームとCSチーム間での共有の話です。 社内用リリースノートとは boardでは、ほぼ週1ペースでデプロイしているのですが、その内容を事前にCSチームに共有するため「社内用リリースノート」を書いています。 基本的なフォーマットは決めていて、以下の内容を記述しています。 ## リリースノート ### 機能追加・改善 #### ユーザーさんに見えるもの #### ユーザーさんに見えないもの ### バグ修正 ### 運用や内部的なもの ## CSチームに事前に操作・把握しておいてほしいこと ## このリリースに伴うリスク デプロイのおよそ1週間前にはリリースノートを書いて社内に共有します。 なお、エンジニア向けにはGitHubのリリースタグで管理していますが、この社内用リリースノートは「CSチーム視点で把握すべきことの共有」を目的とし
個人プロダクト開発の成功に必要なこと - ボクココ
ども、@kimihom です。 よくエンジニアと話していると、「~を作ろうと思ってるんだよね」とか「今 ~ を作ってるんだよね」とかそんな話をよく聞く。私はこれらの話を信じないようにしている。なぜなら、そのほとんどが情熱半ばで止まってしまったり、作ったとしても自己満のレベルで止まってしまったりするからである。 一人で作りきることができて、ユーザーに使ってもらえるレベルまで成長させるのは、当然ながら難しい。でも、そこまで行けばちゃんとそのアプリやサービスをメンテナンスしようと思うし、ユーザーからの声を聞くことになる。大変だけどもやりがいのある趣味になるし、収益化を狙うことだってできる。自己満で終わりじゃなく、みんなに使ってもらって満足させられたなら、開発者として幸せなことではないか。そこまでやって初めて、"個人プロダクト開発が成功した"と言えると考えている。 今回は、一人で色々なアプリケーシ
個人的コードを早く書くための覚書
なんとなく書いてみた。というか書いてみると作業方針ぽくなったし、チケットの捌き方みたいになった。 IDEを駆使して自分の作業をoptimizeする ショートカットキーとコード補完などは覚える。 操作を行う頻度の多いもの、処理に時間がかかっているものを最適化するのが目的。 IDE自体の処理スピードがネックになる場合はチューニングすること。 タイピングからのレスポンシビリティが下がる、 ビルド・デプロイにコードベースの量から想定される以上に時間がかかる。 などと行った場合はなんらかのゾンビプロセスなりが存在しているかもしれない。 なるべくチケット化する これはプロジェクト方針と合致するかということも大いにあるけど、 基本的にチケットは細かくあったほうが良いと考える。 明らかに作業に対してチケットのタイトルが合致していない場合、 チケットにない作業をしている場合などが該当する。 タスクを細かく切
自分の成果物を自分で使え - 西尾泰和のScrapbox
今まで他のコースやSecHack365全体のやり方などに配慮してあえて言わないできたけど、今日はそれをあえて書いてみようと思う。 とりあえず、こういう考えの人もいるんだなー程度に思ってほしい。これが絶対の正解というわけではない。というか正解はたぶん複数ある。だから好きな正解を選べばいい。
昔のパソコンの色数
24bit表示が当たり前に出来る今からは想像もつかないが(?) ちょっと前のパソコンは同時表示色数が少なかったりした。 『マイ』コン少年達は他機種と比較して一喜一憂したものである。 そんな時代の空気をちょっとだけ―。 最終更新日 2003/7/11 色数じまん グラフィック面に相当する部分の同時発色数で勝負です。 『/』が入っている場合は『同時発色数/選択可能色』の意味です。 書かれている解像度はその画面モード時のものです。 解像度より色数を徹底的に優先しています。 今の所、インターレースや特殊な設定は抜きにします。 その代わり?セミグラフィックはありですが(汗)。 間違いや「このパソコンが抜けてる」等ありましたら メールで御連絡下さい。 8001・8051
JavaScript を愛してくれ - エムスリーテックブログ
この記事は エムスリー Advent Calendar 2022 の 21 日目の記事です。 前日は @mski_iksm による 毎日追加学習する機械学習モデルを、日次実行を止めずにコードをバージョンアップしたい - エムスリーテックブログ でした。 こんにちは。エンジニアリンググループの西川です。 好きな言語は JavaScript です。 適当に書いているので実はあまり習熟していないです。 さて、私は趣味で JavaScript のことを頻繁に調べているのですが、この言語は「好き」と打つと「好きになれない」がサジェストに出てきます。 私はこのことを大変心苦しく思っていました。 JavaScript は思い立ったらすぐ書け、動かせる、非常に魅力的な言語です。今この記事を閲覧しているブラウザひとつで、サクッと実行できます。 そんな素晴らしい言語が嫌われることは極めて遺憾であり、やり切れな
研究や仕事のアイデアメモをとるツール｜武久真士
ふと思いついたアイデア、これから育ちそうな研究の種、あるいは舞い込んできたタスク。そうしたものをなににメモするか。これはなかなか悩ましい問題です。 メモをとるのに最低限必要な条件は、いつでもメモがとれることと、すぐにメモがとれること。思いついた時にメモ帳が無いのは論外ですし、時間が経つとアイデアやタスクを忘れてしまう可能性があるのであまり放っておくのもよろしくない。 ちゃんとアイデアを展開する場所はまた別に用意するとして、その場の思いつきはささっとどこかにメモしたい。私の知る限り、優秀な研究者はこまめにメモをとっている気がします。 私自身は、最初アナログの手帳にいろいろと書き込んでいました。手帳にはそもそも予定を書いてあるので、日ごとのタスクを管理するのが簡単です。うしろのほうにメモ用のページがいくらかあるので、研究などのメモもそこにとれます。 ただ、アナログ手帳はメモにあまり向きませんで
1ヶ月に30冊本を読む僕が教える、読んだら忘れない、使える読書法｜半蔵門と調布あたりで働く、編集者のおはなし
僕は仕事柄、本をよく読みます。 エンターテインメントで読む本が、月にだいたい10冊ぐらい。そして仕事で読む本が、だいたい月20冊だから、合計約30冊ぐらいの本を読みます。 ジャンルは小説、ビジネス書、ノンフィクション、実用書、エッセイ、専門書などさまざま。 人に比べると多読な方なので、よく人から、 「設楽さんはどういう読書法をしているのですか？」 「30冊も！？速読できるんですか？」 と聞かれます。（もちろん速読なんて高等技術はできません。笑） 本記事は、僕が人からそんなことを聞かれた時にお話しすることをまとめたものです。 「もっと読書をしてみたい」 「本を読んだ経験や知識を役立てたい」 そう思う方は是非ご一読ください。 本を読むコツ その１） エンターテインメントの読書は、とことん味わえ僕は、読書を2種類に分けています。 一つは、エンターテイメント、つまり「完全な趣味」で本を読むこと。（
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
