Здравствуйте, vitaly_spb, Вы писали:
mgu>>Angular -- это птичий грипп программирования, все массово болеют, но это пройдёт. Я в Angular-е разобрался за час, т. к. сам писал подобные среды (только без байндинга -- пользователь тоже человек), но выкладывать подобное для всеобщего использования не пришло бы в голову.
_>А в чем смысл Angular'a без binding'a (а точнее даже double-binding'a)?
В моём случае аналогичный результат достигался напрямую: событие -> эффект. Да, с байндингом меньше кода и ошибок, модный inversion of control опять же, но платить приходится плохой масштабируемостью и непредсказуемой управляемостью.
Ну, с jQuery я вообще за полчаса . Это не значит, что я напишу на нём всё, что угодно с закрытыми глазами, но опыт самостоятельного написания AJAX-запросов (во времена, когда подобных библиотек попросту не было) и мучения с ExtJS помогли разобраться, где за что дёргать.
Здравствуйте, Sashaka, Вы писали:
S>Здравствуйте, mgu, Вы писали:
mgu>>Здравствуйте, sergey2b, Вы писали:
S>>>Здравствуйте, mgu, Вы писали:
S>>>хотя я сторонник теории что надо уметь делать что то лучше всех и все будет нормально
mgu>>Согласен, проблема только в доказательстве своего превосходства тем, кто по определению хуже, и при этом не задеть нежных чувств суровых программистов.
mgu>>И ещё. Вакансий для уникальных личностей мало, в основном нужно мясо.
S>От тебя так и веет высокомерием и заносчивостью. Этот пост прям апогей: "своего превосходства", "уникальных личностей" =)
Ну, кто что видит. Я, заметьте, не писал "моего превосходства". Просто привычка мыслить логически и абстрактно накладывается: если некто (не я лично) делает нечто лучше других, то все остальные (в т. ч. и интервьюеры) -- хуже в этой области. Соответственно, проверка знаний сводится к "Так и я сыграю, ты вот лучше "Мурку" сбацай".
S>Уверен процентов на 90, что не берут из-за этого
Здравствуйте, neFormal, Вы писали:
F>Здравствуйте, landerhigh, Вы писали:
L>>Писать "эффективные и правильно работающие программы" это "знание" не помогает. Вообще никак. Равно как и не помогает этому "знание" любых других алгоритмов.
F>и как в итоге определять качество кандидата? F>остаются: F>1. ТЗ, которое не любят F>2. рекомендации, которых может не быть F>3. и собственное чутьё, которое подводит
Много в теме написали, по делу. Я добавлю (или повторю) свое мнение: многие проблемы из-за страха взять более опытного и знающего человека. Если сложился коллектив, например, человек 10, во главе с парой менеджер-технарь, и все люди примерно возраста 25-30, то если взять 45-летнего не идиота, а, наоброт, умного человека, авторитет иерархии пошатнется. По крайней мере, они (молодые) так думают, как раз из-за своей молодости, возможно. И чем молодые амбициозней, тем достойным старикам труднее получить их одобрение.
Здравствуйте, mgu, Вы писали:
mgu>И если предполагается, что программисты с утра до вечера должны молотить код, то их технического лидера надо гнать в шею.
Здравствуйте, oziro, Вы писали:
O>Много в теме написали, по делу. Я добавлю (или повторю) свое мнение: многие проблемы из-за страха взять более опытного и знающего человека. Если сложился коллектив, например, человек 10, во главе с парой менеджер-технарь, и все люди примерно возраста 25-30, то если взять 45-летнего не идиота, а, наоброт, умного человека, авторитет иерархии пошатнется. По крайней мере, они (молодые) так думают, как раз из-за своей молодости, возможно. И чем молодые амбициозней, тем достойным старикам труднее получить их одобрение.
Согласен, я поэтому и мечу в "начальство" ("технарь"). Насчёт авторитета иерархии не совсем однозначно: я, будучи в подчинении у "молодого", выполняю его распоряжения, ибо за них отвечает он. Молодёжь же, после получения полугодового опыта, обычно чувствует себя, так сказать, королями дороги; схема сказано-обсуждено-выполнено часто не работает. Так что меня даже удивляет, что не охотятся за специалистами предпенсионного возраста (это не про меня) -- и не подсидит, и ответственность есть, и опыт, и не сбежит через полгода на втрое большую зарплату.
Здравствуйте, mgu, Вы писали:
mgu> Насчёт авторитета иерархии не совсем однозначно: я, будучи в подчинении у "молодого", выполняю его распоряжения, ибо за них отвечает он.
Так это ты такой хороший. А молодые не могут отфильтровать или перестраховываются. Я с позиции 25 летнего скажу, мне в прошлом пришлось искать знающих людей. Вот приходит дядька, весь такой из себя хитрый. Вроде и шарит, но не чувствуешь его, не можешь просчитать и доверять. Понятно, что рынок все расставляет по своим местам, только результаты этого не нравятся, в итоге, ни тебе ни мне. Я, молодой, остался без ценного сотрудника, а ты — без работы; а я тоже без работы, в результате, потому что кадры решают всё Особенность отрасли такая. Кто все понял — тот миллиардер.
>Молодёжь же, после получения полугодового опыта, обычно чувствует себя, так сказать, королями дороги; схема сказано-обсуждено-выполнено часто не работает.
О да
>Так что меня даже удивляет, что не охотятся за специалистами предпенсионного возраста (это не про меня) -- и не подсидит, и ответственность есть, и опыт, и не сбежит через полгода на втрое большую зарплату.
Не понимают. Боятся тех, что притворяется, а потом подсидит и бизнес отожмет, или еще что надумают себе.
Здравствуйте, neFormal, Вы писали:
F>Здравствуйте, mgu, Вы писали:
mgu>>4. Собственные знания.
F>ну вот, алгоритмы/паттерны/асимптотики/знание API — это оно и есть. F>потому и вопрос об альтернативах.
Знания: дать заранее подготовленный говнокод и послушать комментарии.
Умение решать проблемы: предложить типичную для будущей работы задачу (простую, решённую, алгоритм; не просить что-то разработать дома).
Обучаемость: "Что такое ХХХ? Не знаете? Прекрасно, вот валерьянка. Значит, ХХХ -- это УУУ, как вы это используете для такой-то задачи?"
Личностные качества: лихость и придурковатость, семейное положение, отношение к алкоголю, ваш главный недостаток, зарплата на предыдущем месте работы, оцените по десятибалльной шкале степень мудачества вашего прежнего начальника, зачем вы сюда пришли готовность обсуждать и выполнять, совместимость с коллективом, взрослость, неконфликтность, старательность, внимательность, аккуратность...
_>>А в чем смысл Angular'a без binding'a (а точнее даже double-binding'a)? mgu>В моём случае аналогичный результат достигался напрямую: событие -> эффект. Да, с байндингом меньше кода и ошибок, модный inversion of control опять же, но платить приходится плохой масштабируемостью и непредсказуемой управляемостью.
Ну так весь смысл Angular'a в том, что это фреймворк. Задача фреймворка помочь писать меньше кода и избегать типичных ошибок. Событие->эффект это видимо jquery way, который для сложного UI становится сложно поддерживать. А так-то можно и на vanilla javascript написать все то же, что и с помощью Angular. Просто это будет сложно писать и поддерживать.
mgu>Вот тут хорошо раскрыта тема: https://medium.com/@mnemon1ck/why-you-should-not-use-angularjs-1df5ddf6fc99#.ldwlxfs9y
Основная претензия к производительности когда много watcher'ов (например, для таблиц), она уже решена в Angular 1.4 и 2.0.
_>>А За час это забавно, конечно, Angular на самом деле большой фреймворк, это в ReactJS можно за час разобраться. mgu>Ну, с jQuery я вообще за полчаса . Это не значит, что я напишу на нём всё, что угодно с закрытыми глазами, но опыт самостоятельного написания AJAX-запросов (во времена, когда подобных библиотек попросту не было) и мучения с ExtJS помогли разобраться, где за что дёргать.
Вам видимо надо побольше с Angular поработать, чтобы понять в чем удобство использования по сравнению с jQuery. Ну или хотя бы глянуть код todomvc и сравнить глазами.
...Ei incumbit probatio, qui dicit, non qui negat...
Здравствуйте, neFormal, Вы писали:
F>Здравствуйте, mgu, Вы писали:
mgu>>И если предполагается, что программисты с утра до вечера должны молотить код, то их технического лидера надо гнать в шею.
F>поэтому ты не можешь пройти через техлидов
Безупречная логика. Но я бы не стал на этом основании лепить "паттерн прохождения интервью Competitor", определять должности синхронизации работы несовместимых программистов и требовать обязательного знания всей этой ботвы при найме в отдел кадров.
Здравствуйте, vitaly_spb, Вы писали:
_>>>А в чем смысл Angular'a без binding'a (а точнее даже double-binding'a)? mgu>>В моём случае аналогичный результат достигался напрямую: событие -> эффект. Да, с байндингом меньше кода и ошибок, модный inversion of control опять же, но платить приходится плохой масштабируемостью и непредсказуемой управляемостью.
_>Ну так весь смысл Angular'a в том, что это фреймворк. Задача фреймворка помочь писать меньше кода и избегать типичных ошибок.
Да, плюс не порождать новых головных болей.
_>Событие->эффект это видимо jquery way, который для сложного UI становится сложно поддерживать. А так-то можно и на vanilla javascript написать все то же, что и с помощью Angular. Просто это будет сложно писать и поддерживать.
Вот и хорошо. Просто внедрять сырую необкатанную технологию -- плохая практика.
_>>>А За час это забавно, конечно, Angular на самом деле большой фреймворк, это в ReactJS можно за час разобраться. mgu>>Ну, с jQuery я вообще за полчаса . Это не значит, что я напишу на нём всё, что угодно с закрытыми глазами, но опыт самостоятельного написания AJAX-запросов (во времена, когда подобных библиотек попросту не было) и мучения с ExtJS помогли разобраться, где за что дёргать.
_>Вам видимо надо побольше с Angular поработать, чтобы понять в чем удобство использования по сравнению с jQuery. Ну или хотя бы глянуть код todomvc и сравнить глазами.
А можно ссылку на todomvc? (Не уверен, что нашёл именно то.)
Здравствуйте, oziro, Вы писали:
O>Много в теме написали, по делу. Я добавлю (или повторю) свое мнение: многие проблемы из-за страха взять более опытного и знающего человека. Если сложился коллектив, например, человек 10, во главе с парой менеджер-технарь, и все люди примерно возраста 25-30, то если взять 45-летнего не идиота, а, наоброт, умного человека, авторитет иерархии пошатнется. По крайней мере, они (молодые) так думают, как раз из-за своей молодости, возможно. И чем молодые амбициозней, тем достойным старикам труднее получить их одобрение.
Здравствуйте, StanislavK, Вы писали:
SK>У меня как раз другое впечатление сложилось. Как бы хочет по той части, но не выходит, так как не понимает, что от таких людей хотят.
Ну да, по части позитива у ТС проблема.
Здравствуйте, mgu, Вы писали:
mgu> Ищу уже полгода, но пока предложений нет.
по своему опыту могу сказать, что если у опытного человека нет работы, то это означает, что он не хочет работать
обдумайте эту фразу минут 60 хотя бы прежде чем отвечать
_>>Ну так весь смысл Angular'a в том, что это фреймворк. Задача фреймворка помочь писать меньше кода и избегать типичных ошибок. mgu>Да, плюс не порождать новых головных болей.
Выбор чего-то это всегда компромисс. Я поэтому и удивился, что можно что-то за час понять: Angular довольно большой фреймворк, сходу сложно начать применять.
mgu>Вот и хорошо. Просто внедрять сырую необкатанную технологию -- плохая практика.
Согласен, но Angular уже сам по себе очень неплохо развит, плюс куча сторонных проектов к нему.
mgu>А можно ссылку на todomvc? (Не уверен, что нашёл именно то.)
Здравствуйте, alzt, Вы писали:
L>>А про лок-фри контейнеры я, навреное, уже книгу могу написать в стиле "Вредных советов" Остера. A>А можно паручку вредных советов?
Если вас тимлид внезапно на прокетик посадил,
а в проекте разных тредов вам придется запилить,
не спешите над проектом голову свою ломать.
и не в коем случае нельзя вам архитектуру рисовать.
Буржуинские замашки в дальний угол отложив, смело
на проект скорей ищите хитренький такой контейнер,
что "лок-фри" приставку носит в части имени своем.
Если молодцом большим прослыть хотите, то берите сразу два,
и библиотеку алгоритмов с ними не забудьте прихватить.
Ведь известно даже детям, что когда потоков много,
настоящие джедаи все вопросы одним махом
лок-фри контейнером решают и фигакс-фигакс в продакшен.
Здравствуйте, mgu, Вы писали:
lpc>>1. Не знать как работает хеш таблица человеку за 20 годами опыта (не знаю сколько у вас) — стремно и странно. Сложности в этом нет, что там можно забыть я не представляю, хеш-таблицы как были 20 лет назад так скорее всего и останутся через 20 лет, а сие знание таки позволяет писать более эффективные и (что важно) правильно работающие программы. Сколько раз видел ламеров которые equals и hashCode неправильно имплементили, после чего волшебным образом что то переставало работать. Как узнать что вы не один из них? Правильно, спросить стандартный вопрос и потом обязательно убедиться что вы понимаете ответ, а не просто зазубрили. В моих интервью незнание этой темы сразу "no hire".
mgu>Я уже упоминал, что знаю успешных программистов, не понимающих, что такое указатель. Т. е. моя проблема, похоже, не в незнании ЭТОЖЕОСНОВ. У меня 20+ лет опыта, про устройство хеш-таблиц знаю, но это мне нисколько не помогает в работе: mgu>в 95% случаев ключи примитивные, а записи я всегда сравниваю при помощи функций сравнения. (Сейчас меня закидают.)
Задачи и технологие бывают разные, так же как и понятие "успех". Где то действительно не нужны знания про указатели. Что это доказывает? Ровно ничего. В моей работе знание хеш таблицы помогает более чем сильно. Я скажу больше — у нас свой collection framework, со своими хеш-таблицами. Потому что нам это надо. Поэтому я спрашиваю про это. Другие могут спрашивать по другим резонным причинам, с чего вы взяли что они просто так спрашивают? Опять же, в тех 5% случаев когда ключ не примитивный, я не хочу чтобы нерадивый программист, который думает что ему не надо знать как работает hashmap, возьмет и все втихоря сломает завязав hashcode на изменяемые поля.
lpc>>2. SOLID конечно большинство не знают, а те кто знают не факт что понимают, но эти знания — хороший плюс и шанс на то, что кандидат будет дизайнить классы с умом. Опять же, классический вопрос про rectangle/square на Liskov substitution principle дает понять, понимает ли кандидат потенциальные косяки когда наследует класс и в переопределенных методах начинает делать "что хочу", мол а почему нет... Я редко спрашиваю про SOLID, для меня оно дает либо +1 либо 0. Минус за это не ставлю.
mgu>Я считаю SOLID гламурной аббревиатурой, состоящей из сомнительных или очевидных утверждений. Базовые правила наследования никто не отменял, странно, что г-жа Лисков не присвоила своё имя, скажем, полиморфизму.
Да какая разница как оно называется и сколько в этом гламурности. Это просто кодовое слово. У меня алгоритм следующий: спрашиваю слышали ли про солид. Если да, расскажите, потом рассмотрим примеры. Если нет — сразу идем к примерам и пытаемся разобраться как лучше и где есть проблема.
lpc>>3. Return из try/finally встречается сплошь и рядом, и здесь нет ничего необычного. Не нравится так писать — ваше право, но программист должен читать и понимать код своих коллег. Если кандидат не знает язык, то это настораживает, так как он может легко сделать или пропустить чужую багу. Такой вопрос лучше всего подходит для multiple choice test... mgu>Я просто не понимаю, зачем делать возврат из try/finally. Что это даёт? Почему не писать очевидный код, там, где это можно сделать? Ход программы с извращённым возвратом я пойму.
Ну а вот я и миллионы других программистов считают что это удобно и много чего дает. Не согласны — тогда наверное вам лучше поискать другую команду, иначе не сработаетесь. Так что вопрос очень даже ничего.
lpc>>Какие еще вопросы вам не понравились? Давайте обсудим!
mgu>Мне не нравится сам принцип построения вопросов. Например, вместо "перечислите все структуры данных" почему бы не спросить: "вот есть такие данные, в какой структуре вы их будете хранить? А почему? А без потоков? А если это список дней недели?"
Согласен что вопрос ни о чем, но в чем проблема перечислить то? Сложно сказать: массив, матрица и многомерный массив, список (1 и 2 связный), хеш-таблица (плюс разные способы разрешение коллизий), дерево (бинарное, не бинарное, сбалансированное, раскаршенное), heap, queue, dequeue, stack, skip list... что там еще бывает... Наверняка следующим вопросом будет что то более полезное, типа когда что удобнее, либо какую структуру выбирете для XYZ.
mgu>Или: "перечислите все параметры функции XYZ. Как? Их же всего 20, и вы же их должны использовать 100 раз в день!" А далее на голубом глазу просят описать "паттерн" wrapper.
Вопросы про параметры функций во многих случаях ничего не дают, но есть исключения. Я никогда не спрашивал таких вопросов но вот случайный пример: параметры System.arraycopy ? Не знаете — ничего страшного, метод копирует кусок памяти из одного место в другое. Какие параметры вам бы понадобились? Если кандидат затупил — значит память он никогда не копировал и возможно не годится для (например) написания бинарных протоколов, по крайней мере без обучения. Еще раз, пример из головы, смысл в том что интервьюер что то хочет узнать о кандидате и поэтому задает какой то вопрос. Если вы не понимаете его замысла, это еще не значит что вопрос плохой. Лучший вариант действий в такой случае это выяснить в чем собственно вопрос? Наверняка можно получить разумные пояснения.
mgu>В общем, я за проверку не знаний, а умение находить решения. Представим на минуту страшное: программист выбрал не ту сортировку и в результате программа работает аж на 100 мс медленнее! Да и чёрт-то то с ним. И если предполагается, что программисты с утра до вечера должны молотить код, то их технического лидера надо гнать в шею.
Опять вы всех под одну гребенку. Например у нас если программа станет работать на 100мс медленнее то уволят всю команду. Разбираться кто виноват будут только если речь идет о 100 микросекундах.
Здравствуйте, landerhigh, Вы писали:
L>Эффективные и правильно работающие программы помогает писать в первую очередь здравый смысл и умение видеть лес за деревьями.
Каким образом волшебное умение "видеть лес за деревьями" поможет избежать классической ошибки когда hashCode использует изменяемые поля класса, если базовых знаний о работе хеш-таблицы нет? Очень жду подробный ответ.
. Это не значит, что я напишу на нём всё, что угодно с закрытыми глазами, но опыт самостоятельного написания AJAX-запросов (во времена, когда подобных библиотек попросту не было) и мучения с ExtJS помогли разобраться, где за что дёргать.
