Свобода — это когда для данного языка существует эффективный способ решения задачи, не требующий написания костылей, обходящих ограничения языка.
Вседозволенность — это когда вообще не задумываешься о том, что, зачем и как пишешь.
Исходя из этого, вы хотите сказать, что строго типизированные языки это панацея от костылей? С этим вынужден не согласиться, потому что там костыли могут быть еще более сложными как раз таки из-за ограничений строгости.
Это вечный холивар между динамическими и строго типизированными языками, думаю нет смысла в это углубляться? Каждый смотрит с точки зрения своего опыта и в какой-то степени предвзятости.
Динамический язык != костыли, это другая идеология к разработке, другие подходы и сравнивать их не всегда корректно.
И если разработчик не умеет искать эти способы — это проблема разработчика, а не языка.
Мне кажется, или вы тут как раз и ответили? что не важно какой язык — строго типизированный или динамический, если разработчик не умеет мыслить и строить программу, то это не проблема инструмента?
В добавок, сейчас как раз я наблюдаю тенденцию, поправьте, если я не прав:
— динамические языки вводят к себе не обязательные ограничения
— строго типизированные языки добавляют к себе послабления (в виде var переменных в C# — ведь var? )
Что я хочу сказать, у каждого языка своя идеология, свои принципы, подходы к решению задач, сказать что решение на языке А плохое, а на Б хорошее, некорректно. Если и оценивать, то с точки производительности и то, сказать надо не «плохое», а неоптимальное с точки зрения производительности.
эффективный способ решения задачи, не требующий написания костылей, обходящих ограничения языка.
Можно пример задачи, когда требуется искать костыли в ее решении?
При этом Go содержит всё необходимое для написания проектов практически любого уровня.
Возможно, но порог входа в язык не самый низкий и не для каждого
Смотря чем он планирует заниматься и какая область ему интересна (веб, мобилки и тд)
От этого можно смотреть вообще на чем разрабатывается в этой сфере, раз вопрос с PHP, то видимо веб.
Из своего опыта скажу, что PHP вполне можно брать за основу в знакомстве с вебом, но лучше начинать без использования фреймворков, а чисто брать язык и смотреть как он вообще используется в разработке, чтобы понять сам принцип, тогда в будущем не будет сюрпризов преходя на другой язык
Так же как альтернативы для веба, можно взять Ruby, Elixir, Python, возможно еще C# и Rust
Ну и кроме языка важно заниматься изучением вообще методологий разработки под веб, как и из чего состоят приложения, там уже сразу идет разделение на слои — фронт, бек с базой. Базы данных хорошо надо бы смотреть, разбираться в SQL нынешние фреймоворки обычно изолируют разработчиков через ORM от работы с чистым SQL, но писать его надо уметь и это будет огромный плюс в карьере и в целом
С вами сложно и согласиться, и возразить, да, динамические языки дают больше свободы, но это не делает обучение на них плохим, все зависит от того КАК строится обучение.
В универе в свое время мы учили программирование Pascal -> C -> C++, веб уже шел к старшим курсам.
Стоит скорее брать сначала в изучение общую теорию программирование и разработку под сферу — веб, декстоп, мобилки, а язык уже дело посредственное, там можно выбрать что больше по душе — синтаксис, подходы, комьюнити ну и возможности в поиске работы
У меня карьера началась с PHP, хотя сначала хотел в C#, но не сложилось с первой работой, в целом, не жалею, PHP дал старт для работы веб разработчика, в процессе ушел на другой язык, да и изучение разных языков дает огромный плюс — расширяет кругозор
Из модных языков таковым является Go.
С GO знаком поверхностно, но я бы не сказал, что новичку в разработке этот язык будет простым в освоении, хотя, может все индивидуально
Как по мне, подход с передачей ссылок может быть справедлив, если это шлет бекенд на фронтенд, чтобы там не хранить информацию о endpoint для работы с данными.
Кстати для описанного в статье реализована спецификация JSON API, как раз работает в описанном формате.
В случае, когда у нас серверное API с большим количеством данных, мы получаем огромное дублирование данных (при хайлоаде очень заметный трафик).
С каким успехом, лучше уже чтобы у API был метод, где мы можем получить схему URL'ов API.
Плюс, часто бывает, что нужен реально идентификатор сущности клиенткой стороне (например у вас другой сервис работает с этим API), для каких-то действий. Тогда что, делать запрос на урл, чтобы получить ID? парсить URL? хранить в БД URL? а если нужно сделать запрос на другой ендпоинт? или в процессе хочешь делать запросы по разным версиям?
предоставление ключей базы данных или прокси для них в полях тех сущностей, которые ассоциированы с этими ключами
Это можно решить путем работы с UUID или каким-то генерируем ключом, который не соответствует реальному ID в БД, таким образом, клиент не знает реального ID и работает с его представлением.
Ежики кололись, плакали, но продолжали есть кактус, зачем делать некачественный контент, потому что я могу?
Это справедливо в университете, когда делаем лабораторки, курсачи, дипломы, для галочки, с ведрами воды, потому что так «принято».
Но мы же все профессионалы, мы должны стараться делать этот мир чуточку лучше, рассказать что-то полезное, привести какие-то обоснования, провести исследование интересующего вас вопроса, а не совочком черпать воду из одной лужи в другую и говорить «я сделяль»
Статьи (да и не только) должны иметь какую-то пользу, а не ради галочки.
Сейчас все выглядит так, Вы решили сделать пиар для себя наштамповав примитивных статей не раскрыв или не разобравшись в технологии, ситуации видя лишь выгоду «стать публичным человеком», дабы потом указывать строчку в резюме.
Мои статьи не нарушают правила хабра
Отступление от темы статей, и аналогия: в разработке ПО написание говнокода тоже не нарушает правила синтаксиса языка, но стоит ли это считать правильным и полезным?
Ruby не имел ни одного преимущества перед этими языками. У него был лишь веб-фреймворк Ruby on Rails, который все уже давно скопировали.
Зачем же вы навязываете ваше мнение, если оно в корни неверное и необоснованное?
В Ruby высокая скорость разработки, понятный и легко читабельный синтаксис, в том числе огромное количество готовых решений практически на любой случай жизни.
Которые кстати, в 90% случаев покрыты юнит тестами и поддерживаются активным и живым комьюнити.
Плюс, сам язык пропагандирует написание тестов и это принято всеми разработчиками писать тесты на код, которые очень легко пишутся, в отличии от других языков, например PHP.
Простой поиск по вакансиям дает крайне мало результатов, и большинство вакансий идет как раз в компании, что были основаны в период его популярности.
И снова неправда и необоснованное утверждение.
Вакансий огромный поток как по СНГ так и на зарубежные компании, его можно легко найти на Linked In, так и в каналах Telegram, есть отдельные сервисы, которые поддерживаются через open-source комьюнити Ruby (в том числе СНГ).
Поэтому вам нужно быть готовым к тому, что основную часть своей работы вы будете тратить на поддержку существующих решений.
Это не так. Есть значительное количество компаний, которые делают разработку с нуля используя стек Ruby, который позволяет быстро и качественно разрабатывать приложения.
если вы хотите стать Ruby программистом, то вам нужно планировать переезд в Силиконовую долину,
Опять голословное утверждение, откройте список вакансий по СНГ, посмотрите в каких городах есть спрос, опять же, куча удаленной работы, не требующей никаких переездов.
Однако, в большинстве случаев вакансий на Ruby будет мало.
Это можно сказать только лишь о джунах, но такое утверждение будет верно для любой технологии, малое количество компаний готово брать на себя обязательства по подготовке разработчиков с нуля. Но это решается личным интересом, в том числе и курсами.
В Санкт-Петербурге и других крупных городах проводятся бесплатные обучающие программы + всегда можно обратиться к комьюнити в Telegram, где в чатах сидят тысячи разработчиков.
Да, верно, это один из подходов, как переводить старый код, на новый стиль, чтобы не заниматься тех долгом только, если поставлена задача.
Но опять же, можно выделять 20% времени спринта на исправление тех долга и доработке старых мест, если всегда рваться только вперед и никогда не оборачиваться на уже готовые части проекта, жди беды, рано или поздно, проект выйдет из под контроля.
Не спорю, что и у технологии есть свои недостатки, в моей практике тоже было много проблем с обновлением версий пакетов, но в данном случае описано много проблем так же в использовании технологии в проекте. В соблюдении чистоты кода проекта и единого подхода в реализации.
А ведь вся проблема в том, что нет четкой и однозначной стилистики, стандартов и их соблюдения.
Если решили использовать новый подход, то будьте добры и старый код перевести на новый лад, плодить зоопарк себе же хуже.
Как и то, что одни разрабы делают в одном стиле, другие в другом, это неприемлемо в любом проекте, нужно добавлять линтеры на код стайл конкретного проекта, выделять время на тех долг
Не будет нулевая если одностраничная визитка? Где-то тут у вас «не» пропущено?
Нет, видимо запутано выразился, 1 HTML страница будет работать без нагузки, а вот уже если их будет 1000, то нагрузка какая никакая все равно будет
А теперь просто подвинем это всё назад во времени — после обновления базы происходит сброс и перегенерация файлового кэша. В фоне, вы об этом точно так же ничего не знаете. Только теперь страница отдастся пользователю за микросекунды, потому что генерировать ничего не надо.
Потому что файловый кеш это медленно, если хранить, то хранить в памяти, вот это дает прирост скорости.
Именно — зачем вмешивать генерацию страницы в механизм отдачи HTML пользователю? Генерация страницы отдельно, отдача — отдельно.
Что мешает использовать тогда уже серверный рендеринг и его кеширование? Это абслютно тоже самое с точки зрения браузера, но без ненужных генераций шаблонов
И меньше, чем одна HD-фотография в карточке товара.
Ну да, ну да…
А ничего, что картинка в данных это только ссылка на картинку? а картинки, как раз относятся к статике и кешируются веб-сервером (Nginx) так что этот пример в корни неправильный.
Уже и в браузере, а не на сервере? И на телефонах? А то, что браузеры файлы тоже в дисковый кэш кладут — вы в курсе?
Ах да, в вашем случае нужно под каждый девайс нагенерить отдельный шаблон, забыл, приношу извинения.
Лишнее действие CMS? Ну, пометила бы она то же самое в базе, какая разница-то?
Давайте не будем путать представление и данные, данные обновляются когда надо и в каком надо объем и это хранилище. Это отдельная зона отвественности.
Потому что на каждое действие ре-рендеринг делают? Давайте без переходов на личности, хорошо?
Кстати тут не было перехода на личности, это скорее было сожаление по факту, т.к. часто сталкиваюсь с проблемами на сайтах, написанных с использованием CMS и возможно каких-то велосипедов. Так что тут извинения, если не так понято.
Нет, потому что изобретаются неправильные решения, которые выдаются за архитектуру, хотя это костыли и не желание разбираться в конечной проблеме, когда она есть.
О кстати, еще в копилку перерендеринга — фронтещик или кто-то решил шаблон поменять, о нет, нам надо сделать перегенерацию всех товаров, потому что в блоке цены добавился новый CSS класс…
В итоге страница будет перерисовываться безо всякой нужды
И это по вашему проблема? С каких пор, рендеринг это проблема в 2021 году? Почему такие гиганты как VK, Facebook не делают HTML шаблоны на каждый пост?
Я бы очень хотел посмотреть, как они террабайты текста перегенеривают в шаблоны, да там харды менять нужно будет каждую неделю с такими нагрузками.
Вот у нас нагрузка на сервер уже и не нулевая…
Она никогда не будет нулевая, если у вас одностраничная визитка, да.
Вот просто один в один то же самое, что просто дёрнуть рендеринг. Только ещё и две прослойки лишних в виду редиса и кеша nginx.
Оставим к примеру редис. Не суть сейчас
У вас есть 2 ОТДЕЛЬНЫЕ операции — подготовка данных и вывод данных, данные всегда в кеше, их сброс это бекграунд операция, вам и посетитель вообще пофигу на этот механизм — сервер вернул данные — браузер срендерил страницу.
Приложение должно быть разбито на зоны ответственности, а если мешать все в одну кучу, разобьем все яйца…
Советую почитать Роберта Мартина — Чистая архитектура, для начала
3 тысяч страниц по одному шаблону. Вы же сами говоите, что это миллисекунды занимает. Если так уж не нравится, подождать целых 10 секунд, то можно и отложенный рендеринг сделать — при первом обращении.
Только зачем хранить 3 тыс страниц, если достаточно хранить шаблон?
Абстрактно ваш шабло 1 КБ, значит вы на ровном месте сделали 3000 КБ только за счет их дублирования. И спрашивается вопрос — зачем?
Миллисекунды занимает рендаринг шаблона в браузере, каждый рендеринг, перерендеринг шаблона это безсмысленная нагрузка на диск, что черевато проблемами + это нагрузка. В отличии от хранения данных в памяти.
Одну страницу. Удалять или обновлять
Только вот это лишние действие
Вот послушав такие разговоры, я не удивлен, что большинство ресурсов, особенно на CMS тупят как адовый ад
Как минимум есть время жизни кешированной страницы, это раз, во вторых, если мы вдаемся в оптимизации, можно накручивать свою логику через скрипты, которые будут его сбрасывать
Данные в БД обновились — сразу обновили кеш в редисе, и при необходимости дернули сброс закешированных данных в nginx для них. Как показывает практика, одного редиса достаточно.
Как у товара может поменяться артикул? Какие 100500 шаблонов мне вдруг придётся менять при изменении одного товара?
Элементарно, товар же явно отображается не только на своем просмотре, а где-то есть превью, где-то еще что-то, везде пойди и перерендели большой HTML ради циферки
Если просмотров хотя бы не в 100 раз больше, чем обновлений, то да, подход не для вас.
Да хоть миллиард просмотров, это решается кешированием данных, а поверх уже оптимизацией рендеринга при необходимости. Redis и Nginx уже закроют основную нагрузку на эту работу
Тогда почему такой идеальны подход не используют все ресурсы? Он ведь так хорошо работает, так давай-те на все будем тулить генерацию HTML и вернемся к сайтам в 90-е
Исходя из этого, вы хотите сказать, что строго типизированные языки это панацея от костылей? С этим вынужден не согласиться, потому что там костыли могут быть еще более сложными как раз таки из-за ограничений строгости.
Это вечный холивар между динамическими и строго типизированными языками, думаю нет смысла в это углубляться? Каждый смотрит с точки зрения своего опыта и в какой-то степени предвзятости.
Динамический язык != костыли, это другая идеология к разработке, другие подходы и сравнивать их не всегда корректно.
Мне кажется, или вы тут как раз и ответили? что не важно какой язык — строго типизированный или динамический, если разработчик не умеет мыслить и строить программу, то это не проблема инструмента?
В добавок, сейчас как раз я наблюдаю тенденцию, поправьте, если я не прав:
— динамические языки вводят к себе не обязательные ограничения
— строго типизированные языки добавляют к себе послабления (в виде var переменных в C# — ведь var? )
Что я хочу сказать, у каждого языка своя идеология, свои принципы, подходы к решению задач, сказать что решение на языке А плохое, а на Б хорошее, некорректно. Если и оценивать, то с точки производительности и то, сказать надо не «плохое», а неоптимальное с точки зрения производительности.
Можно пример задачи, когда требуется искать костыли в ее решении?
Возможно, но порог входа в язык не самый низкий и не для каждого
От этого можно смотреть вообще на чем разрабатывается в этой сфере, раз вопрос с PHP, то видимо веб.
Из своего опыта скажу, что PHP вполне можно брать за основу в знакомстве с вебом, но лучше начинать без использования фреймворков, а чисто брать язык и смотреть как он вообще используется в разработке, чтобы понять сам принцип, тогда в будущем не будет сюрпризов преходя на другой язык
Так же как альтернативы для веба, можно взять Ruby, Elixir, Python, возможно еще C# и Rust
Ну и кроме языка важно заниматься изучением вообще методологий разработки под веб, как и из чего состоят приложения, там уже сразу идет разделение на слои — фронт, бек с базой. Базы данных хорошо надо бы смотреть, разбираться в SQL нынешние фреймоворки обычно изолируют разработчиков через ORM от работы с чистым SQL, но писать его надо уметь и это будет огромный плюс в карьере и в целом
В универе в свое время мы учили программирование Pascal -> C -> C++, веб уже шел к старшим курсам.
Стоит скорее брать сначала в изучение общую теорию программирование и разработку под сферу — веб, декстоп, мобилки, а язык уже дело посредственное, там можно выбрать что больше по душе — синтаксис, подходы, комьюнити ну и возможности в поиске работы
У меня карьера началась с PHP, хотя сначала хотел в C#, но не сложилось с первой работой, в целом, не жалею, PHP дал старт для работы веб разработчика, в процессе ушел на другой язык, да и изучение разных языков дает огромный плюс — расширяет кругозор
С GO знаком поверхностно, но я бы не сказал, что новичку в разработке этот язык будет простым в освоении, хотя, может все индивидуально
Кстати для описанного в статье реализована спецификация JSON API, как раз работает в описанном формате.
В случае, когда у нас серверное API с большим количеством данных, мы получаем огромное дублирование данных (при хайлоаде очень заметный трафик).
С каким успехом, лучше уже чтобы у API был метод, где мы можем получить схему URL'ов API.
Плюс, часто бывает, что нужен реально идентификатор сущности клиенткой стороне (например у вас другой сервис работает с этим API), для каких-то действий. Тогда что, делать запрос на урл, чтобы получить ID? парсить URL? хранить в БД URL? а если нужно сделать запрос на другой ендпоинт? или в процессе хочешь делать запросы по разным версиям?
Это можно решить путем работы с UUID или каким-то генерируем ключом, который не соответствует реальному ID в БД, таким образом, клиент не знает реального ID и работает с его представлением.
Ежики кололись, плакали, но продолжали есть кактус, зачем делать некачественный контент, потому что я могу?
Это справедливо в университете, когда делаем лабораторки, курсачи, дипломы, для галочки, с ведрами воды, потому что так «принято».
Но мы же все профессионалы, мы должны стараться делать этот мир чуточку лучше, рассказать что-то полезное, привести какие-то обоснования, провести исследование интересующего вас вопроса, а не совочком черпать воду из одной лужи в другую и говорить «я сделяль»
Сейчас все выглядит так, Вы решили сделать пиар для себя наштамповав примитивных статей не раскрыв или не разобравшись в технологии, ситуации видя лишь выгоду «стать публичным человеком», дабы потом указывать строчку в резюме.
Отступление от темы статей, и аналогия: в разработке ПО написание говнокода тоже не нарушает правила синтаксиса языка, но стоит ли это считать правильным и полезным?
Зачем же вы навязываете ваше мнение, если оно в корни неверное и необоснованное?
В Ruby высокая скорость разработки, понятный и легко читабельный синтаксис, в том числе огромное количество готовых решений практически на любой случай жизни.
Которые кстати, в 90% случаев покрыты юнит тестами и поддерживаются активным и живым комьюнити.
Плюс, сам язык пропагандирует написание тестов и это принято всеми разработчиками писать тесты на код, которые очень легко пишутся, в отличии от других языков, например PHP.
И снова неправда и необоснованное утверждение.
Вакансий огромный поток как по СНГ так и на зарубежные компании, его можно легко найти на Linked In, так и в каналах Telegram, есть отдельные сервисы, которые поддерживаются через open-source комьюнити Ruby (в том числе СНГ).
Это не так. Есть значительное количество компаний, которые делают разработку с нуля используя стек Ruby, который позволяет быстро и качественно разрабатывать приложения.
Опять голословное утверждение, откройте список вакансий по СНГ, посмотрите в каких городах есть спрос, опять же, куча удаленной работы, не требующей никаких переездов.
Это можно сказать только лишь о джунах, но такое утверждение будет верно для любой технологии, малое количество компаний готово брать на себя обязательства по подготовке разработчиков с нуля. Но это решается личным интересом, в том числе и курсами.
В Санкт-Петербурге и других крупных городах проводятся бесплатные обучающие программы + всегда можно обратиться к комьюнити в Telegram, где в чатах сидят тысячи разработчиков.
Но опять же, можно выделять 20% времени спринта на исправление тех долга и доработке старых мест, если всегда рваться только вперед и никогда не оборачиваться на уже готовые части проекта, жди беды, рано или поздно, проект выйдет из под контроля.
Если решили использовать новый подход, то будьте добры и старый код перевести на новый лад, плодить зоопарк себе же хуже.
Как и то, что одни разрабы делают в одном стиле, другие в другом, это неприемлемо в любом проекте, нужно добавлять линтеры на код стайл конкретного проекта, выделять время на тех долг
Нет, видимо запутано выразился, 1 HTML страница будет работать без нагузки, а вот уже если их будет 1000, то нагрузка какая никакая все равно будет
Потому что файловый кеш это медленно, если хранить, то хранить в памяти, вот это дает прирост скорости.
Что мешает использовать тогда уже серверный рендеринг и его кеширование? Это абслютно тоже самое с точки зрения браузера, но без ненужных генераций шаблонов
Ну да, ну да…
А ничего, что картинка в данных это только ссылка на картинку? а картинки, как раз относятся к статике и кешируются веб-сервером (Nginx) так что этот пример в корни неправильный.
Ах да, в вашем случае нужно под каждый девайс нагенерить отдельный шаблон, забыл, приношу извинения.
Давайте не будем путать представление и данные, данные обновляются когда надо и в каком надо объем и это хранилище. Это отдельная зона отвественности.
Кстати тут не было перехода на личности, это скорее было сожаление по факту, т.к. часто сталкиваюсь с проблемами на сайтах, написанных с использованием CMS и возможно каких-то велосипедов. Так что тут извинения, если не так понято.
Нет, потому что изобретаются неправильные решения, которые выдаются за архитектуру, хотя это костыли и не желание разбираться в конечной проблеме, когда она есть.
О кстати, еще в копилку перерендеринга — фронтещик или кто-то решил шаблон поменять, о нет, нам надо сделать перегенерацию всех товаров, потому что в блоке цены добавился новый CSS класс…
В данном случае, слово «архитектуру» надо взять в кавычки. И сложно представить экономию в серевере для такой задачи, видимо я не в том вебе работаю.
Тут я только развести руками могу, я уже не знаю
А зачем мне вообще база? странички HTML? можно же просто 1 PDF\Word файл скинуть и вуаля, прайс лист готов
И это по вашему проблема? С каких пор, рендеринг это проблема в 2021 году? Почему такие гиганты как VK, Facebook не делают HTML шаблоны на каждый пост?
Я бы очень хотел посмотреть, как они террабайты текста перегенеривают в шаблоны, да там харды менять нужно будет каждую неделю с такими нагрузками.
Она никогда не будет нулевая, если у вас одностраничная визитка, да.
Оставим к примеру редис. Не суть сейчас
У вас есть 2 ОТДЕЛЬНЫЕ операции — подготовка данных и вывод данных, данные всегда в кеше, их сброс это бекграунд операция, вам и посетитель вообще пофигу на этот механизм — сервер вернул данные — браузер срендерил страницу.
Приложение должно быть разбито на зоны ответственности, а если мешать все в одну кучу, разобьем все яйца…
Советую почитать Роберта Мартина — Чистая архитектура, для начала
Только зачем хранить 3 тыс страниц, если достаточно хранить шаблон?
Абстрактно ваш шабло 1 КБ, значит вы на ровном месте сделали 3000 КБ только за счет их дублирования. И спрашивается вопрос — зачем?
Миллисекунды занимает рендаринг шаблона в браузере, каждый рендеринг, перерендеринг шаблона это безсмысленная нагрузка на диск, что черевато проблемами + это нагрузка. В отличии от хранения данных в памяти.
Только вот это лишние действие
Вот послушав такие разговоры, я не удивлен, что большинство ресурсов, особенно на CMS тупят как адовый ад
1 — А не на калькуляторе ли хостится сайт?
2 — А оптимальный ли код?
3 — А оптимальная ли работа с базой?
И вот когда, из всех 3х пунктов можно сказать — да, соки выжаты по максимуму, можно уже начинать крутить кеши и прочие манипуляции
Данные в БД обновились — сразу обновили кеш в редисе, и при необходимости дернули сброс закешированных данных в nginx для них. Как показывает практика, одного редиса достаточно.
Элементарно, товар же явно отображается не только на своем просмотре, а где-то есть превью, где-то еще что-то, везде пойди и перерендели большой HTML ради циферки
Да хоть миллиард просмотров, это решается кешированием данных, а поверх уже оптимизацией рендеринга при необходимости. Redis и Nginx уже закроют основную нагрузку на эту работу
Тогда почему такой идеальны подход не используют все ресурсы? Он ведь так хорошо работает, так давай-те на все будем тулить генерацию HTML и вернемся к сайтам в 90-е