это как про крутой компилятор с кучей проверок сказать что никаких гарантий на его результаты не даем

Смешнее было бы, если бы это было написано про коммерческий проприетарный софт, за который нужно платить

венда (as is)

Смешнее было бы, если бы это было написано про коммерческий проприетарный софт, за который нужно платить

про Винду же так

Смешнее было бы, если бы это было написано про коммерческий проприетарный софт, за который нужно платить

коммерческий проприетарный платный лицензируемый софт, за который нужно платить, покупать его и отдавать за него деньги

коммерческий проприетарный платный лицензируемый софт, за который нужно платить, покупать его и отдавать за него деньги

Масло масляное какое-то , честное слово

Зачем его ругать, если он заставляет нас подумать и взглянуть на вещи критически

Чепуху он всякую говорит. Какие-то "объекты" придумал, "композицию объектов", ещё что-то. Я сильно не углублялся, но по ощущениям человек не разбирается даже в тех темах, о которых пишет. По-моему, достаточно код Егора посмотреть.

коммерческий проприетарный платный лицензируемый софт, за который нужно платить, покупать его и отдавать за него деньги

орнул чет

Чепуху он всякую говорит. Какие-то "объекты" придумал, "композицию объектов", ещё что-то. Я сильно не углублялся, но по ощущениям человек не разбирается даже в тех темах, о которых пишет. По-моему, достаточно код Егора посмотреть.

но там же хадукен!

Извините, я не понял шутки.

кто-нибудь собирается участвовать в хакатоне вк?

Ага)

а уже подал заявку?

@rockjam хочешь команду собрать?

@rockjam если позовешь, то с меня дизайнер и верстальщик

и даже фронтендер)

кто-нибудь собирается участвовать в хакатоне вк?

kakom

https://vk.com/vkhackathon

@rockjam хочешь команду собрать?

ну хотел бы пойти. но пока не знаю с чем и с кем)

ну хотел бы пойти. но пока не знаю с чем и с кем)

можешь меня взять

ну хотел бы пойти. но пока не знаю с чем и с кем)

гоу спамер напишем

@krivdaallstarts а ты в Питере?

@krivdaallstarts а ты в Питере?

я приеду

ехать 4 часа на сапсане

Добрый день! Подскажите, кто-нибудь работает с AWS на Scala? Я смотрю, тут на сайте нет официальной поддержки, а на гитхабе несколько реализации SDK. Может посоветуете, с какой начать ?

Добрый день! Подскажите, кто-нибудь работает с AWS на Scala? Я смотрю, тут на сайте нет официальной поддержки, а на гитхабе несколько реализации SDK. Может посоветуете, с какой начать ?

http://developer.lightbend.com/docs/alpakka/current/connectors.html

юзаем aws sdk для джавы (из скалы) и немного alpakka

Благодарю, изучу варианты

https://www.manning.com/dotd сегодня действителен еще

https://medium.com/@viktortnk/monorepo-for-small-teams-part-1-why-d7b96d5173a

...По мотивам недавнего анализа билд тулов от Jetbrains и в подкасте Scalalaz

интересно было бы поднять вопрос и возможно получить фидбэк для следующей части

возможно, много упускаю. Но просто кажется альтернативы не часто озвучиваются и всплывают в сети

Монорепо гуд, пока у тебя нет подпроекта, где спарк и ты застрял на 2.10.5, например.

Артифактный ад тоже то ещё удовольствие

Почитал бы вторую часть с удовольствием ?

@aleksei_t ты прав, в монорепе больше неоюходимости в борьбе с jar hell. Приходится быть довольно строгими с тем, что притаскиваем

У нас обычно с netty немного возни, приходится удостоверяться что версии у всех netty 3rdparty библиотек примерно одинаковые

Мы просто шейдим, имхо лучшее решение

А примерная одинаковость все равно дает неожиданности в рантайме

Мы просто шейдим, имхо лучшее решение

+

Ну если постоянно не гоняться за всеми новыми версиями, то можно в раз все обновлять и потом жить с этим долго. Но если какая-то либа публикуется в shaded варианте, мы конечно тянем ее

Ну с хадупами кафками и пр оч сложно одной версии неттии или гуавы добиться, к сожалению

Почитал бы вторую часть с удовольствием ?

+1

Это же стыд какой что я немогу писать _.headOption там где ожидается FunctionK[List, Option]

Возможно, что все знают, но я тут гулял и случайно нашёл на улице: https://github.com/non/kind-projector#polymorphic-lambda-values

случайно наступил?

Идея не знает про них, они все обещают сделать ) а так удобно, но все равно вербозно

Возможно, что все знают, но я тут гулял и случайно нашёл на улице: https://github.com/non/kind-projector#polymorphic-lambda-values

было, да

кстати все равно удобно; и поли лямбды и тайп лямбдо сахар

Возможно, что все знают, но я тут гулял и случайно нашёл на улице: https://github.com/non/kind-projector#polymorphic-lambda-values

как же так, я думал ты смотрел исходники котов

или ты конкретно про Polymorphic lambda values ?

или ты конкретно про Polymorphic lambda values ?

конкретно, конечно

просто кайнд-прожектор редко обновляют и я не знал, что их добавили в 9-й версии в прошлом году

посмотри, на что реплай

@aleksei_t @tvaroh FYI https://finelydistributed.io/monorepo-for-small-teams-part-1-9-why-you-havent-heard-of-pants-28358b12f0cb

https://finelydistributed.io/monorepo-for-small-teams-part-2-1-modularity-with-pants-82182996c98f

останется только последняя часть

о, ?

чет я не понял, почему мульти репо это плохо?

посмотри, на что реплай

ok, I got it

чет я не понял, почему мульти репо это плохо?

потому что "так сложилось" у многих контор, переделывать нормально нет средств, вот и убеждают себя

как так? моно репо у многих?

ну да

твиттер тот же

хм, ну может быть. Я просто такого не встречал)

А я не оч понял, речь про то что вот есть например бэкенд, и он микросервисный — давайте не будем разделять его в разные репозитарии потому что это принесет много проблем? Если так, то я согласен полностью. Но есть же еще вопрос с монорепой на фронт и бэк например. И еще на какие-то составляющие проекты, например на аналитику, если она отдельно, и тд. Было же бы супер круто иметь возможность держать в одной репе скажем бэкенд, фронт под мобилки, фронт под веб, и еще что-нибудь. Тогда можно их вместе удобно релизить, например через release branches, протокол шарить, и если ЯП позволяют, то даже утилитарные всякие вещи шарить. Но если попытаться такой подход реализовать, оказывается что очень неочевидно как правильно это сделать. Кто-нибудь пытался такое внедрить у себя?

> Тогда можно их вместе удобно релизить Это не работает. У этих кусков общего только интерфейс сервиса, остальное все свое. Свои задачи и приоритеты. Да и банально невозможно все свести к одному релизу - яркий пример мобилки, у которых даже под разные ось свои циклы.

А я не оч понял, речь про то что вот есть например бэкенд, и он микросервисный — давайте не будем разделять его в разные репозитарии потому что это принесет много проблем? Если так, то я согласен полностью. Но есть же еще вопрос с монорепой на фронт и бэк например. И еще на какие-то составляющие проекты, например на аналитику, если она отдельно, и тд. Было же бы супер круто иметь возможность держать в одной репе скажем бэкенд, фронт под мобилки, фронт под веб, и еще что-нибудь. Тогда можно их вместе удобно релизить, например через release branches, протокол шарить, и если ЯП позволяют, то даже утилитарные всякие вещи шарить. Но если попытаться такой подход реализовать, оказывается что очень неочевидно как правильно это сделать. Кто-нибудь пытался такое внедрить у себя?

почему разные репы принесут проблемы?

А я не оч понял, речь про то что вот есть например бэкенд, и он микросервисный — давайте не будем разделять его в разные репозитарии потому что это принесет много проблем? Если так, то я согласен полностью. Но есть же еще вопрос с монорепой на фронт и бэк например. И еще на какие-то составляющие проекты, например на аналитику, если она отдельно, и тд. Было же бы супер круто иметь возможность держать в одной репе скажем бэкенд, фронт под мобилки, фронт под веб, и еще что-нибудь. Тогда можно их вместе удобно релизить, например через release branches, протокол шарить, и если ЯП позволяют, то даже утилитарные всякие вещи шарить. Но если попытаться такой подход реализовать, оказывается что очень неочевидно как правильно это сделать. Кто-нибудь пытался такое внедрить у себя?

Зависит от масштаба. Я конечно диванный эксперт и сам с монорепами не работал, но мне видится что это будет работать только на мелком и среднем масштабе. В большой компании могут быть сотни всяких разных проектов, которые вообще друг с другом никак не связаны. И там монорепо превратится в кашу.

Зависит от масштаба. Я конечно диванный эксперт и сам с монорепами не работал, но мне видится что это будет работать только на мелком и среднем масштабе. В большой компании могут быть сотни всяких разных проектов, которые вообще друг с другом никак не связаны. И там монорепо превратится в кашу.

это да, если все проекты скидывать в одну репу — будет плохо. Я имел ввиду в рамках одного проекта, да. Ну и понятно что с масштабом начнутся проблемы. Они и без масштаба начнутся на самом деле :) Ветки одной команды будут мешать другой, нужно оч строго следить за структурой директорий, и вообще много мороки.

мне даже для мелкого бизнеса это странным кажется, зачем билдить каждый раз все?

почему разные репы принесут проблемы?

Ну, никаких showstopper'ов в разных репах нету, если речь не про "разные репы" как написано в статье, а про "разные репы" как я писал — разные платформы или что-то такое же различное. Просто есть такая идея что если держать всё в одном месте, то это - проще, людям с одной стороны нравится, когда можно сразу всё охватить взглядом - подтолкнет разработчиков к шарингу кода/тестов/скриптов - подтолкнет разработчиков к унификации всех частей проекта - подтолкнет разработчиков к чтению кода других проектов, и таким образом а) позволит глубже понимать механики продукта; б) приблизит фуллстековость

Ну, никаких showstopper'ов в разных репах нету, если речь не про "разные репы" как написано в статье, а про "разные репы" как я писал — разные платформы или что-то такое же различное. Просто есть такая идея что если держать всё в одном месте, то это - проще, людям с одной стороны нравится, когда можно сразу всё охватить взглядом - подтолкнет разработчиков к шарингу кода/тестов/скриптов - подтолкнет разработчиков к унификации всех частей проекта - подтолкнет разработчиков к чтению кода других проектов, и таким образом а) позволит глубже понимать механики продукта; б) приблизит фуллстековость

ну для обьединения репозиториев можно использовать git submodules)

Но я не говорю "разные репы под разные платформы - зло", я скорее говорю "о у меня есть такая идея, и вроде там есть плюсы, но выглядит дико и сложно, кто делал?"

ну для обьединения репозиториев можно использовать git submodules)

Ну да, это если нужно билдить все вместе например или что-то такое. Репы как сабмодули это как раз посередине между обоими подходами, причем направление скорее от монорепы к раздельным репам чем наоборот, так что это противоположно моей идее

мне даже для мелкого бизнеса это странным кажется, зачем билдить каждый раз все?

А про билдить я не говорю, я говорю скорее про некоего рода сосуществование

ну плюшки у монореп есть, но вот на реально крупных масштабах это _зло_

Но это всё такое, пока на уровне идей и обсуждений внутри команды

ну плюшки у монореп есть, но вот на реально крупных масштабах это _зло_

ну вот какие?

ну для обьединения репозиториев можно использовать git submodules)

bи получить расстройство личности

пры бы в своих проектах досмотреть, когда уж там чужие проекты листать...

ну вот какие?

@gurinderu ну вот те что я написал например?

сабмодули в гите это ад и израиль

сабмодули в гите это ад и израиль

++

сабмодули в гите это ад и израиль

да все с ними ок)

да все с ними ок)

поэтому в гитбуке написано прям, что они получились не очень

да все с ними ок)

@gurinderu Сыграю в вангу: у тебя сишный бэкграунд?

@gurinderu ну вот те что я написал например?

размытые плюсы и сильно зависят от конкретной ситуации (проекты и команда)

@gurinderu Сыграю в вангу: у тебя сишный бэкграунд?

сабмодули не используются в ядре линукса

сабмодули не используются в ядре линукса

и что

ядра линукс и на гитхабе нету