Статья была написана давно, и мой коммент едва ли увидит много народу… Но я не нахожу эти вопросы глупыми.
Конечно, общетехнические вопросы я бы всё равно задавал.
Например, я спрашиваю у разработчика: «ты открываешь страницу сайта, и она долго загружается. Твои действия?» При это я ожидаю услышать про профилирование, пути локализации проблемы, explain и тп.
НО:
> Почему ты хочешь у нас работать?
Мне каждый день предлагают работать программистом в области рекламы и торговли. А я всю жизнь хотел делать что-то полезное для людей. Ваш проект кажется мне полезным и интересным.
[Знаете, возможно это звучит странно, но я хочу работать там, где я ХОЧУ работать. Где меня привлекает что-то кроме денег]
> Как ты думаешь, какое твое личное качество будет наиболее полезно в командной работе?
Вот тут не знаю, что ответить. Мне не задавали этот вопрос, и я не задавал.
> Что ты по-настоящему любишь делать?
Я люблю программировать, решать интересные задачи, учиться и узнавать что-то новое. Не люблю рутину, не люблю неинтересные задачи, не люблю верстать.
[Извините, ребята, если вы не можете мне предложить интересные задачи, вы мне не подходите. Да и я вам не подойду, потому что свалю через полгода].
Вообще, я для себя сформулировал описание идеальной работы:
«Если бы у меня было много денег, и мне не нужно было бы работать, я всё равно занимался бы этим проектом просто потому мне нравится этот проект и эта команда».
Скажите, а зачем в «В app/config/config.yml удаляем auto_mapping»
Я сам только что перешёл с первых версий Symfony и Doctrine на вторые и ещё не до конца разобрался, как работает mapping, но, насколько я понял, во-первых, и с auto_mapping всё работает, а во-вторых, если его убрать, придётся всё время помнить, что надо прописать маппинги при добавлении новых бандлов.
Или я не прав?
Уже несколько месяцев Ётой не пользуюсь (нет необходимости), но по старому негативному опыту вопрос:
а что если я выставлю 10 мбит/с, а реальная скорость так и останется 320 кбит/с (в виду загруженности каналов и ещё каких-то сугубо ётовских проблем)?
Кажется мне, проблема высосана из пальца.
Точнее, это проблема может возникнуть только у недобросовестных заказчиков и исполнителей.
А нормальный проект можно сделать только по ТЗ. Основываясь на вашем примере со строителями, в ТЗ НЕ МОЖЕТ НЕ БЫТЬ не описано, что в доме должна быть арка.
Вот она и радость заказчиков и разработчиков — сначала разработчик «оптичивает» ТЗ пункт за пунктом и получает удовольствие от каждой реализованной фичи ( = проставленной птички), потом заказчик «оптичивает» ТЗ при приёме работы.
И все счастливы.
Отдельный вопрос — разработка ТЗ. В тех случаях, когда заказчик не в состоянии написать ТЗ, оно обычно разрабатывается исполнителями за отдельную плату.
А подскажите, пожалуйста, какое решение возможно для такой ситуации:
Есть файл, который нельзя исключать из репозитария, но в строчке ХХ у одного разработчика должно стоять одно значение, а у другого — другое. Допустим, вынести эту настройку во внешний файл, который не участвует в репозитарии, по каким-то причинам нельзя. Городить логику из if-else тоже не хочется.
Как быть?
Может, можно сделать игнор не всего файла, а какой-то строки или нескольких строк?
Есть такая вещь, как Соглашение об уровне обслуживания (SLA).
Вот пример SLA одного из провайдеров, которым я пользуюсь:
Мы гарантируем следующие параметры услуги:
— время подключения сервера: 24 часа;
— доступность сервера: 99.5% (кроме DDoS и форс-мажорных обстоятельств);
— время ремонта/замены неисправного оборудования: 1 час.
При несоблюдении указанных параметров предоставляется компенсация, эквивалентная месячной стоимости услуги, в виде предоставления услуги в течение 1 месяца бесплатно.
Переездов у них еще не было, но был один простой порядка 5 часов. После этого мне в тот же день прислали письмо с извинениями и уведомлением о продлении услуг на один месяц.
Это у больших начальников обязанность такая. Не врать нельзя (очень дорого) и краснеть нельзя (раскусят).
Сам сталкивался с таким, когда вице-президент крупной инофирмы пытался удержать отдел разработки, врал как дышал просто))
Всё не так))
Во-первых, в XSLT есть вполне себе for-each, и есть много народу, которые пытаются на нём (на XSLT) программировать. Думаю, это не основное применение языка)
По поводу универсальности тоже можно поспорить. Когда объем данных большой, XSLT становится ощутимым тормозом. Например, подробный годовой отчет с кучей параметров с детализацией по дням.
XSLT настолько прост и изящен, что многие мои знакомые программисты, увидев его, стали его использовать его во всех проектах, даже в хомяках.
Попытайтесь встать на точку зрения не-программиста (верстальщика) и сравните 2 конструкции:
<?
foreach ($items as $item) {
echo "* {$item}\n";
}
?>
и
<xsl:template match='item'>
… красивый html-like код без страшных конструкций
</xsl:template>
> У идеала всё хорошо, кроме того, что в реальной жизни не встречается, увы.
Мне кажется, именно так сделали в яндексе. Не думаю, что XSLT там используется только из-за разных форм вывода одной информации (хотя и это тоже). Есть еще много крупных проектов, разные части которых написаны на разных языках. Сам на одном из таких работал. Если верстка и программинг разделены, то это вообще никого не парит.
Про ваш случай… Да, тут тонкий момент. Чтобы писать на смарти, достаточно его поизучать пару часов. Чтобы писать на XSLT хорошо, его надо полюбить) А плохо на XSLT лучше вообще не писать. Это будет медленно, некрасиво и только пополнит ряды ненавистников этой технологии. Впрочем, это относится не только к XSLT…
А я бы не рискнул доверить PHP верстальщику…
Как перешел на XSLT, понял, что с другими шаблонизаторами работать больше не могу. Если программизм серьезный, то идеальный вариант такой: программисты выдают XML где все данные подготовлены и представлены в нужном виде, и им абсолютно все равно, что с этими данными будут делать верстальщики.
Моя практика показывает, что верстальщику намного проще освоить xsl, чем php. Не целиком, а на уровне <xsl:template/> и <xsl:apply-templates/>
Уже вторая подобная статья… Я вот не совсем понимаю — вебмани и яндекс.деньги и так распространены. Процедуры внедрения их на свои сайты уже отлажены годами и описаны много где. Зачем про это писать?)
Про оплату через смс знают меньше народу, про оплату пластиковыми картами — еще меньше. А спрос на эти технологии при этом растет.
Думаю, ни с какими платежными системами проблем не будет, потому что они сами заинтересованы в сотрудничестве и оказывают посильную поддержку.
Но если уж так хотите написать, пишите лучше про PayPal, Chronopay и Assist (а можно и про то, как организовать свой акцептор платежей через пластиковые карты). Как клиенту, мне эти способы оплаты нравятся намного больше, а как программист, я еще недавно не знал, как внедрить их в свои приложения, и, в силу природной лени, избегал работы с ними.
До сих пор для меня идеалом был NetBeans. Его можно настроить так, что при работе с локальной версией проекта, при сохранении файла он автоматом сохраняет на ftp или sftp. Кстати, сегодня был приятно удивлен им. Добавил через файловый менеджер (не NetBeans'a. NetBeans просто в фоне висел) несколько новых файлов и папок в проект, переименовал несколько старых. NetBeans тут же пересканил проект и обновил файлы на удаленном сервере. Причем, судя по тому, как быстро он это сделал, скорее всего он не тупо удалил старые папки и создал новые, а переименовал старые. Как он догадался — не знаю :)
К сожалению, совсем не факт. На западе совсем другие учебные программы. Они актуальные для сегодняшних реалий. Как выпускник МГТУ им. Баумана, могу сказать, что в университете я развил аналитическое мышление, научился лучше работать с литературой, возможно ему чему-то… Но мне никаким боком не пригодилось и не пригодится то, чему меня непосредственно учили. В России, возможно, неплохо учат физиков и математиков, но программистов у нас учить не умеют.
Если выпускник ни разу не применял свои знания на практике, то он не будет сильно отличаться от первокурсника при создании первого сайта.
Конечно, общетехнические вопросы я бы всё равно задавал.
Например, я спрашиваю у разработчика: «ты открываешь страницу сайта, и она долго загружается. Твои действия?» При это я ожидаю услышать про профилирование, пути локализации проблемы, explain и тп.
НО:
> Почему ты хочешь у нас работать?
Мне каждый день предлагают работать программистом в области рекламы и торговли. А я всю жизнь хотел делать что-то полезное для людей. Ваш проект кажется мне полезным и интересным.
[Знаете, возможно это звучит странно, но я хочу работать там, где я ХОЧУ работать. Где меня привлекает что-то кроме денег]
> Как ты думаешь, какое твое личное качество будет наиболее полезно в командной работе?
Вот тут не знаю, что ответить. Мне не задавали этот вопрос, и я не задавал.
> Что ты по-настоящему любишь делать?
Я люблю программировать, решать интересные задачи, учиться и узнавать что-то новое. Не люблю рутину, не люблю неинтересные задачи, не люблю верстать.
[Извините, ребята, если вы не можете мне предложить интересные задачи, вы мне не подходите. Да и я вам не подойду, потому что свалю через полгода].
Вообще, я для себя сформулировал описание идеальной работы:
«Если бы у меня было много денег, и мне не нужно было бы работать, я всё равно занимался бы этим проектом просто потому мне нравится этот проект и эта команда».
Я сам только что перешёл с первых версий Symfony и Doctrine на вторые и ещё не до конца разобрался, как работает mapping, но, насколько я понял, во-первых, и с auto_mapping всё работает, а во-вторых, если его убрать, придётся всё время помнить, что надо прописать маппинги при добавлении новых бандлов.
Или я не прав?
а что если я выставлю 10 мбит/с, а реальная скорость так и останется 320 кбит/с (в виду загруженности каналов и ещё каких-то сугубо ётовских проблем)?
Вдвойне обрадовался, когда понял, что автор — тот самый Дима, с которым мы катали на двух колёсах в ярославскую область :)
Точнее, это проблема может возникнуть только у недобросовестных заказчиков и исполнителей.
А нормальный проект можно сделать только по ТЗ. Основываясь на вашем примере со строителями, в ТЗ НЕ МОЖЕТ НЕ БЫТЬ не описано, что в доме должна быть арка.
Вот она и радость заказчиков и разработчиков — сначала разработчик «оптичивает» ТЗ пункт за пунктом и получает удовольствие от каждой реализованной фичи ( = проставленной птички), потом заказчик «оптичивает» ТЗ при приёме работы.
И все счастливы.
Отдельный вопрос — разработка ТЗ. В тех случаях, когда заказчик не в состоянии написать ТЗ, оно обычно разрабатывается исполнителями за отдельную плату.
Есть файл, который нельзя исключать из репозитария, но в строчке ХХ у одного разработчика должно стоять одно значение, а у другого — другое. Допустим, вынести эту настройку во внешний файл, который не участвует в репозитарии, по каким-то причинам нельзя. Городить логику из if-else тоже не хочется.
Как быть?
Может, можно сделать игнор не всего файла, а какой-то строки или нескольких строк?
Вот пример SLA одного из провайдеров, которым я пользуюсь:
Переездов у них еще не было, но был один простой порядка 5 часов. После этого мне в тот же день прислали письмо с извинениями и уведомлением о продлении услуг на один месяц.
Сам сталкивался с таким, когда вице-президент крупной инофирмы пытался удержать отдел разработки, врал как дышал просто))
Во-первых, в XSLT есть вполне себе for-each, и есть много народу, которые пытаются на нём (на XSLT) программировать. Думаю, это не основное применение языка)
По поводу универсальности тоже можно поспорить. Когда объем данных большой, XSLT становится ощутимым тормозом. Например, подробный годовой отчет с кучей параметров с детализацией по дням.
XSLT настолько прост и изящен, что многие мои знакомые программисты, увидев его, стали его использовать его во всех проектах, даже в хомяках.
Попытайтесь встать на точку зрения не-программиста (верстальщика) и сравните 2 конструкции:
<?
foreach ($items as $item) {
echo "* {$item}\n";
}
?>
и
<xsl:template match='item'>
… красивый html-like код без страшных конструкций
</xsl:template>
<xsl:apply-templates select='item'/>
Мне кажется, именно так сделали в яндексе. Не думаю, что XSLT там используется только из-за разных форм вывода одной информации (хотя и это тоже). Есть еще много крупных проектов, разные части которых написаны на разных языках. Сам на одном из таких работал. Если верстка и программинг разделены, то это вообще никого не парит.
Про ваш случай… Да, тут тонкий момент. Чтобы писать на смарти, достаточно его поизучать пару часов. Чтобы писать на XSLT хорошо, его надо полюбить) А плохо на XSLT лучше вообще не писать. Это будет медленно, некрасиво и только пополнит ряды ненавистников этой технологии. Впрочем, это относится не только к XSLT…
Как перешел на XSLT, понял, что с другими шаблонизаторами работать больше не могу. Если программизм серьезный, то идеальный вариант такой: программисты выдают XML где все данные подготовлены и представлены в нужном виде, и им абсолютно все равно, что с этими данными будут делать верстальщики.
Моя практика показывает, что верстальщику намного проще освоить xsl, чем php. Не целиком, а на уровне <xsl:template/> и <xsl:apply-templates/>
Про оплату через смс знают меньше народу, про оплату пластиковыми картами — еще меньше. А спрос на эти технологии при этом растет.
Думаю, ни с какими платежными системами проблем не будет, потому что они сами заинтересованы в сотрудничестве и оказывают посильную поддержку.
Но если уж так хотите написать, пишите лучше про PayPal, Chronopay и Assist (а можно и про то, как организовать свой акцептор платежей через пластиковые карты). Как клиенту, мне эти способы оплаты нравятся намного больше, а как программист, я еще недавно не знал, как внедрить их в свои приложения, и, в силу природной лени, избегал работы с ними.
Если выпускник ни разу не применял свои знания на практике, то он не будет сильно отличаться от первокурсника при создании первого сайта.