#232 Три гика и портвейн 2
Едим баранину на даче на веранде, сверчки поют, потягиваем портвейн и болтаем об Enterprise IT.
He’s overqualified for entire Enterprise IT
На скольки работах может работать один консультант одновременно
Зачем наливают дорогих консультантов?
Are we over-educated?
Какой фреймворк лучше?
What’s dependency injection?
SQL or ORM?
Качаем или слушаем:
На фотке бараньи ребрышки которые мы жарили и ели.
Америчка 
Столько долгожданных тем , с удовольствием послушаем. =)
Очень полезный подкаст, многое разложил по полочкам по матчасти. Будам, спасибо, за организацию подобной встречи.
Спасибо большое за подкаст. Собирайтесь для этого почаще =)
Спасибо за интересные подкасты, сейчас слушаю старые ваши, с р-пода. Нашел вас тут, зашел сказать спасибо )
Спасибо за подкаст, под портвейн пошло 🙂
Вот вам ссылочка:
http://www.lookatme.ru/flows/antonovskiy/posts/103051-strana-lentyaev
Что вы думаете по этому поводу?
Прав ли восклицающий?
Про Москву конкретно не знаю, но статья хорошая. Прав автор. Может подкаст получиться.
От себя замечу, что не всегда и не везде так, как говорится в статье. Я заметил, что многие пишут о своём негативном опыте, тем самым создавая впечатление, что в России везде так.
Да нет же, не везде, есть гики, есть успешные люди, но их относительно немного. Как не каждый вытянет (а может вдруг ВНЕЗАПНО гикнется и вытянет, как вы считаете?) обновлять и поддерживать проекты на много миллионов строк кода, так не каждый сможет работать, например, в студии Артемия Лебедева в Москве. Вот я заметил, что ваш сайт работает на engine x, а ведь его разработал русский народный гик, Игорь Сысоев, работающий в Rambler 🙂
Поэтому не верьте всему, что пишут, или, по крайней мере, проверяйте через инсайдеров в Москве 🙂
С уважением, gigam.
А я со статьей не согласен, вернее с её названием. Дело в том, что в б. СССР в значительной мере отсутствует связь между качеством работы и оплатой. Вот ты – бы достиг того профессионального уровня, который у тебя есть, если – бы четко знал: есть ряд вещей, которые честно работая не купить? Никогда! Вне зависимости от эффективности твоей работы. И это не золотой унитаз и не пентхауз в центре Лондона. Речь идет о обыкновенной квартире в спальном районе твоего города.
Вот доказательство: квартира в Киеве сейчас стоит 70 – 100 тыс. долларов. Конкретно ты платишь программисту три тысячи и это для Киева высокая оплата. Значит, если человек не ходит в отпуск, не платит вообще никаких налогов при этом живет в лесу, ест что там поймает и одевается в шкурки за год ему не собрать денег на нормальное жилье. Ты скажешь:”ипотека”. Вот только дают её под 50 – т процентов годовых. Заметь, речь идет о самой высокооплачиваемой профессии и самых высокооплачиваемых её представителях.
Обыкновенный школьный учитель получает в районе двух тысяч гривен(приблизительно 250 долларов), репетиторствуя может заработать ещё две – все! Больше денег ему не поднять, никак. Отсюда вопрос – имеет смысл повышать свою квалификацию, чего – то делать если лучше жить от этого ты не станешь?
Можно долго рассказывать, что не хлебом единым жив человек, что мол надо нести людям добро и т.п. Но когда видишь прокурора на дорогущей машине(взятки за закрытие дел) желание развиваться несколько снижается.
p.s. Лично я работаю над собой только потому, что надеюсь из этой поганой страны уехать.
Кстати, те – же люди, когда приезжают в штаты порой добиваются очень хороших результатов, почему? Да потому, что в штатах имеет смысл работать.
Помнишь рассказ твоего друга – Феликса о человеке, который в Союзе сильно пил, а в Америке перестал потому, что его работа швейцаром позволяла нормально жить?
Насчёт высокооплачиваемой профессии – это беда IT-индустрии, по моему.
Все говорят, что программист – это круто, потому что тут типа денег много.
А ведь получают то их не те, кто пошёл сюда именно за большой зарплатой, а те, кому интересно, те, кто готов с утра до ночи склониться над монитором и с компилятором в зубах сидеть три месяца над большой и очено трудной задачей и довести дело до конца. Востребованы Proud Maniac Developers, а их мало. Тем более, что такие люди, как правило, не живут в одном месте, а кочуют из страны в страну, куда позовут и где задача интереснее. Из личного опыта общения таких примеров – масса.
На эту тему, может быть, и боян, который плавал ещё по FIDO в своё время, но:
http://www.wasm.ru/article.php?article=onebyte
Скажи, Будам, разве у вас заказчики разбираются в программировании на столько, чтоб выбирать фреймворки? Имхо, если ты гарантируешь заказчику что “будет хорошо” ему должно быть все равно какой фреймворк использовать
А ты попробуй девушку затащить в постель просто приговаривая, “Не волнуйся, тебе будет хорошо!” Опытная девушка, которая обожглась уже пару раз, решит сначала проверить твою технику как-то по другому и до того: “А почему мне будет хорошо?”.
Забавная аналогия 🙂 И не возразишь, так и есть.
Мне кажется сравнение несколько некорректно. Девушка, в отличие от заказчика, сама эксперт в том что ей надо(возможно несколько ниже уровнем, но не суть :)). + она сама принимает активное участие в процессе и денег с меня не берет. Другими словами она в теме.
Заказчик – же за то мне и платит, чтоб я сделал ему работу, которую он сам делать в большинстве случаев совершенно не умеет. Отсюда у меня вопрос: откуда твои заказчики знают, что хибернейт это хорошо? Они перед тем как заказать работу спрашивают мнение экспертов. Мол объясните мне, с использованием каких технологий это нужно делать или как?
Вопрос совершенно не праздный. Вот допустим есть клиент – владелец пиццерии, он хочет заказать у тебя сайт по онлайн заказу пиццы. Каким образом он узнает, что одна технология “хорошая”, а другая “плохая”. У нас, когда заказывают ПО говорят:” мне нужна программа, которая делает это, это и это – сможешь ты это сделать, или нет? Если сможешь, за какую сумму?” Если я говорю “да” это уже мои проблемы какую технологию выбрать, главное чтоб с помощью её я решил проблемы заказчика.
А в Америке как это происходит, расскажи пожалуйста?
Мы не делаем сайты для пиццерий. Мы помогаем IT отделам крупных корпораций или стартапов. И в одном и в другом случае у них есть собственные специалисты, которые имеют свою точку зрения как надо.
Интересно, а если задача ставится оптимизационного плана, повысить нагрузку/производительность?
Такие не каждый разработчик может решить, а если может – то стоит дорого. Один сотрудник за 3 месяца работы в [sensored] фирме сделал то, что не смог сделать отдел в 100 человек и его решение дерёт их в 10 раз, то есть его решению нужно в 10 раз меньше операторов, в 10 меньше железа и в 10 раз меньше денег. Как думаете, до такого решения специалисты компании могли додуматься самостоятельно?
100 человек могут никогда не додуматься до того, что может один талантливый человек. это нормально.
Будам, спасибо большое. Очень интересный и познавательный подкаст.
Будаму и двум гикам, спасибо за подкаст 🙂 Весело у Вас ……….да еще и портвейн, что самое интересное, чувствуется уважение к собеседнику и это очень приятно слышать 🙂 Чаще собирайтесь, а то работа да работа, а так поболтали о том о сём и подслушателям было что послушать и к чему прислушаться 🙂
Просто отличный подкаст!
Еще бы упомянуть формулы эрланга для расчета размерности очередей. Рассмотреть приложения как СМО для более удобного анализа узких мест и путей решения. Мне кажется сейчас это почти никто не применяет.
Будам, а ваши коллеги насколько часто используют мат. методы для решения различных задач? Насколько я помню, один из ваших гостей упоминал, что с их помощью многие задачи бы решались намного проще.
А вот, все говорят про ограничение по возрасту в России при приёме на работу. А между тем в Google:
http://habrahabr.ru/blogs/arbeit/97230/
Свое мнение о Хабре я уже когда-то высказывал. Они бы еще взяли работников какого-нибудь стартапа и сделали выводы о возрасте и качестве программистов в США.
gigam, для тех кто не знает английский и читает только хабр пишу:
The Greyglers is a group of approximately 200 Googlers, a little less than that,… бла бла бла
There is a goto address on the screen if you would like to join. бла бла блв
А теперь перевод:
Greyglers – это группа состоящая приблизительно из 200 гуглеров (сотрудников компании Google), на самом деле немного меньше,… бла бла бла
Вот есть goto адрес, если вы хотите присоединиться, бла бла бла
Что говорит что на ДАННЫЙ момент в этой группе 200 человек и кто хочет тот может присоединиться.
Это все вы можете найти в видео, ссылка которого есть на том самом хабре. Надо фильтровать информацию а не верить всему что пишут.
Толик консультант ушел через пару месяцев. Понадобилось маленькое но не тривиальное изменение. И что? И жопа, потому что никто не разобрал ковбойский код Толика. Пишем систему заново… Или зовем Толика за дурные деньги, и то, он тоже смотрит на свой код и половину переписывает..
Если вам удастся позвать Толика, даже за дурные деньги, и даже если он перепишет половину своего старого кода, считай, что твоей конторе и тем людям которые с ним работали очень по-вез-ло. Жаль, что ты этого не услышал из подкаста.
Не, я согласен что повезло 🙂
Я о пытался показать пользу использования общепринятых практик/фреймворков. Может это будет немного медленнее, но в перспективе сильно дешевле в поддержке.
Да, оказалось 5 минут не дослушал. Витя очень правильно говорил о заменяемости. Ладно, закончить проект по накатаной дорожке смогут, а вот изменить? Сделать что-то нетривиальное…
В Гугл и Микрософт, очень строго относятся к code style, именно по этим причинам
Здравствуйте Будам,
Понравился ваш подкаст, но немного удивило ваше общее неприятие фреймворков. Да, не все они идеальны, осбенно в Java мире, где большая часть из них opensource и из-за этого страдают в поддержке и особенно в документации. Сам я из .Net мира, но опыт работы с nHibernate очень большой(порт вашего java Hibernate). У этого фреймворка много проблем, но из ваших слов у меня сложилось впечатление что вы не очень то в курсе его возможностей. К примеру при всех его недостатках, как можно было забыть 2 его несравненных достоинства:
1)Lazy loading – просто великолепная вещь при работе с большими БД
2)Возможность написать слой доступа к данным не заморачиваясь с типом СУБД(по своему опыту, заказчики часто выставляют в требованиях поддержку нескольких СУБД, к примеру MSSQL и Oracle)
Производительность – это очень важно, но здесь надо обращать большое внимание и на требования заказчика. Если заказчик просит создать гибкую систему(которую потом без сильного геммороя можно доработать под изменившиеся условия) без использования фреймворков и паттернов вы далеко не уедете. И дело тут не в опыте разработчиков, а в самом подходе к написанию приложений.
Паттерны и фреймворки не одно и то же. Фреймворки часто есть реализация паттерном, но можно обходится и собственной реализацией в зависимости от задач. Проблемой часто является то, что люди использующие фреймворки не понимают какие паттерны лежат в основе, для чего они и как с ними работать.
Приходилось работать с большими БД в телекомю компании. Никаких Lazy Loading там не используют, обращение к базе напрямую и берешь то, что тебе нужно только оттуда. Что касается типа СУБД в среде ява JDBC как раз и предназначен для универсализации работы с бд, интерфейс тот же, просто меняется драйвер в путях.
Андрей,
На сколько я знаю, JDBC подходит только для небольших приложений. Если вы будете иметь дело с реальными системами и работать с сущностями с большим количеством связей(к примеру какие нибудь данные о должнике какого нибудь банка), разработка и поддержка приложения с использованием JDBC превратится в ад. Еще от коллег джавистов слышал, что у JDBC есть проблемы при работе с транзакциями, конкрурентной работой и слежением за закрытием подключений. Другими словами, я не представляю, как вы будете разрабатывать систему уровня предприятия, используя только jdbc. Можно не любить ORM, но в современном программировании на много проще оперировать сущностями которые имееют аналог в реальном мире(как в моем примере “Должник”), чем с кучкой ничего не значащих таблиц. Хотя, может вы имели ввиду приложения, которые пишут фрилансеры в одиночку за пару недель, тогда вопросов нет.
Все фреймворки работающие с базами данный используют JDBC как систему доступа низкого уровня. Соответственно любой ORM на java не может не использовать JDBC.
Что касается описанных вами проблем JDBC – звучит как какая-то ерунда. JDBC – это интерфейс и если база данных и драйвер это поддерживают, значит и JDBC это поддерживает.
Приложения о которых говорил я – приложения внутри крупной телекоммуникационной американской компании. Там сознательно не используются ORM и если нужно тобразить какие-то данные на класс, то делается это с помощью пециально для это го написанного Mapper. Дело в том, что инфраструктура ORM может быть очень громоздкой и не приносить никаких выгод в использовании.
Андрей Кр, а вы знаете, что кроме стандарта SQL, который ТИПА ДОЛЖНЫ поддерживать все БД, у каждой БД есть еще свои модификации. Так например какой то сложный sql запрос будет работать на одной бд, а на второй фиг вам. Потому что один и тот же сложный запрос (иногда даже не сложный, а просто использующий какие то фичи определнной бд) будет работать намного быстрее на определенной БД чем если написать его sql-ом придерживаясь стандарта.
Так вот еще и для таких вещей предназначены ORM фреймворки. Не только чтобы быстро писать представления БД в программе, но и чтобы использовать один и тот же код для разных БД.
А с простой подменой драйвера удачи вам использовать например ORACLE и MS SQL в одном приложении.
Андрей,
Из вашего первого ответа у меня сложилось впечатление, что вы не имеете опыта работы с Hibernate, из второго ответа у меня сложилось впечатление, что у вас нет опыта работы с jdbc. Прошу прощения, если я не прав. Ответ был поставлен именно таким образом, чтобы это проверить. Под проблемами понималась необходимость хардкода описанных мною вещей под конкретную БД. И если отследить корректное закрытие подключений как правило больших проблем не представляет, то решение 2х других задач частенько бывает довольно гемморойным и сильно зависит от опыта разработчика.
Позволю дать вам некоторый совет. Никогда не стоит так рьяно отстаивать какую либо технологию или подход к разработке. Как у хорошего специалиста, у вас должен быть опыт работы со всеми представленными на рынке решениями для вашей платформы(не буду цитировать Будама, по поводу набора скиллз, вы и так думаю в курсе). И какой из подходов выбрать в данном конкретном случае вам иногда придется решать самому, а потом еще и доказать заказчику или руководству, что выбранный вами вариант действительно лучший для текущей задачи. И общие фразы типа “Дело в том, что инфраструктура ORM может быть очень громоздкой и не приносить никаких выгод в использовании”, может быть и проканают для заказчика, но для руководства, которое скорее всего опытнее вас, это будет звучать как – человек нихрена не знает.
По поводу изобретения велосипедов, у меня двоякое мнение. Когда кто либо начинает предлагать вещи типа, а давайте не будем использовать к примеру Hibernate, а сделаем собственный OR/M с блэкджеком и … Сразу возникает 2 вопроса:
1)Ты уверен, что твой вариант решения будет лучше технологии, которая уже несколько лет на рынке?
2)Сколько тебе нужно времени?
Как правило, у адекватного разработчика после этого пропадает желание чинить то, что не ломалось, но видимо в вашей крупной телекоммуникационной компании работают специалисты высочайшего класса, обладающие огромным бюджетом и неограниченным временем. Честно, очень рад за вас.
У меня богатый опыт работы и с тем и с другим.
Никто не предлагает разрабатывать собственный ОРМ, можно прекрасно работать и без оного, что многие компании и делают.
Тогда прошу прощения,
В последнем пункте речь шла как раз о вашем mapper-ре, что, как я понимаю, и есть жалкое подобие полноценной OR/M. На счет многие компании так и делают, я бы не стал заявлять так категорично.
Яков, скажите, а насколько в Штатах у вас развит рынок dataflow management?
Есть ли на нём люди? Заинтересованы ли они? Мне кажется, если бы появилось нечто, что способно управлять терабайтами данных в час, то очень многие бы компании это приобрели. Ваша компания берёт на себя такие задачи?
Отличный подкаст, спасибо 🙂
Про первую проблему вот на днях прочел хороший пост http://unab0mber.livejournal.com/1116318.html
Тут скорее не про overqualified, а sick of ent IT. Такая ли ситуация в USA в Enterprise? Если так же, что я не понимаю, откуда такое кол-во людей, которые так работают и не кончают со своей жизнью 🙂
Автор блога в ЖЖ просто лузер. Полностью обленившийся человек, который пытается найти виноватых вокруг, которые портят его жизнь. Неясно зачем такой принц сидит в этом болоте? А что неправильного или плохого в том, что руководство потратило на обед столько, сколько он зарабатывает за неделю? Или должно быть равенство?
Если интересно посмотреть на трех гиков во время проведения технического семинара весной 2010 в Брюсселе, это здесь: http://cyrilhanquez.com/blog/2010/03/19/farata-systems-flex-master-class-review/
Интересно, какой объект привлек ваше внимание на снимке?
1. DI – основной смысл – развязать компоненты программы, что позволит покрыть код юнит-тестами. + зачем делать глупую работу, как вызов дефолтного конструктора компонента(или с дефолтными параметрами), если контейнер может сделать это за тебя?
2. ORM или SQL – если я не ошибаюсь, основная идея любого ORM – это возможность абстрагироваться от уровня базы данных. Это значит что программисту не надо знать SQL, не надо знать какая база у него стоит. Он работает просто с объектами и ни о чем не задумывается, ясное дело что проекты с большой нагрузкой, не смогут обойтись ORM, так как генерированный код будет не оптимальным. Все упирается в деньги и скорость разработки.
И насчет ковбойского кода – господа, будь вы хоть семь пядей во лбу, научитесь писать нормально, код пишется для людей, а не для машин.
За объяснения что такое DI, ORM, и SQL спасибо. Вот уже и не зря подкаст записали – что-то новое для себя узнал. А то, что код пишется для людей, концепция тоже интересная. Свежая такая. Какая разница насколько эффективно программа работает? Задача сделать так, чтобы InnerJL понял код и при этом ему не пришлось SQL изучать.
Прошу к столу – вскипело (Михаил Жванецкий).
🙂 типичный ответ будама, каким я его знаю по подкастам последние пару лет.
Комментарии о DI в подкасте звучали так, как будто действительно не очень много об этом знаете.
InnerJL приходится изучать SQL и теорию баз данных, но есть ниша проектов, в которых можно обойтись и без этого. И они стартуют каждый день и приносят деньги. Django позиционирует себя, как фреймворк, который позволяет программировать, не задумываясь о базе данных. И это здорово, каждый инструмент создается для определенных задач.
Насчет фреймворков, могу посоветовать всем кандидатам отвечать так – они позволяют выполнить работу быстрее, следовательно дешевле. (Не надо говорить, что страдает качество, это не так). Сам язык Java – это “фреймворк” по сравнению с C++, попробуйте написать веб-сайт на C++.
Господа, пишите чистый и эффективный код – Ивану, Хосе и Джону потом его читать и изменять. Будьте в конце концов просто гуманными, поберегите их нервы.
Веселый ты парень. Просто хочу убедиться, что я правильно понял задачу. Эффективный, но сложный код писать не нужно ибо Дон Педро может его прочесть через пару лет. Дон Педро может его не догнать. Будет стыдно перед Доном Педро. А так как большинсво программистов нынче Педриллы, то еще и засмеют. Надо пойти на курсы программирования, чтобы научили как правильно писать. Если найду свой старый блог про Монголию, озвучу в подкасте 🙂