Скорее случится наоборот. В новых очках будете видеть рекламу, которой нет. Идете по городу, а впереди белый щит, на котором очки услужливо рисуют нужную картинку. И запретить ходить без таких очков — мол, реклама является частью композиции города, и отказ от просмотра таковой нарушает авторские права. :)
> user.destroy
> user.followers.remove // user удален, как я могу им пользоваться?
removeUser($user);
removeUserFollowers($user); // user удален, как я могу им пользоваться? ;)
Не придираясь к терминологии, в чем в данной ситуации вы видите разницу между структурой и прилагающимся к ней и только к ней функционалом для работы (removeUser, removeUserFollowers и т.д.) и объектом и его методами? Если честно, я разницы тут не вижу. Разве что запись длиннее.
Это не совсем так, например, к аксиоматике Гильберта пришли в процессе весьма продолжительного развития геометрии и плясок с бубном вокруг пятого постулата. На ранних этапах математики вообще упирались не на аксиомы, а на «очевидность», продемонстрированную чертежами. В этом смысле очень хорошо прослеживается параллель с разработкой ПО — изначально условно-рабочий прототип, потом его «отливка» в ООП.
Вы знаете, это чем-то напоминает диалог с креационистами — они придумывают тезисы эволюционистов, а потом успешно их опровергают. Александр написал все верно, но он подменил методологию, как она описывается у Буча, своим измышлением. Уже во многих источниках описано, что работа начинается с прототипа, на базе которого в процессе рефакторинга создаются работоспособные классы, удовлетворяющие потребностям проекта. Никто не предлагает запрягать телегу в лошадь. Методология ООП как раз является тем, что описано во втором абзаце, но никак не в первом. И то, что ООП используется неправильно — это не проблема ООП.
Я очень поверхностно ознакомился к концепцией erlang'а, и заметил интересную вещь. Говоря языком околоматематическим, концепция erlang'а является изоморфной концепции ООП в том смысле, что можно провести параллели в терминологии. То есть, если заменить термины erlang'а определенным образом, можно вернуться к ООП. Процессы можно считать объектами, изоляция процессов — так же самая инкапсуляция, сообщения — вызовы методов… Поправьте меня, возможно, я ошибаюсь, но в эрланге много от ООП, просто с другим названием.
Я думаю, что объектное программирование было создано не только из соображения удобства написания кода, немаловажной деталью является использование однажды написанного в других проектах. Причем желательно без лишних телодвижений в виде copy/paste (что влечет за собой также перенос несуразиц и ошибок, трудности поддержки и т.д. и т.п.). И так или иначе Вы все равно придете к концепции модульности, потом инкапсуляции (что, кстати, позволит Вам проводить эффективное тестирование) и, вероятно, в итоге к внедрению зависимостей (dependency injection).
Не нужно им даже ничего постить. Закрытие производится без суда, потом владелец бежит в суд и пытается доказать, что он не верблюд. Суд можно тянуть достаточно долго, пока актуальность сайта не пропадет. Либо, если уж хочется закрыть сайт навсегда, можно сделать скриншоты с любым контентом — пока сайт закрыт, доказать, что скриншот является подделкой, маловероятно.
Про меню я имел в виду выбор. :) И это было сказано не в укор, так что не будем спорить.
Конкуренция между отделами админов, программистов и поддержки? Ой... Это как объявить конкурентами "Кока-колу" и "Майкрософт" :) Но хорошо, смягчим терминологию - "неприязненные отношения между отделами". ;) Но админу нет резона конкурировать с колл-центром - разные ниши в компании.
Есть, не спорю. Но когда сотрудник говорит, что все, кроме техподдержки, безалаберны - это симптом, нес па?
С Агавой зависит от отдела. В некоторых система оплаты точь в точь описанная в корневой статье - берут на полную ставку, платят почасовку. Разве что запись в трудовой оставляют. :)
Насколько мне известно, хостинг там в любимчиках, и их не обижают.
Не могу сказать, что целиком все бред, насчет оплаты и режимов работы для службы техподдержки, возможно, так и есть, я судить не могу, работал в другом подразделении.
Возражение по существу: еда вполне пристойная - ее не привозят и не разогревают в микроволновках, даже не готовят из полуфабрикатов. Там две поварихи, которые готовят еду из нормальных продуктов, и готовят неплохо, разве что нет меню. :)
Минус компании: агрессивное соперничество между подразделениями - техподдержка, админы и программисты. Соперничество, если не сказать хуже - вражда. Кстати, в оригинальной статье она проглядывает во фразе:
Инженеру технической поддержки приходится нести постоянную моральную ответственность перед пользователями за безолаберность других подразделений.
Очень распространенное заблуждение. :) Я делал бомбочки. Кстати, в основном благодаря учебникам химии.
Если взять, кстати, справочники по химии советского образца, так там можно найти способ изготовления даже гексагена.
> user.followers.remove // user удален, как я могу им пользоваться?
removeUser($user);
removeUserFollowers($user); // user удален, как я могу им пользоваться? ;)
Не придираясь к терминологии, в чем в данной ситуации вы видите разницу между структурой и прилагающимся к ней и только к ней функционалом для работы (removeUser, removeUserFollowers и т.д.) и объектом и его методами? Если честно, я разницы тут не вижу. Разве что запись длиннее.
«Интеллект толпы равен интеллекту ее самого глупого члена, поделенного на размер толпы» (Пратчетт)
Конкуренция между отделами админов, программистов и поддержки? Ой... Это как объявить конкурентами "Кока-колу" и "Майкрософт" :) Но хорошо, смягчим терминологию - "неприязненные отношения между отделами". ;) Но админу нет резона конкурировать с колл-центром - разные ниши в компании.
Есть, не спорю. Но когда сотрудник говорит, что все, кроме техподдержки, безалаберны - это симптом, нес па?
Насколько мне известно, хостинг там в любимчиках, и их не обижают.
Возражение по существу: еда вполне пристойная - ее не привозят и не разогревают в микроволновках, даже не готовят из полуфабрикатов. Там две поварихи, которые готовят еду из нормальных продуктов, и готовят неплохо, разве что нет меню. :)
Минус компании: агрессивное соперничество между подразделениями - техподдержка, админы и программисты. Соперничество, если не сказать хуже - вражда. Кстати, в оригинальной статье она проглядывает во фразе:
Инженеру технической поддержки приходится нести постоянную моральную ответственность перед пользователями за безолаберность других подразделений.