вот только чего у Маннинга такие чудовищные обложки?

Это Маннинг, детка

лол)

Кстати, посмотрел я тут выступления Влашина с NDC Oslo

Оба доклада норм

Нормальный такой входной уровень для C#\

УРАААА, я научился использовать зависимые от shiny(R web framework) в F# R Type Provider

Решение прямо в лоб... Нагуглил очень случайно =) R.wordcloud2(data = R.demoFreq) |> R.print

вот это самое print позволяет рендерить то, что приходит из модуля wordcloud2

Парни, куда бы это записать, что бы все знали ?

Парни, куда бы это записать, что бы все знали ?

В блог!

Парни, куда бы это записать, что бы все знали ?

Давай статью на хабр

Там вроде рейтинг нужен

Что бы писать.

Я то могу запилить =)

Решение прямо в лоб... Нагуглил очень случайно =) R.wordcloud2(data = R.demoFreq) |> R.print

Вордклауд2 эт жсная библиотека же

@Worldbeater https://cran.r-project.org/web/packages/wordcloud2/vignettes/wordcloud.html

оно видать js → R → F# =)

Там вроде рейтинг нужен

В “песочницу”, ты только еще кишочков добавить вообще про R на F#

Окей, буду писать по вечерам статейку, потом сюда скину.

А сколько нас, которым про R внутри F# интересно ?

Я что-то туплю - не могу понять как выглядит тип demoFreq

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

немного ещё жс в ф чате: я писал вордклауд на d3.js https://github.com/jasondavies/d3-cloud

соре за оффтопик

Через RStudio выяснил, что demoFreq это rda файл и как создать подобный через F# пока не очень понятно, или хотя бы тип, с такой же структурой данных, что бы скармливать в wordcloud2

внутри исходников wordcloud2 нашел вот такую интересну конструкцию... if (class(data) == "table") { dataOut = data.frame(name = names(data), freq = as.vector(data)) } else { data = as.data.frame(data) dataOut = data[, 1:2] names(dataOut) = c("name", "freq") }

Опа, видать можно попробовать сделать на F# лист и замапить его на R лист

А сколько нас, которым про R внутри F# интересно ?

много

В общем, буду разбираться дома и писать статью параллельно.

> OO is an essential component for large F# projects, but I wouldn't call it OO first. The core of the language is still ML.

@angmarr ты если не ошибаюсь что-то подобное упоминал. Как бы ты делал такую модель в NoSQL - надо хранить партии готовой продукции (приборы). К партии относится ряд пропертей (дата создания и т.п.) и список приборов (у приборов овердофига пропртей). Я всё ни как не могу опредлиться - хранить приборы внутри документа с партией, либо для каждого создавать отдельный документ, а внутри партии держать список ID документов приборов. Профит второго варианта - можно безболезненно просматривать какие партии есть в репозитории (при этом не надо десериализовывать всю БД), но в этом случае структура БД усложняется.

буду делать это на F# в LiteDB

А почему не хранить в приборах Id партии? И сколько будет приборов в одной партии?

буду делать это на F# в LiteDB

Кстати ты не планируешь хранить DU? Интересно как с этим LiteDB, у mongo я столкнулся с некоторыми проблемами.

А почему не хранить в приборах Id партии? И сколько будет приборов в одной партии?

собственно во втором варианте это не избежно. приборов от ~10 до ~100

Кстати ты не планируешь хранить DU? Интересно как с этим LiteDB, у mongo я столкнулся с некоторыми проблемами.

не, в LiteDB не умеет в структуры данных F# к сожалению( FsPickler - без проблем.

собственно во втором варианте это не избежно. приборов от ~10 до ~100

Так все таки список Id приборов в партии или Id партии в каждом приборе?

думаю, и то, и то

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

Но это же возможная некончистентность. В общем я делаю у себя по второму варианту, но без списка Id

Ок, понятно. Ну тут в любом случае консистентность обеспечивает прикладной код и есть много способов её похерить. Придётся писать много тестов как всегда.

Посмотрел доклады по акторам, ещё более непонятно стало)

Посмотрел доклады по акторам, ещё более непонятно стало)

что не понятно?)

что не понятно?)

Ну во первых, я начал сомневаться, что оно здесь уместно

Ну во первых, я начал сомневаться, что оно здесь уместно

почему?

Во вторых, я не понял, нужна ли мне БД, или достаточно будет персистентности

Во вторых, я не понял, нужна ли мне БД, или достаточно будет персистентности

для персистентности нужна БД, но тебе не надо писать запросов.

Ну и в третьих, как вообще должна выглядеть архитектура, какие акторы и т.п.

для персистентности нужна БД, но тебе не надо писать запросов.

За тебя восстановлением и сохранением будет заниматься плагин. ты будешь только писатть save/restore

Ну и в третьих, как вообще должна выглядеть архитектура, какие акторы и т.п.

архитектура это не к акторам.

для персистентности нужна БД, но тебе не надо писать запросов.

Ну да, я криво немного выразился.

Ну и в третьих, как вообще должна выглядеть архитектура, какие акторы и т.п.

акторы хорошо роляют с eventsource + cqrs. Но можно обойтись и без акторов.

Там же абстрагировно. Может как БД использоваться, так и локальное хранилище. И вот я имел ввиду, достаточно ли мне будет персистентности, или всё же нужна БД для хранения каких-то своих данных

ноесли тебе нужно просто восстанавливать состояние чатика бе всяких сайдэффектов, то архитектура простая. Получил сообщение, обработал, сохранил.

Ну мне бывает нужно в истории поковыряться, найти какие-либо сообщения

Или просто всю историю получить

Там же абстрагировно. Может как БД использоваться, так и локальное хранилище. И вот я имел ввиду, достаточно ли мне будет персистентности, или всё же нужна БД для хранения каких-то своих данных

это уже от задачи зависит. Обычно, нужна, особенно если у тебя интеграция с другими системами есть. Напримре по CQRS у тебя write это persistnece(Акка), а Query это витрина данных, любая БД, \и эти данные не важны, т.к. ты их можешь пересобрать из event лога.

Или просто всю историю получить

ща

все удалил, т.к. понял что сложно.

Или просто всю историю получить

пошли в ЛС

Посмотрел доклады по акторам, ещё более непонятно стало)

Акка как, мне кажется, трудный фреймворк, но на самом деле всё действительно просто. Чтобы понять, тебе надо не доклады смотреть, а изучить модель акторов. Там смысл в том, что 1) есть изолированный иммутабельный стэйт 2) чтобы его изменить, нужно отправить сообщение, в которое вложены данные с описанием изменения состояния. Всё. Как это работает на практике легко понять 1) изучая erlang, на основе которого сделана акка 2) во фронтэнде redux. Или elm архитектура, что то же самое

Акка как, мне кажется, трудный фреймворк, но на самом деле всё действительно просто. Чтобы понять, тебе надо не доклады смотреть, а изучить модель акторов. Там смысл в том, что 1) есть изолированный иммутабельный стэйт 2) чтобы его изменить, нужно отправить сообщение, в которое вложены данные с описанием изменения состояния. Всё. Как это работает на практике легко понять 1) изучая erlang, на основе которого сделана акка 2) во фронтэнде redux. Или elm архитектура, что то же самое

С моделью акторов,имхо, просто нужен другой тип мышления.Мыслить не объектами,а сообщениями. Кстати, по идее,uml sequence diagram неплохо подходит для описания взаимосвязей между акторами.Ну а грамотно спроектировать систему на акторах -все же для меня уровень бог пока

Акка как, мне кажется, трудный фреймворк, но на самом деле всё действительно просто. Чтобы понять, тебе надо не доклады смотреть, а изучить модель акторов. Там смысл в том, что 1) есть изолированный иммутабельный стэйт 2) чтобы его изменить, нужно отправить сообщение, в которое вложены данные с описанием изменения состояния. Всё. Как это работает на практике легко понять 1) изучая erlang, на основе которого сделана акка 2) во фронтэнде redux. Или elm архитектура, что то же самое

да redux похож

С моделью акторов,имхо, просто нужен другой тип мышления.Мыслить не объектами,а сообщениями. Кстати, по идее,uml sequence diagram неплохо подходит для описания взаимосвязей между акторами.Ну а грамотно спроектировать систему на акторах -все же для меня уровень бог пока

ты будешь смеяться, но в 80х годах всё это уже было в продакшене - и редакс, и акка, и даже рендеринг по необходимости, а не когда стейт меняется. Примерно в таком виде: LRESULT CALLBACK WndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam) { switch (message) { case WM_PAINT: hdc = BeginPaint(hWnd, &ps); // Here your application is laid out. For this introduction, we just print out "Hello, World!" in the top left corner. TextOut(hdc, 5, 5, greeting, _tcslen(greeting)); // End application-specific layout section. EndPaint(hWnd, &ps); break; case WM_DESTROY: PostQuitMessage(0); break; default: return DefWindowProc(hWnd, message, wParam, lParam); break; } return 0; } Но мужланы не поняли прекрасную идею, и обернули ее в богомерзкий ООП в виде Delphi. Эх, не было еще тогда ES6 и NPM, и светлых голов современных хипстеров))

ты будешь смеяться, но в 80х годах всё это уже было в продакшене - и редакс, и акка, и даже рендеринг по необходимости, а не когда стейт меняется. Примерно в таком виде: LRESULT CALLBACK WndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam) { switch (message) { case WM_PAINT: hdc = BeginPaint(hWnd, &ps); // Here your application is laid out. For this introduction, we just print out "Hello, World!" in the top left corner. TextOut(hdc, 5, 5, greeting, _tcslen(greeting)); // End application-specific layout section. EndPaint(hWnd, &ps); break; case WM_DESTROY: PostQuitMessage(0); break; default: return DefWindowProc(hWnd, message, wParam, lParam); break; } return 0; } Но мужланы не поняли прекрасную идею, и обернули ее в богомерзкий ООП в виде Delphi. Эх, не было еще тогда ES6 и NPM, и светлых голов современных хипстеров))

О, мы такое в универе писали. Буквально в прошлом году, а ты про 80-ые...

О, мы такое в универе писали. Буквально в прошлом году, а ты про 80-ые...

сочувствую..

ты будешь смеяться, но в 80х годах всё это уже было в продакшене - и редакс, и акка, и даже рендеринг по необходимости, а не когда стейт меняется. Примерно в таком виде: LRESULT CALLBACK WndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam) { switch (message) { case WM_PAINT: hdc = BeginPaint(hWnd, &ps); // Here your application is laid out. For this introduction, we just print out "Hello, World!" in the top left corner. TextOut(hdc, 5, 5, greeting, _tcslen(greeting)); // End application-specific layout section. EndPaint(hWnd, &ps); break; case WM_DESTROY: PostQuitMessage(0); break; default: return DefWindowProc(hWnd, message, wParam, lParam); break; } return 0; } Но мужланы не поняли прекрасную идею, и обернули ее в богомерзкий ООП в виде Delphi. Эх, не было еще тогда ES6 и NPM, и светлых голов современных хипстеров))

Ну вот кстати да, вполне себе жизнеспособная вещь была

Она еще в винформах была даже

Еще,помню,в винапи была практика возврата нужного количества памяти под возвращаемую коллекцию

Ну вот кстати да, вполне себе жизнеспособная вещь была

А чего хорошего? концепция не взлетела. Не потому что не было first-class функций, и люди не заморачивались immutability. А потому что не скейлится на сложность. Как декомпозицию делать - непонятно. Поэтому дельфи зашло, и другие ООП-штуки про UI зашли. Которые про то, что стейт инкапсулирован с рендером в одну, реюзабельную, коробочку. А redux этот, как и акка, красивы только пока у тебя что-то простенькое.

А чего хорошего? концепция не взлетела. Не потому что не было first-class функций, и люди не заморачивались immutability. А потому что не скейлится на сложность. Как декомпозицию делать - непонятно. Поэтому дельфи зашло, и другие ООП-штуки про UI зашли. Которые про то, что стейт инкапсулирован с рендером в одну, реюзабельную, коробочку. А redux этот, как и акка, красивы только пока у тебя что-то простенькое.

т же говорил что на elm пишешь что-то. тот же подход. И все ок

так остальное ещё хуже. ну и у elm другие плюсы есть по мимио elm архитектуры. Я пишу в основном WebGL, там сообщений не так много как в насыщенном UX приложении, для которого я предпочту mobx + react на typescript

так остальное ещё хуже. ну и у elm другие плюсы есть по мимио elm архитектуры. Я пишу в основном WebGL, там сообщений не так много как в насыщенном UX приложении, для которого я предпочту mobx + react на typescript

понятно.

Dmitry Привет!

@avashkevich Привет!

А если в разных сборках два типа с одинаковым именем, как в F# это разруливать?

Типа using static

А если в разных сборках два типа с одинаковым именем, как в F# это разруливать?

type R = Fable.Import.React вроде так там было

https://www.infoq.com/news/2017/07/microsoft-fsharp-build?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=global

type R = Fable.Import.React вроде так там было

module R= Fable.Import.React