rifkiamil

Looker all_oauth_client_apps example responses

This Gist contains example output from the Looker API 4.0 all_oauth_client_apps endpoint (GET /oauth_client_apps).

It includes:

1. OAuth client applications present on a Looker instance for integrations such as Connected Sheets, Power BI, Tableau, Excel, Gemini Enterprise, and Looker CLI.
2. A sanitized example of a customer-created OAuth client application used by Codex CLI with a Looker-managed MCP server.

The examples are useful for developers, administrators, security teams, and users who may not have access to a Looker instance or sufficient permissions to see what an actual all_oauth_client_apps response looks like.

rifkiamil

Introduction

The command-line environment on macOS is experiencing a renaissance in 2024–2025. Beyond the built-in Terminal.app, a wave of modern terminal emulators and related tools are vying for attention – especially among developers, DevOps engineers, and power users often dubbed the “cool kids.” This report explores the coolest terminal/emulator tools for macOS in 2024–2025 and compares them, including how they stack up against resource monitoring tools like btop. We’ll survey which terminal emulators and CLI tools are gaining traction, delve into each tool’s features and differentiators, discuss what makes them trendy, and consider their target users and platform support. We’ll also examine strengths and trade-offs (performance, resource usage, complexity, cost, etc.), and where a tool like btop fits in. Finally, we present case studies of a few trend-setting terminals, and give recommendations for Mac power-users choosing a terminal setup in 2025 – including when to augment a terminal with

rifkiamil

rifkiamil

Let's look at the Speckle APIs and 3 methods getting data into Looker Studio.

1. https://speckle.guide/dev/server-rest-api.html
2. https://developers.google.com/looker-studio/connector
3. https://developers.google.com/apps-script/reference/url-fetch/url-fetch-app

Speckle Service APIs: GraphQL vs. REST

Speckle provides both GraphQL and REST APIs to interact with your data on a Speckle Server. They serve similar purposes (accessing streams, commits, objects, etc.) but differ in how you structure your requests and receive data.

rifkiamil

Trino's Efficiency in Processing JSON Files in Data Lakes: A Technical Deep Dive

Introduction

Trino, the distributed SQL query engine formerly known as PrestoSQL, is engineered for high-performance, interactive analytics across a multitude of heterogeneous data sources.1 Its architecture is particularly well-suited for querying large datasets residing in data lakes, whether deployed on-premises using HDFS or in the cloud on object storage systems like Amazon S3, Google Cloud Storage, or Azure Blob Storage.2 A key capability enabling this is Trino's schema-on-read approach, allowing users to query data in various formats directly where it resides, without requiring upfront transformation and loading into a proprietary storage system.3

JSON (JavaScript Object Notation) has become ubiquitous in modern data ecosystems, frequently used for API payloads, application logs, configuration files, and semi-structured data exchange.7 However, querying JSON efficiently at scale presents significant challen

rifkiamil

Trino JSON Processing in Data Lakes: Engine Internals, Comparisons, and SIMD Aspects

Engine Internals and JSON Processing Enhancements

Trino’s JSON architecture: Trino (formerly PrestoSQL) is a distributed MPP query engine where workers scan data in parallel and pipeline results in memory. JSON in a data lake (e.g. files on S3 or HDFS) is typically handled via the Hive connector, which treats JSON files as line-oriented text. Each JSON object (or array) is expected to be a record – often one JSON per line (NDJSON). Trino splits large JSON files into segments for parallel reading, aligning splits on record boundaries (usually newline delimited) so that no JSON object is cut in half between workers. This ensures each split contains whole JSON records for valid parsing. Internally, Trino uses a LinePageSource to read text files and find record boundaries (e.g. newline positions) so that each worker thread reads a chunk of the file and emits complete JSON rows. For extremely large JSON objects th

rifkiamil

-- Template for Azure Synapse Dedicated Pool Table Creation from Query with CLUSTERED COLUMNSTORE INDEX ORDER
-- Schema: testing_rif_k
-- Goal: Make easy to find the commands that only work on Azure Synapse Dedicated Pool ( SQL DW )

CREATE TABLE testing_rif_k.banking_data
WITH
(
    DISTRIBUTION = HASH(AccountId), -- Recommended for even data distribution based on a key
    CLUSTERED COLUMNSTORE INDEX ORDER (TransactionDate DESC) -- Good for analytical queries on date ranges
    -- DISTRIBUTION = ROUND_ROBIN, -- Useful for small tables or when no clear distribution key exists

rifkiamil

Rrocess to ensure that both your debug and release builds (including those distributed via Google Play) are correctly recognized by Firebase for Google Sign-In. Option Reading Might want to read SHA1 key hell regarding Gmail authentication and sign-in.

---

Overview

• Debug Builds:
  Your development builds are signed with the debug keystore (typically located in ~/.android/debug.keystore). The SHA-1 fingerprint from this keystore is already added to Firebase, which is why sign-in works in the emulator.

• Release Builds & Google Play App Signing:

rifkiamil

Project project_name {
  database_type: 'BigQuery'
  Note: 'Football Data by https://github.com/dcaribou'
}

Table appearances {
  player_id INTEGER
  game_id INTEGER
  appearance_id STRING [pk]
  league_id STRING

rifkiamil

Project project_name {
  database_type: 'BigQuery'
  Note: 'Football data'
}

Table appearances {
  player_id INTEGER
  game_id INTEGER
  appearance_id STRING [pk]
  league_id STRING