There will be no singularity

Сейчас будет скучный пост про стартапы и бизнес, Потому что в ChatGPT вчера добавили поддержку PDF файлов

(при чем тут это?)

При том, что десятки инди-стартапов вчера дружно построились и пошли умирать. Все эти pdf.ai, ChatPDF, AskYourPDF внезапно стали не нужны.

Прикольно, что все это очень смахивает на историю с Amazon Basics.

Вы же в курсе, как работает Амазон? Если они в аналитике видят выстреливший продукт от независимого поставщика - они быстро его клонируют и выпускают под брендом Amazon Basics. И впихивают свой клон в топ поиска. А потом наваливаются всей своей логистическо-ритейлово-маркетиноговой мощью. Оригинальный продукт через месяц умирает.

За это их много раз таскали по судам, антимонопольным разбирательствам и даже на слушания в Конгрессе. После чего они... просто научились лучше прятаться. Теперь копии продаются под "независимыми" фейковыми брендами.

Если вы делаете тупой враппер для GPT в горизонтальной нише - OpenAI убьет вас так же, как Amazon Basics убивает инди-ритейл. Я почти уверен, что они посматривают на свою API-аналитику и как только видят где-то "хоккейную клюшку" и легко реплицируемый продукт - добавляют его в виде фичи.

В английском бизнес-жаргоне пару лет назад стал популярен классный термин "moat". Буквальный перевод - "крепостной ров". Moat - это то, что защитит вас от конкурентов и platform-риска. Это ваш момент импульса (тот самый, который не дает гироскопу отклоняться от оси). Moat - это то, почему нельзя просто взять и скопировать бизнес-модель. Это не обязательно фича продукта - возможно это преданная аудитория. Или вы "go to" бренд в своей нише. А возможно ваш продукт плотно и незаметно интегрируется в критические бизнес-процессы клиента, и слезть с него тупо невозможно. Ну или вы - AWS и берете такие баблищи за траффик что переезжать очень больно.

Если у вас нет moat - бизнес под угрозой.

В общем, хватит пилить врапперы для ЖПТшки.

Пилите врапперы "with a twist". Ну, например, я не знаю, "PDF-чатилка для адвокатов да еще и совместимая с GDPR".

AI is a feature, not a product ☝️

I wrote an article about the Snowflake update and how startups are getting screwed by it, but my graphomania didn't fit into the damn LinkedIn, so I had to split it into three.

I won't torture you here either, so here's a link to the whole article:
https://dwh.dev/blog/startup-killers

and you can like it on LinkedIn here, here and here (please).

There's just an article from Alex on the same topic (forward next post).

"What are you going to do if Snowflake (Amazon, Google, name it) do the same thing?" - every investor's favorite question...

Scalar functions name resolution special behavior in Snowflake.

I never get tired of repeating that writing a universal compiler for different SQL dialects is impossible.
Today, I will tell you about the behavior of name resolution in Snowflake inside CREATE VIEW.

When you execute queries, Snowflake looks for the objects specified in the query in the schemas specified in SEARCH_PATH. You can check them like this:

SELECT current_schemas();

But it seems like a good idea to make the creation of VIEWs independent of SEARCH_PATH. Otherwise, we will get different results when we work with VIEWs at different SEARCH_PATH.

The documentation says the following:

The SEARCH_PATH is not used inside views or UDFs. All unqualifed objects in a view or UDF definition will be resolved in the view’s or UDF’s schema only.

That's great! And it works!

CREATE OR REPLACE DATABASE db1;
CREATE SCHEMA sh1;

CREATE TABLE public.t1(c1 int);

CREATE VIEW sh1.v1 AS
SELECT * FROM t1;

will return

SQL compilation error:
Object 'DB1.SH1.T1' does not exist or not authorized.

And not only for tables. For any objects, except … scalar functions!

CREATE OR REPLACE DATABASE db1;
CREATE SCHEMA sh1;
CREATE TABLE sh1.t1(c1 int);
INSERT INTO sh1.t1(c1) VALUES (1);

CREATE FUNCTION public.test()
RETURNS NUMBER
LANGUAGE SQL
AS '1';

CREATE VIEW sh1.v1 AS
SELECT *, test() c2 FROM t1;

SELECT * FROM sh1.v1;

will return

C1 C2
1   1

Strange behavior, don't you agree?

In PostgreSQL, for example, it works like this: when creating a VIEW, all objects without schema specification are searched in the public schema. If you want a different schema, specify it by hand.

But maybe I'm being picky? Let's add one more thing…

CREATE FUNCTION sh1.test()
RETURNS NUMBER
LANGUAGE SQL
AS '2';

SELECT * FROM sh1.v1;

will return

C1 C2
1  2

Oops… If there is a scalar function in the schema where VIEW is created, it will be used. If not, the function from PUBLIC will be used.

I.e. if you didn't specify a schema for a scalar function from the PUBLIC schema while creating a VIEW, in a schema other than PUBLIC, then to corrupt the data in your database it is enough to create a function with the same name in the corresponding schema…

At dwh.dev, we know about a lot of these nuances. So you are unlikely to find a better data lineage for Snowflake 🙂

linkedin likes goto https://www.linkedin.com/feed/update/urn:li:activity:7132776122580152320/

- Anti-pattern #1. Using exotic databases for the wrong reasons

- Anti-pattern #2. Caching things unnecessarily

- Anti-pattern #3. Storing everything and a kitchen sink
. . .
Most importantly, study your database (and SQL). Learn it, love it, use it, abuse it. Spending a couple of days just leafing through that Postgres manual to see what it can do will probably make you a better engineer than spending more time on the next flavor-of-the-month JavaScript framework hotness. Again.

YOUR DATABASE SKILLS ARE NOT 'GOOD TO HAVE'
https://renegadeotter.com/2023/11/12/your-database-skills-are-not-good-to-have.html

Who is in Spain?

https://www.meetup.com/devmad/events/297277747/