Обновить
13
Anarchist@Anarchist

Пользователь

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

Конкуренция между отделами админов, программистов и поддержки? Ой... Это как объявить конкурентами "Кока-колу" и "Майкрософт" :) Но хорошо, смягчим терминологию - "неприязненные отношения между отделами". ;) Но админу нет резона конкурировать с колл-центром - разные ниши в компании.

Есть, не спорю. Но когда сотрудник говорит, что все, кроме техподдержки, безалаберны - это симптом, нес па?
Я слишком себя уважаю, чтобы несколько раз просить просить об одном и том же. :)
С Агавой зависит от отдела. В некоторых система оплаты точь в точь описанная в корневой статье - берут на полную ставку, платят почасовку. Разве что запись в трудовой оставляют. :)

Насколько мне известно, хостинг там в любимчиках, и их не обижают.
Про Рамблер - гон.
Не могу сказать, что целиком все бред, насчет оплаты и режимов работы для службы техподдержки, возможно, так и есть, я судить не могу, работал в другом подразделении.

Возражение по существу: еда вполне пристойная - ее не привозят и не разогревают в микроволновках, даже не готовят из полуфабрикатов. Там две поварихи, которые готовят еду из нормальных продуктов, и готовят неплохо, разве что нет меню. :)

Минус компании: агрессивное соперничество между подразделениями - техподдержка, админы и программисты. Соперничество, если не сказать хуже - вражда. Кстати, в оригинальной статье она проглядывает во фразе:

Инженеру технической поддержки приходится нести постоянную моральную ответственность перед пользователями за безолаберность других подразделений.
12 ...
29

Информация

В рейтинге
5 382-й
Откуда
Москва, Москва и Московская обл., Россия
Дата рождения
Зарегистрирован
Активность