Нужен веб-программист (фронт-енд) энтузиаст в Open Source проект ($0)

По моим прикидкам, дел на 2-3 вечера под настроение и тихую музыку.

В чём проблема заплатить за них символические 10-15 тысяч рублей?

Поправь, где не так. Ты подогнал некую базу данных под задачу при этом сделал некий биндинг python expr <=> sql с помощью sqlalchemy, представил это в виде api и запихал это в докер? Если да, то в чем смысл?

Мне кажется, как только в фанатском проекте возникают деньги, сразу многое меняется:

1. Мое восприятие. «Это уже не проект для фана, я уже проинвестировал деньги». Теперь надо как-то их отбивать, да и почему 15, лучше бы 10… или даже найти кого-нибудь похуже, зато за 5. А я в целом на этом (очень раннем) этапе не уверен в его успешной монетизации. У меня нет цели «сжать зубы и достичь цели», а цель легко и красиво и в удовольствие сделать что-то прекрасное само по себе, и если оно будет востребовано - хорошо, но и без этого - тоже хорошо.

2. Восприятие программиста. Самомотивированный программист - гораздо лучше работает если идея привлекает, хочет сделать очень хорошо, не просто уложиться в ТЗ, а предложить свои идеи, покритиковать задумку, итд. Но вот когда программист работает за деньги - он заинтересован как-то быстрее на изоленте все сделать, запинать, уложиться в ТЗ, получить оплату. (Сам фрилансил иного и иногда и такое бывает). При этом вряд ли предложит «а давай еще вот эту фишку сделаю, будет лучше» (Зачем создавать себе работу, если хочется денег, а проект бесплатный? Разве что будет предлагать фичи чтобы сделать их за деньги, но тогда не факт, что фичи полезные).

3. Скорее всего, специалист с такими навыками и ценностями, и для других проектов подойдет (один из которых может как-то «выстрелить»). Я, например, много фриланс проектов получил хвастаясь тем, что я со-разработчик ядра Линукса (да, маааленькую часть написал, но это впечатляет заказчиков).

Мне хочется не столько аккуратного исполнителя, сколько сообщника, которому тоже интересен IT-авантюризм, с 99% шансами на неудачу, и 1% шансами «сорвать банк».

По крайней мере бэк написан фанатом (мною) за эти же $0 под настроение без четкой цели. Человек похожий на меня в этом - меня абсолютно устроил бы.

Для меня этот проект (как и многие другие хобби-проекты) во многом игра, охота за удачей: что-то сделать, посмотреть, что получилось, какие ошибки, что переделать. Взлетит, не взлетит. Иногда сложные и ценные (на мой взгляд) проекты не взлетают, а иногда пустячные развлекательные вдруг сильно привлекают людей.

Вот как в той притче про строительство собора, моя мотивация здесь: «Мне нравится отесывать камни» + «Я строю собор», а вот «я зарабатываю на жизнь» - этой мотивации нет, зарабатываю я на более скучных и малоперспективных проектах :-)

Снесут тему, потому что она не подходит под правила раздела.

Есть профильный тред - Поиск работы за еду для повышения квалификации

Есть раздел форума - Development, где можно в том числе немного описав задачу попросить помощи.

И так и не так, «expr <=> sql» там нету. Exact либо читает данные из JSON/YAML (а они могут быть созданы на основе данных из базы), либо читает их (при старте) из базы, делая нужный SELECT. После поднятия API уже никакой работы с базой нет совсем (и это важно).

Это не заточено ни под какой формат базы, можно использовать и для магазина хозтоваров и для сайта знакомств и для атласа звездного неба и для поиска авиабилетов - любой поиск по любым данным, с возможностью любых сложных запросов (ноутбук с экраном >17" до 100 000, но не Acer, хотя если ноут до 30 000, то можно любого бренда).

Например, тестил на данных с букинистического сайта, узнал, что самый дешевый товар (книга, брошюра, …) выпущенный до 1900 года у них стоит всего 5 евро!

Идея возникла из осознания сочетания двух фактов:

• простой поиск по списку с фильтрацией через eval() в Python - охренительно быстрый. Настолько быстрый, что перебрать миллион записей занимает 200 миллисекунд.
• eval() можно сделать безопасным.

Что это дает:

Скорость разработки

При разработке нового проекта не надо делать свой поиск с сложными запросами (и возможными уязвимостями). Просто запустил Exact в докере и все готово. Время на разработку поиска (очень гибкого (можно ли гибче?) и быстрого) - около нуля. Один бэкенд на почти любой проект. Нужно только во фронте прописать эти поля и отрисовать контролы (типа слайдера, двигать мин-макс цену) соответствующие проекту. Посетитель на сайте ведь хочет кнопочки-крутилочки, а не питоновские выражения.

Безопасность

Гарантированная безопасность. Никаких там SQL Injection или broken authentication - Все данные, которые доступны Exact’у - публичные. (Даже если все сольют - не страшно, это все и так на сайте есть). А те, которые недоступны - до них Exact и сам добраться не может, даже если и будет взломан.

Поиск, кмк, одна из самых коварных задач, так как там больше всего шансов сделать уязвимость. Если поиск изолирован, тогда остальные страницы проекта достаточно примитивны и, следовательно, более безопасны.

Нагрузка и защита от DoS

Нагрузка на Exact не дает нагрузки на саму базу данных. Ни при штатной высокой нагрузке (например, в черную пятницу), ни при DoS атаке через Exact - сама СУБД работает как и раньше. В худшем случае (всего 1 слабый сервер для поиска) - ляжет поиск, но база будет обслуживать простые легковесные запросы, продажи будут работать.

Есть раздел форума - Development, где можно в том числе немного описав задачу попросить помощи.

Не знал про это, спасибо. Да, если снесут (и никого не найду к тому времени) - там отпишусь

и никого не найду к тому времени

Не найдёте. )

Я посмотрел репозиторий, почитал ваши большие сообщения и совсем не понял зачем это может пригодиться. Думаю фронтендеров такая постановка вообще не впечатлит.

Поэтому тут не обсуждать проект надо и красивую веб-морду, а просто сформулировать хотя бы минимальные требования для этой самой морды. А лучше нарисовать её в фигме, да и самому накидать в тильде.

похожую на веб-магазин или маркетплейс типа Озона

2-3 вечера под музыку? Ну-ну ))

Upd. Ну, выделите вы под это дело 2000 - 5000 руб., да попытайте счастья, хоть на том же фрилансиме.

зачем это может пригодиться

Критика тоже ценна.

Если вам нужно сделать, скажем, сайт (фронт+бэк), например, аналог IMDB с продажей/прокатом фильмов, как бы вы решили задачу хорошего, гибкого поиска (например, чтобы можно было узнать, «в каких фильмах вместе с Одри Хепберн снимался еще ДеНиро или Джек Николсон, были ли такие» или «Какие цветные фильмы до такого-то года, в жанре комедии снимались в городе X?»).

Сколько времени на разработку такого поискового бэкенда вы бы запросили? (с отладкой, поиском уязвимостей, чтобы через него гарантированно нельзя было бы оформить себе покупку или прочитать данные о клиентах из другой таблички или нагрузить базу сложными запросами)

Как-то слишком многословно оформлен классический текст «мы уважаемая компания, сто лет на рынке, сделайте тут нам забесплатно и может быть мы когда-нибудь подкинем вам работы за еду».

Вот опять тонна слов и ннп, чем тебе sql не угодил и нкх нужна вся эта груда дерьмятины.

Какой-то бред…

Если ты хочешь найти энтузиаста который подключится к развитию проекта, то ты должен рассказывать не про себя, а про проект. Объясни для чего этот проект, какие цели он ставит, какие проблемы решает. Затем расскажи про архитектуру с диаграммами, в лучших традициях корпоративных wiki. В общем продай свой проект публике. И только в конце расскажи что не хватает для успеха, в этом месте можешь делать упор на нехватку достойной frontend к проекту. Дальше обращаешься к публике намеками – «вот бы было хорошо, если бы нашелся разработчик на vue или react в нашу веселую компанию».

А текущее полотно написанного текста можешь отправить в мусор, потому как сейчас это похоже на письмо африканского принца.

Ну как-то не принято вроде как из фронтенда SQL принимать и исполнять по ряду причин. ;-)

Я выше привел пример про ДеНиро. Получаем гибкость, как если бы юзеру дали доступ в mysql, но безопасно и за полминуты.

А где еще можно найти желающих для таких вот фанатских некоммерческих проектов?

То есть где еще дураки водятся, готовые вкладывать свое время и силы в чужое предприятие задаром? Почему ты не ищешь людей, готовых вложить свои деньги в твою затею, чтобы заработать на ней? Если дело нужное людям, то денежки ты найдешь без затруднений. А затем уже наймешь увлеченных программистов на эти деньги. А сейчас выходит, что свою недоработку с поиском денег ты пытаешься взвалить на программистов. Им и так непросто работается, когда код не работает большую часть времени.

Получаем гибкость

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

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

Это да. Но может не обязательно так уж на каждый чих? Скажем, есть у нас магазин, продаем 1000 товаров, количество на складе при каждой покупке меняется (и иногда становится равным 0). Базу каждый раз экспортировать не хотим, понятное дело. Как быть?

Вариант 1 (мне кажется, не самый оптимальный)

Переформировываем не на каждый чих, а когда какой-то товар кончился на складе (или появился снова).

Вариант 2 (мне больше нравится)

Ассортимент меняется редко, данные для поиска мы не меняем. Когда посетитель что-то ищет, получает результат поиска (без учета наличия) и обращается к «обычному» API для тривиальной операции проверки наличия товаров по SKU из списка.

Причем, если мы хотим вообще разгрузить базу, то можем где-то (redis?) держать список что у нас в наличии.

В результате, для получения гибкого поиска по актуальным данным нам (на бэке) потребуется просто реализовать простую функцию проверки наличия и все.

Но вообще, вы дали интересную идею, подумаю, может быть как-то это можно с Exact интегрировать, чтобы «отключать» некоторые записи (например вот товары, которых нет на складе). Правда, тогда это уже получится целая in-memory database, а хотелось что-то более простое, легкое и unix-way’ное.

Им и так непросто работается, когда код не работает большую часть времени.

Именно по этой причине, чтобы помочь бедным программистам, я совершенно бесплатно и написал этот проект и выложил его под открытой лицензией, чтобы они не мучались с реализацией поиска, а брали готовое, работающее, совершенно бесплатно и с исходными кодами.

Можете взять с заказчика пару килобаксов на реализацию поиска, и за 2 минуты запустить поиск на Exact. Я тот дурак, который за вас его написал и разрешаю вам использовать это (даже рад буду, если мой проект окажется вам полезен).

Можете даже форкнуть репозиторий, назвать любым другим именем и продавать этот продукт (или его поддержку) за деньги - лицензия все это вам позволяет.

Мне вот совсем неочевидно преимущество вашего формата поискового запроса перед SQL, а для последнего in memory на питоновских объктах есть, например быстрым поиском нашёл, https://github.com/ptmcg/littletable

Т.е. получается есть, кто в этом направлении движется.

Вы предлагаете делать поисковый API с интерфейсом вроде /search?q=SELECT * FROM products что ли? (а на бэкенде просто исполнять любой полученный SQL)

Он будет очень гибким, ничем не хуже Exact, но сами же понимаете, почему его нельзя ни в коем случае использовать?

Про littletable бегло посмотрел, может быть я не совсем его понимаю, но мне он показался альтернативой pandas, много что может, но главное с ним работает программист, а не внешний пользователь. Чтобы сделать сортировку по цене, скажем, нужно чтобы в коде было записано вроде:

catalog.where(lambda o: o.unitprice > X):

То есть, для littletable нужно чтобы заранее на бэке были в коде реализованы все возможные виды поиска (по цене от минимума, по цвету, по цене и цвету). А если пользователь захочет искать по цене от минимума до максимума? (майку от 300 до 1000 рублей), а у нас в коде этого нет…

// Это я говорю на основании двухминутного знакомства с README, может там есть и другие функции.

Если программист при создании системы не предусмотрел, что кто-то может хотеть искать фильмы по наличию актеров - то этого типа поиска и не будет. А с Exact - любой поиск будет (примерно, как при q=SELECT…), но без ущерба для безопасности.

для littletable нужно чтобы заранее на бэке были в коде реализованы все возможные виды поиска (по цене от минимума, по цвету, по цене и цвету).

В Exact все они уже реализованы?

если пользователь захочет искать по цене от минимума до максимума? (майку от 300 до 1000 рублей), а у нас в коде этого нет…

В Exact есть такой поиск?

Посмотрел репозиторий и не вижу существенного отличия category=="smartphones" and price>1 and price<1000 and brand in ["Apple", "Samsung"] and "retina" in description.lower() от SQL/NoSQL запроса. Учитывая что эту строку пользователь не будет писать сам и программисту (возможно этим и будет заниматься фронтендер) придется ее получать из его хотелок, так что непонятно в чем преимущество фронтендеру каждый сайт настраивать на этот синтаксис Exact-a, а не писать тоже самое обычными запросами к SQL.

В Exact все они уже реализованы?

Примерно так же, как в MySQL. Там ведь нет конкретной реализации «поиска маек цвета X с максимальной ценой не выше Y», там есть просто SELECT … WHERE … .

Я не знаю, как классифицировать Exact, может быть его предназначение будет понятнее, если назвать его как-то вроде «anonymous (no-auth) read-only database» куда вы открываете доступ всем, и ничем не рискуете.

В некотором приближении можно сказать, что подход Exact’а аналогичен тому, как если бы мы на бэкенде делали «SELECT * FROM tableName WHERE $query». (query может быть «color=‘red’ and price<100» или «year<2000 and salary>1000»)

А вот отличия в том, что делать SQL запросы свободного формата на основании недоверенных входных данных - опасно. SQL Injection, все такое. Открыли пользователю доступ, чтоб он майки искал, а он себе баланс на счете увеличил до квадриллиона долларов. А вот передавать любое выражение в Exact - заведомо безопасно.

Выше в треде мой пример с «ДеНиро» - представьте, что вам нужно написать API для поиска с такой вот гибкостью - как бы вы поступили, сколько времени-денег это бы стоило. Вот этот же эффект можно достичь за минуту с экзактом.

чем преимущество фронтендеру каждый сайт настраивать на этот синтаксис Exact-a, а не писать тоже самое обычными запросами к SQL

Вы имеете в виду, «почему нельзя выполнять SQL команды, полученные от хакера»?

Открыли пользователю доступ, чтоб он майки искал, а он себе баланс на счете увеличил

Нарезку прав доступа в РСУБД еще ж не изобрели, конечно.

Нарезку прав доступа в РСУБД еще ж не изобрели, конечно.

Много вы знаете таких проектов, где бы в мир был открыт SQL, а внутри все правами доступа СУБД ограничивалось?

Да уж побольше, чем использующих этот вот «exact».

Да уж побольше, чем использующих этот вот «exact».

Если бы вы сказали «не меньше» - я бы согласился (ибо 0=0), а чтобы «побольше»… даже вот не уверен. При том, что этот exact неделю назад даже я не использовал. Примем его «используемость» как 0. Значит больше - это 1.

Один более-менее известный реальный проект, пускающий анонимный SQL в базу с чувствительными данными (но защищенными через права доступа РСУБД) такой могли бы назвать? Не надо много, одного хватит. Всего один. 1. Ну один, а? Ну пожааалуйста? :-)

Просто у меня все мировоззрение рухнет, если вдруг окажется, что люди SQL в мир открывают. Я много удивительного в жизни видел, но такое вот увижу только сейчас.

https://www.ensembl.org/info/data/mysql.html

Первое, что нашлось в гугле.

А теперь ты вышли мне свою фотку с клоунским носом, раскраской и париком на голове. Тебе всего делов-то - до телефона дотянуться.

Если вам нужно сделать, скажем, сайт (фронт+бэк), например, аналог IMDB с продажей/прокатом фильмов, как бы вы решили задачу хорошего, гибкого поиска (например, чтобы можно было узнать, «в каких фильмах вместе с Одри Хепберн снимался еще ДеНиро или Джек Николсон, были ли такие» или «Какие цветные фильмы до такого-то года, в жанре комедии снимались в городе X?»).

Я бы взял бы elasticsearch или solr и считал бы для них индексы на spark или hadoop.

Я прям представил ситуацию, что прихожу на собес по архитектуре и там рассказываю как сгружу все в память и буду дергать код пользователя через eval для поиска.

Можете даже форкнуть репозиторий, назвать любым другим именем и продавать этот продукт (или его поддержку) за деньги - лицензия все это вам позволяет.

Опять ты пытаешься переложить ответственность за прибыльность проекта на другого человека. Если твой код такой продаваемый, то почему ты жалеешь денег на оплату услуг программистов?

И в «Майкрософте» совсем дурни сидят да, если нанимают толпы программистов на завышенные зарплаты, когда можно просто надергать исходников с «Гитхаба», быстренько их собрать и продавать, продавать, продавать?

Неужели ты считаешь, что ответственный человек, вкладывающий в проект, скажем, десять миллионов рублей будет использовать какие-то исходники с «Гитхаба», написанные неизвестно кем? Ты тесты писал вообще? За такие деньги гораздо спокойнее будет свое решение написать под свои требования с предсказуемым результатом.

А это было бы интересное сравнение!

Я бы взял бы elasticsearch или solr и считал бы для них индексы на spark или hadoop.

Это детали, а если к главному: Представим это как фриланс проект. За сколько времени-денег вы бы это сделали? Сколько выставлять счет заказчику?

На собесе, наверное, я бы тоже, что-то подобное предложил - там ведь цель, продемонстрировать знание кунфу, айкидо и других страшных слов. Но во фрилансе, если заказчик платит сам (или, тем более, вы и есть заказчик) важно время и деньги.

Если это под рукой есть - давайте замерим, как будет работать? Не только чтоб поспорить-доказать, а и просто из интереса. Можно на вашей базе. С exact это так просто и легко, что я могу для интереса с этим поиграться.

Мне это особенно интересно потому, что в Exact даже индексами и не пахнет, он работает достаточно тупо, пробегая по миллиону записей, но вот бегает на удивление быстро. Возможно технологически RAM/CPU выросли настолько, что полный перебор миллиона кортежей оказывается вполне быстрым. Или пайтон (вроде бы не самый быстрый язык) свой байт-код так быстро исполнять умеет… Единственный рокет-сайнс там - валидация AST-деревьев, и eval() уже скомпилированного питон-кода. Мне было бы интересно узнать, чье кунфу сильнее в цифрах и насколько.

буду дергать код пользователя через eval для поиска

До evalidate/simpleeval/asteval дергать eval() с кодом пользователя вообще было небезопасно. Примерно как посылать в базу SQL запросы от юзера. Эта причина уже давно в прошлом, сейчас, чтобы избегать eval, нужны какие-то новые причины.

Один более-менее известный реальный проект, пускающий анонимный SQL в базу с чувствительными данными (но защищенными через права доступа РСУБД) такой могли бы назвать?

Если я правильно понял, эксакт принципиально не умеет в авторизацию, а значит пускать анонимных пользователей к чувствительным данным тоже не может.

Чем это тогда принципиально отличается от read-only реплики БД, например?

Да, по большому счету - никакой авторизации. (На самом деле, сейчас вот думаю, что нужен простой метод для минимальных обновлений с авторизацией по токену, чтобы «отключать» некоторые записи из списка, например, когда они кончились на складе. Но для простоты отбросим это)

По степени защиты главной базы данных - думаю, read-only реплика даст такой же параноидально-высокий уровень защиты. (Полагаем, что у нее нет доступа в главную базу, в нее данные пихаются, а не она их вытягивает, имея логин-пароль, иначе это небезопасно)

Но дальше подход с репликой возвращает к некоторым тем же проблемам - нам нужно все таки писать относительно безопасный поисковый API, который будет работать с базой и поддерживать в том числе очень сложные запросы? (но реплика снижает потери, если вдруг в нем будет уязвимость) Или в самом деле работаем через q=SELECT ... WHERE ...?

Ну и главный тест вопрос - как вы оцениваете трудоемкость этой задачи (репликация базы + какой-то поисковый бэкенд) в деньгах-времени? Мы же тут все программисты, все могут все сделать, хоть свой вебсервер написать, вопрос в сроках и стоимости. Задача «запустить докер образ с простой конфигурацией» явно ведь проще и дешевле.

Реплика — это пара кликов в AWS консоли. Дожили, да.

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

Я бы не стал работать с ТС даже за деньги . Судя по количеству слов в его постах, он будет знатно выносить мозг потоками сознания.

Ох уж этот ЛОРчик. Чечил пришёл с идеей и предложил под пивасик чёт там накидать по-быренькому, как тут же слетелись матёрые профессионалы, которые одним усилием мысли создают корпорации, и всё засрали. Классика.

Просто, если твой язык настолько же гибкий как SQL, то пользователь сможет легко положить базу на лопатки через джойны и сортировки по неиндексированным полям, например

Это не мой язык, это Python. Демо сервер запущен на супер-слабом бесплатном контейнере на https://www.back4app.com/. (иногда он спит, дерните второй раз через 10 секунд, проснется) Можете попользоваться (ниже команда для httpie):

http POST https://exact-yaroslaff.b4a.run/search/dummy 'expr=price<100 and rating>4.0'

Если положите на лопатки, или взломаете - буду даже благодарен. Ну и там все поля неиндексированные, там в принципе нет никакой индексации.

Да, на англ. форумах можно про микро-утилитку из 5 строчек написать, и все будут «вандефул» и все такое говорить. У нас народ суровый! Но пару фишек все-таки подсказали (vvn_black, спасибо), подкручу кое-чего, не зря зашел!

Это детали, а если к главному: Представим это как фриланс проект. За сколько времени-денег вы бы это сделали? Сколько выставлять счет заказчику?

Я не беру фриланс проекты, а если беру то с почасовой оплатой и проекты уровня imdb обычно не делают фрилансеры. Там скорее всего есть команда, которая им занимается на постоянной основе. Сделать mvp в первом приближении можно за пару дней, а допиливать до бесконечности.

Если это под рукой есть - давайте замерим, как будет работать? Не только чтоб поспорить-доказать, а и просто из интереса. Можно на вашей базе. С exact это так просто и легко, что я могу для интереса с этим поиграться.

Ну смотрите в imdb 500 млн тайтлов https://www.imdb.com/pressroom/stats/ даже если вы сложите все в оперативку у вас скорее всего больше минуты выполняться будет. Под рукой нету, но по ключевым словам можно найти кучу e-commerce, в которых такой подход используется(например японский rakuten). Думаю в районе 0.5с запрос выполняться будет. Но дело не только в скорости, а в том что обычно при поиске нужно искать не просто точное вхождение слова, а наличие в тексте других словоформ, когда вы берете elasticsearch у вас из коробки это есть + horizontal scalability + high availability.

Мне это особенно интересно потому, что в Exact даже индексами и не пахнет, он работает достаточно тупо, пробегая по миллиону записей, но вот бегает на удивление быстро.

Если гляните реализации сортировок и бинарного поиска в стандартной библиотеке популярных ЯП, то там обычно есть threshold порядка 10 элементов, где вместо продвинутых сортировок и бин поиска используют сортировку вставками и линейный поиск потому что так быстрее.

Я программирую за 20 русских руб в час.

Есть готовый, мной написанный поисковик.

Тебя не хватало.

С возвращением!

Чем писать «русских руб» используйте иероглиф ₽.

Внушительный послужной список, а звёзд на лоре нет. Странно.