> непонятная мутота в кроне с рутовыми правами на боевом сервере
Уже давно нет. Для корректной работы certbot достаточно запускать его под самым урезанным юзером, который должен иметь права на запись в единственную папку (как правило называется .well-known) в document_root. Проставить симлинки на сертификаты или запилить тупой скрипт копирования по крону можно и руками единоразово.
Как я понимаю, автора спрашивать смысла нет, но может быть кто-то из присутствующих пользуется этим ноутом: как там дела со всякими залочками, UEFI и прочим ненужным хламом, из-за которого другую ОС поставить нельзя или затруднительно?
php — замечательный язык, который позволяет быстро и малыми силами добиваться поставленных целей в одной достаточно четко очерченной области. Со своими минусами — куда без них. Но минусы в большинстве своем простые, явные и их довольно легко обойти, не впадая в борьбу с языком (как это бывает во многих популярных языках, ага). Так что совершенно непонятны нападки на него со всех сторон в течение последних лет. Складывается впечатление, что вместо того, чтобы выбрать правильный инструмент и делать дело, людям интереснее изливать свои печали в бложиках :(
В fetch — нельзя. https://github.com/whatwg/fetch/issues/27 Ибо cancelable promises еще не завезли. Возможно в каких-то имплементациях и можно, но это явно отсебятина, поскольку спек еще даже не драфт. Так что кому нужны отменяемые запросы — да, superagent почти единственный выбор, если не хочется возиться с низкоуровневым доступом.
Какая разница, каков состав boilerplate, если его все равно необходимо осваивать? Оптимальный boilerplate для старта новых проектов — всегда и исключительно — _знакомый_ конкретному разработчику или команде boilerplate. Иначе старт может, мягко говоря, затянуться.
Не согласен. Знание фреймворков не кажется определяющей компетенцией для фулстэка. А вот понимание того, как всё работает — кажется, потому что при наличии такого понимания новый фреймворк изучается и встраивается в процесс за несколько дней, в худшем случае — за пару недель.
Думаю вы правы, что это обыкновенное стремление снизить затраты за счет найма одного человека-оркестра вместо двоих, а то и троих :) И насчет развития узких специалистов до фулстэкеров — тоже объяснимо, если принять во внимание стремление к взаимозаменяемости людей в команде.
Мне кажется, ваша боль не от фулстэка как такового, а от неадекватной самооценки кандидатов в каждом втором резюме. Так это и не у фулстэкеров встречается сплошь и рядом. А фулстэк на то и фулстэк, чтобы уметь поднять веб-продукт целиком и уметь смотреть на систему в целом. Да, это требует колоссального количества познаний. Но невозможного в этом я ничего не вижу.
По сути все паттерны сводятся так или иначе к идее введения дополнительного уровня абстракции. Различаются только способы взаимодействия между уровнями. По идее эти способы могут быть очень гибкими и не ограничиваться только общепринятыми шаблонами. Почему и зачем насаждаются конкретные реализации, под которые люди начинают подгонять свой код (вместо того, чтобы на основе базовой идеи создать наиболее подходящее в конкретном случае взаимодействие) — мне лично не очень понятно.
А вы не находите, что сознательное применение инструмента существенно отличается от случайного? То, что об использовании системного анализа никто не говорит — не означает, что использование не имеет места. Особенно в свете того, что таким вещам, как декомпозиция и стратификация обучают на младших курсах практически во всех технических университетах, не особо упоминая об их отношении к системному анализу, а иногда и не упоминая сами названия методов.
Автор, поработай над стилем. Плюс в карму за в целом верные мысли, но если бы мог поставить два минуса за стиль публикации — поставил бы.
Насчет идей к статье — ООП это про моделирование предметной области в целом и конкретных ее объектов в частности. Было бы неплохо отталкиваться от концептуального понятия модели, тогда всё станет еще красивее.
По ссылке эталонный пример неосилятора ООП типа «мне сказали что будет хорошо, а оказалось что надо думать головой». В текущей же статье, несмотря на отвратительный стиль изложения, мысли в целом верные.
Не соглашусь, от всепроникающего mutable state — баги скорее типа «кто-то где-то обновил, но непонятно кто и откуда» :) Т.е. грубо говоря, в первом случае проблема в рассинхронизации состояний (которые каждое само по себе консистентно), а во втором — в неконсистентности (но состояние одно и оно синхронизовано).
Кажется, вы путаетесь в понятиях. Иммутабельность не является несовместимой с императивностью, так же как и чистота функции таковой не является. Так или иначе, возвращаясь к исходному вашему комментарию — не понимаю, что именно вы хотите донести.
Без доказательств принимаются только религиозные аргументы. Мне прекрасно известны доказательства того, что чистые функции хороши. Автор сего опуса не утрудил себя их приведением, именно поэтому к нему отношение как к очередному недалекому адепту. Если бы привел — отношение было бы чуть лучше, примерно как к капитану очевидность. Однако ни первый, ни второй случай не тянут на статью.
Как же надоели уже стереотипные фанатики ФП, а. Из всех щелей лезут. И ладно бы умные вещи говорили, так очередная капитанская пурга про реакт, редакс и то, что чистые функции и иммутабельные структуры это круто. Причем без обоснований и доказательств (которые, впрочем, уже тоже набили оскомину). И мне кажется, именно такие люди (что автор, что переводчик) оказывают популяризации ФП медвежью услугу.
Уже давно нет. Для корректной работы certbot достаточно запускать его под самым урезанным юзером, который должен иметь права на запись в единственную папку (как правило называется .well-known) в document_root. Проставить симлинки на сертификаты или запилить тупой скрипт копирования по крону можно и руками единоразово.
47. Write some code :(
Какая разница, каков состав boilerplate, если его все равно необходимо осваивать? Оптимальный boilerplate для старта новых проектов — всегда и исключительно — _знакомый_ конкретному разработчику или команде boilerplate. Иначе старт может, мягко говоря, затянуться.
Насчет идей к статье — ООП это про моделирование предметной области в целом и конкретных ее объектов в частности. Было бы неплохо отталкиваться от концептуального понятия модели, тогда всё станет еще красивее.