За то, что я задекларирую. В конце концов, я не обязан открывать счет ИП. Например, я могу вообще только с наличкой работать.
Скажите, пожалуйста, насколько Вам близка область налогового законодательства России? Мне необходимо трактовать Ваши вопросы как риторические не в мою пользу?
Или мы совместно пытаемся познать особенности налогообложения ИП? :)
У меня сейчас не получилось найти ссылку на запись выступления Алексея Шипилева, где он рассказывает __какие__ баги были пофиксены в jdk седьмой версии (куча багов с concurrency, например). При этом фиксы не были включены в шестую jdk.
Поэтому, юзайте jdk6 на свой страх и риск. :)
Ненормированный рабочий день не подразумевает переработок. Они лишь возможны в этом случае.
Уточните, пожалуйста, в статье, что подразумевались именно переработки.
Простите, ну как-то наверное не очень правильно писать this->balance в интерфейсе. Получается, что затачиваемся на конкретную реализацию, где есть такое поле. Например, какую-нибудь проксю за этим интерфейсом уже не напишешь. :) А в ином случае выделение сущности интерфейса сомнительно на мой взгляд.
Такой пример: есть те же 2 часа Вашего рабочего времени. Ваш потенциальный работодатель хочет понять, что каждые 2 часа рабочего времени Вы будете решать задачи, а не тупить над элементарными вопросами типа «как назвать метод».
Ну и опять же — не факт, что подразумевается решать такое тестовое в авральном режиме. Надо просто покодить эти 2 часа ни на что не отвлекаясь, но и при этом ничего себе не порвав. ;)
Я конечно понимаю, что такие задания могут давать в контексте авралов и прочей ереси. Но я оптимист. :)
Ну и у меня был только описываемый опыт в режиме live coding.
На мой взгляд те, кто дает такие задания, не подразумевают работать потом в аврале. Они хотят посмотреть, как соображает программер в условиях, когда сделать все и сразу не получится изначально (примером может быть создание прототипа, когда команда собирается раз в день и смотрит, куда идти дальше, забивая на мелочи). Т.е. какую стратегию выполнения человек выбирает (в данном случае — вначале фичи, затем красивости), приоритет выполнения фич (когда незначительные для результата отодвигаются на потом), может ли кандидат делать step-by-step законченные фичи, и т.п.
Вообще мне такое задание сильно напоминает live coding без задачи сделать законченное решение. Просто чтобы интервьювер посмотрел как чел себя будет вести в реальной разработке.
После прочтения статьи у меня сложилось ощущение, что автор в крайности бросается, и ему мерещатся заговоры. :)
Ну а мир жесток, это да. Поэтому можем порадоваться за себя, что нам повезло заниматься тем, что нам нравится. Ну или когда-то нравилось. :)
Имхо, это зависит от логики, её объёма и в особенности от правильности рук того, кто пишет эту логику.
Если от Вашего проекта счастливы разработчики, клиенты, и бизнес получает кучу бабла, то Вы определённо на правильном пути. :)
Ну, если логика специфичная (например, нам надо переворотить миллионы записей из разных таблиц — с точки зрения производительности), имеет смысл переваривать данные ближе к источнику и не выносить в какой-нибудь бекэнд.
А если в БД находится __вся__ логика, то весь проект сильнее рискует превратиться в набор лапши, чем написанная на какой-нибудь Джаве. Нет поддержки IDE в написании кода, мало библиотек (если они вообще есть).
Если короче — много рисков.
Я не смог в посте найти ответа на главный вопрос — почему логика работы с изображениями находится в БД? У Вас вся бизнес логика в базе? Или Вы пишите некий фреймворк для каких-то целей?
В начале поста я увидел доводы только за внешний сервис работы с изображениями.
Даже если поставить else-блок, нельзя гарантировать, что в него случайно не попадет вызов free. А что если вызов free вообще в середине вторых тысяч строк кода, а не в конце? :) Все решает внимательность к деталям.
По моему пример неудачный. Здесь early return не пахнет (после первых-то тысяч строк кода).
Ну и в подобных монстрах надо все перепроверять на двадцать рядов, чтобы хоть как-то быть уверенным, что не ошибся.
И не надо меня минусовать :D
Скажите, пожалуйста, насколько Вам близка область налогового законодательства России? Мне необходимо трактовать Ваши вопросы как риторические не в мою пользу?
Или мы совместно пытаемся познать особенности налогообложения ИП? :)
Поэтому, юзайте jdk6 на свой страх и риск. :)
Уточните, пожалуйста, в статье, что подразумевались именно переработки.
И что именно не устраивало в ней?
* @Contract\Ensure("$this->balance == $__old->balance+$amount")Простите, ну как-то наверное не очень правильно писать this->balance в интерфейсе. Получается, что затачиваемся на конкретную реализацию, где есть такое поле. Например, какую-нибудь проксю за этим интерфейсом уже не напишешь. :) А в ином случае выделение сущности интерфейса сомнительно на мой взгляд.
Ну и опять же — не факт, что подразумевается решать такое тестовое в авральном режиме. Надо просто покодить эти 2 часа ни на что не отвлекаясь, но и при этом ничего себе не порвав. ;)
Я конечно понимаю, что такие задания могут давать в контексте авралов и прочей ереси. Но я оптимист. :)
Ну и у меня был только описываемый опыт в режиме live coding.
Вообще мне такое задание сильно напоминает live coding без задачи сделать законченное решение. Просто чтобы интервьювер посмотрел как чел себя будет вести в реальной разработке.
Ну а мир жесток, это да. Поэтому можем порадоваться за себя, что нам повезло заниматься тем, что нам нравится. Ну или когда-то нравилось. :)
Я Вам так сочувствую.
P.S. тег сарказма съелся :)
Если от Вашего проекта счастливы разработчики, клиенты, и бизнес получает кучу бабла, то Вы определённо на правильном пути. :)
А если в БД находится __вся__ логика, то весь проект сильнее рискует превратиться в набор лапши, чем написанная на какой-нибудь Джаве. Нет поддержки IDE в написании кода, мало библиотек (если они вообще есть).
Если короче — много рисков.
В начале поста я увидел доводы только за внешний сервис работы с изображениями.
Ну и в подобных монстрах надо все перепроверять на двадцать рядов, чтобы хоть как-то быть уверенным, что не ошибся.