Ну вот а теперь приходится им везде развешивать рекламу о том как это классно — работать в люксофте. И вывешивать на хабре такие вот откровения капитанов очевидностей о том что же движет людьми.
Особая ирония ситуации в том, что в luxoft много проектов и он весь разный. Но вот только из «хороших» проектов люди увольняются меньше, да и слава о «дурных» проектах расползается куда как быстрей.
Ну по поводу «единственного метода» — думаю вы ошибаетесь. Думаю там много «признаков». Вот вам для размышления одна из возможностей: на сайте стоит яндекс-метрика или jQuery расположен у яндекса или какие-то сервисы от их партнеров — это даёт яндексу информацию о посетителях. Несложно среди потока посещаемых урлов найти относящиеся к административным функциям, и так же не сложно определить, что один человек администрирует 2 магазина.
И таких «мелочей» можно найти много.
Ох. Если бы на свете не было других языков программирования и я бы не знал как пользоваться исключениями из этой бы статьи точно не узнал + запутался сильней.
Особы диссонанс вызывает «Ошибки — это то, что нельзя исправить, об этом можно только сообщить: записать в лог, отправить email разработчику и извинится перед пользователем.», но при этом на своём человеческом языке мы вполне себе говорим об ошибках ввода пользователя и о том, что мы покажем сообщение и попросим ИСПРАВИТЬ.
Простите, но ознакомить команду с AOP и внедрить в проект для подобной обработки ошибок, кажется проще и быстрей, чем всей команде «пересесть» на clojure в проекте, который отягощен архитектурными ошибками прошлого «режима» (Что в прочем никак не отрицает того, что с разумным использованием ФП код действительно получается короче. Но просто людей которые бы с одной стороны умело пользовались бы это парадигмой и при этом были бы не склонны к «стремлению к интеллектуальному иллитизму» в достаточном количестве найти очень не просто + они вряд ли согласятся по разным причинам)
Я вот хочу указать, что проект состоит из трех слоев ABC и из С использовать A напрямую нельзя. Как мне это сделать в любом современном языке?
Как на уровне языка отделить презентацию от модели? Я хочу объявить «слой модели» и запретить использовать в нем классы из UI.
Ну это вы можете сделать уже давно. Почитайте про то, что такое на самом деле инкапсуляция/сокрытие, почитайте про «компонентное проектирование», почитайте про правильное использование пространств имён и про то что в вашем любимом языке уже есть package private область видимости — и пользуйтесь на здоровье.
Да я видел, но сама формулировка "(правда, до этого тоже были разговоры)" + место в тексте, говорит о том, что они «какбэ были» а «как бэ и небыли». Просто мне непонятно — когда ты пытаешься выяснить сколько времени нужно на то-то, а тебе человек выдаёт отговорки — вместо того чтобы выяснить, из чего она состоит и что мешает ему сделать оценку времени (ведь действительно может быть проблема, когда непонятно как решить задачу и неясно сколько на это надо времени, но и эта ситуация должна быть озвучена, чтобы начать действовать уже в этом «режиме») мы успокаиваемся ответом «скоро»и уходим. Повторю свою мысль — данный случай очень похож на пример вашей субъективной оценки ситуации. Ведь подобные факапы — целиком вина моя как «манагера» — я не работал с людьми, а потом очень удивился, когда обнаружил такой огромный прыщ у себя на заднице.
думаю mocus просто удивляется вашим формулировкам:
Во введении вы говорите о том, что вы знакомы с тем как люди могут однобоко оценивать ситуацию — и далее являете собой как раз пример такой оценки. В статье вы рассказываете как он вводил вас в заблуждение, а потом ещё обиделся и обвинил во всех смертных грехах. Но простите, кто тут «манагер»? Кто «работает с людьми» и «создаёт команды»? Как так получилось, что за несколько месяцев вы не заметили что у человека проблемы? Почему не разобрались в их причинах (и не выяснили что человек просто «болтун»)?
Вы долго копили в себе претензии и вопросы, и хоть в тексте теперь вы пишите что финальный разговор прошёл «без негатива», но слово «основательно» + то что вы так долго тянули + то что в жизни бывает обычно не так (посмотрите на пары в которой одна из сторон копит претензии — такие разговоры редко происходят без агрессии) склоняет меня к мысли что вы и здесь «не справились» (но это не так важно, так как человек постфактум оказался неподходящим).
Ну и да — выходные 2 оклада ИМХО лишние — ведь испытательный срок не закончился же?
Это так странно, в своей работе принимать более чем сомнительные решения (синглтоны, отягощеннеы ещё и множеством обязанностей), и при этом «очень нравится задавать этот вопрос на интервью :)». Делааа…
Если «все прагматики», то и темы бы не было — какая разница как получать экземпляр если мы синглотанми почти не пользуемся). Да и HotSpot VM, похоже, разогревшись, уберёт блок синхронизации даже из «Synchronized Accessor», так какая тогда разница «как»?))
Всё жду, когда же кто-то напишет, о том, что «синглтоны — зло» и в архитектуре «по последней моде» их использование сведено к минимуму, а значит не так важно, как именно мы получаем экземпляр.
«с помощью только стилей» — почему только стилей — ещё и js есть. Но я просто о том, что работу верстальщика/client-side разработчика приходится выполнять server-side — разработчику.
Хм. Складывается ощущение, что с данной работой вполне мог бы справиться Zend_Form_Element_Radio + css стайлинг от выделенного верстальщика. С другой стороны — далеко не везде ещё поняли необходимость выделенного верстальщика + если проект только один, для аутсорса этой работы нужно чтобы работа по проекту хоть как-то планировалась — а с этим у многих «какбэПМ»ов проблемы.
Думаю, в оригианальном посте, он просто пытался напомнить, что лучше программировать «вне» фреймворка. Тогда «модель» (в широком смысле этого слова, не только «модель данных») получается чище, её при прочих равных — проще тестировать + имея такую модель проще менять интерфейсы: сегодня это будет веб-интерфейс с помощью ROR, завтра — stand-alone демон + некоторый RPC, а после завтра — десктопное приложение, или — «всё сразу».
Особая ирония ситуации в том, что в luxoft много проектов и он весь разный. Но вот только из «хороших» проектов люди увольняются меньше, да и слава о «дурных» проектах расползается куда как быстрей.
И таких «мелочей» можно найти много.
У вас случаем нет «удалённых» сотрудников, которые работают с сайтом? (контент-манагеры или ещё кто)?
Особы диссонанс вызывает «Ошибки — это то, что нельзя исправить, об этом можно только сообщить: записать в лог, отправить email разработчику и извинится перед пользователем.», но при этом на своём человеческом языке мы вполне себе говорим об ошибках ввода пользователя и о том, что мы покажем сообщение и попросим ИСПРАВИТЬ.
Ну это вы можете сделать уже давно. Почитайте про то, что такое на самом деле инкапсуляция/сокрытие, почитайте про «компонентное проектирование», почитайте про правильное использование пространств имён и про то что в вашем любимом языке уже есть package private область видимости — и пользуйтесь на здоровье.
Во введении вы говорите о том, что вы знакомы с тем как люди могут однобоко оценивать ситуацию — и далее являете собой как раз пример такой оценки. В статье вы рассказываете как он вводил вас в заблуждение, а потом ещё обиделся и обвинил во всех смертных грехах. Но простите, кто тут «манагер»? Кто «работает с людьми» и «создаёт команды»? Как так получилось, что за несколько месяцев вы не заметили что у человека проблемы? Почему не разобрались в их причинах (и не выяснили что человек просто «болтун»)?
Вы долго копили в себе претензии и вопросы, и хоть в тексте теперь вы пишите что финальный разговор прошёл «без негатива», но слово «основательно» + то что вы так долго тянули + то что в жизни бывает обычно не так (посмотрите на пары в которой одна из сторон копит претензии — такие разговоры редко происходят без агрессии) склоняет меня к мысли что вы и здесь «не справились» (но это не так важно, так как человек постфактум оказался неподходящим).
Ну и да — выходные 2 оклада ИМХО лишние — ведь испытательный срок не закончился же?