8. Клиенты не могут сказать, сколько готовы заплатить
Когда мне присылают опрос типа: «Готовы ли Вы за это платить» или «Готовы ли Вы платить за эту услугу больше?», я всегда отвечаю — нет. Просто потому, что зачем мне платить больше, если можно не платить или платить столько же. Если бы пользователи отвечали: «Да, повысьте мне цену, пожалуйста, я слишком мало вам плачу», это было бы как минимум странно.
8. Клиенты не могут сказать, сколько готовы заплатить.
— я далёк от монетизации сайтов, но неоднократно читал о таком варианте решения проблемы, как случайная цена в каких-то пределах. То есть каждому пользователю дают какую-то случайную цену и смотрят на конверсию — какой процент человек согласились заплатить, и сколько прибыли принес каждый из вариантов цен. Исходя из этого уже и выбирают конечный вариант.
У Вас тут явно масса проблем. Этот подход не применим в приложениях хотя бы мелкого размера. Возможно только в совсем крохотных, где весь код можно уместить в голове.
По пунктам:
Почему ваш код находится в пространстве App\Http\Controllers ?
Если речь идёт про DDD. То надо было реализовать всю логику приложения в отдельном пространстве. Вообще не в папке с Laravel. Где то в /src/. Вот туда надо было складывать ваши абстрактные репозитории. А на Laravel лишь реализовывать адаптеры, по интерфейсам. А вообще, делать универсальный репозиторий — идея так себе. На практике это не работает. Хоть они и похожи, всегда есть отличия. Тут надо событие бросить, тут что то не сохранять. В итоге каждый репозиторий будет иметь методы, которые будут перегружать методы родительского класса. Лучше делать отдельный, несвязанный реп, к каждой из сущностей. Так будет проще впоследствии.
У вас репозиторий сетит в себя модель при инстанцировании, что потом приведет к проблемам. Что делать если вы захотите создать сразу 3 объекта Pizza?
В create должна быть фабрика.
$class = get_class($this->model);
$newObj = new $class();
$newObj->fill($data);
return $newObj;
Сортировка как свойство класса? Really. Ну на вкус и цвет конечно, но видать вы еще не усвоили, что использование явных параметров в функциях лучше, чем свойства объектов. Все потому что у вас в классе 6 методов, а сортировку используют лишь 2. Подумайте об этом.
$this->model->hydrate, опять же, используйте статичные фабричные методы. {Model}::hydrate() или по аналогии с п.3
Ну и ответ на вопрос: — как справиться с жадной загрузкой?
Ответ: Не использовать. Да как бы привлекательно это ни было.
На край — не должна покидать пределы репы.
Проект открытый, создайте ишью, отправьте пул реквест, создайте свой собственный менеджер пакетов, вам никто ничего не должен из разрабов npm'а, они вроде добровольно всем занимаются. Впрочем, всего этого даже не надо делать: yarn сейчас наиболее близок к composer'у, поэтому если есть желание — можно использовать просто его.
Там дело в том, что команда npm i изменяла существующий package-lock.json на новый, как написано в док-ции к этому файлу:
package-lock.json is automatically generated for any operations where npm modifies either the node_modules tree, or package.json.
Теперь у нас есть команда npm ci, которая не будет изменять этот файл, обновляя зависимости проекта на самые последние, вместо этого он будет устанавливать строго то, что содержится в этом файле.
Все хорошо, полезное улучшение. Но непонятно, почему так много времени понадобилось для реализации такой простой идеи — устанавливать модули по package-lock.json, невзирая package.json.
Складывается впечатление, что сами разработчики npm своим детищем не особо пользуются, и хорошим практикам ci не следуют
Не отчаивайтесь, зато теперь вы знаете как работает initramfs — а это уже половина дела, все что вы описали в статье применимо так же и к LTSP.
LTSP просто предоставляет вам набор скриптов который сильно упрощает жизнь. :)
К примеру: ltsp-chroot — что бы установить софт или внести другие изменения. ltsp-update-image — и у вас новый squashed образ. ltsp-update-kernels — и у вас готовый конфиг с новыми ядрами для pxelinux.
В оперативную память должен помещаться сжатый образ системы, и должно оставаться место для запуска программ.
Собираемый по-умолчанию образ с LXDE работает на 1 Гб оперативки, сам образ весит 330 Мб(вместе с initrd и ядром). Причём top после загрузки показывает, что занято 400 Мб, а ещё 600 осталось для программ, а с учётом zram там поместится раза в полтора больше.
Если убрать LXDE, оставить только X и какой-нибудь легковесный WM, то возможно получится завестись на 768 Мб.
Эти локальные копии появились и до high sierra и место занятое под этот бакап показывается когда жмешь информации по этому маку. Сиреневый цвет кажется. Как это можно не заметить?
Для этого в Time Machine есть настройка папок-исключений, которые не уходят в резервную копию.
Я себе там оставил только рабочие папки. И всякий временный «факл» идет мимо локального бекапа.
PS: Сомневаюсь что для Apple в этом есть какая-то польза, может допишут и опять заработает «sudo tmutil disablelocal».
Я столкнулся с другой неприятной проблемой в High Sierra: после нескольких часов паботы, ОС начинает делать большое количество операций записи на диск (до 100 Гб в час при ~30 Гб свободного места). С SSD последнего поколения изменение производительности при такой интенсивной записи субъективно сложно заметить, так что саму проблему я обнаружил случайно, изучая нагрузку на диск в Activity Monitor.
Несмотря на относительную «живучесть» современных SSD, конкретно для моей модели ресурс диска при таком режиме работы может быть исчерпан всего за три года непрерывной работы. И при этом диск заменить нельзя, ноутбук можно выбрасывать.
В корневых причинах разобраться пока не удалось, но практическим путем я нашел два фактора, которые, по-сидимому, сильнее других влияют на интенсивность записи:
1) индексирование папок с большим количеством объектов в Spotlight
2) активное использование свопа
Удалив из индекса Spotlight папку с проектами (включающую в себя в том числе множество модулей в node_modules), контролируя использование оперативной памяти и свопа, а так же каждый день выключая ноутбук, я добился снижения интенсивности записи до 5-10 Гб/час, но осадочек остался, конечно
Локальные бэкапы в Mac OS делались и до APFS, но в High Sierra их отключить нельзя.
Они храняться не в черной дыре а в папке /Volumes/com.apple.TimeMachine.localsnapshots/
Локальные копии ускоряют следующую резервную копию на внешний диск, поэтому их удалять не стоит.
Чтобы их удалить не надо никаких команд, ничего гуглить. Просто сделать еще одну резервную копию на внешний диск и все будет туда перемещено, получите свободное место и более детальную резервную копию.
Того всем и желаю, не забывайте чаще делать резервные копии.
Честно скажу, что su -c "ifconfig hw ether {один из интересных маков с premium: true}" после включения wi-fi модуля работает лучше практически любого решения, т.к особо нет вариантов защититься от смены мака.
Но таких интересных маков скорее всего нет на моей странице vk.
Когда мне присылают опрос типа: «Готовы ли Вы за это платить» или «Готовы ли Вы платить за эту услугу больше?», я всегда отвечаю — нет. Просто потому, что зачем мне платить больше, если можно не платить или платить столько же. Если бы пользователи отвечали: «Да, повысьте мне цену, пожалуйста, я слишком мало вам плачу», это было бы как минимум странно.
Есть такая хорошая архетиктура, обделенная статьей на хабре — Proto, реализованная на Laravel в проекте Apiato
Суть примерно та же. Голый MVC в том виде в котором он есть в Laravel недостаточен.
У Вас тут явно масса проблем. Этот подход не применим в приложениях хотя бы мелкого размера. Возможно только в совсем крохотных, где весь код можно уместить в голове.
По пунктам:
Почему ваш код находится в пространстве App\Http\Controllers ?
Если речь идёт про DDD. То надо было реализовать всю логику приложения в отдельном пространстве. Вообще не в папке с Laravel. Где то в /src/. Вот туда надо было складывать ваши абстрактные репозитории. А на Laravel лишь реализовывать адаптеры, по интерфейсам. А вообще, делать универсальный репозиторий — идея так себе. На практике это не работает. Хоть они и похожи, всегда есть отличия. Тут надо событие бросить, тут что то не сохранять. В итоге каждый репозиторий будет иметь методы, которые будут перегружать методы родительского класса. Лучше делать отдельный, несвязанный реп, к каждой из сущностей. Так будет проще впоследствии.
В create должна быть фабрика.
Сортировка как свойство класса? Really. Ну на вкус и цвет конечно, но видать вы еще не усвоили, что использование явных параметров в функциях лучше, чем свойства объектов. Все потому что у вас в классе 6 методов, а сортировку используют лишь 2. Подумайте об этом.
$this->model->hydrate, опять же, используйте статичные фабричные методы. {Model}::hydrate() или по аналогии с п.3
Ну и ответ на вопрос: — как справиться с жадной загрузкой?
Ответ: Не использовать. Да как бы привлекательно это ни было.
На край — не должна покидать пределы репы.
Проект открытый, создайте ишью, отправьте пул реквест, создайте свой собственный менеджер пакетов, вам никто ничего не должен из разрабов npm'а, они вроде добровольно всем занимаются. Впрочем, всего этого даже не надо делать: yarn сейчас наиболее близок к composer'у, поэтому если есть желание — можно использовать просто его.
Там дело в том, что команда
npm iизменяла существующийpackage-lock.jsonна новый, как написано в док-ции к этому файлу:Теперь у нас есть команда
npm ci, которая не будет изменять этот файл, обновляя зависимости проекта на самые последние, вместо этого он будет устанавливать строго то, что содержится в этом файле.Более подробно об особенностях
npm ciможно, опять же, почитать в документации к этому методу.Наверное, хорошо было бы немного прояснить этот момент в документации, да, ибо я согласен, что это немного сбивает с толку.
Большой и сложный проект + малое число контрибьютеров. Основных разрабов там два человека, как я понимаю.
Все хорошо, полезное улучшение. Но непонятно, почему так много времени понадобилось для реализации такой простой идеи — устанавливать модули по package-lock.json, невзирая package.json.
Складывается впечатление, что сами разработчики npm своим детищем не особо пользуются, и хорошим практикам ci не следуют
Не отчаивайтесь, зато теперь вы знаете как работает initramfs — а это уже половина дела, все что вы описали в статье применимо так же и к LTSP.
LTSP просто предоставляет вам набор скриптов который сильно упрощает жизнь. :)
К примеру:
ltsp-chroot— что бы установить софт или внести другие изменения.ltsp-update-image— и у вас новый squashed образ.ltsp-update-kernels— и у вас готовый конфиг с новыми ядрами для pxelinux.Если бы этот комментарий появился в 2013 году, описанное в статье решение вероятно не было бы создано :)
Думаю, мой вариант выигрывает в простоте настройки, но возможностей у LTSP наверняка больше и поддержка лучше.
Сейчас уже поздно, завтра добавлю к списку альтернатив помимо Thinstation ещё и LTSP.
Посмотрел, специализированный дистрибутив, в том числе нацеленный на минимальный размер, конечно оно легче немного обрезанной стандартной убунты.
Впрочем, сейчас железо меньше чем с гигабайтом памяти просто не найдёшь.
В оперативную память должен помещаться сжатый образ системы, и должно оставаться место для запуска программ.
Собираемый по-умолчанию образ с LXDE работает на 1 Гб оперативки, сам образ весит 330 Мб(вместе с initrd и ядром). Причём top после загрузки показывает, что занято 400 Мб, а ещё 600 осталось для программ, а с учётом zram там поместится раза в полтора больше.
Если убрать LXDE, оставить только X и какой-нибудь легковесный WM, то возможно получится завестись на 768 Мб.
Я себе там оставил только рабочие папки. И всякий временный «факл» идет мимо локального бекапа.
PS: Сомневаюсь что для Apple в этом есть какая-то польза, может допишут и опять заработает «sudo tmutil disablelocal».
Я столкнулся с другой неприятной проблемой в High Sierra: после нескольких часов паботы, ОС начинает делать большое количество операций записи на диск (до 100 Гб в час при ~30 Гб свободного места). С SSD последнего поколения изменение производительности при такой интенсивной записи субъективно сложно заметить, так что саму проблему я обнаружил случайно, изучая нагрузку на диск в Activity Monitor.
Несмотря на относительную «живучесть» современных SSD, конкретно для моей модели ресурс диска при таком режиме работы может быть исчерпан всего за три года непрерывной работы. И при этом диск заменить нельзя, ноутбук можно выбрасывать.
В корневых причинах разобраться пока не удалось, но практическим путем я нашел два фактора, которые, по-сидимому, сильнее других влияют на интенсивность записи:
1) индексирование папок с большим количеством объектов в Spotlight
2) активное использование свопа
Удалив из индекса Spotlight папку с проектами (включающую в себя в том числе множество модулей в node_modules), контролируя использование оперативной памяти и свопа, а так же каждый день выключая ноутбук, я добился снижения интенсивности записи до 5-10 Гб/час, но осадочек остался, конечно
Они храняться не в черной дыре а в папке /Volumes/com.apple.TimeMachine.localsnapshots/
Локальные копии ускоряют следующую резервную копию на внешний диск, поэтому их удалять не стоит.
Чтобы их удалить не надо никаких команд, ничего гуглить.
Просто сделать еще одну резервную копию на внешний диск и все будет туда перемещено, получите свободное место и более детальную резервную копию.
Того всем и желаю, не забывайте чаще делать резервные копии.
PS: Никак не ожидал такой статьи от Parallels.
Честно скажу, что
su -c "ifconfig hw ether {один из интересных маков с premium: true}"после включения wi-fi модуля работает лучше практически любого решения, т.к особо нет вариантов защититься от смены мака.Но таких интересных маков скорее всего нет на моей странице vk.
Там всё равно работает view-source, насколько я помню. Вбей мануально в адресную строку
view-source:http://auth.wi-fi.ru/auth.