Ну теперь это вам придется каждый квартал делать, так как у них обновления апи есть, и они по чеклисту вас проверять будут =)
У них это разделено на категории, вот например хотите вы апи статы использовать — будьте любезны реализовать 5-10 пунктов (не маленьких)
Я не работаю в AdHands, но как человек, работавший с API Директа v4, Google AdWords 2013+, ВКонтакте, Begun могу сказать, что они настолько разные, что у вас либо будет выбираться слишком много данных из БД, чтобы сохранить интерфейсы простыми и будут проблемы с потерей remote id добавленых объектов, либо запросы к api будут неэффективными.
Поясню детально: в апи Директа до v5 добавлять и редактировать объявления можно только сразу передавая все параметры объявления, все ключевые слова, ставки и настроки по ним — просто адское кол-во данных (https://tech.yandex.ru/direct/doc/dg-v4/reference/CreateOrUpdateBanners-docpage/). Слава богу они в v5 это поправили и сделали более менее как в гугле. Доходило до того, что чтобы не затереть автопроставленные минус слова на фразах нам приходилось скачивать обявление из api, менять то, что нам нужно и отправлять обратно.
Что касается гугла, то тут наоборот — на каждый пук, извините, вызов метода. Например — добавить объявление, добавить допссылку, связать допссылку с объявлением. Хотя стоит отметить, что это лучший api, с которым мне пришлось работать по уровню свободы действий и в целом эффективности запросов к нему. Он на soap (xml), но работает раз в 5 быстрее чем json у api директа v4.
Ну и прикиньте еще, что будет у вас в «общих» методах. Еще вспомните о том, что программы падают, сеть пропадает и происходит много чего, что может вызвать добавление объектов во внешних сиетемах, но при этом упадет до сохранения полученных remote id объектов у вас в системе.
А еще в разных внешних системах не всегда совпадает иерархия объектов и вообще их наличие, настройки, иерархия настроек.
В общем-то я не против общих методов, они полезны, но иногда их поддержка стоит дороже, чем отдельная реализация.
pportnoy, если я правильно прочитал первый график, то я вижу, что и новых фичьвы стали делать в 2+ раза меньше, хотя количесво багов и уменьшилось.
Все верно?
Извиняюсь, если я не заметил в статье, но я не увидел итоги внедрения этого всего — вы стали делать фичи быстрее или стабильнее?
А самое главное, если не секрет, насколько это стало финансово выгоднее, чем то, что было до?
предполагается, что объекты в свойстве «a» идентичны. Оно и понятно, ведь есть код:
a = Reused(A, local=True)
Но не все так просто, так как также есть код:
u = Unique(U)
который, мне как читателю говорит, что экземпляры U должны быть уникальными для v1 и v2, при этом как-то надо переиспользовать a и b в этом самом U.
Видимо я не понял политику Constructs Unique. Не могли бы вы пояснить этот момент, так как, я не уверен, что правильно понял предложение «Уникальный в том смысле, что даже если в нашем графе уже где-то есть объект типа typeToBuild, мы все равно сгенерим новый.» Под уникальностью Unique понимается не контент объекта, как в случае с Reused, а ссылка на память?
Сразу извинюсь, если сейчас чушь спрашиваю, может просто код неверно прочитал — про python навыков увы нет.
Тут не смогу поспорить можно это назвать agile или нет.
Я правильно понял, что бизнес по сути не получал профита от разработки все эти 16 месяцев и смог зарабатывать деньги только в конце срока? По мне agile с точки зрения деплоя — это именно методология, которая позволяет получить профит для бизнеса в денежном эквиваленте после каждой итерации.
Можно у вас спросить почему для вашей команды не подошла водопадная модель?
На самом деле не многие задумываются над тем когда agile нужен команде, а когда нет.
Например у вас большой SAAS, который сам по себе много чего умеет и завязан на требования рынка и плюсом к нему поступает задача написать биллинг, но так, чтобы и другие «дружественные» проекты могли его использовать. При этом, допустим, в вашем SAAS проекте итерации одна неделя и agile там полезен.
В такой ситуации я бы сказал, что биллинг делать тоже по agile методологии не стоит, а надо сперва выделить людей из команды на биллинг или взять новых, собрать сведения, подумать, попытать менеджеров и дружественные проекты, подумать еще, составить список сущностей, диаграммы взаимодействий компонентов и сущностей, подумать над расширяемостью и т.д. Только после составить план и двигаться по нему по победного. Возможно только после написания основного куска, который замет у вас 1-3 месяца, уместно будет добавлять к биллингу рюшечки, работая по agile.
Конечно, можно экспериментировать с agile в биллинге с самого начала, но я думаю хорошего ничего не будет — либо итерации у вас будут большие, либо от итерации смысла не будет. В общем биллинг показывает проблему проектов, где польза для заказчика или пользователя наступает только после довольно большого куска проделанной работы. Ну и, конечно, если с разработкой биллинга поторопиться, то вероятно хорошего тоже ничего не будет — это же не личный блог.
Извините, Михаил, но я не понимаю зачем вообще такие комментарии тут нужны.
Вы бы лучше по делу написали — посоветовали бы почитать что-то конкретное или сами выдали рекомендации.
Я думаю хабр как раз для этого.
Заинтересовал один момент. У нас PostgreSQL используется в проекте с похожими характеристиками с точки зрения количества операций в единицу времени и объема БД. И по факту получается, что 7000 транзакций в секунду (в среднем) превращаются примерно в 600млн транзакций в сутки. А это значит, что каждые, грубо, три дня переполняется счётчик транзакций и база впадает в неизбежный многочасовой VACUUM. При размере БД больше 100ГБ процесс этот тянется медленно и печально. Фактически, некоторые, особо крупные, таблицы практически блокируются на время VACUUM'а. Не сталкивались ли вы с такой проблемой, учитывая, что заметные тормоза в вашем случае, по идее, недопустимы?
Хочу уточнить — немного не понял, что со сгенерированными объектами дальше происходит?
Те как эти данные попадают в БД, чтобы потом на них тесты гонялись?
Не соглашуть. Откуда pg знает на каком из серверов (!) хранятся данные об конкретном объекте? Сразу скажу, что рассматриваю ситуацию, когда на один сервер все данные не вмещаются (и это вполне реальная ситуация в большом проекте).
Самый быстрый хранить кеш в nosql, так как sql вечно что-то читает и пишет на диск при большом кол-во обращений. Даже тупо список друзей вывести будет проблема. Это лучше кешировать.
Я видимо говорил не про то, что вы подумали, я про то, что если вы знаете номер пользователя, то несложно понять где он находится. Просто вы составляете карту типа такой: serverId spotId userIdFrom userIdTo. И очень быстро находите место нахождения пользователя.
обычно лучший вариант — это тот, кода код может быстро получить номер сервера, к которому надо обращаться за данными. при такой реализации, при условии кеширования карты например в redis оверхед будет минимальным.
Я не уверен, что монге можно и нужно говорить что и куда она кладет. Вот допустим у вас пользователи и их друзья, допустим у вас сайт vk.com с их посещаемостью. если у вас список друзей будет «размазан» по серверам средствами БД, то вы рискуете получить неопределенное кол-во запросов к шардовым серверам. Если же вы храните друзей одного пользователя на одном сервере, то запрос будет всего один. Еще лучше, если вы сумеете хранить инфу о пользователе и его друзей на одно сервере — тогда профит будет вообще крутой. Это я все про большие нагрузки.
К чему я это — о нагрузках надо думать в самом начале, иначе рискуете нарваться на переписывание кода — это не надо никому.
У них это разделено на категории, вот например хотите вы апи статы использовать — будьте любезны реализовать 5-10 пунктов (не маленьких)
Я про https://developers.google.com/adwords/api/docs/access-levels
и IDEA 14.1.4 c lombok плагином нормально работает
Поясню детально: в апи Директа до v5 добавлять и редактировать объявления можно только сразу передавая все параметры объявления, все ключевые слова, ставки и настроки по ним — просто адское кол-во данных (https://tech.yandex.ru/direct/doc/dg-v4/reference/CreateOrUpdateBanners-docpage/). Слава богу они в v5 это поправили и сделали более менее как в гугле. Доходило до того, что чтобы не затереть автопроставленные минус слова на фразах нам приходилось скачивать обявление из api, менять то, что нам нужно и отправлять обратно.
Что касается гугла, то тут наоборот — на каждый пук, извините, вызов метода. Например — добавить объявление, добавить допссылку, связать допссылку с объявлением. Хотя стоит отметить, что это лучший api, с которым мне пришлось работать по уровню свободы действий и в целом эффективности запросов к нему. Он на soap (xml), но работает раз в 5 быстрее чем json у api директа v4.
Ну и прикиньте еще, что будет у вас в «общих» методах. Еще вспомните о том, что программы падают, сеть пропадает и происходит много чего, что может вызвать добавление объектов во внешних сиетемах, но при этом упадет до сохранения полученных remote id объектов у вас в системе.
А еще в разных внешних системах не всегда совпадает иерархия объектов и вообще их наличие, настройки, иерархия настроек.
В общем-то я не против общих методов, они полезны, но иногда их поддержка стоит дороже, чем отдельная реализация.
Все верно?
А самое главное, если не секрет, насколько это стало финансово выгоднее, чем то, что было до?
Например тот, что в yeoman есть — пакует как надо.
В коде github.com/yandex-qatools/builders/blob/master/builders/tests/test_builder.py#L81
вы строите два экземпляра класса V и судя про проверке
предполагается, что объекты в свойстве «a» идентичны. Оно и понятно, ведь есть код:
Но не все так просто, так как также есть код:
который, мне как читателю говорит, что экземпляры U должны быть уникальными для v1 и v2, при этом как-то надо переиспользовать a и b в этом самом U.
Видимо я не понял политику Constructs Unique. Не могли бы вы пояснить этот момент, так как, я не уверен, что правильно понял предложение «Уникальный в том смысле, что даже если в нашем графе уже где-то есть объект типа typeToBuild, мы все равно сгенерим новый.» Под уникальностью Unique понимается не контент объекта, как в случае с Reused, а ссылка на память?
Сразу извинюсь, если сейчас чушь спрашиваю, может просто код неверно прочитал — про python навыков увы нет.
Я правильно понял, что бизнес по сути не получал профита от разработки все эти 16 месяцев и смог зарабатывать деньги только в конце срока? По мне agile с точки зрения деплоя — это именно методология, которая позволяет получить профит для бизнеса в денежном эквиваленте после каждой итерации.
Можно у вас спросить почему для вашей команды не подошла водопадная модель?
Например у вас большой SAAS, который сам по себе много чего умеет и завязан на требования рынка и плюсом к нему поступает задача написать биллинг, но так, чтобы и другие «дружественные» проекты могли его использовать. При этом, допустим, в вашем SAAS проекте итерации одна неделя и agile там полезен.
В такой ситуации я бы сказал, что биллинг делать тоже по agile методологии не стоит, а надо сперва выделить людей из команды на биллинг или взять новых, собрать сведения, подумать, попытать менеджеров и дружественные проекты, подумать еще, составить список сущностей, диаграммы взаимодействий компонентов и сущностей, подумать над расширяемостью и т.д. Только после составить план и двигаться по нему по победного. Возможно только после написания основного куска, который замет у вас 1-3 месяца, уместно будет добавлять к биллингу рюшечки, работая по agile.
Конечно, можно экспериментировать с agile в биллинге с самого начала, но я думаю хорошего ничего не будет — либо итерации у вас будут большие, либо от итерации смысла не будет. В общем биллинг показывает проблему проектов, где польза для заказчика или пользователя наступает только после довольно большого куска проделанной работы. Ну и, конечно, если с разработкой биллинга поторопиться, то вероятно хорошего тоже ничего не будет — это же не личный блог.
Вы бы лучше по делу написали — посоветовали бы почитать что-то конкретное или сами выдали рекомендации.
Я думаю хабр как раз для этого.
Те как эти данные попадают в БД, чтобы потом на них тесты гонялись?
Если скажите, буду вам премного благодарен.
Я не уверен, что монге можно и нужно говорить что и куда она кладет. Вот допустим у вас пользователи и их друзья, допустим у вас сайт vk.com с их посещаемостью. если у вас список друзей будет «размазан» по серверам средствами БД, то вы рискуете получить неопределенное кол-во запросов к шардовым серверам. Если же вы храните друзей одного пользователя на одном сервере, то запрос будет всего один. Еще лучше, если вы сумеете хранить инфу о пользователе и его друзей на одно сервере — тогда профит будет вообще крутой. Это я все про большие нагрузки.
К чему я это — о нагрузках надо думать в самом начале, иначе рискуете нарваться на переписывание кода — это не надо никому.