В комментариях видно, что кол-во точных углов на эклиптике Урана к планетам в момент рождения человека коррелирует с увеличением событий в тот или иной год (с p-value < 2.2e-16).
Имелось ввиду, самый мощный эффект, конечно там много других.
Вставлю пару слов об астрологии и науке, вообще, большая часть экспериментов(даже, того же Гоклена) были сделана людьми, которые далеки от астрологии, т.е. которые не учитывали базовые элементы астрологии. А у большей части астрологов-практиков нет достаточного научного образования для проведения грамотных экспериментов, есть конечно и исключения.
Приведу список интересных материалов для ознакомления:
Изучение «эффекта Марса» с помощью machine learning:
Публикация эксперимента в Nature и биас, который присутствовал у экспериментаторов.
В Беларуссии существует защищенная диссертация на тему астрологии(окей, из-за сильной предвзятости люди, стараются не использовать слово астология, да и по разным другим причинам): Вероника Кудрявцева «Методологические основы социального прогнозирования (универсумный подход)» (в интернете лежит автореферат), а вот так выглядит ее сайт. Так что «космономика» — это не новая отрасль знаний, а хорошо забытая старая астрология, нашедшая в университете понимание.
Вот диссертация по астрологии в Англии(в Англии проще с упоминанием слова астрология), а вот сайт автора.
В Германии есть интересная дипломная работа на тему астрологии ( ее текст и комментарии к ней ). В комментариях видно, что кол-во точных углов на эклиптике Урана к планетам в момент рождения человека коррелирует с увеличением событий в тот или иной год (с p-value < 2.2e-16).
Когда-то давно, Бузинов астролог планировал защищать диссертацию по астрологии(можно найти статьи за 2000 год), потом он больше публично ничего не говорил и неизвестно, дали ли ему защитить диссертацию или нет, но много лет спустя, можно увидеть, что существуют, к примеру, учебные пособия: Методика прогнозирования функционирования и устойчивости объектов на основе космических ритмозадающих факторов. в гос учреждениях.
В общем, такая вот подпольная жизнь у астрологии и науки.
В своё время, я начал делать свой персональный проект с Angular 1 и на тот момент — это был самый простой и лёгкий для понимания путь, как для backend-разработчика. В конечном итоге, Angular 1 лишил меня страха писать под вэб, за что ему большое спасибо. Потом, когда пришла эра React — я долго ходил вокруг, да около, много сложного и куча разнообразия, в конечном итоге теряешься, что выбрать, так я его и не смог понять, ждал выхода бэта Angular2 и начал переходить на него...
И тут, всё начало не срастаться (с учётом того, что мой проект на coffeescript + jade, большую часть кода я планировал оставить, да и coffeescript по-прежнему является моим выбором для фронтэнда). Начал изучать Angular2, но без TS, мне нужен был именно Javascript, чтобы без магии переводить его в Coffeescript. Документация совершенно не полная, из 16 отделов для TS в JS было всего 4, даже главы объясняющей архитектуру не было, без которой было сложно двигаться. Примеры из этих 4 глав на половину не работали, подключались какие-то библиотеки помимо Angular-а, непонятно зачем. В конечном итоге, потратив дня 3 на попытки разобраться самому, я расписал примеры чего, я хочу видеть, и заказал у фрилансера через upwork пример рабочего приложения, получил его через два дня с решением, что смогу сам перевести на Coffeescript и подключить build систему. Помимо этого там был магический фаил, который создавал абстракцию для эмуляции чего-то похожего на декораторы в Typescript-е.
В конечном итоге, потратив более 30 часов и дневную работу фрилансера на Angular2, читая хабрахабр я наткнулся на VueJs, мне очень понравилось начало, примеры оказались проще, чем у Angular2, а я продолжал читать о Vue, легко находил ответы на свои вопросы в документации на классическом Javascript, который я без труда мог перевести в Coffeescript. С помощью Vue скрипта я создал сразу проект, легко модифицировав пример с Jade и Coffeescript (а компоненты .vue — это вообще оказалось гениальное решение, держать шаблон с Jade и код в Coffeescript в одном файле и стиль к шаблону в том же файле). В конечном итоге, где-то за 3 вечера я сделал на Vue(не использовав его до этого) нужный мне прототип.
Самое интересное, что именно для Vue была статья, которая объяснила мне популярную архитектуру под React и объяснила, как её легко и при необходимости можно использовать с Vue.
Ещё, немаловажная отличительная особенность — скорость ответов. Когда у меня был вопрос к Angular2 — то он висел там две недели(а дальше я перестал проверять) без ответа, как и десятки других вопросов. Когда что-то не получалось с Vue, ответ пришёл в течение 1 часа, я и не ожидал так быстро.
В конечном итоге, простота Vue + гибкость настройки под себя + в отличие от React есть стандартные библиотеки для всего, что нужно, и они очень легко подключаются и работают + коммьюнити, которое в отличие от Angular2 отвечает на вопросы(я уже не говорю про скорость) — сделали мой выбор на Vue окончательным. И учитывая, с какой простотой я подключил jade и могу писать jade разметку и код компонента в одном файле в разных блоках, то даже не представляю как и когда это будет возможно в Angular2, всё-таки Vue здесь технически проблему решил пока намного более гибким способом (по моему личному мнению).
Всё было бы по-другому, если бы я не шёл бы на перекор TypeScript-у, как поступили Вы. Но и поэтому мне был бы интересен ваш опыт с VueJS, чем он оказался хуже Angular2.
Скажите, как добавить или помочь добавить тот или иной язык? (Мои пожелания: Elixir) Плюс в том, что можно уже использовать erlang тесты для проверки эликсир программ(только добавить elixir и компилировать по-другому). Готов оказать любую помощь бесплатно, при необходимости.
Я видел как минимум с сотню живых разработчиков на Elixir. На конференции по Erlang-у всегда собирается много Elixir разработчиков, куда включаются и доклады по Elixir, тусовка вокруг эликсира не изолирована от эрланговской. Чаще интеграция происходит так, разработчики садятся за Elixir — видят те или иные преимущества из-за которых стоит перейти на Elixir, включают существующий эрланг код (который mix-ом хорошо интегрируется, rebar-проекты компилируются ребаром, Makefile-ы мейком, соответственно и все нифы компилируются), и переходят на Elixir — как минимум в «верхнем» проекте. rebar3 скооперировался с Elixir разработчиками, и использует hex, как пакет менеджер и возможно, что он будет поддерживать построение Elixir проектов mix-ом, как это делает mix c ребаром — возможно, что это решит проблему? Я за rebar3 не следил в этом плане, но наверное — это было бы идеальном решением по интеграции, которое может прийти со стороны rebar3.
Отсутствие спроса на оную интеграцию — не показатель, иначе можно сказать, что такое позднее появление maps-ов в эрланге «показатель наихудшего ретроградства в эрланге, к которой как-то боязно подходить». Но и это не так, отсутствие спроса и здесь был так или иначе фактором, который повлиял на их введение или невведение в тот или иной момент времени maps-ов в эрланг. И там и тут играет роль, человеческий фактор.
Если erlang проект включён как зависимость к elixir проекту, то он зависимость компилирует указанной системой сборки, значит что erlang проекты, которые компилируются rebar-ом или make-ом mix умеет компилировать.
* rebar_elixir_plugin — низкий спрос на интеграцию elixir-а в erlang проект сделал его практически не поддерживаемым. Но в целом — проблема — это определённые баги или недочёты в плагине, которые можно устранить. Мы же, конечно поступали иначе, добавили поверх эрланг-проекта wrapper проект с эликсиром и тянули erlang проект, как зависимость, вся система сборки сабпроектов сохранилась (rebar-овские проекты компилировались rebar-ом, Makefile-овые мейком, и все нифы тоже компилировались).
* Учитывая, что для этого есть механизм changeset-ов:
Который решает проблему json | erlang map -> ecto model — решение тут простое. А вообще, учитывая, что в elixir-е структуры полиморфные структуры, а в эрланге полиморфных структур официально нет, то не удивительно, что нужно делать трансформацию из неполиморфной структуры в полиморфную.
* «Что ecto жестко привязан к эликсирному логгеру, как результат нам нужно конфигурить два логгера при старте — потому что у нас уже есть логгер, какой проект без логгера.» — это единственная неприятная проблема, в которой без trade-off-ов не выйти просто, и на самом деле это боль с обоих сторон, скрипя сердцем github.com/PSPDFKit-labs/lager_logger пришлось включить в новый проект эту библиотеку, так как какие библиотеки не возьми, в разные erlang проект lager часто тоже хардкором вписан и по-другому никак.
Нет, как раз из-за этого, rebar_elixir_plugin был создан почти с появлением elixir-ом, в истории issues, я нашёл всего 1 issue, ок pull request-ов было больше, но больше половины из них от elixir-разработчиков, которые им занимались несмотря на спрос, равный почти нулю. Если бы был спрос, было бы намного больше issue. В данном случае, нет спроса, нет и проработки, а не наоборот.
Я не мог не прокомментировать этот комментарий, так как мы ecto используем с версии помойму 0.10.0 или может даже раньше, уже как год и пароль там точно работал всегда, а посмотрев историю и тесты ecto — то видно, что к базе данных она ходит по паролю с самой первой версии, ещё с 0.1.0: github.com/elixir-lang/ecto/blob/v0.1.0/integration_test/pg/test_helper.exs#L23
Можно Elixir — подключить к Erlang проекту. После компиляции весь Elixir и все Elixir проекты ничто иное, как точно такие же .beam файлы и OTP приложения, как и от erlang проекта. В конечном итоге — Elixir — это просто OTP приложение. И функции Elixir-овского кода из Erlang-а можно вызывать.
И он скачивает ту зависимость, которая тебе нужна. Не представляете, как легко стало решить все конфликты при включении даже такого dependency hell, как riak_core в elixir проект… Эти проблемы mix решает прекрасно.
При том, очень сильно не договаривает. Пароль к базе данных существует с версии 0.1.0. С версии 0.10.0 использовали в разработке, с версии 0.12.0 мы используем ecto в production, где пароль и подавно во всех версиях работает.
А что мешает использовать эликсир в эрланговском коде? Помимо прямого использования эликсировских макро из эрланга (что по логичным причинам невозможно).
Имелось ввиду, самый мощный эффект, конечно там много других.
Приведу список интересных материалов для ознакомления:
Изучение «эффекта Марса» с помощью machine learning:
Публикация эксперимента в Nature и биас, который присутствовал у экспериментаторов.
В Беларуссии существует защищенная диссертация на тему астрологии(окей, из-за сильной предвзятости люди, стараются не использовать слово астология, да и по разным другим причинам): Вероника Кудрявцева «Методологические основы социального прогнозирования (универсумный подход)» (в интернете лежит автореферат), а вот так выглядит ее сайт. Так что «космономика» — это не новая отрасль знаний, а хорошо забытая старая астрология, нашедшая в университете понимание.
Вот диссертация по астрологии в Англии(в Англии проще с упоминанием слова астрология), а вот сайт автора.
В Германии есть интересная дипломная работа на тему астрологии ( ее текст и комментарии к ней ). В комментариях видно, что кол-во точных углов на эклиптике Урана к планетам в момент рождения человека коррелирует с увеличением событий в тот или иной год (с p-value < 2.2e-16).
Когда-то давно, Бузинов астролог планировал защищать диссертацию по астрологии(можно найти статьи за 2000 год), потом он больше публично ничего не говорил и неизвестно, дали ли ему защитить диссертацию или нет, но много лет спустя, можно увидеть, что существуют, к примеру, учебные пособия: Методика прогнозирования функционирования и устойчивости объектов на основе космических ритмозадающих факторов. в гос учреждениях.
В общем, такая вот подпольная жизнь у астрологии и науки.
Поделюсь своим опытом c Angular2.
В своё время, я начал делать свой персональный проект с Angular 1 и на тот момент — это был самый простой и лёгкий для понимания путь, как для backend-разработчика. В конечном итоге, Angular 1 лишил меня страха писать под вэб, за что ему большое спасибо. Потом, когда пришла эра React — я долго ходил вокруг, да около, много сложного и куча разнообразия, в конечном итоге теряешься, что выбрать, так я его и не смог понять, ждал выхода бэта Angular2 и начал переходить на него...
И тут, всё начало не срастаться (с учётом того, что мой проект на coffeescript + jade, большую часть кода я планировал оставить, да и coffeescript по-прежнему является моим выбором для фронтэнда). Начал изучать Angular2, но без TS, мне нужен был именно Javascript, чтобы без магии переводить его в Coffeescript. Документация совершенно не полная, из 16 отделов для TS в JS было всего 4, даже главы объясняющей архитектуру не было, без которой было сложно двигаться. Примеры из этих 4 глав на половину не работали, подключались какие-то библиотеки помимо Angular-а, непонятно зачем. В конечном итоге, потратив дня 3 на попытки разобраться самому, я расписал примеры чего, я хочу видеть, и заказал у фрилансера через upwork пример рабочего приложения, получил его через два дня с решением, что смогу сам перевести на Coffeescript и подключить build систему. Помимо этого там был магический фаил, который создавал абстракцию для эмуляции чего-то похожего на декораторы в Typescript-е.
В конечном итоге, потратив более 30 часов и дневную работу фрилансера на Angular2, читая хабрахабр я наткнулся на VueJs, мне очень понравилось начало, примеры оказались проще, чем у Angular2, а я продолжал читать о Vue, легко находил ответы на свои вопросы в документации на классическом Javascript, который я без труда мог перевести в Coffeescript. С помощью Vue скрипта я создал сразу проект, легко модифицировав пример с Jade и Coffeescript (а компоненты .vue — это вообще оказалось гениальное решение, держать шаблон с Jade и код в Coffeescript в одном файле и стиль к шаблону в том же файле). В конечном итоге, где-то за 3 вечера я сделал на Vue(не использовав его до этого) нужный мне прототип.
Самое интересное, что именно для Vue была статья, которая объяснила мне популярную архитектуру под React и объяснила, как её легко и при необходимости можно использовать с Vue.
Ещё, немаловажная отличительная особенность — скорость ответов. Когда у меня был вопрос к Angular2 — то он висел там две недели(а дальше я перестал проверять) без ответа, как и десятки других вопросов. Когда что-то не получалось с Vue, ответ пришёл в течение 1 часа, я и не ожидал так быстро.
В конечном итоге, простота Vue + гибкость настройки под себя + в отличие от React есть стандартные библиотеки для всего, что нужно, и они очень легко подключаются и работают + коммьюнити, которое в отличие от Angular2 отвечает на вопросы(я уже не говорю про скорость) — сделали мой выбор на Vue окончательным. И учитывая, с какой простотой я подключил jade и могу писать jade разметку и код компонента в одном файле в разных блоках, то даже не представляю как и когда это будет возможно в Angular2, всё-таки Vue здесь технически проблему решил пока намного более гибким способом (по моему личному мнению).
Всё было бы по-другому, если бы я не шёл бы на перекор TypeScript-у, как поступили Вы. Но и поэтому мне был бы интересен ваш опыт с VueJS, чем он оказался хуже Angular2.
* rebar_elixir_plugin — низкий спрос на интеграцию elixir-а в erlang проект сделал его практически не поддерживаемым. Но в целом — проблема — это определённые баги или недочёты в плагине, которые можно устранить. Мы же, конечно поступали иначе, добавили поверх эрланг-проекта wrapper проект с эликсиром и тянули erlang проект, как зависимость, вся система сборки сабпроектов сохранилась (rebar-овские проекты компилировались rebar-ом, Makefile-овые мейком, и все нифы тоже компилировались).
* Учитывая, что для этого есть механизм changeset-ов:
Который решает проблему json | erlang map -> ecto model — решение тут простое. А вообще, учитывая, что в elixir-е структуры полиморфные структуры, а в эрланге полиморфных структур официально нет, то не удивительно, что нужно делать трансформацию из неполиморфной структуры в полиморфную.
* «Что ecto жестко привязан к эликсирному логгеру, как результат нам нужно конфигурить два логгера при старте — потому что у нас уже есть логгер, какой проект без логгера.» — это единственная неприятная проблема, в которой без trade-off-ов не выйти просто, и на самом деле это боль с обоих сторон, скрипя сердцем github.com/PSPDFKit-labs/lager_logger пришлось включить в новый проект эту библиотеку, так как какие библиотеки не возьми, в разные erlang проект lager часто тоже хардкором вписан и по-другому никак.
из
И он скачивает ту зависимость, которая тебе нужна. Не представляете, как легко стало решить все конфликты при включении даже такого dependency hell, как riak_core в elixir проект… Эти проблемы mix решает прекрасно.