Комментарии 33
Суперское интервью, понравилось. Очень заинтересовала вот эта фраза:
Если хотите, вообще могу рассказать отдельно, как мы пытались внедрить agile в нашу компанию и почему он не пошёл, это очень интересная отдельная тема.Расскажете?
потому что любые методолгии разработки — дерьмо и пустая трата времени
Нет, я как раз так не считаю.
Если очень кратко:
* Аджайл в целом и скрам в частности является наполовину сборником просто хороших рецептов здравого смысла, а частично — сектантством, тк старается притянуть за уши всё-всё в свою единственно-верную модель мира.
* Аджайл не работает в саппорте, его в большом проекте грубо половина. По аджайлу не могут работать пожарные, полиция. Это не значит что у всех больших сплошной пожар, конечно, но вы поняли ;)
* Аждайл плохо принимается гордым и матерым профи, в то время как он может быть очень полезен для бизнеса при других условиях работы. То есть — либо такого человека «ломать», либо расставаться. Это — совершенно неэффективно в условиях, когда все определяют люди, и особенно когда хорошие люди — на вес золота.
* Тут самый холиварный момент, комментарий темной силы. Аджайл не позволяет системно выводить команды или отдельных участников в транс извне, подталкивать и принуждать к эффективной работе. Команда начнёт защищаться, в скраме — через покер, стараясь оставаться в зоне комфорта (далеко не самой эффективной зоне для бизнеса).
Если очень кратко:
* Аджайл в целом и скрам в частности является наполовину сборником просто хороших рецептов здравого смысла, а частично — сектантством, тк старается притянуть за уши всё-всё в свою единственно-верную модель мира.
* Аджайл не работает в саппорте, его в большом проекте грубо половина. По аджайлу не могут работать пожарные, полиция. Это не значит что у всех больших сплошной пожар, конечно, но вы поняли ;)
* Аждайл плохо принимается гордым и матерым профи, в то время как он может быть очень полезен для бизнеса при других условиях работы. То есть — либо такого человека «ломать», либо расставаться. Это — совершенно неэффективно в условиях, когда все определяют люди, и особенно когда хорошие люди — на вес золота.
* Тут самый холиварный момент, комментарий темной силы. Аджайл не позволяет системно выводить команды или отдельных участников в транс извне, подталкивать и принуждать к эффективной работе. Команда начнёт защищаться, в скраме — через покер, стараясь оставаться в зоне комфорта (далеко не самой эффективной зоне для бизнеса).
вы разве не понимаете что эффективности от этого ноль, есть лишь видимость эффективности. просто людям делать нечего. им всегда делать нечего
Алексей, что вы имеете ввиду под «саппортом», которого — «в большом проекте грубо половина» — фикс багов? Почему, например, фикс багов в сочетании с рефакторингом проблемной области не может вписывать в agile?
Так же, что вы имеете ввиду под «выведением команды в транс извне», когда команду нужно принуждать к эффективной работе? — вы предполагаете, что команда не сформировалась и требуется внешнее воздействие, или что команда занимается не тем, что нужно для бизнеса? В последнем случае, причём здесь agile?
Так же, что вы имеете ввиду под «выведением команды в транс извне», когда команду нужно принуждать к эффективной работе? — вы предполагаете, что команда не сформировалась и требуется внешнее воздействие, или что команда занимается не тем, что нужно для бизнеса? В последнем случае, причём здесь agile?
Нет, саппорт — это не фикс багов. Это любая работа по поддержке большой системы в продакшене. Попробуйте представить, как будут работать «по аджайлу» пожарные и полиция, вам всё станет сразу ясно. Если не стало — вы программист и аджайл-сектант :) Касательно второго пункта — у вас какая-то волшебная формула, команда «сформировалась» — значит, всё отлично. Так не бывает. Но в это свято верят аджайл-сектанты.
Алексей, вы, как многоопытный человек, не можете не понимать, что agile-методологии предназначены для эффективной работы команд и перекладывании на команды значительной области ответственности менеджмента. Формирование команд с сопутствующим значительным повышением общей эффективности — непреложный и надёжно зафиксированный исследованиями факт, так же как и «неформирование» команд при наличии неразрешённых проблем. Понятно, что не всё в этом мире идеально и от любого изменения состава команды её будет «трясти». Но дело в том, что agile-методологии позволяют технические задачи по организации команд переложить на сами команды, а на этапе ввода — на консультантов agile'а.
Можно, конечно, и дальше запираться и утверждать, что все они сектанты и это не работает, если бы не было удачных примеров. Например, команды, работающие над веб-платформой скайпа, перешли на скрам, и весьма довольны результатом.
Можно, конечно, и дальше запираться и утверждать, что все они сектанты и это не работает, если бы не было удачных примеров. Например, команды, работающие над веб-платформой скайпа, перешли на скрам, и весьма довольны результатом.
А вы, извините, кто по профессии? А к Badoo какое отношение имеете?
НЛО прилетело и опубликовало эту надпись здесь
— когда стоит использовать облачные сервисы, а когда физический хостинг.
вопрос, конечно, довольно ясный, но пропущен почему-то, хотя в заглавии есть
вопрос, конечно, довольно ясный, но пропущен почему-то, хотя в заглавии есть
Блин, вообще них… я не понял, простите.
Как устроено масштабирование и балансировка?
Как реализован шардинг и репликация БД?
Как реализуется бэкап?
Как устроена ваша CDN?
Как обеспечивается failover при выходе какого-либо физического сервера из строя?
Как устроена защита от DDoS?
Как устроена защита от ботов?
Какова архитектура приложений в целом?
Как сишные и пхпшные сервисы общаются между собой?
Как реализуются параллельные вычисления на сложных участках?
Как реализован деплой и роллбэк, в частности при изменений структур БД?
Как управляется железная инфраструктура в датацентрах?
Как мониторите нелегальный контент?
Весь подкаст (и соответственно вся статья) — какое-то маркетинговое бла-бла на уровне студентов первого курса. Подробности давайте.
Как устроено масштабирование и балансировка?
Как реализован шардинг и репликация БД?
Как реализуется бэкап?
Как устроена ваша CDN?
Как обеспечивается failover при выходе какого-либо физического сервера из строя?
Как устроена защита от DDoS?
Как устроена защита от ботов?
Какова архитектура приложений в целом?
Как сишные и пхпшные сервисы общаются между собой?
Как реализуются параллельные вычисления на сложных участках?
Как реализован деплой и роллбэк, в частности при изменений структур БД?
Как управляется железная инфраструктура в датацентрах?
Как мониторите нелегальный контент?
Весь подкаст (и соответственно вся статья) — какое-то маркетинговое бла-бла на уровне студентов первого курса. Подробности давайте.
Вопросы полностью определяются авторами подкаста.
* масштабирование, шардинг, бекап, частично про failover — в первой части.
* CDN — был доклад в 2007м на РИТе, долго рассказывать в деталях, кратко — все стандартно, слой кешей и бекенды к стораджам, немного магии по вычищению холодного контента с кешей, дц с кешами можем ставить в интересующих регионах (пилотный проект недавно запустили в азии)
* защита от ботов — антиспам-отдел, там много всяких штук, инфа по понятным причинам будет всегда закрыта, увы
* DDoS — попробуй задидось (мелкие не потянут, если будет очень крупный «заказ» — будем резать на магистральных уровнях)
* сишные и пхпшные сервисы общаются через gpbs все интерфейсы генерятся автоматом
* параллельные вычисления почти не нужны (долгий разговор, есть свой фреймворк для параллельных приложений, в BI есть Hadoop)
* деплой и роллбек — смотрите блог, куча статей на тему и доклады на РИТе и на прочих конференциях
* железная инфраструктура — ну конкретные вопросы напишите — ответим, слишком общий вопрос
* нелегальный контент — ручная модерация + распознавалка
Если ещё нужны подробности — спрашивайте!
* масштабирование, шардинг, бекап, частично про failover — в первой части.
* CDN — был доклад в 2007м на РИТе, долго рассказывать в деталях, кратко — все стандартно, слой кешей и бекенды к стораджам, немного магии по вычищению холодного контента с кешей, дц с кешами можем ставить в интересующих регионах (пилотный проект недавно запустили в азии)
* защита от ботов — антиспам-отдел, там много всяких штук, инфа по понятным причинам будет всегда закрыта, увы
* DDoS — попробуй задидось (мелкие не потянут, если будет очень крупный «заказ» — будем резать на магистральных уровнях)
* сишные и пхпшные сервисы общаются через gpbs все интерфейсы генерятся автоматом
* параллельные вычисления почти не нужны (долгий разговор, есть свой фреймворк для параллельных приложений, в BI есть Hadoop)
* деплой и роллбек — смотрите блог, куча статей на тему и доклады на РИТе и на прочих конференциях
* железная инфраструктура — ну конкретные вопросы напишите — ответим, слишком общий вопрос
* нелегальный контент — ручная модерация + распознавалка
Если ещё нужны подробности — спрашивайте!
Архитектура приложения в целом интересует.
Монолит, модульная, SOA с общением напрямую, SOA с ESB, очереди сообщений?
Я видел Фотострану изнутри + по Мамбе с Федоровским общался, интересно какой путь вы избрали.
Монолит, модульная, SOA с общением напрямую, SOA с ESB, очереди сообщений?
Я видел Фотострану изнутри + по Мамбе с Федоровским общался, интересно какой путь вы избрали.
не понимаю, зачем всё в кучу — модули, SOA, ESB, MQ…
есть всякое, у нас просто куча приложений разных. ну разве что ESB нигде нет, боже упаси. ну и SOA вообще в хайлоаде очень редко — или Вы webapp имели в виду?
есть всякое, у нас просто куча приложений разных. ну разве что ESB нигде нет, боже упаси. ну и SOA вообще в хайлоаде очень редко — или Вы webapp имели в виду?
Фразу «у нас просто куча приложений разных» из уст руководителя разработки я себе в рамочку поставлю, да.
Ну не хотите по делу рассказывать — Ваше право, посмотрю презентации. Нафига только было пост писать, неясно, если вопросы вглубь не копать.
Ну не хотите по делу рассказывать — Ваше право, посмотрю презентации. Нафига только было пост писать, неясно, если вопросы вглубь не копать.
Эту фразу можно было бы также воспринять как робкую попытку уточнить, какие приложения интересуют. У нас есть несколько мобильных приложений, причем нативных, под них серверные приложения, фейсбук-приложения, обычный сайт, приложения для интеграции с платежными системами, с социальными сетями, куча оффлайн приложений для мониторинга, статистики, построения RRD/отчетов, обработки очередей, прочих данных от антиспама до BI. Вы же понимаете, что говорить о какой-то единой архитектуре для такого набора несколько бессмысленно?
Алексей, расскажите, пожалуйста:
1. gbps — это хитрый секретный протокол, или просто означает, что сервисы общаются по сети? По сути оригинального вопроса: у вас сервисы общаются на голых tcp-запросах, используется свой формат данных, или что-нибудь известное, от json до protobuf? Используется ли общение между C и PHP сервисами через scribe?
2. По параллельным вычислениям: ваш фреймворк сделан на основе форков, или позволяет распределённые вычисления? В последнем случае — как это работает?
1. gbps — это хитрый секретный протокол, или просто означает, что сервисы общаются по сети? По сути оригинального вопроса: у вас сервисы общаются на голых tcp-запросах, используется свой формат данных, или что-нибудь известное, от json до protobuf? Используется ли общение между C и PHP сервисами через scribe?
2. По параллельным вычислениям: ваш фреймворк сделан на основе форков, или позволяет распределённые вычисления? В последнем случае — как это работает?
тест на php.feedme.ru чуток понижает самооценку :)
По поводу ORM — жиденькая позиция. Например, через Hibernate можно запускать нативный SQL, получая на выходе либо уже готовые сущности, либо нетипизированные объекты. Т.е., кроме высокоуровневого языка Hibernate, дающего на выходе высокоуровневые объекты, можно также детализироваться до чистого SQL, и даже получить ужасно удобный микс — отдать SQL, получить обратно типизированный замапленный объект.
Три ваших абзаца про ORM мне почему-то кажутся чистой теорией. Лично я 10 лет в проектах масштаба предприятия работаю исключительно через ORM Hibernate. 90+ процентов кода вообще не требуют оптимизации, просто потому, что это простые вещи. Если же где-то требуется более внимательный подход к ресурсам или сложные выборки — Hibernate может это сделать, при этом в большинстве случаев не загаживая ваши исходники рутинным перекладыванием объектов.
Я понимаю, что у вас своя специфика и средний JEE-проект по нагрузкам не тянет и десятой доли ваших, но тем не менее, ваша фраза "ORM — это небольшие проекты, где очень быстро можно сделать интерфейс, не знаю, редактирования, да каких-то простых сущностей. " не выдерживает никакой критики. А хуже всего, что новички прочитают авторитетное мнение и возьмут на вооружение. Печально…
Три ваших абзаца про ORM мне почему-то кажутся чистой теорией. Лично я 10 лет в проектах масштаба предприятия работаю исключительно через ORM Hibernate. 90+ процентов кода вообще не требуют оптимизации, просто потому, что это простые вещи. Если же где-то требуется более внимательный подход к ресурсам или сложные выборки — Hibernate может это сделать, при этом в большинстве случаев не загаживая ваши исходники рутинным перекладыванием объектов.
Я понимаю, что у вас своя специфика и средний JEE-проект по нагрузкам не тянет и десятой доли ваших, но тем не менее, ваша фраза "ORM — это небольшие проекты, где очень быстро можно сделать интерфейс, не знаю, редактирования, да каких-то простых сущностей. " не выдерживает никакой критики. А хуже всего, что новички прочитают авторитетное мнение и возьмут на вооружение. Печально…
огласите, пожалуйста
1) какую СУБД вы используете
2) число запросов в секунду на
* application server/cluster
* database server/cluster
3) какие аналитические задачи решаются через Hibernate
4) размер команды, поддерживающей проект
5) время жизни проекта
6) приблизительное число сущностей (таблиц)
7) приблизительное число строк java-кода
спасибо
1) какую СУБД вы используете
2) число запросов в секунду на
* application server/cluster
* database server/cluster
3) какие аналитические задачи решаются через Hibernate
4) размер команды, поддерживающей проект
5) время жизни проекта
6) приблизительное число сущностей (таблиц)
7) приблизительное число строк java-кода
спасибо
Ну проектов было несколько, но все JEE, более того, некоторые работают в масштабах страны (не России, но всё же...).
1) В основном Oracle, лет 10 назад попадался Infomix
2) Тут до вас запредельно далеко, не более 100 в секунду, обычно меньше, но запросы достаточно тяжелые, например SOAP веб-сервисы с выборкой из БД. Парсинг XML, знаете ли, штука ресурсоемкая, но стандартизация обязывает.
3) Из аналитики — отчеты, формируемые выборками из БД. Существенной разницы не замечено между запуском их через приклад и напрямую SQL-ем в БД, конечно при условии передачи Hibernate-у нативного SQL-а
4) От 1-го до 30-ти разработчиков на разных проектах и разных этапах.
5) Первый Enterprise, на котором я был джуниором 10 лет назад еще работает. Распределенная система из полуторасотни серверов приложений+баз данных, разбросанных регионально. Абсолютно все более поздние проекты сейчас так же находятся в промышленной эксплуатации.
6) Глянул в текущем проекте — 316 таблиц, в некоторых из них 200-300 полей
7) Вот это не считал, сейчас нет времени искать утилиту, если что — попозже. НО! Думаю, что кол-во строк кода — одно из главных преимуществ ORM-фреймворков, так что больше кода — не всегда означает более сложный проект.
Еще раз скажу, что ни в коем случае не претендую на опыт работы со схожими с вашими объемами данных, но моё ИМХО повторю: "небольшие проекты" — это вы чересчур загнули.
1) В основном Oracle, лет 10 назад попадался Infomix
2) Тут до вас запредельно далеко, не более 100 в секунду, обычно меньше, но запросы достаточно тяжелые, например SOAP веб-сервисы с выборкой из БД. Парсинг XML, знаете ли, штука ресурсоемкая, но стандартизация обязывает.
3) Из аналитики — отчеты, формируемые выборками из БД. Существенной разницы не замечено между запуском их через приклад и напрямую SQL-ем в БД, конечно при условии передачи Hibernate-у нативного SQL-а
4) От 1-го до 30-ти разработчиков на разных проектах и разных этапах.
5) Первый Enterprise, на котором я был джуниором 10 лет назад еще работает. Распределенная система из полуторасотни серверов приложений+баз данных, разбросанных регионально. Абсолютно все более поздние проекты сейчас так же находятся в промышленной эксплуатации.
6) Глянул в текущем проекте — 316 таблиц, в некоторых из них 200-300 полей
7) Вот это не считал, сейчас нет времени искать утилиту, если что — попозже. НО! Думаю, что кол-во строк кода — одно из главных преимуществ ORM-фреймворков, так что больше кода — не всегда означает более сложный проект.
Еще раз скажу, что ни в коем случае не претендую на опыт работы со схожими с вашими объемами данных, но моё ИМХО повторю: "небольшие проекты" — это вы чересчур загнули.
Ясно, соглашусь с Вами. Для меня «небольшой» = с небольшой нагрузкой. Это некорректно, Вы правы. У нас десятки тысяч запросов в секунду на кластер приложений, порядок запросов к кластеру баз — примерно такой же. Меня смутило, что Вы написали про «десятую долю».
В свою очередь, прошу меня извинить, если тон был излишне резок. Я хотел высказаться не столько против Вас, сколько за ORM. При хорошей реализации (такой, например, как Hibernate), вещь это чрезвычайно мощная и полезная, и должна применяться в абсолютном большинстве случаев, начиная от простеньких утилит и заканчивая, естественно, Enterprise-ами. Другое дело, что даже в абсолютном большинстве есть исключения, что, собственно к вам и относится.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Архитектура высоконагруженных приложений. Масштабирование распределенных систем. Часть вторая