Нет, но они хотят решать своими «методами» кому они разрешают продавать семена/мыло и постельное бельё, а кому нет. И применение этих методов определяется закрытыми/проприетарными алгоритмами роскомнадзора. И явно, что эти алгоритмы работают не в пользу «обычных» граждан. Т.е. роскомнадзор пытается блокировать алгоритмы работы, которыми активно пользуется сам. Хм. Чтобы это значило?
Основная угроза — возможность натолкнуться на пропаганду наркотиков, терроризма и т.п.
Поскольку я взрослый человек, то сам решаю, что мне интересно. Более того, я способен отличить пропаганду от информации вообще. Было бы классным дополнением закона «о пропаганде» все ролики или статьи, имеющие соответствующие признаки, помечать как «на правах пропаганды» или «материал содержит признаки пропаганды». И вот тогда б началось веселье — количество пропаганды о пропаганде по «защите» от реторизма и накротиков и т.п. занимало бы 99% контента. Вот интересно было бы посмотреть на работу органов вообще, когда 99% генерируемого ими контента шли бы с пометкой «на правах пропаганды». Например, выступает Роскомнадзор, надувает щёки, отрабатывая хэштег "#намкажетсячтомыборемсястерроризмом", а внизу на треть экрана надпись (как на пачке с сигаретами) — «на правах пропаганды, (18+)».
Вот это был бы годный закон! Потому что каждый, выражающий своё личное мнение под видом «заботы» и преследующий свои корыстные цели сами понимали какой статус у их «заявлений». И «пусть говорят» о какой угодно «заботе».
У меня запущена серверная и клиентская отладка + само web-приложение. Поэтому три монитора. И хотел бы иметь четвёртый. На один экран точно не лезет, на двух еле помещались, но было тесновато. Три уже получше, но ещё недостаточно.
В просьбе решить ТЗ есть одна тонкость, о чём иногда многие забывают — не только вас выбирают, но и вы выбираете компанию тоже. Поэтому не позволяйте себя обманывать и предложите свои условия выполнения ТЗ — например, что вы считаете, что для теста можно выполнить только часть задания (в вашем случае, например, только запрет на чтение) и этого должно быть вполне достаточно, чтобы оценить уровень при этом так же сказать, что это съэкономит время и им и вам. И посмотрите на реакцию. Возможно по их реакции вы сразу поймёте, что что-то не чисто (даже если не будет понятно что именно, но неподготовленная их реакция о многом говорит) и этого будет достаточно, чтобы прекратить собеседование и не тратить на них время, а если они идут на встречу вашим предложениям, то почему бы и не попробовать?
Так его в принципе и невозможно написать, т.к. всё зависит от контекста. Так что хорошая постановка задачи всё-таки важнее. Выходит, что дух первичнее? )
Но даже теперь я продолжаю сомневаться в себе. Дело в том, что это чувство никогда не уходит, так что старайтесь не обращать на него внимания
Я думаю, что это ошибочный совет. Нужно не перестать обращать внимание на это чувство, а использовать его, чтобы разобраться в чём дело. Ведь не спроста же оно возникло? Я недавно размышлял на тему возникновения этого чувства и пришёл к следующему выводу. Когда вы учитесь программировать по книгам или в институте, то при формулировке задачи пытаетесь найти набор ключевых слов, которые подскажут вам решение или применение тех или иных технологий. Но в задачах, которые вам попадаются в реальной жизни может не быть знакомых вам ключевых слов, либо они будут использованы в неверном контексте, что ещё больше сбивает с толку. Так что по-хорошему, чтобы вернуть себе чувство уверенности, нужно научится правильно интерпретировать задачу в свой опыт. А опыт у вас есть уже с рождения.
Арнольд Шварцнеггер в своей книге «Вспомнить всё» написал, что для достижения успеха надо тренировать не только то что хочется, но и свои слабые места. Для этого, конечно, сначала надо признать, что они есть ;)
Привыкай комментировать практически каждую часть кода, ведь это значительно упростит анализ кода коллегами
Правильная и отличная мысль, можно мне добавить, что комментировать не в стиле зачем (что делает код ясно из самого кода), а в стиле почему. Почему я делаю unshift в array, а не push?
Я сначала комментирую ненужные куски кода, потом через два-три коммита начинаю их потихоньку стирать. Некоторые куски кода оставляю в комментах жить вообще бесконечно, чтобы в будущем не пытаться переписать код к варианту, когда он был оттестирован как неправильный ранее. Даже изменения в коде часто делаю по алгоритму — сначала добавил нужные символы, потому удалил ненужные. (Особенно это касается изменения статических исходных данных, имён таблиц, полей).
Если какой-то код отлажен, приносит пользу и оброс комментариями, то и комментарии тоже копируются вместе с кодом в новый проект.
Если я взял код у кого-то, то даю ссылку на страницу, откуда взято и т.д.
Идея с комментариями ещё может получить дополнительное развитие. Действительно не стоит ими пренебрегать.
А какие действие предусмотрены на случай изменения схемы данных?
Я к тому, что можно ли было пользоваться форматом JSON для хранения логов конкретной записи? Сама «ячейка» логов (если так можно выразиться) является JSON-массивом, куда вы только добавляете данные.Такой способ вполне может переварить и изменение колонок и изменение данных логов через триггеры. И таблица логов вполне себе может быть одна. (не знаю, насколько критична эта схема будет по производительности под хорошей нагрузкой).
Так это очень важно, что заказчик вам доверяет. Если заказчик видит, что вы понимаете его проблему и рвётесь в бой её решить, то он вам многое простит. Не значит, что нужно лезть в авантюру, но если чувствуете в себе силы решить задачу, то почему нет?
Я считаю, что всегда в цене люди, которые решают задачи и проблемы. Это и надо демонстрировать. Остальное не имеет значения. Вы всегда в большом спорте, если решаете задачи.
Мне кажется, что больше нужно напирать не на технологии, а на интерфейсы. Интерфейсы стандартизируются, а технологии далеко не всегда. Поэтому нужно ставить вопрос не о том, сколько нужно изучать конкретную технологию, а взглянуть на интерфейсы, которые она поддерживает, чтобы понять, пригодится ли технология в принципе и какую часть от технологии стоит изучать. Технологии бывают очень заумные и не всегда все части технологии нужны. Очень хорошо, если технология поддаётся разделению на части, потому что конечный продукт это далеко не одна технология, а их сумма. Просто нужно стараться не сильно увеличивать сумму неиспользуемых частей в проекте.
Мой вывод такой — интерфейсы нужно учить всегда и в это нужно вкладываться и не жалеть времени, а технологии просто берутся и тратиться нужно в основном на изучение части, которая подходит к нужному интерфейсу.
P.S.
Технологии, конечно, нужно учить, но с оглядкой на то, как быстро она начнёт приносит профит в какой-то части разработки.Особенно интересно «проникаться» технологией, когда читаешь документацию и вдруг ловишь себя на мысли — «Вау, КРУТО! Я бы до этого не догадался» или «Да, я тоже так бы сделал». ))) Тогда и освоение идёт быстрее.
Вот мои правила.
1. Исходный код пишется не для компьютера, а для людей.
2. Документировать/кормментировать код, писать документацию для разработчика (как запустить программу на отладку, где смотреть логи и т.д.), делать скриншоты. (со скриншотами всегда заморочка, а где их хранить? Я предпочитаю выложить изображение скриншота на фотохостинг, а в код кинуть ссылку на скриншот).
3. Если я использую код, найденный в интернете, то даю ссылку перед этим кодом, что код взят оттуда-то, чтобы читающий мог перейти и глянуть в каком контексте это было использовано там, да и описание почитать будет не лишним. 4. Радуюсь, что оставил комментарий, ссылку или скриншот к запутанному месту в своём коде через полгода.
undefined — это работа на клиенте, тут всё просто и по идее до клиента такие ошибки доходить не должны.
Просто если сосредоточиться на обработке ошибок ajax, то с сервера в ответ на ajax запрос может прийти ответ, к которому клиент совсем не будет готов и при этом это не будет ошибкой сервера! Ошибку может сгенерировать фильтр сервера, когда до вашего приложения дело ещё не дошло и формат ошибки тоже может быть неожиданным для клиента. Вот вы ожидаете text, а приходит xml или json, а может csv!? Но это тоже не гарантия, что сервер вернул вам что-то из разряда того, что вы ожидаете и что именно ваше приложение сформировало сообщение об ошибке.
За те года, что существует ajax я не видел универсального решения этой проблемы. Ведь проблема формулируется просто — надо как-то дать понять, что именно моя программа обработала запрос. Даже если вы возвращаете ошибку 500 это не гарантирует клиенту, что именно ваша серверная часть вернула эту ошибку. По сути 500 ошибку, которую сгенерировала ваша программа не отличить от такой же ошибки, сгенерированной самим сервером. Процентах в 90 случаев это может выручить, но никогда нельзя быть уверенным, что если в вашем проекте на тесте надежда что 90% уверенности работали в 100% случаев, то в продакшене не случиться, что эти 90% уверенности работают только в 50% случаев, а то и меньше.
Простите за занудство. Меня эта проблема бесит. :)
Если API разрабатываются отдельно, то ошибка обрабатывается по HTTP коду или кастомному строчному коду, это лучше делать сразу в методе сервиса который делает AJAX запрос.
Остальные ошибки чаще всего вообще никак не обрабатываются, предполагается что их быть не должно, а если все-таки случились, пользователь догадается перегрузить страницу."
Нет ли всё-таки другого варианта сообщить о «странном» ответе от сервера? Насколько я могу судить — это очень болезненная тема в разработке с ajax-запросами. Ведь ошибки бывают в бизнеслогике и её уже никак не свалить на код 500. В этом случае сервер будет пытаться честно предупредить клиента. Что же делать клиенту? Вдруг у него форма на 20-30 полей и перезагрузка страницы ооочень расстроит его. Простите, что несколько придираюсь и утрирую, но не может быть, чтобы не было решения?
Может он хочет коды доступа к Зеону?
Поскольку я взрослый человек, то сам решаю, что мне интересно. Более того, я способен отличить пропаганду от информации вообще. Было бы классным дополнением закона «о пропаганде» все ролики или статьи, имеющие соответствующие признаки, помечать как «на правах пропаганды» или «материал содержит признаки пропаганды». И вот тогда б началось веселье — количество пропаганды о пропаганде по «защите» от реторизма и накротиков и т.п. занимало бы 99% контента. Вот интересно было бы посмотреть на работу органов вообще, когда 99% генерируемого ими контента шли бы с пометкой «на правах пропаганды». Например, выступает Роскомнадзор, надувает щёки, отрабатывая хэштег "#намкажетсячтомыборемсястерроризмом", а внизу на треть экрана надпись (как на пачке с сигаретами) — «на правах пропаганды, (18+)».
Вот это был бы годный закон! Потому что каждый, выражающий своё личное мнение под видом «заботы» и преследующий свои корыстные цели сами понимали какой статус у их «заявлений». И «пусть говорят» о какой угодно «заботе».
Я думаю, что это ошибочный совет. Нужно не перестать обращать внимание на это чувство, а использовать его, чтобы разобраться в чём дело. Ведь не спроста же оно возникло? Я недавно размышлял на тему возникновения этого чувства и пришёл к следующему выводу. Когда вы учитесь программировать по книгам или в институте, то при формулировке задачи пытаетесь найти набор ключевых слов, которые подскажут вам решение или применение тех или иных технологий. Но в задачах, которые вам попадаются в реальной жизни может не быть знакомых вам ключевых слов, либо они будут использованы в неверном контексте, что ещё больше сбивает с толку. Так что по-хорошему, чтобы вернуть себе чувство уверенности, нужно научится правильно интерпретировать задачу в свой опыт. А опыт у вас есть уже с рождения.
Правильная и отличная мысль, можно мне добавить, что комментировать не в стиле зачем (что делает код ясно из самого кода), а в стиле почему. Почему я делаю unshift в array, а не push?
Я сначала комментирую ненужные куски кода, потом через два-три коммита начинаю их потихоньку стирать. Некоторые куски кода оставляю в комментах жить вообще бесконечно, чтобы в будущем не пытаться переписать код к варианту, когда он был оттестирован как неправильный ранее. Даже изменения в коде часто делаю по алгоритму — сначала добавил нужные символы, потому удалил ненужные. (Особенно это касается изменения статических исходных данных, имён таблиц, полей).
Если какой-то код отлажен, приносит пользу и оброс комментариями, то и комментарии тоже копируются вместе с кодом в новый проект.
Если я взял код у кого-то, то даю ссылку на страницу, откуда взято и т.д.
Идея с комментариями ещё может получить дополнительное развитие. Действительно не стоит ими пренебрегать.
Я к тому, что можно ли было пользоваться форматом JSON для хранения логов конкретной записи? Сама «ячейка» логов (если так можно выразиться) является JSON-массивом, куда вы только добавляете данные.Такой способ вполне может переварить и изменение колонок и изменение данных логов через триггеры. И таблица логов вполне себе может быть одна. (не знаю, насколько критична эта схема будет по производительности под хорошей нагрузкой).
Хм… Всегда так делаю.
Не часто пользуюсь, но в принципе местами бывает удобна. На if-ах это сделать уже значительно сложнее без дополнительных переменных.
Тоже самое есть и в JavaScript: https://developer.mozilla.org/ru/docs/Web/JavaScript/Reference/Statements/label
Мой вывод такой — интерфейсы нужно учить всегда и в это нужно вкладываться и не жалеть времени, а технологии просто берутся и тратиться нужно в основном на изучение части, которая подходит к нужному интерфейсу.
P.S.
Технологии, конечно, нужно учить, но с оглядкой на то, как быстро она начнёт приносит профит в какой-то части разработки.Особенно интересно «проникаться» технологией, когда читаешь документацию и вдруг ловишь себя на мысли — «Вау, КРУТО! Я бы до этого не догадался» или «Да, я тоже так бы сделал». ))) Тогда и освоение идёт быстрее.
1. Исходный код пишется не для компьютера, а для людей.
2. Документировать/кормментировать код, писать документацию для разработчика (как запустить программу на отладку, где смотреть логи и т.д.), делать скриншоты. (со скриншотами всегда заморочка, а где их хранить? Я предпочитаю выложить изображение скриншота на фотохостинг, а в код кинуть ссылку на скриншот).
3. Если я использую код, найденный в интернете, то даю ссылку перед этим кодом, что код взят оттуда-то, чтобы читающий мог перейти и глянуть в каком контексте это было использовано там, да и описание почитать будет не лишним.
4. Радуюсь, что оставил комментарий, ссылку или скриншот к запутанному месту в своём коде через полгода.
Просто если сосредоточиться на обработке ошибок ajax, то с сервера в ответ на ajax запрос может прийти ответ, к которому клиент совсем не будет готов и при этом это не будет ошибкой сервера! Ошибку может сгенерировать фильтр сервера, когда до вашего приложения дело ещё не дошло и формат ошибки тоже может быть неожиданным для клиента. Вот вы ожидаете text, а приходит xml или json, а может csv!? Но это тоже не гарантия, что сервер вернул вам что-то из разряда того, что вы ожидаете и что именно ваше приложение сформировало сообщение об ошибке.
За те года, что существует ajax я не видел универсального решения этой проблемы. Ведь проблема формулируется просто — надо как-то дать понять, что именно моя программа обработала запрос. Даже если вы возвращаете ошибку 500 это не гарантирует клиенту, что именно ваша серверная часть вернула эту ошибку. По сути 500 ошибку, которую сгенерировала ваша программа не отличить от такой же ошибки, сгенерированной самим сервером. Процентах в 90 случаев это может выручить, но никогда нельзя быть уверенным, что если в вашем проекте на тесте надежда что 90% уверенности работали в 100% случаев, то в продакшене не случиться, что эти 90% уверенности работают только в 50% случаев, а то и меньше.
Простите за занудство. Меня эта проблема бесит. :)
Нет ли всё-таки другого варианта сообщить о «странном» ответе от сервера? Насколько я могу судить — это очень болезненная тема в разработке с ajax-запросами. Ведь ошибки бывают в бизнеслогике и её уже никак не свалить на код 500. В этом случае сервер будет пытаться честно предупредить клиента. Что же делать клиенту? Вдруг у него форма на 20-30 полей и перезагрузка страницы ооочень расстроит его. Простите, что несколько придираюсь и утрирую, но не может быть, чтобы не было решения?