Да уж… На столь хилом примере не показать пользу от ExpressionVisitor, да и мощь ExpressionTrees не раскрыта.
Тем более, что способ использования… не слишком очевиден, попахиает шаманством :)
Я недавно решал в чём-то схожую задачу: делал фильтр для js-грида. В используемом мной гриде был встроенный механизм автофильтров, но работал только на клиентской стороне, а мне очень хотелось не тащить ни клиента лишние данные… Итогом стал универсальный механизм фильтрации на стороне сервера, работающий для любых данных. Со стороны клиента прилетает список фильтров «имя поля/тип фильтра/фильтрующее значение», а коде контроллера получается что-то вроде
IQueryable<T> source = DAL.GetQuery<T>();
IQueryable<T> data = source.ApplyFilter(filters);
Если интересно — могу код выложить и статейку по это набросать.
Ох уж этот вечный холивар…
Каждый раз смотрю и удивляюсь — как же люди в споре суть его упускают. И ведь даже озвучивают порой ключевые разногласия, но спор не прекращают. Спор ради спора.
А ведь как всё просто (и было сказано уже не раз): программисты разные нужны, программисты разные важны. :)
Просто слово на всех одно.
Так почему же спорщики так уверенно трактуют в универсальный вариант «правильного программиста» частное суждение «мне нужны вот такие» или «я считаю правильными именно вот этих». Но ведь не бывает универсальных программистов.
Не проще ли уж начать дополнять термин? Типа «нужен хороший программист на фабрику данных», или «спец по моделированию физических процессов», или «умеющий в одно лицо создать систему поддержки бизнеспроцесса», или даже «мастер скоростного кодирования по готовому ТЗ». Тогда сразу будет понятно, почему один должен алгоритмами дышать, а второму они до лампочки :)
Пара моих личных примеров.
Я сам «матёрый» программист, начинал ещё в 90-х, и всю жизнь имею дело с реальным бизнесом. Именно поэтому любая задачка для меня начинается с user stories & use cases. Потом добавляем потенциал развития и жизненный цикл программы/системы. Потом уже можно подумать о том, как и что писать. И вот как-то до явной реализации алгоритмов я доходил пару-тройку раз, не более. Да, в институте писал алгоритмы, и помню некие общие подходы… Главное, что в жизни пригождается — понимание вычислительной сложности. Ибо без него можно на ровном месте систему в down уложить. Чаще, конечно, за этим следить надо в области sql.
Зато понимание общих концепций, паттернов и т.п. — это то, что спрашиваю у senior-ов. (Весьма забавно получить ответ про паттерны от tech lead/architect в духе «да пофиг что использовать, ибо decorator, wrapper, adapter и façade суть одно и то же»). И да, про паттерны я спрашиваю только про те, которые собеседуемый сам заявляет как понятные и используемые.
С другой стороны, сам, проходя собеседования, если натыкался на кучу вопросов по алгоритмам, честно говорил «ребята, вам нужен не я. Вот систему запроектировать — это ко мне, а алгоритмы… потребуются — найду. А помнить без нужды — нафиг надо»…
Немного поддержу автора…
Видно что наболело. Но, тем не менее, такая классификация, как и любая другая имеет смысл, если она даёт возможность оптимизировать процесс. Да, грубовато и неоднозначно, но в целом понятно.
А теперь немного поспорю :)
Всё же, не всё так просто с «врождённостью». Да, есть некое специфическое «воспитание» личности, из-за которого человек будет стремиться к тому или иному привычному способу участвовать в работе. Но, всё же, двигать человека по такой шкале вполне возможно. И это таки задача и даже талан управленца персоналом, сделать так, чтобы в наполнение коллектива разными «характерами» было оптимально. И чем выше требуемая для работы квалификация, тем ценнее возможность предоставить работнику ту позицию, на которой он будет наиболее эффективен, чем просто менять каждый раз на нового.
А есть и ещё более интересные примеры. Тут из личного опыта.
Был момент, когда я сидел на работе по 30-40 часов, но за полтора месяца в одиночку сделал то, что, по идее, должны были делать три человека два месяца. Больше я такие эксперименты не повторял, но, по предложенной шкале я был «героем». Чуть позже там же я был очень ценным «специалистом», при необходимости выскакивая в «герои». Но работа была интересна и с мотивацией было хорошо.
Попозже, на другой работе, я колебался от «пофигиста» до «героя», в зависимости от текущих задач и мотивации.
Так что, эти характеристики совсем не врождённые. И поработав со многими, неоднократно участвуя в формировании команды, для себя сделал такой вывод (приведя его к предложенной схеме): в ИТ-команде желательно иметь колеблющегося героя — ему спасать аврал и преодолевать неординарные вызовы, толпу специалистов — им делать большую часть работы, но и без пофигистов не обойтись — они хороши на скучных задач, за которые лучше совсем не сажать героя, а спецы долго не протянут… Наличие всех остальных — ошибка в управлении проектом и командой.
Обычно я примерно знаю, сколько могут дать, а часто зарплатная вилка указана в объявлении. Но суть не в том. Я честно говорю: «Абсолютный минимум вот столько, но это при наличии многих других интересных мне бонусов». И даже список интересных бонусов перечисляю. А потом следует предложение в стиле «никаких бонусов не обещаем, но вы нам очень понравились, предлагаем вам зарплату на 10% меньше вашего минимума»…
Тоже, что ли, поделиться… за последние полгода посетил несколько десятков компаний в Москве…
(для уточнение — стэк .net, опыта 15 лет, позиция не ниже ведущего разработчика)
Раздражающие факторы в организации собеседований:
— неполная инструкция к тому, как же найти офис/кабинет/человека. Например: офис в большом бизнес-центре, три здания, ни слова о том, в какое соваться, или нужный вход только с другой улицы да из подворотни.
— отсутствие готовности места/собеседующих. Было и так, что 15 минут ищем, куда бы присесть, потом ещё полчаса собираем тех, кто же хотел меня лицезреть. И это при том, что заранее было оговорено, что времени у меня — час на всё про всё.
— и да, нелепые рукописные анкеты, которые сильно проще было бы заранее заполнить на компьютере.
Печальные факторы:
— нелепые тесты из задачника «как никогда не надо писать код», типа что выведет этот код. Очень хочется сказать «если я такой код увижу в своём проекте, выкину его нафиг», и да, часто так и говорю.
— туда же алгоритмические задачки из разряда «есть решение у гугле на первой странице» и совершенно точно не нужные в реальной работе.
— вопросы из серии «самые редковстречаемые особенности» языка/технологи. Судя по тону спрашивающего — токмо с целью доказать собственное превосходство.
— или как вариант вопросы про азы, которые я уже давно забыл ввиду неиспользуемости нигде, кроме как в начальных туториалах.
Совсем печальные:
— предложение написать тестовое задание-приложение. Да, некто у них там наспор пишет его за 3-4 часа. А я, значит, должен угадать, какой из двух-трёх десятков возможных вариантов решения их удовлетворит.
— уходящие с тень HR-ы. Все клятвенно обещают обязательно перезвонить, даже в случае ядерной войны… Но некоторые умудряются даже переставать отвечать на звонки.
— и на первом месте традиция спросить «сколько минимум вы хотите денег» чтобы уж точно предложить не больше, не зависимо от степени моей пригодности. Обычно предлагают меньше.
Тем более, что способ использования… не слишком очевиден, попахиает шаманством :)
Я недавно решал в чём-то схожую задачу: делал фильтр для js-грида. В используемом мной гриде был встроенный механизм автофильтров, но работал только на клиентской стороне, а мне очень хотелось не тащить ни клиента лишние данные… Итогом стал универсальный механизм фильтрации на стороне сервера, работающий для любых данных. Со стороны клиента прилетает список фильтров «имя поля/тип фильтра/фильтрующее значение», а коде контроллера получается что-то вроде
IQueryable<T> source = DAL.GetQuery<T>();
IQueryable<T> data = source.ApplyFilter(filters);
Если интересно — могу код выложить и статейку по это набросать.
Каждый раз смотрю и удивляюсь — как же люди в споре суть его упускают. И ведь даже озвучивают порой ключевые разногласия, но спор не прекращают. Спор ради спора.
А ведь как всё просто (и было сказано уже не раз): программисты разные нужны, программисты разные важны. :)
Просто слово на всех одно.
Так почему же спорщики так уверенно трактуют в универсальный вариант «правильного программиста» частное суждение «мне нужны вот такие» или «я считаю правильными именно вот этих». Но ведь не бывает универсальных программистов.
Не проще ли уж начать дополнять термин? Типа «нужен хороший программист на фабрику данных», или «спец по моделированию физических процессов», или «умеющий в одно лицо создать систему поддержки бизнеспроцесса», или даже «мастер скоростного кодирования по готовому ТЗ». Тогда сразу будет понятно, почему один должен алгоритмами дышать, а второму они до лампочки :)
Пара моих личных примеров.
Я сам «матёрый» программист, начинал ещё в 90-х, и всю жизнь имею дело с реальным бизнесом. Именно поэтому любая задачка для меня начинается с user stories & use cases. Потом добавляем потенциал развития и жизненный цикл программы/системы. Потом уже можно подумать о том, как и что писать. И вот как-то до явной реализации алгоритмов я доходил пару-тройку раз, не более. Да, в институте писал алгоритмы, и помню некие общие подходы… Главное, что в жизни пригождается — понимание вычислительной сложности. Ибо без него можно на ровном месте систему в down уложить. Чаще, конечно, за этим следить надо в области sql.
Зато понимание общих концепций, паттернов и т.п. — это то, что спрашиваю у senior-ов. (Весьма забавно получить ответ про паттерны от tech lead/architect в духе «да пофиг что использовать, ибо decorator, wrapper, adapter и façade суть одно и то же»). И да, про паттерны я спрашиваю только про те, которые собеседуемый сам заявляет как понятные и используемые.
С другой стороны, сам, проходя собеседования, если натыкался на кучу вопросов по алгоритмам, честно говорил «ребята, вам нужен не я. Вот систему запроектировать — это ко мне, а алгоритмы… потребуются — найду. А помнить без нужды — нафиг надо»…
Видно что наболело. Но, тем не менее, такая классификация, как и любая другая имеет смысл, если она даёт возможность оптимизировать процесс. Да, грубовато и неоднозначно, но в целом понятно.
А теперь немного поспорю :)
Всё же, не всё так просто с «врождённостью». Да, есть некое специфическое «воспитание» личности, из-за которого человек будет стремиться к тому или иному привычному способу участвовать в работе. Но, всё же, двигать человека по такой шкале вполне возможно. И это таки задача и даже талан управленца персоналом, сделать так, чтобы в наполнение коллектива разными «характерами» было оптимально. И чем выше требуемая для работы квалификация, тем ценнее возможность предоставить работнику ту позицию, на которой он будет наиболее эффективен, чем просто менять каждый раз на нового.
А есть и ещё более интересные примеры. Тут из личного опыта.
Был момент, когда я сидел на работе по 30-40 часов, но за полтора месяца в одиночку сделал то, что, по идее, должны были делать три человека два месяца. Больше я такие эксперименты не повторял, но, по предложенной шкале я был «героем». Чуть позже там же я был очень ценным «специалистом», при необходимости выскакивая в «герои». Но работа была интересна и с мотивацией было хорошо.
Попозже, на другой работе, я колебался от «пофигиста» до «героя», в зависимости от текущих задач и мотивации.
Так что, эти характеристики совсем не врождённые. И поработав со многими, неоднократно участвуя в формировании команды, для себя сделал такой вывод (приведя его к предложенной схеме): в ИТ-команде желательно иметь колеблющегося героя — ему спасать аврал и преодолевать неординарные вызовы, толпу специалистов — им делать большую часть работы, но и без пофигистов не обойтись — они хороши на скучных задач, за которые лучше совсем не сажать героя, а спецы долго не протянут… Наличие всех остальных — ошибка в управлении проектом и командой.
Обычно я примерно знаю, сколько могут дать, а часто зарплатная вилка указана в объявлении. Но суть не в том. Я честно говорю: «Абсолютный минимум вот столько, но это при наличии многих других интересных мне бонусов». И даже список интересных бонусов перечисляю. А потом следует предложение в стиле «никаких бонусов не обещаем, но вы нам очень понравились, предлагаем вам зарплату на 10% меньше вашего минимума»…
(для уточнение — стэк .net, опыта 15 лет, позиция не ниже ведущего разработчика)
Раздражающие факторы в организации собеседований:
— неполная инструкция к тому, как же найти офис/кабинет/человека. Например: офис в большом бизнес-центре, три здания, ни слова о том, в какое соваться, или нужный вход только с другой улицы да из подворотни.
— отсутствие готовности места/собеседующих. Было и так, что 15 минут ищем, куда бы присесть, потом ещё полчаса собираем тех, кто же хотел меня лицезреть. И это при том, что заранее было оговорено, что времени у меня — час на всё про всё.
— и да, нелепые рукописные анкеты, которые сильно проще было бы заранее заполнить на компьютере.
Печальные факторы:
— нелепые тесты из задачника «как никогда не надо писать код», типа что выведет этот код. Очень хочется сказать «если я такой код увижу в своём проекте, выкину его нафиг», и да, часто так и говорю.
— туда же алгоритмические задачки из разряда «есть решение у гугле на первой странице» и совершенно точно не нужные в реальной работе.
— вопросы из серии «самые редковстречаемые особенности» языка/технологи. Судя по тону спрашивающего — токмо с целью доказать собственное превосходство.
— или как вариант вопросы про азы, которые я уже давно забыл ввиду неиспользуемости нигде, кроме как в начальных туториалах.
Совсем печальные:
— предложение написать тестовое задание-приложение. Да, некто у них там наспор пишет его за 3-4 часа. А я, значит, должен угадать, какой из двух-трёх десятков возможных вариантов решения их удовлетворит.
— уходящие с тень HR-ы. Все клятвенно обещают обязательно перезвонить, даже в случае ядерной войны… Но некоторые умудряются даже переставать отвечать на звонки.
— и на первом месте традиция спросить «сколько минимум вы хотите денег» чтобы уж точно предложить не больше, не зависимо от степени моей пригодности. Обычно предлагают меньше.