arturgspb
0

Я бы даже сказал Текущего сварма, а не сварма времен начала кубера.

arturgspb
0

Короче походу сейчас проще со старичком maven, что для сборки java разобраться, чем с современной сборкой js. Прескорбно очень. Кучи настроек и файлов, чтобы просто проект начать… Капец… Сам страдаю, если что) в java правда на Градо перешел, так что полегче стало. Но js капец… Такое ощущение, что вообще не смотрят на какие грабли уже натыкались в старых топовых языках

arturgspb
0

Активно пользуемся cloudflare, очень круто, согласен. Есть только один нюанс, который не смогли побороть — автощащита от роботов. Когда питоном качаем статиек, которая, идёт через прокси cloudflare за их ssl, он иногда тупо долго отдает файлов или вообще тупит и потом сбрасывает соединение. Долго это легко сек 30. Сталкивались?

arturgspb
+4

Астрологи объявили год поклонения Котлину. )) Как это знакомо все… Года не проходит, начинаются посты Почему вас стоит… А через год, может и от этого же автора про другой язык и что Х, оказался не так хорош и бла бла. Прямо как с javascript, но там итерации короче — где-то полгода, до очередного просветления.

arturgspb
+3

Я пару лет назад понял и принял одно очень простое правило — списков объектов нет, есть только отчёты и там проще и быстрее в поддержке м развитии sql. Для выборки одного объекта на карточку этого объекта скорее всего orm может прокатить до определенного момента, в некоторых случаях, все равно на sql и там перейдешь. Для добавления или редактирования одного объекта тоже orm прокатит. А вот для тех, кто статистику с 100к записями в модели сериализует вместо hashmap или пр. есть отдельный котёл. )

arturgspb
0

Чем не угодил antlr парсер? У них там из папки примеров можно готовые грамматики взять.

arturgspb
+1

@and_rew, а вы используйте Navicat. Очень дельная программа, уже лет 5-6 пользуюсь. Вместе с pgAdmin-ом правда.

arturgspb
0

Не кажется ли вам это несколько ненормальным? ) В топовых языках такого сумбура я не наблюдаю, только в js каждые полгода что-то "новое" изобретают. И супер тренд, ИМХО типизация переменных. От неё вроде ушли, но чето вроде как народ понимает, что это все же не зло. А с компонентный подходом для построения ui вообще смех — тыщщу лет оно в операционных системах и тут бац, в web е наконец об этом вспомнили.

arturgspb
+2

Не проходит и полгода/год, как появляется очередной супер фреймворк и начинаются статьи типа: почему jquery фигня, я выбираю angular. Через год, ангуляр уже ваще тьма, а реакт просто чудо и всех спасет. Еще через полгода, как со scala случилось, оказывается, что и реакт не серебряная пуля. Ок… думает js сообщество, теперь vue. И, не прошло года после криков с сравнением ангуляр и ректально, как общественность не заставила себя долго ждать и пошли статьи как обычно с громким и названиями "почему я перехожу на vue". Ну смешно просто)

arturgspb
0

Используем uotine ribot год наверо, всегда работает и шлем себе в телеграмм через http get запрос. Запрос там шаблонизируется за 5 минут.

arturgspb
0
Ну теперь это вам придется каждый квартал делать, так как у них обновления апи есть, и они по чеклисту вас проверять будут =)
У них это разделено на категории, вот например хотите вы апи статы использовать — будьте любезны реализовать 5-10 пунктов (не маленьких)
arturgspb
0
Nicholas_Savelev, у вас сейчас стандартный уровень доступа в api adwords?

Я про https://developers.google.com/adwords/api/docs/access-levels
arturgspb
0
lombok, кстати умеет val — https://projectlombok.org/features/val.html
и IDEA 14.1.4 c lombok плагином нормально работает
arturgspb
0
Я не работаю в 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 объектов у вас в системе.
А еще в разных внешних системах не всегда совпадает иерархия объектов и вообще их наличие, настройки, иерархия настроек.

В общем-то я не против общих методов, они полезны, но иногда их поддержка стоит дороже, чем отдельная реализация.
arturgspb
0
pportnoy, если я правильно прочитал первый график, то я вижу, что и новых фичьвы стали делать в 2+ раза меньше, хотя количесво багов и уменьшилось.
Все верно?
arturgspb
0
Извиняюсь, если я не заметил в статье, но я не увидел итоги внедрения этого всего — вы стали делать фичи быстрее или стабильнее?
А самое главное, если не секрет, насколько это стало финансово выгоднее, чем то, что было до?
arturgspb
+1
Посмотрите на Scala — это язык способен помочь вам не писать много кода, он типизированнный и вы сможете использовать Java библиотеки.
arturgspb
+2
Я вам больше скажу — есть js минификаторы, которые и без повторений все нормально понимают.
Например тот, что в yeoman есть — пакует как надо.
arturgspb
0
dchr, еще вопрос к вам.

В коде github.com/yandex-qatools/builders/blob/master/builders/tests/test_builder.py#L81
вы строите два экземпляра класса V и судя про проверке
assert v1.u.a == v2.u.a


предполагается, что объекты в свойстве «a» идентичны. Оно и понятно, ведь есть код:
a = Reused(A, local=True)

Но не все так просто, так как также есть код:
u = Unique(U)

который, мне как читателю говорит, что экземпляры U должны быть уникальными для v1 и v2, при этом как-то надо переиспользовать a и b в этом самом U.

Видимо я не понял политику Constructs Unique. Не могли бы вы пояснить этот момент, так как, я не уверен, что правильно понял предложение «Уникальный в том смысле, что даже если в нашем графе уже где-то есть объект типа typeToBuild, мы все равно сгенерим новый.» Под уникальностью Unique понимается не контент объекта, как в случае с Reused, а ссылка на память?

Сразу извинюсь, если сейчас чушь спрашиваю, может просто код неверно прочитал — про python навыков увы нет.
arturgspb
–1
Тут не смогу поспорить можно это назвать agile или нет.

Я правильно понял, что бизнес по сути не получал профита от разработки все эти 16 месяцев и смог зарабатывать деньги только в конце срока? По мне agile с точки зрения деплоя — это именно методология, которая позволяет получить профит для бизнеса в денежном эквиваленте после каждой итерации.

Можно у вас спросить почему для вашей команды не подошла водопадная модель?
arturgspb
+5
На самом деле не многие задумываются над тем когда agile нужен команде, а когда нет.
Например у вас большой SAAS, который сам по себе много чего умеет и завязан на требования рынка и плюсом к нему поступает задача написать биллинг, но так, чтобы и другие «дружественные» проекты могли его использовать. При этом, допустим, в вашем SAAS проекте итерации одна неделя и agile там полезен.

В такой ситуации я бы сказал, что биллинг делать тоже по agile методологии не стоит, а надо сперва выделить людей из команды на биллинг или взять новых, собрать сведения, подумать, попытать менеджеров и дружественные проекты, подумать еще, составить список сущностей, диаграммы взаимодействий компонентов и сущностей, подумать над расширяемостью и т.д. Только после составить план и двигаться по нему по победного. Возможно только после написания основного куска, который замет у вас 1-3 месяца, уместно будет добавлять к биллингу рюшечки, работая по agile.

Конечно, можно экспериментировать с agile в биллинге с самого начала, но я думаю хорошего ничего не будет — либо итерации у вас будут большие, либо от итерации смысла не будет. В общем биллинг показывает проблему проектов, где польза для заказчика или пользователя наступает только после довольно большого куска проделанной работы. Ну и, конечно, если с разработкой биллинга поторопиться, то вероятно хорошего тоже ничего не будет — это же не личный блог.
arturgspb
+1
Извините, Михаил, но я не понимаю зачем вообще такие комментарии тут нужны.
Вы бы лучше по делу написали — посоветовали бы почитать что-то конкретное или сами выдали рекомендации.
Я думаю хабр как раз для этого.
arturgspb
0
Скажите пожалуйста, а как вы пытались бороться с потерей производительности на postgres до того, как перешли на mysql?
arturgspb
+1
Заинтересовал один момент. У нас PostgreSQL используется в проекте с похожими характеристиками с точки зрения количества операций в единицу времени и объема БД. И по факту получается, что 7000 транзакций в секунду (в среднем) превращаются примерно в 600млн транзакций в сутки. А это значит, что каждые, грубо, три дня переполняется счётчик транзакций и база впадает в неизбежный многочасовой VACUUM. При размере БД больше 100ГБ процесс этот тянется медленно и печально. Фактически, некоторые, особо крупные, таблицы практически блокируются на время VACUUM'а. Не сталкивались ли вы с такой проблемой, учитывая, что заметные тормоза в вашем случае, по идее, недопустимы?
arturgspb
0
Хочу уточнить — немного не понял, что со сгенерированными объектами дальше происходит?
Те как эти данные попадают в БД, чтобы потом на них тесты гонялись?
arturgspb
+7
Интересно другое исследование — почти таже самая диаграма, только отображающая то, что реально произошло через 5 лет ;)
arturgspb
0
Не соглашуть. Откуда pg знает на каком из серверов (!) хранятся данные об конкретном объекте? Сразу скажу, что рассматриваю ситуацию, когда на один сервер все данные не вмещаются (и это вполне реальная ситуация в большом проекте).

Если скажите, буду вам премного благодарен.
arturgspb
0
Самый быстрый хранить кеш в nosql, так как sql вечно что-то читает и пишет на диск при большом кол-во обращений. Даже тупо список друзей вывести будет проблема. Это лучше кешировать.
arturgspb
0
Я видимо говорил не про то, что вы подумали, я про то, что если вы знаете номер пользователя, то несложно понять где он находится. Просто вы составляете карту типа такой: serverId spotId userIdFrom userIdTo. И очень быстро находите место нахождения пользователя.
arturgspb
0
обычно лучший вариант — это тот, кода код может быстро получить номер сервера, к которому надо обращаться за данными. при такой реализации, при условии кеширования карты например в redis оверхед будет минимальным.

Я не уверен, что монге можно и нужно говорить что и куда она кладет. Вот допустим у вас пользователи и их друзья, допустим у вас сайт vk.com с их посещаемостью. если у вас список друзей будет «размазан» по серверам средствами БД, то вы рискуете получить неопределенное кол-во запросов к шардовым серверам. Если же вы храните друзей одного пользователя на одном сервере, то запрос будет всего один. Еще лучше, если вы сумеете хранить инфу о пользователе и его друзей на одно сервере — тогда профит будет вообще крутой. Это я все про большие нагрузки.

К чему я это — о нагрузках надо думать в самом начале, иначе рискуете нарваться на переписывание кода — это не надо никому.
arturgspb
0
Подход действительно интересный, вот только есть одно НО, и довольно большое — возможно я что-то пропустил, но я понял, что у вас один сервер БД и все. Предполагается, что допустим это логи по действию пользователя, робота, рекламы у вас на сайте. Все будет отлично пока у вас менее миллиона пользователей (это я с потолка для примера). Логи по ним будут собираться вы раз в день будете сбрасывать их в архив и т.д. Все довольны.

Но если пользователей становиться в 10 раз больше вы начинаете выбирать — или подрезать чаще, чем раз в день или хранить меньше статы. Так как ваш код не готов к работе с двумя подключениями. По хорошему надо сразу делать так, чтобы код не надо было переделывать из-за роста данных, так как рост данных (например набирающая оборот соц. сеть) вы не прекратите, сервер перполнится и вы будете говорить менеджеру проекта, что вам надо over 1 month на переделку кода. Прикол в том, что этого времени просто нет и вы можете потерять проект, так как пользователи просто уйдут от вас, так как не могут комментить, фотки заргружать и т.д.

Конечно, тут можно спорить о преждевременной оптимизации, улучшениях, которые возможно не понядобятся, если проект не выстрелит. Так вот — если он выстрелит и не справиться с возросшей нагрузкой, то он просто будет не нужен. А хороших проектов мало.
arturgspb
0
У меня вопрос — действительно ли полное ТЗ по задаче у вас формируется примерно так:

Рисуется, верстается, менеджер проекта или направления сам или с помощью тех. писателя пишет полное исчерпывающее ТЗ.
Все вопросы от программистов решаются в рамках комментариев в задаче — т.е. разработчик спрашивает, ему там отвечают и ничего не остается не задокументированным?
arturgspb
0
Понятно, главное, что никакой магии с полем Client нет, это просто public свойство Q верно?
arturgspb
0
Ага, уже понятнее. Вы меня остановите пожалуйста, если я тут флуд устраиваю. Ссылочное поле Client появляется при прекомпиляции или его заводит программист?
arturgspb
0
Спасибо за информацию, попробую у себя как-то такое реализовать, думаю поможет разрабатывать быстрее.

Скажите, а IDE поддерживают автокомплит такой записи — «q.Client.Address.Country.Languages.Contains»? Я люблю записи в виде цепочки, но, если IDE мне помогает) Просто не знаю, в рамках какого языка это пример, но что-то похожее на C# или Java.
arturgspb
0
У меня на php так:

$taskQueues = \TaskQueue\Model::select()
        ->withTaskId([1, 2, 3])
        ->withTaskOrigin(10)
        ->getCollection();


Второй ваш запрос я не понял, честно, но наверное, потому, что с этой ORM я не знаком.

Но если простой join, то примерно так:
$clientSelector = \Client\Model::select()
        ->withNameNotContains('Артур');

$taskQueues = \TaskQueue\Model::select()
        ->join($clientSelector)
        ->getCollection();


ну или так:
$taskQueues = \TaskQueue\Model::select()
        ->join(\Client\Model::select()->withNameNotContains('Артур'))
        ->getCollection();

Но предыдущий вариант, мне нравиться больше, если условий больше.
arturgspb
0
Я все равно не понял вас. Я имел ввиду что дома не занимаюсь, но в тренажерку хожу. А о каких бомжах вы говорили?
arturgspb
0
Простите, что? Чего дома не было и при чем тут бомжи?
arturgspb
+6
А где пункт «дома нет, но хожу в тренажерку»? А то сгребете под одну гребенку тех кто вообще не занимается и тех кто дома не занимается.
arturgspb
0
Посмотрев на картинку превью подумал — а где собственно знак нуля? Даже опешил на минуту — подумал, что они решили, что мы и без него справимся) Полез в ttf — хорошо, что там есть)