Pull to refresh
104
0
Валера Леонтьев @feedbee

User

Send message
Жаль, что ответа по существу вопроса нет… Ну да ладно. Ваша аналогия ясна. А я на базе вашего примера, аналогию выверну. Наверное, правильно сделали в итоге, что убрали из ОС то, чему не место было в ней. Наверное в следующем году в аналогичном посте вы сформулируете мысли корректнее.

А про личную обиду — это вы чтобы добить? Только голова всплыла, а вы ее назад толкаете? Я, честно говоря, несколько обескуражен таким отношением.

Я то как раз не PHP-шник, Григорий, не смотря на использование этого инструмента в работе. Ваше суждение, похоже, как раз шаблонно и стереотипно. Открыли профиль, увидели там php, и — бинго! Все сразу ясно :)

А про позицию компании мне действительно интересно, какое же отношение к людям на купленных проектах, и какое отношение людей к компании при таком подходе…
Интересно, цитата ниже — это позиция компании, или личное мнение сотрудника, ответственного за написание этого поста?

Специалист непонятного профиля. Вот типичный PHP-программист — это программист суперширокого профиля, то есть не специалист ни в чем. Я уточню сейчас, что это типичный программист, потому что есть нормальные PHP-программисты. Их просто очень мало.


Мне кажется, что рамки приличия вы переступили в данном случае. Надо уметь свои мысли выражать по-корректнее, особенно в местах, где, наверное, процентов 80 — как раз те, кого вы только что чем-то облили :)
Не вырывайте фраз из контекста. Связь вашего комментария с цитатой моего предложения мне не понятна. Это предложение не имеет смысл без предыдущего, а оно ничего не говорит про QDD.

Но вот предполагать, что весь код «в теле сайта» — это одна зона доверия — ошибочно. Так можно делать только в том случае, если кода достаточно мало, и пишет его один человек.

Не важно, сколько людей пишут. Важно, где граница автономного (от сайта) модуля — библиотеки. Про security boundary — это именно то, что пытаюсь донести и я, и автор. Проверили на входе и юзаем дальше где надо в рамках единого кода. Каждый вход в библиотеку — это новый вход и новые проверки. Контроллер бить библиотекой не может и проверок в нем быть не должно, кроме случая отхода от ООП и MVC, когда контроллер напрямую работает с GET-параметрами, куками или другими данными, приходящими отпользователя. Подробнее тут написал.
Входные данные для контроллера поставляется компонент, который их принимает от юзера. Если это форма — то это объект, который представляет эту форму. Если это список с фильтрами и сортировками — то это объект, представляющий список. При этом контроллер сам его инициализирует и запускает в работу. Еще вариант, что параметры проверяет на валидность роутер, когда речь о парсинге URL (ну вон как ID поста на хабре). Кстати роутер сам же и 404 должен отдать при ошибке, без участия контроллера. Когда ни формы, ни списка, ни роута как таковоого нет, проверка происходит в контроллере, потому что он становится точкой входа. Но это как бы относительно редко используется *ну прямая передача get-параметров из ссылки).
Подождите, причем тут клиент и БД. Речь во-первых о коде, который работает в рамках одного процесса. Это как бы не явно подразумевается. Для БД наш бэкэнд — как раз источник неконтроллируемых данных. Тоже самое и в связке киент-сервер. Но когда речь идет о «теле сайта», т.е. все, что выполняется в рамках одного процесса PHP/Ruby/Python/anyCGI и при этом написано для этого сайта, а не является отдельной библиотекой (т.е. view, controller – да, стороннее ORM — нет) – все эти части не просто могут, а должны доверять друг другу (оставляя проверки только на входе), иначе весь ваш код будут сполшные повторяющиеся проверки, а это плохо (если не атом, медицина, космос). Опять же не уверен, что мысль донес, но постарался.
Имелось в виду, что проверять данные должен тот модуль системы, который их принимает. Например, форма. В любом адекватном движке форм (Симфони, Зенд, моем кастомном ;-) валидаторы вставляются прямо в форму, а в контроллере их нет. Если говорить о декстопах, то ситуация там должна быть аналогичной, хотя это и не практикуется в классике.

Если автономный код принимает на вход неконтроллируемые значения, он должен их проверить. В противном случае проверять данные нет смысла, если вы пишете не космос, атом или медицину. Контроллер — это никак не автономный код, который принимает неконтроллируемые значения. А вот слой интерфейса — это именно оно.

Надеюсь удалось донести мысль :)
Приятно, когда местные ребята еще что-то делают, а не только наклейки штампуют на китай. К сожалению это пока редкость. Удачи вам.
Имелось в виду пользуется ли им кто-то из здешней аудитории.
Конкретно маки так ведут себя только с флешем на самых простых роликах. Думаю, что гугл, как разработчик браузера, сможет генерировать такой код, на котором _простейшая_ анимация в баннере не будет приводить к такому эффекту.
А кто-нибудь им пользуется? Дизайнер сможет самостоятельно работать с этим инструментом?

Жду не дождусь, когда мир наконец избавится от флеш-баннеров, из-а которых ноут перегревается и гудит.
Потому что в этом случае до ваших NS-ов запрос просто не дойдет.
После предыдущей статьи о вас тут просто взял и попробовал написать текст по работе в вашем редакторе. Не вышло, по середине процесса переключился на гуглдокс. Были проблемы с навигацей по тексту (активное использование клавиатуры с shift, ctrl, alt), еще какие-то мелочи, которые в совокупности блокировали мою работу. Писал об этом где-то, кажется у вас в обратной связи или типа того чем-то… Не знаю, пофиксили или нет, надо будет попробовать еще раз в новой версии.
Знающий человек не станет без лишней надобности проверять, число у нас или строка в переменной


Знающий проверять не будет, потому что он будет знать заранее, какой тип там в переменной. И конструкции в коде, где так как в этом примере лепятся разные типы не допустит в принципе. Это плохой код как минимум потому, что сходу он непонятный (я про неявное приведение, когда сроки с числами перемешиваться через плюс).
Опытный разработчик, у которого многие наработки уже сушествуют десяток лет


Мне кажется, эта фраза потеряла актуальность лет 5 назад. Сейчас во-первых, опытный разработчик скорее всего не будет работать с шаредами в принципе (коробочные продукты да — ориентированы как раз на шареды, но их относительно мало, и по большей части там сейчас не ведется активная разработка, да и не интересны они опытным). Во-вторых, если человек перестал развиваться, не изучает и не пользуется новыми фичами PHP (здесь особенно важно понимать, что после 5.2 каждая версия приносит пачку важных и нужных фич, которые обязательно надо использовать вместо тех костылей, что были до них), не интересен.
Обилие бесполезного выделения жирным свойственно маркентинговым текстам (воде). Мне изначально текст показался скрытой рекламой, хотя после беглого прочтения уже показалось, что все же доза пользы присутствует.
Там какие-то мелкие цифры… Давайте в долларах считать. Средняя у программера точно не меньше чем 1500. Понимаете, что такое средняя, да? У большинства специалистов с опытом в вебе и мобе (за другие сферы не отвечу) от 1500 до 2000. Кто по-опытнее, там больше. Но надо отдать должное, что выше тройки программеру вытянуть можно только в особых условиях. Вот и сравните с вашими реальными.
Законно. Но не наличными, а на карту. У меня 2 карты, на одну приходит часть денег рублями, на вторую — остальное в USD. Еще раз подчеркиваю, что все абсолютно законно и все налоги уплачиваются как положено. Скорее всего услугу разбиения по валютам предоставляет банк, куда переводится сумма в белках.
копите деньги на пенсию заранее != грамотно управляйте активами чтобы получить в итоге некий капитал
Вот все, что вы написали в этом ответе, не сходится с тем, что написано в статье. Вывод, который я сделал из статьи (как, думаю, и большинство) — копите деньги на пенсию заранее. С остальным, вроде, разобрались.

Information

Rating
Does not participate
Location
Минск, Минская обл., Беларусь
Date of birth
Registered
Activity