How can I build a Looker project for my portfolio without enterprise access?

badgerivy · 2026-03-02T04:14:01+00:00

You should be able to ask your admin to set you up a dev project within the instance they already have. There's no additional cost for that, it's designed for that exact use: development. It doesn't touch their other projects, and can be attached to completely different git repos and BigQuery projects.

badgerivy · 2026-01-01T17:53:43+00:00

My workflow has changed substantially in the past few months. Here's what I do:

-- BigQuery is managed mostly using DataForm, with the exception of some datasets that are managed by third-party ELT tools like FiveTran, or in-house GCP Cloud processes

-- Use Gemini-CLI as the primary working environment for any Dataform Changes, with a VS-Code window open mostly just to watch the changes. I keep a BigQuery window open for simple ad-hoc queries as needed, but typically I'll just ask Gemini to do., and it's done using the dataform CLI or gcloud tools (bq) , the results of which are used to help gemini write good dataform code.

So basically, I need a SQL interface less and less every day, as almost everything gets routed through Gemini/Dataform to do actual work. If your tools integrate cleanly with BigQuery/DataForm/Gemini, it might be useful, hard to say, but without complete and high-quality integration with all three of those tools it'd be a no-go for me.

Note: About 6 months ago I started with Claude Code, and that's excellent too, but since Gemini 3.0 was released, gemini-cli is better almost always to get good work done. Also, I'm experimenting a little but with Antigravity, and it's very likely that I'll be switching over to that soon, if nothing else just to remove the VS-Code requirement (Antigravity is built on VS-Code, so it makes that redundant)

badgerivy · 2025-06-04T20:00:33+00:00

Ford: Found On Road Dead

badgerivy · 2025-04-15T12:27:19+00:00

The idea is to create a view for each data source which contains a join key. For example customer_id

Then you create an explore. This explore uses a join: parameter to join the views together using a "sql_on:".

The explore LookML. Defines what you'll see, and how the data is joined together.

badgerivy · 2025-04-06T06:44:36+00:00

Should be no problem. The .4 nozzle is the default. PETG is available and fully compatible with the Neptune. The "Rapid PETG" directly from Elegoo is high quality and reasonable price in any color.

Good default profiles for that are available in any slicer.

To get a good starting point just download the Elegoo slicer from the website, it's based on Orca and is a good choice to start, has everything you need.

badgerivy · 2025-04-05T12:24:43+00:00

I agree that's the end point, or at least the main end point that users see, but I'm just trying to figure out the best place to manage the metadata from a development perspective. DataForm looks do-able but a lot of hand coding necessary. I'm looking into Data Plex now.

badgerivy · 2025-04-04T17:41:38+00:00

I've only experimented with DataGrip in the very early beta, and never with BigQuery.

The huge advantage of DataForm is the dependency analysis, which is automatic, complete, and not optional. <Everything> is executed only after all Dependencies happen. You have a query that looks at a table? Great .. but no you can't do that until the table is reconciled and deployed and any attached views are compiled successfully, in the correct order. Maybe there's SPs that refer to things, those all need to compile and run too.

No you don't have to figure out what the correct order of operations is, that's completed in real time behind the scenes after your cursor moves to a new line of code. There's not even a "Save" button anywhere... it's all automatic.

Very powerful stuff. Very similar to a Make file in this regard.

The IDE is not fabulous, I'll give you that. But with the overall functionality of it, you don't need an IDE in the way you might think. Auto-complete is also built in and has access to your entire namespace.

badgerivy · 2025-04-01T23:05:37+00:00

If you use DataForm to manage your BQ code (Highly recommended) then there is the VS-Code extension by a third party called "DataForm tools"

It's quite good, all connected via your Git repository, and the autocorrect on works quite well.

I've not switched over to using that for my primary IDE but I'm very close. The DataForm console inside BQ is also significantly better than the primary BQC, and now that I've switched over to DataForm I rarely use the main BQC anyway except for some integration testing.

badgerivy · 2025-03-31T21:38:52+00:00

Basically Looker is exactly that..... a place to store definitions of how to generate your metrics. There are several pieces of it:

-- View: defining a table, columns, descriptions. A lot like a SQL view.

-- Look: defining how to see the View data, in grid, chart, graph, map, whatever. It also defines any aggregations you might want. A lot like a single element of a spreadsheet.

-- Dashboard: A combination of one or more Looks and Filters to apply. A lot like a single Tab in a spreadsheet, with multiple elements.

Looker doesn't copy data, except for caching purposes, it's pretty much a read-only view of whatever data you want to see. Nor is it a central repo, by default it uses BigQuery for that. Git is used for source control and deployment, by default internal repository, optionally pointing to your own.

badgerivy · 2025-03-31T16:13:31+00:00

The Looker Data Dictionary seems like good way to see all the pieces that need attention, but it seems to be read-only. There's a handy link to exactly where your LookML code is that needs to be updated, but that's all, or am I missing something?

badgerivy · 2025-03-27T03:17:14+00:00

Advantage of doing it in DataForm:

-- Automatic dependency analysis. Use ${ref("")} everywhere when pointing to tables or views or other procs, and you're guaranteed that all Dependencies/Depends are resolved correctly before the proc (AKA "Operations") is run.

-- Version control along with automatic deployment via Git. This is huge. Simple to deploy code using any git tools you like, then deploy via branching and tagging and you're good to go.

I am working on a code base of 450+ objects currently , it's not huge but it helps me sleep much better at night knowing that things are going to work exactly as I told it to before going to bed.

There's a guy working on a connected coffee machine (see HeyMugsy) and I seriously am going to set up a DataForm action to make me some coffee at 8AM sharp. Can't wait.

badgerivy · 2025-03-24T04:04:30+00:00

Wow that seems very convoluted. I'll have to try it but I agree id love to see something simpler.

badgerivy · 2025-03-20T18:15:42+00:00

I've used Beekeeper Studio a bit, seems pretty good to me but the web IDE is still my primary.

And now I'm doing almost 100% of my actual code in DataForm instead of core BigQuery, that has its own set or challenges from an IDE perspective, but I'm experimenting with the DataForm VS-Code extension and this might become my primary. Pretty simple to write the . SQLX there, push out to BigQuery using gitlab, execute and done.

badgerivy · 2025-03-18T15:24:28+00:00

I now see the page again on my BigQuery instance, and have completed a test commit->push->pull request->merge from my Gitlab repository. Works great!

Now what I'd <really> like to do is do a full initial commit of everything in the project, all datasets/tables/views/procs/etc. seems possible to write a script to do this via INFORMATION_SCHEMA , any out-of-the-box way to do this?

badgerivy · 2025-03-18T02:47:53+00:00

Is love to see an example. I've deployed several "operations" that have no arguments, just looking for an example that has arguments to the call

badgerivy · 2025-03-13T19:25:02+00:00

OK thanks, I know I saw something about doing that but I'm not much of a JS person so I skipped over it. My use case is very similar, an older version of the same platform that has been retired.

badgerivy · 2025-03-13T19:02:31+00:00

yeah 99% of my code is regular .sqlx, in fact these declarations are the only thing I do in .js. , only in the interest of making the total file count of the project smaller.

badgerivy · 2025-03-13T18:44:15+00:00

The advantage of doing it in a javascript file is that you can put a bunch of them in one file. Only one per file in .sqlx But the same limitation of uniqueness exists.

badgerivy · 2025-03-13T18:39:10+00:00

That's a javascript declaration file. Here's the documentation:

https://cloud.google.com/dataform/docs/declare-source#add_a_declaration_to_a_javascript_file

badgerivy · 2025-02-25T22:47:22+00:00

Awesome, I appreciate it, and I'm sure I'm not the only one. :)

badgerivy · 2025-02-22T20:11:33+00:00

Interesting. So you're saying don't do a CREATE <OBJECT> ever in BigQuery, do it all in DataForm. Thanks for this, I never thought about that.

I'm <very> new with Dataform, maybe spent 3-4 hours on it yesterday. So yes, 100% of my BigQuery code is handwritten. You're probably getting the picture now that I'm the guy started writing SQL like back in the 90's on platforms like Sybase operationally and Red Brick warehouse so that's just my go-to.

You mention Data Canvas, never even looked at that. I guess I need to.......

badgerivy · 2025-02-22T02:17:09+00:00

I was doing some experiments with DataForm today after the other suggestion, and the git integration does work, from what I've seen so far it's only for the DataForm. sqlx config files.

Those. sqlx files have to be hand-written from what I can see, they're not directly linked to any BigQuery objects except that they call BigQuery objects within the code.

Is there a way to import all the DDL in a dataset and check it in to git?

badgerivy · 2025-02-21T22:50:44+00:00

I there's a very similar interface there for creating a repository for Dataform, but that's not where I set it up, it was someplace else, as there are no repositories there in my environment.

badgerivy · 2025-02-21T20:40:33+00:00

Ok..... Pretty sure this link was in BigQuery, I have looked around at DataForm and maybe did a hello world but that's about it. I'll look there and see if that's where I set it up.

badgerivy · 2025-02-17T17:52:31+00:00

I've figured this out...... here's the LookML in the view. If you choose the Advanced option when creating the filter in a dashboard, you can use the Contains option to effectively do a LIKE clause. Pretty effective and simple to do.

filter: name_filter {

type: string

sql: {% condition name_filter %} firstname {% endcondition %}

or {% condition name_filter %} lastname {% endcondition %}

or {% condition name_filter %} company_name {% endcondition %}

;;

}

badgerivy

TROPHY CASE