Если вам действительно интересно узнать, как это помогает, то можно погуглить. Я понимаю, что это ответ так себе, но в этом посте скорее всего никто уже не будет отвечать подробно на этот вопрос.
А вот что касается тотального контроля — ну давайте тогда подставим под сомнение вакцины, СПИД, ну и вспомним все остальные теории заговора. Очень конструктивный получится разговор.
Двухэтапная аутентификация. Хорошая идея, но на практике только упрощающая получение доступа к вашим данным, т.к. включает в себя слишком много дополнительных участников, которые тоже могут иметь свои уязвимости.
То есть ее придумали (и мало того, активно используют как люди так и различные структуры самого разного уровня) для того, чтобы упростить взлом? Может не надо так резко?
Если рассмотреть эту проблему как лингвист, то очевиден корень проблема — намного более сложная морфология русского языка. В английском нет падежей, родов прилагательных/причастий, большого кол-ва лиц/спряжений глаголов. Любое согласование частей речи в предложении в русском ведет к дополнительным буквам, меняющимся то перед, то после корня (а иногда и корень меняется! беглые гласные! в английском этим и не пахнет!).
Вот как то так :)
Статья хорошая, пускай и немного неудачна в рассчетах.
Простите, а почему в качестве маршрута выбран берег Калифорнии, а не, скажем, Москва-СПб?
Я уже подумал, что в конце будет ссылка на оригинал :)
Тем не менее, можно сказать, что у Google+ шансы выше, чем у MySpace, поскольку, если бы хотя бы малая толика из миллиардов пользователей Google пожелает стать пользователем новой социальной сети, то Google+ станет весьма успешным проектом
Статья хорошая, но весьма спорным оказался первый пункт.
Первое, что сразу бросилось в глаза — выполнение запросов через объект модели прямо в коде контроллера, что напрочь перечеркивает все преимущества MVC…… Такое смешивание логики было в каждом файле контроллера, что очень мешало чтению кода и исправлению ошибок, постоянно возникали какие-то не очевидные зависимости, перезаписывались важные данные. Соответственно так делать не в коем случае нельзя, даже если вы разрабатываете небольшой проект.
Это утверждение мне кажется несколько резким и в некоторых случаях даже голословным. Зачем плодить в модели множество методов, используемых ровно один раз ровно в одном контроллере? А конструктор запросов с помощью Zend_Db_Table_Select и Zend_Db_Select для чего по вашему был создан? Уж не для того ли, чтобы в контроллере, в зависимости от параметров, динамически сформировать нужный запрос? И не надо отделываться общими фразами вроде «перезаписывались важные данные», надо приводить конкретные примеры, именно они суть этой статьи…
В программировании точно также: основы алгоритмов, паттерны, теории автоматов и т.д. могут выступать как база, которая реализована пока что во всех языках без существенных изменений.
Назвать статью понятной — сложно. Даются общие определения, какие-то примеры, но суть куда-то ускользает.
Все это ИМХО, конечно. Я бы с целью ознакомления аудитории сделал иначе — привел бы примеры на псевдокоде
и на этих примерах объяснил бы, где тут срезы, где советы и т.д.
Тот из нас, кто нашел работу, выступает в роли заказчика, он оформляет работу в виде отдельных задач с четким требуемым результатом.
Поиск работы — тоже работа, кто ее будет оплачивать?
Найдя работу, ты так или иначе заключаешь устные или письменные договоренности, нарушать которые не имеешь права. Где страхование рисков? Одно звено в длинной цепочек подрядчиков может все сорвать.
Поймите, крупный бизнес интересуют, очень интересуют риски! Для малого данная модель может сработать, для крупного — есть серьезные сомнения.
Исполнитель выполняет работу так, тогда и там, как, когда и где посчитает нужным и передает исполнителю результат.
Замечательно, никаких обязательств, риск 120%.
Заказчик в любом случае обязан расплатиться по оговоренной цене независимо от того, как выполнена задача.
Сильно. Я сделаю какаху, но ты, заказчик, будь добр, гони деньги.
В дальнейшем статья поясняет подход, но его работоспособность хотя бы в 50% реальных проектов, из реальной жизни, с репрезентативной выборкой, ИМХО, стремится к нулю…
Unfulfilling work правильнее перевести «невдохновляющая», «неинтересная», «скучная»
А вот что касается тотального контроля — ну давайте тогда подставим под сомнение вакцины, СПИД, ну и вспомним все остальные теории заговора. Очень конструктивный получится разговор.
Если не поможет, в запасе есть угрозы, пытки, или в крайнем случае можно взять обратно :)
То есть ее придумали (и мало того, активно используют как люди так и различные структуры самого разного уровня) для того, чтобы упростить взлом? Может не надо так резко?
Вот как то так :)
Простите, а почему в качестве маршрута выбран берег Калифорнии, а не, скажем, Москва-СПб?
Я уже подумал, что в конце будет ссылка на оригинал :)
У Гугла ярд пользователей?! Автор, вы жжете!
Это утверждение мне кажется несколько резким и в некоторых случаях даже голословным. Зачем плодить в модели множество методов, используемых ровно один раз ровно в одном контроллере? А конструктор запросов с помощью Zend_Db_Table_Select и Zend_Db_Select для чего по вашему был создан? Уж не для того ли, чтобы в контроллере, в зависимости от параметров, динамически сформировать нужный запрос? И не надо отделываться общими фразами вроде «перезаписывались важные данные», надо приводить конкретные примеры, именно они суть этой статьи…
то все выглядит совсем нелепо.
Все это ИМХО, конечно. Я бы с целью ознакомления аудитории сделал иначе — привел бы примеры на псевдокоде
и на этих примерах объяснил бы, где тут срезы, где советы и т.д.
Поиск работы — тоже работа, кто ее будет оплачивать?
Найдя работу, ты так или иначе заключаешь устные или письменные договоренности, нарушать которые не имеешь права. Где страхование рисков? Одно звено в длинной цепочек подрядчиков может все сорвать.
Поймите, крупный бизнес интересуют, очень интересуют риски! Для малого данная модель может сработать, для крупного — есть серьезные сомнения.
Замечательно, никаких обязательств, риск 120%.
Сильно. Я сделаю какаху, но ты, заказчик, будь добр, гони деньги.
В дальнейшем статья поясняет подход, но его работоспособность хотя бы в 50% реальных проектов, из реальной жизни, с репрезентативной выборкой, ИМХО, стремится к нулю…
Сначала не понял, но пока писал коммент — догнал идею и стер все, что хотел написать :)
И спасибо за порцию веры в себя.
Но нет-нет — да и появится очередная околохоливарная статься на Хабре…