Сеньор, который не пользуется опытом других, может конечно и сеньор, но обычно по ряду факторов (не по знаниям) в большей части компаний будет считаться плохим вариантом для найма.
Да запятые эт отдельная тема для холивара. Те же trailing запятые (не в SQL, но к примеру в js) кто-то любит, кто-то нет (я). Кто-то для избавления от trailing запятых начинает добавлять leading запятые, примерно как в посте (не я).
Тут и люди с отступами табами могут повозмущаться.
Идея вертикальной линии мне в целом нравится, если редактор или IDE будет уметь это делать автоматом. Если нет, можно и не заморачиваться на мой взгляд.
Я бы в первую очередь рассмотрел проектирование API в широком смысле, без привязке к какому-либо протоколу передачи данных, будь то http по tcp/ip или обычный вызов функции.
Если мы берём API с одной функцией, вы просто хотите взять набор данных X и получить в ответ набор данных Y или сведения об ошибке, а так же, возможно, добавить какой-то сайд эффект, например, модификацию данных.
В этом смысле условный User GetUser(int id) и GET /users/{id} решают одну и ту же задачу.
Далее у вас есть вполне очевидное требование, что consumer и provider это не части одной программы и даже не находятся на одной машине.
Поэтому вы выбираете последовательно протоколы на 4-7 уровнях OSI. Обычно всё сводится к TCP/IP и HTTP. И в этот самый момент, если у вас есть человек, отвечающий за архитектуру, стоит выбрать какой-то стандарт, который вы будете использовать. Вы можете остановиться на REST, добавить к нему JSON API, или же можете взять GraphQL. Возможно вам нужно своё решение. В редких случаях, стандарт трудно принять или практически невозможно, но частично стандартизировать что-либо можно, например способ именования параметров или ещё что-либо.
Далее, если выбранный стандарт имеет достаточно хорошие соглашения и у фронта есть понимание, что в апи не будет никаких подводных камней, то возможно, что фронт может сам предоставить спецификацию апи. К примеру, это хорошо работает для всяких простых CRUD эндпойнтов. Но в любом случае со стороны бэкэнда должна быть проверка этой спецификации. Так же хорошие соглашения позволят обнаруживать фронтэнду уже существующие эндпойнты, которые могут помочь им решить их задачу.
Если же бэкэнд достаточно сложный, то фронтэнд спректировать апи не может, и всё, что может сделать фронтэнд, это дать бэкэнд разработчикам input и ожидаемый output и попросить апи, которое им предоставят. Вот тут вероятно то, что концептуально выглядит как одна функция на фронтэнде, может превратиться в более чем один вызов функции (а в вашем случае в несколько HTTP запросов), либо, в целях оптимизации, в новый и сложный эндпойнт, который делает то, что вам нужно за один вызов. И вот тут, если вы используете достаточно хороший стандарт, спецификация может оказаться лучшим языком общения. А может и не быть им.
В общем случае, фронтэнд разработчик может предложить спецификацию АПИ как способ выразить свои требования по инпуту и аутпуту при хорошей стандартизации этого апи, но финальное слово за бэкэндом, ибо только они знают все ограничения бэкэнда и лучший путь реализовать требования фронтэнда.
Нужно ли для такой коллаборации специальное решение? Не уверен. Но и критиковать ваш проект я не готов.
Познакомился с SOPS благодаря Helmfile и helm-secrets. Было легко настроить и очень удобно использовать. Плюс очень быстро вникаешь в это всё. Поэтому согласен с автором.
В Воронеже много айти компаний и хорошие зарплаты в айти, при сравнительно невысокой стоимости жилья и невысокой средней зп в других отраслях. Иными словами, переехав в Воронеж, будет гораздо больше оставаться денег, чем в других городах.
При этом Воронеж - город-миллионник, есть достаточно много всяких развлечений, событий. Немало парков и скверов хотя хотелось бы больше. Да, конечно всего этого сильно меньше, чем в Питере или Москве. Но Москва недалеко (6 часов сидячий поезд, 4 часа на машине по трассе или час на самолёте), туда периодически можно гонять. До Питера 2 часа на самолёте, и это относительно недорого. Иными словами, можно жить спокойно, но при этом иметь большинство плюсов Москвы/Питера в том или ином виде.
Город так же сильно меньше Москвы/Питера, поэтому вполне можно жить за чертой города в домике, но при этом не быть сильно далеко от цивилизации (час езды в худшем случае, если нет сильных пробок). Либо можно жить в городе очень близко ко всем необходимым объектам.
И в целом город развивается, правда и жильё дорожает, особенно новостройки, особенно элитные.
Есть, конечно, и минусы. Ситуация на дорогах не очень, хотя для общественного транспорта ввели выделенные полосы и она улучшается. Плюс не назвал бы город чистым, но стало чуть лучше. Ну и я бы сказал что после 10 вечера город относительно вымирает, народ либо тусит и пьёт, либо сидит дома. Общественного транспорта после 10 сильно меньше (сравниваю с тем же Питером). Но такси круглосуточно и ехать вряд ли нужно будет сильно далеко.
Не уверен, что есть смысл полностью уходить с Firebase. Их авторизацию можно использовать без всего остального, и она очень удобна на мой взгляд.
Если говорить про базы, то да, если вам нужны ACID транзакции, Firebase базы уже становятся не лучшим решением. Но это всё про бизнес требования и их решения. Вы скорее всего пропустили нужный момент миграции. Но частично эти проблемы можно решить с помощью cloud functions и state машин. Собственно мы это и делаем, но проект небольшой.
Резюмируя - Firebase не так плох, но нужно понимать, когда его перестаёт хватать. Он и правда хорошо экономит на старте.
Удвоение зарплаты не действует в некоторых крайних точках, вы правы. Туда можно отнести и 0х2=0, и что 1000 или 2000 рублей в месяц разницы не сделают. И что х2 зп на пару месяцев перед пенсией ничего существенно не поменяет.
Но если мы возьмём обычного человека, зарплата которого находится между половиной от реального прожиточного минимума и до той зарплаты, которая сможет обеспечить абсолютно все его потенциальные хотелки, то выражение верно и покрывает ситуацию почти всех людей.
Сеньор, который не пользуется опытом других, может конечно и сеньор, но обычно по ряду факторов (не по знаниям) в большей части компаний будет считаться плохим вариантом для найма.
Я как-то такую форму (had forgave) в песне услышал, очень удивился.
Да запятые эт отдельная тема для холивара. Те же trailing запятые (не в SQL, но к примеру в js) кто-то любит, кто-то нет (я). Кто-то для избавления от trailing запятых начинает добавлять leading запятые, примерно как в посте (не я).
Тут и люди с отступами табами могут повозмущаться.
Идея вертикальной линии мне в целом нравится, если редактор или IDE будет уметь это делать автоматом. Если нет, можно и не заморачиваться на мой взгляд.
Туркменистан вроде не лучше, если говорить об аналогах. Но могу и ошибаться, ибо глубоко не вникал. По остальной части с вами согласен.
Я бы в первую очередь рассмотрел проектирование API в широком смысле, без привязке к какому-либо протоколу передачи данных, будь то http по tcp/ip или обычный вызов функции.
Если мы берём API с одной функцией, вы просто хотите взять набор данных X и получить в ответ набор данных Y или сведения об ошибке, а так же, возможно, добавить какой-то сайд эффект, например, модификацию данных.
В этом смысле условный User GetUser(int id) и GET /users/{id} решают одну и ту же задачу.
Далее у вас есть вполне очевидное требование, что consumer и provider это не части одной программы и даже не находятся на одной машине.
Поэтому вы выбираете последовательно протоколы на 4-7 уровнях OSI. Обычно всё сводится к TCP/IP и HTTP. И в этот самый момент, если у вас есть человек, отвечающий за архитектуру, стоит выбрать какой-то стандарт, который вы будете использовать. Вы можете остановиться на REST, добавить к нему JSON API, или же можете взять GraphQL. Возможно вам нужно своё решение. В редких случаях, стандарт трудно принять или практически невозможно, но частично стандартизировать что-либо можно, например способ именования параметров или ещё что-либо.
Далее, если выбранный стандарт имеет достаточно хорошие соглашения и у фронта есть понимание, что в апи не будет никаких подводных камней, то возможно, что фронт может сам предоставить спецификацию апи. К примеру, это хорошо работает для всяких простых CRUD эндпойнтов. Но в любом случае со стороны бэкэнда должна быть проверка этой спецификации. Так же хорошие соглашения позволят обнаруживать фронтэнду уже существующие эндпойнты, которые могут помочь им решить их задачу.
Если же бэкэнд достаточно сложный, то фронтэнд спректировать апи не может, и всё, что может сделать фронтэнд, это дать бэкэнд разработчикам input и ожидаемый output и попросить апи, которое им предоставят. Вот тут вероятно то, что концептуально выглядит как одна функция на фронтэнде, может превратиться в более чем один вызов функции (а в вашем случае в несколько HTTP запросов), либо, в целях оптимизации, в новый и сложный эндпойнт, который делает то, что вам нужно за один вызов. И вот тут, если вы используете достаточно хороший стандарт, спецификация может оказаться лучшим языком общения. А может и не быть им.
В общем случае, фронтэнд разработчик может предложить спецификацию АПИ как способ выразить свои требования по инпуту и аутпуту при хорошей стандартизации этого апи, но финальное слово за бэкэндом, ибо только они знают все ограничения бэкэнда и лучший путь реализовать требования фронтэнда.
Нужно ли для такой коллаборации специальное решение? Не уверен. Но и критиковать ваш проект я не готов.
Worst of the best думаю можно сказать
It was the worst of the best options.
Windows 1nte1 же
Мб они 1сники
Мне кажется это шутка, ибо 1500 страниц, но при этом краткого
В мире есть много других игр, которые такого не требуют. Скоро рипнутся они, жаль близзард
Познакомился с SOPS благодаря Helmfile и helm-secrets. Было легко настроить и очень удобно использовать. Плюс очень быстро вникаешь в это всё. Поэтому согласен с автором.
Пойду с горя продам свой нетоповый или неигровой Lenovo Legion 7
В Воронеже много айти компаний и хорошие зарплаты в айти, при сравнительно невысокой стоимости жилья и невысокой средней зп в других отраслях. Иными словами, переехав в Воронеж, будет гораздо больше оставаться денег, чем в других городах.
При этом Воронеж - город-миллионник, есть достаточно много всяких развлечений, событий. Немало парков и скверов хотя хотелось бы больше. Да, конечно всего этого сильно меньше, чем в Питере или Москве. Но Москва недалеко (6 часов сидячий поезд, 4 часа на машине по трассе или час на самолёте), туда периодически можно гонять. До Питера 2 часа на самолёте, и это относительно недорого. Иными словами, можно жить спокойно, но при этом иметь большинство плюсов Москвы/Питера в том или ином виде.
Город так же сильно меньше Москвы/Питера, поэтому вполне можно жить за чертой города в домике, но при этом не быть сильно далеко от цивилизации (час езды в худшем случае, если нет сильных пробок). Либо можно жить в городе очень близко ко всем необходимым объектам.
И в целом город развивается, правда и жильё дорожает, особенно новостройки, особенно элитные.
Есть, конечно, и минусы. Ситуация на дорогах не очень, хотя для общественного транспорта ввели выделенные полосы и она улучшается. Плюс не назвал бы город чистым, но стало чуть лучше. Ну и я бы сказал что после 10 вечера город относительно вымирает, народ либо тусит и пьёт, либо сидит дома. Общественного транспорта после 10 сильно меньше (сравниваю с тем же Питером). Но такси круглосуточно и ехать вряд ли нужно будет сильно далеко.
Меня удивляет, что вы пишете некоторые аспекты, называете их минусами и рассказываете в основном о негативной стороне. Слишком однобоко выходит.
Не уверен, что есть смысл полностью уходить с Firebase. Их авторизацию можно использовать без всего остального, и она очень удобна на мой взгляд.
Если говорить про базы, то да, если вам нужны ACID транзакции, Firebase базы уже становятся не лучшим решением. Но это всё про бизнес требования и их решения. Вы скорее всего пропустили нужный момент миграции. Но частично эти проблемы можно решить с помощью cloud functions и state машин. Собственно мы это и делаем, но проект небольшой.
Резюмируя - Firebase не так плох, но нужно понимать, когда его перестаёт хватать. Он и правда хорошо экономит на старте.
Удвоение зарплаты не действует в некоторых крайних точках, вы правы. Туда можно отнести и 0х2=0, и что 1000 или 2000 рублей в месяц разницы не сделают. И что х2 зп на пару месяцев перед пенсией ничего существенно не поменяет.
Но если мы возьмём обычного человека, зарплата которого находится между половиной от реального прожиточного минимума и до той зарплаты, которая сможет обеспечить абсолютно все его потенциальные хотелки, то выражение верно и покрывает ситуацию почти всех людей.
Всегда забавляли примеры с отсутствующим в списке элементом.
А в целом спасибо за статью!
Видосы по математике у него довольно интересны для обывателя. Видно, что увлечён своим делом.
Но в этом интервью он местами, конечно, пургу гонит. Но это со всеми людьми науки случается, имхо.
Спасибо гугл транслейту за перевод