Атеизм – это отрицание существования Бога или богов. Агностицизм – это убеждение, что невозможно доказать или опровергнуть существование Бога или богов. Все же по поему мнению агностицизм ближе к науке, а вот атеизм ближе к вере. Да и будем честны, демагогию на эту тему вести можно долго. Для древних людей уже мы можем сойти за богов, к примеру. Нет никаких гарантий, что вселенную не создало какое-то существо рангом повыше, как нет и доказательств этого. Следовательно полная вера или же наоборот, полное отрицание - это две стороны одной монеты. Так, что-то мы не в ту степь ушли в комментариях к статье о разработчиках.
Забавный факт, атеисты в какой-то степени тоже религиозные фанатики. Верующие свято верят в условного Бога, но не могут доказать его существование. Атеисты верят в отсутствие бога, но не могут доказать его отсутствие. (Я знаю, что бремя доказательства лежит на том кто делает заявление)
Абстракция хороша до тех пор, пока разработчик не абстрагируется от всего что можно. Абстрагироваться от того, как браузер дергает апи ос - нормально, абстрагироваться от того как работает какая-нибудь функция в твоем языке, которую дергаешь ты - плохо
Суть поста не в том, что всё можно сделать на плюсах и будет всё летать. Суть в том, что разработчики выбирают какую-то технологию не разбираясь в ней, а просто потому что(подчеркнуть нужное): так повелось, так сказали в каком-то гайде, тот авторитетный человек назвал технологию нужной. А последствия того, что человек не изучает то, с чем он работает могут быть ужасающими. В статье отличный пример с монгой, когда человек прогоняет всё данные через клиент. Если бы человек разобрался в своём яп и монге, произошло бы такое? Нет. И да, софт булет здесь и сейчас, а потом бизнес будет разгребать последствия. Другой пример, сейчас всех джунов заставляют учить js event loop, и они зубрят, но понимания что и как у них не появляется, а про конструкцию сет тайм-аут с нулевой задержкой я давно не слышал, хотя, при тяжёлых действиях на фронте, она может ускорить рендер. Такая же ситуация и с алгоритмами, их возвели в культ, но того, что за ними стоит никто толком не учит. На фронте вообще ужасная ситуация, люди тащат с npm даже самые мелкие библиотеки. Имхо, но суть статьи в том, что если что-то изучаешь, то копни чуть глубже, не до самого ядра планеты, а чуть-чуть, если что-то собираешься сделать, то подумай перед этим, ты разработчик, и тебе платят не за следование религиозным догмам, а за твой мозг в первую очередь. Ты ты можешь решить задачу сейчас, не подумав, с наскока, выбрав, только те технологии, которые знаешь, даже если они совсем не подходят, и бизнес будет благодарен тебе, сегодня, а завтра проклянет, когда весь проект начнёт сыпаться. И да, предыдущее предложение не значит, что нужно под каждый проект учить новые технологии и тратить на это время и деньги бизнеса, определить где это целесообразно, а где нет, тоже входит в зону ответственности разработчика.
Я не говорю, что надо учить и знать алгоритмы - нет. Но нужно понимание того, как и что работает. Точнее наизусть знать алгоритмы не надо, а вот о существование каких-нибудь условных авл и красно-черных деревьев и разницы между ними знать стоит, т.к. для каких-то ситуаций это может пригодится, правда не вижу смысла это знать джуном, а вот мидлам вполне себе полезное знание.
Ну тут все же зависит от задачи и того кто это будет реализовывать. Кстати еще из забавных моментов, когда смотришь на код людей, некоторые не понимают, что (на примере js) такие методы как - includes, split, filter, map, reduce и т.д. выполняются не за O(1) времени или когда какой-нибудь цикл выносят в отдельную функцию и вот уже сложность не n^2 а линейная(хотя это и не так). Как раз такие люди любую технологию могут сломать, какой-бы она продвинутой не была. Мне в этом плане очень нравится Go(на счет других яп сказать не могу, работал только с python, js, golang), если тебе надо обойти массив, то тебе надо обойти массив, циклом, в лоб.
Не совсем корректный пример. Все же условный реакт не сломается, если им 1 html страницу делать, но вот смысла в этом не очень много. Да и осваивание вещь относительная. К примеру, есть стартап, какая-то фича нужна срочно и сейчас - выбрать известный, но не совсем подходящий, инструмент идея хорошая. Или у нас условная средне-крупная компания и нам нужно заменить какой-то сервис, у нас есть время, а эта замена послужит основанием для крупного роста, то тут лучше взять подходящий инструмент.
С последним пунктом согласен, в статье не совсем корректный пример. Пока приложение лежит от нагрузки, бизнес может терять прибыль, и если затраты на увеличение мощности серверов меньше потерь бизнес, то это стоит сделать, и дальше уже искать причину. Другой пример, какой-нибудь медицинский аппарат выключился из-за сбоя, не стоит его просто перезагружать, пока не заработает, тут, наоборот, стоит сначала найти причину неполадки.
К слову, в go очень много последователей другой религии. Если в js условном тянем всё с npm, то в go религия - сделай сам (хотя и в других яп свои последователи будут) .
Мне кажется корень проблемы в том, что люди просто не хотят фильтровать информацию, которую находят. Недавно была ситуация, хотел сделать селект с поиском на реакте, ну и начал гуглить как люди это делают, чтобы понять какие подходы используют, а не изобретать велосипед. Гайдов 10 перелистал и по итогу все гайды это npm i react-select. Правда там есть и хорошие моменты, такие как асинхронная подгрузка. Судить насколько имеет смысл тащить его в проект не могу(зависит правда от проекта), основное направление все же это бекенд на Go. Но лично я не привык тащить в проект зависимости ради проблем на решений которых можно потратить день.
Монга - больная тема и гайды по ней, как не откроешь, кидают в базу все как есть, про ту же jsonSchema нигде толком не пишут (да, у схемы есть свои минусы, но это не повод кидать в базу данные в сыром виде и молиться, что нигде на клиенте нет ошибки из-за чего цена товара отправиться в базу не децималом, а флоатом к примеру). И ладно этот клиент какой-нибудь типизированный язык, но зачастую это js(даже не ts), python. А от fullstack гайдов по MERN стеку рыдать хочется. Пытаешься агрегировать в монге данные и что-то не можешь решить, гуглишь, находишь в основном решения, где данные прогоняют через клиент. В монге замечательная интеграция с языками, особенно js, настолько замечательная, что многие перестают видеть грань между приложением и базой.
Я так понимаю автор в этой статье хотел показать пагинацию по ключам, но тему эту даже близко не раскрыл и зачем-то прикрутил новую колонку sortID. Такую пагинацию вполне можно выполнять и по pk. Правда в случае сортировки данных по какой-то другой колонке нужно прописывать дополнительную логику (в случае если колонка не уникальна) WHERE some_field > $1 OR (some_field = $1 AND id > $2) ORDER BY some_field, id Ну и конечно без индексов никуда
Мы видимо не совсем друг друга поняли) Практический каждый проект в том или ином виде кидает данные, но не в каждом проекте есть какая-то интересная логика к этому. Ну и пример - аутентификации и авторизация в стейтлесс микросервисах. По факту это в основном простые круды, но вариантов реализации там достаточно много и у каждого есть свои плюсы и минусы. Ну или другой пример, уже скучного круда, практически каждый гайд на какой-нибудь язык или фреймворк.
Я думаю не имеет смысла ожидать чего-то внятного от человека, который зарегистрировался в 11 году, не сделал за это время ни одной публикации и при этом как-то смог удержать карму меньше 10. И признаюсь честно, статья интересна, но не содержанием, а из-за вашего возраста. Меня максимум хватало на почистить комп от вирусов на тот момент) Кстати, насколько я вижу вы пока не выбрали конкретное, интересное для вас, направление в разработке? Всё же бекенд бекенду рознь. Можно джсоны по круду перекидывать, но это далеко не самое интересное занятие.
Согласен, Антитеизмом, Атеизм, Агностицизм, крайне похожие термины, но суть все же разная.
Спасибо, не знал. Тогда приношу свои извинения.
Атеизм – это отрицание существования Бога или богов.
Агностицизм – это убеждение, что невозможно доказать или опровергнуть существование Бога или богов.
Все же по поему мнению агностицизм ближе к науке, а вот атеизм ближе к вере.
Да и будем честны, демагогию на эту тему вести можно долго. Для древних людей уже мы можем сойти за богов, к примеру. Нет никаких гарантий, что вселенную не создало какое-то существо рангом повыше, как нет и доказательств этого. Следовательно полная вера или же наоборот, полное отрицание - это две стороны одной монеты. Так, что-то мы не в ту степь ушли в комментариях к статье о разработчиках.
Забавный факт, атеисты в какой-то степени тоже религиозные фанатики. Верующие свято верят в условного Бога, но не могут доказать его существование. Атеисты верят в отсутствие бога, но не могут доказать его отсутствие. (Я знаю, что бремя доказательства лежит на том кто делает заявление)
Абстракция хороша до тех пор, пока разработчик не абстрагируется от всего что можно. Абстрагироваться от того, как браузер дергает апи ос - нормально, абстрагироваться от того как работает какая-нибудь функция в твоем языке, которую дергаешь ты - плохо
Суть поста не в том, что всё можно сделать на плюсах и будет всё летать. Суть в том, что разработчики выбирают какую-то технологию не разбираясь в ней, а просто потому что(подчеркнуть нужное): так повелось, так сказали в каком-то гайде, тот авторитетный человек назвал технологию нужной. А последствия того, что человек не изучает то, с чем он работает могут быть ужасающими. В статье отличный пример с монгой, когда человек прогоняет всё данные через клиент. Если бы человек разобрался в своём яп и монге, произошло бы такое? Нет. И да, софт булет здесь и сейчас, а потом бизнес будет разгребать последствия. Другой пример, сейчас всех джунов заставляют учить js event loop, и они зубрят, но понимания что и как у них не появляется, а про конструкцию сет тайм-аут с нулевой задержкой я давно не слышал, хотя, при тяжёлых действиях на фронте, она может ускорить рендер. Такая же ситуация и с алгоритмами, их возвели в культ, но того, что за ними стоит никто толком не учит. На фронте вообще ужасная ситуация, люди тащат с npm даже самые мелкие библиотеки. Имхо, но суть статьи в том, что если что-то изучаешь, то копни чуть глубже, не до самого ядра планеты, а чуть-чуть, если что-то собираешься сделать, то подумай перед этим, ты разработчик, и тебе платят не за следование религиозным догмам, а за твой мозг в первую очередь. Ты ты можешь решить задачу сейчас, не подумав, с наскока, выбрав, только те технологии, которые знаешь, даже если они совсем не подходят, и бизнес будет благодарен тебе, сегодня, а завтра проклянет, когда весь проект начнёт сыпаться. И да, предыдущее предложение не значит, что нужно под каждый проект учить новые технологии и тратить на это время и деньги бизнеса, определить где это целесообразно, а где нет, тоже входит в зону ответственности разработчика.
Я не говорю, что надо учить и знать алгоритмы - нет. Но нужно понимание того, как и что работает. Точнее наизусть знать алгоритмы не надо, а вот о существование каких-нибудь условных авл и красно-черных деревьев и разницы между ними знать стоит, т.к. для каких-то ситуаций это может пригодится, правда не вижу смысла это знать джуном, а вот мидлам вполне себе полезное знание.
Ну тут все же зависит от задачи и того кто это будет реализовывать. Кстати еще из забавных моментов, когда смотришь на код людей, некоторые не понимают, что (на примере js) такие методы как - includes, split, filter, map, reduce и т.д. выполняются не за O(1) времени или когда какой-нибудь цикл выносят в отдельную функцию и вот уже сложность не n^2 а линейная(хотя это и не так). Как раз такие люди любую технологию могут сломать, какой-бы она продвинутой не была. Мне в этом плане очень нравится Go(на счет других яп сказать не могу, работал только с python, js, golang), если тебе надо обойти массив, то тебе надо обойти массив, циклом, в лоб.
Но один момент все же от контекста не зависит. Не надо тащить все что не приколочено с npm/pip/go get и тд
Не совсем корректный пример. Все же условный реакт не сломается, если им 1 html страницу делать, но вот смысла в этом не очень много. Да и осваивание вещь относительная. К примеру, есть стартап, какая-то фича нужна срочно и сейчас - выбрать известный, но не совсем подходящий, инструмент идея хорошая. Или у нас условная средне-крупная компания и нам нужно заменить какой-то сервис, у нас есть время, а эта замена послужит основанием для крупного роста, то тут лучше взять подходящий инструмент.
Вы на растохейтеров можете случайно гоферов вызвать, вы там поосторожнее с этим как-нибудь. Одного вот уже вызвали.
С последним пунктом согласен, в статье не совсем корректный пример. Пока приложение лежит от нагрузки, бизнес может терять прибыль, и если затраты на увеличение мощности серверов меньше потерь бизнес, то это стоит сделать, и дальше уже искать причину. Другой пример, какой-нибудь медицинский аппарат выключился из-за сбоя, не стоит его просто перезагружать, пока не заработает, тут, наоборот, стоит сначала найти причину неполадки.
К слову, в go очень много последователей другой религии. Если в js условном тянем всё с npm, то в go религия - сделай сам (хотя и в других яп свои последователи будут) .
Мне кажется корень проблемы в том, что люди просто не хотят фильтровать информацию, которую находят. Недавно была ситуация, хотел сделать селект с поиском на реакте, ну и начал гуглить как люди это делают, чтобы понять какие подходы используют, а не изобретать велосипед. Гайдов 10 перелистал и по итогу все гайды это npm i react-select. Правда там есть и хорошие моменты, такие как асинхронная подгрузка. Судить насколько имеет смысл тащить его в проект не могу(зависит правда от проекта), основное направление все же это бекенд на Go. Но лично я не привык тащить в проект зависимости ради проблем на решений которых можно потратить день.
Монга - больная тема и гайды по ней, как не откроешь, кидают в базу все как есть, про ту же jsonSchema нигде толком не пишут (да, у схемы есть свои минусы, но это не повод кидать в базу данные в сыром виде и молиться, что нигде на клиенте нет ошибки из-за чего цена товара отправиться в базу не децималом, а флоатом к примеру). И ладно этот клиент какой-нибудь типизированный язык, но зачастую это js(даже не ts), python. А от fullstack гайдов по MERN стеку рыдать хочется. Пытаешься агрегировать в монге данные и что-то не можешь решить, гуглишь, находишь в основном решения, где данные прогоняют через клиент. В монге замечательная интеграция с языками, особенно js, настолько замечательная, что многие перестают видеть грань между приложением и базой.
Fastapi - первый коммит 05.12.2018
Яндекс практикум появился в 2018-2019 году
Я так понимаю автор в этой статье хотел показать пагинацию по ключам, но тему эту даже близко не раскрыл и зачем-то прикрутил новую колонку sortID. Такую пагинацию вполне можно выполнять и по pk. Правда в случае сортировки данных по какой-то другой колонке нужно прописывать дополнительную логику (в случае если колонка не уникальна)
WHERE some_field > $1 OR (some_field = $1 AND id > $2) ORDER BY some_field, idНу и конечно без индексов никудаБудем честны, если вы хоть раз какой-то 1 компании давали свой телефон(а вы давали), то велик шанс, что теперь этот телефон есть у всех компаний.
Мы видимо не совсем друг друга поняли)
Практический каждый проект в том или ином виде кидает данные, но не в каждом проекте есть какая-то интересная логика к этому.
Ну и пример - аутентификации и авторизация в стейтлесс микросервисах. По факту это в основном простые круды, но вариантов реализации там достаточно много и у каждого есть свои плюсы и минусы. Ну или другой пример, уже скучного круда, практически каждый гайд на какой-нибудь язык или фреймворк.
Я думаю не имеет смысла ожидать чего-то внятного от человека, который зарегистрировался в 11 году, не сделал за это время ни одной публикации и при этом как-то смог удержать карму меньше 10.
И признаюсь честно, статья интересна, но не содержанием, а из-за вашего возраста. Меня максимум хватало на почистить комп от вирусов на тот момент)
Кстати, насколько я вижу вы пока не выбрали конкретное, интересное для вас, направление в разработке? Всё же бекенд бекенду рознь. Можно джсоны по круду перекидывать, но это далеко не самое интересное занятие.