Как стать автором
Обновить
-2
0
Дэн @iit

php backed + js frontend

Отправить сообщение

Хм, этого конечно не учел. Как обновлю машину надо будет посмотреть.


С другой стороны чтение будет в любом случае random при любом размере swap.


Не разбираюсь в низкоуровневых механизмов работы с памятью на уровне ос. Но предполагаю что должен быть некий индекс который точно помнит на каких секторах диска какие страницы памяти записаны и скорее всего он динамический и содержит только фактически записанные на диск страницы. В этом случае большой swap лишь увеличит размер этого индекса и то — только в том случае если фактически потребляемая память действительно вырастет до этого объема и будет вытеснена на диск в остальное время будет зарезервирована и фактически не использована — что для твердотельных накопителей скорее будет в плюс.

Товарищи минусующие аргументировать минусы будем? нет?!

Даже если было бы 256гб — заложил бы пол TB на отдельном диске, и точно не там где boot и ядро


Тем более что сейчас ssh nvme на 1-2 TB стоят достаточно адекватно.


Для windows не актуально — там ось сама расширяет swap по необходимости. Для nix тоже есть такая возможность но этим лучше не злоупотреблять.


С другой стороны сейчас у меня всего 8gb и swap на отдельном старом ssd в 16gb спасает еще как. Хотя когда закладывал — думал как и все остальные (нахрена 16 gb — браузер жрет больше всего и в то время максимум съедал 200мб). А оно вон как сейчас вышло. Хорошо что умный человек еще в те давние времена сказал — не отключай swap и всегда выставляй его в виде ram * 2 или хотя-бы просто размером с ram.


Правда забил я его почти полностью только один раз — когда запустил не оптимизированный скрипт парсера на php и натравил его на 5gb xml — но ничего не упало — наоборот через 48 часов получил ожидаемый результат.


После я конечно рефакторил этот скрипт 8 раз и итоговый вариант выполнился за 8 минут. Но оптимизировал его месяц копаясь с xprofile. Первый результат от разбора первого файла нужен был до конца недели.


Понимая что обычный вариант парсера считывает весь xml в память а после мапит его на массивы/объекты — написал потоковый парсер на конечном автомате, отказался от mysql в пользу postgres и на него переложил построение древовидной иерархии данных — которые получал из xml (категории с под-категориями на 5 уровней вложенности)

Всегда оставляю под swap размер текущая память * 2

Основная проблема не в этом а в том что все это прибито намертво гвоздями в ядре.


В тем проблема вынести это в отдельный service provider и дать выбор пользователю самому решить где и что в каком виде хранить?


В итоге приходиться делать патч на ядро а это боль и при обновлении все это слетит.

Laravel хорош для новичка — все из коробки, просто развернуть, просто работать — но как только появляется необходимость что-то поменять в ядре — жизнь боль, Job's если поменять параметры конструктора — тоже валяться на раз два. При работе с миграциями — необходимо быть предельно осторожным.


Symfony — монстр с решениями на все случаи жизни, но на его изучение также придется потратить пару жизней.


Zend — раньше жил только за счет его форса ZendFoundation и был жутко неудобной страшной штукой. Сейчас (Laminas) даже не смотрел.


Yii — Собран на коленке для создания проектов на коленке, после laravel покажется жутко не удобным.


Phalcon — был актуален на php5.6 так как работал намного быстрее всего что было тогда — за счет того что ядро скомпилировано как плагин php. При php >= 7.0 уже почти не имеет смысла так как из самого php выжали почти все возможное и теперь дожимают остальное.


Все остальное — уже жуткий legacy — проще с нуля собрать свой фреймворк с помощью php-di

js разминифицировать реально тем более что многие оставляют открытыми map файлы которые позволяют еще и получить исходный код как есть.


Тут же мы получим аналог asm для некоторой виртуальной машины — исходный код не поучить. Без хорошего знания ассемблера и LLVM понять что же делает этот маленький пакет на 620кб который визуально ничего не делает — доступно только избранным.

А мне нравился flash — он был тупо прост и при нем был просто сумасшедший удобный редактор анимации.


Помню как мы на 1-м курсе по фану делали на нем простенькие игры и анимацию, при этом из программирования мы знали только циклы и логические условия. Но даже такого минимума хватало чтобы написать свою игрушку или анимацию чисто по приколу.


Например один из одногрупников на коленке за неделю сделал двумерный файтинг где персонажами были другие одногрупники в стиле southpark. Багов была конечно куча но было дико весело. Сейчас для этого нужно уже изучать какой либо движок, уметь нормально кодить а модели импортировать с шаманскими танцами из других редакторов.

Мало того кроме чувства прекрасного, академических знаний на тему того как люди воспринимают цвета и изображения (в том числе и дальтоники).


Необходимы:


  • Сугубо технические знания о том что возможно реализовать на той или иной платформе (web/desktop/mobile/embeded) и насколько это трудозатратно.
  • Понимание того что приложение это не только красивая картинка но и набор состояний переход между которыми должен быть в должной степени продуман и анимирован.
  • Понимание что дизайн страницы должен адаптироваться под контент и выглядеть адекватно при любом контенте а на пограничные случаи должны быть продуманны и задокументированы ограничения. Например на количество символов текста на кнопках.
  • Умение создать брендбук и единый корпоративный стиль в том числе и UI-KIT чтобы логотип/сайт/приложение/рекламные и подарочные материалы были оформлены в одном стиле и не вызывали отторжения или недоумения.
  • Помимо всего этого еще и уметь создать дизайн под конкретную целевую аудиторию — например контент который например будет интересным "для девушек 18-20 лет со средним доходом без детей" или для "пожилых людей со слабым зрением, отторжением к современным технологиям но желающим про инвестировать свои накопления для внуков"
  • Обладанием понимания авторских прав и поиска только тех ресурсов которые разрешены для включение их в другие материалы и соответственно опытом создания уникального контента
  • Пониманием того как конкретная целевая аудитория будет использовать продукт и реагировать на различные состояния продукта в том числе и не стандартные.
  • В случае материальных продуктов еще знать ограничения и свойства материалов при определенных температурах и нагрузках, тактильные ощущения от различных материалов, доступность и цены этим материалов.
  • Еще плюсом будет нестандартное мышление и умение удивлять и манипулировать сознанием или эмоциями через свое творчество.

Для этого конечно не всегда нужно 5-10 лет опыта конкретно на такой позиции. Но и двух недельный курс не сделает из вас такого человека. Для этого однозначно необходимо нестандартное воспитание и огромный жизненный опыт.


Сам знаю только 3 подобных и только с одним работал над общими проектами — и это было круто.

Понимаю боль автора. В larevel ядро жестко захардкожено и патчить что-то в нем — лютый ад.
Мало того при обновлении версии патчить нужно все заново.


В свое время патчил authorization когда еще не было socialite для входа через oAuth2.0, патчил логи так как monolog умел нужный мне провайдер а вот laravel нет. Патчил models для graphql. В общем жизнь боль.


Хорошо постепенно в laravel появилась поддержка всего этого из коробки.

Хм, надо попробовать!

То есть по сути нечто по паттерну Observer либо publisher-subscriber ?

То есть по сути — вы не пишете свою Kafka с нуля. А используете те части интерфейса пакета которые отвечают за producer и consumer?

Хм, интересно. Можно будет ссылку на карты?

Эмм и часто приходиться писать свои базы данных ?

Скорее не сменил а расширил. Был только backend теперь fullstack.


Постоянно делать одно и тоже на одном и том же стеке оно конечно и удобно и даже прибыльно. Но вот поковырять и другие технологии тоже полезно и интересно. Да java тоже доберусь постепенно.

с PHP, где долгоживущие сервисы писать было больно

Да и сейчас больно. Но и смысла в долго живущих сервисах не так много. Сервисы с api где достать данные и выдать в определенном формате и возможно закешировать — проще простого.


Если нужно обработать поток данных то RabbitMq или Kafka + php тоже все ок.


Так что остается только стримы аудио и видео — там да постоянно открытый сокет и постоянно живущий сервис. Вот только с этим и голый nginx справляется на отлично.
Если же нужна еще и модификация этого контента на лету — тогда да тут и подключаются go/java/python/etc...

Ну так после 2010 я пересел на стек с php, видел что да на GlassFish все действительно стартует быстро но мне уже на это было как-то пофиг. Поле 2018 пересел на node.js.
Далее по плану нормально изучить Ceph + k8s а после уже думаю развиваться в сторону go/rust/python.


На java за это время — написал только один сервис допилил — добавил в него провайдер который берет сертификат X.509 с хитрыми алгоритмами ГОСТ и подписывает XML. И то это так — считай ничего и не написал.

И самое забавное что все это было еще со времен Java 6.


Но приколы с патентами от Oracle, куча платных библиотек которые сегодня есть а завтра уже история и распространяются только в уже скомпиленном виде без возможности модификации, лагающий Eclipse на основе которого +100500 IDE. Сложность всего этого добра для освоения ( я еще студентом бросил Java в web после того как попытался понять web.xml от tomcat ) превращаются в лютый Ынтенпрайз от которого стынет кровь в жилах. Про JavaEE "hello world" только ленивый не шутил.


Сейчас времена поменялись — есть Idea которая шикарна и позволяет компилироваться только ту часть байт-кода которая поменялась а не ждать 10 часов из за изменений в 2-х строчках, есть Android. OpenESB и Apachee Talend тоже шикарные вещи которые использовал. Для запуска одиночного сервиса не нужно долго подымать JavaEE сервер — достаточно упаковать его в тот-же docker.


Только время уже упущено и на все это смотрят как на жуткое legacy а Oracle все еще пугает патентами. Тот-же Google вынужден платить, терпеть и пилить матерясь про себя свою Fuchsia.

У меня старший брат авто-электрик, и у него есть внезапно ВСЯ документация и ВСЕ спецификации по всем моделям с 2008 года по 3 маркам машин которые он ремонтирует.


Начиная от того где какой агрегат расположен, заканчивая схемами всех плат автомобиля и исходниками разрешенной к модификации программной части и дампами закрытой программной части.


Да — для того чтобы получить это все нужно пройти обучение и сертификацию и оплатить все лицензии и это ДОРОГО.


Если следовать такой аналогии — то Apple должна предоставить любому китайцу возможность пройти обучение и сертификацию для того чтобы собрать или починить любую модификацию iphone с нуля в том числе и кастомную. Любому разработчику предоставить открытые исходный код ос и обучить собирать все это.


А для того чтобы не реверсили конкуренты и не выгнали с рынка — добавить один проприетарый чип с apple id и одну проприетарую библиотеку для работы с эти чипом.


Но вот только так никто не делает, ни apple ни google ни ms. Canonical попыталась но не хватило зубов.

Информация

В рейтинге
Не участвует
Откуда
Алматы (Алма-Ата), Алма-Атинская обл., Казахстан
Дата рождения
Зарегистрирован
Активность