ну кто-то написал библиотеку

как ты из её байткода вырежешь кусок, необходимый для твоих отсутствующих методов, учитывая, что такой кусок, скорее всего равен всей библиотеке

и ты получишь несовместимость только уже на уровне своей франкенштейновой склейки

возьмем библиотеку Lib. соберем одну версию, среди которых будет класс Utils с методом test и будем его использовать на равне с другими классами этой библиотеки. Соберем джарник и вырежем из него класс Utils. Соберем новую версию этой библиотеки и заменим там содержимое метода test. Запустим приложение и в итоге легко можем получить ситуацию, при которой все классы будут использоваться из первой сборки, а вот наш класс Utils может быть легко загружен из второй сборки. Таким образом будут использоваться обе версии сборки. 99% из первой сборки и 1% из второй - и они вполне могут выполнять интероп без всяких казусов

хоть раз этот алгоритм ты успешно реализовал?

хоть раз этот алгоритм ты успешно реализовал?

если хочется искусственно породить подобное поведение - конечно это реализуемо. с практической точки зрения для работы - это зачастую не применимо, поскольку связи могут быть гораздо глубже - и в здравом уме никто даже пытаться не будет это делать. тем более, что если нужно пропатчить тело метода (обойти локи какие-нибудь) - проще сам джарник пересобрать заменив нужный блок. я не спорил с тобой, просто дополнял про некоторые нюансы, которые вполне могут иметь место исходя из алгоритма работы класслодера

https://github.com/nbronson/scala-stm использовал кто?

https://github.com/nbronson/scala-stm использовал кто?

вспомнился фильм Бронсон

А подкаст-то где?

А подкаст-то где?

На шейплессе, собирается ещё

Зато математически корректный!

Зато математически корректный!

Это ты потом спарку расскажешь!

http://degoes.net/articles/insufficiently-polymorphic Тут кто-то кидал на прошлой неделе. Я сначала подумал что это первоапрельский пост, но оказалось что нет

Здорова скаланы

One day Shizuo Kakutani was teaching a class at Yale. He wrote down a lemma on the blackboard and announced that the proof was obvious. One student timidly raised his hand and said that it wasn't obvious to him. Could Kakutani explain? After several moments' thought, Kakutani realized that he could not himself prove the lemma. He apologized, and said that he would report back at their next class meeting. After class, Kakutani, went straight to his office. He labored for quite a time and found that he could not prove the pesky lemma. He skipped lunch and went to the library to track down the lemma. After much work, he finally found the original paper. The lemma was stated clearly and succinctly. For the proof, the author had written "Exercise for the reader". The author of this 1941 paper was Kakutani.

с кодом на скале точно так же :)

с кодом на скале точно так же :)

» At least for me, the resulting improvements in code quality have been quite noticeable. If you’ve tried the technique, please share your experiences below! De Goes Kakutani

» At least for me, the resulting improvements in code quality have been quite noticeable. If you’ve tried the technique, please share your experiences below! De Goes Kakutani

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

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

I'm not sure I have any strong argument for one way or another in cases where longer names make sense. One can argue that `source` and `target` create wrong impression and are overly specific for `Lens`, but in the case of k/v, key/value seems more useful. Some people have suggested that tiny variable names are easier to read in short functions, where you don't need any context for "remembering" a variable's introduction and purpose. I can see this argument (long names are difficult for me to mentally parse), though it's far from definitive or universal.

ага, и пиши все в поинт-фри стиле, потому что ты супер-крут, а остальные лохи, да?

Ему тоже не приходится читать его код, он же для последователей пишет) Чукча не читатель, чукча писатель)

прочитал как "для преследователей"

А хороший критерий generic кода. Если ты можешь подобрать descriptive имя для параметра - твой код недостаточно обобщён!

или у тебя плохо с воображением

А хороший критерий generic кода. Если ты можешь подобрать descriptive имя для параметра - твой код недостаточно обобщён!

либо ты какую-то хрень пишешь мое куда вероятнее

Я неправильно написал. Скорей, если можно назвать параметр чем-то весьма конкретным (например, кейвордом из бизнеса), то такой код, скорее всего, нифига не generic. Но это и не плохо, в общем то.

скорее если ты не можешь назвать переменную кратко

Ну у меня часто бывает - пишешь утильную фунцию для перемещения данных из одной структуры в другую, называешь каким нибудь условным "projectKeysToIssues", а потом обобщаешь, и там уже нет никаких projects и всякого такого.

https://github.com/nbronson/scala-stm использовал кто?

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

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

А что у него за книжка ?

https://www.amazon.com/Learning-Concurrent-Programming-Aleksandar-Prokopec/dp/1783281413

книги этого издания как правило отвратительны)

спасибо

какого? packt? да ну брось

есть хорошие

Scala for Data Science, например, ничего вполне

я уже добавил себе в queue

правда, там упор на breeze первые пару глав :)

https://www.amazon.com/Learning-Concurrent-Programming-Aleksandar-Prokopec/dp/1783281413

я почему то сразу догадался что это Packt :)

книги этого издания как правило отвратительны)

вот да. у них ревью очень плохое. но бывают исключения

если автор индус, то , как правило у них просто ухудшенный вариант офф доки

пыщ! 13 выпуск http://scalalaz.ru/series-13.html

пыщ! 13 выпуск http://scalalaz.ru/series-13.html

Закрепи плиз, чтоб я утром не потерял)

А у меня прав нема)

Утром кто-нибудь закрепит

@gurinderu в shared media чата всегда можно найти

был же Season 2, а стал опять 1 !

а где там у нас чатик по хаскеллу?

Я знаю слек про FP, там есть хаскел

https://t.me/haskellru

например этот

http://fpchat.com/

Scalalaz #13 c Денисом Михайловым @notxcain про Liberator и Free. http://scalalaz.ru/series-13.html Не забывайте шарить в соцсетях!

Что посоветуете для работы с pdf ?

PDFBox ? Там вроде как раз допилили поддержку юникода))

Либо Apache PDFBox, если нужно писать или более-менее низкоуровневое чтение, либо Apache Tika, если нужно просто выдрать данные

Да вобщем-то надо всего лишь вставить картинку в существующий pdf и уметь pdf срендерить. PDFBox, судя по описанию, вполне себе должен подойти, спасибо!

Ну может быть можно какими-нибудь консольными утилитами обойтись

https://vc.ru/n/rocket-smoke-vs-tinkov

вот это я понимаю ответочка тинькову)

ждемс теперь, что Греф скажет ?

ждемс теперь, что Греф скажет ?

https://meduza.io/news/2017/01/23/gref-reshil-sokratit-polovinu-rabotnikov-sberbanka-im-predlozhili-poyti-v-pochtu-rossii

вот это понимаю ответочка

ERROR: S client not available

ах да, точно он вроде как первый был

а тинькофф и рокет - мелковато взяли

так у почты со сбером одна ЦА, а у рокета с ткс - другая

если просто отрендерить pdf, то часто удобен pdflatex и/или pdfjam

Привет всем. Посоветуйте,пожалуйста, годную ORM, будет использоваться для бота, главные требования к ней стабильность и норм работа с многопоточностью Спасибо заранее

https://github.com/salat/salat Вот вам ORM хахах)

Привет всем. Посоветуйте,пожалуйста, годную ORM, будет использоваться для бота, главные требования к ней стабильность и норм работа с многопоточностью Спасибо заранее

Может быть http://getquill.io ? (тоже в общем-то не ORM).

import com.mongodb.casbah.commons.conversions.MongoConversionHelper

Ребята, подскажите, чем лучше с Kafka из Scala работать?

стандартный драйвер

стандартный драйвер

версии 0.8, да?)))

не понимаю

вот у них джавовский драйвер естсь

версия 0.9, официальный клиент, что у них в вики немного устарел

что мешает взять 0.10.1?

Хорошо, это как-то поможет с выбором клиента?

вот официальный https://github.com/elodina/scala-kafka/commits/master там последний коммит год назад

https://mvnrepository.com/artifact/org.apache.kafka/kafka-clients/0.10.1.1

чем вам это не нравится?

Привет всем. Посоветуйте,пожалуйста, годную ORM, будет использоваться для бота, главные требования к ней стабильность и норм работа с многопоточностью Спасибо заранее

если будут динамические запросы (типа - если A, то в запрос нужно добавить такой-то фильтр) - scalikejdbc. Если все запросы заранее известные и никаких условий нет - однозначно quill

скалайк jdbc оч нравится, что это не орм

ORM не нужен

ORM не нужен

просто ты с sql не работаешь) и драйвера пишешь

Но не все же должны страдать :)

+ не забудь коннекторы к твоей БД глянуть. Про scalikejdbc не скажу, но quill например, даже кассандру поддерживает (хз насколько хорошо), не только "обычный" SQL.

просто ты с sql не работаешь) и драйвера пишешь

А в чем проблема писать за внутри Scala на крисвом, выразительном SQL-подобном DSL типа Quill или то что есть ScalalikeJDBC? В чем проблема маппить результаты запросов на кейс-классы?

И это не ORM.

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

и бд большая

А в чем проблема писать за внутри Scala на крисвом, выразительном SQL-подобном DSL типа Quill или то что есть ScalalikeJDBC? В чем проблема маппить результаты запросов на кейс-классы?

проблемы то нет, как мне показалось орм, что прототипировать очень быстро. Я ,честно, не работал с орм в джава мире(только обсуждаемые скалайк). Но у меня был достаточно тесный опыт с Entity на дот нете, и прототипирование было радостью. То есть ты бесшовно меняешь источник данных, рисуешь свои структуры , оно тебе сразу таблички рисует и ты общаешься с ним помощью LINQ , а если хочешь посмотреть генерируемый SQL то смотришь