Не обязательно. Я начинал со Спектрума и БК и мне наоборот интересны платформы, которые прошли мимо меня, тот же упомянутый Commodore VIC-20, недавно собрал реплику югославской Galaksija, пописываю всякое под неё. И, насколько я вижу, в среде ретро-железячников такое не редкость.
Веб никуда не денется без хранения состояния бэка на клиенте, в том или ином виде. Это неизбежное зло. Хотя бы идентификатор сессии хранить на клиенте нужно, а это уже "состояние". Также очевидно, что абсолютно любые данные, приходящие на бэк с клиента должны быть проверены и отфильтрованы перед использованием. В случае с сериализованными сущностями, такую проверку придется делать дважды, перед десериализацией и после, так как "использование" идет уже при десериализации, неявным образом. Вот и все, что я хотел сказать.
Мне кажется тут дело совсем не в архитектуре фреймворка а именно в механизме сериализации и десереализации объектов. Предположим какой то сайт на той же Ларе решит хранить какие то пользовательские настройки в куках в виде сериализованного массива. Скажете так не бывает? Да сплошь и рядом. Это же выглядит безопасно? Вроде да. А если злоумышленник заменит в своих куках сериализованный массив на сериализованный объект, в котором будет магический метод __wakeup , в котором произвольный код? Который будет выполнен автоматически в том месте, где вызывается unserialize. Нужно или проверять до десериализации, а что же нам пришло - массив или объект, разбирая сериализованную строку на низком уровне. Или не использовать сериализацию там, где сериализованные данные могут быть модифицированы на стороне пользователя.
Прошу прощения, вы писали не "передать запрос" а "отправить запрос". Но двусмысленности, лично в моём его воспроятии, ничего не меняет. Возможно у меня уже профессиональная деформация, но в реальности так часто встречается ситуация, когда под вполне формально определенным понятием имеют в виду не совсем то, а иногда и совсем не то, что я лучше покажусь чудаком и два раза уточню, что имеется в виду. Вам тоже спасибо за интересную искуссию!
Никакого фантазирования у меня нет, я препарирую на части написанный вами же вопрос "можно ли передать запрос". Мне действительно последние лет 15 не приходилось проходить собеседования, собеседую в основном я. Поэтому я действительно не понимаю, что сейчас ждут - формального ответа "по учебнику" или всё таки более глубокого погружения в саму суть вопроса. Вы вероятно практикуете первый подход, для меня лично важен второй.
Проблема в том, что лично я, исходя из своего опыта не знаю, что для вас "причём" и какой ответ вы примете как верный. К примеру, если бы мне был задан такой вопрос на собеседовании, я бы подумал, что в вопросе есть какой то подвох, связанный с неоднозначностью, на мой взгляд, самой формулировки "передать запрос". И я бы точно уточнил у собеседующего, что он имеет в виду, формальную сторону (формальное название метода в HTTP-запросе) или фактическую (место размещения "тела" запроса в HTTP-запросе).
Я к тому что он у вас сформулирован так, что лично у меня вызывает ощущение двоякости, хотя я начинал работу с HTTP с обработчиков на чистом C и к PHP пришёл спустя много много лет после этого. С одной стороны, формально метод действительно задаётся в заголовке HTTP запроса и двоякости тут быть не может. С другой стороны, ничего не мешает часть параметров запроса передать в части query а не body.
У меня обратное практические наблюдение. В студенческие годы (95-99 годы) частенько занимались тем, что помогали преподавателям верстать методички с большим количеством "многоэтажных" формул . И честно пробовали применить для этого LaTeX. И ни у кого не хватило сил и времени освоить его настолько, чтобы хотя бы приблизится по скорости работы к Word 6.0 с Microsoft Equation. Возможно после 500 часов работы (это более 2 месяцев работы по 8 часов), но никого из тех, кого я знаю, на это не хватило.
Не обязательно уметь писать свою сортировку. Но хотя бы примерно представлять сложность популярных алгоритмов сортировки нужно даже джуну-фронту. Хотя бы чтобы не использовать сортировку для вывода минимального-максимального значения (вы считаете что никто в здравом уме так делать не будет? да щаззз!)
4 года прошло с момента написания поста. В этом году исполняется 40 лет с момента выпуска компьютера Galaksija. В связи с этим Войя Антонич разработал новую версию Galaksija 2024. В основном она повторяет исходную схему за исключением нескольких моментов:
использование микросхем 74HCT вместо 74LS (К555...)
корректировка под тайминги CMOS версии процессора Z80A
частота тактового генератора 6 МГц, соответственно поправлена схема делителей, где из неё получаются частоты кадровой и строчной развертки изображения
отсутствие магнитофонного и интерфейсного разъёмов и замена их на SPI флешку 512 килобайт с возможностью подключения ПК.
переразведенная плата
В остальном это старая добрая Галаксия на выводных компонентах (кроме SPI флешки).
Я не удержался и заказал печатную плату, сейчас заканчиваю сборку.
Для большинства людей Commodore 64 ассоциируется с играми. Но фактически он был универсальной платформой со множеством аксессуаров и отлично подходил для решения офисных задач.
К сожалению это не так, из за экстремально низкой скорости дисковых операций на большинстве доступых дисководов C64 очень плохо подходил для офисной работы. Самый популярный дисковод 1541 обеспечивал скорость чтения-записи 400 БАЙТ в секунду. Виной тому подключение дисковода через последовательный порт и аппаратная ошибка в микросхеме порта 6522.
Государства (точнее силовые структуры, находящиеся в подчинении оного) занимались, а кое где ещё и продолжают заниматься ровно тем же самым. См. концепцию государства как стационарного бандита Мартина Макгуайра.
Для интереса посмотрел код коммерческих модулей из Marketplace Bitrix - в основном используют такой же подход, вешают на OnBeforeProlog модуля main. Многие даже в "старом" стиле через RegisterModuleDependences а не registerEventHandler.
У меня есть нож, точнее мультитул у которого есть, в том числе 2 лезвия, который летает со мной по миру уже лет 8. И ни на одном досмотре никогда он не вызывал никаких вопросов. То есть даже вытащить не просили показать "а что это у вас такое". Хотя я 99.9% уверен, что режущая кромка (градиент убывания толщины металла) должны были как то отобразиться на интраскопе.
Моя первая XT-шка была Искра-1031. Тот же компьютер, что Искра-1030 но с другой корзиной и в другом, на мой взгляд, более удобном, корпусе.
Не обязательно. Я начинал со Спектрума и БК и мне наоборот интересны платформы, которые прошли мимо меня, тот же упомянутый Commodore VIC-20, недавно собрал реплику югославской Galaksija, пописываю всякое под неё. И, насколько я вижу, в среде ретро-железячников такое не редкость.
Да, благодарю за разъяснение!
Веб никуда не денется без хранения состояния бэка на клиенте, в том или ином виде. Это неизбежное зло. Хотя бы идентификатор сессии хранить на клиенте нужно, а это уже "состояние". Также очевидно, что абсолютно любые данные, приходящие на бэк с клиента должны быть проверены и отфильтрованы перед использованием. В случае с сериализованными сущностями, такую проверку придется делать дважды, перед десериализацией и после, так как "использование" идет уже при десериализации, неявным образом. Вот и все, что я хотел сказать.
Мне кажется тут дело совсем не в архитектуре фреймворка а именно в механизме сериализации и десереализации объектов. Предположим какой то сайт на той же Ларе решит хранить какие то пользовательские настройки в куках в виде сериализованного массива. Скажете так не бывает? Да сплошь и рядом. Это же выглядит безопасно? Вроде да. А если злоумышленник заменит в своих куках сериализованный массив на сериализованный объект, в котором будет магический метод __wakeup , в котором произвольный код? Который будет выполнен автоматически в том месте, где вызывается unserialize. Нужно или проверять до десериализации, а что же нам пришло - массив или объект, разбирая сериализованную строку на низком уровне. Или не использовать сериализацию там, где сериализованные данные могут быть модифицированы на стороне пользователя.
Прошу прощения, вы писали не "передать запрос" а "отправить запрос". Но двусмысленности, лично в моём его воспроятии, ничего не меняет. Возможно у меня уже профессиональная деформация, но в реальности так часто встречается ситуация, когда под вполне формально определенным понятием имеют в виду не совсем то, а иногда и совсем не то, что я лучше покажусь чудаком и два раза уточню, что имеется в виду. Вам тоже спасибо за интересную искуссию!
Никакого фантазирования у меня нет, я препарирую на части написанный вами же вопрос "можно ли передать запрос". Мне действительно последние лет 15 не приходилось проходить собеседования, собеседую в основном я. Поэтому я действительно не понимаю, что сейчас ждут - формального ответа "по учебнику" или всё таки более глубокого погружения в саму суть вопроса. Вы вероятно практикуете первый подход, для меня лично важен второй.
Проблема в том, что лично я, исходя из своего опыта не знаю, что для вас "причём" и какой ответ вы примете как верный. К примеру, если бы мне был задан такой вопрос на собеседовании, я бы подумал, что в вопросе есть какой то подвох, связанный с неоднозначностью, на мой взгляд, самой формулировки "передать запрос". И я бы точно уточнил у собеседующего, что он имеет в виду, формальную сторону (формальное название метода в HTTP-запросе) или фактическую (место размещения "тела" запроса в HTTP-запросе).
Я к тому что он у вас сформулирован так, что лично у меня вызывает ощущение двоякости, хотя я начинал работу с HTTP с обработчиков на чистом C и к PHP пришёл спустя много много лет после этого. С одной стороны, формально метод действительно задаётся в заголовке HTTP запроса и двоякости тут быть не может. С другой стороны, ничего не мешает часть параметров запроса передать в части query а не body.
Мне вот интересно, а какой ответ вы ожидаете, как правильный?
У меня обратное практические наблюдение. В студенческие годы (95-99 годы) частенько занимались тем, что помогали преподавателям верстать методички с большим количеством "многоэтажных" формул . И честно пробовали применить для этого LaTeX. И ни у кого не хватило сил и времени освоить его настолько, чтобы хотя бы приблизится по скорости работы к Word 6.0 с Microsoft Equation. Возможно после 500 часов работы (это более 2 месяцев работы по 8 часов), но никого из тех, кого я знаю, на это не хватило.
Не обязательно уметь писать свою сортировку. Но хотя бы примерно представлять сложность популярных алгоритмов сортировки нужно даже джуну-фронту. Хотя бы чтобы не использовать сортировку для вывода минимального-максимального значения (вы считаете что никто в здравом уме так делать не будет? да щаззз!)
А вот и собранное изделие, пока без корпуса:
4 года прошло с момента написания поста. В этом году исполняется 40 лет с момента выпуска компьютера Galaksija. В связи с этим Войя Антонич разработал новую версию Galaksija 2024. В основном она повторяет исходную схему за исключением нескольких моментов:
использование микросхем 74HCT вместо 74LS (К555...)
корректировка под тайминги CMOS версии процессора Z80A
частота тактового генератора 6 МГц, соответственно поправлена схема делителей, где из неё получаются частоты кадровой и строчной развертки изображения
отсутствие магнитофонного и интерфейсного разъёмов и замена их на SPI флешку 512 килобайт с возможностью подключения ПК.
переразведенная плата
В остальном это старая добрая Галаксия на выводных компонентах (кроме SPI флешки).
Я не удержался и заказал печатную плату, сейчас заканчиваю сборку.
К сожалению это не так, из за экстремально низкой скорости дисковых операций на большинстве доступых дисководов C64 очень плохо подходил для офисной работы. Самый популярный дисковод 1541 обеспечивал скорость чтения-записи 400 БАЙТ в секунду. Виной тому подключение дисковода через последовательный порт и аппаратная ошибка в микросхеме порта 6522.
Для остальных дисководов данные по скорости можно посмотреть данные тут: https://singularcrew.hu/idedos/perf.php
Государства (точнее силовые структуры, находящиеся в подчинении оного) занимались, а кое где ещё и продолжают заниматься ровно тем же самым. См. концепцию государства как стационарного бандита Мартина Макгуайра.
Ну собственно у Хайнлайна в "Двери в лето" тоже самое было лаконично описано в двух, если не изменяет память, предложениях.
Можно загрузить zip файл через админку, через управление структурой, там же и распаковать.
Можно добавить модуль в Marketplace, мы это проходили, в принципе ничего сложного.
Для интереса посмотрел код коммерческих модулей из Marketplace Bitrix - в основном используют такой же подход, вешают на OnBeforeProlog модуля main. Многие даже в "старом" стиле через RegisterModuleDependences а не registerEventHandler.
У меня есть нож, точнее мультитул у которого есть, в том числе 2 лезвия, который летает со мной по миру уже лет 8. И ни на одном досмотре никогда он не вызывал никаких вопросов. То есть даже вытащить не просили показать "а что это у вас такое". Хотя я 99.9% уверен, что режущая кромка (градиент убывания толщины металла) должны были как то отобразиться на интраскопе.