Классический капитализм трансформировался в постиндустриальной эпохе. Теперь для информационных продуктов контролируются не столько средства производства, сколько распространения продукта(Google Play, App Store, Steam) и информации конечным пользователям.
Ваша ошибка в том, что вы видите разницу там, где её нет. Единственное отличие информационного продукта от обычного в том, что информационный продукт можно продать много раз. А далее ничего не отличается и не меняется веками. Представьте себе, вы - кузнец в XV веке, решили делать гвозди. Наковали ведро гвоздей и что? А ничего! Они так и будут лежать в ведре, пока вы их не затащите на рынок и не продадите. И ещё не факт, что вам бы просто так разрешили в XV веке стоять и торговать. Что касается современнности, выложить приложение на Play Market сейчас проще, чем легально торговать опятами, собранными собственноручно в лесу. И если вам не нравится Pay Market, никто вам не запретит выложить apk файл на собственном сайте, на форуме, гитхабе и т.д. А вот если вы попытаетесь продавать опята просто в переходе возле дома, тем самым нарушите закон и рискуете получить штраф. И конкуренция на обычном рынке ничуть не легче, чем в сети. Ваше ведёрко с опятами будет крайне блекло смотреться в ряду заправских торгашей, которые свои опята купили из контейнера на какой-то оптовой базе, и выглядят их опята бодрее ваших, потому что в них весь цвет китайской химической промышленности.
В общем, это типичное заблуждение ремесленника, недооценившего важность торговли. И это в прямом смысле старо, как мир.
Когда работаешь с вебом, как-то очень редко думаешь о железе. Сделали даже специально для них поддержку Internet Explorer, а засада оказалась в хроме. Ну и как бы железо тут вообще ни при чём, я на 200% уверен, что те компы потянули бы и семёрку, просто у кого-то в период с 2009 по 2019 годы не нашлось времени, чтобы "освоить новую систему".
Вопрос с сертификатом решился довольно просто. Суть истории в том, что парк используемого устаревшего железа значительно шире, чем это может показаться. И в том, что даже очень большие юрлица не гонятся за обновлением своего парка компьютеров.
В неидеальном мире мы в 2019 году сделали CRM-ку для одной торговой сети, у которой было более ста магазинов. И с первых дней внедрения начался поток звонков от заведующих магазинами, что у них ошибка недоверенного соединения. Оказалось, почти во всех магазинах стояли старинные компы с икспишкой, и поставить на них браузеры с поддержкой сертификатов Let's encrypt оказалось невозможно.
Кроме того, довелось мне работать довольно долго в одном конструкторском бюро в инженерно-техническом отделе. Там старые компы переходили сначала к старым сотрудникам (в смысле для работы, а не в собственность), потом ко всяким снабженцам, потом всё это драконилось на запчасти. В середине прошлого десятилетия оттуда в утиль списывали ЭЛТ-мониторы и планки памяти по 32МБ.
Поэтому я и говорю, что в наших краях никто никогда не выбрасывает железо, которое ещё может послужить
Чушь полная. Обычно, когда прекращается сопровождение операционной системы устройства, никто ничего не выбрасывает. Можно же просто пользоваться устаревшей системой. Сколько людей до сих пор сидит на семёрке и не парятся
Очевидно же, что пост и комментарий - это два разных типа сущностей. Посты можно продвигать, закреплять, наверное что-то ещё можно с ними делать, что нельзя делать с комментариями. А чтобы сделать эндпоинт, который будет "россыпью" возвращать последние комментарии, в принципе ничего не надо менять. Просто нужен запрос с другим фильтром. Другой вопрос, почему этого не сделали. Возможно, из-за невостребованности.
Так и не понял, что хотел сказать автор? Продуктовые компании хорошо, а галеры плохо? Напомню, что стартапы - это тоже продуктовые компании, и там может вообще не быть никакой экономики, а тупо проедание инвестиций. Кроме того, в стартапах ценят "увлечённых людей", что на деле означает, что овертаймы обязательны. Что касается галер, то галера галере тоже рознь. Многие умудряются проработать на галере десятилетия, в то время, как не каждая продуктовая компания протянет столько.
Предлагаете всем перестать коммитить в чужие проекты из-за боязни, что коммит могут не принять? Что вообще за глупость? Если коммит что-то ломает, об этом напишут в issue и это будет повод доработать свой код. Если будут другие причины не принять - да пожалуйста, какие проблемы, если пакет уже установлен из форка и выполняет свои функции?
Опять же, прежде чем делать свой проект на замену заброшенного, нужно всё оценить и подумать, а не приведёт это к тому, что через довольно короткий промежуток это будет уже два заброшенных проекта?
Прежде, чем публиковать свой код в виде общедоступного пакета/модуля/библиотеки, стоит также оценить, действительно ли это кому-то нужно, а во вторую очередь оценить свои силы, потянешь ли бесконечное сопровождение проекта. Потому что во всех репозиториях вроде npm, packagist, drupal.org и прочих, большая часть проектов - это либо что-то очень редко используемое, либо что-то контекстозависимое, либо банально некачественное, либо настолько простое, что 3-5 строк своего кода полностью заменяют сторонний пакет. В этих репозиториях можно смело дропнуть от 50 до 90% проектов, и мир от этого станет только лучше.
Делаешь форк, решаешь в нём проблему, ставишь в свой проект пакет из форка. В официальном репозитории создаёшь issue и pull request. Ждёшь пока примут. Потом переустанавливаешь уже исправленную версию из официального репозитория.
У меня так уже несколько раз получалось. Именно так весь опенсорс работает вообще-то.
В вашем случае, естественно, не было смысла менять существующие библиотеки. Но опять де надо понимать, если пишешь какой-то код для своего проекта, это не значит, что его тут же нужно оформить, как общедоступную библиотеку. Сделать открытый репозиторий на гитхабе - пожалуйста. Но не нужно тянуть весь свой кастомный код в репозитории типа npm, packagist, maven и т.д.
Очень верное замечание. Очень часто бывает,что ищешь пакет или библиотеку под определенную задачу, а находишь сразу несколько, но все сырые, устаревшие и брошенные. Если бы авторы этих библиотек не делали свои библиотеки, а потратили это время на то, чтобы добавить пару коммитов в уже существующие, всем было бы только лучше.
Спасибо за статью, теперь хоть буду знать, как это называется. Вообще, токсичная терапированность - довольно распространенное явление и этот масштаб порой пугает. Не так давно видел в линкедин скриншот вакансии, где искали фронтенд-разработчика "с решёнными проблемами или хотя бы в терапии". То есть вариант, что человеку не нужен психолог или психотерапевт, уже не рассматривается. Второй пример: недавно одна дама устроила какой-то спор в домовом чате, а потом со словами "лучше поберегу менталку" закончила дискуссию. То есть человек в быту настолько часто употребляет термин "ментальное здоровье", что ей понадобилось ввести в свой лексикон жаргонизм, чтобы сократить термин.
Да и в целом все вокруг какие-то странные становятся - открываешь соцсети: у этого марафон осознанности, другой вон с утра щеголяет свеженачищенной чакрой, все вокруг знают наизусть названия антидепрессантов и успокоительных. Это всегда так было что ли?
Тут суть не в арифметике, а в логике работы веб-приложений. Само собой, что десять маленьких файлов - это модули, которые будут грузиться не на одной странице, а на разных. И пользователь при переходе с одной страницы на другие будет догружать необходимые стили. А если всё это упаковать в один единственный файл, то он загрузится только один раз, а при переходе по внутренним страницам будет браться из кэша, что в итоге сильно снизит количество сетевых запросов, ускорит отрисовку самих страниц плюс снимет нагрузку с сервера.
Естественно,что при общем объёме стилей в 10МБ это не сработает, но истина где-то по середине: стили можно дробить, но не слишком мелко. Условно говоря, если в файле всего 10 строчек, то время, затраченное на его загрузку по большей части будет состоять из времени на постановку запроса в очередь и установку соединения, и если его разделить на два файла по 5 строк, то эти два файла суммарно будут грузиться дольше.
И ещё один очень забавный момент: у CSS-чанков обычно хэшированные имена, лежат они в папке с длинным именем и могут иметь гет-параметры. Так вот, иногда длина URL CSS-файла может оказаться больше, чем его содержимое. То есть, если в HTML-документ вместо URL сразу инлайново запихнуть содержимое чанка, размер HTML уменьшится.
Если стиль нужно использовать точно такой же, то проблем нет. А если в один компонент нужно применить стили из двух, то нужно из двух объектов клеить один и присваивать его. А на выходе это скомпилируется в набор CSS-правил, которые уже описаны в двух других местах. То есть итоговое количество стилей увеличится.
Это не библиотека стилей, а библиотека, чтобы писать стили на javascript. Ничего перезаписывать там не приходится. Но в данном случае проблема в том, что повторно использовать что-либо будет либо неудобно, либо неэффективно с точки зрения производительности
Ваша ошибка в том, что вы видите разницу там, где её нет. Единственное отличие информационного продукта от обычного в том, что информационный продукт можно продать много раз. А далее ничего не отличается и не меняется веками. Представьте себе, вы - кузнец в XV веке, решили делать гвозди. Наковали ведро гвоздей и что? А ничего! Они так и будут лежать в ведре, пока вы их не затащите на рынок и не продадите. И ещё не факт, что вам бы просто так разрешили в XV веке стоять и торговать. Что касается современнности, выложить приложение на Play Market сейчас проще, чем легально торговать опятами, собранными собственноручно в лесу. И если вам не нравится Pay Market, никто вам не запретит выложить apk файл на собственном сайте, на форуме, гитхабе и т.д. А вот если вы попытаетесь продавать опята просто в переходе возле дома, тем самым нарушите закон и рискуете получить штраф. И конкуренция на обычном рынке ничуть не легче, чем в сети. Ваше ведёрко с опятами будет крайне блекло смотреться в ряду заправских торгашей, которые свои опята купили из контейнера на какой-то оптовой базе, и выглядят их опята бодрее ваших, потому что в них весь цвет китайской химической промышленности.
В общем, это типичное заблуждение ремесленника, недооценившего важность торговли. И это в прямом смысле старо, как мир.
Когда работаешь с вебом, как-то очень редко думаешь о железе. Сделали даже специально для них поддержку Internet Explorer, а засада оказалась в хроме. Ну и как бы железо тут вообще ни при чём, я на 200% уверен, что те компы потянули бы и семёрку, просто у кого-то в период с 2009 по 2019 годы не нашлось времени, чтобы "освоить новую систему".
Вопрос с сертификатом решился довольно просто. Суть истории в том, что парк используемого устаревшего железа значительно шире, чем это может показаться. И в том, что даже очень большие юрлица не гонятся за обновлением своего парка компьютеров.
В неидеальном мире мы в 2019 году сделали CRM-ку для одной торговой сети, у которой было более ста магазинов. И с первых дней внедрения начался поток звонков от заведующих магазинами, что у них ошибка недоверенного соединения. Оказалось, почти во всех магазинах стояли старинные компы с икспишкой, и поставить на них браузеры с поддержкой сертификатов Let's encrypt оказалось невозможно.
Кроме того, довелось мне работать довольно долго в одном конструкторском бюро в инженерно-техническом отделе. Там старые компы переходили сначала к старым сотрудникам (в смысле для работы, а не в собственность), потом ко всяким снабженцам, потом всё это драконилось на запчасти. В середине прошлого десятилетия оттуда в утиль списывали ЭЛТ-мониторы и планки памяти по 32МБ.
Поэтому я и говорю, что в наших краях никто никогда не выбрасывает железо, которое ещё может послужить
Контора тем более не отправит железо на свалку. Продадут, и будет оно работать уже в других руках.
Чушь полная. Обычно, когда прекращается сопровождение операционной системы устройства, никто ничего не выбрасывает. Можно же просто пользоваться устаревшей системой. Сколько людей до сих пор сидит на семёрке и не парятся
Очевидно же, что пост и комментарий - это два разных типа сущностей. Посты можно продвигать, закреплять, наверное что-то ещё можно с ними делать, что нельзя делать с комментариями. А чтобы сделать эндпоинт, который будет "россыпью" возвращать последние комментарии, в принципе ничего не надо менять. Просто нужен запрос с другим фильтром. Другой вопрос, почему этого не сделали. Возможно, из-за невостребованности.
Надеюсь, кто-нибудь поставил себе цель вернуть стену.
Так и не понял, что хотел сказать автор? Продуктовые компании хорошо, а галеры плохо? Напомню, что стартапы - это тоже продуктовые компании, и там может вообще не быть никакой экономики, а тупо проедание инвестиций. Кроме того, в стартапах ценят "увлечённых людей", что на деле означает, что овертаймы обязательны. Что касается галер, то галера галере тоже рознь. Многие умудряются проработать на галере десятилетия, в то время, как не каждая продуктовая компания протянет столько.
В таком случае создание собственных open source проектов вообще противопоказано, т к. рано ещё.
Предлагаете всем перестать коммитить в чужие проекты из-за боязни, что коммит могут не принять? Что вообще за глупость? Если коммит что-то ломает, об этом напишут в issue и это будет повод доработать свой код. Если будут другие причины не принять - да пожалуйста, какие проблемы, если пакет уже установлен из форка и выполняет свои функции?
Опять же, прежде чем делать свой проект на замену заброшенного, нужно всё оценить и подумать, а не приведёт это к тому, что через довольно короткий промежуток это будет уже два заброшенных проекта?
Прежде, чем публиковать свой код в виде общедоступного пакета/модуля/библиотеки, стоит также оценить, действительно ли это кому-то нужно, а во вторую очередь оценить свои силы, потянешь ли бесконечное сопровождение проекта. Потому что во всех репозиториях вроде npm, packagist, drupal.org и прочих, большая часть проектов - это либо что-то очень редко используемое, либо что-то контекстозависимое, либо банально некачественное, либо настолько простое, что 3-5 строк своего кода полностью заменяют сторонний пакет. В этих репозиториях можно смело дропнуть от 50 до 90% проектов, и мир от этого станет только лучше.
Делаешь форк, решаешь в нём проблему, ставишь в свой проект пакет из форка. В официальном репозитории создаёшь issue и pull request. Ждёшь пока примут. Потом переустанавливаешь уже исправленную версию из официального репозитория.
У меня так уже несколько раз получалось. Именно так весь опенсорс работает вообще-то.
В вашем случае, естественно, не было смысла менять существующие библиотеки. Но опять де надо понимать, если пишешь какой-то код для своего проекта, это не значит, что его тут же нужно оформить, как общедоступную библиотеку. Сделать открытый репозиторий на гитхабе - пожалуйста. Но не нужно тянуть весь свой кастомный код в репозитории типа npm, packagist, maven и т.д.
Статья интересная, непонятно только причём тут SSR?
PS: слово Fullstack читается как "фуллстек". А "фуллстАк" - это full stuck - дословный перевод "полностью застрявший"
Мой страшный сон, когда коллеги начнут говорить "а вот ChatGPT считает иначе, значит, ты не прав".
Очень верное замечание. Очень часто бывает,что ищешь пакет или библиотеку под определенную задачу, а находишь сразу несколько, но все сырые, устаревшие и брошенные. Если бы авторы этих библиотек не делали свои библиотеки, а потратили это время на то, чтобы добавить пару коммитов в уже существующие, всем было бы только лучше.
Спасибо за статью, теперь хоть буду знать, как это называется. Вообще, токсичная терапированность - довольно распространенное явление и этот масштаб порой пугает. Не так давно видел в линкедин скриншот вакансии, где искали фронтенд-разработчика "с решёнными проблемами или хотя бы в терапии". То есть вариант, что человеку не нужен психолог или психотерапевт, уже не рассматривается. Второй пример: недавно одна дама устроила какой-то спор в домовом чате, а потом со словами "лучше поберегу менталку" закончила дискуссию. То есть человек в быту настолько часто употребляет термин "ментальное здоровье", что ей понадобилось ввести в свой лексикон жаргонизм, чтобы сократить термин.
Да и в целом все вокруг какие-то странные становятся - открываешь соцсети: у этого марафон осознанности, другой вон с утра щеголяет свеженачищенной чакрой, все вокруг знают наизусть названия антидепрессантов и успокоительных. Это всегда так было что ли?
Тут суть не в арифметике, а в логике работы веб-приложений. Само собой, что десять маленьких файлов - это модули, которые будут грузиться не на одной странице, а на разных. И пользователь при переходе с одной страницы на другие будет догружать необходимые стили. А если всё это упаковать в один единственный файл, то он загрузится только один раз, а при переходе по внутренним страницам будет браться из кэша, что в итоге сильно снизит количество сетевых запросов, ускорит отрисовку самих страниц плюс снимет нагрузку с сервера.
Естественно,что при общем объёме стилей в 10МБ это не сработает, но истина где-то по середине: стили можно дробить, но не слишком мелко. Условно говоря, если в файле всего 10 строчек, то время, затраченное на его загрузку по большей части будет состоять из времени на постановку запроса в очередь и установку соединения, и если его разделить на два файла по 5 строк, то эти два файла суммарно будут грузиться дольше.
И ещё один очень забавный момент: у CSS-чанков обычно хэшированные имена, лежат они в папке с длинным именем и могут иметь гет-параметры. Так вот, иногда длина URL CSS-файла может оказаться больше, чем его содержимое. То есть, если в HTML-документ вместо URL сразу инлайново запихнуть содержимое чанка, размер HTML уменьшится.
Если стиль нужно использовать точно такой же, то проблем нет. А если в один компонент нужно применить стили из двух, то нужно из двух объектов клеить один и присваивать его. А на выходе это скомпилируется в набор CSS-правил, которые уже описаны в двух других местах. То есть итоговое количество стилей увеличится.
Это не библиотека стилей, а библиотека, чтобы писать стили на javascript. Ничего перезаписывать там не приходится. Но в данном случае проблема в том, что повторно использовать что-либо будет либо неудобно, либо неэффективно с точки зрения производительности